Intel video testing: It worked for a bit...

[Bob Arendt]

Leon Stringer wrote:
> Robert Arendt wrote:
>> Also, you should use xorg-x11-drv-intel-2.6.0-14.fc11.i586.rpm for
>> the latest;  Yum/rawhide changed me from -i810 to -intel at some point.
>> I have a intel 845G/GL[Brookdale-G] 8086:2562 rev3 on a Dell laptop.
>>  From yesterday's testing:
>>   https://fedoraproject.org/wiki/QA/Test_Days/2009-03-12
>>
>> .. it appears the KMS (on by default) doesn't set up the 845G correctly.
>> Boot with "nomodeset" on the kernel boot line.
>>
>> If the screen goes black, toggle around the VT's (clt-alt-Fn) to restore
>> it.
>> With nomodeset, the text VT backlights always work.  There seems to be a
>> race condition in re-enabling the screen backlight with the intel Xserver.
>>
> 
> Bob: Thanks for your reply. Unfortunately, I can't get this to work for
> me. I did:
> 
>    rpm -e --nodeps xorg-x11-drv-i810
> 
> then
> 
>    rpm -i xorg-x11-drv-intel-2.6.0-14-fc11.i586
> 
> And I've tried all the tests I think could possibly work:
> 
> 1. Driver "intel": Screen flashes blank, then back text mode a few times
> before staying black, cursor in top left, system locked up.
> 2. Driver "intel"+nomodeset: X attempts to load, see mouse cursor
> briefly, then blank, system locked up
> 3. Driver "intel"+NoAccel: Screen flashes blank, then back text mode a
> few times before staying black, system locked up
> 4. Driver "intel"+NoAccel+nomodeset: X attempts to load, see mouse
> cursor briefly, then blank, system locked up, no VTs
> 5. Driver "intel"+XXA: Screen flashes blank, then back text mode a few
> times before staying black, cursor in top left, system locked up
> 6. Driver "intel"+XXA+nomodeset: X attempts to load, see mouse cursor
> briefly, then blank, system locked up, no VTs
> 7. Driver "vesa"+NoAccel+nomodeset: X attempts to load, see mouse cursor
> briefly, then blank, system locked up
> 8. Driver "vesa"+NoAccel: X attempts to load, see mouse cursor briefly,
> then blank, system locked up
> 9. Driver "vesa"+XXA: X attempts to load, see mouse cursor briefly, then
> blank, system locked up
> 10. Driver "vesa"+XXA+nomodeset: X attempts to load, see mouse cursor
> briefly, then blank, system locked up
> 11. Driver "vesa": X attempts to load, see mouse cursor briefly, then
> blank, system locked up
> 12. Driver "vesa"+nomodeset: X attempts to load, see mouse cursor
> briefly, then blank, system locked up
> 
> Some of these combinations may not make sense, but I've tried to be
> thorough...
> 

Case 2 is the one that works the best for me.  Though 1 is the goal
of the intel Xorg and kernel developers.  My grub entry:
title Fedora (2.6.29-0.237.rc7.git4.fc11.i586)
         root (hd0,0)
         kernel /vmlinuz-2.6.29-0.237.rc7.git4.fc11.i586 ro rootwait root=UUID=[bigstring] selinux=0 rhgb nomodeset
         initrd /initrd-2.6.29-0.237.rc7.git4.fc11.i586.img

You can verify the command line args after boot by:
   cat /proc/cmdline
It will show you the running kernel's command line string.
You're running the same version of intel xorg driver.
Mine also worked without an xorg.conf file.  If you look in
/var/log/Xorg.0.log, it should say
     (==) Using default built-in configuration
if you're running without a config file.  If you *do* have
a config file, it will be identified here.  You might rename
to something else to move it out of the way.  Some config interaction
might an issue.

Are you sure your machine is locking up?  For me the acid test is
to toggle the caps-lock key and see if the indicator light toggles.
If not, the machine's locked up.  Also ping or ssh in from another
host.  Often it was the backlight failure that made it appear to be
totally dead.

To get more diagnostics, again try booting with "nomodeset 3"
(to start at runlevel 3, without X).  Log into a VT and type:
   startx /usr/bin/xterm -- -logverbose 255

This should start an Xserver and xterm (yum install /usr/bin/xterm)
on vt7.  This is sort of a failsafe mode - not even a window manager.
It takes gdm and the rest of the gnome session out of the equation.
When you exit the xterm, the Xserver will terminate.  The logverbose
puts maximum debug into the /var/log/Xorg.0.log.

If you got an xterm, you can start a window manager wiht "metacity &".
Now you have borders and can drag the xterm.  Maybe try simple tests
like "x11perf -putimage100" (2D)  or "glxgears" (3D).  This will
give you some simple numeric benchmarks to compare to other systems.

If you didn't get an xterm or really locked up, it's a bug.
Create a bug against rawhide, posting your rpm versions, the output of lspci -n
and the verbose /var/log/Xorg.0.log.  Also look in /var/log/messages.
Though working (for me) I've got entries like this:

kernel: =======================================================
kernel: [ INFO: possible circular locking dependency detected ]
kernel: 2.6.29-0.237.rc7.git4.fc11.i586 #1
kernel: -------------------------------------------------------
kernel: Xorg/2351 is trying to acquire lock:
kernel: (&mm->mmap_sem){----}, at: [<c04912bf>] might_fault+0x48/0x85
kernel:
  (.... and more detail)

Add that info into the bug as well.

I feel your pain, I've been testing this hardware since F10 alpha (last Halloween):
https://bugzilla.redhat.com/show_bug.cgi?id=469292

It looks like it's getting a lot closer, but the 845G hardware isn't
out of the woods yet.

Good luck,
-Bob Arendt