Bug 382061 - resume resets hard disk advanced power management settings
Summary: resume resets hard disk advanced power management settings
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 430373
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-14 10:32 UTC by Zdenek Kabelac
Modified: 2013-04-16 17:46 UTC (History)
23 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-16 17:46:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
no black screen after resume on T61 (722 bytes, patch)
2007-11-14 13:09 UTC, Jan Hutař
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 428512 0 low CLOSED Resets BIOS settings... badly. 2021-02-22 00:41:40 UTC

Internal Links: 428512

Description Zdenek Kabelac 2007-11-14 10:32:00 UTC
Description of problem:

For Lenovo T61 I'd to add the file:
/etc/pm/config.d/quirk 

----
DISPLAY_QUIRK_S3_BIOS="true"
----

Also to stop the harddrive LoadCycle problem after resume:
/etc/pm/sleep.d/10hdparm

----
#!/bin/bash

. /usr/lib/pm-utils/functions

case "$1" in
        hibernate|suspend)
                ;;
        thaw|resume) 
                hdparm -B 192 /dev/sda
                ;;
        *)
                ;;
esac

exit $?
----

I think it would be nice to have some active database
of needed quirks for various known hardware issues - so that
users would not have to spend hours to figure them out them self.
There are some quirks for Radeon - so why not for Lenovo
and some other notebooks ?

Version-Release number of selected component (if applicable):
pm-utils-0.99.4-6.fc8

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:
Without the above quirks 
- suspend resumes into black screen
  (Ctrl+Alt+F1 followed with Alt+F7 needed)
- LoadCycle increments with drastic speed (thousands cycles/day)
  (I know it's mostly a BIOS issue - but linux can't prevent it)

Expected results:
pm-utils will suspend/resume T61 without the user's help :)

Additional info:

Comment 1 Jan Hutař 2007-11-14 13:09:31 UTC
Created attachment 258001 [details]
no black screen after resume on T61

Hello,
this was needed for my T61 to get rid of black screen after resume. But this do
not solve the other part of this bug (LoadCycle problem).

# lshal | grep system.hardware
  system.hardware.primary_video.product = 10754  (0x2a02)  (int)
  system.hardware.primary_video.vendor = 32902	(0x8086)  (int)
  system.hardware.product = '6464Y1R'  (string)
  system.hardware.serial = 'XXXXXXX'  (string)
  system.hardware.uuid = 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'  (string)
  system.hardware.vendor = 'LENOVO'  (string)
  system.hardware.version = 'ThinkPad T61'  (string)

Using this hal-info package:

hal-info-20071030-1.fc8

Comment 2 Jan Hutař 2007-11-14 14:38:04 UTC
Just to clarify things: attachment 258001 [details] solves "black screen after resume" 
issue for me. It do not solve LoadCycle problem (see comment #0 for the 
solution).

