Bug 437922

Created attachment 298340 [details]
/var/log/Xorg.0.log

Created attachment 298341 [details]
/etc/X11/xorg.conf

Created attachment 298342 [details]
output of glxinfo

Jane, is this a regression from 5.1?

Confirmed with Jane and Austin that this _is_ a regression. It also occurs on
the Weybridge desktop (Bearlake chipset). Both Bearlake and Crestline 3D were
working in 5.1.

Jane, please try 5.1 kernel on top of RHEL5.2-beta or whatever snapshot, and see
if that fixes it.

I just reproduced this with 5.2 Beta on a Weybridge/Bearlake box. It's using the
"intel" driver. I noticed glxgears runs unaccelerated, and X does crash when I
restore the window size. If I switch to i810 driver in xorg.conf, though,
glxgears comes up accelerated, and doesn't have the problem.

Maybe we need to consider having i810 remain the default driver for
Bearlake/Crestline in 5.2? I'm not sure what other effects this would have. But
on this box, one effect is: the i810 driver comes up in 800x600 resolution and
system-config-display offers nothing higher. The intel driver comes up in
1024x768 and supports other options like 1280x1024.

I think the kernel is off the hook for now, should probably assign to
xorg-x11-i810-drv.

Created attachment 300155 [details]
fix direct rendering with the new driver running against our old server.

This is a regression for new installs or anyone trying to use the new Intel
driver as opposed to the old i810 driver.

This should probably be fixed before GA, so for that please be setting the
blocker flag.

RHEL5.1 is using "i810" driver as the default for Bearlake/Crestline.  RHEL5.2 
is using "intel" driver as the default for Bearlake/Crestline.  Direct 
rendering works with "i810" driver.  So I tried 5.2 kernel on 5.1 system, it's 
using "i810" driver and direct rendering works.  But it doesn't work with 5.1 
kernel on 5.2 system, which is using "intel" driver.

Dave, I tried to apply your patch to 5.2-sp2 xf86-video-intel-20080119 source 
package, "configure" failed by requiring X server >= 1.3 source tree.  
Actually,X server is version 1.1 in 5.2.  Did I do something wrong with 
building the source code?

Log messages,
configure: error: Must have X server >=1.3 source tree for mode setting code.  
Please specify --with-xserver-source

the kernel shouldn't matter.

this is purely the i810 vs the intel driver problem.

You need to build the 5.2 intel driver against the 5.2 X server with the
xorg-x11-server-randr-source package installed. you need to do add the patch to
the spec and do an rpm rebuild, I don't think hand building will work too well..

FYI, I have tested Dave's patch on a T61 and an X61 laptop (both with 965GM) and
direct rendering appears to work fine.

Dave, thanks for your information.  I applied your patch and rebuild 5.2 driver
intel_drv.so successfully.  But direct rendering still does not work with the
new driver.

Kevin, did you use "intel" driver or "i810" driver for your test on T61?  "i810"
driver always works fine.:)

 

(In reply to comment #13)
> Kevin, did you use "intel" driver or "i810" driver for your test on T61?  "i810"
> driver always works fine.:)

I've tested both the "intel" and "i810" drivers and direct rendering works on
both now with Dave's patch (according to glxinfo and glxgears).  We have an
internal build with Dave's patch.  Would you like to try that updated package to
see if it works for you?  FYI, I'm testing on 5.2 beta and the only updated
package is xorg-x11-drv-i810-1.6.5-9.11.el5, which includes both the i810 and
intel drivers.

In case anyone would like to test the latest build which includes Dave's patch,
I've put it on my people page here:
  http://people.redhat.com/kem/intel/1.6.5-9.11.el5/

*** Bug 441569 has been marked as a duplicate of this bug. ***

