On Sun, 2 Sep 2012, Matthew Hall wrote: > > > What about a quirk which gets the blocksize from the smaller commands and > > > combines with the device size from the larger command? > > > > It's not quite that simple. The trace showed that two different > > commands gave the right block size, and we don't know which one Windows > > believed. I suppose we could figure out the answer to that. > > > > It might work. But the only justification would be "That's the way > > Windows does it"... which might not be strong enough. Especially since > > different versions of Windows might do it in different ways. One thing I failed to mention before... The READ FORMAT CAPACITIES and READ CAPACITY(10) results in Alon's usbmon trace had an incorrect device size along with a correct block size. The responses to these commands contain the size as a number of blocks, limited to a 32-bit value. Thus they cannot handle more then about 4 billion blocks. If the block size is 512 bytes then 4 billion blocks is only 2 TB. But with a 4096-byte block size, the limit is 16 TB and so the size could have easily fit. Nevertheless, the responses sent by the JMicron had the size fields set to all ones. > How about a dummy read which only can work when you've discovered the size > correctly? You noticed one failed right that occurred due to the mismatch in > the block size. At some point it stops being worthwhile to try supporting devices which are simply too buggy. The devices sold by JMicron passed my personal threshold some years ago. 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
