brightness adjusting crashes system

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1007765/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Hello
please reproduce the bug and reboot with Alt+Sysrq+r e i s u b (reisub one letter at time). It works?
If yes, please attach here, using the button below 'Add attachment or patch' the files:
/var/log/xorg.0.log.old
/var/log/kern.log
Thnaks
Fabio
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Hello Fabio.
I tried to reboot with the magic key combination, but nothing happens when the system freezes with color flickering.

What else can i do?

---
The bug is very annoying cause my laptop has a very bright screen and i have to dim it every time.
Sometimes I can't get to the lower brightness state for 3-6 reboots in row.

Hello Karlis
Good, this mean that the problem is in the kernel.
So Reproduce again the bug, restart the pc and attach the required log files.
Thanks
Fabio
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Done that above, run in terminal
apport-collect 1007765

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649346
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

confirmed from screencast
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.4kernel[1] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-rc1-quantal/

I'm having the same problem the video is showing.

Has the kernel-update being refered to in #32 already landed? If not, will this happen automatically or do I really have to manually install it? I'm asking because I'm not sure if I'm technically skilled enough to start messing with kernels. Then again, this bug makes my laptop virtually unusable (every time you accidentaly hit one of the brightness-keys it crashes and I have to reboot).

In case I do have to install the kernel manually, I just have to install the two debs from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/, the headers and the image and then I just reboot?

If I run the Ubuntu 12.10 (Quantal Quetzal) daily live image from USB, brightness fuctions normally again, so it would seem the kernel currently used in 12.10 has fixed this issue. Any way to get it fixed in 12.04 too?

try with the precise kernels installing -all.deb, image and header for your architecture and pae if ram<2Gb nad let us know
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Alright, I installed the -all, image-amd64 and headers-amd64 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/ (if I understand correctly, 3.4 the latest stable release of the kernel for precise).

Unfortunately it did not work. The 3.4 kernel was succesfully installed (I guess, since Grub detected it, and I could boot the 3.4 option in Grub, and uname -a reported version 3.4), but Unity 3D didn't start, so Ubuntu fell back to Unity 2D and adjusting the brightness settings still crashed the system (though the screen animation was now slightly different then from the video). Also, all drivers installed using Jockey were disabled and refused to reinstall (including AMD/ATI graphics drivers). Strangely, when I originally installed Ubuntu, Unity 3D worked out of the box with the opensource drivers, but now it fell back to Unity 2D.

Luckely, I could still select the 3.2 kernel in Grub and there Unity 3D still worked fine (except the brightess-crash-problem still occured). I uninstalled the 3.4 kernel files and ran update-grub2 (since that was recommended).

I retested the Ubuntu 12.10 daily live version today, and unfortunately the bug does still exist in kernel 3.5. I'm not sure if I tested it wrong the first time (it seems to matter how fast you try to increase or decrease the brightness) or if this is a regression. The screen doesn't show the behaviour in the video any more though (the weird colors), now it just hangs. Switching to CLI (CTR-ALT-F1) is not possible.

From Elco's response it looks as though this issue is not fixed in the mainline build. Therefore, changing to confirmed and tagging kernel-bug-exists-upstream as Joseph said.

Tested kernels 3.4 and 3.5-rc3 and both of them had the same bug.

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report at bugzilla.kernel.org [1]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[1] https://wiki.ubuntu.com/Bugs/Upstream/kernel

SPARX's solution seems to have worked for me as well (comment #71).

$uname -a
Linux Inspiron-N5010 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:41:11 UTC 2013 i686 i686 i686 GNU/Linux

Thanks for the work around!

