Bug 439022 - fedora9 beta liveCd cannot startx
Summary: fedora9 beta liveCd cannot startx
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dave Airlie
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-03-26 15:54 UTC by Herbert Carl Meyer
Modified: 2018-04-11 09:03 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-14 17:27:55 UTC

Attachments (Terms of Use)
/var/log/Xorg.0.log from a run with no xorg.conf (12.59 KB, text/plain)
2008-04-03 05:11 UTC, xunilarodef
no flags Details

Description Herbert Carl Meyer 2008-03-26 15:54:07 UTC
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):

fedora9 beta

How reproducible:

Steps to Reproduce:
1. boot from liveCd
2. login as fedora
3. startx
Actual results:
error message

Expected results:
X windows

Additional info:
Laptop has ATI Rage mobility chipset.
I will try liveCd later, using VESA.

Comment 1 Matěj Cepl 2008-03-27 16:43:30 UTC
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

Comment 2 xunilarodef 2008-04-03 05:11:54 UTC
Created attachment 300177 [details]
/var/log/Xorg.0.log from a run with no xorg.conf

Comment 3 xunilarodef 2008-04-03 05:14:01 UTC
  While running a rawhide system updated to:
    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"
 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]
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

Comment 4 bjordonthaden 2008-04-20 18:37:18 UTC
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

Comment 5 bjordonthaden 2008-04-20 18:48:06 UTC
p.s. Xserver will run with vesa driver.

Comment 6 Herbert Carl Meyer 2008-04-23 12:44:35 UTC
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.

Comment 7 Dave Airlie 2008-04-24 06:16:37 UTC
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.

Comment 8 xunilarodef 2008-04-24 15:59:39 UTC
  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%]
[root@localhost ~]# 

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

Section "Device"
	Identifier  "Videocard0"
        Driver      "r128"
#	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[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"

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


Comment 9 xunilarodef 2008-04-24 19:45:39 UTC
  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

Comment 10 Herbert Carl Meyer 2008-04-25 17:35:38 UTC
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 ?

Comment 11 Bug Zapper 2008-05-14 06:53:19 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 12 Bug Zapper 2009-06-09 23:52:29 UTC
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: 

Comment 13 Bug Zapper 2009-07-14 17:27:55 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.