Re: SATA link power management issues
Hello, Gabriele.
On Tue, Apr 21, 2015 at 11:44:28PM +0200, Gabriele Mazzotta wrote:
> I haven't considered that possibility. Something like the following then?
Yeah, looks great. Some minor comments below.
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -1700,6 +1700,8 @@ static void ahci_handle_port_interrupt(struct ata_port
> *ap,
> struct ahci_port_priv *pp = ap->private_data;
> struct ahci_host_priv *hpriv = ap->host->private_data;
> int resetting = !!(ap->pflags & ATA_PFLAG_RESETTING);
> + unsigned long lpm_timeout = ap->link.last_lpm_change + 10 * HZ;
We prolly want to define the timeout as a constant symbol in libata.h
and explain what this is about.
> + int ignore_event = 0;
Use bool?
> @@ -1707,8 +1709,13 @@ static void ahci_handle_port_interrupt(struct ata_port
> *ap,
> if (unlikely(resetting))
> status &= ~PORT_IRQ_BAD_PMP;
>
> + if (time_before(jiffies, lpm_timeout) &&
> + (ap->link.flags & ATA_LFLAG_CHANGED))
> + ignore_event = 1;
Nothing major but testing LFLAG first would prolly be a better style
given that timeout value is relevant only while the flag is asserted
and some comment would be nice too.
> @@ -788,6 +789,8 @@ struct ata_link {
> struct ata_eh_context eh_context;
>
> struct ata_device device[ATA_MAX_DEVICES];
> +
> + unsigned long last_lpm_change;
A brief explanation would be nice.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Tuesday 21 April 2015 16:56:08 Tejun Heo wrote:
> Hello,
>
> On Tue, Apr 21, 2015 at 10:29:38PM +0200, Gabriele Mazzotta wrote:
> > Doing some quick tests I found that in some cases it takes 5 or 6
> > seconds for the first interrupt to arrive, so I'd have to use a quite
> > long interval to completely prevent errors.
>
> Hmm...
>
> > I am wondering if it would be better using my original solution
> > (i.e. ignore first event), but make it device specific given that it
> > might make no sense on other systems and seems to be more reliable than
> > the time-based one.
>
> I'm not sure. What if the extra PHY event isn't that reliable. It'd
> be pretty confusing if it ends up ignoring a legitimate PHY event
> after, say, two hours, so one way or the other, we'd need to cap how
> long we're gonna be ignoring the event. Ignore the first PHY event
> for 10s after LPM state change?
I haven't considered that possibility. Something like the following then?
---
drivers/ata/libahci.c | 9 -
drivers/ata/libata-eh.c | 3 +++
include/linux/libata.h | 3 +++
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 61a9c07..452c8f9 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -1700,6 +1700,8 @@ static void ahci_handle_port_interrupt(struct ata_port
*ap,
struct ahci_port_priv *pp = ap->private_data;
struct ahci_host_priv *hpriv = ap->host->private_data;
int resetting = !!(ap->pflags & ATA_PFLAG_RESETTING);
+ unsigned long lpm_timeout = ap->link.last_lpm_change + 10 * HZ;
+ int ignore_event = 0;
u32 qc_active = 0;
int rc;
@@ -1707,8 +1709,13 @@ static void ahci_handle_port_interrupt(struct ata_port
*ap,
if (unlikely(resetting))
status &= ~PORT_IRQ_BAD_PMP;
+ if (time_before(jiffies, lpm_timeout) &&
+ (ap->link.flags & ATA_LFLAG_CHANGED))
+ ignore_event = 1;
+
/* if LPM is enabled, PHYRDY doesn't mean anything */
- if (ap->link.lpm_policy > ATA_LPM_MAX_POWER) {
+ if (ap->link.lpm_policy > ATA_LPM_MAX_POWER || ignore_event) {
+ ap->link.flags &= ~ATA_LFLAG_CHANGED;
status &= ~PORT_IRQ_PHYRDY;
ahci_scr_write(&ap->link, SCR_ERROR, SERR_PHYRDY_CHG);
}
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 07f41be..cf0022e 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -3597,6 +3597,9 @@ static int ata_eh_set_lpm(struct ata_link *link, enum
ata_lpm_policy policy,
}
}
+ link->last_lpm_change = jiffies;
+ link->flags |= ATA_LFLAG_CHANGED;
+
return 0;
fail:
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 8dad4a3..c30c7aa 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -205,6 +205,7 @@ enum {
ATA_LFLAG_SW_ACTIVITY = (1 << 7), /* keep activity stats */
ATA_LFLAG_NO_LPM= (1 << 8), /* disable LPM on this link */
ATA_LFLAG_RST_ONCE = (1 << 9), /* limit recovery to one reset */
+ ATA_LFLAG_CHANGED = (1 << 10), /* LPM state changed on this link
*/
/* struct ata_port flags */
ATA_FLAG_SLAVE_POSS = (1 << 0), /* host supports slave dev */
@@ -788,6 +789,8 @@ struct ata_link {
struct ata_eh_context eh_context;
struct ata_device device[ATA_MAX_DEVICES];
+
+ unsigned long last_lpm_change;
};
#define ATA_LINK_CLEAR_BEGIN offsetof(struct ata_link, active_tag)
#define ATA_LINK_CLEAR_END offsetof(struct ata_link, device[0])
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
Hello, On Tue, Apr 21, 2015 at 10:29:38PM +0200, Gabriele Mazzotta wrote: > Doing some quick tests I found that in some cases it takes 5 or 6 > seconds for the first interrupt to arrive, so I'd have to use a quite > long interval to completely prevent errors. Hmm... > I am wondering if it would be better using my original solution > (i.e. ignore first event), but make it device specific given that it > might make no sense on other systems and seems to be more reliable than > the time-based one. I'm not sure. What if the extra PHY event isn't that reliable. It'd be pretty confusing if it ends up ignoring a legitimate PHY event after, say, two hours, so one way or the other, we'd need to cap how long we're gonna be ignoring the event. Ignore the first PHY event for 10s after LPM state change? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Tuesday 21 April 2015 11:31:21 Tejun Heo wrote: > On Mon, Apr 20, 2015 at 10:02:12PM +0200, Gabriele Mazzotta wrote: > > On Sunday 22 February 2015 21:53:35 Gabriele Mazzotta wrote: > > > It seems that the following patch prevents errors when the policy is > > > changed. Could anybody explain why? > > The device is generating a spurious PHY event after LPM state change > and the patch is ignoring the event once after state change. It's a > bit too specific. Maybe we should do this timeout-based - e.g. ignore > phy events for 1s after LPM state change. Gabriele, would be > interested in making such changes? Thanks for the explanation and yes, I am interested. Doing some quick tests I found that in some cases it takes 5 or 6 seconds for the first interrupt to arrive, so I'd have to use a quite long interval to completely prevent errors. I am wondering if it would be better using my original solution (i.e. ignore first event), but make it device specific given that it might make no sense on other systems and seems to be more reliable than the time-based one. Gabriele -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Mon, Apr 20, 2015 at 10:02:12PM +0200, Gabriele Mazzotta wrote: > On Sunday 22 February 2015 21:53:35 Gabriele Mazzotta wrote: > > It seems that the following patch prevents errors when the policy is > > changed. Could anybody explain why? The device is generating a spurious PHY event after LPM state change and the patch is ignoring the event once after state change. It's a bit too specific. Maybe we should do this timeout-based - e.g. ignore phy events for 1s after LPM state change. Gabriele, would be interested in making such changes? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Sunday 22 February 2015 21:53:35 Gabriele Mazzotta wrote:
> Hi,
>
> It seems that the following patch prevents errors when the policy is
> changed. Could anybody explain why?
>
> Thanks,
> Gabriele
>
> diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> index 61a9c07..38d39f7 100644
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -1708,7 +1708,10 @@ static void ahci_handle_port_interrupt(struct ata_port
> *ap,
> status &= ~PORT_IRQ_BAD_PMP;
>
> /* if LPM is enabled, PHYRDY doesn't mean anything */
> - if (ap->link.lpm_policy > ATA_LPM_MAX_POWER) {
> + if (ap->link.lpm_policy > ATA_LPM_MAX_POWER ||
> + ap->link.flags & ATA_LFLAG_CHANGED) {
> + if (ap->link.flags & ATA_LFLAG_CHANGED)
> + ap->link.flags &= ~ATA_LFLAG_CHANGED;
> status &= ~PORT_IRQ_PHYRDY;
> ahci_scr_write(&ap->link, SCR_ERROR, SERR_PHYRDY_CHG);
> }
> diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
> index d2029a4..e8f965c 100644
> --- a/drivers/ata/libata-eh.c
> +++ b/drivers/ata/libata-eh.c
> @@ -3489,6 +3489,8 @@ static int ata_eh_set_lpm(struct ata_link *link, enum
> ata_lpm_policy policy,
> }
> }
>
> + link->flags |= ATA_LFLAG_CHANGED;
> +
> return 0;
>
> fail:
> diff --git a/include/linux/libata.h b/include/linux/libata.h
> index fc03efa..5abf5f2 100644
> --- a/include/linux/libata.h
> +++ b/include/linux/libata.h
> @@ -205,6 +205,7 @@ enum {
> ATA_LFLAG_SW_ACTIVITY = (1 << 7), /* keep activity stats */
> ATA_LFLAG_NO_LPM= (1 << 8), /* disable LPM on this link */
> ATA_LFLAG_RST_ONCE = (1 << 9), /* limit recovery to one reset */
> + ATA_LFLAG_CHANGED = (1 << 10),
>
> /* struct ata_port flags */
> ATA_FLAG_SLAVE_POSS = (1 << 0), /* host supports slave dev */
Hi,
did anyone looked at the above change?
Thanks,
Gabriele
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
Hi,
It seems that the following patch prevents errors when the policy is
changed. Could anybody explain why?
Thanks,
Gabriele
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 61a9c07..38d39f7 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -1708,7 +1708,10 @@ static void ahci_handle_port_interrupt(struct ata_port
*ap,
status &= ~PORT_IRQ_BAD_PMP;
/* if LPM is enabled, PHYRDY doesn't mean anything */
- if (ap->link.lpm_policy > ATA_LPM_MAX_POWER) {
+ if (ap->link.lpm_policy > ATA_LPM_MAX_POWER ||
+ ap->link.flags & ATA_LFLAG_CHANGED) {
+ if (ap->link.flags & ATA_LFLAG_CHANGED)
+ ap->link.flags &= ~ATA_LFLAG_CHANGED;
status &= ~PORT_IRQ_PHYRDY;
ahci_scr_write(&ap->link, SCR_ERROR, SERR_PHYRDY_CHG);
}
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index d2029a4..e8f965c 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -3489,6 +3489,8 @@ static int ata_eh_set_lpm(struct ata_link *link, enum
ata_lpm_policy policy,
}
}
+ link->flags |= ATA_LFLAG_CHANGED;
+
return 0;
fail:
diff --git a/include/linux/libata.h b/include/linux/libata.h
index fc03efa..5abf5f2 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -205,6 +205,7 @@ enum {
ATA_LFLAG_SW_ACTIVITY = (1 << 7), /* keep activity stats */
ATA_LFLAG_NO_LPM= (1 << 8), /* disable LPM on this link */
ATA_LFLAG_RST_ONCE = (1 << 9), /* limit recovery to one reset */
+ ATA_LFLAG_CHANGED = (1 << 10),
/* struct ata_port flags */
ATA_FLAG_SLAVE_POSS = (1 << 0), /* host supports slave dev */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
I just tried the following and I no longer get errors:
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 97683e4..c815b31 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -1708,10 +1708,10 @@ static void ahci_handle_port_interrupt(struct ata_port
*ap,
status &= ~PORT_IRQ_BAD_PMP;
/* if LPM is enabled, PHYRDY doesn't mean anything */
- if (ap->link.lpm_policy > ATA_LPM_MAX_POWER) {
+// if (ap->link.lpm_policy > ATA_LPM_MAX_POWER) {
status &= ~PORT_IRQ_PHYRDY;
ahci_scr_write(&ap->link, SCR_ERROR, SERR_PHYRDY_CHG);
- }
+// }
if (unlikely(status & PORT_IRQ_ERROR)) {
ahci_error_intr(ap, status);
I haven't read the specification, so this might be bad. I did this in
base of some consideration I made that, as far as I know, could be
completely wrong. I hope you can get something meaningful out of this.
Gabriele
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Tuesday 13 January 2015 02:17:00 Suman Tripathi wrote:
> Hi,
>
> On Tuesday 13 January 2015 02:00:45 Suman Tripathi wrote:
> > On Monday 12 January 2015 22:46:02 Suman Tripathi wrote:
> > > Can you dump the ata_id parameters(LPM section) from the drive and we
> > > can check the related LPM parameters of the drive ?
> >
> > Hi,
> >
> > I'm sorry, but I'm not really familiar with ata, could you be a bit
> > more specific about what you'd like to see?
> > ok no issues. First can show the log from the point the drive got
> > enumerated ? Like for eg :
> > ata2.00: ATA-8: WDC WD5000AAKX-08U6AA0, 19.01H19, max UDMA/100
> >
> > ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
> >
> > ata2.00: configured for UDMA/100
> >
> > I would like to the ATA version the drive is complaint. In the above case
> > it is ATA-8
>
> [0.698842] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [0.701419] ata3.00: ATA-8: LITEONIT LMT-256M6M mSATA 256GB, DM8110F,
> max UDMA/133
> [0.701421] ata3.00: 500118192 sectors, multi 1: LBA48 NCQ (depth
> 31/32), AA
> [0.701982] ata3.00: configured for UDMA/133
>
> You can see the entire log here:
> http://www.spinics.net/lists/linux-ide/msg50069.html
>
> Can you try the below fix ? In the libata-core.c
Tried, unfortunately it does not solve the problem. I no longer get
"ahci :00:1f.2: port does not support device sleep"
[ 60.170199] ata3.00: exception Emask 0x10 SAct 0x2000 SErr 0x5 action
0xe frozen
[ 60.170209] ata3.00: irq_stat 0x0040, PHY RDY changed
[ 60.170215] ata3: SError: { PHYRdyChg CommWake }
[ 60.170221] ata3.00: failed command: WRITE FPDMA QUEUED
[ 60.170231] ata3.00: cmd 61/01:68:01:08:00/00:00:00:00:00/40 tag 13 ncq 512
out
res 40/00:6c:01:08:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
[ 60.170236] ata3.00: status: { DRDY }
[ 60.170244] ata3: hard resetting link
[ 60.894728] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 60.897672] ata3.00: configured for UDMA/133
[ 60.910690] ata3: EH complete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Tuesday 13 January 2015 02:00:45 Suman Tripathi wrote: > On Monday 12 January 2015 22:46:02 Suman Tripathi wrote: > > Can you dump the ata_id parameters(LPM section) from the drive and we > > can check the related LPM parameters of the drive ? > > Hi, > > I'm sorry, but I'm not really familiar with ata, could you be a bit > more specific about what you'd like to see? > ok no issues. First can show the log from the point the drive got > enumerated ? Like for eg : > ata2.00: ATA-8: WDC WD5000AAKX-08U6AA0, 19.01H19, max UDMA/100 > > ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32) > > ata2.00: configured for UDMA/100 > > I would like to the ATA version the drive is complaint. In the above case > it is ATA-8 [0.698842] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [0.701419] ata3.00: ATA-8: LITEONIT LMT-256M6M mSATA 256GB, DM8110F, max UDMA/133 [0.701421] ata3.00: 500118192 sectors, multi 1: LBA48 NCQ (depth 31/32), AA [0.701982] ata3.00: configured for UDMA/133 You can see the entire log here: http://www.spinics.net/lists/linux-ide/msg50069.html > > Thanks, > Gabriele > > On Tue, Jan 13, 2015 at 1:56 AM, Gabriele Mazzotta > wrote: > > > On Monday 12 January 2015 22:46:02 Suman Tripathi wrote: > > > Can you dump the ata_id parameters(LPM section) from the drive and we > > > can check the related LPM parameters of the drive ? > > > > Hi, > > > > I'm sorry, but I'm not really familiar with ata, could you be a bit > > more specific about what you'd like to see? > > > > Thanks, > > Gabriele > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Monday 12 January 2015 22:46:02 Suman Tripathi wrote: > Can you dump the ata_id parameters(LPM section) from the drive and we > can check the related LPM parameters of the drive ? Hi, I'm sorry, but I'm not really familiar with ata, could you be a bit more specific about what you'd like to see? Thanks, Gabriele -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
Can you dump the ata_id parameters(LPM section) from the drive and we
can check the related LPM parameters of the drive ?
On Mon, Jan 12, 2015 at 10:42 PM, Suman Tripathi wrote:
> Hi,
>
> I'm having some problems with the link_power_management_policy on my
> Dell XPS13 9333.
> Changing policy from min_power or medium_power to max_performance
> causes the following errors:
>
> [ 3955.667086] ahci :00:1f.2: port does not support device sleep
> [ 3958.257106] ata3.00: exception Emask 0x10 SAct 0x40 SErr 0x5 action
> 0xe frozen
> [ 3958.257110] ata3.00: irq_stat 0x0040, PHY RDY changed
> [ 3958.257113] ata3: SError: { PHYRdyChg CommWake }
> [ 3958.257116] ata3.00: failed command: READ FPDMA QUEUED
> [ 3958.257120] ata3.00: cmd 60/00:30:c8:60:10/01:00:1d:00:00/40 tag 6 ncq
> 131072 in
> res 40/00:34:c8:60:10/00:00:1d:00:00/40 Emask 0x10 (ATA bus error)
> [ 3958.257122] ata3.00: status: { DRDY }
> [ 3958.257126] ata3: hard resetting link
> [ 3958.981727] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [ 3958.984994] ata3.00: configured for UDMA/133
> [ 3958.997686] ahci :00:1f.2: port does not support device sleep
> [ 3958.997698] ata3: EH complete
>
> Sometimes I get "failed command: WRITE FPDMA QUEUED" multiple times.
>
> As far as I know, this had always happened and it was confirmed
> by another user. I've also come across some logs of the same system
> and saw the same errors here and there, so it shouldn't be a problem
> of my laptop in particular.
>
> What I find interesting is that transitions from min_power to
> medium_power and vice versa do not cause these errors. There are only
> problem switching from min_power and medium_power to max_performance.
> Doing the opposite, i.e. from max_performance to min_power or
> medium_power, seems to work fine.
>
> As a consequence of these continuous errors, the speed is reduced
> from 6.0 Gbps to 1.5 Gbps.
>
> I'd prefer not to disable LPM as it saves a considerable amount of
> power when I'm using the battery. For this reason I'm currently using
> medium_power and min_power only to prevent errors.
>
> Is it normal that these errors appears only when I switch to
> max_performance? Was something similar observed on other systems?
> Can you dump the ata_id parameters(LPM section) from the drive and we can
> check the related LPM parameters of the drive ?
>
> Thanks,
> Gabriele
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> On Fri, Jan 9, 2015 at 1:07 AM, Gabriele Mazzotta
> wrote:
>>
>> Hi,
>>
>> I'm having some problems with the link_power_management_policy on my
>> Dell XPS13 9333.
>> Changing policy from min_power or medium_power to max_performance
>> causes the following errors:
>>
>> [ 3955.667086] ahci :00:1f.2: port does not support device sleep
>> [ 3958.257106] ata3.00: exception Emask 0x10 SAct 0x40 SErr 0x5 action
>> 0xe frozen
>> [ 3958.257110] ata3.00: irq_stat 0x0040, PHY RDY changed
>> [ 3958.257113] ata3: SError: { PHYRdyChg CommWake }
>> [ 3958.257116] ata3.00: failed command: READ FPDMA QUEUED
>> [ 3958.257120] ata3.00: cmd 60/00:30:c8:60:10/01:00:1d:00:00/40 tag 6 ncq
>> 131072 in
>> res 40/00:34:c8:60:10/00:00:1d:00:00/40 Emask 0x10 (ATA bus
>> error)
>> [ 3958.257122] ata3.00: status: { DRDY }
>> [ 3958.257126] ata3: hard resetting link
>> [ 3958.981727] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
>> [ 3958.984994] ata3.00: configured for UDMA/133
>> [ 3958.997686] ahci :00:1f.2: port does not support device sleep
>> [ 3958.997698] ata3: EH complete
>>
>> Sometimes I get "failed command: WRITE FPDMA QUEUED" multiple times.
>>
>> As far as I know, this had always happened and it was confirmed
>> by another user. I've also come across some logs of the same system
>> and saw the same errors here and there, so it shouldn't be a problem
>> of my laptop in particular.
>>
>> What I find interesting is that transitions from min_power to
>> medium_power and vice versa do not cause these errors. There are only
>> problem switching from min_power and medium_power to max_performance.
>> Doing the opposite, i.e. from max_performance to min_power or
>> medium_power, seems to work fine.
>>
>> As a consequence of these continuous errors, the speed is reduced
>> from 6.0 Gbps to 1.5 Gbps.
>>
>> I'd prefer not to disable LPM as it saves a considerable amount of
>> power when I'm using the battery. For this reason I'm currently using
>> medium_power and min_power only to prevent errors.
>>
>> Is it normal that these errors appears only when I switch to
>> max_performance? Was something similar observed on other systems?
>>
>> Thanks,
>> Gabriele
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo
Re: SATA link power management issues
On Monday 12 January 2015 12:07:34 Tejun Heo wrote:
> Hello, Gabriele.
>
> On Mon, Jan 12, 2015 at 06:03:41PM +0100, Gabriele Mazzotta wrote:
> > I tried it and got the same result:
> >
> > [ 451.077463] ahci :00:1f.2: port does not support device sleep
> > [ 452.162451] ata3.00: exception Emask 0x10 SAct 0x400 SErr 0x5 action
> > 0xe frozen
> > [ 452.162461] ata3.00: irq_stat 0x0048, PHY RDY changed
> > [ 452.162467] ata3: SError: { PHYRdyChg CommWake }
> > [ 452.162473] ata3.00: failed command: WRITE FPDMA QUEUED
> > [ 452.162484] ata3.00: cmd 61/58:50:98:7c:4b/00:00:17:00:00/40 tag 10 ncq
> > 45056 out
> > res 40/00:54:98:7c:4b/00:00:17:00:00/40 Emask 0x10 (ATA bus error)
> > [ 452.162489] ata3.00: status: { DRDY }
> > [ 452.162497] ata3: hard resetting link
> > [ 452.886958] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> > [ 452.890384] ata3.00: configured for UDMA/133
> > [ 452.902976] ahci :00:1f.2: port does not support device sleep
> > [ 452.903002] ata3: EH complete
>
> Hah, that's weird. Can you please double check that you're actually
> running the patched kernel by throwing in a printk around the
> commented out section? If leaving phy irqs turned off doesn't make
> the problem go away, I'm not sure there's much we can do. Hmmm... one
> option could be holding off speed-down verdict after LPM state
> transition, but it looks like the ssd in question is misbehaving
> pretty badly.
>
> Thanks.
Done:
[ 168.515793] ahci :00:1f.2: port does not support device sleep
[ 168.515800] Skip turn PHYRDY IRQ back on
[ 168.515802] turn PHYRDY IRQ back on skipped
[ 168.523793] ata3.00: exception Emask 0x10 SAct 0x40 SErr 0x5 action 0xe
frozen
[ 168.523798] ata3.00: irq_stat 0x0048, PHY RDY changed
[ 168.523801] ata3: SError: { PHYRdyChg CommWake }
[ 168.523805] ata3.00: failed command: WRITE FPDMA QUEUED
[ 168.523811] ata3.00: cmd 61/28:30:68:60:4b/00:00:17:00:00/40 tag 6 ncq 20480
out
res 40/00:34:68:60:4b/00:00:17:00:00/40 Emask 0x10 (ATA bus error)
[ 168.523814] ata3.00: status: { DRDY }
[ 168.523819] ata3: hard resetting link
[ 169.248384] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 169.251661] ata3.00: configured for UDMA/133
[ 169.264293] ahci :00:1f.2: port does not support device sleep
[ 169.264299] Skip turn PHYRDY IRQ back on
[ 169.264301] turn PHYRDY IRQ back on skipped
[ 169.264315] ata3: EH complete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
Hello, Gabriele.
On Mon, Jan 12, 2015 at 06:03:41PM +0100, Gabriele Mazzotta wrote:
> I tried it and got the same result:
>
> [ 451.077463] ahci :00:1f.2: port does not support device sleep
> [ 452.162451] ata3.00: exception Emask 0x10 SAct 0x400 SErr 0x5 action
> 0xe frozen
> [ 452.162461] ata3.00: irq_stat 0x0048, PHY RDY changed
> [ 452.162467] ata3: SError: { PHYRdyChg CommWake }
> [ 452.162473] ata3.00: failed command: WRITE FPDMA QUEUED
> [ 452.162484] ata3.00: cmd 61/58:50:98:7c:4b/00:00:17:00:00/40 tag 10 ncq
> 45056 out
> res 40/00:54:98:7c:4b/00:00:17:00:00/40 Emask 0x10 (ATA bus error)
> [ 452.162489] ata3.00: status: { DRDY }
> [ 452.162497] ata3: hard resetting link
> [ 452.886958] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [ 452.890384] ata3.00: configured for UDMA/133
> [ 452.902976] ahci :00:1f.2: port does not support device sleep
> [ 452.903002] ata3: EH complete
Hah, that's weird. Can you please double check that you're actually
running the patched kernel by throwing in a printk around the
commented out section? If leaving phy irqs turned off doesn't make
the problem go away, I'm not sure there's much we can do. Hmmm... one
option could be holding off speed-down verdict after LPM state
transition, but it looks like the ssd in question is misbehaving
pretty badly.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Monday 12 January 2015 08:16:02 Tejun Heo wrote:
> Hello,
>
> What you're experiencing looks like the ssd behaving badly after link
> state transition. I wonder whether the right solution is plugging
> PHYRDY IRQ for a while after LPM state change. Does the following
> path make any difference?
>
> Thanks.
>
> diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> index 97683e4..684f45d 100644
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -735,8 +735,8 @@ static int ahci_set_lpm(struct ata_link *link, enum
> ata_lpm_policy policy,
> sata_link_scr_lpm(link, policy, false);
>
> /* turn PHYRDY IRQ back on */
> - pp->intr_mask |= PORT_IRQ_PHYRDY;
> - writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK);
> + //pp->intr_mask |= PORT_IRQ_PHYRDY;
> + //writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK);
> }
>
> return 0;
Hi,
I tried it and got the same result:
[ 451.077463] ahci :00:1f.2: port does not support device sleep
[ 452.162451] ata3.00: exception Emask 0x10 SAct 0x400 SErr 0x5 action 0xe
frozen
[ 452.162461] ata3.00: irq_stat 0x0048, PHY RDY changed
[ 452.162467] ata3: SError: { PHYRdyChg CommWake }
[ 452.162473] ata3.00: failed command: WRITE FPDMA QUEUED
[ 452.162484] ata3.00: cmd 61/58:50:98:7c:4b/00:00:17:00:00/40 tag 10 ncq
45056 out
res 40/00:54:98:7c:4b/00:00:17:00:00/40 Emask 0x10 (ATA bus error)
[ 452.162489] ata3.00: status: { DRDY }
[ 452.162497] ata3: hard resetting link
[ 452.886958] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 452.890384] ata3.00: configured for UDMA/133
[ 452.902976] ahci :00:1f.2: port does not support device sleep
[ 452.903002] ata3: EH complete
Gabriele
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
Hello, What you're experiencing looks like the ssd behaving badly after link state transition. I wonder whether the right solution is plugging PHYRDY IRQ for a while after LPM state change. Does the following path make any difference? Thanks. diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c index 97683e4..684f45d 100644 --- a/drivers/ata/libahci.c +++ b/drivers/ata/libahci.c @@ -735,8 +735,8 @@ static int ahci_set_lpm(struct ata_link *link, enum ata_lpm_policy policy, sata_link_scr_lpm(link, policy, false); /* turn PHYRDY IRQ back on */ - pp->intr_mask |= PORT_IRQ_PHYRDY; - writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK); + //pp->intr_mask |= PORT_IRQ_PHYRDY; + //writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK); } return 0; -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Friday 09 January 2015 17:02:53 Tejun Heo wrote:
> On Fri, Jan 09, 2015 at 05:00:18PM -0500, Tejun Heo wrote:
> > It's not normal. It definitely doesn't happen with all devices. I
> > guess it could be a quirk from the device side. What's on the other
> > side of the connector? Can you post the full kernel log after such
> > incidence?
>
> What happens if you comment out the DIPM part of ata_eh_set_lpm() -
> the first ata_for_each_dev() loop in the function?
I commented the first loop and something seems to have changed.
I was able to get back to max_performance with no errors once, but
most of the times I get errors.
The last policy change here below went fine for instance:
[ 32.368603] setting min_power
[ 32.368670] ahci :00:1f.2: port does not support device sleep
[ 38.550840] setting max_performance
[ 38.564932] ahci :00:1f.2: port does not support device sleep
[ 38.579716] ata3: exception Emask 0x10 SAct 0x0 SErr 0x5 action 0xe
frozen
[ 38.579722] ata3: irq_stat 0x0040, PHY RDY changed
[ 38.579726] ata3: SError: { PHYRdyChg CommWake }
[ 38.579731] ata3: hard resetting link
[ 39.301543] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 39.304783] ata3.00: configured for UDMA/133
[ 39.317499] ahci :00:1f.2: port does not support device sleep
[ 39.317509] ata3: EH complete
[ 46.412652] setting min_power
[ 46.412769] ahci :00:1f.2: port does not support device sleep
[ 53.869869] setting max_performance
[ 53.885083] ahci :00:1f.2: port does not support device sleep
[ 53.898857] ata3: exception Emask 0x10 SAct 0x0 SErr 0x5 action 0xe
frozen
[ 53.898865] ata3: irq_stat 0x0040, PHY RDY changed
[ 53.898870] ata3: SError: { PHYRdyChg CommWake }
[ 53.898877] ata3: hard resetting link
[ 54.621720] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 54.624864] ata3.00: configured for UDMA/133
[ 54.637674] ahci :00:1f.2: port does not support device sleep
[ 54.637680] ata3: EH complete
[ 58.837307] setting min_power
[ 58.837427] ahci :00:1f.2: port does not support device sleep
[ 63.269078] setting max_performance
[ 63.284571] ahci :00:1f.2: port does not support device sleep
[ 63.297954] ata3: exception Emask 0x10 SAct 0x0 SErr 0x5 action 0xe
frozen
[ 63.297958] ata3: irq_stat 0x0040, PHY RDY changed
[ 63.297961] ata3: SError: { PHYRdyChg CommWake }
[ 63.297966] ata3: hard resetting link
[ 64.021185] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 64.024291] ata3.00: configured for UDMA/133
[ 64.037206] ahci :00:1f.2: port does not support device sleep
[ 64.037214] ata3: EH complete
[ 69.282264] setting min_power
[ 69.282320] ahci :00:1f.2: port does not support device sleep
[ 74.933589] setting max_performance
[ 74.945847] ahci :00:1f.2: port does not support device sleep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Friday 09 January 2015 17:00:18 Tejun Heo wrote:
> Hello, Gabriele.
>
> On Thu, Jan 08, 2015 at 08:37:35PM +0100, Gabriele Mazzotta wrote:
> > I'm having some problems with the link_power_management_policy on my
> > Dell XPS13 9333.
> > Changing policy from min_power or medium_power to max_performance
> > causes the following errors:
> >
> > [ 3955.667086] ahci :00:1f.2: port does not support device sleep
> > [ 3958.257106] ata3.00: exception Emask 0x10 SAct 0x40 SErr 0x5 action
> > 0xe frozen
> > [ 3958.257110] ata3.00: irq_stat 0x0040, PHY RDY changed
> > [ 3958.257113] ata3: SError: { PHYRdyChg CommWake }
> > [ 3958.257116] ata3.00: failed command: READ FPDMA QUEUED
> > [ 3958.257120] ata3.00: cmd 60/00:30:c8:60:10/01:00:1d:00:00/40 tag 6 ncq
> > 131072 in
> > res 40/00:34:c8:60:10/00:00:1d:00:00/40 Emask 0x10 (ATA bus error)
> > [ 3958.257122] ata3.00: status: { DRDY }
> > [ 3958.257126] ata3: hard resetting link
> > [ 3958.981727] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> > [ 3958.984994] ata3.00: configured for UDMA/133
> > [ 3958.997686] ahci :00:1f.2: port does not support device sleep
>
> Ah, it actually happens.
>
> > [ 3958.997698] ata3: EH complete
> >
> > Sometimes I get "failed command: WRITE FPDMA QUEUED" multiple times.
> >
> > As far as I know, this had always happened and it was confirmed
> > by another user. I've also come across some logs of the same system
> > and saw the same errors here and there, so it shouldn't be a problem
> > of my laptop in particular.
> >
> > What I find interesting is that transitions from min_power to
> > medium_power and vice versa do not cause these errors. There are only
> > problem switching from min_power and medium_power to max_performance.
> > Doing the opposite, i.e. from max_performance to min_power or
> > medium_power, seems to work fine.
> >
> > As a consequence of these continuous errors, the speed is reduced
> > from 6.0 Gbps to 1.5 Gbps.
>
> Always? Or does it sometimes get lucky and stabilize at a higher
> speed?
Let's say I need to change the policy a few times before 1.5 Gbps are
reached and the speed is always lowered to 3.0 Gbps first.
I've never noticed any different trend, but I haven't observed this
problem enough. The policy is normally changed when I plug and unplug
my laptop, so not frequently enough to be a 100% sure.
I could do some tests though, all I need is to do is change the policy
a bunch of times.
> > I'd prefer not to disable LPM as it saves a considerable amount of
> > power when I'm using the battery. For this reason I'm currently using
> > medium_power and min_power only to prevent errors.
> >
> > Is it normal that these errors appears only when I switch to
> > max_performance? Was something similar observed on other systems?
>
> It's not normal. It definitely doesn't happen with all devices. I
> guess it could be a quirk from the device side. What's on the other
> side of the connector? Can you post the full kernel log after such
> incidence?
There's connected an SSD. Let me know if you need more information than
those in the dmesg here below.
"setting max_performance" and "setting min_power" were added by me.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.19.0-rc2+ (root@xps13) (gcc version 4.9.2
(Debian 4.9.2-10) ) #8 SMP Thu Jan 8 19:37:54 CET 2015
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.19.0-rc2+
root=/dev/sda6 ro quiet rootfstype=ext4 resume=/dev/sda3 possible_cpus=4
[0.00] KERNEL supported cpus:
[0.00] Intel GenuineIntel
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009cfff] usable
[0.00] BIOS-e820: [mem 0x0009d000-0x000b] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x81afcfff] usable
[0.00] BIOS-e820: [mem 0x81afd000-0x81cfefff] reserved
[0.00] BIOS-e820: [mem 0x81cff000-0xdadb6fff] usable
[0.00] BIOS-e820: [mem 0xdadb7000-0xdafb6fff] type 20
[0.00] BIOS-e820: [mem 0xdafb7000-0xdceeefff] reserved
[0.00] BIOS-e820: [mem 0xdceef000-0xdcf9efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdcf9f000-0xdcffefff] ACPI data
[0.00] BIOS-e820: [mem 0xdcfff000-0xdcff] usable
[0.00] BIOS-e820: [mem 0xdd00-0xdf9f] reserved
[0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] reserved
[0.00] BIOS-e820: [mem 0xfe101000-0xfe
Re: SATA link power management issues
On Fri, Jan 09, 2015 at 05:02:53PM -0500, Tejun Heo wrote: > On Fri, Jan 09, 2015 at 05:00:18PM -0500, Tejun Heo wrote: > > It's not normal. It definitely doesn't happen with all devices. I > > guess it could be a quirk from the device side. What's on the other > > side of the connector? Can you post the full kernel log after such > > incidence? > > What happens if you comment out the DIPM part of ata_eh_set_lpm() - > the first ata_for_each_dev() loop in the function? Never mind. Noticed it happening in your other posting. Applied to libata/for-3.19-fixes. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
On Fri, Jan 09, 2015 at 05:00:18PM -0500, Tejun Heo wrote: > It's not normal. It definitely doesn't happen with all devices. I > guess it could be a quirk from the device side. What's on the other > side of the connector? Can you post the full kernel log after such > incidence? What happens if you comment out the DIPM part of ata_eh_set_lpm() - the first ata_for_each_dev() loop in the function? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA link power management issues
Hello, Gabriele.
On Thu, Jan 08, 2015 at 08:37:35PM +0100, Gabriele Mazzotta wrote:
> I'm having some problems with the link_power_management_policy on my
> Dell XPS13 9333.
> Changing policy from min_power or medium_power to max_performance
> causes the following errors:
>
> [ 3955.667086] ahci :00:1f.2: port does not support device sleep
> [ 3958.257106] ata3.00: exception Emask 0x10 SAct 0x40 SErr 0x5 action
> 0xe frozen
> [ 3958.257110] ata3.00: irq_stat 0x0040, PHY RDY changed
> [ 3958.257113] ata3: SError: { PHYRdyChg CommWake }
> [ 3958.257116] ata3.00: failed command: READ FPDMA QUEUED
> [ 3958.257120] ata3.00: cmd 60/00:30:c8:60:10/01:00:1d:00:00/40 tag 6 ncq
> 131072 in
> res 40/00:34:c8:60:10/00:00:1d:00:00/40 Emask 0x10 (ATA bus error)
> [ 3958.257122] ata3.00: status: { DRDY }
> [ 3958.257126] ata3: hard resetting link
> [ 3958.981727] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [ 3958.984994] ata3.00: configured for UDMA/133
> [ 3958.997686] ahci :00:1f.2: port does not support device sleep
Ah, it actually happens.
> [ 3958.997698] ata3: EH complete
>
> Sometimes I get "failed command: WRITE FPDMA QUEUED" multiple times.
>
> As far as I know, this had always happened and it was confirmed
> by another user. I've also come across some logs of the same system
> and saw the same errors here and there, so it shouldn't be a problem
> of my laptop in particular.
>
> What I find interesting is that transitions from min_power to
> medium_power and vice versa do not cause these errors. There are only
> problem switching from min_power and medium_power to max_performance.
> Doing the opposite, i.e. from max_performance to min_power or
> medium_power, seems to work fine.
>
> As a consequence of these continuous errors, the speed is reduced
> from 6.0 Gbps to 1.5 Gbps.
Always? Or does it sometimes get lucky and stabilize at a higher
speed?
> I'd prefer not to disable LPM as it saves a considerable amount of
> power when I'm using the battery. For this reason I'm currently using
> medium_power and min_power only to prevent errors.
>
> Is it normal that these errors appears only when I switch to
> max_performance? Was something similar observed on other systems?
It's not normal. It definitely doesn't happen with all devices. I
guess it could be a quirk from the device side. What's on the other
side of the connector? Can you post the full kernel log after such
incidence?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
SATA link power management issues
Hi,
I'm having some problems with the link_power_management_policy on my
Dell XPS13 9333.
Changing policy from min_power or medium_power to max_performance
causes the following errors:
[ 3955.667086] ahci :00:1f.2: port does not support device sleep
[ 3958.257106] ata3.00: exception Emask 0x10 SAct 0x40 SErr 0x5 action 0xe
frozen
[ 3958.257110] ata3.00: irq_stat 0x0040, PHY RDY changed
[ 3958.257113] ata3: SError: { PHYRdyChg CommWake }
[ 3958.257116] ata3.00: failed command: READ FPDMA QUEUED
[ 3958.257120] ata3.00: cmd 60/00:30:c8:60:10/01:00:1d:00:00/40 tag 6 ncq
131072 in
res 40/00:34:c8:60:10/00:00:1d:00:00/40 Emask 0x10 (ATA bus error)
[ 3958.257122] ata3.00: status: { DRDY }
[ 3958.257126] ata3: hard resetting link
[ 3958.981727] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3958.984994] ata3.00: configured for UDMA/133
[ 3958.997686] ahci :00:1f.2: port does not support device sleep
[ 3958.997698] ata3: EH complete
Sometimes I get "failed command: WRITE FPDMA QUEUED" multiple times.
As far as I know, this had always happened and it was confirmed
by another user. I've also come across some logs of the same system
and saw the same errors here and there, so it shouldn't be a problem
of my laptop in particular.
What I find interesting is that transitions from min_power to
medium_power and vice versa do not cause these errors. There are only
problem switching from min_power and medium_power to max_performance.
Doing the opposite, i.e. from max_performance to min_power or
medium_power, seems to work fine.
As a consequence of these continuous errors, the speed is reduced
from 6.0 Gbps to 1.5 Gbps.
I'd prefer not to disable LPM as it saves a considerable amount of
power when I'm using the battery. For this reason I'm currently using
medium_power and min_power only to prevent errors.
Is it normal that these errors appears only when I switch to
max_performance? Was something similar observed on other systems?
Thanks,
Gabriele
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
