Bug 41042 - Changing the backlight brightness may freeze the laptop
Changing the backlight brightness may freeze the laptop
Status: CLOSED WILL_NOT_FIX
Product: ACPI
Classification: Unclassified
Component: Power-Video
All Linux
: P1 normal
Assigned To: Aaron Lu
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-12 20:27 UTC by Jose Alonso
Modified: 2013-03-20 03:19 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.2
Tree: Mainline
Regression: No


Attachments
acpidump (185.47 KB, application/octet-stream)
2011-08-12 20:27 UTC, Jose Alonso
Details
lspci -vxxx (28.06 KB, application/octet-stream)
2011-08-12 20:28 UTC, Jose Alonso
Details

Description Jose Alonso 2011-08-12 20:27:38 UTC
Created attachment 68732 [details]
acpidump

Sometimes when pressing the keys to adjust screen brightness, the laptop freezes.

The script below reproduces the freeze:

for (( i=1 ; i <= 100 ; i++))
do
    echo 3 >/sys/class/backlight/acpi_video0/brightness
done

The screen shows the last image, no disk/net/keyboard activity, and the
processor cooler increases the air flow indicating a heavy usage of CPU (interrupt ??, spinlock ??)

I tested with kernel version 3.0.0, 2.6.38 and fedora 15 kernels.

laptop: Dell Inspiron, i5, intel graphics

follow acpidump and lspci -vxxx
Comment 1 Jose Alonso 2011-08-12 20:28:56 UTC
Created attachment 68742 [details]
lspci -vxxx
Comment 2 Jose Alonso 2011-08-14 16:35:46 UTC
To debug this, I boot the kernel in single mode, using one cpu and outputing
the kernel messages to console. I set the acpi parameters debug_level and
debug_layer and put some printk.
The machine freezes showing the last message: "start outb(0x79, 0xb2)"

