Comment 113 for bug 1007765

Dear George, I am quite sure, this does not fix the problem. I investigated this in deep now, let me elaborate on this. At first I forgot to mention, my system is entirely a 64bit one, may be this is importand. Secondly, I have only one AMD/ATI HD4500 card build into my notebook as a graphincs card. This is no intel, radeon or fglrx issue. But may be forcing intel interface reveals some stuff intel fixed in their code path.

I got fluctuate_bl.sh to test this out from here:
https://bugzilla.kernel.org/show_bug.cgi?id=57571

This script penetrates the /sys/class/backlight/acpi_backlight0/brightness interface with a interval which may be configured. It can be called penetrating another interface. My Kernel offers acpi_backlight0 (values 0..15) and radeon_bl0 (values 0..255).

When I penetrate the acpi_backlight0 the system freezes almost immediately, penetrating radeon_bl0 lasts a bit longer to make the system freeze. What I learned is, adding a delay for example of 0.2s looks more stable on first sight but acpi interface lasts not much longer either, pentrating radeon_bl0 lasts going out to smoke a cigarette but will crash. Again, rdaeon_bl0 looks a bit more robust. The delay seems to be relevant for a statistic feeling.
Changing with xorg.conf or kernel command line from acpi interface away to vendor one could look better but only on first sight!

If I do

echo 0 >/proc/sys/kernel/nmi_watchdog

Both tests are running for ages (0 delay!). SOLVED!

I tested the acpi_backlight=vendor kernel command line. acpi_backlight0 vanishes and dell backlight appears under /sys/class/backlight. Despite of the fact there is no brightness interface under this new directory I can penetrate the interface with the fluctuate_bl.sh script, but only the backlight OSD appeears (running kde here) but the brightness does not change. Penetrating the still existing radeon_bl0 interface yields to the well known crash.

Kind Regars
Konsti