Bug 490366 - [KMS] DRI2/GLX on i855GM: glxgears not rendering properly when KMS is on
Summary: [KMS] DRI2/GLX on i855GM: glxgears not rendering properly when KMS is on
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kristian Høgsberg
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks: F11Target IntelKMS
TreeView+ depends on / blocked
 
Reported: 2009-03-15 19:02 UTC by Ilyes Gouta
Modified: 2009-06-11 04:59 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-06-02 20:34:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Desktop capture depicting the issue. (1.08 MB, image/jpeg)
2009-03-15 19:02 UTC, Ilyes Gouta
no flags Details
glxgears in action (133.74 KB, image/png)
2009-04-15 11:42 UTC, Michal Nowak
no flags Details
Dmesg log (54.16 KB, text/plain)
2009-04-15 11:43 UTC, Michal Nowak
no flags Details
lspci (1.76 KB, text/plain)
2009-04-15 11:43 UTC, Michal Nowak
no flags Details
Xorg.0.log (61.09 KB, text/plain)
2009-04-15 11:43 UTC, Michal Nowak
no flags Details
Xorg.0.log using KMS on 845G chip (startx /usr/bin/xterm -- -logverbose 255) (28.20 KB, text/plain)
2009-04-27 02:51 UTC, Bob Arendt
no flags Details
Rawhide glxgears corruption on intel driver (229.39 KB, image/png)
2009-05-18 00:12 UTC, Kamin Horvath
no flags Details

Description Ilyes Gouta 2009-03-15 19:02:22 UTC
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 17:55:25 UTC
Is this still happening with the current kernel/xorg-x11-drv-intel in rawhide?

Comment 2 Ilyes Gouta 2009-04-15 08:21:16 UTC
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 11:40:24 UTC
(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-2.6.99.902-3.fc11, from my observations.

Comment 4 Michal Nowak 2009-04-15 11:42:50 UTC
Created attachment 339671 [details]
glxgears in action

Comment 5 Michal Nowak 2009-04-15 11:43:12 UTC
Created attachment 339672 [details]
Dmesg log

Comment 6 Michal Nowak 2009-04-15 11:43:33 UTC
Created attachment 339673 [details]
lspci

Comment 7 Michal Nowak 2009-04-15 11:43:58 UTC
Created attachment 339674 [details]
Xorg.0.log

Comment 8 Ilyes Gouta 2009-04-15 12:14:52 UTC
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 20:50:01 UTC
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 20:55:37 UTC
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 23:22:39 UTC
Similar to 489988.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 12 Bob Arendt 2009-04-27 02:51:48 UTC
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-2.6.29.1-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-09 03:10:05 UTC
Issue persists with todays rawhide:

kernel-2.6.29.2-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-18 00:12:38 UTC
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 23:18:39 UTC
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-21 00:03:07 UTC
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 07:45:41 UTC
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 07:52:29 UTC
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 17:59:38 UTC
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 22:35:36 UTC
does Google Earth work with nomodeset?

Comment 21 Walter Francis 2009-05-21 22:55:13 UTC
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 05:53:29 UTC
(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 16:52:57 UTC
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 18:45:13 UTC
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 08:19:13 UTC
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-2.6.29.3-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 19:28:47 UTC
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 16:27:44 UTC
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 04:45:41 UTC
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 06:44:51 UTC
The effect of kernel 2.6.29.4-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 18:42:03 UTC
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 19:59:01 UTC
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 20:00:42 UTC
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 20:08:35 UTC
(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 20:14:14 UTC
actually, what fixed this is probably kernel 2.6.29.4-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 20:30:33 UTC
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 20:32:06 UTC
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. 
2.6.29.4-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 20:34:18 UTC
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 05:58:18 UTC
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-2.6.29.4-167.fc11.i686.

Comment 39 Will Woods 2009-06-03 13:04:06 UTC
(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 13:32:09 UTC
(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 13:41:13 UTC
Kristian, What was the fix? That's what was the issue ? :)

-Ilyes

Comment 42 Kristian Høgsberg 2009-06-03 13:47:49 UTC
(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


Note You need to log in before you can comment on or make changes to this bug.