Description of problem: I tested the S3 suspend/resume on Lenovo T61 laptop (Intel Santa Rosa paltform) with RHEL5.1-snapshot-1 x86_64 kernel. The screen is in black when resuming from S3 suspend, while the system is alive and can be remotely logged in. Version-Release number of selected component (if applicable): How reproducible: The way I was using to perform S3 suspend/resume is,append "acpi_sleep=s3_bios" to linux boot parameter, use "pm-suspend" to suspend. It results in black screen when resuming. But if I use "echo 'mem'> /sys/power/state" to suspend, resume is OK. Steps to Reproduce: 1. 2. 3. Actual results: Resume results in black screen. Expected results: Resume can be successful. Additional info:
I encounter similar problem, only that there is no "acpi_sleep=s3_bios" parameter. My system works in init 3 level without X, screen is back when resuming from ram by this command. # pm-suspend But s2ram works well if adding one parameter # pm-suspend --quirk-vbe-post Jane, can you try command "pm-suspend --quirk-s3-bios" if kernel parameter is added?
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Created attachment 248231 [details] Output of "lshal" on a test Lenovo T61. The latest hal-0.5.8.1-26.el5 is using the following rule to activate the quirk for T61's: <match key="system.hardware.version" string="766314G"> However, as shown in the attached "lshal" output, in my test hardware the correct rule should be: <match key="system.hardware.version" prefix_ncase="ThinkPad T61"> Which does indeed correctly activate power_management.quirk.s3_bios on this hardware. -- Navid
+ qa_ack for rhel-5.2
(In reply to comment #3) > Created an attachment (id=248231) [edit] > Output of "lshal" on a test Lenovo T61. > > The latest hal-0.5.8.1-26.el5 is using the following rule to activate the quirk > for T61's: > > <match key="system.hardware.version" string="766314G"> > > However, as shown in the attached "lshal" output, in my test hardware the > correct rule should be: > > <match key="system.hardware.version" prefix_ncase="ThinkPad T61"> > > Which does indeed correctly activate power_management.quirk.s3_bios on this > hardware. > > -- Navid Will hal-0.5.8.1-26.el5 be included in rhel-5.2? If so, I think we can verify this bug after rhel-5.2 is released. If we should verify this bug now, where can I find hal-0.5.8.1-26.el5?
Hui, you can just ask me for stuff like that. I've been authorized to send you the package, so I will do so.
Created attachment 287311 [details] lshal output for this machine
I had tried the latest hal-0.5.8.1-26.el5. But this issue didn't been fixed yet. When append kernel parameter: acpi_sleep=s3_bios, "echo 'mem'> /sys/power/state" can suspend and resume successfully, but both pm-suspend and 'suspend' button in 'system' menu will lead to failure of resume. If don't append acpi_sleep=s3_bios to kernel parameter, 'pm-suspend --quirk-s3- bios ' can resume well, but both pm-suspend and 'suspend' button in 'system' menu will lead to failure of resume.
This works: In /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-el5-lenovo.fdi add: <!-- X61 --> <match key="system.hardware.product" prefix="7674"> <merge key="power_management.quirk.s3_bios" type="bool">true</merge> <merge key="power_management.quirk.s3_mode" type="bool">true</merge> </match> Resume now works. But sometimes the wireless card is not working. ifup eth1 and service NetworkManager restart are my current workaround. Jan
What's the rationale behind using numerical product number prefixes such as 7674, 7575, ... and not textural values of system.product or system.hardware.version? There is a really huge and growing number of the numerical versions (consult IBM website) and we pretty much lost track of most IBM ThinkPad hardware I've seen. Is that the different video hardware, or something like that? Is there a good way to prevent the quirk databasae from being obsoleted as quickly as it currently happens?
I've added these two entries <!-- X61 (https://bugzilla.redhat.com/show_bug.cgi?id=252452#c11) --> <match key="system.hardware.product" prefix="7674"> <merge key="power_management.quirk.s3_bios" type="bool">true</merge> <merge key="power_management.quirk.s3_mode" type="bool">true</merge> </match> <!-- T61 (https://bugzilla.redhat.com/show_bug.cgi?id=252452#c10) --> <match key="system.hardware.product" prefix="7658"> <merge key="power_management.quirk.s3_bios" type="bool">true</merge> <merge key="power_management.quirk.s3_mode" type="bool">true</merge> </match> * Wed Jan 02 2008 David Zeuthen <davidz> - 0.5.8.1-31%{?dist} - Add some more quirks - Resolves: #252452
David: My T61 has system.hardware.product = '6464Y1R' (intel graphic chip), has the same problem and same fix (with different numbers) work. Why don't we do a match for system.product or system.hardware.version?
(In reply to comment #15) > David: My T61 has system.hardware.product = '6464Y1R' (intel graphic chip), has > the same problem and same fix (with different numbers) work. Why don't we do a > match for system.product or system.hardware.version? Simply because keying of the product name is not precise enough. See the hal ml archives for details.
(In reply to comment #14) > I've added these two entries > <!-- X61 (https://bugzilla.redhat.com/show_bug.cgi?id=252452#c11) --> > <match key="system.hardware.product" prefix="7674"> > <merge key="power_management.quirk.s3_bios" type="bool">true</merge> > <merge key="power_management.quirk.s3_mode" type="bool">true</merge> > </match> > <!-- T61 (https://bugzilla.redhat.com/show_bug.cgi?id=252452#c10) --> > <match key="system.hardware.product" prefix="7658"> > <merge key="power_management.quirk.s3_bios" type="bool">true</merge> > <merge key="power_management.quirk.s3_mode" type="bool">true</merge> > </match> > * Wed Jan 02 2008 David Zeuthen <davidz> - 0.5.8.1-31%{?dist} > - Add some more quirks > - Resolves: #252452 David, for my type (7658), it should be fixed in hal 0.5.8.1-31? Where can I get this package for verifying? Thanks.
I provided -32 packages to Austin for testing.
I used the latest hal package hal-0.5.8.1-32.el5.x86_64.rpm and hal-gnome- 0.5.8.1-32.el5.x86_64.rpm, it still doesn't wotk (After I use 'suspend' button from menu to suspend the system, and after resume, the screen is balck yet.) After checking lshal (you can get it also from above comments#9), it seemd the product type should be "7658CTO" rather than "7658". After revise the string in /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-el5- lenovo.fdi from "7658" to "7658CTO", the s3 can work normally now. Thanks!
(In reply to comment #19) > I used the latest hal package hal-0.5.8.1-32.el5.x86_64.rpm and hal-gnome- > 0.5.8.1-32.el5.x86_64.rpm, it still doesn't wotk (After I use 'suspend' button > from menu to suspend the system, and after resume, the screen is balck yet.) > > After checking lshal (you can get it also from above comments#9), it seemd the > product type should be "7658CTO" rather than "7658". After revise the string > in /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-el5- > lenovo.fdi from "7658" to "7658CTO", the s3 can work normally now. > > Thanks! I've updated this in hal-0.5.8.1-33.el5.
Another T61 has the same issue, product type is:7661W1P Add the related entry in /usr/share/hal/fdi/information/10freedesktop/20-video- quirk-pm-el5-lenovo.fdi, it was fixed also. If possible, maybe you can add 7661CTO in hal also. Thanks.
So this is what we want to add? <-- https://bugzilla.redhat.com/show_bug.cgi?id=252452#c24 --> <match key="system.hardware.product" prefix="6463WFX"> <merge key="power_management.quirk.s3_bios" type="bool">true</merge> <merge key="power_management.quirk.s3_mode" type="bool">true</merge> </match> <-- https://bugzilla.redhat.com/show_bug.cgi?id=252452#c25 --> <match key="system.hardware.product" prefix="7661W1P"> <merge key="power_management.quirk.s3_bios" type="bool">true</merge> <merge key="power_management.quirk.s3_mode" type="bool">true</merge> </match> <-- https://bugzilla.redhat.com/show_bug.cgi?id=252452#c26 --> <match key="system.hardware.product" prefix="8895Y13"> <merge key="power_management.quirk.s3_bios" type="bool">true</merge> <merge key="power_management.quirk.s3_mode" type="bool">true</merge> </match>
That looks right, yes.
In hal-0.5.8.1-35.el5
Guys, customer just added an product type that also should be included (it's a Lenovo x61): 7673Y2U
(In reply to comment #31) > Guys, > > customer just added an product type that also should be included (it's a Lenovo > x61): > > 7673Y2U > It's a little bit late in the game for this. Please file a new bug for this (and get the appropriate exceptions from PM).
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0476.html