Adding 'acpi_backlight=vendor' to the GRUB_CMDLINE_LINUX_DEFAULT options in /etc/default/grub (comment #71) also worked for me. 'quiet splash' and 'pcie_aspm=force' options shouldn't be necessary in this situation (though 'quiet splash' is added by default). Also, as a general rule, you should check what commands do before blindly following solutions followed by others. Google is your friend. ; )

$ uname -a
Linux Mazinger-Z 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:47:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ sudo lshw -class system
mazinger-z
    description: Portable Computer
    product: Inspiron N5010 (To be filled by O.E.M.)
    vendor: Dell Inc.
    version: A04
    serial: 1D04FL1
    width: 64 bits
    capabilities: smbios-2.6 dmi-2.6 vsyscall32
    configuration: boot=normal chassis=portable sku=To be filled by O.E.M. uuid=44454C4C-4400-1030-8034-B1C04F464C31

As with others that have an ATI graphics card, the solution in #71 does NOT work for me either I'm afraid. Can't wait for some sort of aolution to this; it's a real pain! Occasionally it even seems to hit when my computers monitor turns off/on after being left..

uname -a:
Linux james-laptop 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:15:40 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

lspci (gfx card only) :
VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Manhattan [Mobility Radeon HD 5400 Series]

Hi,

I think adding 'acpi_backlight=vendor' to grub cmd option fix problem for only Intel graphics cards, for other GPU this bug is still present.

This is very serious one. As this affects linux usability and stability.

Regards,
Savio

I am still having this problem even after adding 'acpi_backlight=vendor' to grub cmd option, but now crash occurs less often.
This problem also occurs when brightness changes due to power on/off. In this case(when frozen) if I remove or plug-in charger, brightness level changes but nothing else work.
Sometime I notice that Brightness Indicator doesn't display brightness level correctly.

Ubuntu 13.04 (64-bit), ATI Mobility Radeon HD 5400 series

Unfortunately the issue is back on Xubuntu 13.04, Dell Inspiron 5010, Intel Graphics.

Temporarily try this brightness adjuster:
http://www.omgubuntu.co.uk/2013/04/brightness-control-ubuntu

Why is this bug still in "Unassigned state"...?

I still have this problem with 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
 with intel graphics HD4000.

When I first boot, changing brightness is fine. But after a period of time, it will hang if I adjust the brightness.

Similarly, when I first boot I can logout and power down my laptop without issues, but after a time, if I attempt to log out or shutdown it hangs. I suspect these hangs are both related.

Adding 'acpi_backlight=vendor' to the kernel parameters didn't make much of a difference for me.

I have Dell inspiron with Intel core I3 and Intel HD graphics with ubuntu. 13.04 .
I tried setting acpi_backlight=vendor but no help
but setting acpi = off works but no touchpad support

setting brightness manually in /sys/class/backlight/dell_ brightness/ current* to 1 works and also changing this setting multiple times works great

please help.

On Sat, Jun 22, 2013 at 11:07:27PM -0000, Savio wrote:
> I have Dell inspiron with Intel core I3 and Intel HD graphics with ubuntu. 13.04 .
> I tried setting acpi_backlight=vendor but no help
> but setting acpi = off works but no touchpad support
>
> setting brightness manually in /sys/class/backlight/dell_ brightness/
> current* to 1 works and also changing this setting multiple times works
> great

This is actually a kernel bug (actually a firmware bug specific to your
machine) that is supposed to be fixed upstream by now (by just disabling the
interface for the firmware backlight driver). I think the fix will be
available starting from 3.10.

For more info, see https://bugzilla.kernel.org/show_bug.cgi?id=57571

On Sat, Jun 22, 2013 at 11:07:27PM -0000, Savio wrote:
> I have Dell inspiron with Intel core I3 and Intel HD graphics with ubuntu. 13.04 .
> I tried setting acpi_backlight=vendor but no help
> but setting acpi = off works but no touchpad support

You can eliminate this problem for now, by putting this line in your
/etc/rc.local:

echo 0 >/proc/sys/kernel/nmi_watchdog

Thats help, but adding this line in /etc/rc.local before exit 0 statement making brigthness hotkey unusable.
I need to change from setting.

will adding this
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "sna"
Option "Backlight" "intel_backlight"
Identifier "Card0"
Driver "intel"
BusID "PCI:0:2:0"
EndSection

in xorg.conf help me?
Should i remove boot option acpi_backlight=vendor

Thanks for your help.

On Sun, Jun 23, 2013 at 04:59:03AM -0000, Savio wrote:
> Thats help, but adding this line in /etc/rc.local before exit 0 statement making brigthness hotkey unusable.

This couldn't be caused by disabling nmi_watchdog; this is totally unrelated.

My guess is that you've booted the system with acpi_backlight=vendor which
disabled the ACPI backlight interface (/sys/class/backlight/acpi_video0), and
enabled the interface for the vendor backlight driver (e.g.,
/sys/class/backlight/dell_backlight) which won't be picked up by X, because
it's not hard-coded to use it. So, you ended up with no backlight interface for
X to use. That's why the hotkeys seem to be not working.

Try booting the kernel without acpi_backlight=vendor, while disabling
nmi_watchdog from /etc/rc.local as before, and let's see what would happen.

> will adding this

> Section "Device"
> Identifier "Intel Graphics"
> Driver "intel"
> Option "AccelMethod" "sna"
> Option "Backlight" "intel_backlight"
> Identifier "Card0"
> Driver "intel"
> BusID "PCI:0:2:0"
> EndSection

Yes, I think this would help, but I haven't tried it before.

For those of you using Inspiron:
Marwan's solution worked for me.
I'm using 'GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_aspm=force acpi=off"' in my /etc/default/grub file.
and I've added 'echo 0 >/proc/sys/kernel/nmi_watchdog' to my /etc/rc.local file.
(Thanks, man!)

I am using debian wheezy... Cannot find a better discussion on this "Brightness Bug" in the whole world.... awesome effort here..

I have Dell Inspiron N5010 , Core i3, 4 GB RAM AND INTEL HD

After updating to 3.2.xx the system starts hanging when the brightness was adjusted. I googled and found that it was a kernel bug. So i leaned how to compile my own kernel.

NOW I HAVE 3.10.5 Kenel BUT TO MY SURPRISE THIS BUG WAS STILL DER..... :`-(

But then more googling got me to this thread and MARWANS SOLUTION (NO. 71) WORKING FOR ME... NOWWW

root@debian:/home/anoop# uname -a
Linux debian 3.10.5-anoop-bfs-firstcompile #1 SMP PREEMPT Wed Aug 7 00:05:38 IST 2013 x86_64 GNU/Linux

This is an update to my post No.93... Not a single time i have have faced any problem with the brigtness button :
after SPARX No.17 comment ( sorry for saying that it was Marwans)

This bug is FIXED for me by adding these kernel options:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_aspm=force acpi_backlight=vendor"

May be the community is looking for the solution in the wrong direction.
Looking in /sys/class/backlight/ lists 3 folders on my Dell inspiron 7520.
One of the folders is intel_backlight .

Manually doing
root@Sirius:~# echo 2000 > /sys/class/backlight/intel_backlight/brightness
works.

This means that the problem is somewhere in the X configuration.

From a thread here https://bugs.freedesktop.org/show_bug.cgi?id=29273
I created an entry in xorg.conf

Section "Device"
        Option "Backlight" "intel_backlight"
        Identifier "Card0"
        Driver "intel"
        BusID "PCI:0:2:0"
EndSection

I created this by using X -c
and copying only relevant section to /etc/X11/xorg.conf

The controls are working fine now. I *do not* have acpi_backlight=vendor .
I just have acpi_osi=Linux , and I am not very sure if it is needed at all.

On Thu, Aug 22, 2013 at 06:10:50PM -0000, Aditya wrote:
> May be the community is looking for the solution in the wrong direction.

Well, I will elaborate on this bug once and for all.

First of all, we can't blame the Linux kernel for this bug, because it is
firmware-specific.

"firmware-specific" means that the peace of software (i.e., the backlight
driver) causing this bug is written by the affected systems manufacturers
(Dell, HP, etc.), and burned into the BIOS ROM chips of those systems. This
software is closed-source, so there is no way to fix it, other than via
firmware updates provided by the manufacturers.

The freeze happens at the time of the interaction between the Linux kernel and
the backlight driver provided by the firmware. Basically, It happens as
follows:

 - The user adjust the brightness using the keyboard hot keys, or a
   software application (e.g., gnome-control-center).

  - In the first case, The X window system provides a prioritized
    list of backlight drivers interfaces (exported by the Linux
    kernel under /sys/class/backlight/) that are used for
    handling the keyboard key presses. The highest priority
    interface, which are present on the system, is used.

  - In the second case, the software application just selects the
    interface to use for adjusting the brightness from the
    currently available interfaces under /sys/class/backlight/

 - Depending on the driver underlying the interface selected at the
   previous step, the system may or may not enter SMM (System Management
   Mode) to adjust the brightness. SMM is an operational mode which the
   system enters when it wants to run critical firmware (e.g., the peace
   of software responsible for shutting down the system when the
   processor temperature hit a critical threshold, or in our case, the
   peace of software responsible for adjusting the brightness level,
   etc). When the system is executing software in SMM, it is no longer
   under the control of the Linux kernel, and is fully controlled by the
   firmware executed.

   The video0_acpi and the dell_backlight (or whatever it's called on
   systems other than Dell) interfaces under /sys/class/backlight/, are
   interfaces, exported by the Linux kernel, for firmware drivers that
   execute in SMM. So if they are selected in the previous step, the
   system is going to enter SMM for adjusting the brightness. On the
   other hand, the intel_backlight interface on systems with Intel
   Graphics is just an interface for the Linux kernel driver responsible
   for adjusting the backlight level of the intel graphics chip. It is
   executed just like any other driver in the Linux kernel, without the
   need to enter special modes like SMM. So, if this driver is buggy, we
   can say that the Linux kernel is buggy, because it is considered part
   of the kernel. So, we have two cases:

  1. The driver underlying the interface selected (by the X
     window system or the software application used for adjusting
     the brightness) is firmware. In this case, when adjusting the
     brightness, the Linux kernel just instructs the processor to
     enter SMM...

Thanks Marwan for the detailed description of the bug.
I just posted this as a fix for the users who were unable to change brightness, and I had no idea how deep the roots of this bug are.

In my case, both acpi_video0 and acpi_video1 do not work, i.e. the brightness does not change and the system is functional.
When I use acpi_backlight=vendor things are different even if I disable nmi_watchdog .

Are there any tests that I run?

On Fri, Aug 23, 2013 at 09:05:34AM -0000, Aditya wrote:
> Thanks Marwan for the detailed description of the bug.

You're welcome.

> I just posted this as a fix for the users who were unable to change brightness, and I had no idea how deep the roots of this bug are.

And, I don't blame you. I just took it as an oppurtunity for explaining the
root cause of the problem in order to reduce the amount of trial-and-error for
poeple experiencing the same problem.

> In my case, both acpi_video0 and acpi_video1 do not work, i.e. the brightness does not change and the system is functional.
> When I use acpi_backlight=vendor things are different even if I disable nmi_watchdog .

But this thread is about the problem of the freeze that happens on some systems
when adjusting the brightness, not about the issue of the brightness controls
not working, while the system is functional. Disabling nmi_watchdog just makes
us avoid this freeze. You are talking about a different issue here. Maybe you
need to open a new bug report for this problem.

Hi,
by different I mean that the system freezes in both the situations, with nmi_watchdog enabled and disabled, and this happens as soon as I soon as I change the brightness levels, and this is the reason I actually reached this bug report.

Thanks,

On Fri, Aug 23, 2013 at 04:09:46PM -0000, Aditya wrote:
> Hi,
> by different I mean that the system freezes in both the situations, with nmi_watchdog enabled and disabled, and this happens as soon as I soon as I change the brightness levels, and this is the reason I actually reached this bug report.

Then, let's do some testing.

Could you please do the following:

 - Boot the system with acpi_backlight=vendor

 - sudo echo 0 >/proc/sys/kernel/nmi_watchdog

 - cat /proc/sys/kernel/nmi_watchdog (make sure the output is 0)

 - Try changing the brightness using the keyboard keys, and see whether
   a freeze would happens or not.

Note that if you just put echo 0 >/proc/sys/kernel/nmi_watchdog in
/etc/rc.local, then you are going to need to reboot the system in order for the
script to be executed.

If a freeze still happens, then my guess is that there is another source of
NMIs on your system other than nmi_watchdog that still conflicts with the
vendor firmware backlight driver.

Marwan, your workaround did in fact fix the problem for me.

I'll add that when I tried your workaround (echo 0 >/proc/sys/kernel/nmi_watchdog), I REMOVED acpi_backlight=vendor (which I already had) at the same time. I rebooted and both problems were fixed: I could change the backlight using my keyboard AND changing the backlight no longer caused the computer to freeze. I haven't tried putting acpi_backlight=vendor back in my grub configuration to see if that breaks anything.

Hi,

> On Fri, Aug 23, 2013 at 04:09:46PM -0000, Aditya wrote:
>> Hi,
>> by different I mean that the system freezes in both the situations, with nmi_watchdog enabled and disabled, and this happens as soon as I soon as I change the brightness levels, and this is the reason I actually reached this bug report.
> Then, let's do some testing.
>
> Could you please do the following:
>
> - Boot the system with acpi_backlight=vendor
>
> - sudo echo 0 >/proc/sys/kernel/nmi_watchdog
>
> - cat /proc/sys/kernel/nmi_watchdog (make sure the output is 0)
I did this, as a result, the system is responsive for 10 - 15 seconds
after brightness change.
I am able to change brightness multiple times within this window. After
this the system freezes.

I never had this bug until yesterday. "acpi_backlight=vendor" and/or the "echo 0 >/proc/sys/kernel/nmi_watchdog" solution didn't work for me. I couldn't install the latest mainline kernel, because of my restricted broadcom WiFi driver I'm depending on.

Workaround for me was: Disable Virtualization Features of my Intel Core i7 in BIOS.
I think I can live without virtualization features for some time. But in future I want to use VirtualBox, where these features are necessary.

System: Thinkpad S531
Linux: Xubuntu 13.04
Kernel: 3.8.0-31

Adding "acpi_backlight=legacy" fixed it for me under Ubuntu 13.10. (Dell N5010, IntelHD)

 'gksu gedit /etc/default/grub'

 add "acpi_backlight=legacy" to GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" line so it'll look like this:

   GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=legacy"

save and run "sudo update-grub"

Restart.

Still no luck for me on Dell N5010, running Kubuntu 13.10:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=legacy"

didn't work...

I fresh installed Ubuntu 13.10, so it was using free drivers by default. And it crashed when I tried to change brightness rapidly. So I think the bug is not present in fglrx-installer. Now I am using AMD drivers, but my brightness control doesn't work properly, it either increases or decreases after pressing the key many times, the progress bar in indicator is displayed correctly but brightness changes randomly.
After echo 0 >/proc/sys/kernel/nmi_watchdog, crash doesn't occur.

I have Dell Integrated Graphics Card and don't understand what echo 0 >/proc/sys/kernel/nmi_watchdog does.
I'm really fed up with this bug.

I've read comment #96 and now I know what echo 0 >/proc/sys/kernel/nmi_watchdog does.
Still, it didn't work for me.

Hello to you all!
I am showing up here because I have the same issue. I found this thread this morning after blaming the hardware on my notebook for a year but rethinking this to be a software issue this morning. I will try out the solutions here to contribute on this this evening.

Please, how are the actual informations on pinning down this issue to a subsystem?

What I want to contribute at first is technical stuff. I have exactly the same issue on this constellation (all tried out in 2013):

Dell Studio 1558 with BIOS A04 and A12, HD4500 ATI
debian or archlinux installed
several installed linux-3.1n.x versions
several recent fglrx catalyst legacy drivers
several recent open source radeon drivers

Yes, no ubuntu launchpad issue at all!

Yes, all the same crash but the pattern on screen after crash is different: fglrx is flashing a couple of chars in the pattern, radeon displays a mor simple pattern with no flashing chars.

Kind Regards
Konsti

I've managed to get this bug solved!

The answer is here: http://ubuntuforums.org/showthread.php?t=2181534&p=12819813#post12819813

Create the file /usr/share/X11/xorg.conf.d/20-intel.conf with the following content:

    Section "Device"
            Identifier "card0"
            Driver "intel"
            Option "Backlight" "intel_backlight"
            BusID "PCI:0:2:0"

    EndSection

Log out to see if it works.

Unfortunately, the solution that worked for George does not work on my Lenovo ThinkPad W530, running Ubuntu 13.10.
After trying to adjust brightness, I see the brightness graphic on the screen, and the system freezes immediately.
This laptop has NVidia - Intel hybrid graphics, so the bug is likely not related to fglrx

I'm not able to disable the virtualization options in BIOS, since those are necessary for running VirtualBox. That is necessary for the work I do, in the job where this laptop is used.

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

Hey, is there any chance this is going to be resolved soon? My system (Ubuntu Studio 10.04) basically renders itself more and more useless everyday and I can't upgrade because of this bug. I tried

- Ubuntu 12.04
- Linux Mint 13 and Linux Mint 15 (both Cinnamon)
- Fedora 20
- Ubuntu Studio 12.04
- Debian 7

and this bug persists in every single one of them. I can't do anything but look how my system slowly perishes. Please somebody fix this bug so I can have a running system again. If there is anything I can do to help, please let me know.

one workaround i been using for quite sometime now, is to decrease the backlight before the kernel boots.

i.e. the system waits on grub bootloader for 5-10 seconds for any distribution i used. dimming the display then bypasses this issue... :)

I believe I have successfully solved the bug now by reading all the comments again and found a solution in #96. I added

echo 0 >/proc/sys/kernel/nmi_watchdog

before "exit 0" in the file etc/rc.local. I have used the system a few hours/days/re-starts/hibernates since and no bug has occured by now. My working configuration is:

- Ubuntu Studio 12.04 fresh install
- Dell Studio 1558 with ATI Radeon HD 4500.
- Gnome Shell
- Solution from comment #96

The problem persists in 14.04. The solution in comment #96 still does not resolve the issue for me.

I can confirm Rahul's observation in #116. Adjusting the brightness before the kernel loads works. Adjusting after that freezes the system.

This is happening on my Lenovo T510 which uses Nvidia so I don't think the video driver has anything to do with it. This bug (for me) is also the worst kind in that it's intermittent. Tonight, the system locked up when I forgot about this problem and it hosed a partition that was in the middle of being resized.