From: Douglas G. <dgi...@in...> - 2009-01-08 21:07:33
|
Alfred Ganz wrote: > Christian, Doug, > > This is really for Doug, but I have trouble sending to him because > of a spam avoidance problem. > > Doug wrote: > > Doug: Looks like the same issue you reported recently for a WD drive > > with SAT support. > > Which USB enclosure? > > The USB enclosure that I reported the problem recently with > is a 250GB WD "My Passport" which a SCSI INQUIRY reports > as "WD 2500BEV External". > > The unit reports compliance with SPC-2: > # sg_inq /dev/sg2 > standard INQUIRY: > PQual=0 Device_type=0 RMB=0 version=0x04 [SPC-2] > ..... > > which makes this patch pending for lk 2.6.29: > http://marc.info/?l=linux-usb&m=123135651222832&w=2 > > inoperative. > I am not sure this is the case, a careful review of the patch seems to > indicate that the patch also addresses the SPC-2 case, but in a more > convoluted way. Note that the very first sat,12 or sat,16 command will > also set the US_FL_SANE_SENSE flag, as will the first sense response > of type 70h - 73h. Agreed, this is an ugly solution to this mess, and > the very first smartctl -H command may still fail, but subsequent ones > should then succeeed. Interesting, I didn't look past the failed "SPC-2" guard. However my observation is that the claimed compliance field in a SCSI response is not something to be taken seriously when ATA, and especially USB, are involved. In the case of my "WD Passport" external disk what it returns beyond by byte 57 in its SCSI INQUIRY response violates SCSI-2, SPC, SPC-2, SPC-3 and SPC-4. It has a model information beyond byte 57 ... wrong ... it should have version descriptors in SPC-2. So much for claiming SPC-2 compliance! The "WD Passport" obviously supports the SAT ATA pass-through commands but does not format its INQUIRY "T10 Vendor Identification" field according to the SAT (or draft SAT-2) standard. It should contain "ATA " but has "WD ". Red card! This means we need to supply a '-d sat' argument to override the SMT assumption that it has a "real" SCSI disk. Now if it had implemented version descriptors properly (discussed in previous paragraph) then we might see a compliance claim for SAT and then we could (but don't) assume a SCSI OS interface to SAT. So I have reason not to trust the external disk (actually the USB to ATA chip) and the Linux USB mass storage driver. Do I need to find out which one is the source of my particular problem? Life is too short to list all the ways that these devices break SCSI standards. My goal is not to count the violations but make things work in smartmontools. The Rob Elliott T10 proposal (url in previous post) should indicate that the 18 byte sense buffer truncation is not a smartmontools/Linux only problem. That said when I place the same "My Passport" external disk on XP SP3 and make allowance for the fact that SAT will not be automatically recognised, for example: $ smartctl.exe -a -d sat PD1 then it works. So there is a need for '-T permissive' option in linux (SMT 5.38, lk 2.6.27) but not in Windows XP SP3. My Windows 2000 laptop has died but I'm pretty sure that I have noted 18 byte sense buffer truncation there. Just another point in passing: Western Digital (WD) haven't made true SCSI (SPI, SAS, FC) disks in a long time (over 10 years). So since "WD " is a registered T10 vendor identification, then as soon as a disk responds to a SCSI INQUIRY with that, we might safely assume that the SAT interface is in play. If it is not (e.g. if WD started producing SAS disks) then we would find that out after the first SCSI ATA PASS-THROUGH command failed with "illegal request; invalid command operation code". Doug Gilbert P.S. Alfred Ganz has problems reading my attachments and I can't even send emails to him: "Diagnostic-Code: smtp; 550 5.7.1 <alf...@ag...>... Sender address verification failed" |