hard lock up after suspend

[MFeif]

Binary package hint: xorg

I have a Jaunty x86_64 install with an NVidia GPU that used to perform flawlessly: acceleration, reliable suspend/resume, etc.

At some point recently after a kernel upgrade, the system began to have hard-lockups. I couldn't find rhyme or reason, till now. I am able to ssh into the box and I saw the tail of dmesg (attached).

It seems that now, sometime about 5 - 10 minutes after a seemingly successful resume, the screens simply lock up, keyboard goes dead, even num/caps lock are unresponsive.

Again, this exact same hardware configuration on this exact same OS used to be rock-solid; no need for a reboot ever. Now, it seems that anytime after a suspend I get this crash.

I wish I could tell you the old/new kernel versions; sorry, it hasn't been that cut-and-dried.

I can't do a bug report from the machine because it is unresponsive (can't even soft-reboot) so I'm doing a manual report. Please let me know if there's anything else I can provide.

[MFeif (matt-feifarek)]

Update: it just happened 3-4m after a clean boot. This time it happened "harder"... I could not even ssh into the box to try and inspect logs. Later inspection of the logs (after a re-boot) shows nothing in /var/log/messages or syslog or Xorg.0.log; they didn't get a chance to write before it really locked up.

Another interesting point. After a re-boot, I have no video at all, and if I ssh into the box, lspci doesn't even show a video card on the bus.

Probably unrelated, but maybe another clue: I have two drives in this box under mdadm, just mirroring eachother. After these hard crashes, they have to resync. It takes a while, and always works, but maybe it's a clue.

Seems like Something Bad is happening, perhaps hardware, but I don't know where to start, and don't want to just start spending money replacing components without a better educated guess. Any expertise? Thanks.

[Bryce Harrington (bryce)]

You said you updated the kernel - the nvidia driver is a proprietary binary driver compiled against a particular kernel version. If you change kernel versions, of course it breaks. So you need to keep linux and nvidia versions in sync.

[MFeif (matt-feifarek)]

No, of course that's not it.

When you get a new kernel, if you haven't compiled the module for nvidia it simply isn't there, and simply will not work. Note that I didn't say that my X won't start, or that I no longer have 3D acceleration, or that my nvidia drivers are no longer present.

That's not what's happening to me. The module is there; it has been compiled for the current kernel.

I continued to have this problem up until and including yesterday.

I have upgraded today to Karmic; we'll see how I do now.

I'm changing the status back from Invalid.

[bugbot (bugbot)]

This bug report was filed against an old version of Ubuntu.
Can you confirm whether this is still an issue in natty?

If you don't mind, it would be very helpful if you could update the bug
report in launchpad to 'Fix Released' if it is no longer an issue for
you, or if it is still occurring under natty, please tag the bug 'natty'
so it's easier for us to track.

[bugbot (bugbot)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.