I thought I had eliminated the allocation from interrupt context, but I'll look at
it again.


Brad Spencer wrote:

>    >    usb_block_allocmem: in interrupt context, size=4096
>    >
>    >
>    > Having no real idea what this message is trying to get at, I was wondering
>    > if anyone knows what this means??
>
>    The kernel malloc may have to block while waiting for pages to become
>    available. This is not a good thing to do in an interrupt context ;-)
>
>    So, if you can use kgdb or ddb: just set a breakpoint on that diagnostic
>    message, trigger it and post a stack backtrace, showing where
>    usb_block_allocmem is called from.
>
>    Martin
>
> Ok...  I set a breakpoint with ddb and the following stack trace was
> returned [1.4L kernel]:
>
> _usb_block_allocmem(f026dcc4,1000,0,f0568c3c,f0460000) at _usb_block_allocmem + 0x15
> _usb_allocmem(f0460000,29b,0,f0568c3c,f4e62bdc) at _usb_allocmem + 0x39
> _uhci_allocm(f0460000,f0568c3c,29b,e000de42,f4c34390) at _usb_allocm + 0x13
> _usbd_transfer(f056800) at _usbd_transfer + 0x52
> _umodemstart(f4c34390) at _umodemstart + 0xd0
> _pppstart(f4c34390) at _pppstart + 0x1b
> _pppsyncstart(f02908cc) at _pppsyncstart + 0x484
> _pppintr(10,10,f4e1bdc8,f4e1bdc8,f4e62ed4) at _pppintr + 0x89
>
> [ddb complained about corruption at this point]
>
> I could not make the system panic from ddb, so I do not have a kernel core
> dump to verify the above which was copied on to paper and then into email.
>
> Brad Spencer - brad@anduin.eldar.org   http://anduin.eldar.org
> [finger brad@anduin.eldar.org for PGP public key]

--

        -- Lennart