<div dir="ltr">In fact I tried to find that information on github before sending this email. The 'Blame' tab on github showed only a refactoring change touching these lines of code. Also, the file seems to have been imported from elsewhere in github and it seems github does not seem to know the history before the import. I am not a git expert - maybe I could use some git commands in my cloned repository to find that info - will have to dig more on that unless someone here can give me a pointer on how to find it.<div><br></div><div>-harendra</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 14, 2015 at 9:32 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, 30.09.15 20:40, Harendra Kumar (<a href="mailto:harendra.kumar@gmail.com">harendra.kumar@gmail.com</a>) wrote:<br>
<br>
> I have a few drives in an enclosure (mediasonic pro box) connected via USB<br>
> using a Jmicron USB bridge (ID 152d:0567 JMicron Technology Corp.). I am<br>
> not able to create the desired names ("ata-<model>-<serial>") for these<br>
> devices in /dev/disk/by-id because ata_id is unable to retrieve the ATA<br>
> device identity information for these drives.<br>
><br>
> I did some root causing and found where the problem lies. The ATA Pass<br>
> Through command (<br>
> <a href="https://github.com/systemd/systemd/blob/master/src/udev/ata_id/ata_id.c#L130" rel="noreferrer" target="_blank">https://github.com/systemd/systemd/blob/master/src/udev/ata_id/ata_id.c#L130</a>)<br>
> sets the check condition flag (CK_COND=1). In the response it expects and<br>
> checks for sense data -<br>
> <a href="https://github.com/systemd/systemd/blob/master/src/udev/ata_id/ata_id.c#L178" rel="noreferrer" target="_blank">https://github.com/systemd/systemd/blob/master/src/udev/ata_id/ata_id.c#L178</a><br>
> .<br>
><br>
> It seems the JMicron USB bridge successfully responds to the ATA IDENTIFY<br>
> DEVICE command but it does not return any sense data along with it and<br>
> therefore the disk_identify_command() function returns EIO even though the<br>
> command was successful and we got all that we needed. I checked by removing<br>
> this condition and the ata_id output was found to be accurate.<br>
><br>
> The behavior implemented by ata_id seems to be correct strictly speaking as<br>
> per the SAT draft. It seems the Jmicron USB hardware does not comply with<br>
> the standard. Here is an excerpt from page 123 of the SAT draft I found by<br>
> googling (<br>
> <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.394.3605&rep=rep1&type=pdf" rel="noreferrer" target="_blank">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.394.3605&rep=rep1&type=pdf</a><br>
> ).<br>
><br>
> -----snip-----<br>
> The CK_COND (Check Condition) bit may be used to request the SATL to return<br>
> a copy of ATA register information in the sense data upon command<br>
> completion. If the CK_COND bit is set to one the SATL shall return a status<br>
> of CHECK CONDITION when the ATA command completes, even if the command<br>
> completes successfully, and return the ATA Normal Output fields (see<br>
> ATA8-ACS) in the sense data using the ATA Return descriptor (see 12.2.6).<br>
> If the CK_COND bit is set to zero, then the SATL shall terminate the<br>
> command with CHECK CONDITION status only if an error occurs in processing<br>
> the command. See clause 11 for a description of ATA error conditions.<br>
> -----snip-----<br>
><br>
> Can anyone suggest what the right fix for this would be? One way I can<br>
> think of is to not set the CK_COND flag in the command and check for sense<br>
> error only if check condition status/sense data was returned by the device.<br>
> This seems to be the way smartctl works for SAT devices and that's why it<br>
> works for my JMicron as well. Will this cause any problems? Why was the<br>
> code written this way in the first place? Is there a better fix for this?<br>
<br>
</div></div>I figure you should put the folks who wrote that code specifically in<br>
CC, as they might not be on this ML. You may find that information in<br>
the git history data.<br>
<span class="HOEnZb"><font color="#888888"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
</font></span></blockquote></div><br></div>