Bug 25607 - drmCheckModesettingSupported fails if X loaded radeon modeset=1 just before
drmCheckModesettingSupported fails if X loaded radeon modeset=1 just before
Status: REOPENED
Product: xorg
Classification: Unclassified
Component: Driver/Radeon
git
Other All
: medium normal
Assigned To: xf86-video-ati maintainers
Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-12 03:07 UTC by Brice Goglin
Modified: 2012-07-30 13:14 UTC (History)
1 user (show)

See Also:


Attachments
Load kernel module before checking for KMS (1.53 KB, patch)
2010-02-01 14:09 UTC, Pauli
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Brice Goglin 2009-12-12 03:07:29 UTC
If using KMS without loading radeon automatically during boot, X loads the radeon kernel module at startup but drmCheckModesettingSupported fails. It looks like drm sysfs files are not setup yet when drmCheckModesettingSupported runs. My understanding is that X loads the radeon kernel module but it doesn't wait long enough before trying to use what radeon is setting up in the kernel and sysfs.

So X starts without enabling KMS support, which works but disables DRI2. Then if I restart X, drm files are already setup, so KMS/DRI2 gets enabled this time, but the display gets screwed up...

If I load radeon during boot, or if I load it manually before starting X, everything looks good.

This is a Thinkpad T43 with rv370. Running Linux 2.6.32 (from Debian sid, with RADEON_KMS not set), libdrm 2.4.16 with radeon experimental api enabled, Xserver 1.7.3, xf86-video-radeon git master from yesterday, and Mesa 7.6.1-rc3.
Comment 1 Pauli 2010-02-01 14:09:52 UTC
Created attachment 32981 [details] [review]
Load kernel module before checking for KMS

In fact kernel module is loaded after KMS support is checked. Attached patch is idea how to make ddx load kernel module before checking for KMS support. Code is a bit modified copy/paste from DRI initialization code that would normally handle kernel module loading.

I didn't test if it really works because on my system radeon module is auto-loaded early in boot.
Comment 2 Daniel Vetter 2010-02-01 15:19:21 UTC
I've experienced the same problem. Preloading the radeon module fixes it, here too.
Also, intel (i915 drm module) has the same problem. My hw: rv570 (radeon) and i855gm (intel).
Comment 3 Michel Dänzer 2012-05-14 03:29:37 UTC
According to Dave Airlie this isn't (easily) fixable completely. Current xf86-video-ati Git bails in this case, and then the next X server startup should work properly.
Comment 4 Fabio Erculiani 2012-07-28 17:37:27 UTC
This is becoming a problem for many people and distros now that KMS is mandatory.
On Linux, if CONFIG_DRM_RADEON_KMS is not enabled, X loads (through the DRI interface I suppose) radeon.ko correctly but X initialization fails as pointed out 3 years ago by Brice Goglin.

Otoh, forcing CONFIG_DRM_RADEON_KMS=y in distributed kernels makes fglrx users' life really hard. So, what are distributors supposed to do in your opinion? Do we really have to consider fglrx and radeon to be mutually exclusive at package manager level? That would be suboptimal as well.
Comment 5 Alex Deucher 2012-07-28 21:18:24 UTC
As of 6.14.3 the ddx will stop loading if the ddx is in UMS mode and the drm is in KMS mode to prevent display problems.  UMS is no longer supported in the DDX on Linux.  Support for UMS was removed in xf86-video-ati git last month.  UMS only supported chips up through evergreen and the open source 3D drivers dropped UMS support a while ago.

The open source radeon driver and fglrx are completely different driver stacks and require some system adjustments to switch between then (different kernel modules, different ddx, different 3D drivers, different libgl and libglx, etc.).  It's probably easiest to have a script to switch the environments between the two drivers or something like that.
Comment 6 Fabio Erculiani 2012-07-29 13:26:56 UTC
Userspace is not a problem here, many distributions have GL implementation switch tools already.

I have users reporting that 6.14.4 suffers from the problem reported here.
Basically, radeon.ko is loaded by X with KMS enabled, (CONFIG_DRM_RADEON_KMS=n but modprobe.d/ contains "options radeon modeset=1") but X fails to start with:

(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
[dri] This chipset requires a kernel module version of 1.17.0,
[dri] but the kernel reports a version of 2.16.0.[dri] Make sure your module is loaded prior to starting X, and
[dri] that this driver was built with support for KMS.
[dri] Aborting.

The problem is that xf86-video-ati is built with KMS and radeon.ko loads with modeset=1 but still, X fails to load due to the initialization (bug?) issue reported by the OP. Restarting X fixes the problem. I do think there is something to fix here and it would be nice to at least fix this chicken/egg issue.
Comment 7 Alex Deucher 2012-07-30 13:14:07 UTC
(In reply to comment #6)
> Userspace is not a problem here, many distributions have GL implementation
> switch tools already.
> 

Userspace is the problem.

> 
> The problem is that xf86-video-ati is built with KMS and radeon.ko loads with
> modeset=1 but still, X fails to load due to the initialization (bug?) issue
> reported by the OP. Restarting X fixes the problem. I do think there is
> something to fix here and it would be nice to at least fix this chicken/egg
> issue.

You need to have the kernel module loaded before starting X.  The same is true of other KMS drivers (intel, nouveau, etc.).  If the drm is not loaded, the ddx assumes UMS and tries to load the drm.  If it loads in KMS mode, you don't want two drivers handling the same hw, so the ddx bails to prevent that.  If you try and load the drm from X and assume that the kernel is in KMS mode, you break old systems with old kernels that don't support KMS.  The other problem with having the ddx load the drm for KMS mode is that with KMS, the drm handles all of the chip init.  With UMS when you load the drm in UMS mode, the kernel module  doesn't do anything at load time; it just waits until userspace inits the hw and actually decides to use the drm.  With KMS, we have no way of knowing when the KMS drm has finished loading or initializing the hw so we may end up trying to use the KMS drm before it's properly loaded.  It's not a configuration we want to support.