Bug 490366

Is this still happening with the current kernel/xorg-x11-drv-intel in rawhide?

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

(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.

Created attachment 339671 [details]
glxgears in action

Created attachment 339672 [details]
Dmesg log

Created attachment 339673 [details]
lspci

Created attachment 339674 [details]
Xorg.0.log

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

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)

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.

Similar to 489988.

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

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

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

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.

quick question on this bug: does it affect applications other than glxgears? 'useful' stuff, like extremetuxracer - real 3D apps / games?

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.

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".

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.

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.

does Google Earth work with nomodeset?

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.

(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: ..." .

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!

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.

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.

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.

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

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.

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".

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...

Happy to report that the latest update (xorg-x11-driver-intel-2.7.0-7.fc11) fixes this bug. GLX now renders properly.

Oops. A little slip up in my last comment. Should say xorg-x11-drv-intel-2.7.0-7.fc11

(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.

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

Uh-oh. Glxgears looks fine, but Google Earth still isn't rendering properly.

Can anyone else test this?

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 ;-)

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

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.

(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'.

(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.

Kristian, What was the fix? That's what was the issue ? :)

-Ilyes

(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