Description of problem: After installing FC2 from CD onto this AMD64 Opteron, everything goes fine until after the end of the firstboot screen, when X tries to start. The screen goes blank and nothing else happens. Logging into a text console and running 'ps' I can see that X is in R state, and 'strace' and 'ltrace' show no output. The funny thing is that anaconda and firstboot worked fine in graphical mode. Version-Release number of selected component (if applicable): xorg-x11-6.7.0-2 How reproducible: 100%
If I edit the xorg.conf file and change 'vesa' to 'radeon' it all works fine (and fast). Console switching also works.
With today's rawhide (first I've tested this in weeks) it is even worse: X doesn't even start properly in Anaconda. Just get a black screen. xorg-x11-6.7.0-6
The kernel is most likely breaking vesa BIOS access, as nothing has changed in X. Nothing I can do about that, but you could file a kernel bug report for it. If "radeon" works as it should though, then this is just a hardware database issue to resolve by pointing the PCI ID to the "radeon" driver. I plan PCI ID updates for sometime in August when I return from vacation. If you supply lspci -vvn and reassign to hwdata, someone might change this one card before then for you though, or you could update it yourself if there's no ACL. HTH
"radeon" works fine, just slowly. 02:00.1 Class 0380: 1002:4e6a Subsystem: 1462:9561 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (2000ns min), Cache Line Size 08 Region 0: Memory at d8000000 (32-bit, prefetchable) Region 1: Memory at ff5e0000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Can you attach the X server log, /var/log/messages and the output of /proc/mtrr? You're probably getting broken MTRRs. There is a kernel bug with MTRR on x86_64 (glibc-kernheaders actually), but I don't know if/when it gets fixed. X probably needs to be recompiled for the fix to get used. In the mean time, if MTRR isn't active, try setting it manually via the /proc/mtrr interface. Your video RAM is at 0xd8000000 so set up an MTRR there with range the size of video RAM. If it fails to set it up, you might need to split MTRR which is a PITA. Once set up tho, you can script it in rc.local for now until the kernel header issue is fixed.
hwdata-0.123-1 I've added a bunch of radeon entries and mapped them to radeon driver. There are probably a lot of cosmetic glitches and incorrect card names, etc. as I just went by the sf.net data, which is often wrong. This should get all ATI hardware we know about at least pointed to the "radeon" driver now though, and I can worry about completing the list and fixing up cosmetics in a month or so. Closing as fixed in rawhide for now, but there's another bug open for the MTRR issues on x86_64.. don't have bug ID handy, but CC yourself on it and add the info requested above. TIA