Log in

No account? Create an account
Suspend with nVidia graphics - Jeremy's Thoughts
Cycling, Fedora, MIT SDM and Miscellany

Jeremy Katz
Date: 2007-10-23 16:20
Subject: Suspend with nVidia graphics
Security: Public
With the large pile of laptops I've tested, one thing that was pretty clear was that suspend on laptops with nVidia graphics hardware is a bit less reliable than anywhere else. At first, I thought that it was just a lack of quirks in hal for the machines in question as they didn't have any. But with some more looking, it's looking more and more like there are bigger problems and that we either don't have the right infrastructure to quirk it or (more likely), there's a need for some work within the X driver and/or the kernel to properly poke the chip into working again post-suspend. Given that time for that is rapidly dwindling and I'd rather not have people try to suspend and have it fail, I'm building a pm-utils that will (by default) show that suspend isn't supported on machines with nVidia graphics using the nv driver. You can override this by creating a file in /etc/pm/config.d that contains a line


While not ideal, hibernate works and this way at least the unsuspecting user doesn't hit the problem. A better fix for this is likely to need to come either from nVidia within the nv driver or from the work being done on the nouveau project.
Post A Comment | 8 Comments | Share | Link

User: (Anonymous)
Date: 2008-05-09 20:23 (UTC)
Subject: Why suspend to ram resume and nv are so troublesome
The PC platform defines the video BIOS size to be 64Kbytes. Alas, that is no longer enough space to hold all the code to reinitialise a GPU (so it's actually an overlay) and there is no guarantee that any given page of it is available when you go to call BIOS services. Further you may not even be able to get to it after POST - the ability to do so is dependent on how the system OEM did the final board design and integration.

Normally you do a POST by calling a given video BIOS address (c000:0003) in real mode but this is so unreliable after the system has initially booted that NVIDIA BIOSes do nothing when this area is called. Reinitialisation of the card is instead handled within the X driver. This decision really makes sense because it gives the most reliable behaviour across all hardware without endless special cases.

Sadly NVIDIA have yet to explain how to do asic init (the reinitialisation) that their binary only drivers do. Consequently the open source drivers for NVIDIA cards (like nv) do not have code to do this. Thus they go and touch the GPU after resume (causing it to become wedged) and never receive a reply.

This does not affect a hibernate/resume cycle because the video BIOS will have been POSTed during the cold boot. This also explains why VESA driver / non X case often works (because the GPU is not touched).

(The above is paraphrased from an X developer)
Reply | Thread | Link

my journal
September 2013