Patchwork sata-sil drive detection issues.

login
register
mail settings
Submitter Tejun Heo
Date Feb. 17, 2011, 9:58 a.m.
Message ID <20110217095815.GN19830@htj.dyndns.org>
Download mbox | patch
Permalink /patch/83437/
State Not Applicable
Delegated to: David Miller
Headers show

Comments

Tejun Heo - Feb. 17, 2011, 9:58 a.m.
Hello,

On Thu, Feb 17, 2011 at 03:23:13PM +1100, Steven Haigh wrote:
> I might have acted a bit prematurely on this. After booting off the
> CentOS 5.5 installation DVD, I noticed that the esata drive at the
> same problem. After lots of cable swapping and testing, I have found
> that the esata cable may be faulty as a direct SATA -> drive
> connection works perfectly.
> 
> I am unsure however why my previous test of plugging the esata drive
> directly to the onboard SATA controller worked - however now this
> also fails.
> 
> I shall attempt to try some different eSATA cables and report back
> if I manage to isolate the issue directly to the sata_sil module.

It's probably dependent on timing and not completely reliable.  It's
rather complicated.  The AC_ERR_NODEV_HINT thing is there primarily
for PATA controllers so that they don't spend time trying to probe
empty ports.

Does the following patch resolve the problem?
Steven Haigh - Feb. 17, 2011, 11:20 p.m.
On Thu, 17 Feb 2011 10:58:15 +0100, Tejun Heo wrote:
> Hello,
>
> On Thu, Feb 17, 2011 at 03:23:13PM +1100, Steven Haigh wrote:
>> I might have acted a bit prematurely on this. After booting off the
>> CentOS 5.5 installation DVD, I noticed that the esata drive at the
>> same problem. After lots of cable swapping and testing, I have found
>> that the esata cable may be faulty as a direct SATA -> drive
>> connection works perfectly.
>>
>> I am unsure however why my previous test of plugging the esata drive
>> directly to the onboard SATA controller worked - however now this
>> also fails.
>>
>> I shall attempt to try some different eSATA cables and report back
>> if I manage to isolate the issue directly to the sata_sil module.
>
> It's probably dependent on timing and not completely reliable.  It's
> rather complicated.  The AC_ERR_NODEV_HINT thing is there primarily
> for PATA controllers so that they don't spend time trying to probe
> empty ports.
>
> Does the following patch resolve the problem?
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index d4e52e2..d08383f 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -1908,7 +1908,13 @@ retry:
>  		err_mask = ata_do_dev_read_id(dev, &tf, id);
>
>  	if (err_mask) {
> -		if (err_mask & AC_ERR_NODEV_HINT) {
> +		/*
> +		 * AC_ERR_NODEV_HINT is primarily used to detect empty PATA
> +		 * ports.  Some SATA devices incorrectly trigger it.
> +		 * Ignore if the physical link is positively online.
> +		 */
> +		if ((err_mask & AC_ERR_NODEV_HINT) &&
> +		    !ata_phys_link_online(ata_dev_phys_link(dev))) {
>  			ata_dev_printk(dev, KERN_DEBUG,
>  				       "NODEV after polling detection\n");
>  			return -ENOENT;

 With this patch applied, my rebuilt kernel based on 2.6.32.26 (due to 
 Xen Dom0 requirements) gives the following:

 ata9: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
 ata9: SError: { PHYRdyChg CommWake }
 ata9: hard resetting link
 ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
 ata9: hard resetting link
 ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
 ata9: hard resetting link
 ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
 ata9: hard resetting link
 ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata9: EH complete

 I would really like to eliminate the possibility of it being my esata 
 enclosure or the sata -> esata cable by using another cable and/or array 
 for testing. New cables will be a few days off as I don't have any of 
 these cables hanging around. My gut feeling says its the cable - as the 
 enclosure works fine via the USB port - however that isn't conlusive 
 proof that the esata port is working as it should!

 --
 Steven Haigh
 
 Email: netwiz@crc.id.au
 Web: http://www.crc.id.au
 Phone: (03) 9001 6090 - 0412 935 897
 Fax: (03) 8338 0299
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tejun Heo - Feb. 18, 2011, 9:16 a.m.
Hello,

On Fri, Feb 18, 2011 at 10:20:43AM +1100, Steven Haigh wrote:
> With this patch applied, my rebuilt kernel based on 2.6.32.26 (due
> to Xen Dom0 requirements) gives the following:
> 
> ata9: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
> ata9: SError: { PHYRdyChg CommWake }
> ata9: hard resetting link
> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
> ata9: hard resetting link
> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
> ata9: hard resetting link
> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
> ata9: hard resetting link
> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata9: EH complete

So, retrying doesn't help at all.

> I would really like to eliminate the possibility of it being my
> esata enclosure or the sata -> esata cable by using another cable
> and/or array for testing. New cables will be a few days off as I
> don't have any of these cables hanging around. My gut feeling says
> its the cable - as the enclosure works fine via the USB port -
> however that isn't conlusive proof that the esata port is working as
> it should!

Yeah, it looks like something is wrong with the setup.  Please let us
know how the testing goes with the new cable (hopefully shorter).

Thanks.
Steven Haigh - Feb. 24, 2011, 2:24 a.m.
On 18/02/2011 8:16 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Feb 18, 2011 at 10:20:43AM +1100, Steven Haigh wrote:
>> With this patch applied, my rebuilt kernel based on 2.6.32.26 (due
>> to Xen Dom0 requirements) gives the following:
>>
>> ata9: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
>> ata9: SError: { PHYRdyChg CommWake }
>> ata9: hard resetting link
>> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
>> ata9: hard resetting link
>> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
>> ata9: hard resetting link
>> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202)
>> ata9: hard resetting link
>> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>> ata9: EH complete
>
> So, retrying doesn't help at all.
>
>> I would really like to eliminate the possibility of it being my
>> esata enclosure or the sata ->  esata cable by using another cable
>> and/or array for testing. New cables will be a few days off as I
>> don't have any of these cables hanging around. My gut feeling says
>> its the cable - as the enclosure works fine via the USB port -
>> however that isn't conlusive proof that the esata port is working as
>> it should!
>
> Yeah, it looks like something is wrong with the setup.  Please let us
> know how the testing goes with the new cable (hopefully shorter).

Hmmm - the replacement SATA -> eSATA cables arrived today and I still 
get the same problem. On a whim, I connected the same cable + adapter + 
cradle to my i7 system running Fedora 14. This is not a sata_sil based 
adapter, but I believe it may rule out both the cable & the cradle as 
faulty.

[  371.217646] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 
0xe frozen
[  371.217700] ata6: irq_stat 0x00000040, connection status changed
[  371.217750] ata6: SError: { RecovComm PHYRdyChg CommWake DevExch }
[  371.217807] ata6: hard resetting link
[  376.326257] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  376.347413] ata6.00: ATA-7: HDS728080PLA380, PF2OA60A, max UDMA/133
[  376.347417] ata6.00: 160836480 sectors, multi 0: LBA48
[  376.356485] ata6.00: failed to IDENTIFY (I/O error, err_mask=0x100)
[  376.356490] ata6.00: revalidation failed (errno=-5)
[  381.324129] ata6: hard resetting link
[  381.629014] ata6: SATA link down (SStatus 0 SControl 300)
[  381.629022] ata6: limiting SATA link speed to 1.5 Gbps
[  386.626909] ata6: hard resetting link
[  387.494543] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  387.533074] ata6.00: configured for UDMA/133
[  387.533082] ata6: EH complete
[  387.533262] scsi 5:0:0:0: Direct-Access     ATA      HDS728080PLA380 
  PF2O PQ: 0 ANSI: 5
