Created attachment 51302 [details] dmesg I am setting up an intel box with Ubuntu. I am having frequent lockups in the graphics stack when compositing (menu fades, moving windows, etc). The screen will go black and flash back on, usually with some graphics corruption which will go away if I move the window. This is highly reproducible (dragging a window will cause it to happen with an expected time until occurrence of around 3 seconds. The fglrx driver does not have this issue, so I'm using it instead. I am attaching dmesg and Xorg.0.log from when this occurred, and lspci -v shows this identification for the card (obviously taken while using fglrx on a subsequent boot): 01:00.0 VGA compatible controller: ATI Technologies Inc RV670 AGP [Radeon HD 3850] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device 0028 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at e0000000 (32-bit, prefetchable) [size=256M] I/O ports at ec00 [size=256] Memory at ff8f0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at ff800000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] AGP version 3.0 Kernel driver in use: fglrx_pci Kernel modules: fglrx, radeon Kernel is: Linux barret 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:05:14 UTC 2011 i686 i686 i386 GNU/Linux xf86-video-ati is: Package: xserver-xorg-video-radeon Version: 1:6.14.0-0ubuntu4.1 libdrm is: Package: libdrm-radeon1 Version: 2.4.23-1ubuntu6
Created attachment 51303 [details] Xorg.0.log
I'm gonna try getting a newer version of xf86-video-ati built from git to see if it reproduces from there.
Persists with git master, but on further investigation, I think it might be gallium related. I moved aside /usr/lib/dri/r600_dri.so ("Gallium 0.4 on AMD RV670") which caused /usr/lib/dri-alternative/r600_dri.so ("Mesa DRI R600 (RV650 9515) 20090101 x86/MMX/SSE2 TCL DRI2") to be used instead. Attaching glxinfo from both.
Created attachment 51304 [details] Good glxinfo (mesa)
Created attachment 51305 [details] Bad glxinfo (gallium)
(In reply to comment #0) > Kernel is: > Linux barret 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:05:14 UTC 2011 i686 > i686 i386 GNU/Linux There was a kernel fix which got gallium working with my AGP rv670 (different mobo though, which makes a difference with AGP) I was the end of May, so I don't think 2.6.38-11 will have it - try the latest kernel Ubuntu has. Probably not related to this directly, but if you still have game/3D troubles try using the radeon module parameter no_wb=1.
(In reply to comment #6) > (In reply to comment #0) > > > Kernel is: > > Linux barret 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:05:14 UTC 2011 i686 > > i686 i386 GNU/Linux > > There was a kernel fix which got gallium working with my AGP rv670 (different > mobo though, which makes a difference with AGP) Oops - sorry ignore that - the fix was mesa not kernel (though a newer kernel is still something worth trying IMHO)
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #0) > > > > > Kernel is: > > > Linux barret 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:05:14 UTC 2011 i686 > > > i686 i386 GNU/Linux > > > > There was a kernel fix which got gallium working with my AGP rv670 (different > > mobo though, which makes a difference with AGP) > > Oops - sorry ignore that - the fix was mesa not kernel (though a newer kernel > is still something worth trying IMHO) Your glxinfo shows Mesa 7.10.2 which is April - so a new mesa may well fix it.
Yeah, it looks like something in either mesa-7.11 or the 3.0 kernel addressed the problem here. If you happen to know the commit to mesa that addressed this issue, perhaps we can get that cherry-picked into 7.10. I seem to recall that there were plans for one more 7.10 release, and if not, it would be good to have in the branch anyway for distros that are tied to the older release. If you're not quite sure, or the change isn't really easily cherry-picked, we can just close this out as I have a working solution. Thanks.
(In reply to comment #9) > Yeah, it looks like something in either mesa-7.11 or the 3.0 kernel addressed > the problem here. If you happen to know the commit to mesa that addressed this > issue, perhaps we can get that cherry-picked into 7.10. I seem to recall that > there were plans for one more 7.10 release, and if not, it would be good to > have in the branch anyway for distros that are tied to the older release. > > If you're not quite sure, or the change isn't really easily cherry-picked, we > can just close this out as I have a working solution. > > Thanks. It was this mesa commit that fixed it for me. r600g: bump domain selection up one layer. ecc051d65b6e17115439fb3609cccfd59f6272bf
Ok, passed along to Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/853667 Can we get this cherry-picked into the 7.10 branch?
7.11 or newer is kind of recommended for r600g in general. That said, if you can test that cherry-picking that commit on top of the 7.10 branch fixes the problem, we can certainly do that.
Yep, cherry picking ecc051d65b6e17115439fb3609cccfd59f6272bf into 7.10 addressed the issue being reported. Please cherry-pick it into 7.10 so distros can inherit the fix. Yes I realize that r600 is "experimental" and disabled by default in 7.10, but apparently that didn't stop Ubuntu. Thanks.
Cherry-picked to 7.10 branch as 1e279de4b01b25df4f153c643f44f8b67dba50e9.
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.