Created attachment 40519 [details] GPU dump after crash caused by starting any 3D app Intel hardware seems to hate me ... here is another laptop with just about unusuable graphics; but this time reproducable: This Thinkpad X200 with GMA4500MHD video chip, just after Linux kernel upgrade to 2.6.36.1, from 2.6.33.2-rt13 (vanilla plus TuxOnIce patch), any attempt to start a 3D app crashes/freezes X11. It can be as simple as glxgears. It was generally fine with the 2.6.33 kernel and a somewhat older X stack, but I experienced some freeze recently and remembered that newer intel drivers with kernel 2.6.35 brought some important improvements (that helped my old GMA945 laptop so far). I am now on intel driver 2.13.0 with associated software (mesa et al), xorg-server 1.8.1 . Previously, I was on intel driver version 2.10 and xorg-server 1.7.5 . It may very well be the change in the software stack, not the kernel itself, as I do not really recall using any OpenGL app before updating the kernel, too. I see that for the current graphics package, xorg-server 1.9 is recommened... but 1.8.1 shouldn't be utterly broken, right? I hope the logs/dump I am attaching give some hint about the issue... at least it is extremely reliable in being reproduced. Only a bit annoying as I have to do a reboot to be able to run X again (linux console is still alive, though, and X killable).
Created attachment 40520 [details] Xorg log
Created attachment 40521 [details] Console output (includes error message from intel_bufmgr_gem.c).
Now I'm confused: Booted the 2.6.33 kernel again. There, X is not even able to start, I get a freeze right away. Worse, I'm not able to get back to the console -- have to use SysRq to get out there at all (reboot). That must mean that I did no full X restart after the software upgrades but before the kernel upgrade. I remember differently. Random chance? Well, before I drive me into insanity with this ... perhaps some wise people get a clue from the dump:-/
Not a chance, you need the /sys/kernel/debug/dri/0/i915_error_state. Manually dumping the gpu contents after a hang is reported is too late, the lists have already been flushed.
Created attachment 40564 [details] /sys/kernel/debug/dri/0/i915_error_state OK, then... here is the error state after running glxgears.
This is most improbable (I would have believed it except for the error state capturing the bug): 0x0cd441e4: 0x78080003: 3DSTATE_VERTEX_BUFFERS 0x0cd441e8: 0x0000000c: buffer 0: sequential, pitch 12b 0x0cd441ec: HEAD 0x00000000: buffer address 0x0cd441f0: 0x00000aaa: max index 0x0cd441f4: 0x00000000: mbz Also looking at the list of buffers used by the batch, there are no vertex buffers. This is a severe bug in mesa, which version are you using?
Ah, that explains it. It's not the kernel, it's not the driver version... it's that I had Gallium3D enabled! I am using Mesalib 7.9, and the crashy variant is this: OpenGL renderer string: Gallium 0.4 on i965 (chipset: GM45_GM) while this works as usual: OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20100330 DEVELOPMENT So this is a bug in the Gallium3D driver. OK, so now I know that I should keep that buzzword out for some time. Or, is it supposed to be stable on intel? Though I am wondering down to what level software is supposed to be able to crash the GPU. The Gallium layer is still in that range, I suppose. So, are we going to reassign this bug to mesa/Drivers/Gallium/i915g?
Ah, it would be mesa/Drivers/Gallium/i965g. No, we [Intel] don't support that since i965g is nowhere near the same level of maturity as i965c and we would spend a lot of time fixing the same bugs... [whereas we are madly trying to get new hw features enabled in time for chip releases, and so far they have only needed incremental changes to the driver.] On the other hand the Gallium framework itself is very interesting.
i965g can't even run glxgears bugs makes no sense for at this time.
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.