| Summary: | [GM965 GEM KMS] GPU wedge during resume | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Ben Gamari <bgamari> | ||||||||
| Component: | DRM/Intel | Assignee: | Jesse Barnes <jbarnes> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | critical | ||||||||||
| Priority: | high | ||||||||||
| Version: | XOrg git | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
Just to confirm, this isn't fixed by the recent suspend/resume ordering fix in the drm-intel-next kernel? Unfortunately it doesn't seem to be. (In reply to comment #2) > Unfortunately it doesn't seem to be. > It is rather interesting, though, that the GPU only freezes when the 3d unit is used (i.e. task switching in compiz). When the machine comes up from suspend I can interact with the gnome-screensaver unlock window effectively indefinitely. However, when I unlock the session and attempt to interact with compiz, the chip quickly locks up. Additionally, for the short duration when compiz does draw (the first few seconds after unlocking), alpha blending appears to be broken, drawing all alpha blended regions as fully transparent. I think I 'm seeing this bug too (on G45). It doesn't seem to matter whether KMS or UMS is used (it happens in both cases). The symptom is that several desktop (KDE 4.3) components become invisible, including e.g., the panels and window decorations (I think these are all part of the plasma process nowadays) Will follow up with more information after I 've done a little more testing I experience this issue too. Upon resume all argb windows become fully transparent. Restarting my window manager fixes the issue however. (In reply to comment #5) > I experience this issue too. Upon resume all argb windows become fully > transparent. Restarting my window manager fixes the issue however. > I can also reproduce this simply by restarting compiz (without suspending/resuming). Running compiz --replace a second time during a session causes alpha blended windows to be rendered transparently. So I devoted a little time to this problem today. Kernel is latest drm-intel, the other versions are latest available (updated this morning) in kubuntu karmic / xorg-edgers repositories (see file versions.txt in the attached archive - gpu-suspend-lockup-20090720.tar.bz2). I 'm using KMS, but last time I tried from UMS it had the same problem. If I activate KDE4's compositing / 3D effects support and perform a suspend to ram / resume cycle the gpu locks up. Unfortunately, ssh in also doesn't work (It looks like the driver takes some lock with it to its doom. sshd asks for the password but hangs where it should spawn a shell - see hang_ssh.txt). If I suspend from the console by echo mem > /sys/power/state rather than from inside X, the machine resumes ok, but locks up when I switch to X.org. Therefore, I took gpu/reg dumps from before the suspend, after resume from console and then also used a sleep 10; intel_reg_dumper > dump.txt trick to try and get output from the wedged state (see test.sh). Please ask if you would like any additional info. Created attachment 27847 [details]
Post-mortem data (20090720)
Created attachment 27868 [details]
dmesg with the reset patches from bgamari applied
Trying the GPU reset patches. With those the driver detects the lockup and tries to reset the chip, but fails. Perhaps this is because the reset algorithm implemented does not work for my chip (G45).
There were some hang fixes that went in recently; do today's git bits still have this issue? (In reply to comment #10) > There were some hang fixes that went in recently; do today's git bits still > have this issue? > Things have definitely improved. The chip is far more stable and coming back from suspend hasn't yet resulted in a wedged GPU. Unfortunately, the problem still isn't completely resolved. The alpha blending issue has recurred in one of the two times I've suspended so far. While immediately restarting compiz does not fix the issue, running metacity and then starting compiz seems to bring the chip back to a sane state. Hm weird... sounds like we're missing some 3D state setup possibly, or there's some other display bit that controls rendering to alpha channels. I'll look for it. This actually seems to have recently disappeared. Perhaps it was Ickle's relocation address verification patch. Who knows... |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 27022 [details] Post-mortem data When resuming from S3 today while running compiz I encountered a GPU lockup. It appears that the 3d unit was the cause of the crash given ringbuffer dump, 0x096133e8: HEAD 0x7b001c04: 3DPRIMITIVE: quad list sequential 0x096133ec: HEAD 0x00000004: vertex count 0x096133f0: HEAD 0x00000000: start vertex 0x096133f4: HEAD 0x00000001: instance count 0x096133f8: HEAD 0x00000000: start instance 0x096133fc: HEAD 0x00000000: index bias This was with the following components, Xorg components as of Mon Jun 22 23:53:55 EDT 2009 drm: 69fc600a9d34e9c2f01d5afc8977496edec80aeb xf86-video-intel: d9e133e6874584e2a0d8ddbeba618cf8d5f1344e mesa: c80ce5ac90b1e0ac7a72cd41c314aa2000bfecf5 xserver: 0f441ed27c547c94c59547b313c40557773dddf1 kernel: Based on Linus's master (7e0338c0de18c50f09aea1fbef45110cf7d64a3c)