← Back to team overview

kernel-packages team mailing list archive

Re: [Bug 1007765] Re: brightness adjusting crashes system

 

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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1007765

Title:
  brightness adjusting crashes system

Status in “fglrx-installer” package in Ubuntu:
  Confirmed
Status in “linux” package in Ubuntu:
  Incomplete

Bug description:
  When adjusting my laptops brightness the system crashes.

  what logs do in need to add and how to get them?

  System:
  -- Dell Studio 1558
  -- Ubuntu 12.04

  Video showing the process: http://www.youtube.com/watch?v=Vxp_rWXHnrg
  --- 
  .tmp.unity.support.test.0:
   
  ApportVersion: 2.0.1-0ubuntu8
  Architecture: amd64
  CompizPlugins: [core,composite,opengl,neg,commands,put]
  CompositorRunning: None
  DistUpgraded: 2012-01-26 12:27:33,165 DEBUG enabling apt cron job
  DistroCodename: precise
  DistroRelease: Ubuntu 12.04
  DistroVariant: ubuntu
  DkmsStatus:
   bcmwl, 5.100.82.38+bdcom, 3.2.0-23-generic, x86_64: installed
   bcmwl, 5.100.82.38+bdcom, 3.2.0-24-generic, x86_64: installed
   fglrx, 8.960, 3.2.0-20-generic, x86_64: installed
   fglrx, 8.960, 3.2.0-23-generic, x86_64: installed
   fglrx, 8.960, 3.2.0-24-generic, x86_64: installed
  ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
  GraphicsCard:
   Advanced Micro Devices [AMD] nee ATI RV710 [Mobility Radeon HD 4500/5100 Series] [1002:9553] (prog-if 00 [VGA controller])
     Subsystem: Dell Device [1028:0413]
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
  JockeyStatus:
   xorg:fglrx_updates - ATI/AMD proprietary FGLRX graphics driver (post-release updates) (Proprietary, Disabled, Not in use)
   kmod:wl - Broadcom STA wireless driver (Proprietary, Enabled, In use) [auto-install]
   xorg:fglrx - ATI/AMD proprietary FGLRX graphics driver (Proprietary, Enabled, In use)
  MachineType: Dell Inc. Studio 1558
  NonfreeKernelModules: fglrx wl
  Package: xorg 1:7.6+12ubuntu1
  PackageArchitecture: amd64
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-24-generic root=UUID=cd6ba6ea-6e63-41cc-b872-c101873444c6 ro quiet splash
  ProcVersionSignature: Ubuntu 3.2.0-24.39-generic 3.2.16
  Tags:  precise ubuntu
  Uname: Linux 3.2.0-24-generic x86_64
  UpgradeStatus: Upgraded to precise on 2012-01-26 (129 days ago)
  UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
  dmi.bios.date: 09/13/2010
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A10
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A10
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: A10
  dmi.modalias: dmi:bvnDellInc.:bvrA10:bd09/13/2010:svnDellInc.:pnStudio1558:pvrA10:rvnDellInc.:rn:rvrA10:cvnDellInc.:ct8:cvrA10:
  dmi.product.name: Studio 1558
  dmi.product.version: A10
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz 1:0.9.7.8-0ubuntu1
  version.fglrx-installer: fglrx-installer N/A
  version.ia32-libs: ia32-libs 20090808ubuntu36
  version.libdrm2: libdrm2 2.4.32-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu3
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu3
  version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu10.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1007765/+subscriptions


References