On Fri, 13 Jan 2012, Ondrej Zary wrote: > On Thursday 12 January 2012, Tomasz Chmielewski wrote: > > On 01/12/2012 09:31 PM, Alan Stern wrote: > > > Judging by the log, the reader isn't able to handle such a large card. > > > It reported a total capacity of 0xffba7800 sectors, about 2 TB as shown > > > in the dmesg log. The correct value should have been somewhere around > > > 0x03b9aca0. Then when the computer took the reader at its word and > > > asked for the contents of sector 0xffba7780, the reader flipped out, > > > requiring a reset. Things went downhill from there. > > > > There are more devices with this problem, judging by Ondrej's email. > > > > Shouldn't we then fall back to an alternative way of accessing the > > device? I.e. do what the alternative OS does? Maybe we should... but you're asking the wrong people. That's a matter for the block layer and hotplug people; as far as USB is concerned your reader works perfectly. > In my case, Windows did not do anything. The device had the same (wrong) size > as in Linux. But something in Linux (don't know if in the kernel or in > unserspace) attempted to read something from the end of device - and that > broke it. That "something" is udev. One of its library programs (perhaps /lib/udev/ata_id -- there used to be a similar program for hal called blk_id) looks through newly-attached block devices, searching for things like partition labels, LVM partitions, and so on. Since some schemes involving storing this information near the end of the device, ata_id has to try reading the last few sectors. Either of you could try temporarily renaming ata_id so that udev can't find it, and see if that makes any difference. > > This is what it seems to do, judging by the times after which the device > > is ready to use / is able to show the content (in the alternative OS). > > The times before the content is shown in the alternative OS is as below: > > > > - 4 secs - when using the laptop built-in card reader and a 32 GB SDHC > > card, - 18 secs - when using this USB card reader and a 32 GB SDHC card, - > > 3 secs - when using this USB card reader and a 2 GB card. > > > > 18 secs - this seems to suggest that the OS is spending extra time and > > uses workarounds to access the device which doesn't work as a spec says. I don't know about that. However, Windows doesn't do the sort of probing that ata_id does. > > > With the 2-GB card, the reported capacity was 0x003cc000, which is > > > about right as shown in the dmesg log. > > > > > > Unfortunately there is no way to override a device capacity. It > > > doesn't look like you'll be able to use this reader with that card. > > > > Great. The situation is likely worse than you think. Let's suppose that when ata_id is out of the way, you're able to use the reader to access the card. There's a very high probability that the reader still won't be able to handle it properly. For example, if you were to store 16 GB worth of files on the card (using a different reader, say) and then read them back using this reader, you probably will end up reading incorrect data. One other thing -- I wouldn't bother to use this reader for anything even as small as 2 GB. Since it runs only at full speed, not high speed, you'd be lucky to get a throughput of 800 KB/s out of it. At that rate, reading 16 GB would require close to 6 hours. > > > By the way, what happens if you try to repartition the 32-GB card using > > > this reader under a different OS? > > > > I'm not able to repartition it under Windows, in the USB card reader, > > and in the built-in card reader. Why not? Doesn't that prove there's something else wrong, somewhere? > > I've repartitioned under Linux (laptop with a built-in SD/HC card reader). > > With one, 2 GB partition, it still resets / doesn't work. Same with no > > partitions at all. That's because ata_id always tries to read the sectors near the end of the card, regardless of the partitioning. 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
