Duncan Sands wrote:
> If I remove the uhci_hcd or ehci_hcd module, then I
> systematically get the following:
>
> (EIP) run_timer_softirq+0xe3/0x400
> timer_interrupt+0x1a3/0x3f0
> do_softirq+0xa1/0xb0
> do_IRQ+0x23f/0x380
> common_interrupt+0x18/0x20
> code: 89 50 04 89 02 C7 41
>
> kernel/timer.c:302: spin_lock (kernel/timer.c:c02f7b00) already
> locked by kernel/timer.c/398.
>
> killing interrupt handler etc
>
> Presumably this is related to the stall_timer.
> This has been happening for ?one week?, and
> still occurs with current BK. Occurs with and
> without preempt (UP).
>
> Any ideas?
I'm not getting it any more, but then I'm also running with
this patch too ... the current source prevents drivers from
properly disconnect()ing, which means all kinds of state
doesn't get cleaned up.
What usually gets me lately is that the whole system locks
up when I remove certain modules. SysRq behaves but little
else (no console). The common behavior seems to be that
the call_usermode_helper() logic is waiting forever; such
as waiting for network interface "remove" events to finish.
- Dave
--- 1.15/drivers/usb/core/urb.c Thu Mar 13 10:45:40 2003
+++ edited/drivers/usb/core/urb.c Thu Mar 20 11:17:55 2003
@@ -384,11 +384,11 @@
/* FIXME
* We should not care about the state here, but the host controllers
* die a horrible death if we unlink a urb for a device that has been
- * physically removed.
+ * physically removed. (after driver->disconnect returns...)
*/
if (urb &&
urb->dev &&
- (urb->dev->state >= USB_STATE_DEFAULT) &&
+ // (urb->dev->state >= USB_STATE_DEFAULT) &&
urb->dev->bus &&
urb->dev->bus->op)
return urb->dev->bus->op->unlink_urb(urb);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:20 EST