Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[KMS] DRI2/GLX on i855GM: glxgears not rendering properly when KMS is on|
|Product:||[Fedora] Fedora||Reporter:||Ilyes Gouta <ilyes.gouta>|
|Component:||xorg-x11-drv-intel||Assignee:||Kristian Høgsberg <krh>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||ajax, awilliam, diegoe, jfrieben, masao-takahashi, mnowak, mohaas05, rda, wally, wwoods, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-06-02 16:34:18 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||446451, 487202|
Description Ilyes Gouta 2009-03-15 15:02:22 EDT
Created attachment 335270 [details] Desktop capture depicting the issue. Description of problem: glxgears doesn't render the rotating gears correctly and it seems like it's using a wrong horizontal pitch. Attached to this bug report, a picture showing the issue. Version-Release number of selected component (if applicable): Rawhide, as of March 15th 2009. How reproducible: Run the kernel w/ KMS on on a i855GM. Run glxgears once GNOME is up. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Comment 1 Will Woods 2009-04-14 13:55:25 EDT
Is this still happening with the current kernel/xorg-x11-drv-intel in rawhide?
Comment 2 Ilyes Gouta 2009-04-15 04:21:16 EDT
Hi Will, I'm not really on rawhide, I'm not able to check again since a lot of system components are involved vs. the current F10. Is there an .iso image which reproduces the current state of the repository? -Ilyes
Comment 3 Michal Nowak 2009-04-15 07:40:24 EDT
(In reply to comment #2) > Hi Will, > > I'm not really on rawhide, I'm not able to check again since a lot of system > components are involved vs. the current F10. Is there an .iso image which > reproduces the current state of the repository? > > -Ilyes http://torrent.fedoraproject.org/ but only snap1. Anyway, the problem is still present with xorg-x11-drv-intel-18.104.22.1682-3.fc11, from my observations.
Comment 4 Michal Nowak 2009-04-15 07:42:50 EDT
Created attachment 339671 [details] glxgears in action
Comment 8 Ilyes Gouta 2009-04-15 08:14:52 EDT
It's always good to have a second opinion. I think that at this level, a direct request should be pushed to the drivers maintainers. Visually, it seems like the 3D rendering is using a bad pitch to draw to the final surface. I hope it gets fixed before the general availability of F11. -Ilyes
Comment 9 Diego Escalante Urrelo 2009-04-15 16:50:01 EDT
I can confirm on current rawhide. Exactly as the latest screenshot, same glitch (although it also gets blank sometimes). console: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try adjusting the vblank_mode configuration parameter. dmesg: [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 (nothing at the end of Xorg.0.log) lspci: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
Comment 10 Diego Escalante Urrelo 2009-04-15 16:55:37 EDT
Forgot to add I get lots of this in dmesg: i915 0000:00:02.0: VGA-1: no EDID data i2c-adapter i2c-1: unable to read EDID block. i915 0000:00:02.0: LVDS-1: no EDID data i2c-adapter i2c-0: unable to read EDID block.
Comment 11 Adam Williamson 2009-04-16 19:22:39 EDT
Similar to 489988. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 12 Bob Arendt 2009-04-26 22:51:48 EDT
Created attachment 341377 [details] Xorg.0.log using KMS on 845G chip (startx /usr/bin/xterm -- -logverbose 255) This is the same bug I saw in bug 469292, using Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset (rev 03) This still happens with today's rawhide, with KMS (good display if nomodeset asserted). kernel-22.214.171.124-102.fc11.i586 xorg-x11-server-Xorg-1.6.1-6.fc11.i586 package xorg-x11-drv-i810 is not installed xorg-x11-drv-synaptics-1.1.0-3.fc11.i586 libdrm-2.4.6-6.fc11.i586 mesa-libGL-7.5-0.9.fc11.i586 mesa-libGLU-7.5-0.9.fc11.i586 mesa-dri-drivers-7.5-0.9.fc11.i586 On the console and in Xorg, there's an (EE) message: II) intel(0): [DRI2] Setup complete (**) intel(0): Framebuffer compression disabled (**) intel(0): Tiling enabled (==) intel(0): VideoRam: 4194303 KB (II) intel(0): Attempting memory allocation with tiled buffers. (EE) intel(0): Failed to set tiling on front buffer: Invalid argument (II) intel(0): Tiled allocation successful. (II) UXA(0): Driver registered support for the following operations: (II) solid (II) copy (II) composite (RENDER acceleration) The memory size is horribly wrong. The correct value is 131072 KB. That might contribute to the later error, and be related to the corrupted GLX rendering. I've attached my Xorg.0.log output
Comment 13 Bob Arendt 2009-05-08 23:10:05 EDT
Issue persists with todays rawhide: kernel-126.96.36.199-126.fc11.i586 xorg-x11-server-Xorg-1.6.1-11.fc11.i586 xorg-x11-drv-intel-2.7.0-4.fc11.i586 xorg-x11-drv-synaptics-1.1.0-5.fc11.i586 libdrm-2.4.6-6.fc11.i586 mesa-libGL-7.5-0.9.fc11.i586 mesa-libGLU-7.5-0.9.fc11.i586 mesa-dri-drivers-7.5-0.9.fc11.i586
Comment 14 Kamin Horvath 2009-05-17 20:12:38 EDT
Created attachment 344363 [details] Rawhide glxgears corruption on intel driver I get this result when attempting to run glxgears. The card is an intel 82855. If you notice, the background in the glxgears windows is actually a portion of the firefox window. Also, I'm not sure if the message in the terminal is relevant to the problem. From what I've researched, it shouldn't be. But I never got it in any previous release.
Comment 15 Adam Williamson 2009-05-20 19:18:39 EDT
quick question on this bug: does it affect applications other than glxgears? 'useful' stuff, like extremetuxracer - real 3D apps / games?
Comment 16 Kamin Horvath 2009-05-20 20:03:07 EDT
Well for me, Google Earth failed to render anything except a small black square in the corner. I haven't tried it again with the newest updates but I suspect the results will be the same.
Comment 17 Joachim Frieben 2009-05-21 03:45:41 EDT
Same issue on "Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device rev 3": - Application window of 'glxgears' comes up with heavy artifacts as in the sample screenshot. - Screensaver module "Juggler3D" works as expected. However, opening preferences of GNOME screen saver leads to immediate lock up of X when the chosen module is (Open GL based) "Juggler3D" which is really bad! It had been selected first after booting the system with option "nomodeset".
Comment 18 Ilyes Gouta 2009-05-21 03:52:29 EDT
Hi, Is it possible to *not* mark this bug as FIXED until Google Earth works as expected? That's I suggest to use it as validation requirement. Can we communicate this to the upstream maintainers? Regards, Ilyes Gouta.
Comment 19 Walter Francis 2009-05-21 13:59:38 EDT
Same here, glxgears has the weird banding, Google Earth is as described, but Tuxracer looks fine (at a screaming 2.5fps), as is teapot.. Compiz runs surprisingly well. Same video, Intel 855GM.
Comment 20 Adam Williamson 2009-05-21 18:35:36 EDT
does Google Earth work with nomodeset?
Comment 21 Walter Francis 2009-05-21 18:55:13 EDT
Setting nomodeset on the Grub line for me makes glxgears look normal (jumpy, 70fps). Google Earth looks good, slow, but shows everything now. extremetuxracer screams along at 2.5fps still. Also, I believe the cursor flickering I've noticed on 855GM is no longer happening as well. Normally see it on login, logout, mainly obvious on the busy cursor and it's solid now.
Comment 22 Joachim Frieben 2009-05-22 01:53:29 EDT
(In reply to comment #21) > Setting nomodeset on the Grub line for me makes glxgears look normal (jumpy, > 70fps). This sounds as not hardware rendering was active but the software rasterizer. Check the output of 'glxinfo', namely the section: "OpenGL renderer string: ..." .
Comment 23 Adam Williamson 2009-05-22 12:52:57 EDT
sorry for the bugzilla-abuse, but can those of you with 855s take a quick look at https://bugzilla.redhat.com/show_bug.cgi?id=500544 and see if it looks at all familiar? that reporter is reporting a complete hang of X on startup (it looks like) with an 855 chipset and the F11 Preview live CD, but it seems from this report that you other guys with 855s don't have any problems starting X, at least...thanks!
Comment 24 Kamin Horvath 2009-05-22 14:45:13 EDT
I've never had an issue with X starting up for me. And I've been using Fedora 11 since beta. This is my OpenGL renderer string, OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM GEM 20090114 x86/MMX/SSE2 I noticed this popped up when I tried to run Google Earth: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try adjusting the vblank_mode configuration parameter. It's the same message I was getting in glxgears and glxinfo.
Comment 25 Joachim Frieben 2009-05-23 04:19:13 EDT
Opening the g-s-s preference panel and selecting a GL based module still leads to immediate lock-up of X. Installed packages from Koji include: - kernel-PAE-188.8.131.52-159.fc11.i686 - mesa-*-7.5-0.15.fc11.i586 - xorg-x11-drv-intel-2.7.0-6.fc11.i586 I would favour setting severity to "high". The machine actually needs to be powered off.
Comment 26 Adam Williamson 2009-05-25 15:28:47 EDT
severity and priority aren't really paid any attention to at present (though hopefully this will change soon), so don't worry about them too much.
Comment 27 Walter Francis 2009-05-26 12:27:44 EDT
I haven't had any problems with X startup, lockups, cursor, etc.. What I do have is a hosed glxgears and Google Earth unless I run nomodeset on the Grub boot line. glxinfo reports (typed, please excuse any typoes): direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 [..] OpenGL vendor string: Tungsten Graphics, Inc OpenGL rendering string: Mesa DRI Intel(R) 852GM/855GM GEM 20090114 x86/MMX/SSE2 OpenGL version string: 1.3 Mesa 7.5-devel
Comment 28 Adam Williamson 2009-05-27 00:45:41 EDT
can you guys please test this kernel? http://koji.fedoraproject.org/koji/taskinfo?taskID=1378653 as I understand it, it should disable KMS by default for all 8xx chipsets. So try running that kernel *without* the nomodeset parameter. It should behave just like the regular kernel does *with* nomodeset, hence it should 'fix' (workaround, really, so don't close it) this bug.
Comment 29 Joachim Frieben 2009-05-27 02:44:51 EDT
The effect of kernel 184.108.40.206-163.i8xx_nokms.fc11 is the intended one. However, enabling desktop effects will trigger bug 490005 which is even worse than the present one as X locks up completely. This applies at least to an "Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device rev 3".
Comment 30 Adam Williamson 2009-05-27 14:42:03 EDT
yeah, I'm aware of that bug too. the status of what we're going to do with nomodeset by default is a bit up in the air...
Comment 31 Kamin Horvath 2009-06-02 15:59:01 EDT
Happy to report that the latest update (xorg-x11-driver-intel-2.7.0-7.fc11) fixes this bug. GLX now renders properly.
Comment 32 Kamin Horvath 2009-06-02 16:00:42 EDT
Oops. A little slip up in my last comment. Should say xorg-x11-drv-intel-2.7.0-7.fc11
Comment 33 Kristian Høgsberg 2009-06-02 16:08:35 EDT
(In reply to comment #31) > Happy to report that the latest update (xorg-x11-driver-intel-2.7.0-7.fc11) > fixes this bug. GLX now renders properly. Thanks for confirming.
Comment 34 Adam Williamson 2009-06-02 16:14:14 EDT
actually, what fixed this is probably kernel 220.127.116.11-167. if any other reporter confirms the fix, we can close this report and take it out of the common issues page - so, if anyone else can test that'd be great. thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 35 Kamin Horvath 2009-06-02 16:30:33 EDT
Uh-oh. Glxgears looks fine, but Google Earth still isn't rendering properly. Can anyone else test this?
Comment 36 Walter Francis 2009-06-02 16:32:06 EDT
Agreed, glxgears is good here. Google Earth, however, is still a useless little square. Teapot, extremetuxracer (2.5fps) still look fine.. Compiz is fine. All of this on the latest F11 kernel, not a nomodeset test kernel. 18.104.22.168-167.fc11.i686.PAE I had submitted this as the same time as someone else, so I agree with Kamin ;-)
Comment 37 Adam Williamson 2009-06-02 16:34:18 EDT
Looks like Google Earth is a separate problem...I think for clarity it'd be best to close this bug and open a new one for GE. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 38 Joachim Frieben 2009-06-03 01:58:18 EDT
Why has this bug been closed? The title clearly states that the issue affects systems on which KMS is enabled. Disabling KMS is not a fix: 'glxgears' used to work properly for disabled KMS enforced by adding 'nomodeset' to the kernel boot options already before. Unfortunately, it is currently not even possible to test the status with active KMS because the corresponding kernel option is broken: Kernel command line: ro root=/dev/mapper/vg_daily-LogVol00 rhgb quiet i915.modeset=1 Unknown boot option `i915.modeset=1': ignoring This applies to kernel-PAE-22.214.171.124-167.fc11.i686.
Comment 39 Will Woods 2009-06-03 09:04:06 EDT
(In reply to comment #38) > Unfortunately, it is currently not even possible to test the status with active > KMS because the corresponding kernel option is broken: > > Kernel command line: ro root=/dev/mapper/vg_daily-LogVol00 rhgb > quiet i915.modeset=1 > Unknown boot option `i915.modeset=1': ignoring Incorrect - that message can be ignored. The *kernel* does not recognize that boot option because i915 is a module (i.e. not built into the kernel). When the i915 module gets loaded it should recognize and use this option. The same thing happens with nouveau using 'nouveau.modeset=1'.
Comment 40 Kristian Høgsberg 2009-06-03 09:32:09 EDT
(In reply to comment #38) > Why has this bug been closed? The title clearly states that the issue affects > systems on which KMS is enabled. Disabling KMS is not a fix The bug was closed because with the fix that went in to the -165 kernel, glxgears now works correctly with KMS. I've verified this on 865 personally, and the replies above verify glxgears working on 855.
Comment 41 Ilyes Gouta 2009-06-03 09:41:13 EDT
Kristian, What was the fix? That's what was the issue ? :) -Ilyes
Comment 42 Kristian Høgsberg 2009-06-03 09:47:49 EDT
(In reply to comment #41) > Kristian, What was the fix? That's what was the issue ? :) > > -Ilyes This commit from Eric Anholt: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=e76a16deb8785317a23cca7204331af053e0fb4e