I'm not on this list but I thought someone here might be interested. (please cc me if you respond) I was tracking down a problem where some USB flash disks could not be used with a 2.4.21 kernel. Apparently lots of "READ CAPACITY failed" messages are generated. It turns out the problem was caused by USB flash disks which have no partition table. The have a valid FAT-16 file system starting at block zero (0). If the disk is inserted and the "partition 1" block device (/dev/discs/disc0/part1) is read, the disk will 'hang' after a read and not respond. Subsequent accesses get "READ CAPACITY failed" messages and the disk will get into a state where TEST_UNIT_READY will always return "not ready". I think I have a trace where I can dig out the actual SCSI read command and see what block number it's asking form. I suspect it's some gigantic number. I'm guessing the invalid parition map caused the scsi code to ask the disk to read off into space and the disk went south. (technical description :-) Note that if the 'raw' partition (/dev/discs/disc0/disc) is used, all is well. I realize it's hard/impossible to validate the partition map. In this case it has the correct '55 aa' signature. But none of the partition 'types' are valid and most are zero. I'm a little suprised that reading from */part1 worked at all, but perhaps it just the perils of using an ms-dos parition map... I'm also suprised a bad partition map could generate a read which would 'crash' the disk, so to speak. I may dig into it a little further. I believe the traces I have showed the original READ CAPACITY worked, so the scsi code should know how big the drive actually is. -brad - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
