Description of problem: After yum update X fails to start. Xorg.0.log contains: (II) RADEON(0): Set up textured video failed to add fb The dmesg contains: [drm:radeon_cp_init_kms] *ERROR* invalid ioctl with kms radeon_cp_init_kms Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.12.2-19.fc12.1.x86_64 kernel-2.6.31-0.69.rc3.fc12.x86_64 How reproducible: Synchronous Steps to Reproduce: 1. Find a box with Radeon Xpress 2. Kill xorg.conf, so radeon is used 3. startx Actual results: Fails to start Expected results: Starts Additional info: David, this is clearly an incompatibility between latest Rawhide kernel and latest radeon module in DRM mode (see versions above). Please play a minimum attention to cross-version compatibility!
Created attachment 354369 [details] Xorg.0.log
Created attachment 354370 [details] dmesg
*** Bug 513336 has been marked as a duplicate of this bug. ***
I am seeing the same problem on a ThinkPad T41 with radeon RV250 graphics kernel-2.6.31-0.86.rc3.git5.fc12.i686 xorg-x11-server-Xorg-1.6.99-14.20090715.fc12.i586 xorg-x11-drv-ati-6.12.2-19.fc12.1.i586 libdrm-2.4.12-0.2.fc12.i586 http://forums.fedoraforum.org/showthread.php?t=226903
*** Bug 511930 has been marked as a duplicate of this bug. ***
I am seeing the same problem on a Dell Latitude D600 with radeon RV250 graphics. kernel-2.6.31-0.81.rc3.git4.fc12.i686 xorg-x11-server-Xorg-1.6.99-14.20090715.fc12.i586 xorg-x11-drv-ati-6.12.2-19.fc12.1.i586 libdrm-2.4.12-0.2.fc12.i586
Can you check if 'nomodeset' kernel parameter changes the behaviour? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Same problem here (also T41 with RV250). kernel-2.6.31-0.69.rc3.fc12.i586 xorg-x11-drv-ati-6.12.2-19.fc12.1.i586 nomodeset doesn't help. That could be because this function is broken (in current mainline kernel): static int __init radeon_init(void) { driver = &driver_old; driver->num_ioctls = radeon_max_ioctl; #if defined(CONFIG_DRM_RADEON_KMS) /* if enabled by default */ if (radeon_modeset == -1) { DRM_INFO("radeon default to kernel modesetting.\n"); radeon_modeset = 1; } if (radeon_modeset == 1) { DRM_INFO("radeon kernel modesetting enabled.\n"); driver = &kms_driver; driver->driver_features |= DRIVER_MODESET; driver->num_ioctls = radeon_max_kms_ioctl; } /* if the vga console setting is enabled still * let modprobe override it */ #ifdef CONFIG_VGA_CONSOLE if (vgacon_text_force() && radeon_modeset == -1) { DRM_INFO("VGACON disable radeon kernel modesetting.\n"); driver = &driver_old; driver->driver_features &= ~DRIVER_MODESET; radeon_modeset = 0; } #endif #endif return drm_init(driver); } vgacon_text_force() returns true if the nomodeset parameter is used. But by the time that is checked radeon_modeset will never equal -1 so it seems radeon kernel modesetting can never be disabled. (I noticed this earlier, and should have reported that to the author of this code.) I'm not sure at all what the purpose of this code is though, so I haven't even tried a patch. Will test radeon.modeset=0 shortly.
radeon.modeset=0 seems to help. It does however print a warning at boot: Unknown boot option `radeon.modeset=0': ignoring (which also shows up in dmesg). That warning notwithstanding, X does start now (correctly it seems, since this comment I can write in Firefox whereas comment #8 I still had to write in elinks ...). False warning? Further details needed?
Option "radeon.modeset=0" works on my ATI Technologies Inc Radeon X800 SE (R430) (PCIE) rev 0, too, whereas option "nomodeset" would not. I had reported bug 510673 on this issue.
as an additional comment, I mistyped it and instead wrote radeon.nomodeset=0 and that also disabled modeset and X worked. Kernel command line: ro root=/dev/mapper/vg_t41-lv_root rhgb quiet hpet=force radeon.nomodeset=0 Unknown boot option `radeon.nomodeset=0': ignoring ..... [drm] Initialized drm 1.1.0 20060810 modprobe used greatest stack depth: 6612 bytes left radeon: Unknown parameter `nomodeset' modprobe used greatest stack depth: 6524 bytes left ..... radeon: Unknown parameter `nomodeset' ..... That is all the messages to do with DRM or RADEON in my bootlog, so it would seem that if it encounters an unknown option it just exits.
Created attachment 355183 [details] dmesg output with drm.debug=1 I had the same problem at my Thinkpad R51e (ATI Technologies Inc RC410 [Radeon Xpress 200M]) I install Fedora11 from Beta-LiveCD, after upgrade to Release, X crash as bug https://bugzilla.redhat.com/show_bug.cgi?id=498457. Now I upgrade to rawhide: kernel-2.6.31-0.86.rc3.git5.fc12.i686 mesa-dri-drivers-7.6-0.4.fc12.i686 (from koji) libdrm-2.4.12-0.2.fc12.i586 xorg-x11-drv-ati-6.12.2-19.fc12.1.i586 I wish my drm.debug=1 dmesg log would help the debug process
*** Bug 514238 has been marked as a duplicate of this bug. ***
kernel-2.6.31-0.118.rc5.fc12 with the radeon KMS updates makes no difference, I still get the same failure when KMS is enabled.
*** Bug 514449 has been marked as a duplicate of this bug. ***
With the latest updates applied this particular issue is resolved for me kernel-2.6.31-0.132.rc5.git3.fc12.i686 xorg-x11-server-Xorg-1.6.99-26.20090804.fc12.i686 xorg-x11-drv-ati-6.12.2-21.fc12.i686
I confirm that as of - kernel-2.6.31-0.132.rc5.git3.fc12.x86_64 - xorg-x11-drv-ati-6.12.2-21.fc12.x86_64 - xorg-x11-server-Xorg-1.6.99-26.20090804.fc12.x86_64 X is fully functional again. It starts correctly both with and without KMS.
I think one more confirmation and we can kill this - Pete? Kyle? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Works for me too.
OK, let's call it fixed. good stuff. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The xorg-x11-drv-ati-6.12.2-21.fc12.x86_64 fixes the bug for me. I opened bug 515785 for the new crash with different symptoms.
*** Bug 515283 has been marked as a duplicate of this bug. ***