> In article <200102202141.f1KLfBD06548@buzzard.freeserve.co.uk>,
>    Richard Earnshaw <rearnsha@buzzard.freeserve.co.uk> wrote:
> > A stack backtrace would be useful, it would at least tell us the function 
> > that was dying.
> 
> I assume the command 'trace' produces this. I fear it is not going
> to be very helpful, though. All it says is:
> 
> _cpu_Debugger(_cpu_Debugger+0x10)
> _userret(_userret+0x10)
> _syscall(_syscall+0x10)

It is a clue, userret() contains the following code:

#ifdef DEBUG
        if (current_spl_level != _SPL_0) {
                printf("userret: spl level=%d on exit\n", 
current_spl_level);
#ifdef DDB
                Debugger();
#endif  /* DDB */
        }
#endif  /* DEBUG */

> 
> > Also, you could try just continuing.  What happens then?
> 
> I get the following messages:
> 
> db>continue
> userret: spl level=6 on exit
> Stopped in Xarm32VIDC at _cpu_Debugger+0x10: ldmdb r11,{r11,r13,r15}
> db>continue
> userret: spl level=6 on entry

Are you sure this was "on entry"?  I can't find that message in the source.


> Stopped in Xarm32VIDC at _cpu_Debugger+0x10: ldmdb r11,{r11,r13,r15}
> 
> The messages above were repeated a number of times. (About 10, I
> think.) After that I got the db> prompt but it would not take any
> more input. I found that the machine was working normally again
> when I switched to one of the other consoles. I found that there
> is a core dump (Xarm32VIDC.core). This is the first time this has
> been produced.
> 

So, we have a syscall that is trying to return control to the user without 
resetting the interrupt levels.  naughty!  A ktrace should tell us what it 
is, and how it fails.

R.