Comment 3 Till Maas 2007-11-14 15:01:25 UTC
(In reply to comment #0)
> I think it would be nice to have some active database
> of needed quirks for various known hardware issues - so that
> users would not have to spend hours to figure them out them self.
> There are some quirks for Radeon - so why not for Lenovo
> and some other notebooks ?

The quirk database is included in the hal-info package, you can find more info
about this at:
http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html

> - LoadCycle increments with drastic speed (thousands cycles/day)
>   (I know it's mostly a BIOS issue - but linux can't prevent it)

What is LoadCycle? Do you have more information about this?

(In reply to comment #1)
> Created an attachment (id=258001) [edit]
> no black screen after resume on T61
> 
> Hello,
> this was needed for my T61 to get rid of black screen after resume. But this

Please submit your patch like it is described here:
http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-report.html or open
a bug against hal-info


Comment 4 Zdenek Kabelac 2007-11-14 15:27:45 UTC
Yep - I didn't know about the hal database for this - so I'll submit update for HAL.


LoadCycle  problem:

See this original Ubuntu bug description

https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695

I'm not sure how big problem it makes to have the high Load Cycles counter - but
I'm not going to be a test-mouse :) (My few weeks old Lenovo managed to get this
number as high as 130.000 like 40.000 per week) - so I'm now using the hdparm
which stops its - I run hdparm in rc.local - but after resume it must be set
again. I'm not sure where this quirk should go ?


Comment 5 Jan Hutař 2007-11-14 19:33:42 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > Created an attachment (id=258001) [edit] [edit]
> > no black screen after resume on T61
> > 
> > Hello,
> > this was needed for my T61 to get rid of black screen after resume. But this
> 
> Please submit your patch like it is described here:
> http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-report.html or 
open
> a bug against hal-info
> 

Patch sent:

http://lists.freedesktop.org/archives/hal/2007-November/009908.html

Comment 6 Till Maas 2007-11-21 13:41:49 UTC
My Thinkpad has a raw load cycle value of 1930336257075 which is 3217227 *
600000 (iirc the reported maximum a drive can take)

Comment 7 Zdenek Kabelac 2007-11-21 15:20:07 UTC
I think that the value was never stated 'as maximum a driver can take' - but
rather a suggested value at which the driver producer seems to give some
guarantee to reasonable functionality of the drive. On the other hand I know
about users whos  hd-drives stopped to work at ~300.000 cycles..
(It something like the guarantee for the car - you get it for 2-7 years -
depends on manufacturer - but there are cars which runs for 30 years..)

Also I'm not sure how old are you and how often you run your drive - but
considering it would be increased 10 times per second and you run it 24/7
your hard drive must be still quite an ancient piece of hardware like ~6000
years old... So I'm not so sure whatever your number actually means...


Comment 8 Till Maas 2007-11-27 18:57:12 UTC
(In reply to comment #7)

> Also I'm not sure how old are you and how often you run your drive - but
> considering it would be increased 10 times per second and you run it 24/7
> your hard drive must be still quite an ancient piece of hardware like ~6000
> years old... So I'm not so sure whatever your number actually means...

The value is from the smartctl output (the raw value for load cycles) of the
harddisk of my iirc two year old notebook which does not run very often.



Comment 9 Zdenek Kabelac 2007-11-29 14:27:06 UTC
I think the key point here is - if you can see that the number is changed many
times per minute while you regularly work with your notebook - on my IMB the
number grows several times per minute without the hdparm setting.
(Maybe smartctl displays completely wrong values for your harddrive ?)

Comment 10 Till Maas 2007-12-30 20:45:43 UTC
Do you know a way to get the current value for the advanced power management
settings from a harddisk? Then it would be possible to get the value before
suspending, storing it and restore it after resume.

Comment 11 Jan Kratochvil 2008-01-02 12:46:11 UTC
Till,
it was suggested above:
# hdparm -B 255 /dev/sda
# hdparm -I /dev/sda
...
        Advanced power management level: 254 (0xfe)
...
               Advanced Power Management feature set
...
(for -B 255 it still prints 254 but it turns off the APM flag there)


Comment 12 Zdenek Kabelac 2008-01-02 13:37:46 UTC
For me setting the APM completely off had the annoying effect of pretty warm
hard drive bellow the right hand after some time - at least subjectively there
is difference in the heat generated by the drive with the 255 and 192 value.

Using -I /dev/sda  gives in my case something different:
...
	Advanced power management level: unknown setting (0x80c0)
...
(with leading --0x80)
Which require somewhat smarter value parsing...


Comment 13 Till Maas 2008-01-02 13:48:57 UTC
(In reply to comment #12)

> Using -I /dev/sda  gives in my case something different:
> ...
> 	Advanced power management level: unknown setting (0x80c0)
> ...
> (with leading --0x80)
> Which require somewhat smarter value parsing...

Which value did you set with hdparm -B to get this result?
What does the following command report? 

hdparm -I /dev/sda | grep "Advanced Power Management feature set"

There is a new build for rahwide, that should work for cases where "hdparm -I"
reports normal values:

http://koji.fedoraproject.org/koji/taskinfo?taskID=319015

To test only the new loadcycle hook, it is enough to copy
https://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/pm-utils/devel/pm-utils-99hd-apm-restore

to /usr/lib/pm-utils/sleep.d/99hd-apm-restore

Comment 14 Zdenek Kabelac 2008-01-02 14:57:41 UTC
As I mentioned in the begging I'm using -B 192   
(which obviously is 0xc0 - hard to tell where the 0x80 prefix comes from)
(The line I posted already IS the grep)

And I'm using uptodate rawhide so your script will surely pick 255 because it
will not parse my APM level.

I should mentions that prefix 0x80 is there all the time (even with values like
254 or 255 - i.e.:

hdparm -B 254 /dev/sda
Advanced power management level: unknown setting (0x80fe)

hdparm -B 255 /dev/sda
Advanced power management level: unknown setting (0x8080)

And as you can see - the value 255 isn't actually 0xff - don't ask me why....

Basically for my T61 the best value is 192 :)


Comment 15 Till Maas 2008-01-02 17:32:20 UTC
(In reply to comment #14)
> As I mentioned in the begging I'm using -B 192   
> (which obviously is 0xc0 - hard to tell where the 0x80 prefix comes from)
> (The line I posted already IS the grep)

The grep is for a different line.
When I use "hdparm -B 255" here, there an asterisk vanishes, but when I use any
other value, it comes back. Also with "hdparm -B 255" the power management level
 is not changed but only the asterisk removed.
 
> And I'm using uptodate rawhide so your script will surely pick 255 because it
> will not parse my APM level.

There is a new script, that should also handle your case. It also allows you to
set a value that should be set for your drive.
 
> I should mentions that prefix 0x80 is there all the time (even with values like
> 254 or 255 - i.e.:
> 
> hdparm -B 254 /dev/sda
> Advanced power management level: unknown setting (0x80fe)

One of my desktop drives has a prefix of 0x00, but only when it is queried with
-I, setting with -B works there.

Comment 16 Zdenek Kabelac 2008-01-03 12:18:54 UTC
Ahh I've not read the whole line for grep :) so here comes the grep again:

# hdparm -I /dev/sda | grep Advanced
	Advanced power management level: unknown setting (0x80c0)
	   *	Advanced Power Management feature set

I'll check your new script at the moment the package will be updated.


Comment 17 Bill Nottingham 2008-01-12 21:14:10 UTC
I strongly feel this needs to be done at the kernel level - if, without any user
intereference, the settings *change* across suspend/resume, that's a failure of
the kernel's suspend layer.

CC'ing libata folks.

Comment 18 Zdenek Kabelac 2008-01-14 09:53:10 UTC
I think that the current version pm-utils-0.99.4-13.fc9.x86_64  still doesn't
safe&restore the proper setting of hdparm (obviously script couldn't parse my
'hdparm -I' output and saves empty pm-hd-apm file.

Is there going to be any change in this area ?

Also I suspect that hard-coding /dev/sda into the script isn't probably going to
work for every user....



Comment 19 Alan Cox 2008-01-14 10:10:17 UTC
I agree the kernel should probably be involved here, I don't know what the plans
are to address it.


Comment 20 Till Maas 2008-01-14 11:38:53 UTC
(In reply to comment #18)
> I think that the current version pm-utils-0.99.4-13.fc9.x86_64  still doesn't
> safe&restore the proper setting of hdparm (obviously script couldn't parse my
> 'hdparm -I' output and saves empty pm-hd-apm file.
>
> Is there going to be any change in this area ?

Imho you should first file a bug for hdparm, because it cannot handle your
drive. The current workaround for you is to store the setting you want for the
drive in /etc/pm/config.d/hd-apm-restore.conf, then this value will be used in
case you hdparm output cannot be parsed.

> Also I suspect that hard-coding /dev/sda into the script isn't probably going to
> work for every user....
 
In case this will not be resolved in the kernel soon, then I will update the
script to use hal to determine the devices. In attachment #291479 [details] there is
already the logic to detect harddisks, I hope it is correct.

Comment 21 Zdenek Kabelac 2008-01-14 11:53:16 UTC
Ok - I've not noticed the config file - looks like this works for me - but I
guess users will have to enable this setting themselves and I suppose majority
of the user will not notice it - I'm not sure how to do it properly at this moment.

And yes it looks like a good idea to fill bug against hdparm :)



Comment 22 Charles R. Anderson 2008-01-27 01:40:31 UTC
Bug #430373 filed against hdparm and set to block this bug.

Comment 23 Till Maas 2008-04-15 12:58:03 UTC
Please note, that the config file was moved in pm-utils-1.1.0-5 and uses a
different format to specify the default settings for a device.

Comment 24 Bug Zapper 2008-05-14 03:53:13 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 25 Jan Hutař 2008-10-10 07:29:09 UTC
Hello,
I see this is still a problem in current F10 (pm-utils-1.2.0-1.fc10.x86_64). I have set the value manually, but that is probably not a solution.

As bug 430373 seems to be fixed, how to fix this?

Regards,
Jan

Comment 26 Bug Zapper 2009-06-09 23:11:03 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 27 Jan Hutař 2009-06-10 07:27:12 UTC
Hello, can anybody test this? Is this still an issue in F10 or in F11?

Comment 28 Charles R. Anderson 2009-06-19 04:24:59 UTC
Confirmed fixed in F10.  I tested suspend/resume and hibernate/resume using default 128 and modified 192 Advanced Power Management level.  hdparm Advanced Power Management setting was restored in all cases. 

kernel-2.6.29.2-52.fc10.x86_64
pm-utils-1.2.2.1-2.fc10.x86_64
gnome-power-manager-2.24.4-1.fc10.x86_64

Lenovo T61

Initial bootup:

#hdparm -I /dev/sda | grep Advan
        Advanced power management level: 128
           *    Advanced Power Management feature set

After suspend/resume:

#hdparm -I /dev/sda | grep Advan
        Advanced power management level: 128
           *    Advanced Power Management feature set

After hibernate/resume:

#hdparm -I /dev/sda | grep Advan
        Advanced power management level: 128
           *    Advanced Power Management feature set

Set custom level:

#hdparm -B 192 /dev/sda

/dev/sda:
 setting Advanced Power Management level to 0xc0 (192)
#hdparm -I /dev/sda | grep Advan
        Advanced power management level: 192
           *    Advanced Power Management feature set

After suspend/resume:

#hdparm -I /dev/sda | grep Advan
        Advanced power management level: 192
           *    Advanced Power Management feature set

After hibernate/resume:

#hdparm -I /dev/sda | grep Advan
        Advanced power management level: 192
           *    Advanced Power Management feature set

Comment 29 Charles R. Anderson 2009-06-19 06:44:30 UTC
Confirmed fixed in F11 as well.

Comment 30 Jan Hutař 2009-06-19 13:26:25 UTC
(In reply to comment #28)
> Confirmed fixed in F10.  I tested suspend/resume and hibernate/resume using
> default 128 and modified 192 Advanced Power Management level.  hdparm Advanced
> Power Management setting was restored in all cases. 

Wow, good job!

Comment 31 Till Maas 2009-06-25 19:36:20 UTC
As written in comment #17, it still needs to be addressed in the kernel. The current situation is only a workaround. To make this more clear, I reassign this to the kernel component.

Comment 32 Chuck Ebbert 2009-06-30 02:06:02 UTC
(In reply to comment #31)
> As written in comment #17, it still needs to be addressed in the kernel. The
> current situation is only a workaround. To make this more clear, I reassign
> this to the kernel component.  

What do you propose we do in the kernel?

Comment 33 Till Maas 2009-07-15 09:15:01 UTC
(In reply to comment #32)
> (In reply to comment #31)
> > As written in comment #17, it still needs to be addressed in the kernel. The
> > current situation is only a workaround. To make this more clear, I reassign
> > this to the kernel component.  
> 
> What do you propose we do in the kernel?  

Store the state of the hard disks before suspend and restore it afterwards. If this is not possible, this would be nice to know, because then the pm-utils quirk should probably go upstream.

Comment 34 Matthew Garrett 2009-07-15 14:13:54 UTC
Right now, the kernel isn't involved in power management settings at all - hdparm sends commands directly to the drive. Implementing this would require adding support to the kernel to parse the IDENTIFY page to save the settings on suspend and then support for performing the reprogramming on resume. It's possible, but probably better done by someone who has more understanding of ata than I do...

Comment 35 Bug Zapper 2009-11-16 07:59:14 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 36 Bug Zapper 2010-11-04 12:04:36 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 37 Bug Zapper 2010-12-05 07:14:16 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 39 Paolo Leoni 2013-03-15 01:18:24 UTC
This old bug, is stil present in Fedora 18.

kernel.x86_64               3.6.10-4.fc18    
pm-utils.x86_64             1.4.1-22.fc18  

For some Hard disk is very important to have that settings functional, also after resume.

Comment 40 Paolo Leoni 2013-03-15 01:19:11 UTC
This old bug, is still present in Fedora 18.

kernel.x86_64               3.6.10-4.fc18    
pm-utils.x86_64             1.4.1-22.fc18  

For some Hard disk is very important to have that settings functional, also after resume.

It could be possibile reopen this bug?

Comment 41 Paolo Leoni 2013-03-19 09:01:34 UTC
I found this solution:

It's possible to write a script and save it in /usr/lib/systemd/system-sleep/

like this:

#!/bin/sh
case $1 in
   pre)
   ;;
   post)
   hdparm -B [APM_PARAMETER] /dev/sda
       ;;
esac

So, after resume hdparm is correctly recalled. 
Btw, I think the best way would be that this setting can be automatically enabled through Gnome Disk (when user modify Advanced power management).

Comment 42 Till Maas 2013-04-12 18:53:50 UTC
Why is this bug not worth fixing?

Comment 43 Josh Boyer 2013-04-16 15:58:41 UTC
Comment #34 sums it up mostly.  Also, it's been 3.5 years since that comment was made and we're clearly not going to implement this ourselves.

Please take this RFE upstream.

Comment 44 Zdenek Kabelac 2013-04-16 16:06:01 UTC
Hmm just amazed, how the restore of hdparm settings after resume seems to be so hard to resolve in Fedora.

Anyway - since I'm already a user of SSD I do not have resources to check any progress here myself....

Just people with rotational disks should be aware they may quickly pass the guaranteed values given by hdd manufacturers...

Comment 45 Till Maas 2013-04-16 16:16:29 UTC
(In reply to comment #43)
> Comment #34 sums it up mostly.  Also, it's been 3.5 years since that comment
> was made and we're clearly not going to implement this ourselves.
> 
> Please take this RFE upstream.

it is also ok to do this for example in pm-utils as it was done at least for a certain amount of time. The problem is to decide whether this belongs in the kernel or not (see comment:17 to comment:30). If it is decided not to do this in the kernel, this bug should be re-assigned to pm-utils or whatever the current framework for suspend is.

Comment 46 Jaroslav Škarvada 2013-04-16 17:05:41 UTC
(In reply to comment #45)
> (In reply to comment #43)
> > Comment #34 sums it up mostly.  Also, it's been 3.5 years since that comment
> > was made and we're clearly not going to implement this ourselves.
> > 
> > Please take this RFE upstream.
> 
> it is also ok to do this for example in pm-utils as it was done at least for
> a certain amount of time. 
>
This is dirty workaround, we should fix the things right in the right place, even if it turns into longterm RFE.

> The problem is to decide whether this belongs in
> the kernel or not
>
This is definitely kernel. It should work without any user space intervention, like restoring the video resolution.

>(see comment:17 to comment:30).
I couldn't find anybody who strictly says this is not kernel.

> If it is decided not to do
> this in the kernel, this bug should be re-assigned to pm-utils or whatever
> the current framework for suspend is.

PM-utils are deprecated, if you think this is not kernel, you can try to reassign this to systemd (but they really don't like user space quirks :)


Note You need to log in before you can comment on or make changes to this bug.