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
Created attachment 68742 [details] lspci -vxxx
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?
It's great that the kernel bugzilla is back. Can you please verify if the problem still exists in the latest upstream kernel?
The problem still exists. Last tested kernel v3.2
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?
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 &&
Rui - is it worth ccing the Intel graphics folks on this as brightness changes go via the i915 driver through ACPI ?
well, I have no idea. len, what do you think of this problem?
(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?
> 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.
(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.
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
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.
This is a problem in BIOS table, WILL_NOT_FIX.