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.
--
Peter Osterlund - [EMAIL PROTECTED]
http://w1.894.telia.com/~u89404340
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
