Bug 533610

Summary: upgrade to 2.6.27.29 comes with weird post-suspend issues
Product: [openSUSE] openSUSE 11.1 Reporter: Jon Nelson <jnelson-suse>
Component: KernelAssignee: Danny Al-Gaaf <dalgaaf>
Status: VERIFIED NORESPONSE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P3 - Medium CC: jeffm
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Jon Nelson 2009-08-24 01:53:08 UTC 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.13) Gecko/2009080200 SUSE/3.0.13-0.1.2 Firefox/3.0.13

I have a Lenovo T61p which works extraordinarily well, including suspending to RAM.

Since upgrading to 2.6.27.29, I've been having suspend-to-ram issues.
Sometimes it won't suspend at all (typically showing ksysguardd still running).
Other times (and this is the core issue, I think) processes get stuck in state 'D'.  Twice today.  Once it was an *unkillable* ksysguardd (kill -9 didn't even touch it - can't strace it - nothing). Once it was dhclient. Also stuck in state 'D'. Also unkillable (even w/kill -9, etc...).

2.6.27.27 (or whatever was openSUSE 11.1's updated kernel prior to 2.6.27.29) worked just fine.


Reproducible: Sometimes

Steps to Reproduce:
1.
2.
3.
Comment 1 Jeff Mahoney 2009-09-09 17:36:56 UTC 
When this happens, can you do "echo w > /proc/sysrq-trigger" and attach the output of dmesg?
Comment 2 Jon Nelson 2009-09-10 03:30:33 UTC 
Please see bug 536549 which I believe is ultimately the same issue.
I found out today I don't have to suspend to cause the issue.
Comment 3 Jon Nelson 2009-11-01 21:15:37 UTC 
This continues to be a regression even with 2.6.27.37

It would appear that all kernels after 2.6.27.25 suffer from this issue.

It might continue to be bug 536549.
Comment 4 Greg Kroah-Hartman 2009-12-15 00:32:12 UTC 
Does openSUSE 11.2 resolve this?
Comment 5 Jon Nelson 2009-12-15 01:35:49 UTC 
Yes, openSUSE 11.2 suspends to RAM perfectly, *provided* I supply the appropriate HAL fdi:

cat /usr/share/hal/fdi/information/20thirdparty/05-fix_suspend.fdi

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="system.hardware.vendor" string="LENOVO">
      <match key="system.hardware.product" prefix_outof="6460">
        <merge key="power_management.quirk.s3_bios" type="bool">false</merge>
        <merge key="power_management.quirk.vbe_post" type="bool">false</merge>
        <merge key="power_management.quirk.s3_mode" type="bool">false</merge>
        <merge key="power_management.quirk.vbemode_restore" type="bool">false</merge>
      </match>
    </match>
  </device>
</deviceinfo>
Comment 6 Jeff Mahoney 2010-03-18 19:29:33 UTC 
Ok, this conflicts with 20-video-quirk-pm-lenovo.fdi

Assigning to HAL maintainer.
Comment 7 Danny Al-Gaaf 2010-04-06 09:38:26 UTC 
What kind of video driver did you use? NVidia?
Comment 8 Jon Nelson 2010-04-06 12:52:32 UTC 
I am using the nvidia proprietary driver.
However, since I switched to a newer kernel (I'm on openSUSE 11.2 now) my laptop suspends and wakes beautifully, with or without the nvidia driver.

However, I believe the above HAL fdi fix is still appropriate for my model, regardless of which video driver is used.

The T61p comes with several different video chipsets, and I don't think the nvidia one was set up properly (or at all?)
Comment 9 Danny Al-Gaaf 2010-04-12 12:34:34 UTC 
(In reply to comment #8)
> I am using the nvidia proprietary driver.
> However, since I switched to a newer kernel (I'm on openSUSE 11.2 now) my
> laptop suspends and wakes beautifully, with or without the nvidia driver.

It suspends now also without the fdi-file from comment #5 ?
Comment 10 Danny Al-Gaaf 2010-05-05 10:26:28 UTC 
No response on NEEDINFO in ~3weeks --> CLOSED NORESPONSE