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 :-)
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to fglrx-installer in Ubuntu.
https://bugs.launchpad.net/bugs/1007765
Title:
brightness adjusting crashes system
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1007765/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help : https://help.launchpad.net/ListHelp
