From: Alfred G. <alf...@ag...> - 2009-01-07 02:42:04
|
Christian, Here is some more on this: Recent releases of hdparm have SAT support, therefore the following command should work if the USB bridge supports SAT: $ hdparm -S 180 /dev/sdb I have communicated with the maintainer of hdparm, and he not only confirmed that the current hdparm doesn't support 12 byte SATA Pass Through, but he provided me with a developing version of hdparm that supports the 12 byte SATA Pass Through. Using this form of hdparm I was able to set the standby timer delay value for the disk, exactly as you suggested, and set SCT=0 for the SCSI interface of the USB-bridge, and I can now run my long selftest without spindown until the test is completed. So I will now add an occasional long test to the smartd.conf file. BTW, these changes have had an additional pleasant side-effect. With the standby state maintained by the SCSI interface of the USB-bridge, I had to do some trickery to wake up the disk, because some driver could not cope with what happened with the command that woke up the disk. With the SCSI interface now always ready, everybody seems to be able to cope with what happens upon wakeup. Thanks again for your help! AG -- ---------------------------------------------------------------------- Alfred Ganz alfred-ganz:at:agci.com AG Consulting, Inc. (203) 624-9667 440 Prospect Street # 11 New Haven, CT 06511 ---------------------------------------------------------------------- |
From: Bruce A. <ba...@gr...> - 2009-01-07 12:59:09
|
Hi Alfred, I'm glad this worked out. Did you get a developers version of hdparm from Mark Lord? If so, we should push him to release this sooner rather than later. Cheers, Bruce On Tue, 6 Jan 2009, Alfred Ganz wrote: > Christian, > > Here is some more on this: > Recent releases of hdparm have SAT support, therefore the following > command should work if the USB bridge supports SAT: > $ hdparm -S 180 /dev/sdb > I have communicated with the maintainer of hdparm, and he not only > confirmed that the current hdparm doesn't support 12 byte SATA Pass > Through, but he provided me with a developing version of hdparm that > supports the 12 byte SATA Pass Through. > > Using this form of hdparm I was able to set the standby timer delay > value for the disk, exactly as you suggested, and set SCT=0 for the > SCSI interface of the USB-bridge, and I can now run my long selftest > without spindown until the test is completed. So I will now add an > occasional long test to the smartd.conf file. > > BTW, these changes have had an additional pleasant side-effect. With > the standby state maintained by the SCSI interface of the USB-bridge, > I had to do some trickery to wake up the disk, because some driver > could not cope with what happened with the command that woke up the > disk. With the SCSI interface now always ready, everybody seems to > be able to cope with what happens upon wakeup. > > Thanks again for your help! AG > > |
From: Christian F. <Chr...@t-...> - 2009-01-07 17:26:51
|
Hi Alfred, Hi Bruce, Bruce Allen wrote: > Hi Alfred, > > I'm glad this worked out. Did you get a developers version of hdparm from > Mark Lord? If so, we should push him to release this sooner rather than > later. > > I agree :-) Alfred: According to you first mail, the USB drive is some Maxtor Onetouch model. Which one? The SAT layer in the firmware of some new USB bridges is apparently a hidden feature. I did'nt find any USB enclosure which lists SAT in its specs. It probably makes sense to collect a list of such devices for smartmontools homepage. >> Thanks again for your help! AG >> >> You're welcome. Thanks for your detailed feedback. I'm glad when something which should work in theory actually works in practice :-) Cheers, Christian |
From: Alfred G. <alf...@ag...> - 2009-01-07 18:09:02
|
Christian, Bruce, Date: Wed, 07 Jan 2009 18:26:11 +0100 From: Christian Franke <Chr...@t-...> To: Bruce Allen <ba...@gr...>, Alfred Ganz <alf...@ag...> CC: sma...@li... Subject: Re: [smartmontools-support] Yet more on Re: long tests in standby mode Bruce Allen wrote: >Hi Alfred, > >I'm glad this worked out. Did you get a developers version of hdparm from >Mark Lord? If so, we should push him to release this sooner rather than >later. I agree :-) Mark tells me that he plans for a new release soon, but things are not fully ready yet. BTW, the latest released version does work for sat,16. Alfred: According to you first mail, the USB drive is some Maxtor Onetouch model. Which one? It is a Maxtor 250GB USB device. Here is some stuff about it, let me know if this is what you are looking for, or if you need something else. The box says: Maxtor OneTouch4 250 GB PN:9NT2A2-500 Here is what lsusb -v says: Bus 001 Device 004: ID 0d49:7310 Maxtor Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0d49 Maxtor idProduct 0x7310 bcdDevice 1.25 iManufacturer 1 Maxtor iProduct 2 OneTouch iSerial 3 2HA1W2YW bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Here is what the new hdparm says (as you can see, not installed yet!): # ./hdparm -I /dev/sdb /dev/sdb: ATA device, with non-removable media Model Number: ST3250410AS Serial Number: 6RY3WRG6 Firmware Revision: 3.AAC Standards: Supported: 7 6 5 4 Likely used: 7 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 488397168 device size with M = 1024*1024: 238475 MBytes device size with M = 1000*1000: 250059 MBytes (250 GB) cache/buffer size = 16384 KBytes Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = ? Recommended acoustic management value: 208, current value: 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * DOWNLOAD_MICROCODE SET_MAX security extension * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test * General Purpose Logging feature set Write-Read-Verify feature set * WRITE_UNCORRECTABLE_EXT command * {READ,WRITE}_DMA_EXT_GPL commands * Segmented DOWNLOAD_MICROCODE * SATA-I signaling speed (1.5Gb/s) * Native Command Queueing (NCQ) * Phy event counters Device-initiated interface power management Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count not supported: enhanced erase Checksum: correct Here is what smartctl says: # smartctl -a -d sat,12 -T permissive /dev/sdb smartctl version 5.38 [i686-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3250410AS Serial Number: 6RY3WRG6 Firmware Version: 3.AAC User Capacity: 250,059,350,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Wed Jan 7 12:32:55 2009 EST SMART support is: Available - device has SMART capability. SMART support is: Enabled Note that the SCSI over USB processing requires a relatively new patch for the usb-storage module to properly handle a sense response (which is longer than 18 bytes, if I remember correctly). The only thing that I found to be affected is the "SMART Status command", which fails. Sorry, this got longer than I wanted. Hope this helps, AG -- ---------------------------------------------------------------------- Alfred Ganz alfred-ganz:at:agci.com AG Consulting, Inc. (203) 624-9667 440 Prospect Street # 11 New Haven, CT 06511 ---------------------------------------------------------------------- |
From: Christian F. <Chr...@t-...> - 2009-01-07 20:11:17
|
Alfred Ganz wrote: > ... > The box says: > Maxtor > OneTouch4 250 GB > PN:9NT2A2-500 > Here is what lsusb -v says: > Bus 001 Device 004: ID 0d49:7310 Maxtor > Device Descriptor: > ... > idVendor 0x0d49 Maxtor > idProduct 0x7310 > bcdDevice 1.25 > iManufacturer 1 Maxtor > iProduct 2 OneTouch > Thanks for the info. > ... > Note that the SCSI over USB processing requires a relatively new patch > for the usb-storage module to properly handle a sense response (which > is longer than 18 bytes, if I remember correctly). The only thing that > I found to be affected is the "SMART Status command", which fails. > > Doug: Looks like the same issue you reported recently for a WD drive with SAT support. Which USB enclosure? Cheers, Christian |
From: Alfred G. <alf...@ag...> - 2009-01-07 21:16:32
|
Christian, Date: Wed, 07 Jan 2009 21:10:48 +0100 From: Christian Franke <Chr...@t-...> Subject: Re: [smartmontools-support] Yet more on Re: long tests in standby mode >... >Note that the SCSI over USB processing requires a relatively new patch >for the usb-storage module to properly handle a sense response (which >is longer than 18 bytes, if I remember correctly). The only thing that >I found to be affected is the "SMART Status command", which fails. > > Doug: Looks like the same issue you reported recently for a WD drive with SAT support. Which USB enclosure? I had e-mail exchanges about my problem with Doug around the beginning of last August. I know he is aware of the usb-storage patch, there were some lengthy discussions as to where and how the problem ought to be fixed at that time. BTW, I installed and tested a version of said patch in an earlier kernel, and it solved the problem. However, I currently am running without such a patch, and except for the failure of the "SMART Status command" proper, I have seen no problems. AG -- ---------------------------------------------------------------------- Alfred Ganz alfred-ganz:at:agci.com AG Consulting, Inc. (203) 624-9667 440 Prospect Street # 11 New Haven, CT 06511 ---------------------------------------------------------------------- |
From: Douglas G. <dgi...@in...> - 2009-01-07 23:44:24
Attachments:
sat_usb_trunc_dpg1.diff
|
Christian Franke wrote: > Alfred Ganz wrote: >> ... >> The box says: >> Maxtor >> OneTouch4 250 GB >> PN:9NT2A2-500 >> Here is what lsusb -v says: >> Bus 001 Device 004: ID 0d49:7310 Maxtor Device Descriptor: >> ... >> idVendor 0x0d49 Maxtor >> idProduct 0x7310 bcdDevice 1.25 >> iManufacturer 1 Maxtor iProduct 2 >> OneTouch > > Thanks for the info. > > >> ... >> Note that the SCSI over USB processing requires a relatively new patch >> for the usb-storage module to properly handle a sense response (which >> is longer than 18 bytes, if I remember correctly). The only thing that >> I found to be affected is the "SMART Status command", which fails. >> >> > > 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 think that we should accept the first (lower) byte of 0x4f for success (or 0xf4 for failure) since it is placed below the 18 byte SCSI-2 sense buffer length limit in a SAT ATA Return descriptor. Silently ignore in incorrect upper byte (0xc2 for success or 0x2c for failure) unless '-r ioctl[,<n>]' is given, in which case smartmontools can explain its assumption/compromise. A patch is attached for consideration. Doug Gilbert |
From: Dan L. <da...@ob...> - 2009-01-08 10:21:45
|
Douglas Gilbert napsal/wrote, On 01/08/09 00:44: > The unit reports compliance with SPC-2: > # sg_inq /dev/sg2 > standard INQUIRY: > PQual=0 Device_type=0 RMB=0 version=0x04 [SPC-2] > I think that we should accept the first (lower) byte > of 0x4f for success (or 0xf4 for failure) since it > is placed below the 18 byte SCSI-2 sense buffer length > limit in a SAT ATA Return descriptor. Silently ignore > in incorrect upper byte (0xc2 for success or 0x2c for > failure) unless '-r ioctl[,<n>]' is given, in which case > smartmontools can explain its assumption/compromise. It sounds as dirty dark hack for me. This is the bug in disk driver, so it shall be patched here, at the first. At the second, it's a OS driver bug. Even you will patch the OS bug in application, your patch shall be in effect only on buggy version of OS. There may other OS with it's own bugs that may be masked by this patch even the such bug will not be caused by broken system driver. Not speaking about disk's firmware bugs. So it shall be part of a "ifdef" clearly marking such code as Linux's dirty hack compiled on affected Linux OS only. Dan |
From: Douglas G. <dgi...@in...> - 2009-01-08 17:00:47
|
Dan Lukes wrote: > Douglas Gilbert napsal/wrote, On 01/08/09 00:44: >> The unit reports compliance with SPC-2: >> # sg_inq /dev/sg2 >> standard INQUIRY: >> PQual=0 Device_type=0 RMB=0 version=0x04 [SPC-2] > >> I think that we should accept the first (lower) byte >> of 0x4f for success (or 0xf4 for failure) since it >> is placed below the 18 byte SCSI-2 sense buffer length >> limit in a SAT ATA Return descriptor. Silently ignore >> in incorrect upper byte (0xc2 for success or 0x2c for >> failure) unless '-r ioctl[,<n>]' is given, in which case >> smartmontools can explain its assumption/compromise. > > It sounds as dirty dark hack for me. This is the bug in disk driver, so > it shall be patched here, at the first. > > At the second, it's a OS driver bug. Even you will patch the OS bug in > application, your patch shall be in effect only on buggy version of OS. > > There may other OS with it's own bugs that may be masked by this patch > even the such bug will not be caused by broken system driver. Not > speaking about disk's firmware bugs. > > So it shall be part of a "ifdef" clearly marking such code as Linux's > dirty hack compiled on affected Linux OS only. Dan, I would be very surprised if Linux is the only OS impacted by this problem. Most SCSI software (and firmware) assumed that a SCSI sense buffer was 18 bytes long. This was the case up until SPC-3 was ratified in 2005. In this case we have ATA commands being tunnelled inside SCSI commands across a USB (mass storage) transport. The current USB transport is such a bunch of crap that they are going to throw it out and start again (see UAS at t10.org). The SMART RETURN STATUS is the only ATA command that I'm aware of that smartmontools needs to read the registers _after_ the command is finished. That truncation of the sense buffer to 18 bytes could occur in: - the USB to ATA bridge inside the external device - in the case of SAS, inside the low level driver (e.g. with LSI HBAs: mptsas) - in this case: inside the USB subsystem and specifically its mass storage class handler ** - in the application layer software (e.g. smartmontools) ** As I tried to point out in my last post, the "fix" going into the linux kernel 2.6.29 will not fix my case because the WD "My Passport" says it complies with SPC-2. The guard in the "fix" wants compliance more recent than SPC-2. There is no requirement in SCSI standards that I have read that says you can't claim a lower level of compliance then you actually implement (i.e. implement SPC-4 + SAT-2 and claim SPC-2 compliance). Legally that is ok! USB mass storage in based on SCSI-2 (circa 1991) with 18 byte sense buffers. So until UAS becomes a standard then I see no pressure for USB to ATA bridge chip makers to increase the sense buffer size. This is becoming a serious problem and not just for smartmontools. No need to believe me, read from an expert: http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-344r0.pdf ... and I don't think those guys worry too much about Linux ... BTW that proposal was voted down! So please forget your "#ifdef" idea. Doug Gilbert |
From: Dan L. <da...@ob...> - 2009-01-08 19:31:52
|
Douglas Gilbert napsal/wrote, On 01/08/09 18:00: >>> I think that we should accept the first (lower) byte >>> of 0x4f for success (or 0xf4 for failure) since it >>> is placed below the 18 byte SCSI-2 sense buffer length >>> limit in a SAT ATA Return descriptor. Silently ignore >>> in incorrect upper byte (0xc2 for success or 0x2c for >>> failure) unless '-r ioctl[,<n>]' is given, in which case >>> smartmontools can explain its assumption/compromise. > That truncation of the sense buffer to > 18 bytes could occur in: > - the USB to ATA bridge inside the external device > - in the case of SAS, inside the low level driver > (e.g. with LSI HBAs: mptsas) > - in this case: inside the USB subsystem and specifically > its mass storage class handler ** > - in the application layer software (e.g. smartmontools) May be, all USB<->ATA bridges are broken. May be, all low level drivers on all operating systems are broken the same way. May be, all OSs have broken mass storage class handler. I'm not expert, so I can't speak about it for sure. It's all possible. But it seems to me your patch doesn't correct response truncated by broken hardware bridge or device driver - it seems to me it "correct" any response that one byte has known value but other has unknown value. It may be caused not only by USB/SAT truncation. We shall not thing we have response with known meaning in those "other" cases. Please don't misunderstand me - I have nothing against Linux nor your patch. My English is far from perfect, so it's easy to say something bad unintentionally. What I'm trying to tell - don't correct unless you are sure it's broken the way you know (e.g. don't correct truncated response unless you know it is truncated response). Or I miss something in your patch ? Dan |
From: Christian F. <Chr...@t-...> - 2009-01-08 20:26:44
|
Dan Lukes wrote: > Douglas Gilbert napsal/wrote, On 01/08/09 18:00: >>>> I think that we should accept the first (lower) byte >>>> of 0x4f for success (or 0xf4 for failure) since it >>>> is placed below the 18 byte SCSI-2 sense buffer length >>>> limit in a SAT ATA Return descriptor. Silently ignore >>>> in incorrect upper byte (0xc2 for success or 0x2c for >>>> failure) unless '-r ioctl[,<n>]' is given, in which case >>>> smartmontools can explain its assumption/compromise. > >> That truncation of the sense buffer to >> 18 bytes could occur in: >> - the USB to ATA bridge inside the external device > >> - in the case of SAS, inside the low level driver >> (e.g. with LSI HBAs: mptsas) > >> - in this case: inside the USB subsystem and specifically >> its mass storage class handler ** > >> - in the application layer software (e.g. smartmontools) > > May be, all USB<->ATA bridges are broken. May be, all low level > drivers on all operating systems are broken the same way. May be, all > OSs have broken mass storage class handler. > > I'm not expert, so I can't speak about it for sure. It's all possible. > > But it seems to me your patch doesn't correct response truncated by > broken hardware bridge or device driver - it seems to me it "correct" > any response that one byte has known value but other has unknown > value. It may be caused not only by USB/SAT truncation. We shall not > thing we have response with known meaning in those "other" cases. > This would be true if SMART STATUS command would be allowed to return arbitrary values which is not the case. SMART STATUS simply returns a boolean value encoded in an 'interesting' way: 0x2cf4 => false, 0xc24f => true. Other values are not allowed. It is IMO safe to tolerate the typical truncation in the ATA->USB->OS->Application path and interpret the values as: 0x??f4 => false, 0x??4f => true. Cheers, Christian |
From: Dan L. <da...@ob...> - 2009-01-08 21:03:55
|
Christian Franke napsal/wrote, On 01/08/09 21:26: > It is IMO safe to tolerate the typical truncation in the > ATA->USB->OS->Application path and interpret the values as: > 0x??f4 => false, 0x??4f => true. With no doubt if the response arrived through USB<->ATA bridge. But shall we "correct" the response that come directly from plain ATA or SCSI disk with no intervening SAT/USB component ? Shall we correct if response come from and RAID with pass-through functionality ? With no USB<->ATA bridge anywhere in the path ? That's I'm asking for ... The patch will not "correct" bridge-truncated responses only. It will create "correct" responses from "we don't know how it mean" response despite the reason of unexpected byte combination. It may hide the disk firmware bugs, the driver code bugs, the smartmon application bugs in the cases where unexpected values can not caused by USB bridge, because there is no such bridge in the path. I'm asking if we understand such consequence - and - if we can't correct the bridge-truncated responses only. Yes, I know the current code doesn't carry the information about "response source" so the "safe" patch will be more complicated than hack in question. Of course, we can accept the side-effect risk and apply the hack as is. I'm asking only. Dan |
From: Bruce A. <ba...@gr...> - 2009-01-08 09:44:52
|
Hi Doug, > I think that we should accept the first (lower) byte of 0x4f for success > (or 0xf4 for failure) since it is placed below the 18 byte SCSI-2 sense > buffer length limit in a SAT ATA Return descriptor. Silently ignore in > incorrect upper byte (0xc2 for success or 0x2c for failure) unless '-r > ioctl[,<n>]' is given, in which case smartmontools can explain its > assumption/compromise. > > A patch is attached for consideration. I have not checked the patch in detail, but I think the basic idea is fine: check the part of the response which survives the overly-short buffer limit, with a diagnostic warning if the remaining part of the response is missing. Cheers, Bruce |
From: Christian F. <Chr...@t-...> - 2009-01-08 10:48:22
|
Bruce Allen wrote: > Hi Doug, > > > I think that we should accept the first (lower) byte of 0x4f for > > success (or 0xf4 for failure) since it is placed below the 18 byte > > SCSI-2 sense buffer length limit in a SAT ATA Return descriptor. > > Silently ignore in incorrect upper byte (0xc2 for success or 0x2c > > for failure) unless '-r ioctl[,<n>]' is given, in which case > > smartmontools can explain its assumption/compromise. > > > > A patch is attached for consideration. > > Doug: Patch looks good, please apply. > > I have not checked the patch in detail, but I think the basic idea is > fine: check the part of the response which survives the overly-short > buffer limit, with a diagnostic warning if the remaining part of the > response is missing. > Agree. It would also be easy to add a more strict check of the actual sense length. This can be done with the hidden flag ata_register.is_set() which is implicitly set by assignment: - Assign lba_high and other output registers only if value is known: bool sat_device::ata_pass_through(...) { ... int ard_len = 'actual length of ardp[]'; ... // Set output registers ata_out_regs & lo = out.out_regs; ... if (ard_len > 11) lo.lba_high = ardp[11]; ... } - Accept the partial result only if lba_high is actually unknown: int smartcommandhandler(...) { ... else if (out.out_regs.lba_mid == SMART_CYL_LOW && !out.out_regs.lba_high.is_set() ) // Truncated GOOD SMART STATUS ... else if (out.out_regs.lba_mid == SRET_STATUS_MID_EXCEEDED && !out.out_regs.lba_high.is_set() ) // Truncated BAD SMART STATUS ... } Cheers, Christian |
From: Bruce A. <ba...@gr...> - 2009-01-08 11:26:06
|
Hi Dan, I might be confused about this, but I thought that this was a bug in the USB <-> SATA interface chip firmware. If so, then our only alternatives are (a) a workaround such as what Doug/Christian have proposed or (b) to say that we don't support buggy hardware. In such cases, I am in favor of (a), particularly if the relevant code sections are fairly isolated and can be stripped out in a few years when the buggy hardware is obsolete and gone. Am I wrong about this? Is it actually a Linux kernel bug that we are working around? Cheers, Bruce On Thu, 8 Jan 2009, Dan Lukes wrote: > Douglas Gilbert napsal/wrote, On 01/08/09 00:44: >> The unit reports compliance with SPC-2: >> # sg_inq /dev/sg2 >> standard INQUIRY: >> PQual=0 Device_type=0 RMB=0 version=0x04 [SPC-2] > >> I think that we should accept the first (lower) byte >> of 0x4f for success (or 0xf4 for failure) since it >> is placed below the 18 byte SCSI-2 sense buffer length >> limit in a SAT ATA Return descriptor. Silently ignore >> in incorrect upper byte (0xc2 for success or 0x2c for >> failure) unless '-r ioctl[,<n>]' is given, in which case >> smartmontools can explain its assumption/compromise. > > It sounds as dirty dark hack for me. This is the bug in disk driver, so > it shall be patched here, at the first. > > At the second, it's a OS driver bug. Even you will patch the OS bug in > application, your patch shall be in effect only on buggy version of OS. > > There may other OS with it's own bugs that may be masked by this patch > even the such bug will not be caused by broken system driver. Not > speaking about disk's firmware bugs. > > So it shall be part of a "ifdef" clearly marking such code as Linux's > dirty hack compiled on affected Linux OS only. > > Dan > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |
From: Dan L. <da...@ob...> - 2009-01-08 13:38:40
|
Bruce Allen napsal/wrote, On 01/08/09 12:25: > I might be confused about this, but I thought that this was a bug in the > USB <-> SATA interface chip firmware. I have no sufficient informations about it. But there has been patch http://marc.info/?l=linux-usb&m=123135651222832&w=2 mentioned here. Such patch repair problem in software - so it seems this is problem of communication between such driver and hardware. Well, such patch will not work for some hardware - but I don't know if it is because used method doesn't work for such hardware at all or because such patch mis-detect the workaround isn't required for such specific hardware. > If so, then our only alternatives > are (a) a workaround such as what Doug/Christian have proposed or (b) to > say that we don't support buggy hardware. In such cases, I am in favor > of (a), particularly if the relevant code sections are fairly isolated > and can be stripped out in a few years when the buggy hardware is > obsolete and gone. The 'a' is better, of course. But even if the bug is not related to specific driver and OS then the patch is workaround for specific hardware with specific bug. There may be other hardware without such bug (so the data we have are real data from underlying drive, not the data damaged by bridge). In short - if we got "half-response" then no problem if they arrived thought known broken chip - we know about it so we can repair it. If we got the same response on other device, then it may mean anything - we know nothing about it, so we can't assume it's either good or bad response. I have nothing about implement workaround in application - but we shall not correct silently the response in general - only when we know it's broken by "our known bug". May be, I misunderstand something, so may assumptions (and conclusions) may be wrong, of course. Dan >>> I think that we should accept the first (lower) byte >>> of 0x4f for success (or 0xf4 for failure) since it >>> is placed below the 18 byte SCSI-2 sense buffer length >>> limit in a SAT ATA Return descriptor. Silently ignore >>> in incorrect upper byte >> It sounds as dirty dark hack for me. This is the bug in disk driver, so >> it shall be patched here, at the first. >> >> At the second, it's a OS driver bug. Even you will patch the OS bug in >> application, your patch shall be in effect only on buggy version of OS. >> >> There may other OS with it's own bugs that may be masked by this patch >> even the such bug will not be caused by broken system driver. Not >> speaking about disk's firmware bugs. >> >> So it shall be part of a "ifdef" clearly marking such code as Linux's >> dirty hack compiled on affected Linux OS only. |
From: Bruce A. <ba...@gr...> - 2009-01-08 13:54:45
|
Hi Dan, >> I might be confused about this, but I thought that this was a bug in the >> USB <-> SATA interface chip firmware. > I have no sufficient informations about it. But there has been patch > http://marc.info/?l=linux-usb&m=123135651222832&w=2 > mentioned here. Such patch repair problem in software - so it seems this > is problem of communication between such driver and hardware. I assumed that this patch was a work-around for a bug in the USB<-->SATA chip firmware, which results in non-compliance with the either SCSI or SAT specs. Perhaps one of the real experts (Doug, Alfred, Christian) can comment: where does the root problem lie? Cheers, Bruce |