[  387.533504] sd 5:0:0:0: Attached scsi generic sg3 type 0
[  387.533721] sd 5:0:0:0: [sdc] 160836480 512-byte logical blocks: 
(82.3 GB/76.6 GiB)
[  387.533790] sd 5:0:0:0: [sdc] Write Protect is off
[  387.533794] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[  387.533823] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[  387.534037]  sdc: sdc1
[  387.549830] sd 5:0:0:0: [sdc] Attached SCSI disk

I found it interesting that the drive failed to ident multiple times, 
however retrying eventually worked.

Could it just be that the cradle is slow to initialise and therefore the 
sata_sil adapter gives up before the cradle is actually ready?

Following this logic, I tried powering up the cradle before connecting 
the esata cable. I don't see anything in dmesg connecting the esata 
cable AFTER the cradle has been powered on. Maybe the cradle disables 
the esata connection if theres no cable connected on powerup?
Tejun Heo - Feb. 24, 2011, 8:31 a.m.
Hello,

On Thu, Feb 24, 2011 at 01:24:21PM +1100, Steven Haigh wrote:
> >Yeah, it looks like something is wrong with the setup.  Please let us
> >know how the testing goes with the new cable (hopefully shorter).
> 
> Hmmm - the replacement SATA -> eSATA cables arrived today and I
> still get the same problem. On a whim, I connected the same cable +
> adapter + cradle to my i7 system running Fedora 14. This is not a
> sata_sil based adapter, but I believe it may rule out both the cable
> & the cradle as faulty.

