Example: sending a correct "READ_NATIVE_MAX_ADDRESS_EXT" to /dev/sdd (opened O_RDWR | O_NONBLOCK) via ATA_PASSTHROUGH_16 (SCSI-Command 0x85) with the EXTEND and the CHECK_CONDITION bits set to 1 yields sense data in descriptor-format. Unfortunately, the descriptor does not have EXTEND set, and by that only returns 24 Bits of LBA. This obviously is a bug, as the SAT-2 Draft says: "If the sense data is for an ATA PASS-THROUGH (16) command with the EXTEND bit set to one, then the SATL shall return the 48-bit extended status and shall set the EXTEND bit to one." Contents of important data-structures for SG_IO: sg_io_hdr.cmdlen = 16 *sg_io_hdr.cmdp = {0x85 0x07 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x27 0x00} sense-data after command: 0x72 0x00 0x00 0x00 0x00 0x00 0x00 0x0e 0x09 0x0c 0x00 0x00 0x00 0x00 0x00 0xaf 0x00 0x6d 0x00 0x70 0x00 0x50 meaning: descriptor-sense, no error descriptor: code=0x09 -> ATA-Return descriptor length=0x0c EXTEND=0 Error = 0x00 SectorCount = 0x00 LBA_Low = 0xaf LBA_Mid = 0x6d LBA_High= 0x70 Device = 0 Status = DeviceReady | DeferredWriteError The drive used should be reporting a native max lba of 0x74706daf (1.02TB), so the expected sense data should look like: 0x72 0x00 0x00 0x00 0x00 0x00 0x00 0x0e 0x09 0x0c 0x01 0x00 0x00 0x00 0x6d 0xaf 0x74 0x70 0x00 0x00 0x00 0x50
Reply-To: dgilbert@interlog.com Douglas Gilbert wrote: > bugzilla-daemon@bugzilla.kernel.org wrote: >> http://bugzilla.kernel.org/show_bug.cgi?id=15185 >> >> Summary: Sending a 48bit ATA-Command with "CheckCondition" >> through SG_IO does not return correct 48bit sense >> descriptor >> Product: SCSI Drivers >> Version: 2.5 >> Kernel Version: 2.6.31 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: normal >> Priority: P1 >> Component: Other >> AssignedTo: scsi_drivers-other@kernel-bugs.osdl.org >> ReportedBy: stefan.huebner@stud.tu-ilmenau.de >> Regression: No >> >> >> Example: sending a correct "READ_NATIVE_MAX_ADDRESS_EXT" to /dev/sdd >> (opened >> O_RDWR | O_NONBLOCK) via ATA_PASSTHROUGH_16 (SCSI-Command 0x85) with >> the EXTEND >> and the CHECK_CONDITION bits set to 1 yields sense data in >> descriptor-format. Unfortunately, the descriptor does not have EXTEND >> set, and by that only >> returns 24 Bits of LBA. >> >> This obviously is a bug, as the SAT-2 Draft says: "If the sense data >> is for an >> ATA PASS-THROUGH (16) command with the EXTEND bit set to one, then the >> SATL >> shall return the 48-bit extended status and shall set the EXTEND bit >> to one." >> >> Contents of important data-structures for SG_IO: >> sg_io_hdr.cmdlen = 16 >> *sg_io_hdr.cmdp = {0x85 0x07 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >> 0x00 0x00 >> 0x00 0x00 0x27 0x00} >> >> sense-data after command: >> 0x72 0x00 0x00 0x00 0x00 0x00 0x00 0x0e 0x09 0x0c 0x00 0x00 0x00 0x00 >> 0x00 0xaf >> 0x00 0x6d 0x00 0x70 0x00 0x50 >> meaning: descriptor-sense, no error >> descriptor: >> code=0x09 -> ATA-Return descriptor >> length=0x0c >> EXTEND=0 >> Error = 0x00 >> SectorCount = 0x00 >> LBA_Low = 0xaf >> LBA_Mid = 0x6d >> LBA_High= 0x70 >> Device = 0 >> Status = DeviceReady | DeferredWriteError >> >> The drive used should be reporting a native max lba of 0x74706daf >> (1.02TB), so >> the expected sense data should look like: >> 0x72 0x00 0x00 0x00 0x00 0x00 0x00 0x0e 0x09 0x0c 0x01 0x00 0x00 0x00 >> 0x6d 0xaf >> 0x74 0x70 0x00 0x00 0x00 0x50 > > This bug does not occur in lk 2.6.30 but does in lk > 2.6.32 . There was a pretty large rework of libata > in that period and there is obvious bug in > drivers/ata/libata-scsi.c that causes this. > > The attached patch fixes this problem in lk 2.6.32 in > my test. > > Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Changelog: - Fix assignment which overwrote SAT ATA PASS-THROUGH command EXTEND bit setting (ATA_TFLAG_LBA48)
Reply-To: dgilbert@interlog.com bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=15185 > > Summary: Sending a 48bit ATA-Command with "CheckCondition" > through SG_IO does not return correct 48bit sense > descriptor > Product: SCSI Drivers > Version: 2.5 > Kernel Version: 2.6.31 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: scsi_drivers-other@kernel-bugs.osdl.org > ReportedBy: stefan.huebner@stud.tu-ilmenau.de > Regression: No > > > Example: sending a correct "READ_NATIVE_MAX_ADDRESS_EXT" to /dev/sdd (opened > O_RDWR | O_NONBLOCK) via ATA_PASSTHROUGH_16 (SCSI-Command 0x85) with the > EXTEND > and the CHECK_CONDITION bits set to 1 yields sense data in descriptor-format. > Unfortunately, the descriptor does not have EXTEND set, and by that only > returns 24 Bits of LBA. > > This obviously is a bug, as the SAT-2 Draft says: "If the sense data is for > an > ATA PASS-THROUGH (16) command with the EXTEND bit set to one, then the SATL > shall return the 48-bit extended status and shall set the EXTEND bit to one." > > Contents of important data-structures for SG_IO: > sg_io_hdr.cmdlen = 16 > *sg_io_hdr.cmdp = {0x85 0x07 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0x00 > 0x00 0x00 0x27 0x00} > > sense-data after command: > 0x72 0x00 0x00 0x00 0x00 0x00 0x00 0x0e 0x09 0x0c 0x00 0x00 0x00 0x00 0x00 > 0xaf > 0x00 0x6d 0x00 0x70 0x00 0x50 > meaning: descriptor-sense, no error > descriptor: > code=0x09 -> ATA-Return descriptor > length=0x0c > EXTEND=0 > Error = 0x00 > SectorCount = 0x00 > LBA_Low = 0xaf > LBA_Mid = 0x6d > LBA_High= 0x70 > Device = 0 > Status = DeviceReady | DeferredWriteError > > The drive used should be reporting a native max lba of 0x74706daf (1.02TB), > so > the expected sense data should look like: > 0x72 0x00 0x00 0x00 0x00 0x00 0x00 0x0e 0x09 0x0c 0x01 0x00 0x00 0x00 0x6d > 0xaf > 0x74 0x70 0x00 0x00 0x00 0x50 This bug does not occur in lk 2.6.30 but does in lk 2.6.32 . There was a pretty large rework of libata in that period and there is obvious bug in drivers/ata/libata-scsi.c that causes this. The attached patch fixes this problem in lk 2.6.32 in my test. Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Just to clear up: sorry, I forgot I recently updated to 2.6.32. Changed bug-description accordingly.
commit bc496ed00ab1411d3efaf295b72e0c9eb343e1a3