Suspend/hibernate does not work with HP Pavilion dv9340ea

Bug #203552 reported by Mrts
10
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Medium
Unassigned
Nominated for Hardy by Mrts
linux-restricted-modules-2.6.24 (Ubuntu)
Fix Released
Undecided
Unassigned
Nominated for Hardy by Mrts

Bug Description

UPDATE:

Progress has been made in 2.6.25 kernel in fixing this, please see the comments below. Resuming does not still work as LCD backlight is not turned on after resume.

----

Binary package hint: nvidia-glx-new

Expected:
 * Laptop is suspended when I choose Logout button -> Suspend or Hibernate in Gnome.
 * Laptop is resumed from sleep when I press the power or resume button.

Got:
 * Blank screen with a blinking cursor, system does not respond to input.

Caveats:
 * If I leave glxgears and glxheads running, suspend sometimes works.
 * If it works, laptop is also correctly resumed from sleep.

Looks like the following note from /usr/share/doc/nvidia-glx-new/README.txt.gz explains this:
"
   o In many cases, suspending and/or resuming will fail. As mentioned above,
     this functionality is very system-specific. There are still many cases
     that are problematic. Here are some tips that may help:

        o In some cases, hibernation can have bad interactions with the PCI
          Express bus clocks, which can lead to system hangs when entering
          hibernation. This issue is still being investigated, but a known
          workaround is to leave an OpenGL application running when
          hibernating.
"

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

$ uname -a
Linux foo 2.6.24-12-generic #1 SMP Wed Mar 12 22:31:43 UTC 2008 x86_64 GNU/Linux

$ apt-cache policy nvidia-glx-new
nvidia-glx-new:
  Installed: 169.12+2.6.24.11-12.31
  Candidate: 169.12+2.6.24.11-12.31
  Version table:
 *** 169.12+2.6.24.11-12.31 0
        500 http://ee.archive.ubuntu.com hardy/restricted Packages
        100 /var/lib/dpkg/status

Unfortunately lshw does not work:
$ sudo lshw
PCI (sysfs)
(hangs forever)

I have attached lspci -vvv output, I'll also attach dmesg and syslog bits later.

Tags: hardy
Revision history for this message
Mrts (mrts) wrote :
Revision history for this message
Mrts (mrts) wrote :

There are no errors in syslog, the last line before failure to suspend is (befor that syslog is quiet):

Mar 22 08:15:18 zeus NetworkManager: <info> Going to sleep.
<------- SUSPEND FAILS, NO INFO ---------->
Mar 22 09:24:32 zeus syslogd 1.5.0#1ubuntu1: restart.

Attaching nvida-bug-report.log that has a lot of system information.

Revision history for this message
Mrts (mrts) wrote :

Attaching successful sleep output and failed sleep output.

Revision history for this message
Mrts (mrts) wrote :
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Mrts,

Just curious if you've tested using the nv driver instead . Also, I'm closing the 'linux' task as this is correctly open against "linux-restricted-modules-2.6.24". Thanks.

Changed in linux-restricted-modules-2.6.24:
status: New → Incomplete
Changed in linux:
status: New → Invalid
Revision history for this message
Mrts (mrts) wrote :

Yes, I did test this with the nv driver. Suspend failed exactly the same way.

So it's not a driver issue, I think the 'linux' task should be re-activated.

Perhaps it's related to the following:
$ dmesg | grep bug
[ 0.000000] ACPI: BIOS bug: multiple APIC/MADT found, using 0

But let me stress that suspend sometimes works with nvidia driver. I haven't found any patterns for triggering a successful suspend though (running glxgears does not always help).

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Care to attach your full dmesg output? Also maybe take a look at https://wiki.ubuntu.com/DebuggingKernelSuspend . Thanks.

Changed in linux:
status: Invalid → Incomplete
Revision history for this message
Mrts (mrts) wrote :

Re-attaching newer nvidia-bug-report.log that has full dmesg output among other info.

