Hi

just found out that the eSATA connector on my Intel DQ35JO motherboard 
doesn't work... because it is connected to the controller with product ID 
29b6... And this ID is not yet handled by the driver. Can I have a patch, 
please?:-) I think the correct entry would be

{ 0x8086, 0x29b6, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },

just because it also has two ports. Am I right? I would rather not test 
blindly.

BTW, why are these 2920, 2926, and 29b6 IDs not handled by the ahci 
driver? The board-manual does say ICH9...

Thanks
Guennadi
---
Guennadi Liakhovetski
--

On Thu, 28 Feb 2008 23:37:36 +0100 (CET)

If the device is in AHCI mode it should match the ahci class entry - is
the device in AHCI mode or PIIX mode ?

--

How does one tell for sure? BIOS typically only say things like "compatible"
or "enhanced".
-- 
"For God so loved the world that he gave his one
and only Son, that whoever believes in him shall
not perish but have eternal life." John 3:16 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://mrmazda.no-ip.com/
--

29b6 is the IDER, IDE Redirection, network device.  There there will not
be anything "locally" attached to that network device.  I have not been
adding the IDER Management devices to the ata_piix driver, perhaps I
should?   

When in doubt, about an unknown device, check the latest pci.ids file on
http://pciids.sf.net.  We try to keep it up to date.

Thanks,

Jason

--

Indeed! It was in "IDE" mode, and 2 out of the 3 chips were handled by the 
piix driver (btw, why did Intel put 3 different SATA controllers on one 
board?). I switched it to AHCI mode (the third possibility is RAID) and 
indeed a kernel with (only) ahci driver managed to bring them up! 
Although, the eSATA link was "slow to respond":

ata4: port is slow to respond, please be patient (Status 0x80)
ata4: softreset failed (device not ready)
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: softreset failed (device not ready)
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4.00: ATA-7: WDC WD1600BB-00RDA0, 20.00K20, max UDMA/100
ata4.00: 312581808 sectors, multi 16: LBA48
ata4.00: applying bridge limits
ata4.00: configured for UDMA/100

but then it did manage it. Is such a delay normal?

One more question, what do UDMA numbers mean in SATA context? The internal 
SATA disk is "ata1.00: configured for UDMA/133", but should be SATA-2.

Thanks
Guennadi
---
Guennadi Liakhovetski
--

If you hotplugged it, sometimes drives don't respond too well and takes
a few retries to talk to it.  How long did the whole thing take?  And is

1.00 is port 1 device 00 and UDMA numbers don't mean much to SATA devices.

Thanks.

-- 
tejun
--

Here's a hot-plug log:

Mar  4 15:04:28 6a kernel: ata4: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xa frozen
Mar  4 15:04:28 6a kernel: ata4: irq_stat 0x00000040, connection status changed
Mar  4 15:04:28 6a kernel: ata4: SError: { PHYRdyChg CommWake DevExch }Mar  4 15:04:28 6a kernel: ata4: hard resetting link
Mar  4 15:04:38 6a kernel: ata4: softreset failed (device not ready)
Mar  4 15:04:38 6a kernel: ata4: hard resetting link
Mar  4 15:04:48 6a kernel: ata4: softreset failed (device not ready)
Mar  4 15:04:48 6a kernel: ata4: hard resetting link
Mar  4 15:04:55 6a kernel: ata4: port is slow to respond, please be patient (Status 0x80)
Mar  4 15:05:20 6a kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mar  4 15:05:20 6a kernel: ata4.00: ATA-7: WDC WD1600BB-00RDA0, 20.00K20, max UDMA/100
Mar  4 15:05:20 6a kernel: ata4.00: 312581808 sectors, multi 0: LBA48
Mar  4 15:05:20 6a kernel: ata4.00: applying bridge limits
Mar  4 15:05:20 6a kernel: ata4.00: configured for UDMA/100
Mar  4 15:05:20 6a kernel: ata4: EH complete
Mar  4 15:05:20 6a kernel: scsi 3:0:0:0: Direct-Access     ATA      WDC WD1600BB-00R 20.0 PQ: 0 ANSI: 5
Mar  4 15:05:20 6a kernel: sd 3:0:0:0: [sdb] 312581808 512-byte hardware sectors (160042 MB)
Mar  4 15:05:20 6a kernel: sd 3:0:0:0: [sdb] Write Protect is off
Mar  4 15:05:20 6a kernel: sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Mar  4 15:05:20 6a kernel: sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar  4 15:05:20 6a kernel: sd 3:0:0:0: [sdb] 312581808 512-byte hardware sectors (160042 MB)
Mar  4 15:05:20 6a kernel: sd 3:0:0:0: [sdb] Write Protect is off
Mar  4 15:05:20 6a kernel: sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Mar  4 15:05:20 6a kernel: sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar  4 15:05:20 6a kernel:  sdb: sdb1 sdb2
Mar  4 15:05:20 6a kernel: sd 3:0:0:0: [sdb] Attached SCSI disk
Mar  4 15:05:20 6a kernel: sd 3:0:0:0: Attached scsi generi...
[ message continues ]

