| Summary: | [PATCH] ATA IDENTIFY DEVICE sent with SECTOR_COUNT=0 | ||
|---|---|---|---|
| Product: | udisks | Reporter: | Peter Paluch <peter.paluch> |
| Component: | detection | Assignee: | David Zeuthen (not reading bugmail) <zeuthen> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Patch to correct IDENTIFY (PACKET) DEVICE calls so that the SECTOR_COUNT is set to 1 | ||
|
Description
Peter Paluch
2014-01-19 01:08:47 UTC
Interesting, nice detective work. I'm not opposed to applying this fix (just tested it, works fine with a couple of ATA devices here) if it fixes real problems, but I don't see anywhere that says that Count should be 1... the ATA8 spec says "N/A". (Btw, there's a ton of other places doing this where you may need the same fix including ata_id, libatasmart, smartmontools. I haven't checked but I think at least ata_id also sets Count to 0.) Hi David, (In reply to comment #1) > Interesting, nice detective work. I'm not opposed to applying this fix (just > tested it, works fine with a couple of ATA devices here) if it fixes real > problems, but I don't see anywhere that says that Count should be 1... the > ATA8 spec says "N/A". Thank you for the compliment. It definitely solves a rather annoying problem for me, and obviously for another person as well (Andrej P. who joined my bug report to the linux-usb). I know that ATA8 spec says N/A with regard to the Count field. What the ATA8 also says, however, is: "The IDENTIFY DEVICE command enables the host to receive a 512-byte block of data from the device." It may be related to the SATL layer in particular, because in SCSI / ATA Translation - 3 (SAT-3) Section 12.2.2.4 the spec states: "The SATL shall determine the transfer length by the method specified in the T_LENGTH field as shown in table 153." Now obviously, the transfer length is 512 bytes - this is the result from the IDENTIFY DEVICE. It appears that it is the SATL, not the drive itself, that needs the count=1, otherwise, the SATL does not read out the data from the drive after the command has been sent - that's my guess. > (Btw, there's a ton of other places doing this where you may need the same > fix including ata_id, libatasmart, smartmontools. I haven't checked but I > think at least ata_id also sets Count to 0.) I believe the opposite is true. I've just checked the source files: - sg_sat_identify from sg3-utils sets count=1 - smartmontools set count=1 - ata_id sets count=1 - libatasmart sets count=1 I can point you towards the particular source files and lines. You may want to check it yourself even without source files - simply run the binaries in strace and check for the ioctl (fd, SG_IO) calls. The hexa dump of the cdb is fairly easily identifiable. Best regards, Peter I just checked udev's ata_id (I wrote parts of it), and, indeed you are correct. I've applied your patch, see http://cgit.freedesktop.org/udisks/commit/?id=81a350fca9431048175fcf639909d988aceb2a17 Thanks! David, Thank you! It was an honor to help. Best regards, Peter (In reply to comment #3) > I just checked udev's ata_id (I wrote parts of it), and, indeed you are > correct. I've applied your patch, see > > http://cgit.freedesktop.org/udisks/commit/ > ?id=81a350fca9431048175fcf639909d988aceb2a17 > > Thanks! Patch from Peter works. Good job. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.