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)
Guennadi Liakhovetski <[email protected]> wrote:
> 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
If the device is in AHCI mode it should match the ahci class entry - is
the device in AHCI mode or PIIX mode ?
On Thu, 28 Feb 2008, Alan Cox wrote:
> On Thu, 28 Feb 2008 23:37:36 +0100 (CET)
> Guennadi Liakhovetski <[email protected]> wrote:
>
> > 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
>
> If the device is in AHCI mode it should match the ahci class entry - is
> the device in AHCI mode or PIIX mode ?
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
On 2008/02/28 22:56 (GMT) Alan Cox apparently typed:
> 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/
>> is the device in AHCI mode or PIIX mode ?
>
>How does one tell for sure? BIOS typically only say things
>like "compatible"
>or "enhanced".
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
Guennadi Liakhovetski wrote:
> 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?
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
it always like that?
> 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.
1.00 is port 1 device 00 and UDMA numbers don't mean much to SATA devices.
Thanks.
--
tejun
On Thu, 6 Mar 2008, Tejun Heo wrote:
> Guennadi Liakhovetski wrote:
> > 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?
>
> If you hotplugged it, sometimes drives don't respond too well and takes
> a few retries to talk to it.
I've seen this messages both on cold- and hot-plug.
> How long did the whole thing take?
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 generic sg2 type 0
Looks like almost a minute to me? On another occurence I see about 1.5
minutes, then "port is slow to respond, please be patient (Status 0x80)"
has been repeated 3 times. On cold-plug also 3 times, I think, about the
same time then (time is not updated in the log).
> And is it always like that?
So far - yes.
> > 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.
>
> 1.00 is port 1 device 00 and UDMA numbers don't mean much to SATA devices.
Sorry, I actually meant to ask what "UDMA/133" means for a SATA link?
Thanks
Guennadi
---
Guennadi Liakhovetski
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of Guennadi
>Liakhovetski
>Sent: Thursday, March 06, 2008 3:58 AM
>To: Tejun Heo
>Cc: Alan Cox; [email protected]; Jeff Garzik;
>[email protected]
>Subject: Re: Unknown SATA PIIX PCI device ID 0x29b6
>
>On Thu, 6 Mar 2008, Tejun Heo wrote:
>
>> Guennadi Liakhovetski wrote:
>> > 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?
>>
>> If you hotplugged it, sometimes drives don't respond too
>well and takes
>> a few retries to talk to it.
>
>I've seen this messages both on cold- and hot-plug.
>
>> How long did the whole thing take?
>
>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 generic sg2 type 0
>
>Looks like almost a minute to me? On another occurence I see about 1.5
>minutes, then "port is slow to respond, please be patient
>(Status 0x80)"
>has been repeated 3 times. On cold-plug also 3 times, I think,
>about the
>same time then (time is not updated in the log).
>
>> And is it always like that?
>
>So far - yes.
>
>> > 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.
>>
>> 1.00 is port 1 device 00 and UDMA numbers don't mean much to
>SATA devices.
>
>Sorry, I actually meant to ask what "UDMA/133" means for a SATA link?
>
>Thanks
>Guennadi
>---
>Guennadi Liakhovetski
>--
>To unsubscribe from this list: send the line "unsubscribe linux-ide" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
If you disable the IDE Redirection in BIOS on that system, the 0x29b6
controller should not appear. If you are not using this, it would be
interesting to see if this effects what you are seeing.
Jason
Gaston, Jason D wrote:
> If you disable the IDE Redirection in BIOS on that system, the 0x29b6
> controller should not appear. If you are not using this, it would be
> interesting to see if this effects what you are seeing.
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
On Thu, 6 Mar 2008, Jeff Garzik wrote:
> Gaston, Jason D wrote:
> > If you disable the IDE Redirection in BIOS on that system, the 0x29b6
> > controller should not appear. If you are not using this, it would be
> > interesting to see if this effects what you are seeing.
>
> 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...?
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
Guennadi Liakhovetski wrote:
> 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)
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
long. Hmmm.. maybe it's having problem establishing link at 3Gbps.
> Looks like almost a minute to me? On another occurence I see about 1.5
> minutes, then "port is slow to respond, please be patient (Status 0x80)"
> has been repeated 3 times. On cold-plug also 3 times, I think, about the
> same time then (time is not updated in the log).
I see. Does the attached patch make any difference?
>> And is it always like that?
>
> So far - yes.
>
>>> 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.
>> 1.00 is port 1 device 00 and UDMA numbers don't mean much to SATA devices.
>
> Sorry, I actually meant to ask what "UDMA/133" means for a SATA link?
That doesn't really mean much to native SATA devices. That's just
something we're carrying over from PATA days.
Thanks.
--
tejun
On Fri, 7 Mar 2008, Tejun Heo wrote:
> > Looks like almost a minute to me? On another occurence I see about 1.5
> > minutes, then "port is slow to respond, please be patient (Status 0x80)"
> > has been repeated 3 times. On cold-plug also 3 times, I think, about the
> > same time then (time is not updated in the log).
>
> I see. Does the attached patch make any difference?
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
Guennadi Liakhovetski wrote:
> On Fri, 7 Mar 2008, Tejun Heo wrote:
>
>>> Looks like almost a minute to me? On another occurence I see about 1.5
>>> minutes, then "port is slow to respond, please be patient (Status 0x80)"
>>> has been repeated 3 times. On cold-plug also 3 times, I think, about the
>>> same time then (time is not updated in the log).
>> I see. Does the attached patch make any difference?
>
> 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"?
Yeap, you can do that. Wasn't sure you were using .25-rc or .24.
Thanks.
--
tejun
On Sun, 9 Mar 2008, Tejun Heo wrote:
> Guennadi Liakhovetski wrote:
> > On Fri, 7 Mar 2008, Tejun Heo wrote:
> >
> >>> Looks like almost a minute to me? On another occurence I see about 1.5
> >>> minutes, then "port is slow to respond, please be patient (Status 0x80)"
> >>> has been repeated 3 times. On cold-plug also 3 times, I think, about the
> >>> same time then (time is not updated in the log).
> >> I see. Does the attached patch make any difference?
> >
> > 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"?
>
> Yeap, you can do that. Wasn't sure you were using .25-rc or .24.
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
Guennadi Liakhovetski wrote:
> On Sun, 9 Mar 2008, Tejun Heo wrote:
>
>> Guennadi Liakhovetski wrote:
>>> On Fri, 7 Mar 2008, Tejun Heo wrote:
>>>
>>>>> Looks like almost a minute to me? On another occurence I see about 1.5
>>>>> minutes, then "port is slow to respond, please be patient (Status 0x80)"
>>>>> has been repeated 3 times. On cold-plug also 3 times, I think, about the
>>>>> same time then (time is not updated in the log).
>>>> I see. Does the attached patch make any difference?
>>> 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"?
>> Yeap, you can do that. Wasn't sure you were using .25-rc or .24.
>
> 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.
How about cold plugging?
--
tejun
On Mon, 10 Mar 2008, Tejun Heo wrote:
> > 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.
>
> How about cold plugging?
Same.
Thanks
Guennadi
---
Guennadi Liakhovetski
---
drivers/ata/ahci.c | 1 +
1 file changed, 1 insertion(+)
Index: tree2/drivers/ata/ahci.c
===================================================================
--- tree2.orig/drivers/ata/ahci.c
+++ tree2/drivers/ata/ahci.c
@@ -397,6 +397,7 @@ static const struct ata_port_operations
static const struct ata_port_info ahci_port_info[] = {
/* board_ahci */
{
+ AHCI_HFLAGS (AHCI_HFLAG_NO_PMP),
.flags = AHCI_FLAG_COMMON,
.link_flags = AHCI_LFLAG_COMMON,
.pio_mask = 0x1f, /* pio0-4 */
On Mon, 10 Mar 2008, Tejun Heo wrote:
> Guennadi Liakhovetski wrote:
> > On Mon, 10 Mar 2008, Tejun Heo wrote:
> >
> >>> 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.
> >> How about cold plugging?
> >
> > Same.
>
> Does the attached patch help?
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,
Guennadi Liakhovetski wrote:
> 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?
Not really. :-P
> 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.
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
On Tue, 11 Mar 2008, Tejun Heo wrote:
> Hello,
>
> Guennadi Liakhovetski wrote:
> > 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?
>
> Not really. :-P
>
> > 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.
>
> 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.
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,
Guennadi Liakhovetski wrote:
>> Guennadi Liakhovetski wrote:
>>> 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?
>> Not really. :-P
>>
>>> 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.
>> 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.
>
> 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.
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