That's unusually long but if you look at the last reset try.  It began
at @48 and the device comes up after 32secs without the driver taking
further action, which might indicate that the device actually took that


That doesn't really mean much to native SATA devices.  That's just
something we're carrying over from PATA days.

Thanks.

-- 
tejun

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4fbcce7..abebdcc 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6712,6 +6712,7 @@ int sata_link_init_spd(struct ata_link *link)
 	spd = (scontrol >> 4) & 0xf;
 	if (spd)
 		link->hw_sata_spd_limit &= (1 << spd) - 1;
+	link->hw_sata_spd_limit = 1;
 
 	ata_force_spd_limit(link);
 
Hm, this would force 1.5Gbps on all ports and devices, right? Cannot I 
just boot with "libata.force=4:1.5Gbps"?

Thanks
Guennadi
---
Guennadi Liakhovetski
--

Yeap, you can do that.  Wasn't sure you were using .25-rc or .24.

Thanks.

-- 
tejun
--

Yctually it was 2.6.24 before, rebuilt 2.6.25-rc4, booted as above, it did 
say:

ata4: FORCE: PHY spd limit set to 1.5Gbps

but hot-plugging the drive still took 50 seconds to recover.

Thanks
Guennadi
---
Guennadi Liakhovetski
--

How about cold plugging?

-- 
tejun
--

Same.

Thanks
Guennadi
---
Guennadi Liakhovetski
--

Does the attached patch help?

-- 
tejun

Well, I am not sure, whether it helps, tried booting with both 1.5Gbps and 
this patch, it recovers now within 30 sec in both cold- and hot-plug 
cases. To really state, that it has improved from about 55 sec down to 30 
sec one would need more testing. Is this the kind of improvement you 
expected? Can it be, that with this hardware it just cannot get better? 
Remember, the disk is an external eSATA enclosure with a (relatively new) 
PATA disk inside.

Well, at least the hotplug case did recover faster this time. Not sure 
about coldplug, because in the logs all kernel messages come with the 
same time and I don't have printk timestamp on.

Thanks
Guennadi
---
Guennadi Liakhovetski
--

Hello,



Can you try out a shorter cable?  I had a lot of troubles with eSATA +
long cable + PMP combinations.  Using shorter cable usually solves the
problem for me.

-- 
tejun
--

Well, this cable is only about 50cm long, or even shorter, and using a 
shorter one would be difficult there, even if I manage to get hold of one. 
But, in principle, if this is not a generic ahci problem that needs to be 
solved, I personally can somehow live with it. Having to wait 1 minute is 
not very nice, but so far not critical.

Thanks for your help
Guennadi
---
Guennadi Liakhovetski
--

Hello,


50cm gotta be short enough.  For intel ahci, it definitely isn't a
general problem but it would still be nice if we can find out what's
going on but I don't have much idea what to do next.  I'll keep your
problem in mind and see whether any pattern emerges.  If you find out
something new, please let us know.

Thanks.

-- 
tejun
--

I think its fair to say that a certain amount of Linux users will 
inevitably have this option enabled in their BIOS.  We should have a 
plan to deal with this sanely...?

	Jeff


--

Sorry, I am afraid, I caused a bit of confusion here. 0x29b6 I had when 
BIOS configuration was set to "IDE". Then I couldn't use the 0x29b6 at 
all, and therefore couldn't access the external eSATA disk at all. Then I 
switched to AHCI, now all SATA hosts are on PCI ID 0x2922 and 0x29b6 is 
also there as an IDE host unused...

So, now BIOS is set to "AHCI", all SATA hosts - internal and external are 
on PCI ID 0x2922, and external needs a minute to start up, but then it 
works fine.

Thanks
Guennadi
---
Guennadi Liakhovetski
--