Hmmm...

> [  371.217646] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4050002
> action 0xe frozen
> [  371.217700] ata6: irq_stat 0x00000040, connection status changed
> [  371.217750] ata6: SError: { RecovComm PHYRdyChg CommWake DevExch }
> [  371.217807] ata6: hard resetting link
> [  376.326257] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [  376.347413] ata6.00: ATA-7: HDS728080PLA380, PF2OA60A, max UDMA/133
> [  376.347417] ata6.00: 160836480 sectors, multi 0: LBA48
> [  376.356485] ata6.00: failed to IDENTIFY (I/O error, err_mask=0x100)
> [  376.356490] ata6.00: revalidation failed (errno=-5)
> [  381.324129] ata6: hard resetting link
> [  381.629014] ata6: SATA link down (SStatus 0 SControl 300)
> [  381.629022] ata6: limiting SATA link speed to 1.5 Gbps
> [  386.626909] ata6: hard resetting link
> [  387.494543] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [  387.533074] ata6.00: configured for UDMA/133
> [  387.533082] ata6: EH complete
> [  387.533262] scsi 5:0:0:0: Direct-Access     ATA
> HDS728080PLA380  PF2O PQ: 0 ANSI: 5
> [  387.533504] sd 5:0:0:0: Attached scsi generic sg3 type 0
> [  387.533721] sd 5:0:0:0: [sdc] 160836480 512-byte logical blocks:
> (82.3 GB/76.6 GiB)
> [  387.533790] sd 5:0:0:0: [sdc] Write Protect is off
> [  387.533794] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
> [  387.533823] sd 5:0:0:0: [sdc] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [  387.534037]  sdc: sdc1
> [  387.549830] sd 5:0:0:0: [sdc] Attached SCSI disk
> 
> I found it interesting that the drive failed to ident multiple
> times, however retrying eventually worked.

Well, yeah, IDENTIFY failure is still there.  Controllers behave
differently and some may have higher tolerance under certain
circumstances but the setup just seems quite flimsy for whatever
reason.

> Could it just be that the cradle is slow to initialise and therefore
> the sata_sil adapter gives up before the cradle is actually ready?
> 
> Following this logic, I tried powering up the cradle before
> connecting the esata cable. I don't see anything in dmesg connecting
> the esata cable AFTER the cradle has been powered on. Maybe the
> cradle disables the esata connection if theres no cable connected on
> powerup?

Is the cradle an active device or is it just power supply +
eSATA->SATA gender?  Oh, right, you said it also had USB connection,
so it's an active device.  Can you open it up and see which chip is
there?

Thanks.
Steven Haigh - Feb. 24, 2011, 9:53 a.m.
On 24/02/2011 7:31 PM, Tejun Heo wrote:
> Well, yeah, IDENTIFY failure is still there.  Controllers behave
> differently and some may have higher tolerance under certain
> circumstances but the setup just seems quite flimsy for whatever
> reason.

Yeah - I noticed that. These things can never be simple, can they?!

>> Could it just be that the cradle is slow to initialise and therefore
>> the sata_sil adapter gives up before the cradle is actually ready?
>>
>> Following this logic, I tried powering up the cradle before
>> connecting the esata cable. I don't see anything in dmesg connecting
>> the esata cable AFTER the cradle has been powered on. Maybe the
>> cradle disables the esata connection if theres no cable connected on
>> powerup?
>
> Is the cradle an active device or is it just power supply +
> eSATA->SATA gender?  Oh, right, you said it also had USB connection,
> so it's an active device.  Can you open it up and see which chip is
> there?