Thanks, Kevin. I tried your test package and found the ia32 one works for ia32
system, but the x86_64 one does not work for x86_64 system.  Both glxinfo and
glxgears do not work on x86_64 system.  I've tested on 5.2-beta and 5.2-sp2.(In
reply to comment #14)
> (In reply to comment #13)
> > Kevin, did you use "intel" driver or "i810" driver for your test on T61?  "i810"
> > driver always works fine.:)
> 
> I've tested both the "intel" and "i810" drivers and direct rendering works on
> both now with Dave's patch (according to glxinfo and glxgears).  We have an
> internal build with Dave's patch.  Would you like to try that updated package to
> see if it works for you?  FYI, I'm testing on 5.2 beta and the only updated
> package is xorg-x11-drv-i810-1.6.5-9.11.el5, which includes both the i810 and
> intel drivers.
> 

Thanks, Kevin. I tried your test package and found the ia32 one works for ia32
system, but the x86_64 one does not work for x86_64 system.  Both glxinfo and
glxgears do not work on x86_64 system with "intel" driver.  I've tested on
5.2-beta and 5.2-sp2.

Dave/Kevin, will Dave's patch be included in RHEL5.2-snapshot6?

Testing reveals that indeed i386 install works, but x86_64 does not.

Currently "intel" driver is not the default setting for Cantiga.  Now it's using
"vesa".  We require to set "intel" as the default driver for Cantiga.

I tested again with snap7 and xorg-x11-drv-i810-1.6.5-9.13.el5 on T61 (x86_64).
 glxgears and glxinfo both work (report and use direct rendering).  However, if
you move the glxgears window off the screen, it gets corrupted and eventually
you get a hardlocked system with a psychadelic display.  New bug or continue
with this bug?

Addendum:  lock happens from just moving the window in any way.

It does work on Cantiga and 82Q35 (bearlake?) with out issues.  T61 is the only
one with problems (DRI enabled, but crashes and hardlocks system)

Can the reporter retest to see if it works their hardware?  X crash and/or
hardlock maybe different bugs.

I filed a bug for the crash/hang: 
https://bugzilla.redhat.com/show_bug.cgi?id=444508

I tested RHEL5.2-snapshot6.  DRI does not work w/ x86_64 version on
Crestline/Bearlake.  Both glxinfo and glxgears shows no DRI supported in x86_64
version.

DRI works w/ i386 version and no "lock" happens in my testing w/ both Bearlake
and Crestline.

The test is also done on my T61 platform, which integrates Crestline chipset. 
DRI works well w/ i386 version, but does not work w/ x86_64 version. And no
"lock" on i386 version.

Jane, you need xorg-x11-drv-i810-1.6.5-9.13.el5.  The fix is not is snap 6 or
snap 7.

other than the glxgears lock issue on T61, is there any other issue WRT this bug
that needs to be documented in the release notes? BZ#444508 already tracks the
glxgears lock issue.

(In reply to comment #35)
> Jane, you need xorg-x11-drv-i810-1.6.5-9.13.el5.  The fix is not is snap 6 or
> snap 7.
Thanks for the info.

So that means it will be in till GA? And 'set 'intel' as default driver in 
_cantiga_ platform' will be in till GA also?

Austin, The fixes should be in the Release Candidate and of course GA.

Don,  I think the requires_release_note flag was added when we thought this was
not fixed.  I think it can be removed now.  We were able to verify this bug, but
we were waiting on the customer to double check.  The only issues is the
glxgears one you already mentioned.

(In reply to comment #39)
> Austin, The fixes should be in the Release Candidate and of course GA.
> 
> Don,  I think the requires_release_note flag was added when we thought this was
> not fixed.  I think it can be removed now.  We were able to verify this bug, but
> we were waiting on the customer to double check.  The only issues is the
> glxgears one you already mentioned.

Tested RHEL5.2-RC1 w/ both x86_64 and i386 version on Intel platforms,
1. "intel" is set as default driver for Cantiga.
2. DRI support for Crestline/Bearlack on both x86_64 and i386 are enabled. But
the only issue is glxgears one for Crestline.  I reproduced it on RHEL5.2-RC1.

I will verify this bug and track glxgears issue in bug
https://bugzilla.redhat.com/show_bug.cgi?id=444508.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2008-0420.html