Hello list, it's me again. I report a new problem with the other disk (so the previous problem is still solved, don't worry). The kernel I used is a 2.6.11-rc4-bk6 with the following patches : http://sjdcolin.free.fr/tmp/patches/
I did the tests with usb-storage debug and usb debug activated, the logs are here : http://sjdcolin.free.fr/tmp/ The test itself : a fsck.ext3 (or ext2, depends) on the partition of the offending usb2-rated disk. logs-1 : fsck.ext2 on sda1, blocks in the middle (but not always at the same place) logs-2 : fsck.ext3 on sda5, blocks also while fscking logs-3-scsi : same as logs-2, but with scsi logging fully activated (all 7), as the problem might be related to scsi logs-4-uhci : same as logs-2 and logs-1, but with uhci instead of ehci (the fsck was successful). The lists.tar.gz shows previous lsusb and lspci, it did not change much so I did not regenerate them. The problem might be only related to scsi handling of the firmware of the disk, but I prefer to post here to go the "right way", from the downhill possible causes to the uphill possible causes. I attached an excerpt of the logs where the errors first appear. After a quick googling, I had seen similar but not exactly identical error reports. What is "interesting" is that the copy of many big files from another (usb) disk did not cause any error, a huge reading neither (for a md5sum of the copied files), while a simple fsck causes problems. Maybe fsck sends particular, disk-controller related commands, making me say that the problem could be located at the scsi level. Any idea ? Regards, Samuel Colin PS : I'm not on the list, so please put me in Cc: so I can follow the discussions.
excerpt.log
Description: Binary data