Of course I can crack it open - thats what makes life fun!

The top side of the internal PCB is fairly plain with just the SATA 
power & data sockets on it and the various USB ports and card sockets on 
the front.

On the rear, we have a 30Mhz and a 12Mhz oscillator and 3 main CPU type 
chips.

Near the card readers:
GL826 / MX2AE08G08 / 842H35518 - I assume this is the IDE / CF / card IO 
chip.

Near the rear:
JMB352 / 0834 LGBA1 A / 370JF3011 - This looks to be hooked up via some 
capacitors to the DATA data lines on both sockets. If I haven't 
mentioned before, this is a 2 x SATA drive bay cradle.

A third tiny chip near the JMB352 is:
GL850A / MN2FA01G11 / 911SK03111 - Not 100% sure of the function of this 
chip by following the tracks, but it looks like it might be some kind of 
a clock source. That is a wild guess though!

If you need photos, let me know and I'll make some up.
Tejun Heo - Feb. 24, 2011, 10:06 a.m.
Hello,

(cc'ing Justin)

On Thu, Feb 24, 2011 at 08:53:15PM +1100, Steven Haigh wrote:
> On 24/02/2011 7:31 PM, Tejun Heo wrote:
> >Well, yeah, IDENTIFY failure is still there.  Controllers behave
> >differently and some may have higher tolerance under certain
> >circumstances but the setup just seems quite flimsy for whatever
> >reason.
> 
> Yeah - I noticed that. These things can never be simple, can they?!
> 
> >>Could it just be that the cradle is slow to initialise and therefore
> >>the sata_sil adapter gives up before the cradle is actually ready?
> >>
> >>Following this logic, I tried powering up the cradle before
> >>connecting the esata cable. I don't see anything in dmesg connecting
> >>the esata cable AFTER the cradle has been powered on. Maybe the
> >>cradle disables the esata connection if theres no cable connected on
> >>powerup?
> >
> >Is the cradle an active device or is it just power supply +
> >eSATA->SATA gender?  Oh, right, you said it also had USB connection,
> >so it's an active device.  Can you open it up and see which chip is
> >there?
> 
> Of course I can crack it open - thats what makes life fun!
> 
> The top side of the internal PCB is fairly plain with just the SATA
> power & data sockets on it and the various USB ports and card
> sockets on the front.
> 
> On the rear, we have a 30Mhz and a 12Mhz oscillator and 3 main CPU
> type chips.
> 
> Near the card readers:
> GL826 / MX2AE08G08 / 842H35518 - I assume this is the IDE / CF /
> card IO chip.

Yeah, that's the card reader.

> Near the rear:
> JMB352 / 0834 LGBA1 A / 370JF3011 - This looks to be hooked up via
> some capacitors to the DATA data lines on both sockets. If I haven't
> mentioned before, this is a 2 x SATA drive bay cradle.

This is the SATA part.

> A third tiny chip near the JMB352 is:
> GL850A / MN2FA01G11 / 911SK03111 - Not 100% sure of the function of
> this chip by following the tracks, but it looks like it might be
> some kind of a clock source. That is a wild guess though!

This is USB thingie.

So, the offending part is JMB352.  Justin, when JMB352 is doing e-SATA
interface, it's failing IDENTIFY.  sata_sil fails to recognize it and
ahci (right? Steven) succeeds only after IDENTIFY failures and
retries.  Any ideas what's going on?  When doing e-SATA, is the chip
active or passive?  ie. Does it just pass through the signals or do
some meddling inbetween?

Thanks.
Mark Lord - Feb. 24, 2011, 4:21 p.m.
On 11-02-24 05:06 AM, Tejun Heo wrote:
>
>> Near the rear:
>> JMB352 / 0834 LGBA1 A / 370JF3011 - This looks to be hooked up via
>> some capacitors to the DATA data lines on both sockets. If I haven't
>> mentioned before, this is a 2 x SATA drive bay cradle.
> 
> This is the SATA part.
> 
>> A third tiny chip near the JMB352 is:
>> GL850A / MN2FA01G11 / 911SK03111 - Not 100% sure of the function of
>> this chip by following the tracks, but it looks like it might be
>> some kind of a clock source. That is a wild guess though!
> 
> This is USB thingie.
> 
> So, the offending part is JMB352.  Justin, when JMB352 is doing e-SATA
> interface, it's failing IDENTIFY.  sata_sil fails to recognize it and
> ahci (right? Steven) succeeds only after IDENTIFY failures and
> retries.  Any ideas what's going on?  When doing e-SATA, is the chip
> active or passive?  ie. Does it just pass through the signals or do
> some meddling inbetween?


Since this is a dual-SATA device, does it have TWO eSATA ports at the back,
or just one?  If the latter, then I'd expect to find a port-multiplier in the chain.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Steven Haigh - Feb. 24, 2011, 4:29 p.m.
On 25/02/2011 3:21 AM, Mark Lord wrote:
> On 11-02-24 05:06 AM, Tejun Heo wrote:
>>
>>> Near the rear:
>>> JMB352 / 0834 LGBA1 A / 370JF3011 - This looks to be hooked up via
>>> some capacitors to the DATA data lines on both sockets. If I haven't
>>> mentioned before, this is a 2 x SATA drive bay cradle.
>>
>> This is the SATA part.
>>
>>> A third tiny chip near the JMB352 is:
>>> GL850A / MN2FA01G11 / 911SK03111 - Not 100% sure of the function of
>>> this chip by following the tracks, but it looks like it might be
>>> some kind of a clock source. That is a wild guess though!
>>
>> This is USB thingie.
>>
>> So, the offending part is JMB352.  Justin, when JMB352 is doing e-SATA
>> interface, it's failing IDENTIFY.  sata_sil fails to recognize it and
>> ahci (right? Steven) succeeds only after IDENTIFY failures and
>> retries.  Any ideas what's going on?  When doing e-SATA, is the chip
>> active or passive?  ie. Does it just pass through the signals or do
>> some meddling inbetween?
>
>
> Since this is a dual-SATA device, does it have TWO eSATA ports at the back,
> or just one?  If the latter, then I'd expect to find a port-multiplier in the chain.

Hi Mark,

There is only one eSATA port on the back of the cradle. From looking at 
the specs of the JMB352[1], it seems that it has the capability to have 
3 SATA channels. Two are used for the cradle bays, the third for the 
uplink to the PC.

The PDF states:
"The SATA controller could be configured as host or device. The
3-port SATA II 3.0G controllers further supports the eSATA to dual SATA 
communication."

[1] - http://www.jmicron.com/PDF/JMB352/JMB352.pdf
Mark Lord - Feb. 24, 2011, 7:04 p.m.
On 11-02-24 11:29 AM, Steven Haigh wrote:
>
> There is only one eSATA port on the back of the cradle. From looking at the
> specs of the JMB352[1], it seems that it has the capability to have 3 SATA
> channels. Two are used for the cradle bays, the third for the uplink to the PC.
> 
> The PDF states:
> "The SATA controller could be configured as host or device. The
> 3-port SATA II 3.0G controllers further supports the eSATA to dual SATA
> communication."
> 
> [1] - http://www.jmicron.com/PDF/JMB352/JMB352.pdf


It would be nice to know what that actually means.
The only standard way for a single eSATA to connect to two SATA
is via a SATA Port Multiplier.  I wonder if that chip implements one?

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Lord - Feb. 24, 2011, 8:26 p.m.
On 11-02-24 02:04 PM, Mark Lord wrote:
> On 11-02-24 11:29 AM, Steven Haigh wrote:
>>
>> There is only one eSATA port on the back of the cradle. From looking at the
>> specs of the JMB352[1], it seems that it has the capability to have 3 SATA
>> channels. Two are used for the cradle bays, the third for the uplink to the PC.
>>
>> The PDF states:
>> "The SATA controller could be configured as host or device. The
>> 3-port SATA II 3.0G controllers further supports the eSATA to dual SATA
>> communication."
>>
>> [1] - http://www.jmicron.com/PDF/JMB352/JMB352.pdf
> 
> 
> It would be nice to know what that actually means.
> The only standard way for a single eSATA to connect to two SATA
> is via a SATA Port Multiplier.  I wonder if that chip implements one?

The product brief lists possible operation modes of the chip as:

 -- RAID0, RAID1, JBOD, or Port Multiplier

So I would guess that the drive detection issues must have something
to do with the operation mode.  I wonder how one selects *which* mode
should be used by the chip?

Or quite likely the only hardware mode is "Port Multiplier",
and the rest are just fakeraid things in software.

You and Tejun ought to be able to collect some debugging info
(eg. initial ATA register state on probe) to see if the device
even tries to report itself as a port multiplier.

Tricky stuff, undocumented hardware.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Steven Haigh - Feb. 28, 2011, 10:07 a.m.
On 24/02/2011 9:06 PM, Tejun Heo wrote:
> Hello,
>
> (cc'ing Justin)
>
> On Thu, Feb 24, 2011 at 08:53:15PM +1100, Steven Haigh wrote:
>> On 24/02/2011 7:31 PM, Tejun Heo wrote:
>>> Well, yeah, IDENTIFY failure is still there.  Controllers behave
>>> differently and some may have higher tolerance under certain
>>> circumstances but the setup just seems quite flimsy for whatever
>>> reason.
>>
>> Yeah - I noticed that. These things can never be simple, can they?!
>>
>>>> Could it just be that the cradle is slow to initialise and therefore
>>>> the sata_sil adapter gives up before the cradle is actually ready?
>>>>
>>>> Following this logic, I tried powering up the cradle before
>>>> connecting the esata cable. I don't see anything in dmesg connecting
>>>> the esata cable AFTER the cradle has been powered on. Maybe the
>>>> cradle disables the esata connection if theres no cable connected on
>>>> powerup?
>>>
>>> Is the cradle an active device or is it just power supply +
>>> eSATA->SATA gender?  Oh, right, you said it also had USB connection,
>>> so it's an active device.  Can you open it up and see which chip is
>>> there?
>>
>> Of course I can crack it open - thats what makes life fun!
>>
>> The top side of the internal PCB is fairly plain with just the SATA
>> power&  data sockets on it and the various USB ports and card
>> sockets on the front.
>>
>> On the rear, we have a 30Mhz and a 12Mhz oscillator and 3 main CPU
>> type chips.
>>
>> Near the card readers:
>> GL826 / MX2AE08G08 / 842H35518 - I assume this is the IDE / CF /
>> card IO chip.
>
> Yeah, that's the card reader.
>
>> Near the rear:
>> JMB352 / 0834 LGBA1 A / 370JF3011 - This looks to be hooked up via
>> some capacitors to the DATA data lines on both sockets. If I haven't
>> mentioned before, this is a 2 x SATA drive bay cradle.
>
> This is the SATA part.
>
>> A third tiny chip near the JMB352 is:
>> GL850A / MN2FA01G11 / 911SK03111 - Not 100% sure of the function of
>> this chip by following the tracks, but it looks like it might be
>> some kind of a clock source. That is a wild guess though!
>
> This is USB thingie.
>
> So, the offending part is JMB352.  Justin, when JMB352 is doing e-SATA
> interface, it's failing IDENTIFY.  sata_sil fails to recognize it and
> ahci (right? Steven) succeeds only after IDENTIFY failures and
> retries.  Any ideas what's going on?  When doing e-SATA, is the chip
> active or passive?  ie. Does it just pass through the signals or do
> some meddling inbetween?

Has there been any progress on this as yet? I haven't heard anything in 
a while...

Patch

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d4e52e2..d08383f 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1908,7 +1908,13 @@  retry:
 		err_mask = ata_do_dev_read_id(dev, &tf, id);
 
 	if (err_mask) {
-		if (err_mask & AC_ERR_NODEV_HINT) {
+		/*
+		 * AC_ERR_NODEV_HINT is primarily used to detect empty PATA
+		 * ports.  Some SATA devices incorrectly trigger it.
+		 * Ignore if the physical link is positively online.
+		 */
+		if ((err_mask & AC_ERR_NODEV_HINT) &&
+		    !ata_phys_link_online(ata_dev_phys_link(dev))) {
 			ata_dev_printk(dev, KERN_DEBUG,
 				       "NODEV after polling detection\n");
 			return -ENOENT;