Revision history for this message
Mrts (mrts) wrote :

A recap: suspend sometimes works (without running glxgears), but this is rare. I haven't found any patterns for triggering a successful suspend.

Adding another, newer syslog excerpt of a failed suspend:

Apr 17 13:45:25 zeus NetworkManager: <info> Going to sleep.
Apr 17 13:45:25 zeus avahi-daemon[5509]: Interface eth0.IPv4 no longer relevant for mDNS.
Apr 17 13:45:25 zeus avahi-daemon[5509]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.42.42.103.
Apr 17 13:45:25 zeus dhclient: receive_packet failed on eth0: Network is down
Apr 17 13:45:25 zeus NetworkManager: <debug> [1208429125.871363] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/net_00_1b_24_2b_32_af').
Apr 17 13:45:26 zeus avahi-daemon[5509]: Withdrawing address record for fe80::21b:24ff:fe2b:32af on eth0.
Apr 17 13:45:26 zeus avahi-daemon[5509]: Withdrawing address record for 10.42.42.103 on eth0.
Apr 17 13:45:26 zeus kernel: [ 6043.572780] ACPI: PCI interrupt for device 0000:05:00.0 disabled
Apr 17 13:46:53 zeus syslogd 1.5.0#1ubuntu1: restart.

Revision history for this message
Mrts (mrts) wrote :

Failing suspend seems still to bite many people. E.g. see the infamous "Ubuntu: More doomed than ever..." http://weblog.infoworld.com/enterprisedesktop/archives/2008/04/ubuntu_more_doo.html .

Changed in linux:
status: Incomplete → New
Changed in linux-restricted-modules-2.6.24:
status: Incomplete → New
Revision history for this message
Mrts (mrts) wrote :

After the updates made to Hardy, the dmesg output has become more verbose.

The problem persists, but I'm attaching another dmesg output for *successful* suspend/resume.

Revision history for this message
Louis-Dominique Dubeau (ldd) wrote :

Mrts, I'm experiencing a problem which looks similar to yours (nVidia hardware but different laptop than yours). One thing you may want to try to help narrow down the problem: can you boot in recovery mode (should be the 2nd option in the Grub prompt), get to the root prompt and see what happens when you put the machine to sleep by running:

$ /etc/acpi/sleep.sh

and then bring it back from sleep. On my machine, the LCD stays blanked even after resume so I know my problem is deeper than X. If your LCD
also stays blanked, then I'll add my own hardware info, etc. to this bug report. Otherwise, I'll seek another report which looks like my case or open a new one.

Thanks!

Revision history for this message
Mrts (mrts) wrote :

In single user mode, sleep.sh seems to put the machine into an undefined state -- the display is properly switched off, but buttons stay lit.

Like you, I'm unable to bring it back from that state (only hard reset helps). Behaviourally, this looks similar to the "Blank screen with a blinking cursor" state under X (except, as I said, the display is switched off).

Revision history for this message
Corey Seliger (seliger) wrote :

I have an HP Pavilion DV9000z (AMD) and am seeing similar issues. However, rather than focusing on the video controller, I want to propose another culprit: the Broadcom Wireless Network Controller

A couple notes on the system:

* Dual Core AMD Turion 64
* nVidia GeForce GO 7600
* Broadcom BCM4312
* 1GB RAM

Basic OS Info (more to come later as attachments):

Linux feathers 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/LinuxDISTRIB_ID=Ubuntu

DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04"

So back to my proposal. For me on my system, if I shut down all applications that make outgoing connections (think Pidgin, Thunderbird, Firefox [if connections are still in a TIME_WAIT state], etc.) are running and have connections to the network made, the system hangs on any hibernate attempts.

The test I did to gain relative confidence in this theory was simple. I ran netstat prior to each hibernate attempt like so:

netstat --inet --inet6

