Oct 19 17:49:59 titanic kernel: SCSI error : <2 0 0 0> return code = 0x8000002Oct 18 21:24:01 titanic kernel: usb-storage: -- code: 0x70, key: 0x4, ASC: 0x4b, ASCQ: 0x0
Oct 19 17:49:59 titanic kernel: Current sdc: sense key Hardware Error
Oct 19 17:49:59 titanic kernel: Additional sense: Data phase error
Oct 19 17:49:59 titanic kernel: end_request: I/O error, dev sdc, sector 103423551
I see we're quoting CSW and sense.
I'm curious to see the CONFIG_USB_STORAGE_DEBUG dmesg quoted back from the corresponding CBW.
Oct 19 17:49:59 titanic kernel: end_request: I/O error, dev sdc, sector 103423551
Quoting the dmesg back thru the CBW will translate this English back into the plain hex of an LBA.
We could then check to see if quick experiments focused near that LBA would reproduce this trouble.
Maybe some other reader will have a good idea
I hesitate to continue my reply: I hope some other reader will have ideas we can evaluate more cheaply. All the same, ...
I think I see we've provoked these troubles only by working way way up high, like at the level of mount -r and fsck and fdisk and mkfs? Before we blame the device firmware, I'd like to see the same device complaint provoked by more determinate tools.
I'm therefore specifically curious to know the results of more determinate, though frustratingly long and slow, experiments along the lines of:
dd if=/dev/sd$v bs=512 skip=0 count=1 | hexdump -C date ; time dd if=/dev/sd$v bs=1M >/dev/null
pldd -v if=/dev/sg$n bs=512 skip=0 count=1 | hexdump -C date ; time pldd if=/dev/sg$n bs=1m skip=0 >/dev/null
Omitting the count= parameters makes the count implicitly indefinitely large, i.e., however big the disk is. I presume we're working over USB2HS, not USB1FS.
The pldd -v result should include an op x25 "READ CAPACITY" result for identifying your drive, if you're unsure of the /dev/sg$n alias for your /dev/sd$v disk.
Anyone who remembers the difference in syntax can substitute sg_dd for pldd, both ask to bypass the Linux cache via pass thru ioctl. Google reminds me, "in sg_dd, bytes per copy is bs= multiplied by bpt=". I may have slightly misquoted the dd and pldd command lines, just now I have no gcc-capable Linux and no Windows nearby to check.
3922341 lines, 290 MB decompressed):
Sounds like we already have figured out how to keep the dmesg manageably short despite reading whole disks?
Me, for this kind of work, I turn off CONFIG_USB_STORAGE_DEBUG, and then I hack back in the tracing of the information we do want, i.e., all we had before, but only for i/o that fails ... and then I lose the patch I wrote, so I can write it again later.
I can't check the drive with this special error under windows because I'm not able to mount ext3 there.
Do you have a name for the device that works for a 64-bit dd that you have for Windows?
Then we could try reading all the blocks in Windows.
I think I remember that syntax like pldd if=\\.\A: ... will work in Windows, if your disk does begin with a Microsoft-style partition table.
Harddisk-errorchecking-tools don't work with USB?
Yes the world of storage divides into ATA and SCSI, yes tools for the one often don't work for the other, but sometimes the tools do work, e.g., pldd speaks thru the SCSI to ATA translator in Windows, e.g., dd speaks to thru translators to SCSI and thru translators to ATA drives in Linux and Mac OS X.
I suppose the device in question is a USB/ATA bridge plus an ATA HDD? That means we're reverse engineering a proprietary SCSI to ATA translator.
I notice the tradition of saying "data phase error" to mean ASC x4B dates back as far as the SCSI 2 s2-r10l.pdf text. That phrase occurs once, without further definition, and searching for the less specific phrase "phase error" also finds no definition. But I think I remember in those days the only protocol was the classic SCSI now named SPI, and a "data phase error" meant that the host or the device was signaling it wanted to clock data at a time when the other was not cooperating.
Pat LaVarre http://linux-pel.blog-city.com/
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
