On Sat, Jan 05, 2002, Peter Osterlund <[EMAIL PROTECTED]> wrote: > Johannes Erdfelt <[EMAIL PROTECTED]> writes: > > > In almost every case, usb_free_dev will be called in the khubd context. > > The only case I can think of where it would be called from an interrupt > > context (in the bug free case) would be a device disconnecting and the > > driver doing an asynchronous unlink (like for the uhci drivers). Then > > the reference would then hit 0 in the interrupt context. > > This is what was left at the top of my screen after the panic: > > hub.c: hub / port 1, portstatus 103, change 1, 12 Mb/s > usb.c: USB disconnect on device 2 > usb.c: kusbd: /sbin/hotplug remove 2 > hub.c: port 1, portstatus 103, change 0, 12 Mb/s > usb-uhci.c: interrupt, status 2, frame# 1311 > divide error: 0000 > > Does that give any clue as to what happened? > > I know that the drive was trying to carry out the first WRITE on a > CDRW disk, but because I had not given an explicit OPC (optimum power > calibration) command first, the drive decided for itself to perform > the OPC before doing the WRITE. However, the disk had a damaged or > worn out power calibration area, so the OPC failed. It sounded like > the drive was doing several OPC attempts before giving up. The write > command therefore took many more seconds than usual to complete. > > Maybe this is such an unusual situation so that it triggered a > firmware bug in the drive, causing it to misbehave badly on the bus.
It definately did get to the disconnect phase, which means it got through the parsing stage and there was a race condition. This sounds like it had a corrupted descriptor table. Did you get any odd messages when the device connected? JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
