You are viewing bgoglin

Brice Goglin's Blog - Debian/X.org notes - Radeon KMS in unstable, enabled by default

Mar. 22nd, 2010

11:37 - Debian/X.org notes - Radeon KMS in unstable, enabled by default

Previous Entry Add to Memories Share Next Entry

Now that we have DRM from 2.6.33 in latest 2.6.32 kernel in unstable, I just uploaded Radeon KMS and DRI2 to unstable. xserver-xorg-video-radeon 1:6.12.192-2 even enables KMS by default. Please test it.

In case of problems, you may for instance disable KMS by changing modeset to 0 in /etc/modprobe.d/radeon-kms.conf. You may also downgrade to testing where xserver-xorg-video-radeon 1:6.12.6-1 does not enable/support KMS.

Make sure you run linux-image-2.6.32-4-$arch or later so that you actually have DRM from 2.6.33 and the radeon kernel module gets loaded early by udev. Otherwise, you may experience problems like this. You may need to add radeon to /etc/modules as a temporary fix.

(Permanent link

Comments:

From:(Anonymous)
Date:March 22nd, 2010 11:35 (UTC)

drmCheckModesettingSupported broken

(Link)
I think you may get
(II) [KMS] drm report modesetting isn't supported.
even if radeon with kms is loaded; my "drm" directory is in /sys/bus/pci/devices/0000:00:01.0/0000:01:00.0/, but drmCheckModesettingSupported searches in /sys/bus/pci/devices/0000:00:01.0/ (using upstream 2.6.33)
lspci:
01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650
From:(Anonymous)
Date:July 1st, 2010 05:40 (UTC)

Re: drmCheckModesettingSupported broken

(Link)
I was seeing this same error message, but I didn't have the "drm" directory anywhere. It turns out I had the "radeonfb" module compiled into my kernel, which conflicts with the radeon drm module (which offers its own framebuffer device). Disabling radeonfb fixed my problem.

--Matthijs
From:(Anonymous)
Date:March 22nd, 2010 17:19 (UTC)

Older kernels

(Link)
As with Intel KMS, it seems unfortunate that the X driver enables KMS via an /etc/modprobe.d file, and this takes effect for all kernels, not just those new enough to properly do KMS. Long-term, other situations like this will probably arise. Any thoughts on how future transitions like these should happen?
From:(Anonymous)
Date:March 23rd, 2010 10:48 (UTC)

No problems so far

(Link)
On squeeze you additionally need libuuid-perl and linux-base from unstable.
All looks fine here.

$ dmesg | grep -i radeon:
http://pastebin.com/nHdP5iTB

$ dmesg | grep -i drm
http://pastebin.com/ajZWV5Qq

$ cat /var/log/Xorg.0.log | egrep "KMS|DRI"
http://pastebin.com/BbiueMVx



From:(Anonymous)
Date:March 23rd, 2010 10:51 (UTC)

the kernel should upgrade automatically

(Link)
OK, unstable should only be used by experienced users, but still it is unpleasant that the drivers get automatically upgraded with aptitude full-upgrade, but the kernel isn't. Therefore the system is unusable after a reboot. With 2.6.32-4 installed the system and KMS are working perfectly.

Thx, Matthias
From:(Anonymous)
Date:March 23rd, 2010 13:45 (UTC)

external monitor corruption

(Link)
I'd be happy to report a bug about this, but with these x/kernel issues I can never tell where to do it.

My issue is that my external monitor is corrupted with kms (both in console and X) so I presume it is an issue with the kernel. Basically, across the entire screen, it looks wavy. The issue can be mitigated by reducing the screen resolution in X, but it still is basically impossible to use.
From:(Anonymous)
Date:March 23rd, 2010 14:09 (UTC)

Still troubles with AGP

(Link)
Hi,

here is some feedback:

with linux-image-2.6.32-3-686 I had to force PCI mode (agpmode=-1) to make the radeon driver work.

I just upgraded to 2.6.32-4-686 and sadly the problem is still present.

Also, I am loading radeon early during boot.
From:(Anonymous)
Date:March 23rd, 2010 17:24 (UTC)

gdm starting with "wrong" resolution

(Link)
I'm using linux-image-2.6.32-4-$arch like suggested.

Everything seems to work, but when I start gdm it starts with the "wrong" resolution. Without kms it was starting with 1400x1050 and now it's starting with 1024x768. I can change it later inside my desktop(using Xfce), in display configuration. It seems default dpi is being detected differently too.

Oh, and I noticed that 3D games(openGL) are a bit slower.

Hope the feedback helps, and thank you for your work.

From:(Anonymous)
Date:March 24th, 2010 03:09 (UTC)

DRI not working

(Link)
$ uname -r
2.6.32-4-amd64

$ lspci |grep VGA
03:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]

