On Sun, 10 Dec 2017, Adam Borowski wrote: > Hi guys! > I have a μSD card that 100%-reproducibly causes the following when tested > with f3probe: > > [ 9241.126155] usb 2-1: new high-speed USB device number 3 using ehci-pci > [ 9241.287011] usb 2-1: New USB device found, idVendor=1976, idProduct=4082 > [ 9241.293846] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ 9241.301121] usb 2-1: Product: USB Reader > [ 9241.305146] usb 2-1: Manufacturer: ChipsBnk > [ 9241.309429] usb 2-1: SerialNumber: 110074973765 > [ 9241.327255] usb-storage 2-1:1.0: USB Mass Storage device detected > [ 9241.333801] scsi host8: usb-storage 2-1:1.0 > [ 9241.338194] usbcore: registered new interface driver usb-storage > [ 9242.370935] scsi 8:0:0:0: Direct-Access ChipsBnk Multi-Reader 4082 PQ: 0 ANSI: 2 > [ 9242.379943] sd 8:0:0:0: Attached scsi generic sg2 type 0 > [ 9242.381523] sd 8:0:0:0: [sdc] 30679040 512-byte logical blocks: (15.7 GB/14.6 GiB) > [ 9242.382135] sd 8:0:0:0: [sdc] Write Protect is off > [ 9242.382137] sd 8:0:0:0: [sdc] Mode Sense: 0b 00 00 08 > [ 9242.382755] sd 8:0:0:0: [sdc] No Caching mode page found > [ 9242.382757] sd 8:0:0:0: [sdc] Assuming drive cache: write through > [ 9242.386877] sdc: > [ 9242.396000] sd 8:0:0:0: [sdc] Attached SCSI removable disk > f3probe /dev/sdc > [ 9276.697035] usb 2-1: reset high-speed USB device number 3 using ehci-pci > [ 9276.915066] sdc: > [ 9626.072637] usb usb2-port1: disabled by hub (EMI?), re-enabling... The 350-second interval here suggests that the disable is not related to the preceding reset. The disable could simply be the result of barely adequate hardware. Have you tried switching USB ports, cables, SD cards, readers, etc? > [ 9626.078933] usb 2-1: USB disconnect, device number 3 > [ 9626.085727] scsi 8:0:0:0: rejecting I/O to offline device > [ 9626.091235] scsi 8:0:0:0: [sdc] killing request > [ 9626.095846] scsi 8:0:0:0: rejecting I/O to offline device > [ 9626.101318] scsi 8:0:0:0: [sdc] killing request > [ 9626.106007] scsi 8:0:0:0: [sdc] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK > [ 9626.114400] scsi 8:0:0:0: [sdc] CDB: Read(10) 28 00 01 9e 2c b0 00 00 f0 00 > [ 9626.121430] print_req_error: I/O error, dev sdc, sector 27143344 > [ 9626.127523] scsi 8:0:0:0: [sdc] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK > [ 9626.135918] scsi 8:0:0:0: [sdc] CDB: Read(10) 28 00 01 9e 2d a0 00 00 f0 00 > [ 9626.142918] print_req_error: I/O error, dev sdc, sector 27143584 > [ 9787.760554] INFO: task kworker/0:1:63 blocked for more than 120 seconds. > [ 9787.767381] Not tainted 4.15.0-rc2-debug-00490-gc09e9bbeb5d1 #1 > [ 9787.773947] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 9787.781892] kworker/0:1 D 0 63 2 0x80000000 > [ 9787.787495] Workqueue: usb_hub_wq hub_event > [ 9787.791760] Call Trace: > [ 9787.794277] ? __schedule+0x1a5/0x6e0 > [ 9787.798028] schedule+0x23/0x80 > [ 9787.801259] blk_mq_freeze_queue_wait+0x31/0x80 This suggests the hang is caused by the block layer's multiqueue code. You might be able to pin it down with git bisect. > [ 9787.805919] ? wait_woken+0x80/0x80 > [ 9787.809487] blk_cleanup_queue+0x68/0x110 > [ 9787.813614] __scsi_remove_device+0x6f/0x150 > [ 9787.818045] scsi_forget_host+0x1b/0x60 > [ 9787.821964] scsi_remove_host+0x6d/0x100 > [ 9787.825997] usb_stor_disconnect+0x57/0xc0 [usb_storage] > [ 9787.831417] usb_unbind_interface+0x6c/0x270 > [ 9787.835787] device_release_driver_internal+0x195/0x260 > [ 9787.841125] bus_remove_device+0xd4/0x120 > [ 9787.845263] device_del+0x11a/0x320 > [ 9787.848802] ? usb_remove_ep_devs+0x16/0x30 > [ 9787.853073] usb_disable_device+0x7b/0x1d0 > [ 9787.857274] usb_disconnect+0xb6/0x220 > [ 9787.861145] hub_event+0x733/0x1300 > [ 9787.864698] process_one_work+0x1a7/0x340 > [ 9787.868811] worker_thread+0x26/0x3f0 > [ 9787.872630] ? create_worker+0x190/0x190 > [ 9787.876698] kthread+0x107/0x120 > [ 9787.879994] ? kthread_create_worker_on_cpu+0x40/0x40 > [ 9787.885143] ret_from_fork+0x1f/0x30 > with f3probe obviously stuck forever. There's no extra messages on actually > physically removing the SD card or the reader. > > With SD cards and USB sticks having floppy-like reliability, I/O failures > need to be considered a normal occurence, especially with no filesystem even > mounted. In this case, the card offlines itself, but the removal doesn't > complete. A usbmon trace of the f3probe test and later events might come in handy. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
