[lucid regression] random graphics effects after resume from suspend to RAM

Attaching pm-suspend.log. Shouldn't ubuntu-bug have done that automatically?

Attaching output of 'lspci -vvv'.

Attaching screenshot of desktop after resume. That is not my standard desktop background!

On Wednesday 20,January,2010 04:44 PM, Per Ångström wrote:
> Attaching screenshot of desktop after resume. That is not my standard
> desktop background!
>
> ** Attachment added: "Desktop after resume.png"
> http://launchpadlibrarian.net/38123737/Desktop%20after%20resume.png
>
Looks like a mixture of Xorg (using nvidia) horror and either GNOME Power
Manager or DeviceKit-Power acting up. Could you do the following:

1. Kill gnome-power-manager (command: killall gnome-power-manager)
2. Run `gnome-power-manager --verbose` in a terminal, suspend and resume and
attach the output here.

That should tell us something regarding why your gnome-power-manager thinks
you're on battery when you resume.

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

This actually appears to be two separate bugs file as one bug report. Could you separate out the battery issue into a new bug report, please? File it under the "gnome-power-manager" package. The rest of it is probably an nvidia issue.

I have filed the battery issue: bug #510118.

After the latest updates, with kernel 2.6.32-11-generic, I no longer have the strange new desktop background, but the other issues remain the same.

I have the same graphical effects when I resume from hibernation on the same machine.

I can confirm that there are artefacts after resume. The ones I'm seeing are different though (attached screenshot). The rest if the same - random characters in console, having to ctrl+alt+f7 to get to the X session. It may be related to hal->udev migration?

I doubt that this problem is related to the nvidia driver. I tested a suspend from the virtual terminal (stopped X and unloaded the nvidia module) - after resume, the monitor is black with some white rectangles but switches to standby soon. Switching to a vt with ctrl-alt-f* does not work. Rebooting the system with ctrl-alt-del works, though.

I have this problem on my desktop and notebook computer - both have a nvidia card (but different ones). So maybe it is hardware related, but not the the nvidia-binary driver itself. Suspend/resume worked on both system without any problems in the last couple of Ubuntu releases.

A good way to create new wallpapers...

Anyone could try to remove plymouth and see it works? From bug #510524.

I just checked: removing plymouth does not make any difference for me.

No better luck with latest nvidia-current, 190.53-0ubuntu12.

Per,
   Would you mind running apport-collect -p linux 510004
to get us the rest of the data.

Thanks,

-JFo

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

What is the Triage/How to fix it?

If a but report is triaged it doesn't mean that there is a fix already available. It just means to the developers, that the bug is confirmed and that there is enough information about it, so that someone can pick the problem up and work on it.

Not sure, if this is helpful, but https://bugs.launchpad.net/ubuntu/+source/linux/+bug/513890 seems to be similar. All reports about this kind of problem seem to use 2.6.32 + nvidia. I have tested resume with 2.6.31, but same problem with that.

I noticed, that I can switch to tty1. At first, nothing happens, but after some seconds the screen switches off, then i can switch to tty7 again and use X with massive glitches.

Switching between the vts works only sometimes, so it is not a reliable workaround. The graphic was normal after a resume on karmic, even with version 190 of the nvidia drivers. I've tried the linux kernel 2.6.33 (from the ubuntu kernel archive) on lucid, but it didn't work either.

