Description of problem:
on my dell 4100, the fedora9 beta liveCd cannot start X. The beta boots, without
X. Logging in as fedora and issuing a startx produces an error from xserver with
the message: (EE) R128(0): cannot allocate space for hold video BIOS!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. boot from liveCd
2. login as fedora
Laptop has ATI Rage mobility chipset.
I will try liveCd later, using VESA.
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?
Created attachment 300177 [details]
/var/log/Xorg.0.log from a run with no xorg.conf
While running a rawhide system updated to:
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:
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!
0: /usr/bin/Xorg(xf86SigHandler+0x79) [0x80bc2c9]
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
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
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
[root@localhost ~]# koji download-build --arch=`uname -i`
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%]
All of that appears healthy. So I edited /etc/X11/xorg.conf to contain:
# Driver "vesa"
to try using the default r128 driver. After booting, X does start,
and I can see the symptoms of the display misconfiguration described in:
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: DEBUG: GdmServer: Starting X
server process: /usr/bin/Xorg :0 -br -verbose -auth /tmp/.gdm-xauth-gdm.023CAU
Apr 24 09:33:50 localhost gdm-simple-slave: DEBUG: GdmServer: Opening
logfile for server /var/log/gdm/:0.log
Apr 24 09:33:50 localhost gdm-simple-slave: DEBUG: GdmServer: Started X
server process 2222 - waiting for READY
Apr 24 09:33:50 localhost gdm-simple-slave: DEBUG: GdmSimpleSlave: Started
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:
# Driver "r128"
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-....)
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
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:
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:
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.