That dumps out all of the current live connections for IPv4 and IPv6 (if there were any). Having services LISTENing does not seem to make a difference as I have sshd running and was still able to hibernate so long as there were no "live" connections at the time of hibernation. So the gist is that if there are no entries in the netstat output, the machine typically will hibernate for me.

I am using the b43 driver as it seems to be more stable now in the general release of Hardy. Also since this is a Pavilion, I am also no longer using the funky kernel workarounds (noapic, irqpoll, noirqdebug) to keep the system from hanging as it appears those patches to clean that up finally made it into the kernel. Prior to that, i was using those workarounds as well as ndiswrapper to get WIFI and let's just say that all bets were off on hibernation, etc.

As far as other testing, I have brought the machine into single user mode and have tried to manually suspend and hibernate the machine. Both work great except for suspend. When I resume, I have to issue "vbetool dpms on" to turn the backlight back on...

This might be an offshoot into another bug if it proves to be separate issue. It may already even be a bug that I have yet to find. But in any case, I would love to see others try to see if this has any effect on their hibernation outcomes.

Revision history for this message
Corey Seliger (seliger) wrote :
Revision history for this message
Mrts (mrts) wrote :

My and Louis's case looks different. We can't suspend in single-user mode.

Revision history for this message
Louis-Dominique Dubeau (ldd) wrote :

I think my symptoms are closer to Mrts than Corey's.

Hardware:
Sager NP2090 (aka Compal IFL90) with bios version 1.13
Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
nVidia 8600M GT 512MB
2Gb Ram

