Bug 518180 - [kms, ati] crash on X server start
Summary: [kms, ati] crash on X server start
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-08-19 11:04 UTC by Robert de Rooy
Modified: 2018-04-11 09:55 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-06 08:44:35 UTC
Type: ---

Attachments (Terms of Use)
xorg log with backtrace (18.58 KB, text/plain)
2009-08-19 11:05 UTC, Robert de Rooy
no flags Details
dmesg log file (33.74 KB, text/plain)
2009-08-19 11:12 UTC, Robert de Rooy
no flags Details
xorg log from gdm starting (29.07 KB, text/plain)
2009-08-20 08:14 UTC, Robert de Rooy
no flags Details
log after apending radeon.modeset=0 (63.64 KB, application/octet-stream)
2009-08-21 00:03 UTC, Todd
no flags Details
updated dmesg (79.36 KB, text/plain)
2009-09-12 21:36 UTC, Robert de Rooy
no flags Details
updated xorg log from gdm starting (29.05 KB, text/plain)
2009-09-12 21:37 UTC, Robert de Rooy
no flags Details

Description Robert de Rooy 2009-08-19 11:04:43 UTC
Description of problem:
ThinkPad X22 with ATI RV100 running Rawhide
with KMS enabled the X server dies when starting. I do get to briefly see GDM before it crashes and restarts.

Version-Release number of selected component (if applicable):
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA controller])
	Subsystem: IBM ThinkPad X22/X23/X24
	Flags: bus master, stepping, fast Back2Back, 66MHz, medium devsel, latency 66, IRQ 11
	Memory at e0000000 (32-bit, prefetchable) [size=128M]
	I/O ports at 2000 [size=256]
	Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
	[virtual] Expansion ROM at c0120000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: radeon
	Kernel modules: radeon, radeonfb


How reproducible:
every time

Steps to Reproduce:
1. Install current rawhide on X22
2. boot
Actual results:
backtrace in xorg log

Expected results:
no crash

Additional info:
I can work around it for now by disabling KMS with nomodeset at boot. In addition KMS did work with F11, so this is a regression.

Comment 1 Robert de Rooy 2009-08-19 11:05:44 UTC
Created attachment 357918 [details]
xorg log with backtrace

Comment 2 Robert de Rooy 2009-08-19 11:12:03 UTC
Created attachment 357919 [details]
dmesg log file

Comment 3 Adam Jackson 2009-08-19 17:58:43 UTC
Build ID: xorg-x11-server 1.6.99-25.20090804.fc12 

Your log file and comment #0 disagree.  Please attach an X log from 1.6.99-36 or later showing the crash.

Comment 4 Robert de Rooy 2009-08-20 08:14:49 UTC
Created attachment 358052 [details]
xorg log from gdm starting

Sorry about that, I was looking for the log with the crash and came across an older log file with a different crash and assumed it was the right one without double checking.

Since this is a crash during GDM I obviously needed the Xorg log from the /var/log/gdm directory instead.

The actual failure is
Xorg: radeon_cs_gem.c:121: cs_gem_write_reloc: Assertion `bo->space_accounted' failed.

Comment 5 Todd 2009-08-21 00:02:47 UTC
I _think_ I am being affected by this bug. I upgraded from a F11 install using preupgrade. now the screen blanks after startup.  CRTL-ALT-F2 has no effect.  If I append radeon.modeset=0 to the kernel, everything works as I would expect, except I don't get the fancy Plymouth screen.  I can't seem to find a log from the crash, but I will attach the X log from when I boot with the append kernel.

Comment 6 Todd 2009-08-21 00:03:49 UTC
Created attachment 358178 [details]
log after apending radeon.modeset=0

Comment 7 Robert de Rooy 2009-08-21 09:33:36 UTC
Todd, I do not see anything in the data you supplied to make me think you have the same problem.
Especially your log file is useless, since it is with KMS disabled. Please enable KMS and check if your log file contains the error I mentioned in comment #4

Comment 8 Dan Williams 2009-09-11 00:19:35 UTC
Does latest mesa make a difference:


that fixed this error for me on an r100-based T42...

Comment 9 Robert de Rooy 2009-09-12 21:35:32 UTC
It gets a bit further, but it still fails.

I do however get some more verbose messages in the logs

Comment 10 Robert de Rooy 2009-09-12 21:36:36 UTC
Created attachment 360816 [details]
updated dmesg

Comment 11 Robert de Rooy 2009-09-12 21:37:37 UTC
Created attachment 360817 [details]
updated xorg log from gdm starting

Comment 12 Robert de Rooy 2009-10-06 08:59:38 UTC
I just installed the latest Xorg updates, and I no longer get a X server crash with KMS enabled. Having said that, I do get

- display corruption when starting GDM, seems like the vram is not cleared before it being used, this does clear up and I get to see GDM.
- during the GDM session my mouse cursor is a square block of random corruption, but this cleared after login (probably related to the issue above)
- graphics are extremely slow compared to booting with nomodeset


But the issue for which the bug report was opened, can be considered solved.

Comment 13 Matěj Cepl 2009-11-05 17:14:10 UTC
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Comment 14 Robert de Rooy 2009-11-05 18:08:10 UTC
As I mentioned already, this issue was resolved. There where other problems, some of which might have been solved with later updates. However I am unable to do any more testing with this system as the systemboard has failed and no longer boots.

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