On Tue, Jan 08, 2002, Peter Osterlund <[EMAIL PROTECTED]> wrote: > Johannes Erdfelt <[EMAIL PROTECTED]> writes: > > > On Sat, Jan 05, 2002, Peter Osterlund <[EMAIL PROTECTED]> wrote: > > > On Sat, 5 Jan 2002, Johannes Erdfelt wrote: > > > > > > > > Did you say this is reproducible? > > > > > > No, I have only seen this once, so maybe we should stop worrying about it > > > for now. At least, quite a few things were found while searching for the > > > problem, so I don't think the effort has been wasted. > > > > Yeah. Without a way to reproduce it and some of the logs gone, it's > > gonna be tough. > > > > Hopefully, one of those patches will fix the problem. If not, we'll hear > > from you again I guess :) > > OK, the good news is that it did happen again, this time with kernel > 2.4.18-pre1. The bad news is that it happened because my CDRW writer > broke. Anyway, this time I had serial console logging active, and > immediately before the oops/panic, this was logged: > > usb_control/bulk_msg: timeout > usb-uhci.c: interrupt, status 2, frame# 499 > > Maybe the usb layer timeout is exactly equal to the drive's internal > timeout. Immediately after printing the timeout msg, the code in usb.c > calls usb_unlink_urb(). If an interrupt occurs while inside that > function, and the interrupt routine also decides to call > usb_unlink_urb(), doesn't that have the potential to seriously mess > things up?
That could definately happen with usb-uhci.c. There's a race there. Also looks like one in uhci.c. I'm kinda surprised we haven't seen this before. > Here is the new oops, it looks very similar to the first one. [snip] JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