$ cat /var/log/Xorg.0.log | egrep "KMS|DRI"
(II) Loading extension XFree86-DRI
(II) Loading extension DRI2
(II) [KMS] drm report modesetting isn't supported.
(EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
[dri] Disabling DRI.
(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable
(II) GLX: Initialized DRISWRAST GL provider for screen 0
____________

radeon was added to /etc/modules but still didn't work.


/dros
From:bgoglin
Date:March 24th, 2010 06:11 (UTC)

Re: DRI not working

(Link)
Missing some firmware maybe ? Look in dmesg and try installing firmware-linux.
From:(Anonymous)
Date:March 24th, 2010 22:28 (UTC)

Re: DRI not working

(Link)
firmware-linux was installed and I did not found anything relevant in dmesg.

I've set radeon modeset=0 in /etc/modprobe.d/radeon-kms.conf for now.

If you need some more info or testing I'll be glad to help.


/dros
From:(Anonymous)
Date:March 25th, 2010 00:04 (UTC)

Re: DRI not working

(Link)
Please provide dmesg output.
From:(Anonymous)
Date:March 25th, 2010 01:32 (UTC)

Re: DRI not working

(Link)
I overlooked something in dmesg before. I had a fglrx module being loaded (although not being used).
Removing it solved the problem.

Sorry for the confusion and thank you for leading me to the solution.



/dros
From:brian_252
Date:April 3rd, 2010 03:06 (UTC)

Re: DRI not working

(Link)
This morning i did an aptitude upgrade and X/gdm would not start. Well, gdm would start, i could hear the beep prompt for input, but i saw nothing. I could not switch to a virtual terminal. I did a bit of research and thought i should update the firmware. Added non-free to apt sources. Upgraded to firmware-linux-nonfree 0.23 and it worked. Not sure exactly when this happened, but i also needed to add radeon to /etc/modules.

Unfortunately, i still have the Blender bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529322
From:(Anonymous)
Date:April 6th, 2010 07:49 (UTC)

Powermanagement

(Link)
Hey Brice,

since you backported DRM, are there any plans to do the same with the powermangement patches for radeons introduced to - I guess - 2.6.34?
This would make the basic radeon support almost complete.

Lukas
From:(Anonymous)
Date:April 9th, 2010 10:01 (UTC)

Radeon KMS on a Thinkpad T41

(Link)
My experience so far on a Thinkpad T41 running mostly testing:

I had video=radeonfb:force_sleep in the linux command line to fix the infamous "high-power drain in ACPI sleep" problem. After upgrading to the latest 2.6.32 and xserver-xorg-video-radeon from unstable, upon resume the screen would stay black with a couple of console log messages (e.g. hub 3-0:1.0: over-current change on port 1). I had to press Alt-F7 to show the X display.

I removed the video=radeonfb:force_sleep from the command line.
* Startup is a little ugly: blinking and a colored line at the bottom of the screen
* Upon resume, the screen shows a couple of console messages:
[ 843.175568] pm_op(): pci_pm_resume+0x0/0x76 returns -16
[ 843.175571] PM: Device 0000:00:00.0 failed to resume: error -16
Then the X display is shown automatically (no need to press Alt-F7).
* I don't know if removing the video=radeonfb:force_sleep option will affect battery drain while sleeping, but I suspect it may. Even a few months ago this option was necessary on my computer.
From:(Anonymous)
Date:June 25th, 2010 17:57 (UTC)

Re: Radeon KMS on a Thinkpad T41

(Link)
(Following up on my own post)
With kernel 2.6.32 and without the video=radeonfb:force_sleep option, my Thinkpad did exhibit the "high-power drain in ACPI sleep problem" again. Upgrading to kernel 2.6.34 from experimental solved that problem.

Sleeping with Fn-F4 still causes random patterns on the screen to be displayed.