Re: [usb-storage] Problems with USB MMC/SD card reader

[Pat LaVarre]

> Feb 23 08:44:16 kepler kernel: SCSI device sdb: 1988608 512-byte  
hdwr sectors (1018 MB)
> ...
> Feb 23 08:44:16 kepler kernel: SCSI device sdb: 1988608 512-byte  
hdwr sectors (1018 MB)

Is stuttering the log of max Lba normal?  I think I remember yes?

> but immediately after that the logs get flooded by error messages:
> ...
> Feb 23 08:44:18 kepler kernel: sdb: Current: sense key=0x3
> Feb 23 08:44:18 kepler kernel:     ASC=0x11 ASCQ=0x0
> Feb 23 08:44:18 kepler kernel: Info fld=0x1e51f9
> Feb 23 08:44:18 kepler kernel: end_request: I/O error, dev sdb,  
sector 1987065
> Feb 23 08:44:18 kepler kernel: Buffer I/O error on device sdb1,  
logical block 248352
> and so on until I disconnect the device.

Ick.

x 3 11 = SK ASC from a Scsi device is a claim that Ecc is saying one  
or more bits of the data read are wrong, as if your flash media were  
wearing out.  Here above we were told max Lba = 1988608 - 1 =  x1E57FF.

"Info fld" is probably kmesg-ese meaning sense bytes 3:4:5:6 echoed  
when byte 0 mask x80 set, i.e., the Lba in error.  In this snippet of  
log we have:

x 3 11 00 1E51F9
x 3 11 00 1E51F9
x 3 11 00 1E5271
x 3 11 00 1E5271
x 3 11 00 1E5271

This isn't a consistently repeated log - our host & device together  
haven't livelocked in one spot - instead they have reported the first  
two of a burst of two or more errors that are being tried 2 or 3 or N  
times.

> ... works perfecly on the same machine in Windows XP ...

Might Linux differ from Windows by failing early by design if the  
last blocks are unreliable?

I see we have reason to believe Windows can read data from this card  
thru this reader without error.  Do we also have reason to believe  
Windows can read all blocks correctly without error?

Have we looked at the event log in Windows?  I mean the one near the  
Disk Manager and Device Manager, that divides into App, Security, and  
System.  x 3 11 complaints from the device often show up there.  To  
see recent events, you can sort by timestamp or clear before  
experimenting.

If I were you, I'd next try plugging in without automount and then a  
dd, both in Linux and in the Windows patched to include dd, to see if  
those dd agree that all the bits read without error.

I'd expect dd reports failed reads in both Linux and Windows, until I  
had reason to think otherwise, like an evil root cause for the  
stuttered log of max Lba.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/