Bug 439022

When you get to the error message, could switch to console (Ctrl+Alt+F2) and
copy to USB drive content of /tmp direcotry and attach it to this bug, please?

Thank you

Created attachment 300177 [details]
/var/log/Xorg.0.log from a run with no xorg.conf

  While running a rawhide system updated to:
    kernel-2.6.25-0.172.rc7.git4.fc9.i686
    xorg-x11-drv-ati   xorg-x11-drv-ati-6.8.0-6.fc9.i386
I also see:
    (EE) R128(0): Cannot allocate space for hold Video BIOS!

  Would not it be appropriate to update the Summary to highlight
the R128 driver, and omit the mention of the LiveCD?  I see this
same failure running the "dead" installed system.  If I use any of: 
 1 - no xorg.conf (e.g. rename /etc/X11/xorg.conf), or 
 2 - an xorg.conf containing:   
  Section "Device"
    Identifier  "Videocard0"
    Driver      "r128"
  EndSection
     or,
 3 - attempt to run "xinit" from a command line
the reward is that X fails to start, while displaying the errors:

(EE) R128(0): Cannot allocate space for hold Video BIOS!

Backtrace:
0: /usr/bin/Xorg(xf86SigHandler+0x79) [0x80bc2c9]
1: [0x110400]
2: /usr/lib/xorg/modules/drivers//r128_drv.so(R128FreeScreen+0x2b) [0x1c76fb]
3: /usr/bin/Xorg(xf86DeleteScreen+0x6e) [0x80cb2de]
4: /usr/bin/Xorg(InitOutput+0x9a3) [0x80a39e3]
5: /usr/bin/Xorg(main+0x279) [0x806b119]
6: /lib/libc.so.6(__libc_start_main+0xe6) [0xaa95d6]
7: /usr/bin/Xorg(FontFileCompleteXLFD+0x22d) [0x806a701]

Fatal server error:
Caught signal 11.  Server aborting

I can confirm this error with a new Fedora 9 install on an Inspiron 8000
Mobility M4 video card, before and after any yum upgrades

p.s. Xserver will run with vesa driver.

Reading bug summaries, I think the r128 hardware is in a group of related bugs:
428986, 427383, 231113. Some of these show when the vesa driver is used with
this hardware. I see the behavior described in 427383 with the kde workspace (I
cannot start a kde session at all) and the system monitor program on a gnome
session.
My specific hardware is a dell inspiron 4100 laptop from around 2001. Other bugs
have other dell models and an old bug is a toshiba laptop. I cannot unsolder the
controller chip and replace it, so I will have to wait for new driver software.

I'm just building a new -ati driver in koji

xorg-x11-drv-ati-6.8.0-11.fc9

If someone could test this on r128 that is seeing this problem I'd appreciate it.

  Thank you for the opportunity to test the new driver.  Well, there
is progress.  Now X starts, but it doesn't stay up long enough to even
offer the chance for a user to login.  First, I did:

[root@localhost ~]# yum -y install koji
 :
Installed: koji.noarch 0:1.2.3-1.fc9
Dependency Installed: pyOpenSSL.i386 0:0.6-4.fc9 python-krbV.i386 0:1.0.13-7.fc9
Complete!
[root@localhost ~]# koji download-build --arch=`uname -i`
xorg-x11-drv-ati-6.8.0-11.fc9
xorg-x11-drv-ati.i386     100% |=========================| 401 kB    00:02     
[root@localhost ~]# rpm -Uvh xorg-x11-drv-ati*
Preparing...                ########################################### [100%]
   1:xorg-x11-drv-ati       ########################################### [100%]
[root@localhost ~]# 

All of that appears healthy.  So I edited /etc/X11/xorg.conf to contain:

Section "Device"
	Identifier  "Videocard0"
        Driver      "r128"
#	Driver      "vesa"
EndSection

to try using the default r128 driver.  After booting, X does start,
and I can see the symptoms of the display misconfiguration described in:
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231113
on the initial booting progress bar, but about the time the bar shows
completion, X crashes and the screen fades to white.  At this point
Ctrl+Alt+F1 or F2 or Ctrl+Alt+Backspace, etc.  all have no effect
... only the power switch leads to any result.  Those two symptoms
have only shown themselves in the past (on earlier releases than f9)
when the r128 driver was in use.  But despite the contents of
xorg.conf, /var/log/Xorg.0.log only mentions VESA from this run !!?!

  It did NOT stay up long enough for lines such as the normal:

