This seems to be related to preemption: oops with preemption (2.5.40), no oops without it. No oops with 2.5.39 without preemption. 2.5.39 with preemption is a problem since it hangs at boot time - I may apply Robert Love's fixes for this to 2.5.39 and see what happens.
In short - looks like a problem with locking. Duncan. PS: I am using the user space speedtouch driver - no kernel usb drivers at all (except for the uhci hub). I noticed that someone reported this same oops to lkml, also with the speedtouch driver. That suggests a problem in devio.c, or a false assumption somewhere that there is a kernel driver loaded for each usb device. On Tuesday 01 October 2002 19:05, Johannes Erdfelt wrote: > On Tue, Oct 01, 2002, Duncan Sands <[EMAIL PROTECTED]> wrote: > > When booting 2.5.40 I immediately get the following oops > > (copied down by hand); > > > > EIP is at uhci_result_control+0x11/0x1f0 [uhci-hcd] > > Process usbmodules > > Call Trace: > > uhci_transfer_result+0x67/0x170 [uhci-hcd] > > uhci_irq+0xd7/0x108 [uhci-hcd] > > usb_hcd_irq+0x19/0x38 > > handle_IRQ_event+0x28/0x4c > > do_IRQ+0x9d/0x114 > > common_interrupt+0x18/0x20 > > kernel_thread+0x6c/0x8c > > > > Here is part of uhci_transfer_result: > > > > 00002218 <uhci_result_control>: > > 2218: 83 ec 04 sub $0x4,%esp > > 221b: 55 push %ebp > > 221c: 57 push %edi > > 221d: 56 push %esi > > 221e: 53 push %ebx > > 221f: 8b 7c 24 1c mov 0x1c(%esp,1),%edi > > 2223: 8b 6f 08 mov 0x8(%edi),%ebp > > 2226: 8d 75 14 lea 0x14(%ebp),%esi > > 2229: 8b 45 14 mov 0x14(%ebp),%eax <=== HERE > > 222c: 39 f0 cmp %esi,%eax > > 222e: 75 10 jne 2240 <uhci_result_control+0x28> > > 2230: b8 ea ff ff ff mov $0xffffffea,%eax > > 2235: e9 c8 01 00 00 jmp 2402 <uhci_result_control+0x1ea> > > 223a: 8d b6 00 00 00 00 lea 0x0(%esi),%esi > > > > So it looks like the oops is happening here: > > > > int ret = 0; > > > > if (list_empty(&urbp->td_list)) <=== OOPS > > return -EINVAL; > > > > head = &urbp->td_list; > > > > > > Maybe this should be (no &): > > > > if (list_empty(urbp->td_list)) > > return -EINVAL; > > Nope, that's definately not the right fix. > > It's difficult to tell what the problem is since you don't have the rest > of the oops, but I'll venture to say that urbp is invalid. > > Does this problem exist in earlier kernels for you? > > I haven't made any changes to to the uhci-hcd driver in a number of > kernel versions so either the problem has been there for a long time or > something else is breaking it. > > JE ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
