Created attachment 23278 [details] Config file for kernel build System is Fedora 10 with the following graphics userspace: xorg-x11-server-common-1.5.3-17.fc10.i386 xorg-x11-server-Xorg-1.5.3-17.fc10.i386 xorg-x11-drv-ati-6.10.0-2.fc10.i386 mesa-dri-drivers-7.2-0.15.fc10.i386 mesa-libOSMesa-7.2-0.15.fc10.i386 mesa-libGL-7.2-0.15.fc10.i386 libdrm-2.4.0-0.21.fc10.i386 xorg.conf is configured for driver "radeon" with: Section "Device" Identifier "Videocard0" Driver "radeon" Option "AccelMethod" "EXA" Option "AGPMode" "4" Option "AGPFastWrite" "on" Option "AccelDFS" "on" EndSection Virtual 1440 1080 lspci of video chipset is: 01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200] (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Device d600 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17 Memory at d8000000 (32-bit, prefetchable) [size=128M] I/O ports at ee00 [size=256] Memory at fdef0000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at fde00000 [disabled] [size=128K] Capabilities: <access denied> Kernel modules: radeon BIOS configured for 64 MB VRAM. With distro kernels kernel-2.6.27.30-170.2.82.fc10.i686 and kernel-2.6.27.35-170.2.94.fc10.i686, and also with vanilla kernels 2.6.31 and 2.6.31.1, the graphics system works normally with DRI fully enabled. With recently-released 2.6.32-rc3, the graphical login results in a black screen and no keyboard response (but keyboard leds do not blink). I have not yet managed to capture a dmesg output or a xorg log. I will try to produce those later. Setting Option "DRI" "off" on xorg.conf makes the graphical login show up, but with no compiz or any other DRM support. To reproduce: Install Fedora 10 with latest updates Compile and install 2.6.32-rc3 Attempt to use graphical login, or otherwise start X with DRI on. Actual results: System hang with black screen and unresponsive keyboard. Expected: Either 1) DRI works normally as it did on earlier versions, or 2) DRI refuses to work with too-old userspace but allows X to start without DRI and without additional configuration. Build 2009-10-05 on Fedora 10 i386
Created attachment 23284 [details] Xorg log up to the point where kernel crashes
Created attachment 23285 [details] dmesg output after boot with graphical login and DRI=off
A ssh session that was made into the test computer went unresponsive after triggering the crash. This, in my opinion, is confirmation that the problem is kernel related, and not xorg-related.
I have checked 2.6.32-rc2 and it also hangs the machine when trying to use DRI.
What's the latest version of the kernel which did not have this bug? Thanks.
2.6.31, 2.6.31.1, and 2.6.31.3 do not have the bug. 2.6.31.3 is what I am running right now. 2.6.32.rc1/2 do have the bug. I am aware that rc1 and rc2 are actually the same tag. I posted the same question at xorg-driver-ati@lists.x.org and got the following response: ---------------------------- >>> > >> Adding Option "DRI" "off" to xorg.conf allows me to start up X, but I >>> > >> lose DRI and compiz. >>> > >> >>> > >> I would like your opinion about the following issues: >>> > >> * Should I expect DRI to continue working for radeon in a setup with a >>> > >> newer kernel and old userspace? >>> > >> * Have any of you experienced anything similar with 2.6.32-rc2 >>> onwards? >>> > >> >> > > >> > > F10 and F11 radeon kernel and userspace are not compatible with >> > > upstream. Both need to be upgraded to use the latest bits. >> > > >> > > Alex >> > > >> > > > > But, is it acceptable to make the system hang up on this > > incompatibility? I think a better response would be for the -rc3 kernel > > to refuse the queries on DRI that come from incompatible userspace, and > > then DRI would be disabled, but X would still start up. Or even that > > xserver refuses to start at all and drop to the command line, but still > > have control of the machine. Either of these would be better than a > > system lockup that forces a hard reset. Is either of these even possible > > if only the kernel is updated? > > > > No possible without introducing crap in the kernel to check userspace process which will never be accepted upstream. You should rather try Fedora12 livecd or update to rawhide we made several improvement that we are adding to fedora12. ---------------------------- But I still think that the kernel should behave in a way that will at least give me back control of the machine without a hard reset.
So you are not enabling KMS in 2.6.32 right ? Did 2.6.31-rc4 had the bug ? I can't remember any change to old radeon drm which might play a role in what you are seeing.
I disabled KMS long ago because my monitor needs a gamma setting of 2.08 and with the distro kernel KMS results in non-working gamma support (screen is too dark, xgamma does not work). In addition, KMS from around vanilla 2.6.30 onwards no longer works with my distro-supplied video drivers, but I did not mind it very much because I worked without KMS anyway. Are you sure that you mean 2.6.31-rc4 and not 2.6.32-rc4 ? 2.6.31-rc4 is older than 2.6.31, which I know for a fact that works. The change that broke my setup was introduced somewhere between 2.6.31 and 2.6.32-rc1. But I can try 2.6.31-rc4 anyway if you think it will demonstrate something.
Still present in 2.6.32-rc5.
On Wednesday 28 October 2009, Alex Villacís Lasso wrote: > Rafael J. Wysocki escribió: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.31. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14331 > > Subject : Radeon XPRESS 200M: System hang with radeon DRI and > Fedora 10 userspace unless DRI=off > > Submitter : Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec> > > Date : 2009-10-06 00:29 (21 days old) > > > > > Sorry for answering late. This bug is still present in 2.6.32-rc5 - I > have just checked.
I too have rc-7 and last 32 stable version of the kernel rendering a system freeze just before the gdm login screen shows up. Moreover, KMS seems to be extremely dangerous for our card right now (X200M rc410). The earlier versions of the kernel 31-14 and up are all giving system hangs sooner or later with the radeon.modeset=1 option enabled. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/489447 It might be a different issue and I will report this here as a separate bug. There is no way I can provide the logs: they are either missing or garbled by the crashes.
On ubuntu karmic 9.10 the last kernel image called drm-next has also this bug. Booting Linux version 2.6.32-996-generic (root@zinc) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #200912071003 SMP Mon Dec 7 10:56:26 UTC 2009 with the radeon.modeset=1 does the same thing.
On Tuesday 29 December 2009, Alex Villacís Lasso wrote: > El 29/12/09 10:28, Rafael J. Wysocki escribió: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.31 and 2.6.32. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.31 and 2.6.32. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14331 > > Subject : Radeon XPRESS 200M: System hang with radeon DRI and > Fedora 10 userspace unless DRI=off > > Submitter : Alex Villacis Lasso<avillaci@ceibo.fiec.espol.edu.ec> > > Date : 2009-10-06 00:29 (85 days old) > > > > > > > > > I will not be able to test this regression anymore. I recently switched > to Fedora 12 on the target machine, and of course the userspace works > with the distro kernel.