Comment 36 for bug 548513

@Jerone
 We already discussed this offline but for everyone else's benefit, I was commenting on the feasibility
of the workaround and how to best optimize it. No where did I ever state that this was an acceptable
alternative to seeking the root cause.

So my initial stab at instrumenting this has been interesting, the passthrough commands are nothing
exotic and other ATA passthrough commands are failing, like configuring the cache.
...

This was plain jane "identify device" dropping dead after the drive was up and stable.

Apr 15 17:22:00 ubuntu kernel: [12081.321383] ieee1394: sbp2: aborting sbp2 command
Apr 15 17:22:00 ubuntu kernel: [12081.321389] sd 22:0:0:0: [sdb] CDB: ATA command pass through(16): 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00

The second byte from the end is the actual ATA command being executed.
IDENTIFY DEVICE = ECh

http://www.spinics.net/lists/hotplug/msg03552.html

Alan makes a good point regarding the ordering of the commands executed. I can reproduce
something similar here using sg_sat_set_features

sg_sat_set_features -f 82 /dev/sdb

which is trying to disable the cache on the drive.

The logs are showing a SCSI inquiry timing out, which should be translated to an identify device,
I never get to the actual "set features" command.

I'm working on some more targeted instrumentation to see how the ordering affects things. It'd
be great if I had an SAS/SATA analyzer here.

Thing is, if this where a general SATL issue we'd be seeing it everywhere, sg_sat_identify works fine
for the host drive. This firewire stuff must be implementing it's own version. Sigh...

Reading further into their analysis, it's this specific USB to SATA bridge chip that's having problems.
We might have the same bridge in our firewire drive. These external drives have USB, eSATA, and FW for
connection options. I wouldn't be surprised if they're translating everything to one protocol before sending
it to the drive. I'd have to take it apart to find out which bridge it's using.

Mark Lord's observation is proving correct so far
http://www.spinics.net/lists/hotplug/msg03610.html

Issuing a 12 byte IDENTIFY DEVICE to the drive is proving successful.

root@ubuntu:~# lsscsi
[0:0:0:0] disk ATA Hitachi HTS54502 PB2O /dev/sda
[1:0:0:0] cd/dvd Optiarc DVD+-RW AD-7585H KD03 /dev/sr0
[28:0:0:0] disk WD My Book 1028 /dev/sdb
[29:0:1:0] enclosu WD My Book Device -

root@ubuntu:~# sg_sat_identify --len 12 /dev/sdb
Response for IDENTIFY DEVICE ATA command:
 00 427a 3fff c837 0010 0000 0000 003f 0000 Bz ?. .7 .. .. .. .? ..
 08 0000 0000 2020 2020 2057 442d 5743 4154 .. .. W D- WC AT
 10 3134 3139 3230 3639 0000 4000 0032 3031 14 19 20 69 .. @. .2 01
 18 2e30 3341 3031 5744 4320 5744 3332 3030 .0 3A 01 WD C WD 32 00
 20 4141 4a53 2d30 3042 3441 3020 2020 2020 AA JS -0 0B 4A 0
 28 2020 2020 2020 2020 2020 2020 2020 8010 ..
 30 0000 2f00 4001 0000 0000 0007 3fff 0010 .. /. @. .. .. .. ?. ..
 38 003f fc10 00fb 0101 ffff 0fff 0000 0007 .? .. .. .. .. .. .. ..
 40 0003 0078 0078 0078 0078 0000 0000 0000 .. .x .x .x .x .. .. ..
 48 0000 0000 0000 001f 0706 0000 0044 0040 .. .. .. .. .. .. .D .@
 50 01fe 0000 746b 7f61 4123 7469 be41 4123 .. .. tk .a A# ti .A A#
 58 407f 001d 001d 0000 fffe 0000 80fe 0000 @. .. .. .. .. .. .. ..
 60 0000 0000 0000 0000 eab0 2542 0000 0000 .. .. .. .. .. %B .. ..
 68 0000 0000 0000 0000 5001 4ee1 56a4 91c9 .. .. .. .. P. N. V. ..
 70 0000 0000 0000 0000 0000 0000 0000 4010 .. .. .. .. .. .. .. @.
 78 4010 0000 0000 0000 0000 0000 0000 0000 @. .. .. .. .. .. .. ..
 80 0021 0000 0000 0000 0000 169f 0000 0000 .! .. .. .. .. .. .. ..
 88 0000 0000 0000 0000 0000 0000 0004 0000 .. .. .. .. .. .. .. ..
 90 0000 0000 0000 0000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 98 0000 0000 0000 0000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 a0 0000 0000 0000 0000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 a8 0000 0000 0000 0000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 b0 0000 0000 0000 0000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 b8 0000 0000 0000 0000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 c0 0000 0000 0000 0000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 c8 0000 0000 0000 0000 0000 0000 303f 0000 .. .. .. .. .. .. 0? ..
 d0 0000 0000 0000 0000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 d8 0000 0000 0000 0000 0000 0000 100e 0000 .. .. .. .. .. .. .. ..
 e0 0000 0000 0000 0000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 e8 0000 0000 0001 1000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 f0 0000 0000 0000 0000 0000 0000 0000 0000 .. .. .. .. .. .. .. ..
 f8 0000 0000 0000 0000 0000 0000 0000 7fa5 .. .. .. .. .. .. .. ..

So Mark Lord's updated hdparm should alleviate the problem. Will retest tomorrow.

http://www.spinics.net/lists/hotplug/msg03575.html

"""
| | Confirming that, what is put in the ATA_16 sector
| | count field is what the ATA command (IDENTIFY DEVICE)
| | expects in its count field. And according to ACS-2 (rev 2)
| | for IDENTIFY DEVICE that is "N/A" which I would
| | interpret as zero.
| |
| Ouch. Reviewing that "N/A" in the ATA spec: it means
| that neither the host nor device should check that
| field. So it could be any value, in this case 1.
..

I'll update hdparm (version 9.29) to supply a sector count of "1"
for IDENTIFY commands, just to satisfy the buggy bridge chip.

Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
"""