As hal is in the process of being deprecated, the suspend quirks were integrated into pm-utils (see https://wiki.ubuntu.com/Halsectomy). Could there be something missing or gone wrong with the conversion? It looks to me as if the system does not use the proper quirks for the hardware when suspending/resuming. Is there a way to check which quirks are applied now?

Christian,

indeed quirks handling was broken in pm-utils until last week. Do you have 1.3.0~rc3-1? Can you please try again with that one?

If it does not work still, please do

  sudo rm /var/log/pm-suspend.log
  sudo PM_DEBUG=true pm-suspend

then resume (or reboot if it's broken) and attach /var/log/pm-suspend.log.

Martin,

thanks for having a look into it.

I've done a suspend as you've suggested, please see the files attached.

Luckily, I can ssh into my computer, so I could get some more data. After a resume, the X server is using nearly 100% of the cpu (I could only take a screenshot). I did an strace of the X server, which I will attach too, hope it is of some use. Stopping KDM and restarting it brings back my computer with a normal display. So is it a X problem, not being able the recover from a suspend?

Christian, it seems that at least the quirks handling seems to work. You are using the proprietary nvidia driver, which does not need any quirks (and thus pm-utils disables them, just like hal did). Also, at least the original reporter's problem (http://launchpadlibrarian.net/38123737/Desktop%20after%20resume.png) does not seem related to quirks.

I believe the pm-utils side here is fixed, but there's still a problem with the graphics driver, of course (keeping those tasks open)

@Per:

There is a current issue with nvidia resume in lucid that is being tracked in bug 488720. Can you check if the solution noted there fixes everything for you? If it does, please mark this bug as a duplicate of it. If not, please describe the behavior that still persists after attempting the fix noted there.

Thanks

I take it the solution was to edit /usr/lib/pm-utils/sleep.d/98-video-quirk-db-handler and remove "add_parameters --quirk-no-chvt" in the using_nvidia block. Well I did that, and sorry, I see no difference at all.

The screen is still garbled and it takes some virtual-terminal switching until the mouse pointer turns up and I can see the screen saver's login prompt. Back in Gnome (or KDE) many parts of the screen are blanked out.

After resuming, if I just wait patiently without trying to switch between virtual consoles, I can see the screen flicker from time to time. It seems that is only after waiting for some thirty seconds that the VT-switching trick will work.

@Chase: the fix from bug #488720 worked for me, thanks for the hint!

My nvidia card is: GeForce 8500 GT

N.B.: the problem also occurred with the nv-driver.

The fix in bug #488720 worked for me, too.

As I tried to explain above, I have applied the patch and I'm still having the same problems as before. Am I now the only one left with random graphics after resume?

Sorry, unduplicating again then.

The fix #448720 worked for me as well.

I have a Dell XPS M1330 with GeForce 8400M GS.

@Per:

Which driver are you using? nvidia or nv (or vesa)?

Thanks

@Chase:
nvidia.

I get the impression that KDE is more severely affected by this bug than Gnome: KDE is barely usable after resume, with large portions of the display more or less permanently blanked out, whereas Gnome can be made to repaint more of the screen.

A screen shot of my KDE desktop a few minutes after I have resumed from suspend.

I have the same problem, but I think I think the real problem here is not suspend/resume but VT handling.
using the suggestion to remove "add_parameters --quirk-no-chvt" works for me -- but only I have have only one user logged in.

If I have more than one user logged in (= more than one X server running), than one of the Xorg processes hangs and uses 100% of one CPU core. Swiching to that user's Xserver/VT (via alt+ctrl+fX or using the graphical session switcher) hangs the system.

If that happens, I have to ssh into that machine and kill -9 the Xorg process - than at least the other users session can live on.

If I add "add_parameters --quirk-no-chvt" again and resume from sleep with two users logged in than I have to press alt+ctrl+f1, alt+ctrl+fX and have a 50% chance of going to the "good" Xorg that is not hanging. If I hit the "bad" Xorg that hangs at 100% cpu, I have to ssh and kill -9 the Xorg process to make the system usable again....

@andoreasu:

Your issues are different than those discussed in this bug. I suggest opening a new bug to deal with the resume failure on multiple X sessions.

Thanks

@Chase Douglas

I disagree.
To me it seems to be the same bug.
It can be triggered by suspend/resume or by switching betreen multiple X sessions.

@andoreasu:

The original issue is: After a suspend/resume of a single X session, artifacts are seen and switching between VTs fixes some, but not all, of the issues.

Your issue is: After a suspend/resume with multiple X sessions, one of the X sessions hangs indefinitely (Christian Schürer-Waldheim had a symptom that looks similar to yours, but removing --quirk-no-chvt fixed his issues).

These are separate issues, so you should open a new bug to deal with your issue. If it happens to be that they are two separate symptoms of the same underlying issue, we can easily link one bug as a duplicate of the other. It is much easier to go that route than to continue trying to fix two different symptoms in the same bug here.

@Per:

Can you run xwininfo on one of the corrupted displays after you resume, and then paste the output here? We have a theory that hinges on the result of the properties "Backing Store State" and "Save Under State".

Thanks

@Bryce:

Can you take a look at this bug? It's getting a little beyond the grasp of our understanding in the kernel team.

Thanks

OK, this is after resume:

xwininfo: Window id: 0x160001e "x-nautilus-desktop"

  Absolute upper-left X: 0
  Absolute upper-left Y: 0
  Relative upper-left X: 0
  Relative upper-left Y: 0
  Width: 1280
  Height: 800
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners: +0+0 -0+0 -0-0 +0-0
  -geometry 1280x800+0+0

This is exactly the same output as before suspending.

Well that's unfortunate. It rejects our theory that X wasn't keeping the window data around and was leaving that up to the graphics card, which may have dropped the data during the resume.

So this is really getting close to the "we can't support nvidia closed source driver" issue, but perhaps Bryce Harrington has some more thoughts. This issue is pretty well outside of the kernel team's expertise at this point.

It's been a few days that I haven't booted into Lucid, but today I find the resume experience even worse than before: not only is the display garbled after resuming, but now I see seemingly randomly blinking pixels in a pattern that changes as the screen is updated.

Thanks for your efforts though!

A snapshot showing how bad it looks today.

Maybe this is interesting: I find that even after exiting KDE, forcing a restart of X (ALT-sysreq+k) and entering Gnome, I can still see some pixels changing color.

@Per Angstrom - I am seeing exactly the same corruption on my MacBook Pro 5,1, with an NVIDIA 9600M GT GPU running latest Lucid with Nvidia 195.36.03 - I noticed that Nvidia have released an updated driver 195.36.08 (ie .03 -> .08) - I will try and test this later when I get home.

@Bryce: Are you planning on shipping .08 in Lucid since its now the latest stable release from Nvidia and MAY help to solve this issue?

As I said, I'll try manually installing it when I get home to test it out and report back if it helps.

Just noticed 2 other comments confirming similarly back in bug #488720 - ie. comments 19, 20 and 21 in that bug report suggest that reverting to the old 190.53 driver should fix this - will also test this and report back.

"Are you planning on shipping .08 in Lucid since its now the latest stable release from Nvidia ..."

Not from what I see at ftp://download.nvidia.com/XFree86/Linux-x86_64/, which still shows 190.53 as the latest stable driver.

"... and MAY help to solve this issue"

What in the change log (http://www.nvnews.net/vbulletin/showthread.php?p=2196696) suggests that to you?

@Noel: It is the latest stable release - http://www.nvnews.net/vbulletin/showthread.php?t=122606 - 190.53 is the old stable release.

Nothing in particular makes me think it could help solved this except maybe 'Fixed a bug that caused screen corruption after an application released a GLX_NV_present_video device' - I doubt this lists every single change which was made to the driver anyway - but it's worth a shot, considering 195.36.03 is the first driver which I've noticed any issues with (ie. both the 190 and 185 series worked great on my hardware in previous versions of Ubuntu) - and you yourself have confirmed on bug #488720 that reverting to 190.53 fixes this, so its likely an issue with 195.36.03 specifically so you never know...

Downgrading to nvidia-current_190.53-0ubuntu14 unfortunately doesn't fix this for me - see attached screen shot and notice white blocks behind panel and docky windows.

At this stage since the release notes say:

Because of the new alternatives system used for nvidia driver packages, the nvidia installer from NVIDIA's website currently doesn't work.

I am hesitant to even try installing 195.36.08 using the Nvidia installer, so I am not to sure what to try next...

Out of interest after resuming from suspend with 190.53 I get the following errors from the nvidia driver in dmesg:

NVRM: Xid (0002:00): 13, 0001 00000000 00005097 00000538 3f800000 00000080
NVRM: Xid (0002:00): 65, CMDre 00000000 00000080 00000000 00000005 00000005
NVRM: Xid (0002:00): 65, CMDre 00000000 00000080 00000000 00000005 00000005
NVRM: Xid (0002:00): 65, CMDre 00000000 00000080 00000000 00000005 00000005
NVRM: Xid (0002:00): 65, CMDre 00000000 00000080 00000000 00000005 00000005
NVRM: Xid (0002:00): 65, CMDre 00000000 00000080 00000000 00000005 00000005
NVRM: Xid (0002:00): 65, CMDre 00000000 00000080 00000000 00000005 00000008

Whilst with 195.36.03 I get the very similar:

NVRM: Xid (0002:00): 13, 0001 00000000 00005097 00000548 3f800000 00000080
NVRM: Xid (0002:00): 54, CMDre 00000000 00000080 00000000 00000005 00000005
NVRM: Xid (0002:00): 54, CMDre 00000000 00000080 00000000 00000005 00000005
NVRM: Xid (0002:00): 13, 0001 00000000 00005097 000015e0 00000000 00000040
NVRM: Xid (0002:00): 54, CMDre 00000000 00000080 00000000 00000005 00000005
NVRM: Xid (0002:00): 54, CMDre 00000000 00000080 00000000 00000005 00000005
NVRM: Xid (0002:00): 54, CMDre 00000000 00000080 00000000 00000005 00000008

I have downgraded to nvidia 173.14.22 and that gets rid of the corrupted graphics. I still have to switch between virtual consoles until I can eventually activate the display.

Upgrading to kernel 2.6.33-020633-generic solves all issues for me. I cannot use nvidia 173.14.22 with that kernel, but 195.36.03 works fine.

Per's test on the latest kernel gives us some good information. On top of that, we have made a decision to base Lucid on the 2.6.32 kernel, but with the drm stack backported from 2.6.33. The first official kernel with the .33 drm stack has yet to be released, but there is a test kernel available in the "red" ppa: https://launchpad.net/~apw/+archive/red. It would be very helpful for us if someone were to test this kernel to see if it fixes the issue. If it does, great. If not, we still have a good lead on the fact that stuff is broken in 2.6.32 but fixed in 2.6.33.

Have noticed that now I don't get corruption after resuming (after a fix to pm-utils I think) but instead X crashes upon resuming, leaving me staring at the gdm login screen.

Just noticed Nvidia just released an updated driver: 195.36.15 which may fix this second issue, from http://www.nvnews.net/vbulletin/showthread.php?t=148947

 - Fixed a bug that caused the X server to crash when rendering occurred while the X server was not on the active VT.
 - Fixed a regression that caused the driver to fail to properly adjust the GPU fan speed on some GPUs.
 - Fixed a bug that prevented performance level transitions on recent GPUs with SDDR3 and GDDR5 memory.

So if anyone can package it up in a PPA it would be great to test and see if it resolves this - I am hoping the crash is a result of the first listed change and hence is now fixed.

I don't normally check these things as Ubuntu usually doesn't do this sort of thing, but the only driver I can load in Lucid is 195.36.08 (the 173 driver fails), which is from my understanding a beta driver. The latest production is 190.53 from Nvidia's website. Now is this not a bit crazy for a LTS? Especially considering NVidia just pulled a production driver for Blake's 7 because it was burning out boards:
http://forums.nvidia.com/index.php?showtopic=162344

Now if you are packaging a beta driver, then the user (who cannot change to a production driver) has no legal recourse if the board fries, because they are using a beta driver. I understand they have little recourse anyway but I did get my motherboard replaced. So is it possible to use the production driver or at least have the option to revert to it.

Or is there something I am missing here?

It would also be nice to see if I can suspend and hibernate again using the production driver.

Indeed it looks like the current Nvidia drivers may be bad:
http://linuxers.org/article/linux-nvidia-drivers-might-also-have-gpu-fan-speed-issue

I am switching to nouveau as I quite like my laptop!

@mbawsa: The 195.36.15 driver which I linked to above fixes the gpu fan issue and so should be safe, as is the 190.53 driver.

Thanks Alex, but I still question the logic on why a beta driver and ONLY a beta driver was selected for an LTS.

I have what sounds like a similar problem on my Thinkpad T41, which has an ATI RV250 GPU. This is 32 bit Lucid, upgraded from Karmic. Suspend/resume worked fine in Karmic. I'm using the default open-source ATI drivers. This is a really old GPU by the way.

Hibernate/resume works fine in Lucid. Suspend seems to work fine, both when closing the lid, and clicking the Sleep icon. When I resume, either by opening the lid or pressing the power button, everything seems to come back up, but initially the screen is blank, though I can tell the backlight is on. Then, over the course of a few seconds, a strange marble-like pattern starts to emerge on the screen, and it gets progressively brighter and brighter over the course of a few minutes, until the whole screen is full white. There's no mouse cursor visible. I can't seem to switch to another TTY. If I remember correctly, the fan speed stays pretty high, so the cpu might be under some load. I think the wireless indicator turns on. There's the normal occasional hard drive activity, and I'm pretty sure one time I punched in my password, and by dead reckoning managed to click the system menu, and then the "switch off" item, and got the system to shut down normally. Otherwise, I have no choice but to do a hard power off.

Seeing as I don't have an nvidia gpu, should I open a new bug, or can someone point me to an existing bug?

@Martin Spacek:

Since your issue is different, you need to find a bug that looks like your issue, or open a new one.

Thanks

As per comment #77, I'm closing out this bug.

Chase Douglas wrote:
> As per comment #77, I'm closing out this bug.
> status: Confirmed → Invalid

What does "Invalid" mean in this context?

For the record: With nvidida 195.36.15 and kernel 2.6.32-17-generic #26-Ubuntu, I'm still seeing the same corrupted graphics after resume from suspend. Also, I still have to switch between virtual consoles and wait several seconds just to get a working display again.

I'm sorry I didn't get round to trying out the test kernel in the "red" ppa: https://launchpad.net/~apw/+archive/red (see comment #78) . Has nobody at all tested it?

Is my only viable remedy to stick with the 2.6.33 kernel then?

@Per:

Sorry, I misread your comment and thought things were working on the Lucid kernel. I'm moving this back to Triaged then.

I have the same issue with an XPS 1210 (with an nvidia 7400 card). Interestingly, I have no nvidia drivers installed and nor do I have compositing/effects enabled.

I am using Kubuntu 4.4.2 and suspend/resume is not working for me - sometimes I get the artifacts on screen. Sometimes I have a long blank screen and I have to hard reboot.

I have now updated to Lucid Lynx final, running 2.6.32-22-generic. The graphics corruption is still present after resume from suspend.

I installed Lucid Lynx to another partition on the same machine. I can now see the artifacts only briefly before the login screen, but apart from that the graphics corruption is gone.

Per Ångström, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Closing this bug with Won't fix as this kernel / release is no longer supported.
Please feel free to open a new bug report if you're still experiencing this on a newer release (Bionic 18.04.3 / Disco 19.04)
Thanks!