This mail is trying to summarize a problem that seems to be ongoing for
a number of mainline releases (at least for certain HW) and for which we
would like some advise as to how to best approach diagnosis and fix.
In order to reduce power usage we have been trying to make use of the SATA
ALPM feature in various kernel releases. However this has resulted in
reports [1] of users who see timeouts on SATA commands apparently
triggered by link power state change, and disk corruption as a result. If
recollection is right this happened on 2.6.31, 2.6.32, and 2.6.35 at least.
The most recent example was a 2.6.35 based kernel running on a system with a
Nvidia MCP67 AHCI controller [2] and a WD disk drive [3].
We are hoping that those working more closely with the SATA code might
be aware of this issue. As the symptoms are so severe (data corruption)
we have ALPM disabled globally, but this does make it hard to get more
targeted information on affected platforms.
As getting testing is tricky, we are keen to get some advise as to how we
might better diagnose this issue should we be able to get some testing.
We would also like to better understand what information is available and
what valuable in such a diagnosis. Perhaps someone remembers fixing it (for
some other hw).
* Is this problem likely only related to the controller or may the drive have
some influence as well? The diagnostics[4] sound a bit like the link fails
to recover in a way it is supposed to.
* Should the error message already show sufficient information or would there
be additional debug data that is helpful and what would that be?
Any advice appreciated. Should we file a bugzilla bug report to discuss this?
Thanks.
Stefan
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539467
[2] 00:09.0 IDE interface [0101]: nVidia Corporation MCP67 AHCI Controller
[10de:0550] (rev a2) (prog-if 85 [Master SecO PriO])
Subsystem: Acer Incorporated [ALI] Device [1025:0126]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 23
Region 0: I/O ports at 30f0 [size=8]
Region 1: I/O ports at 30e4 [size=4]
Region 2: I/O ports at 30e8 [size=8]
Region 3: I/O ports at 30e0 [size=4]
Region 4: I/O ports at 30d0 [size=16]
Region 5: Memory at d0884000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] SATA HBA v1.0 InCfgSpace
Capabilities: [b0] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [cc] HyperTransport: MSI Mapping Enable- Fixed+
Kernel driver in use: ahci
Kernel modules: ahci
[3] Model=WDC WD2500BEVS-22UST0, FwRev=01.01A01, SerialNo=WD-WXE108A79290
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
[4] [12348.040077] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x150000
action 0x6 frozen
[12348.040086] ata3: SError: { PHYRdyChg CommWake Dispar }
[12348.040091] ata3.00: failed command: READ FPDMA QUEUED
[12348.040099] ata3.00: cmd 60/10:00:b0:94:c5/00:00:03:00:00/40
tag 0 ncq 8192 in
[12348.040101] res 40/00:00:00:4f:c2/00:00:00:00:00/00
Emask 0x4 (timeout)
[12348.040104] ata3.00: status: { DRDY }
[12348.040112] ata3: hard resetting link
[12348.390082] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[12348.404414] ata3.00: configured for UDMA/133
[12348.404550] ata3.00: device reported invalid CHS sector 0
[12348.404570] ata3: EH complete
Hello,
On Fri, Feb 18, 2011 at 01:58:09PM +0100, Stefan Bader wrote:
> We are hoping that those working more closely with the SATA code might
> be aware of this issue. As the symptoms are so severe (data corruption)
> we have ALPM disabled globally, but this does make it hard to get more
> targeted information on affected platforms.
What do you mean by data corruption? File system ro remount or actual
fs corruption? If actual fs corruption is happening, it's highly
likely that there's an underlying issue with the hardware. If data
corruption can be reproduced, can you please run smartctl -a before
and after such failure and post the outputs?
As for ro remounts, I recall applying fixes for that months ago. I
don't remember the details but some configurations raised extra PHY
event afterwards and command was failed without retry. Anyways, it
got fixed. Please dig through the log for details.
Also, the whole LPM thing got revamped several releases ago. Can you
please test how the recent kernels behave? There will be failures as
not all hardware can handle LPM well but those failures shouldn't lead
to any catastrophic failures like ro remounting of filesystem.
Thanks.
--
tejun
On 02/18/2011 03:50 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Feb 18, 2011 at 01:58:09PM +0100, Stefan Bader wrote:
>> We are hoping that those working more closely with the SATA code might
>> be aware of this issue. As the symptoms are so severe (data corruption)
>> we have ALPM disabled globally, but this does make it hard to get more
>> targeted information on affected platforms.
>
> What do you mean by data corruption? File system ro remount or actual
> fs corruption? If actual fs corruption is happening, it's highly
> likely that there's an underlying issue with the hardware. If data
> corruption can be reproduced, can you please run smartctl -a before
> and after such failure and post the outputs?
>
Sorry that was not specific enough. It is remounting ro, which can leave the fs
in a better or worse state.
> As for ro remounts, I recall applying fixes for that months ago. I
> don't remember the details but some configurations raised extra PHY
> event afterwards and command was failed without retry. Anyways, it
> got fixed. Please dig through the log for details.
>
> Also, the whole LPM thing got revamped several releases ago. Can you
> please test how the recent kernels behave? There will be failures as
> not all hardware can handle LPM well but those failures shouldn't lead
> to any catastrophic failures like ro remounting of filesystem.
>
The example output given as footnotes in the original post were taken from the
latest re-test someone did on a 2.6.38-rc5 kernel (same user also reported bad
experience with a 2.6.35 based kernel). The comment we got on that was:
"Here's what i get - the drive led lights continuously for about 10 seconds
during which any hdd access results in hanging process:"
[12348.040077] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x150000 action 0x6 frozen
[12348.040086] ata3: SError: { PHYRdyChg CommWake Dispar }
[12348.040091] ata3.00: failed command: READ FPDMA QUEUED
[12348.040099] ata3.00: cmd 60/10:00:b0:94:c5/00:00:03:00:00/40 tag 0 ncq 8192 in
[12348.040101] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
[12348.040104] ata3.00: status: { DRDY }
[12348.040112] ata3: hard resetting link
[12348.390082] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[12348.404414] ata3.00: configured for UDMA/133
[12348.404550] ata3.00: device reported invalid CHS sector 0
[12348.404570] ata3: EH complete
I believe the details of the failures varied but "READ FPDMA QUEUED" and a
timeout were usually involved.
Stefan
> Thanks.
>
Hello,
On Fri, Feb 18, 2011 at 04:55:45PM +0100, Stefan Bader wrote:
> Sorry that was not specific enough. It is remounting ro, which can
> leave the fs in a better or worse state.
I see and, nope, that shouldn't lead to corrupted filesystem on a
journaled filesystem. I agree it sucks tho. This shouldn't be
happening with newer kernels unless the hardware completely shuts
down, which some very early SATA harddrives did but shouldn't happen
with most modern devices. Backporting the fix isn't difficult.
> > Also, the whole LPM thing got revamped several releases ago. Can you
> > please test how the recent kernels behave? There will be failures as
> > not all hardware can handle LPM well but those failures shouldn't lead
> > to any catastrophic failures like ro remounting of filesystem.
>
> The example output given as footnotes in the original post were taken from the
> latest re-test someone did on a 2.6.38-rc5 kernel (same user also reported bad
> experience with a 2.6.35 based kernel). The comment we got on that was:
>
> "Here's what i get - the drive led lights continuously for about 10 seconds
> during which any hdd access results in hanging process:"
>
> [12348.040077] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x150000 action 0x6 frozen
> [12348.040086] ata3: SError: { PHYRdyChg CommWake Dispar }
> [12348.040091] ata3.00: failed command: READ FPDMA QUEUED
> [12348.040099] ata3.00: cmd 60/10:00:b0:94:c5/00:00:03:00:00/40 tag 0 ncq 8192 in
> [12348.040101] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
> [12348.040104] ata3.00: status: { DRDY }
> [12348.040112] ata3: hard resetting link
> [12348.390082] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [12348.404414] ata3.00: configured for UDMA/133
> [12348.404550] ata3.00: device reported invalid CHS sector 0
> [12348.404570] ata3: EH complete
>
> I believe the details of the failures varied but "READ FPDMA QUEUED" and a
> timeout were usually involved.
It's on NVIDIA ahci, right? This shouldn't be happening with intel
and jmb ones, which were used while implementing. The problem is most
likely controller dependent. One possibility is the controller is not
happy with DIPM. Does specifying "medium_power" instead make the
problem go away? Can the bug reporter try some kernel patches?
Thanks.
--
tejun
On 02/18/2011 05:16 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Feb 18, 2011 at 04:55:45PM +0100, Stefan Bader wrote:
>> Sorry that was not specific enough. It is remounting ro, which can
>> leave the fs in a better or worse state.
>
> I see and, nope, that shouldn't lead to corrupted filesystem on a
> journaled filesystem. I agree it sucks tho. This shouldn't be
> happening with newer kernels unless the hardware completely shuts
> down, which some very early SATA harddrives did but shouldn't happen
> with most modern devices. Backporting the fix isn't difficult.
>
>>> Also, the whole LPM thing got revamped several releases ago. Can you
>>> please test how the recent kernels behave? There will be failures as
>>> not all hardware can handle LPM well but those failures shouldn't lead
>>> to any catastrophic failures like ro remounting of filesystem.
>>
>> The example output given as footnotes in the original post were taken from the
>> latest re-test someone did on a 2.6.38-rc5 kernel (same user also reported bad
>> experience with a 2.6.35 based kernel). The comment we got on that was:
>>
>> "Here's what i get - the drive led lights continuously for about 10 seconds
>> during which any hdd access results in hanging process:"
>>
>> [12348.040077] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x150000 action 0x6 frozen
>> [12348.040086] ata3: SError: { PHYRdyChg CommWake Dispar }
>> [12348.040091] ata3.00: failed command: READ FPDMA QUEUED
>> [12348.040099] ata3.00: cmd 60/10:00:b0:94:c5/00:00:03:00:00/40 tag 0 ncq 8192 in
>> [12348.040101] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
>> [12348.040104] ata3.00: status: { DRDY }
>> [12348.040112] ata3: hard resetting link
>> [12348.390082] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [12348.404414] ata3.00: configured for UDMA/133
>> [12348.404550] ata3.00: device reported invalid CHS sector 0
>> [12348.404570] ata3: EH complete
>>
>> I believe the details of the failures varied but "READ FPDMA QUEUED" and a
>> timeout were usually involved.
>
> It's on NVIDIA ahci, right? This shouldn't be happening with intel
> and jmb ones, which were used while implementing. The problem is most
> likely controller dependent. One possibility is the controller is not
> happy with DIPM. Does specifying "medium_power" instead make the
> problem go away? Can the bug reporter try some kernel patches?
>
Yes, it is an Nvidia MCP67 in ahci mode. I can relay the question about
medium_power and yes we can try patches. If not the reporter, I can prepare
kernels and ask for testing.
One question in general would be whether (if it cannot be said for sure which
controller is good or not) it may be a good idea to add some whitelisting for
those known to work and disable (or limit the mode) for the unknown.
-Stefan
> Thanks.
>
On 02/18/2011 05:51 PM, Stefan Bader wrote:
> On 02/18/2011 05:16 PM, Tejun Heo wrote:
>> Hello,
>>
>> On Fri, Feb 18, 2011 at 04:55:45PM +0100, Stefan Bader wrote:
>>> Sorry that was not specific enough. It is remounting ro, which can
>>> leave the fs in a better or worse state.
>>
>> I see and, nope, that shouldn't lead to corrupted filesystem on a
>> journaled filesystem. I agree it sucks tho. This shouldn't be
>> happening with newer kernels unless the hardware completely shuts
>> down, which some very early SATA harddrives did but shouldn't happen
>> with most modern devices. Backporting the fix isn't difficult.
>>
>>>> Also, the whole LPM thing got revamped several releases ago. Can you
>>>> please test how the recent kernels behave? There will be failures as
>>>> not all hardware can handle LPM well but those failures shouldn't lead
>>>> to any catastrophic failures like ro remounting of filesystem.
>>>
>>> The example output given as footnotes in the original post were taken from the
>>> latest re-test someone did on a 2.6.38-rc5 kernel (same user also reported bad
>>> experience with a 2.6.35 based kernel). The comment we got on that was:
>>>
>>> "Here's what i get - the drive led lights continuously for about 10 seconds
>>> during which any hdd access results in hanging process:"
>>>
>>> [12348.040077] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x150000 action 0x6 frozen
>>> [12348.040086] ata3: SError: { PHYRdyChg CommWake Dispar }
>>> [12348.040091] ata3.00: failed command: READ FPDMA QUEUED
>>> [12348.040099] ata3.00: cmd 60/10:00:b0:94:c5/00:00:03:00:00/40 tag 0 ncq 8192 in
>>> [12348.040101] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
>>> [12348.040104] ata3.00: status: { DRDY }
>>> [12348.040112] ata3: hard resetting link
>>> [12348.390082] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [12348.404414] ata3.00: configured for UDMA/133
>>> [12348.404550] ata3.00: device reported invalid CHS sector 0
>>> [12348.404570] ata3: EH complete
>>>
>>> I believe the details of the failures varied but "READ FPDMA QUEUED" and a
>>> timeout were usually involved.
>>
>> It's on NVIDIA ahci, right? This shouldn't be happening with intel
>> and jmb ones, which were used while implementing. The problem is most
>> likely controller dependent. One possibility is the controller is not
>> happy with DIPM. Does specifying "medium_power" instead make the
>> problem go away? Can the bug reporter try some kernel patches?
>>
>
> Yes, it is an Nvidia MCP67 in ahci mode. I can relay the question about
> medium_power and yes we can try patches. If not the reporter, I can prepare
> kernels and ask for testing.
> One question in general would be whether (if it cannot be said for sure which
> controller is good or not) it may be a good idea to add some whitelisting for
> those known to work and disable (or limit the mode) for the unknown.
>
> -Stefan
>> Thanks.
>>
>
Sorry for the delay. So medium power is ok. Only minimum causes the problems
(again this was a relative recent kernel with ndvidia controller). What kind of
information is needed for further debugging?
Stefan
On Fri, Mar 11, 2011 at 11:27:54AM +0100, Stefan Bader wrote:
> > Yes, it is an Nvidia MCP67 in ahci mode. I can relay the question about
> > medium_power and yes we can try patches. If not the reporter, I can prepare
> > kernels and ask for testing.
> > One question in general would be whether (if it cannot be said for sure which
> > controller is good or not) it may be a good idea to add some whitelisting for
> > those known to work and disable (or limit the mode) for the unknown.
Does the following patch resolve the issue?
Thanks.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index b8d96ce..da75ec3 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -150,7 +150,7 @@ static const struct ata_port_info ahci_port_info[] = {
{
AHCI_HFLAGS (AHCI_HFLAG_NO_FPDMA_AA | AHCI_HFLAG_NO_PMP |
AHCI_HFLAG_YES_NCQ),
- .flags = AHCI_FLAG_COMMON,
+ .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_DIPM,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
.port_ops = &ahci_ops,
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 17a6378..3021b95 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -3276,6 +3276,7 @@ static int ata_eh_set_lpm(struct ata_link *link, enum ata_lpm_policy policy,
struct ata_eh_context *ehc = &link->eh_context;
struct ata_device *dev, *link_dev = NULL, *lpm_dev = NULL;
enum ata_lpm_policy old_policy = link->lpm_policy;
+ bool no_dipm = ap->flags & ATA_FLAG_NO_DIPM;
unsigned int hints = ATA_LPM_EMPTY | ATA_LPM_HIPM;
unsigned int err_mask;
int rc;
@@ -3292,7 +3293,7 @@ static int ata_eh_set_lpm(struct ata_link *link, enum ata_lpm_policy policy,
*/
ata_for_each_dev(dev, link, ENABLED) {
bool hipm = ata_id_has_hipm(dev->id);
- bool dipm = ata_id_has_dipm(dev->id);
+ bool dipm = ata_id_has_dipm(dev->id) && !no_dipm;
/* find the first enabled and LPM enabled devices */
if (!link_dev)
@@ -3349,7 +3350,8 @@ static int ata_eh_set_lpm(struct ata_link *link, enum ata_lpm_policy policy,
/* host config updated, enable DIPM if transitioning to MIN_POWER */
ata_for_each_dev(dev, link, ENABLED) {
- if (policy == ATA_LPM_MIN_POWER && ata_id_has_dipm(dev->id)) {
+ if (policy == ATA_LPM_MIN_POWER && !no_dipm &&
+ ata_id_has_dipm(dev->id)) {
err_mask = ata_dev_set_feature(dev,
SETFEATURES_SATA_ENABLE, SATA_DIPM);
if (err_mask && err_mask != AC_ERR_DEV) {
diff --git a/include/linux/libata.h b/include/linux/libata.h
index c9c5d7a..3ad1eeb 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -137,8 +137,6 @@ enum {
ATA_DFLAG_ACPI_PENDING = (1 << 5), /* ACPI resume action pending */
ATA_DFLAG_ACPI_FAILED = (1 << 6), /* ACPI on devcfg has failed */
ATA_DFLAG_AN = (1 << 7), /* AN configured */
- ATA_DFLAG_HIPM = (1 << 8), /* device supports HIPM */
- ATA_DFLAG_DIPM = (1 << 9), /* device supports DIPM */
ATA_DFLAG_DMADIR = (1 << 10), /* device requires DMADIR */
ATA_DFLAG_CFG_MASK = (1 << 12) - 1,
@@ -203,6 +201,7 @@ enum {
* management */
ATA_FLAG_SW_ACTIVITY = (1 << 22), /* driver supports sw activity
* led */
+ ATA_FLAG_NO_DIPM = (1 << 23), /* host not happy with DIPM */
/* bits 24:31 of ap->flags are reserved for LLD specific flags */
On 03/11/2011 12:01 PM, Tejun Heo wrote:
> On Fri, Mar 11, 2011 at 11:27:54AM +0100, Stefan Bader wrote:
>>> Yes, it is an Nvidia MCP67 in ahci mode. I can relay the question about
>>> medium_power and yes we can try patches. If not the reporter, I can prepare
>>> kernels and ask for testing.
>>> One question in general would be whether (if it cannot be said for sure which
>>> controller is good or not) it may be a good idea to add some whitelisting for
>>> those known to work and disable (or limit the mode) for the unknown.
>
> Does the following patch resolve the issue?
>
A test kernel with this patch applied was just verified to be resolving the
issue by one of our affected users.
-Stefan
> Thanks.
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index b8d96ce..da75ec3 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -150,7 +150,7 @@ static const struct ata_port_info ahci_port_info[] = {
> {
> AHCI_HFLAGS (AHCI_HFLAG_NO_FPDMA_AA | AHCI_HFLAG_NO_PMP |
> AHCI_HFLAG_YES_NCQ),
> - .flags = AHCI_FLAG_COMMON,
> + .flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_DIPM,
> .pio_mask = ATA_PIO4,
> .udma_mask = ATA_UDMA6,
> .port_ops = &ahci_ops,
> diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
> index 17a6378..3021b95 100644
> --- a/drivers/ata/libata-eh.c
> +++ b/drivers/ata/libata-eh.c
> @@ -3276,6 +3276,7 @@ static int ata_eh_set_lpm(struct ata_link *link, enum ata_lpm_policy policy,
> struct ata_eh_context *ehc = &link->eh_context;
> struct ata_device *dev, *link_dev = NULL, *lpm_dev = NULL;
> enum ata_lpm_policy old_policy = link->lpm_policy;
> + bool no_dipm = ap->flags & ATA_FLAG_NO_DIPM;
> unsigned int hints = ATA_LPM_EMPTY | ATA_LPM_HIPM;
> unsigned int err_mask;
> int rc;
> @@ -3292,7 +3293,7 @@ static int ata_eh_set_lpm(struct ata_link *link, enum ata_lpm_policy policy,
> */
> ata_for_each_dev(dev, link, ENABLED) {
> bool hipm = ata_id_has_hipm(dev->id);
> - bool dipm = ata_id_has_dipm(dev->id);
> + bool dipm = ata_id_has_dipm(dev->id) && !no_dipm;
>
> /* find the first enabled and LPM enabled devices */
> if (!link_dev)
> @@ -3349,7 +3350,8 @@ static int ata_eh_set_lpm(struct ata_link *link, enum ata_lpm_policy policy,
>
> /* host config updated, enable DIPM if transitioning to MIN_POWER */
> ata_for_each_dev(dev, link, ENABLED) {
> - if (policy == ATA_LPM_MIN_POWER && ata_id_has_dipm(dev->id)) {
> + if (policy == ATA_LPM_MIN_POWER && !no_dipm &&
> + ata_id_has_dipm(dev->id)) {
> err_mask = ata_dev_set_feature(dev,
> SETFEATURES_SATA_ENABLE, SATA_DIPM);
> if (err_mask && err_mask != AC_ERR_DEV) {
> diff --git a/include/linux/libata.h b/include/linux/libata.h
> index c9c5d7a..3ad1eeb 100644
> --- a/include/linux/libata.h
> +++ b/include/linux/libata.h
> @@ -137,8 +137,6 @@ enum {
> ATA_DFLAG_ACPI_PENDING = (1 << 5), /* ACPI resume action pending */
> ATA_DFLAG_ACPI_FAILED = (1 << 6), /* ACPI on devcfg has failed */
> ATA_DFLAG_AN = (1 << 7), /* AN configured */
> - ATA_DFLAG_HIPM = (1 << 8), /* device supports HIPM */
> - ATA_DFLAG_DIPM = (1 << 9), /* device supports DIPM */
> ATA_DFLAG_DMADIR = (1 << 10), /* device requires DMADIR */
> ATA_DFLAG_CFG_MASK = (1 << 12) - 1,
>
> @@ -203,6 +201,7 @@ enum {
> * management */
> ATA_FLAG_SW_ACTIVITY = (1 << 22), /* driver supports sw activity
> * led */
> + ATA_FLAG_NO_DIPM = (1 << 23), /* host not happy with DIPM */
>
> /* bits 24:31 of ap->flags are reserved for LLD specific flags */
>