stumped - xorg edgers + 2.6.35-rc1 DRI fail

[hmmm]

Hi all,

On 10.4 with the latest xorg edgers updates (+ libdrm epoch bump fix) and latest ubuntu mainline (2.6.35-rc1) on my rv635 (Tosh_IEC_Potomac_M86_DDR2 M86 GDDR2_16Mx16 128bit 256MB 600e/500m); I seem to be booting into swrast mode. 2.6.34 mainline does not exhibit this problem, checking out the xorg.0.log shows:

[ 26.161] (II) AIGLX: Screen 0 is not DRI2 capable
[ 26.161] (II) AIGLX: Screen 0 is not DRI capable
[ 26.255] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so

Has something broken DRI recently? (Firmware is definitely there)

[nanonyme]

Put dmesg output on boot and X.org log into pastebin or whatever and link to this?

[Vii7]

You just went to far with the "testing part" - that's all.

[Melcar]

Same here.

[hmmm]

Put dmesg output on boot and X.org log into pastebin or whatever and link to this?

xorg.0.log - http://pastebin.org/305908
dmesg - http://pastebin.org/305912

[agd5f]

xorg.0.log - http://pastebin.org/305908
dmesg - http://pastebin.org/305912

radeon drm module isn't loaded.

[hmmm]

cheers; working now - passing radeon.dynpm=1 at boot was stopping it from loading.

[nanonyme]

That's interesting. Maybe the radeon module should be made to rather ignore unknown options?

[HokTar]

I have the same issue with drm-next and 2.6.35-rc1. If radeon.dynpm=1 is set the drm fails to load, bacause of "unknown option dynpm".
I guess even if dynpm is on by default it still should not happen.

2.6.34 works fine.

[agd5f]

The option was removed in 2.6.35 as the dynpm can now be dynamically set via sysfs. It's a general property of kernel modules to fail if an invalid option is provided; not something specific to radeon.