Suspend with nVidia graphics

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.

8 thoughts on “Suspend with nVidia graphics”

  1. Does this give us an option of changing the default state of this config in an update package if and when the kernel/driver issues get sorted out in the F8 timeframe?


  2. Yep. All we have to do is push whatever actually fixes the problem (be it xorg-x11-drv-nv, the kernel, or whatever) and then push a new pm-utils with the patch I added today pulled.

    Also, to help encourage getting the right fix, I haven’t applied the pm-utils patch upstream or on the devel branch

  3. Re: Fedora on the Dell Inspiron 640m – Suspend/Resume

    The check actually doesn’t trigger if you’re using the nvidia driver as I’ve seen a few reports that it makes things work better.

    Which makes me that much more convinced that it could be fixed in the nv driver. nVidia — do you hear me? Fixes appreciated! 🙂

  4. what would ubuntu do?

    I think ubuntu has this problem solved, by messing with vbetool posting I think…

    I’ll check with the ubuntu guys..

  5. Re: what would ubuntu do?

    According to the intarwebz, Ubuntu has the same sorts of problems with nv hardware in Gutsy. But if you hear otherwise, that’d be good to know

  6. poking around the web for an nv fix

    What comes to light after trying to find a fix for this for my laptop (hp tx1000, nvidia 6100) is that the proprietary nv driver knows how to re-initialise the video hardware and the xorg doesn’t. So although some machines can suspend and resume fine (with quirks) you won’t get the video back (in any form, text or graphics) with the xorg driver until someone figures out how to to this or nvidia let someone know.

  7. 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)

Comments are closed.