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:
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
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).
(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
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 ?
(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
My Thinkpad has a raw load cycle value of 1930336257075 which is 3217227 * 600000 (iirc the reported maximum a drive can take)
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...
(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.
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 ?)
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.
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)
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...
(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
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 :)
(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.
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.
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.
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....
I agree the kernel should probably be involved here, I don't know what the plans are to address it.
(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.
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 :)
Bug #430373 filed against hdparm and set to block this bug.
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.
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
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
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
Hello, can anybody test this? Is this still an issue in F10 or in F11?
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
Confirmed fixed in F11 as well.
(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!
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.
(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?
(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.
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...
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
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
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.
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.
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?
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).
Why is this bug not worth fixing?
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.
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...
(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.
(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 :)