sata-sil drive detection issues.

sata-sil drive detection issues.

[Steven Haigh]

Hi all,

Firstly, please CC me in all replies as I am not a member of this list.

I have been having an issue with quite a few of the fedora kernels in 
detecting drives on a sil3112 or sil3114 PCI card.

When plugging in a SATA drive (I'm using an external esata drive for 
this test), I see the following appear in dmesg:

[   74.664034] ata10: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe
frozen
[   74.664208] ata10: SError: { PHYRdyChg CommWake }
[   74.664310] ata10: hard resetting link
[   80.416870] ata10: link is slow to respond, please be patient (ready=-19)
[   81.789464] ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   81.789572] ata10.00: NODEV after polling detection
[   81.789593] ata10: EH complete

No device is detected.

This seems to occur if the drive is turned on after the machine is 
started, and when the system boots. I can see the drive in the card BIOS 
when the system starts if it is powered on after the drive has power.

So far, I have tried the following kernel versions:
2.6.32.26-174.2.xendom0.fc12.x86_64
2.6.35.10-71.fc14.x86_64
2.6.35.11-83.fc14.x86_64
2.6.38-0.rc4.git0.2.fc15.x86_64

If I move the internal SATA cable from the sil3112 or sil3114 card to 
the onboard SATA ports (detected as AHCI), then the drive is detected as 
it should and works perfectly.

I have a current bug open for Fedora at:
https://bugzilla.redhat.com/show_bug.cgi?id=677217

The sil3114 that is currently installed seemed to work perfectly using 
CentOS 5.5 kernel (based on 2.6.18) - I am going to try and install 
CentOS to a different LV to confirm this shortly.

Does anyone have any suggestions on this?

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

Re: sata-sil drive detection issues.

[Steven Haigh]

On 17/02/2011 2:16 PM, Steven Haigh wrote:
> Hi all,
>
> Firstly, please CC me in all replies as I am not a member of this list.
>
> I have been having an issue with quite a few of the fedora kernels in
> detecting drives on a sil3112 or sil3114 PCI card.
>
> When plugging in a SATA drive (I'm using an external esata drive for
> this test), I see the following appear in dmesg:
>
> [ 74.664034] ata10: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe
> frozen
> [ 74.664208] ata10: SError: { PHYRdyChg CommWake }
> [ 74.664310] ata10: hard resetting link
> [ 80.416870] ata10: link is slow to respond, please be patient (ready=-19)
> [ 81.789464] ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [ 81.789572] ata10.00: NODEV after polling detection
> [ 81.789593] ata10: EH complete
>
> No device is detected.
>
> This seems to occur if the drive is turned on after the machine is
> started, and when the system boots. I can see the drive in the card BIOS
> when the system starts if it is powered on after the drive has power.
>
> So far, I have tried the following kernel versions:
> 2.6.32.26-174.2.xendom0.fc12.x86_64
> 2.6.35.10-71.fc14.x86_64
> 2.6.35.11-83.fc14.x86_64
> 2.6.38-0.rc4.git0.2.fc15.x86_64
>
> If I move the internal SATA cable from the sil3112 or sil3114 card to
> the onboard SATA ports (detected as AHCI), then the drive is detected as
> it should and works perfectly.
>
> I have a current bug open for Fedora at:
> https://bugzilla.redhat.com/show_bug.cgi?id=677217
>
> The sil3114 that is currently installed seemed to work perfectly using
> CentOS 5.5 kernel (based on 2.6.18) - I am going to try and install
> CentOS to a different LV to confirm this shortly.
>
> Does anyone have any suggestions on this?
>

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.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

Re: sata-sil drive detection issues.

[Tejun Heo]

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;


-- 
tejun

Re: sata-sil drive detection issues.

[Steven Haigh]

 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

Re: sata-sil drive detection issues.

[Tejun Heo]

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.

-- 
tejun

Re: sata-sil drive detection issues.

[Steven Haigh]

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?

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

Re: sata-sil drive detection issues.

[Tejun Heo]

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.

-- 
tejun

Re: sata-sil drive detection issues.

[Steven Haigh]

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.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

Re: sata-sil drive detection issues.

[Tejun Heo]

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.

-- 
tejun

Re: sata-sil drive detection issues.

[Mark Lord]

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

Re: sata-sil drive detection issues.

[Steven Haigh]

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

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

Re: sata-sil drive detection issues.

[Mark Lord]

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?

Re: sata-sil drive detection issues.

[Mark Lord]

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.

Re: sata-sil drive detection issues.

[Steven Haigh]

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...

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299