When I start the X server the screen goes blank and machine locks up hard. Caps key does not light caps LED. cant switch VT. can't ping. sometimes the machine reboots. I see this with the radeon driver, vesa works fine. I have a ASUS EAH3650 SILENT, ATI radeon HD 3650 08:00.0 VGA compatible controller: ATI Technologies Inc Mobilitiy Radeon HD 3600 Series I am running ubuntu intrepid (dev branch). with xserver-xorg-core 2:1.4.99.906-1ubuntu3 and xserver-xorg-video-radeon 1:6.9.0+git20080802.1f3eee36-1ubuntu1 the bug is reported downstream at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/254583 you can find some strace and gdb logs there. I can copy them here if that is useful for you.
From the gdb debugging, it can be seen that it dies (hangs) in RADEONMapMMIO -> pci_device_map_range -> mmap See the gdb log http://launchpadlibrarian.net/16676661/xorg.3650.gdb4.log from the Ubuntu bug for more details, function arguments, local variables etc.
Just offhand, sounds like fglrx is present in the kernel, blocking a successful MMIO setup. Were you using fglrx before?
no. i had the linux restricted modules installed, but never the fglrx packages (not on this install anyway). i have removed the restricted-modules, rebooted, and the problem persists.
Just to confirm, the only files on the system with fglrx in the name, are the install scripts in ubuntu's jockey, and the .desktop file in app-install. I did a cold start (machine had been off for hours). booted with mem=1024M, nosplash screen. the machine still locked and rebooted when starting the X server.
Created attachment 18566 [details] fixed Xorg.0.log
this is fixed with latest ubuntu updates 1:7.4~1ubuntu1. X.Org X Server 1.4.99.906 (1.5.0 RC 6)
It seems that it was the kernel upgrade from 2.6.26 to 2.6.27 that actually fixed this.
I ran into this in 2.6.27-rc5-00006-gbef69ea yesterday (latest Git kernel), and latest Git ati driver, so I don't think it's fixed in new kernels. Testing specifics: - To trigger the bug, you MUST cause the card to POST with a display on the DVI-0 output. If there is only a display on the DVI-1 output, it works perfectly. Simply disconnecting the DVI-0 output is not sufficent. I did however trace it using poor-mans debugging (print statements). In src/radeon_modes.c, the RADEONProbeOutputModes, this block: 285 if (output->MonInfo) 286 modes = xf86OutputGetEDIDModes (output); It's inside that call that it's hanging. After commenting out those two lines, X comes up perfectly for me. Maybe related, maybe unrelated, when I exit X with that change, sometimes the contents of DVI-0 end up on both monitors again, frozen so the console isn't restored.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.