Apr 24 09:33:50 localhost gdm-simple-slave[2221]: DEBUG: GdmServer: Starting X
server process: /usr/bin/Xorg :0 -br -verbose -auth /tmp/.gdm-xauth-gdm.023CAU
-nolisten tcp
Apr 24 09:33:50 localhost gdm-simple-slave[2222]: DEBUG: GdmServer: Opening
logfile for server /var/log/gdm/:0.log
Apr 24 09:33:50 localhost gdm-simple-slave[2221]: DEBUG: GdmServer: Started X
server process 2222 - waiting for READY
Apr 24 09:33:50 localhost gdm-simple-slave[2221]: DEBUG: GdmSimpleSlave: Started
X server

to be written to /var/log/messages, nor to progress to attempting to
display the user login screen.

  Rename xorg.conf to xorg.conf.hidden, try again.  Same results as 
described above, but this time I note that the file /var/log/Xorg.0.log
still has the timestamp of the previous boot, so as one would expect it
still has the same contents (VESA bits only, no trail from r128).

  Just to add to the puzzlement, I restored /etc/X11/xorg.conf so that
it contained the previously working:

Section "Device"
	Identifier  "Videocard0"
#       Driver      "r128"
	Driver      "vesa"
EndSection

and an attempt to boot with that led to a third occurrence of the 
improperly configured screen, followed by a white screen X crash.
Again the file /var/log/Xorg.0.log still has the timestamp of the 
now second-previous boot, so there is no useful evidence to attach
from that file.  

  I am willing to test the next iteration of the driver, particularly
if someone offers some insights on how to encourage X to leave us 
some more clues.  (Can't get to a vt command line to issue "sync".)
This is on the same hardware as mentioned in comment #2 (with 
Xorg.0.log) and comment #3.

  Yes, it would also be nice to deduce how to run (instead of crash)
with the VESA driver once again.  I guess step 1 will be to uninstall 
this test ati driver?  (Now you understand even more my willingness
to try out the next xorg-x11-drv-ati-....)

Cheers,
Nelson

  There seems to be a timing bug that introduces lack of determinism
into the results of trying to boot with this driver.

  Booting into runlevel 3 (by using grub to add "3" to the kernel
arguments) and using "startx" from the command line provides variable
results.  In each case:

  startx 2>&1 > startx.log

has left the file startx.log of size 0.  Some of the various results are:
 
 1 - See desktop displayed (in discontiguous overlaid stripes, see
     https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231113 ), but
     before I can attempt to repair the display misconfiguration via
     system-config-display and restart X in a usable setting, X crashes
     fading to a white screen.
 2 - [Fuzzy notes and memory, but something like] stippled grey background
     with frozen mouse pointer icon in center of screen, maybe with disk
     access LED on continuously for a few minutes (before power off).
 3 - X crashes fading to a white screen.
 4 - Results in black screen, no visible pointer, no response to any
     keyboard sequences (e.g. to switch back to a terminal), had to
     use the power switch.
 5 - Encountered a kernel oops before the desktop was fully displayed.
     Sent that off, used system-config-display to properly configure
     for usable screen resolution, X crashes with fading to white screen
     as attempt to restart X with Ctrl+Alt+Backspace.

The Xorg.0.log files from each case seem rather as expected (e.g. they
even admit that the R128 driver is in use, although it appears we
still suffer from lack of buffer flushing / failure to progress to
where the current log file is written to a persistent file in some
cases), although in a couple of cases there are a few unusual lines at
the end:
 
In cases 2 and 3, the last 3 lines in the log are unusual:

  :
(II) Macintosh mouse button emulation: Close
(II) TPPS/2 IBM TrackPoint: Close
(II) R128(0): [drm] removed 1 reserved context for kernel
(II) R128(0): [drm] unmapping 8192 bytes of SAREA 0xe0af8000 at 0xb7fb0000
(II) R128(0): [drm] Closed DRM master.


In case 4, the last line is unusual:

  : 
(II) Initializing built-in extension XEVIE
(II) AIGLX: Screen 0 is not DRI2 capable
drmOpenDevice: node name is /dev/dri/card0

I tried xorg-x11-drv-ati-6.8.0-12.fc9 from koji, and it works. I can start a kde
session and the strange appearance of system monitor is gone. Should I file a
new bug on the vesa driver for r128 hardware ?

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.