[180.08] Screen off after suspend to ram

[olifre]

Sorry for the late answer, there was a lot of other stuff to do :P.

Well, there is an option 'MODULES=""' in ACPI-Support. However, it seems that Intrepid does not use these options anymore, but now does standby using the kernel (or some other method). Thus, all the other ways tried here can't work.

Currently, I'm lacking time to do further investigation - maybe somebody else knows more about Ubuntu's way to suspend?

I am not sure whether the X-Server really would have to be unloaded - maybe, the module is unloaded / loaded before the CPU is completely reactivated. But, as I said, I don't know so much about the newer methods to standy.

TuxOnIce might do a better job, though - however, you'd have to recompile your kernel, and you need time for that :P.

[overkll]

I don't know if this pertains to 180.xx, but I've needed it for my Geforce 8400M/MCP768 based laptop in order to get suspend AND hibernate to work with ANY of the newer stable nvidia drivers 173+. Works with Gentoo and Ubuntu Intrepid. I couldn't even boot the Hardy Heron or Intrepid beta live-cds without it.

Try adding `pci=nomsi` to your bootloader's kernel command line.

[huiii]

Originally Posted by olifre

Sorry for the late answer, there was a lot of other stuff to do :P.

Well, there is an option 'MODULES=""' in ACPI-Support. However, it seems that Intrepid does not use these options anymore, but now does standby using the kernel (or some other method). Thus, all the other ways tried here can't work.

Currently, I'm lacking time to do further investigation - maybe somebody else knows more about Ubuntu's way to suspend?

I am not sure whether the X-Server really would have to be unloaded - maybe, the module is unloaded / loaded before the CPU is completely reactivated. But, as I said, I don't know so much about the newer methods to standy.

TuxOnIce might do a better job, though - however, you'd have to recompile your kernel, and you need time for that :P.

As far as I know, there was a change performed in suspend/hibernation methods with the release of ubuntu hardy;
since then the suspend-stuff is done by pm-utils and not by acpi anymore.
so, if we need to investigate on how to deal with the video-card during suspend, i guess we need to understand how pm-utils work...

[huiii]

Originally Posted by overkll

I don't know if this pertains to 180.xx, but I've needed it for my Geforce 8400M/MCP768 based laptop in order to get suspend AND hibernate to work with ANY of the newer stable nvidia drivers 173+. Works with Gentoo and Ubuntu Intrepid. I couldn't even boot the Hardy Heron or Intrepid beta live-cds without it.

Try adding `pci=nomsi` to your bootloader's kernel command line.

what does it do, actually, `pci=nomsi`?

[overkll]

It disables Message Signaled Interrupts system wide. From menuconfig:

  │ CONFIG_PCI_MSI:                                                         │  
  │                                                                         │  
  │ This allows device drivers to enable MSI (Message Signaled              │  
  │ Interrupts).  Message Signaled Interrupts enable a device to            │  
  │ generate an interrupt using an inbound Memory Write on its              │  
  │ PCI bus instead of asserting a device IRQ pin.                          │  
  │                                                                         │  
  │ Use of PCI MSI interrupts can be disabled at kernel boot time           │  
  │ by using the 'pci=nomsi' option.  This disables MSI for the             │  
  │ entire system.                                                          │  
  │                                                                         │  
  │ If you don't know what to do here, say N.

EDIT: IIRC, Ubuntu ALWAYS enables MSI in their kernels.

[ledoc]

In my experience, you can have other devices use MSI (like soundcard, ethernet) without necessarily causing suspend problems. But having the nvidia module and GPU use MSI will break suspend.

I think there is an option for the nvidia module to enable/disable MSI for it (check in /proc/interrupts what is used).

[nevion]

pci=nomsi and NVreg_EnableMSI=0 changes nothing. I've tested them both in all permutations. Each time my machine hardlocked before it could even turn on the screen.

Nvidia's driver is what broke, the distributions have not changed, at least not ubuntu/opensuse. Nvidia can you please comment on the matter?

[tomee]

I am not sure yet, but it seems like applying the following changes to /usr/share/hal/fdi/information/10freedesktop/21-video-quirk-nvidia.fdi helps in Ubuntu Intrepid:

14,15d13
<         <remove key="power_management.quirk.s3_bios"></remove>
<         <remove key="power_management.quirk.s3_mode"></remove>
18a17,18
>         <merge key="power_management.quirk.s3_bios" type="bool">true</merge>
>         <merge key="power_management.quirk.s3_mode" type="bool">true</merge>

(Lenovo T61, NVidia NVS140m)

[perfectska04]

Originally Posted by tomee

I am not sure yet, but it seems like applying the following changes to /usr/share/hal/fdi/information/10freedesktop/21-video-quirk-nvidia.fdi helps in Ubuntu Intrepid:

14,15d13
<         <remove key="power_management.quirk.s3_bios"></remove>
<         <remove key="power_management.quirk.s3_mode"></remove>
18a17,18
>         <merge key="power_management.quirk.s3_bios" type="bool">true</merge>
>         <merge key="power_management.quirk.s3_mode" type="bool">true</merge>

(Lenovo T61, NVidia NVS140m)

What exactly does this do? Does it completely fix resuming from suspend?

[nevion]

I've tried this method using the fdi and - as usual - there is no change in behavior. In my earlier posts I mentioned that I could resume if I suspended and resumed back to back only seconds apart - I theorize this has to do with memory discharge over time in the suspend power state and the driver's assumption of memory state upon resume. If the memory loses its state from discharging too much over a few seconds (something dram is known to do) then the driver is foobared on resume. Now if you make it in that narrow window where the memory state is intact, then things resume fine. This is the card's memory btw, not system memory. So it would seem it's a case of not storing and recovering the card's state properly. So again, suspend is completely broken atm. Somebody would have posted a working configuration by now if one existed.

*Cough* nvidia, enough people have gathered on this now right? Can haz driver fix now pleez?

[tomee]

Originally Posted by perfectska04

What exactly does this do? Does it completely fix resuming from suspend?

Don't know, haven't tested extensively.
Before these changes resume always broke, now for 5 tries that I did it always worked.

[nevion]

Originally Posted by tomee

Don't know, haven't tested extensively.
Before these changes resume always broke, now for 5 tries that I did it always worked.

Have you tried waiting some period of time (>1 min) before trying to resume? Does it resume consistently then?