On Mon, 18 Apr 2005, Sander Jansen wrote: > Ok. I finally was able to compile a kernel with debug messages on. > So here's what I'm doing. I'm plugging in the device and hotplug > automatically > detects it [see connect.log as attached] > > Then I mount it and start copying files. Which involves a lot of message > like > this: <snip> > Then after so many files processed, the cp command locks up. This is what > usb-storage says: > > usb-storage: queuecommand called > usb-storage: *** thread awakened. > usb-storage: Command WRITE_10 (10 bytes) > usb-storage: 2a 00 00 a4 d7 53 00 00 80 00 > usb-storage: Bulk Command S 0x43425355 T 0xa79 L 65536 F 0 Trg 0 LUN 0 CL 10 > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > usb-storage: Status code 0; transferred 31/31 > usb-storage: -- transfer complete > usb-storage: Bulk command transfer result=0 > usb-storage: usb_stor_bulk_transfer_sglist: xfer 65536 bytes, 10 entries > usb-storage: command_abort called > usb-storage: usb_stor_stop_transport called > usb-storage: -- cancelling sg request
Was that the end? There should be a bunch of stuff following, mostly error messages. > A couple of things I noticed: > > - I still can browse through the mounted directory. Although it lists files > which are not completely transferred (if I disconnect the device, they're not > showing up in the device itself) You're seeing data in Linux's block cache, not data from the drive. > - I cannot umount it. but when I disconnect the cable I still get these > messages: > > hub 3-0:1.0: state 5 ports 5 chg 0000 evt 0020 > ehci_hcd 0000:01:07.2: GetStatus port 5 status 001002 POWER sig=se0 CSC > hub 3-0:1.0: port 5, status 0100, change 0001, 12 Mb/s > usb 3-5: USB disconnect, address 3 > usb 3-5: usb_disable_device nuking all URBs > > - The following related processes seem to be sleeping: > > 4825 root 15 0 0 0 0 D 0.0 0.0 0:00.00 scsi_eh_1 > 4826 root 15 0 0 0 0 D 0.0 0.0 0:00.20 usb-storage > 4939 root 17 0 3540 588 500 D 0.0 0.1 0:00.00 cp This sounds like a problem with the ehci-hcd driver. The transfer was aborted but for some reason it never finished. (This doesn't answer the question of why the transfer failed in the first place. It could simply be because of marginal hardware that isn't very reliable when running at high speed.) > The full log file is somewhat large. I hope I've provided everything you > need. > Let me know If I need to turn more debugging on or not. Or send the full log > file. One more thing you could do is use Alt-SysRq-T to get a stack trace once cp has hung. The entries for usb-storage and scsi_eh_1 will be of interest. This usually works best when there aren't many other processes running at the same time, so you might want to do it in single-user mode. Also, which version of the Linux kernel are you using? Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
