Bug 512757 - [KMS] X fails to start, invalid ioctl with kms radeon_cp_init_kms
[KMS] X fails to start, invalid ioctl with kms radeon_cp_init_kms
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: 511930 513336 514238 514449 515283 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-07-20 13:06 EDT by Pete Zaitcev
Modified: 2009-08-06 09:14 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-08-05 13:12:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log (30.54 KB, text/plain)
2009-07-20 13:06 EDT, Pete Zaitcev
no flags Details
dmesg (39.42 KB, text/plain)
2009-07-20 13:07 EDT, Pete Zaitcev
no flags Details
dmesg output with drm.debug=1 (43.27 KB, text/plain)
2009-07-26 04:12 EDT, Yingbo Qiu
no flags Details

  None (edit)
Description Pete Zaitcev 2009-07-20 13:06:09 EDT
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):


How reproducible:


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:


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!
Comment 1 Pete Zaitcev 2009-07-20 13:06:53 EDT
Created attachment 354369 [details]
Comment 2 Pete Zaitcev 2009-07-20 13:07:24 EDT
Created attachment 354370 [details]
Comment 3 Kyle VanderBeek 2009-07-23 02:44:23 EDT
*** Bug 513336 has been marked as a duplicate of this bug. ***
Comment 4 Robert de Rooy 2009-07-23 04:04:54 EDT
I am seeing the same problem on a ThinkPad T41 with radeon RV250 graphics


Comment 5 Robert de Rooy 2009-07-23 04:12:03 EDT
*** Bug 511930 has been marked as a duplicate of this bug. ***
Comment 6 Jerry Amundson 2009-07-23 10:15:23 EDT
I am seeing the same problem on a Dell Latitude D600 with radeon RV250 graphics.

Comment 7 Adam Williamson 2009-07-23 18:12:31 EDT
Can you check if 'nomodeset' kernel parameter changes the behaviour? Thanks.

Fedora Bugzappers volunteer triage team
Comment 8 Paul Bolle 2009-07-23 19:42:48 EDT
Same problem here (also T41 with RV250).


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 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 */
        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;
        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.
Comment 9 Paul Bolle 2009-07-23 19:53:46 EDT
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?
Comment 10 Joachim Frieben 2009-07-24 03:00:02 EDT
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.
Comment 11 Robert de Rooy 2009-07-24 03:32:01 EDT
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.
Comment 12 Yingbo Qiu 2009-07-26 04:12:34 EDT
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:
mesa-dri-drivers-7.6-0.4.fc12.i686 (from koji)

I wish my drm.debug=1 dmesg log would help the debug process
Comment 13 Alan Crosswell 2009-08-02 10:14:22 EDT
*** Bug 514238 has been marked as a duplicate of this bug. ***
Comment 14 Robert de Rooy 2009-08-03 03:55:36 EDT
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.
Comment 15 Pete Zaitcev 2009-08-03 16:11:51 EDT
*** Bug 514449 has been marked as a duplicate of this bug. ***
Comment 16 Robert de Rooy 2009-08-05 08:33:15 EDT
With the latest updates applied this particular issue is resolved for me

Comment 17 Joachim Frieben 2009-08-05 10:33:42 EDT
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.
Comment 18 Adam Williamson 2009-08-05 12:36:33 EDT
I think one more confirmation and we can kill this - Pete? Kyle?

Fedora Bugzappers volunteer triage team
Comment 19 Warren Togami 2009-08-05 12:39:56 EDT
Works for me too.
Comment 20 Adam Williamson 2009-08-05 13:12:44 EDT
OK, let's call it fixed. good stuff.

Fedora Bugzappers volunteer triage team
Comment 21 Pete Zaitcev 2009-08-05 13:56:02 EDT
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.
Comment 22 Bill Nottingham 2009-08-06 09:14:26 EDT
*** Bug 515283 has been marked as a duplicate of this bug. ***

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