Radeon XPRESS 200M (RC410) - system lockup on DRI with 2.6.32-rc3 and Fedora 10 userspace

[Alex Villací­s Lasso]

Alex Deucher escribió:
> On Wed, Oct 7, 2009 at 11:18 AM, Alex Villací­s Lasso
> <a_villacis at palosanto.com> wrote:
>   
>> http://bugzilla.kernel.org/show_bug.cgi?id=14331
>>
>> I am testing kernel releases on a machine with the following radeon
>> chipset as reported by lspci -v:
>>
>> 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: [50] Power Management version 2
>>    Capabilities: [80] Message Signalled Interrupts: Mask- 64bit-
>> Count=1/1 Enable-
>>    Kernel modules: radeon
>>
>> On all of these tests, I use the Fedora 10 distro with kernel
>> modesetting disabled and with the latest updates:
>>
>> 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
>>
>> I know these versions do not follow the latest developments from xorg,
>> but up to vanilla kernel 2.6.31.1, I had somewhat decent DRI and Compiz
>> support. So I expected that the changes to radeon kernel support would
>> continue to work with the old userspace. However, with 2.6.32-rc3 (and
>> now 2.6.32-rc2), I get a system lockup with a black screen and an
>> unresponsive keyboard when X starts up. The keyboard leds do not blink,
>> so this makes me think that the kernel is caught in a loop instead of
>> having a kernel panic. Opened ssh sessions into the machine also become
>> unresponsive. When checking the xorg logs, the log stops at the line
>> "drmOpenDevice: node name is /dev/dri/card0".
>>
>> 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?


-- 
perl -e '$x=2.3;printf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'