I am running Kubuntu 8.04, 32bit version. I did an alternate install and use LVM to manage my partitions. (I've also installed Ubuntu 8.04, 32bit: the problems were the same.)

The suspend problems have happened in Gnome, KDE, KDE4 and in single user mode.

Symptoms:

1. If I use the nVidia driver packaged with [K]Ubuntu, the machine always sleeps but sometimes does not resume. (I typically have "desktop effects" on. Maybe this achieves the same effect as having glxgears running.)

2. If I use the nv driver, the machine always sleeps but NEVER resumes.

3. If I boot in single user mode, the machine sleeps and resumes but the internal LCD does not turn back on after resume. I know the OS is still running because I can issue a shutdown -r to properly reboot the machine. Even issuing a manual vbetool dpms on does not turn the LCD back on. There is a difference in the ACPI LCD state before and after resume:

Before
/proc/acpi/video/VGA/LCD/state
state: 0x1f
query: 0x01

After:
/proc/acpi/video/VGA/LCD/state
state: 0x1d
query: 0x01

Network activity or lack of network activity has no effect whatsoever on whether or not the machine sleeps or resume.

Hibernate behaves the same. In Gutsy everything worked properly. Because I ran Gutsy for a while with a Hardy kernel and did not experience any problem then, I think the problem is not with the kernel itself (and probably not with the nVidia driver either). Rather, I think something in userspace is interacting badly with the kernel. I have checked vbetools and udev and saw nothing there which was problematic.

However, and this is **preliminary**, I think that setting:

vm.mmap_min_addr = 0

in /etc/sysctl.conf

I know that there is a line in the default sysctl.conf shipped with Hardy which sets that parameter to 65536. This line was not present in Gutsy but is present in Hardy. At the moment, I would say that after changing that parameter to 0, stability with the nVidia driver seems to have improved (or maybe I'm just really lucky). I have not tested again with nv. Unfortunately, it does not improve the situation in single user mode: the LCD stays off after resume. (Maybe there are really multiple bugs.)

Revision history for this message
Corey Seliger (seliger) wrote :

Louis,

You are probably right -- sounds like there are three potential bugs:

* Sleep/Hibernate with NVidia
* Sleep/Hibernate with Broadcom Wifi
* Resume in Single User does not restore the backlight

Just out of curiosity, is the machine frozen when when you resume in Single User mode? For me, the system comes back, but does not have the backlight turned on. I can type commands blindly (or if I hit backspace on an empty command line, the system responds with a beep).

What happens if you blindly type in "vbetool dpms on" manually after resuming in single user land?

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Mrts,

Just to see if it makes a difference, care to test the Intrepid Ibex 8.10 kernel? It was most recently rebased with the upstream 2.6.25 kernel and is currently available in the following PPA:

https://edge.launchpad.net/~kernel-ppa/+archive

If you are not familiar with how to install packages from a PPA basically do the following . . .

Create the file /etc/apt/sources.list.d/kernel-ppa.list to include the following two lines:

deb http://ppa.launchpad.net/kernel-ppa/ubuntu hardy main
deb-src http://ppa.launchpad.net/kernel-ppa/ubuntu hardy main

Then run the command: sudo apt-get update

You should then be able to install the linux-image-2.6.25 kernel package. After you've finished testing you can remove the kernel-ppa.list file and run 'sudo apt-get update' once more. Thanks

Revision history for this message
Mrts (mrts) wrote :

I installed linux-image-2.6.25-1-generic (2.6.25-1.2ubuntu5) from the kernel-ppa archives and suspend seems to work with it.

However, as is the case with Louis, backlight is not activated after resume.

What I did:

* booted to single user mode
* run /etc/acpi/sleep.sh
* the machine suspended correctly
* resumed the machine from sleep successfully, EXCEPT backlight was not turned on
* I was able to enter commands "blindly" at the terminal, including two successful sleep/resume cycles (backlight was never turned on)

I also tried with X. As nvidia kernel modules were missing from the kernel-ppa archive, X started in "low-resolution" mode (vesa driver probably). Similarly to single-user mode, I was able to suspend and resume the machine, but backlight did not turn on after resume.

So it looks we have two bugs here. The suspend bug has been fixed in 2.6.25 for my case, but it is still present in 2.6.24.

I have a gut feeling that the backlight bug is either nvidia-related or, as Louis mentioned, has something to do with userspace tools.

Revision history for this message
Mrts (mrts) wrote :

Leann, please let me know if I can debug this further.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Mrts,

Thanks for testing and the update. It seems this is partially fixed with the 2.6.25 kernel for you. Unfortunately as you've noted linux-restricted-modules for 2.6.25/2.6.26 is not yet available. If you don't mind, we'd appreciate you testing once it is available. I'll try to notify you via this report as well. It may also help if you could update the description/title of this bug report to reflect your latest test results. Thanks.

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Mrts (mrts) wrote :

Thanks, I will be glad to test once restricted-modules has landed.

As for updating the description -- it looks still relevant to me once I remove the blame on nvidia?

description: updated
Revision history for this message
dvo (mueller8) wrote :

For Asus M2NPV-VM, nVidia GeForce 6150, I found the following solution - maybe it helps:
Simply update the BIOS (from revision 0504 to revision 1301) as recommended at
http://fixunix.com/kernel/337502-swsusp-amd-x2-64-2-6-24-regression.html

BTW, on that machine I still have problems with pm-utils, therefore I use acpi-support:
In /usr/lib/hal/scripts/linux/hal-system-power-hibernate-linux
replace /usr/sbin/pm-hibernate $QUIRKS
by /etc/acpi/hibernate.sh force
In /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux
replace /usr/sbin/pm-suspend $QUIRKS
by /etc/acpi/sleep.sh force

I use these settings in /etc/defaul/acpi-support:
ACPI_SLEEP=true
ACPI_SLEEP_MODE=mem
SAVE_VBE_STATE=false
POST_VIDEO=false
SAVE_VIDEO_PCI_STATE=true
USE_DPMS=false

Revision history for this message
Mrts (mrts) wrote :

Both suspend and hibernate work out of the box now. As I updated the BIOS, I'm not sure whether this or the recent kernel updates helped. Anyhow, thanks!

Changed in linux:
status: Triaged → Fix Released
Revision history for this message
Mrts (mrts) wrote :

Works now after BIOS update and recent kernel updates.

Changed in linux-restricted-modules-2.6.24:
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.