Most recent kernel where this bug did not occur: 2.6.22 Distribution: Fedora 8 Hardware Environment: Compaq HP nx6110 Software Environment: xserver 1.4.1 and drv-video-intel Problem Description: On kernel 2.6.23 I had a problem with backlight, lid button doesn't work ! If I boot computer and close lid (to plug other devices like mouse and network), after a little while when I open lid, I can't get screen anymore , I have to reboot my laptop to have screen. On suspend after resume, I have to go to console and return to X go get screen maybe I will open other bug to ACPI I found a few bugs reports that could be related . https://bugs.freedesktop.org/show_bug.cgi?id=13709 https://bugzilla.redhat.com/show_bug.cgi?id=423931 https://bugzilla.redhat.com/show_bug.cgi?id=389541 https://bugzilla.redhat.com/show_bug.cgi?id=351661
Created attachment 14197 [details] dmesg
Created attachment 14198 [details] dmidecode
Created attachment 14199 [details] acpidump generated by pmtools-20071116
ah! and maybe the most visible bug , when close lid , backlight doesn't work. but after an suspend to disk and resume, when close lid backlight works. I like to remember from kernel-2.6.20 to kernel-2.6.22, hibernation was broken, http://bugzilla.kernel.org/show_bug.cgi?id=8592
if you boot the system with acpi=off, and you close and then open the lid, does the backlight work then? it isn't clear from your description exactly what was working in 2.6.22 that isn't working in 2.6.23. Or has this always been an issue?
(In reply to comment #5) > it isn't clear from your description exactly what was working in 2.6.22 > that isn't working in 2.6.23. backlight, is that clear ? > Or has this always been an issue? no , just in 2.6.23. The other associates issues has hibernate and suspend, which worked in some kernels. For hibernation the list is 2.6.15 and 16 works, 17 and 18 no , 19 and 20 yes, 21 22 no and 23 yes suspend the list is < 23 no , 23 yes
(In reply to comment #5) > if you boot the system with acpi=off, > and you close and then open the lid, does the backlight work then? yes, backlight works normally if I boot with acpi=off on kernel 2.6.23.9.
On lid open/close actions, does /proc/interrupts show an ACPI interrupt for each action? If you kill acpid and cat /proc/acpi/event, do you see lid events on each lid action? What do you see under /proc/acpi/button/lid/C1E9/state -- does it update correctly to the new state on each lid action? BTW. > acpi_osi=!Linux This should be a NOP on this system, as the AML in comment #1 does not contain any invocations of _OSI("Linux"). If the kernel did find the AML asking _OSI("Linux"), you'd see an additional dmesg line about it.
(In reply to comment #8) > On lid open/close actions, does /proc/interrupts show > an ACPI interrupt for each action? watch -n 1 "cat /proc/interrupts" says no. ACPI interrupt don't change when press lid button. > If you kill acpid and cat /proc/acpi/event, > do you see lid events on each lid action? cat /proc/acpi/event seems about: 40 in 40 seconds show a lid message like this: video C055 00000080 00000000 button/lid C1E9 00000080 00000259 and dmesg says: video bus notify Not understanding when neither why. I just know that I don't had press the lid button in last 10 minutes and still have messages of button/lid. > What do you see under /proc/acpi/button/lid/C1E9/state -- > does it update correctly to the new state on each lid action? cat /proc/acpi/button/lid/C1E9/state state: closed Always says that is closed, when I'm pressing or not in the id button. Hope that can help
can you try 2.6.24-rc?
>> If you kill acpid and cat /proc/acpi/event, >> do you see lid events on each lid action? >cat /proc/acpi/event >seems about: 40 in 40 seconds show a lid message like this: >video C055 00000080 00000000 >button/lid C1E9 00000080 00000259 It seems that GPE 0x1D is keeping on firing. Does this exist on a working kernel? Please set CONFIG_ACPI_DEBUG and "echo 0x8800001f > /sys/module/acpi/parameters/debug_level" and "echo 0x04 > /sys/module/acpi/parameters/debug_layer" and attach the dmesg after closing and opening the lid. Please do the same test in both a working kernel and a failed kernel. >Always says that is closed, when I'm pressing or not in the id button. Method (_LID, 0, NotSerialized) { Store (0x00, Local0) If (And (\_SB.C002.C003.C099, 0x2000)) { Store (0x01, Local0) } Return (Local0) } OperationRegion (C097, SystemIO, 0x1100, 0x3C) Field (C097, AnyAcc, NoLock, Preserve) { Offset (0x0C), C098, 32, Offset (0x2C), C099, 32, Offset (0x38), C09A, 16 } Hmm, what does C099 stands for? Please attch the output of lspci -vvxxx.
>> acpi_osi=!Linux >This should be a NOP on this system, this is not true. Method C015 invokes _OSI. But anyway, this should has no impact on the current issue.
Today , I realize that lid problem just happens, after load the kernel and happens in the middle of udev service init. I mean, kernel load, and appears the message press [I] to interact with services at this time lid is working good. Starting udev ... in the middle of this starting udev service, lid stops to work and never work again. Just a lead, If I do an S4 (hibernation) , lid works again. So, I tried find out if it is a problem with udev. I am using fedora 8, which have udev-116 , I try downgrade to udev 113. But no differences. Newer udev don't seem have great differences. I try boot with kernel-2.6.22.9-91.fc7 and lid works well and with an early version of 23, lid have this problem. (In reply to comment #10) > can you try 2.6.24-rc? I had try kernel-2.6.24-0.123.rc6.fc9, have the same problem. (In reply to comment #11) > It seems that GPE 0x1D is keeping on firing. Does this exist on a working > kernel? what do you mean with working kernel ? > Please set CONFIG_ACPI_DEBUG > and "echo 0x8800001f > /sys/module/acpi/parameters/debug_level" > and "echo 0x04 > /sys/module/acpi/parameters/debug_layer" > and attach the dmesg after closing and opening the lid. > Please do the same test in both a working kernel and a failed kernel. huch ! recompile kernel, this will take some time .
Created attachment 14258 [details] lspci -vvxxx
Hi, Sergio From the log in comment #14 we can find the following: 1f.0 LPC bridge : 0xb8-0xbb >0a 40 4a 91 It seems that the bit 3:2 of 0xbb is 0x0, which means that GPIO13 won't trigger SCI interrupt(GPIO13 is related to GPE 0x1D). So after the lid is reopened, there will be some exception. At the same time the bit 7:6 of 0xb9 is 0x0, which means that the GPIO7 also can't trigger SCI interrupt(GPIO7 is related to GPE 0x17). Based on the above analysis it seems that 2.6.22 shouldn't work well. But according to the description it is regression. Will you please do the following test on the kernel of 2.6.22(work well) and 2.6.23(not working)? (Please enable the debug of ACPI in kernel configuration) a. after the system is booted, "echo 0x08080006 > /sys/module/acpi/paramters/debug_layer" and "echo 0x0c00001f > /sys/module/acpi/parameters/debug_level" b. get the output of lspci -vxxx and dmesg before closing lid c. close the lid d. get the output of lspci -vxxx and dmesg after the lid is open. Thanks.
(In reply to comment #15) > Based on the above analysis it seems that 2.6.22 shouldn't work well. But > according to the description it is regression. Strictly based on backlight is a regression, but I have some progression on hibernation. About suspend to ram on kernel 2.6.22 had working well. I don't test it many times. I wrote on #6 that just work on 23 but now I remember that also worked on 22. I hadn't test much the S3, so I don't remember exactly when worked or not. On Kernel 2.6.22 lid works well .
Created attachment 14333 [details] tones of DEBUG_ACPU messages with: echo 0x0c00001f > /sys/module/acpi/parameters/debug_level echo 0x08080006 > /sys/module/acpi/parameters/debug_layer dmesg is continually receiving messages , here is a extract.
Created attachment 14334 [details] lspci -vvxxx after hibernation The issue of lid working after hibernation, the lscpi -vvxxx is different after hibernation and lid works. All other cases lscpi -vvxxx gives always the same results. press or not press lid button and with ACPI_DEBUG or with different debug layers etc.
Hi, Sergio Thanks for the test. The log info in comment #17 is printed by cpu idle, which is not helpful. Will you please retry the test in comment #15 again? a. after the system is booted, "echo 0x08080004 > /sys/module/acpi/paramters/debug_layer" and "echo 0x0800001f > /sys/module/acpi/parameters/debug_level" b. get the output of lspci -s 0000:00:1f.0 -vxxx and dmesg before closing lid c. close the lid d. get the output of lspci -s 0000:00:1f.0 -vxxx and dmesg after the lid is open. After the test ,please attach the above output. (It is noted that two lspci and dmesg are included for every kernel). Thanks.
Created attachment 14342 [details] lspci -s 0000:00:1f.0 -vxxx before close lid a. after the system is booted, "echo 0x08080004 > /sys/module/acpi/paramters/debug_layer" and "echo 0x0800001f > /sys/module/acpi/parameters/debug_level" b. get the output of lspci -s 0000:00:1f.0 -vxxx and dmesg before closing lid
Created attachment 14343 [details] dmesg before close lid
Created attachment 14344 [details] lspci -s 0000:00:1f.0 -vxxx after close and open lid
Created attachment 14345 [details] dmesg after close and open lid
Hi, Sergio Will you please do the same test on the working kernel(2.6.22) and attach the output? Thanks.
re: comment #12 True that the DSDT invokes OSI. However, it doesn't invoke OSI(Linux), which is why acpi_osi=!Linux is a NOP on this system. Sergio, if you boot with cmdline parameter "1" to enter single user mode, does lid and backlight work then?
(In reply to comment #25) > Sergio, if you boot with cmdline parameter "1" to enter single user mode, > does lid and backlight work then? same problem no luck. (In reply to comment #24) > Hi, Sergio > Will you please do the same test on the working kernel(2.6.22) and attach the > output? > Thanks. > I will try recompile kernel 2.6.22 with ACPI_DBEUG on next weekend ok ?
Created attachment 14471 [details] dmesg after close and open lid on kernel 2.6.22 I had test kernel 2.6.22 with acpi_debug, on this weekend. The lid button was working, but something on Kernel boot make ACPI failed and /proc/acpi/buttons and acpi/battery as disappeared on kernels 22 versions, with or without ACPI_DEBUG. I had used a stocked kernel, big !?, ACPI buttons and battery never had disappeared before :(, this seems somehow related with intel-viedo drive, which I had upgrade in mean time. Ah and the day before I try used one attach one monitor and work with dual head , the fn + F4 works with 22 but not in 23 , so this silence of ACPI events is not only on lid button.
Created attachment 14527 [details] print out the notified ACPI node name instead of node address. please apply this patch and re-do the test in comment#19.
Is this a Linux/kernel regression? There is not ACPI backlight devices on your laptop from the acpidump you attached. /sys/class/backlight/ is empty, right? could you please follow comment #28 and attach the dmesg output please?
(In reply to comment #29) > Is this a Linux/kernel regression? since backlight and switch to vga (fn +f4) works in previous kernels , yes , but I had others improvements. > There is not ACPI backlight devices on your laptop from the acpidump you > attached. /sys/class/backlight/ is empty, right? yes > could you please follow comment #28 and attach the dmesg output please? I am pretty busy , I am waiting for 2.6.24 rpm package to test it, ok ? Thanks
Created attachment 14686 [details] dmesg on working kernel 2.6.22 before press lid echo 0x08080004 > /sys/module/acpi/parameters/debug_layer echo 0x0800001f > /sys/module/acpi/parameters/debug_level dmesg > dmesgkernel22beforepresslid clean of debug messages !
Created attachment 14687 [details] dmesg after close and open lid on working kernel 2.6.22 the backlight was working correctly.
Created attachment 14688 [details] lspci -vvxxx after open and close lid on working backlight kernel 2.6.22 that is the test on working kernel2.6.22. Next, I will try debug patch with kernel 2.6.24 where backlight (as 2.6.23) don't work
Created attachment 14696 [details] dmesg kernel 2.6.24 beforepresslid with debug patch after: echo 0x08080004 > /sys/module/acpi/parameters/debug_layer echo 0x0800001f > /sys/module/acpi/parameters/debug_level
Created attachment 14697 [details] dmesg kernel 2.6.24 after press lid with debug patch
Created attachment 14698 [details] lspci -vvxxx kernel 2.6.24 after press lid
hi, sergio, thanks for the information, as I'll be on vacation for Chinese New Year, I'm afraid I can't work on this during the next two weeks. Since this is a regression between 2.6.22 and 2.6.23, it would be great if you can do a git-bisect to narrow down the problem.
BTW, by a quick review of the debug message you attached, it seems to be related to the ec change. You can probably copy the driver/acpi/ec.c from 2.6.22 to 2.6.23 to see if anything changes.
(In reply to comment #37) > Since this is a regression between 2.6.22 and 2.6.23, it would be great if > you > can do a git-bisect to narrow down the problem. > yap, kernel-2.6.23-0.195.rc7.git3.fc8 , backlight works, and kernel-2.6.23-0.196.rc7.git4.fc8 don't. Now I am trying bisect patch-2.6.23-rc7-git3.bz2 to patch-2.6.23-rc7-git4.bz2 BTW: on rpm for 2.6.23.9 I found this patch which conflicts with reversion of acpi patch-2.6.23-rc7.git3-git4.bz2 # fix cpuidle regressions #ApplyPatch linux-2.6-acpi-cpuidle-0-upstream.patch #ApplyPatch linux-2.6-acpi-cpuidle-1-fix-C3-for-no-bm-ctrl.patch #ApplyPatch linux-2.6-acpi-cpuidle-2-fix-HP-nx6125-regression.patch cpuidle: fix HP nx6125 regression Fix for http://bugzilla.kernel.org/show_bug.cgi?id=9355
Created attachment 14723 [details] roll back this Reverting this patch make my backlight working again ! this patch was been commited in 2.6.23.rc7-git4 ... I apply the revert patch to 2.6.23.14 and I got backlight again.
Created attachment 14745 [details] this patch fix this bug ! Happy to announce the fix for my system lid backlight regression.
lets close all the _DOS=0/_DOS=1 bugs as a duplicate of the first one that ran into this, bug 6001 It looks like we'll need to revert the fix to 6001 -- which is effectively the patch in comment #41 here *** This bug has been marked as a duplicate of bug 6001 ***
so you have more than one laptops, right? one intel 915 and another ... could you please describe the problem you have and the problem that was fixed in 2.6.25 separately. please also attach the lspci/acpidump separately.
(In reply to comment #43) > so you have more than one laptops, right? one intel 915 and another ... no, I just have one laptop the one with Intel 915. The bug 6001 , is about one i945GM (which is not mime)
then it's weird that there is no ACPI video device for an intel 915. could you please see if there is any new bios released?
(In reply to comment #45) > then it's weird that there is no ACPI video device for an intel 915. > could you please see if there is any new bios released? > I already done that , yes, my bios lacks of some information , also /sys/class/backlight/ is empty . as you saw on comment #29
hmm, probably fixed by jesse's drm patches. anyway, as this is fixed in 2.6.25, I'll close this bug and mark it as UNREPRODUCIBLE. Please re-open it if you still have any questions.
re-open this bug as the problem still exists.
Created attachment 22405 [details] customized DSDT: set GPIO 0x0D to SCI mode if _DOS=0 please 1. apply this customized DSDT. 2. set CONFIG_ACPI_DEBUG 3. rebuild and boot with boot with acpi.debug_level=0x07 and acpi.debug_layer=0xffffffff 4. attach the dmesg output after close and open the lid for two times.
ping Sergio
Created attachment 22559 [details] 2nd acpidump generated by pmtools-20071116 hi (In reply to comment #50) > ping Sergio Now, I have 2 equal Compaq nx6110, the first is the now is a server. And the new one, which exactly the same model, is the one which I work . But in this new one, I can't upgrade BIOS because the BIOS password is blocked. I know sounds confuse , but the main problem is acpidumps aren't equal. Can you send DSDT.hex again based on this acpidump ? I will give a try ... Thanks,
Created attachment 22582 [details] customized DSDT: set GPIO 0x0D to SCI mode if _DOS=0 done. :)
Created attachment 22615 [details] dmesg with Override DSDT and acpi.debug_level=0x07 acpi.debug_layer=0xffffffff Here it is ! , Pressing lid button seems don't change nothing on dmesg! dmesg was truncated, I will send the initial boot on next reboot I hope . cat dmesg*| grep -i DSDT ACPI: DSDT 5F7EFD50, 7D58 (r1 HP DAU00 10000 MSFT 100000E) ACPI: Override [DSDT- DAU00 ], this is unsafe: tainting kernel ACPI: Table DSDT replaced by host OS ACPI: DSDT 00000000, 7744 (r1 HP DAU00 10000 INTL 20081204) ACPI: DSDT override uses original SSDTs unless "acpi_no_auto_ssdt" ACPI: EC: Look up EC in DSDT I don't understand, if I should put acpi_no_auto_ssdt on boot options or not ?
Created attachment 22630 [details] complete dmesg with Override DSDT and acpi.debug_level=0x07 acpi.debug_layer=0xffffffff 1M, need boot with log_buf_len=2M
please try the patch at http://patchwork.kernel.org/patch/38246/ and see if it helps.
(In reply to comment #55) > please try the patch at http://patchwork.kernel.org/patch/38246/ and see if > it > helps. Unfortunately don't help .
Created attachment 24112 [details] custom DSDT please try this DSDT and see if it helps.
please re-open it if you can try the custom DSDT attached in comment #57.