Douglas Gilbert wrote: > Albert Lee wrote: > >>Alan Cox wrote: >> >>>>We have two possible solutions here: >>>>a. Patch Ubuntu, such that the incorrect INQUIRY is fixed. >>>>b. Patch kernel, such that the AOpen drives are blacklisted. >>>> Each INQUIRY is inspected for the blacklisted drives. >>>> If the INQUIRY looks wrong, the INQUIRY is rejected. >>>> >>>>I guess a. is the preferred solution... >>> >>>We have two problems here >>> >>>#1 Ubuntu got the inquiry command wrong >>> >>>#2 Until now we considered "INQUIRY" a safe command for SG_IO passthrough. >>> >>>We can't really take INQUIRY out of SG_IO so do we decide its the >>>hardware vendors problem or do something cleverer in the filters ? > > > Albert, > "Definitions: > .... > Reserved: A keyword referring to bits, bytes, words, fields > and code values set aside for future standardization. A > reserved bit, byte, word or field shall be set to zero, or > in accordance with a future version to this standard. > Recipients are not required to check reserved bit, bytes, > words or fields for zero values. ..." [SPC-4 rev 9] > > I haven't seen anywhere that says that a recipient may > crash and burn if it receives a non zero value in > a reserved field. > Thanks for the advice (also Sergei and Alan's). Yurema did more test on the Aopen 56X/AKH and it seems has trouble with other commands, too. (It also chokes on GET_CONFIGURATION, etc. during request sense.) Agreed it's the drive/firmware problem, not the reserved EVPD bit nor Ubuntu/hald/scsi_id's fault. Maybe the best fix is firmware update. I will ask AOpen about any firmware update available for it. > That suggests to me that the ATAPI drive (TORiSAN) should > be black listed. It's the AOpen 56X/AKH drive that chokes on INQUIRY with EVPD=1. The TORiSAN drive has another ATAPI DMA problem and max_sector limitation. Sorry for the mix-up. > > >>Maybe the SG_IO author has better idea (ccing Doug)? > > > Filtering is madness. We can have: > - ATA commands passing through SCSI commands > - encapsulated SCSI commands (security freaks) > - and of course vendor specific commands > > to name a few. > > Setting the EVPD bit is to fetch VPD pages (and the > failure shown in this thread is an attempt to fetch > a list of supported VPD pages). The device identification > VPD page (0x83) is very important in FCP, SAS, SAT. > ATA8-ACS allocates 8 bytes in its IDENTIFY DEVICE response > for a wwn. Not sure if any wwn has been proposed for ATAPI > devices. > > >>BTW, in addition to the AOpen "INQUIRY with EVPD" problem, we have >>another imperfect ATAPI drive (TORiSAN) that freezes when "READ >= 128KB". >>(http://bugzilla.kernel.org/show_bug.cgi?id=6710) >> >>We can limit "dev->max_sectors" to workaround the TORiSAN problem. >>But I don't know whether "dev->max_sectors" also works for SG_IO? >>If no, some user space application, unaware of the problem, >>might send a "correct" READ that locks the drive completely. > > > Currently only SCSI subsystem LLDs set max_sectors > (although libata might). Can it be set via sysfs? > Recent versions of the sg driver honour max_sectors > and the block layer SG_IO ioctl implementation always > has. It's good to know that the sg driver honors max_sectors. So, my previous concern about user space app might send commands with invalid max_sect that kills the TORiSAN drive is solved. :) > > SCSI direct access devices (i.e. SCSI disks) have a VPD > page that supplies block limit (and optimal) values > for data transfers. Linux doesn't currently ask that > particular question. Of course the standard that defines > block limits also defines an error response if it is > exceeded. > Thanks, Albert - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
