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 in order to execute the instructions of this driver, and when finished, it takes control back on the system. 2. The driver underlying the interface selected, is the Linux kernel driver for the graphics chip. In this case, when adjusting the brightness, this driver, provided by the Linux kernel, is responsible for doing the job, while the system is fully controlled by the Linux kernel, and without the need for entering any special modes like SMM for executing opaque firmware. In case 1, we have a problem, because the kernel has another driver, exported via /proc/sys/kernel/nmi_watchdog, that uses a hardware timer to periodically issue signals called NMIs (Non-Maskable Interrupts) every second or two. If an NMI is emitted while the system is operating in SMM, the buggy firmware executing in SMM causes the system to freeze. In case 2, we are fine, because there is no buggy firmware involved. The apci_backlight=vendor solution is not reliable, because all it does is to instruct the Linux kernel to not export the acpi_video0 interface, which is the interface for the BIOS ACPI backlight driver that is executed from SMM. But, it also instructs the kernel to export the interface for the vendor driver, which is also firmware and is executed from SMM. So, depending on the priority of those two drivers in the X window system configurations (having higher/lower priority than a kernel-supplied driver like intel_backlight), or the ad-hoc way , by which, a backlight-adjusting application selects the interface to use, the interface for the vendor driver (executing in SMM) may be the one that is selected after booting with the acpi_backlight=vendor kernel parameter. That's why using this kernel parameter sometimes doesn't work; we just replaced one buggy firmware driver executing in SMM with another buggy firmware driver executing in SMM. CONCLUSION: The only reliable way of avoiding this bug on systems with buggy firmware is by putting this line in /etc/rc.local echo 0 >/proc/sys/kernel/nmi_watchdog When executed, this command will instruct the kernel to stop emitting NMIs periodically, and therefore, we can avoid the conflict resulting when the X window system or backlight-adjusting software applications selects an interface exported by the Linux kernel for a firmware driver that has to be executed from SMM. > 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. You are using the wrong way for testing this bug. You have to do quick successive adjustments to reproduce the bug. Try using a script like the fluctuate_backlight.sh shell script provided in the attachments of the bug report at https://bugzilla.kernel.org/show_bug.cgi?id=57571 for reproducing the bug via the sysfs interfaces. I wrote it and used it a lot for testing, while following up to this bug report. It always works right with intel_backlight, though, so it won't make a difference in this case, because, as mentioned above, intel_backlight is an interface for a driver that isn't executed from SMM... However, I was able to use it to reproduce the bug with all other interfaces for drivers executing from SMM (e.g., acpi_video0, and dell_backlight, on Dell systems). Oh, forgot to mention that there is another more reliable way for avoiding this bug: buy a new laptop, and don't forget to try it out in the store before finishing the deal :-)