Description of problem: X fails to start, apparently while POSTing the two PCI video cards (radeon). Version-Release number of selected component (if applicable): 2.6.24.4-64.fc8 How reproducible: Boot recent kernel update. Try to start X. Steps to Reproduce: 1. Boot 2. Log in at console 3. mv X.log X.log.old ; exec startx -- -config xorg.conf.xaa -dpi 86 >X.log 2>&1 Actual results: Emulator asked to make a suspect word access to port 0 (0x0000); terminating. Backtrace: 0: /usr/bin/X(xf86SigHandler+0x81) [0x80c2f91] 1: [0x11e420] 2: [0x11e402] 3: /lib/libc.so.6(kill+0x16) [0xbf5ac6] 4: /usr/lib/xorg/modules//libint10.so [0x2b4441] 5: /usr/lib/xorg/modules//libint10.so(x_inw+0x8d) [0x2b486d] 6: /usr/lib/xorg/modules//libint10.so [0x2bb51e] 7: /usr/lib/xorg/modules//libint10.so(X86EMU_exec+0xa3) [0x2c9de3] 8: /usr/lib/xorg/modules//libint10.so(xf86ExecX86int10+0x55) [0x2b6315] 9: /usr/lib/xorg/modules//libint10.so(xf86ExtendedInitInt10+0x3d4) [0x2b7004] 10: /usr/lib/xorg/modules//libint10.so(xf86InitInt10+0x25) [0x2b4145] 11: /usr/lib/xorg/modules/drivers//radeon_drv.so(RADEONPreInit+0x9f1) [0x244fc1] 12: /usr/bin/X(InitOutput+0x9a8) [0x80a3348] 13: /usr/bin/X(main+0x27b) [0x807032b] 14: /lib/libc.so.6(__libc_start_main+0xe0) [0xbe2390] 15: /usr/bin/X(FontFileCompleteXLFD+0x1f1) [0x806f831] Fatal server error: Caught signal 11. Server aborting Expected results: (II) Module already built-in (II) Module already built-in NTSC PAL finished output detect: 0 finished output detect: 1 finished output detect: 2 finished all detect ... etc Additional info: Have verified this is specific to new kernel by booting into previous kernel. Problem only occurs with 2.6.24.4-64.fc8. Not that this actually proves anything, I understand ...
Created attachment 300410 [details] output of lspci -v
Created attachment 300411 [details] Log of failed attempt to start X
Created attachment 300412 [details] Log of successful attempt to start X (plus noise :o))
Created attachment 300413 [details] /var/log/messages output from failed session I've clipped out the part from the previous boot where X failed to start; I can't actually see anything that might be relevant, but I'd rather include it and have it be useful than vice versa ...
Created attachment 300414 [details] /var/log/messages output from successful session
Can you post the output of lspci -v from the other kernel? (And which one was that from in comment #1?)
I believe the one in comment #1 is from the current kernel (because I had to reboot to start X to log into Bugzilla, etc ... :o)). I will try to remember to post the other later, but I have to use this machine for work, alas.
Created attachment 301651 [details] lspci -v from kernel 2.6.24.4-64.fc8
Created attachment 301652 [details] lspci -vv from kernel 2.6.24.4-64.fc8
Created attachment 301653 [details] lspci -x from kernel 2.6.24.4-64.fc8
The most useful piece of info might actually be this. The working kernel + Xorg combination logs as follows: compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.2 (II) RADEON(0): initializing int10 (II) Attempted to read BIOS 128KB from /sys/bus/pci/devices/0000:00:0a.0/rom: got 52KB (--) RADEON(0): Chipset: "ATI Radeon 9250 5960 (AGP)" (ChipID = 0x5960) (--) RADEON(0): Linear framebuffer at 0x00000000d8000000 (II) RADEON(0): PCI card detected (II) RADEON(0): Legacy BIOS detected drmOpenDevice: node name is /dev/dri/card0 ... The failed one just goes straight to the traceback as noted in the bug: compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.2 (II) RADEON(0): initializing int10 Emulator asked to make a suspect word access to port 0 (0x0000); terminating. Backtrace: 0: Xorg(xf86SigHandler+0x81) [0x80c2f91] ... So it looks like the failure is even before attempting to read the VBIOS.
Created attachment 301666 [details] lspci -v from kernel 2.6.24.3-50.fc8
Created attachment 301667 [details] lspci -vv from kernel 2.6.24.3-50.fc8
Created attachment 301668 [details] lspci -x from kernel 2.6.24.3-50.fc8
Last three are from a root xterm in the X session, so probably not too useful for comparison. Will try to capture after fresh reboot tomorrow or so if that would be more help.
Silly question, but is there anything else I can do to help debug this?
Ajax, could this be caused by not mapping the ROM of non-boot adapters? That change was backported from the 2.6.25 kernel: commit 9f8daccaa05c14e5643bdd4faf5aed9cc8e6f11e PCI: remove default PCI expansion ROM memory allocation 2.6.24.4-50: 00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] Region 2: Memory at eb110000 (32-bit, non-prefetchable) [size=64K] 2.6.24.4-64: 00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA controller]) Region 2: Memory at eb110000 (32-bit, non-prefetchable) [disabled] [size=64K]
Adding "pci=rom" to the kernel boot options should enable the ROM.
Can pciaccess be made to enable the rom before trying to read it? Or is the disabling "permanent"?
Finally rebooted yesterday; yes the pci=rom workaround fixes things for me. Is this likely to remain necessary? One of my colleagues has been bitten by this this morning (on Debian Etch) ... granted we're on cheap hardware, but it's not exactly uncommon (Acer Aspire, various models).
We can revert the backport for Fedora 8, but Fedora 9 gets this change directly from kernel 2.6.25. Is this going to cause a problem in Fedora 9 too?
Honestly, I can't tell without testing rawhide on my system at work, which I don't dare do at the moment ... rawhide is working pretty well here at home, but that only has one card, and it's therefore the "primary" anyway. I suppose I'm just surprised this change was made defaulting to "on" ... If I get a chance I'll try installing the rawhide X server. It might behave differently. Can the roms be enabled by the X server when needed? ISTR at one point there was actually code to enable rom mapping via sysfs before reading them?
I'll rephrase that: this is definitely a problem in F8, please ask the X team if it's likely to be an issue for F9 onwards.
This change was reverted in 2.6.26, so reverting in the F9 2.6.25 kernel. F8 will get this kernel very soon...
OK, please close as CURRENTRELEASE when we do ;o) in the meantime the workaround is in my grub.conf (and I don't reboot that often anyway).
kernel-2.6.25.4-30.fc9 has been submitted as an update for Fedora 9
kernel-2.6.25.4-30.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-4630
Hi, there's a f9 update in bodhi which mentions this bug (https://admin.fedoraproject.org/updates/F9/FEDORA-2008-4630) but the latest f8 update (https://admin.fedoraproject.org/updates/F8/FEDORA-2008-4484) doesn't mention it. Is this an oversight (i.e. should I go ahead and grab it and try it)?
kernel-2.6.25.4-30.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
Erm, guys? This was reported against F8 ;o)
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. 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 '8'. 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 8'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 8 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.