Some time (10-20 minutes on average) after booting the laptop the system stops seeing the battery and ac_adapter info in /proc/acpi/{battery,ac_adapter}. This is a regression -- in gentoo-sources-2.6.27-r1 everything worked great. For example, with fully charged battery and power chord connected: looptop ~ # cat /proc/acpi/battery/BAT1/state present: no looptop ~ # cat /proc/acpi/ac_adapter/ADP1/state state: off-line I had this problem some time ago and even complained upstream: http://www.spinics.net/lists/linux-acpi/msg14208.html http://bugzilla.kernel.org/show_bug.cgi?id=10855. However, when I upgraded the kernel to (vanilla) 2.6.26-rc6, the problem misteriously went away. I'm attaching the dmesg logs from (working) 2.6.27-rc1 and (non-working) 2.6.27-rc4.
Created attachment 173056 [details] dmesg from -r1 (i.e. working)
Created attachment 173057 [details] dmesg from -r4 (i.e. non-working)
Following is a diff chunk from the attached dmesg outputs that seems to mess the things up. @@ -152,13 +153,11 @@ PCI: MCFG area at e0000000 reserved in ACPI motherboard resources PCI: Using MMCONFIG at e0000000 - efffffff ACPI: EC: non-query interrupt received, switching to interrupt mode -ACPI: EC: GPE storm detected, disabling EC GPE -ACPI: EC: missing confirmations, switch off interrupt mode. ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62 -ACPI: EC: driver started in poll mode +ACPI: EC: driver started in interrupt mode ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: 0000:00:02.0 reg 10 64bit mmio: [fda00000, fdafffff] -PCI: 0000:00:02.0 reg 18 32bit mmio: [d0000000, dfffffff] +PCI: 0000:00:02.0 reg 18 64bit mmio: [d0000000, dfffffff] PCI: 0000:00:02.0 reg 20 io port: [b480, b487] PCI: 0000:00:02.1 reg 10 64bit mmio: [fdb00000, fdbfffff] PCI: 0000:00:1a.0 reg 20 io port: [b800, b81f]
The exact patch that causes the ACPI to start in interrupt mode is 1004_linux-2.6.27.5.patch.
Updated to git-sources-2.6.28_rc5-r4. ACPI starts in interrupt mode, but the battery seems fine. So basically, if we are not interested in solving this bug, we can just wait for the problem to go away when 2.6.28 is out.
Similar to http://bugzilla.kernel.org/show_bug.cgi?id=12004 (which was supposedly fixed in 2.6.27.7) Is the attachment in comment #2 from before or after the battery problem appeared during that session? (you said it takes 10-20 minutes) In 2.6.27-r4, can you edit drivers/acpi/ec.c change this line: /* #define DEBUG */ to: #define DEBUG and enable CONFIG_PRINTK_TIME in your config, recompile/reboot, and attach dmesg output from after the error occurs Also, please attach dmesg from 2.6.28
(In reply to comment #6) > Similar to http://bugzilla.kernel.org/show_bug.cgi?id=12004 (which was > supposedly fixed in 2.6.27.7) > > Is the attachment in comment #2 from before or after the battery problem > appeared during that session? (you said it takes 10-20 minutes) > It is from before the problem appears. When the problem occurs, nothing new is added to dmesg. > In 2.6.27-r4, can you edit drivers/acpi/ec.c > change this line: > /* #define DEBUG */ > to: > #define DEBUG > > and enable CONFIG_PRINTK_TIME in your config, recompile/reboot, and attach > dmesg output from after the error occurs > I will report back. > Also, please attach dmesg from 2.6.28 > In 2.6.28 the problem also occurs, but much less frequently.
OK, in that case it would be best to see the dmesg from 2.6.28-rcX rather than 2.6.27.
to clarify: I mean dmesg while DEBUG is turned on, and both immediately after boot, *and* after the bug has appeared
Created attachment 173675 [details] dmesg right after boot
Created attachment 173676 [details] dmesg right after battery dissapeared
Created attachment 173702 [details, diff] Don't do transaction from GPE handler in poll mode. Please try this patch and tell us if it fixed the problem.
(In reply to comment #12) > Created an attachment (id=173702) [edit] > Don't do transaction from GPE handler in poll mode. > > Please try this patch and tell us if it fixed the problem. > Sergey, Do you mean, to revert this patch? Because my ec.c already has it applied, both in gentoo-sources-2.6.27-r4 and git-sources-2.6.28_rc5-r4.
There is an upstream bug that looks very similar to your issue: http://bugzilla.kernel.org/show_bug.cgi?id=11892 There is a patch in the acpi tree: http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=06cf7d3c7af902939cd1754abcafb2464060cba8 that supposedly fixes that issue, and is already included in 2.6.27-gentoo-r4 There is one other fix queued in the ACPI tree that fixes a regression introduced with the patch Sergey mentions: http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=7b4d469228a92a00e412675817cedd60133de38a If you feel inclined it would be good to test with that patch.
Created attachment 174161 [details, diff] possible Yes, please ignore the previous patch (you're right - it is already included) and apply this one to 2.6.27-r4. Does it help?
Instead of the above patch, please just upgrade to gentoo-sources-2.6.27-r5
(In reply to comment #16) > Instead of the above patch, please just upgrade to gentoo-sources-2.6.27-r5 > Daniel, I just synced, and -r5 is not in the tree yet. Instead, I downloaded genpatches-2.6.27-7 from the genpatches home page, and applied them. The issue is still here.
Alright, please file this bug upstream at http://bugzilla.kernel.org and post the new bug URL here when done. Please be sure to make clear: - this is a regression introduced in 2.6.27.5 (2.6.27.4 worked OK) - it also exists in 2.6.28, but is harder to reproduce - please also duplicate comments #1, #2 and #3 on the upstream bug (working dmesg, non-working dmesg, and the differences you highlight) Thanks!
(In reply to comment #18) > Alright, please file this bug upstream at http://bugzilla.kernel.org and post > the new bug URL here when done. http://bugzilla.kernel.org/show_bug.cgi?id=12187 > > Please be sure to make clear: > - this is a regression introduced in 2.6.27.5 (2.6.27.4 worked OK) > - it also exists in 2.6.28, but is harder to reproduce > - please also duplicate comments #1, #2 and #3 on the upstream bug (working > dmesg, non-working dmesg, and the differences you highlight) The differences are not important, because in 2.6.28-rc5 with DEBUG uncommented, the driver starts in poll mode, and the problem still happens. See http://bugzilla.kernel.org/show_bug.cgi?id=12187#c3
