Hi Doug, Douglas Gilbert wrote: > Stefan Richter wrote: >>> James Bottomley wrote: >>>> It's all very well to say this, but I think if you look at what udev >>>> does, you'll find that it uses scsi_id to send a VPD inquiry to the >>>> device so it can populate /dev/disk/by-id, so the point is already >>>> conceded >> >> PS: Alas we don't have a practicable way to know how many of the >> - doesn't work with Linux but works to some degree with Windows, >> - doesn't work with a 2.6 based Linux distro but did work with a >> 2.4 based distro >> kinds of devices are those with this INQUIRY bug or similar bugs. >> >> While non-udev distros slowly went out of fashion on the desktop, there >> was a certain frequency of reports of the latter kind of FireWire >> devices, but this was before I became aware of that kind of firmware >> bug, therefore I don't have any data whether it played a role for these >> cases. > > Just a small point here. To my knowledge all devices > that understand the SCSI command set will accept a > 36 byte INQUIRY (i.e. an INQUIRY with an "allocation length" > of 36). That is a practical consideration since they would > crash on Windows otherwise. > > Now scsi_id (and probably other programs of that ilk > (including some of mine)) get excited when they get a > response to a "36 byte" INQUIRY and go onto ask for > VPD page 0x80 (serial number) or page 0x83 (device id) > via an INQUIRY command with the EVPD bit set. > Now if they were clever they would make sure that > the "allocation length" of the _first_ such VPD inquiry > was 36! That way they could have a close look at the > response and if it wasn't valid for a VPD page > (e.g. requested_VPD_page_num != response[1]) then > they would leave the damn device alone **. > Oh, but of course we can do this. Actually not a bad idea. > <<< Special case: removable media >>> > Since response[1] of a standard INQUIRY has RMB (removable > medium bit) set in its top bit and the rest of the byte > reserved, 0x80 is a possibility. That could give a > false positive when the serial number VPD page is > requested. So try looking for VPD page 0x83 (with > alloc_len=36) first. > What we do is to query page 0x0 first (if no specific page has been given), and then try 0x83 or, failing that, 0x80. So we could easily modify the query to page 0x0 to get the first 36 bytes only, that should catch these type of errors. And we can check byte 4 of the response; according to SPC it should always be 0 (as page 0 always has to be implemented). Good idea. I'll do it. > > ** The logic here is that a brain dead SCSI target > interpreter doesn't look at the EVPD bit and can > only handle an "allocation length" of 36. So if > it receives an INQUIRY cdb with the EVPD bit set > it will just respond with its standard INQUIRY > response. > Yes, but that's pretty much standard anyway. So we're dealing with that already. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: 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
