On 5/28/20 12:05 PM, Alan Stern wrote:
Thanks, I've attached a usbmon trace to the bug. It seems the kernel submits
a bulk input transfer that never receives a response. I hope my drive isn't
broken...
Did you wait for thirty seconds after that final bulk input transfer
started? It should have been aborted at that point, just like the two
previous transfer attempts. There might be a bad sector on the disc you
were trying to read; all three attempts seem to have failed at the same
place.
Yes, in fact I waited for several minutes. The transfer seems never to
have been aborted.
I get the impression that the SCSI error handler may have tried to reset
the device without first aborting the current transfer. But it's not
easy to tell if that's what really happened. You might be able to get
more information by enabling CONFIG_USB_STORAGE_DEBUG and rebuilding the
usb-storage driver, or by turning on SCSI debugging.
I've attached a kernel log with CONFIG_USB_STORAGE_DEBUG to the bug
report. I'm not able to properly interpret the results, but I do see
"device_reset called" as the last USB/SCSI-related message without any
nearby mention of cancellation...?
The backtrace looks different, though.
With respect to SCSI debugging, the best instructions I was able to find
directed me to try:
hazel@watership:~$ cat /proc/scsi/sg/debug
max_active_device=2 def_reserved_size=32768
while the hang was taking place. If there's more useful debugging I can
do, I'll need pointers. I did enable CONFIG_SCSI_LOGGING in the above build.
