| Summary: | [i965g] where are my vbo? | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Thomas Orgis <sobukus> |
| Component: | Drivers/Gallium/i915g | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | critical | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
GPU dump after crash caused by starting any 3D app
Xorg log Console output (includes error message from intel_bufmgr_gem.c). /sys/kernel/debug/dri/0/i915_error_state |
||
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.
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).