stumped - xorg edgers + 2.6.35-rc1 DRI fail

[icek]

How well does the pm work now?

Well, with this kernel and ati 3200 hd my notebook freezed after enabling dynpm mode...

[pingufunkybeat]

sudo echo dynpm > /sys/class/drm/card0/device/power_method

You should put everything after 'sudo' in double quotes: ""

[Hans]

How well does the pm work now?

[Wielkie G]

With this command, you just sudo-ed 'echo'. The redirect ('> /sys/...') is still done by shell (bash), which is not sudo-ed. I found once really interesting alternative, using tee:

echo dynpm | sudo tee /sys/class/drm/card0/device/power_method

The only side-effect is that "dynpm" string will be emitted to stdout too.

[hmmm]

cheers, it worked - although i'm getting some intermittent flickering now.

Any idea why i had do go into sudo -i as opposed to having to running the command with just:

sudo echo dynpm > /sys/class/drm/card0/device/power_method

[Kano]

try

sudo -i

and THEN your commands

[hmmm]

I keep getting Permission denied whenever I try to enable dynpm:

echo dynpm > /sys/class/drm/card0/device/power_method

Same thing happens when trying to:

echo low > /sys/class/drm/card0/device/power_profile

[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.

[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.

[nanonyme]

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