--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -638,7 +638,12 @@ EXPORT_SYMBOL(acpi_os_read_port);
 acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
 {
        if (width <= 8) {
-               outb(value, port);
+               if (port == (acpi_io_address)0xb2 && value == 0x79) {
+                       printk("start outb(0x79, 0xb2)\n");
+                       outb(value, port);
+                       printk("end outb(0x79, 0xb2)\n");
+               } else
+                       outb(value, port);
        } else if (width <= 16) {
                outw(value, port);
        } else if (width <= 32) {

-----------------
This corresponds in file DSDT.dsl to:
...
    OperationRegion (GNVS, SystemMemory, 0xBB622E18, 0x0172)
    Field (GNVS, AnyAcc, Lock, Preserve)
    {
        ...
        BRTL,   8,                      <---------
...
    OperationRegion (EXBU, SystemMemory, 0xBB62F018, 0x1011)
    Field (EXBU, AnyAcc, Lock, Preserve)
    {
        ...
        SMIB,   8,                       <----------
...
    Scope (_SB.PCI0.GFX0)
...
        Device (DD02)
...
           Method (_BCM, 1, NotSerialized)  <-------(1)
            {
                SX10 ()
                SX30 (0x19)
                SX30 (One)
                SX30 (Arg0)
                Store (Arg0, BRTL)
                SX11 ()                  <---------(2)
                SX12 ()
            }
...
    Scope (_SB)
    {
        OperationRegion (SMIR, SystemIO, 0xB2, 0x02)
        Field (SMIR, ByteAcc, NoLock, Preserve)
        {
            SMII,   8,                   <-------------
...
    Method (SX11, 0, NotSerialized)
    {
        If (LEqual (NSMI, Zero))
        {
            SXX4 ()
            Store (SXX6 (0x79, Zero), SXX3)   <-------(3)
...
    Method (SXX6, 2, NotSerialized)
    {
        Store (Arg1, SMIB)
        Store (Arg0, \_SB.SMII)               <--------(4)(here)
        Return (SMIB)
    }

----------------------------
Sequence to change brightness:
    brightness -> BRTL
    0 -> SMIB
    outb(0x7b, 0xb2)   (value,port)
    SMIB -> return value not used
    0x19 -> SMIB
    outb(0x7c, 0xb2)
    SMIB -> return value not used
    1 -> SMIB
    outb(0x7c, 0xb2)
    SMIB -> return value not used
    brightness -> SMIB
    outb(0x7c, 0xb2)
    SMIB -> return value not used
    0 -> SMIB
    outb(0x79, 0xb2)                           <---------(here)
    SMIB -> return value = 0 (no return arguments)
-------------------------------

Seems that the CPU cannot use the PCI/IO bus ?!?

I suspect it is a timing problem or
some interference with bus usage.
I don't know if its a Dell hardware specific or
intel chipset.
Any clue?
Comment 3 Zhang Rui 2012-01-18 05:32:54 UTC
It's great that the kernel bugzilla is back.

Can you please verify if the problem still exists in the latest upstream
kernel?
Comment 4 Jose Alonso 2012-01-21 16:14:51 UTC
The problem still exists.
Last tested kernel v3.2
Comment 5 Jose Alonso 2012-01-25 14:17:42 UTC
I have some questions:

1) Are there any documentation describing the protocol used in
   the section "Sequence to change brightness" in Comment #2 ?
   Is it Dell specific? Chipset?
2) What is the "hardware" implementing the acpi?
   Is it a microcontroller with firmware?
   Are there any documentation?
   Is it Dell specific? Chipset?
Comment 6 Jose Alonso 2012-01-25 21:13:28 UTC
More info:

The system log shows:

ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS tables! (20110623/tbfadt-369)
ACPI Warning: 32/64X FACS address mismatch in FADT - 0xBB62CF40/0x00000000BB62CF80, using 32 (20110623/tbfadt-489)

Forcing the usage of 64 bit version with the patch below doesn't help!

--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -484,11 +484,10 @@ static void acpi_tb_validate_fadt(void)
            (acpi_gbl_FADT.Xfacs != (u64) acpi_gbl_FADT.facs)) {
                ACPI_WARNING((AE_INFO,
                              "32/64X FACS address mismatch in FADT - "
-                             "0x%8.8X/0x%8.8X%8.8X, using 32",
+                             "0x%8.8X/0x%8.8X%8.8X, using 64",
                              acpi_gbl_FADT.facs,
                              ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xfacs)));
 
-               acpi_gbl_FADT.Xfacs = (u64) acpi_gbl_FADT.facs;
        }
 
        if (acpi_gbl_FADT.dsdt &&
Comment 7 Alan 2012-08-30 10:29:31 UTC
Rui - is it worth ccing the Intel graphics folks on this as brightness changes go via the i915 driver through ACPI ?
Comment 8 Zhang Rui 2012-11-13 08:44:38 UTC
well, I have no idea.
len, what do you think of this problem?
Comment 9 Aaron Lu 2013-03-15 07:50:56 UTC
(In reply to comment #5)
> I have some questions:
> 
> 1) Are there any documentation describing the protocol used in
>    the section "Sequence to change brightness" in Comment #2 ?

Perhaps yes, but we can't get it...

>    Is it Dell specific? Chipset?

Code in DSDT table are generally provided by chipset vendor, but this is not a sure thing.

> 2) What is the "hardware" implementing the acpi?
>    Is it a microcontroller with firmware?
>    Are there any documentation?

The only public documentation is the ACPI spec, where you can see descriptions for _BCM, _BQC, etc. I believe you have already read them and know what they are supposed to do. Well regarding what the asl code in _BCM and _BQC does, it is totally a mystery to me. And if it doesn't work, we can probably only say, this BIOS table is broken.

>    Is it Dell specific? Chipset?

PS, do you have any problem during your normal use?
Comment 10 Jose Alonso 2013-03-18 17:26:11 UTC
> PS, do you have any problem during your normal use?

During normal use, the system freezes one time per week, because I am
using "Display Power Management". The system freezes when the display
is off and I move the mouse to turn it on.
Comment 11 Aaron Lu 2013-03-19 03:16:42 UTC
(In reply to comment #10)
> > PS, do you have any problem during your normal use?
> 
> During normal use, the system freezes one time per week, because I am
> using "Display Power Management". The system freezes when the display
> is off and I move the mouse to turn it on.

Possible to get the dmesg after it freezes(netconsole may be helpful here)?

And it sounds like an i915 driver problem - I suppose DPM functionalities are handled by i915, but I'm not sure. If you can attach the dmesg here, we can take a look to see what happened; if not possible, I think you can file a bug against Drivers/DRI-intel on this: "The system freezes when the display
is off and I move the mouse to turn it on". Perhaps they have an idea about what happened.
Comment 12 Jose Alonso 2013-03-20 02:55:19 UTC
Using the intel driver for changing backlight solves the problem !!!

There are 3 drivers on my laptop to change the backlight:
1) default driver: ACPI Video
   /sys/class/backlight/acpi_video0
2) vendor driver: dell_laptop (kernel parameter: acpi_backlight=vendor)
   /sys/class/backlight/dell_backlight
3) intel driver - /sys/class/backlight/intel_backlight

The drivers 1 and 2 freeze the laptop. (probably: hardware or BIOS table is broken)

To use the intel driver, add the Option "Backlight" to xorg.
/etc/X11/xorg.conf.d/00-intel.conf:
Section "Device"
        Option     "AccelMethod"        "uxa"
        Option     "Backlight"          "intel_backlight"
        Identifier "Card0"
        Driver     "intel"
        BusID      "PCI:0:2:0"
EndSection

for more information about another broken acpi see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651741#64
Comment 13 Aaron Lu 2013-03-20 03:18:04 UTC
Thanks for reporting back.

I'll close it, and I think INVALID may be better than CODE_FIX, since the problem probably lies in broken BIOS table and acpi video driver still has problem with it, and I don't see a way to fix it.
Comment 14 Aaron Lu 2013-03-20 03:19:26 UTC
This is a problem in BIOS table, WILL_NOT_FIX.

Note You need to log in before you can comment on or make changes to this bug.