T40 panics at usb_get_next_event() when ACPI is disabled
avatar at mmlab.cse.yzu.edu.tw
Tue Jun 8 02:42:38 GMT 2004
On Mon, 7 Jun 2004, Brian Buchanan wrote:
> Yes, I see this too on my T40p, but only when booting with the mouse
> plugged into the laptop through a USB hub connected to the docking
> station. If the mouse is plugged in directly to the laptop (I haven't
> tried plugging the USB hub directly into the laptop) or not plugged in,
The problem always occurs on my T40 when the USB mouse is directly plugged
into the laptop.
> the problem does not occur. My hypothesis is that because a certain
> event list entry is being overwritten, the USB event list only grows long
> enough to use this area of memory in this configuration.
Interesting hypothesis. What really bothers me is that the extra
"if (ueq != NULL)" checks didn't catch the NULL ueq case. According to the
backtrace, it crashed at "*ue = ueq->ue," where ueq is NULL at that moment.
> I wrote a function to perform a sanity check on the event list and
> determined that the list is not corrupt after all the USB boot-time events
> have been queued. The list becomes corrupted some time between then and
I'm curious about the sanity check function you've written. Would you mind
to post it?
> when usbd attempts to read the event queue. One of the events, the same
> one every time, is overwritten with something like 0x01000010 (I don't
> have a log of the actual bit pattern). Since it's happening to the same
> object every time, the next step would be to set a watch point in the
> debugger. I'll probably give this a try once I have a chance to consult
> with someone who knows more about kernel debugging.
Did you try to extract the backtrace from the core file? It helps for
Or you'd like to use DDB to do the online kernel debugging:
> I did experiment with rolling back some usb commits, but it does not
> appear that a change to the usb subsystem is what caused this breakage. I
> think something else in the system is misbehaving and overwriting memory.
Perhaps, since the enqueuing/dequeuing of usb_event supposed to be protected
by splusb(), there shouldn't be race here unless there's something wrong in
the interrupt priority(shared with splnet/splnet/splbio?) settings.
More information about the freebsd-current