If it only happens with preemption and with userspace access, it coulb be an issue with uhci-hcd. It should be safe against all of the paths that can occur.
I'll double check the code to see what the problem could be. This was reproducible with 2.5.40, right? JE On Fri, Oct 04, 2002, Duncan Sands <[EMAIL PROTECTED]> wrote: > 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
