Bug 4588 - AE_TIME - Battery not recognized at bootup - PCG-FR215E
Summary: AE_TIME - Battery not recognized at bootup - PCG-FR215E
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Battery (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Luming Yu
: 3750 5236 (view as bug list)
Depends on:
Reported: 2005-05-06 09:23 UTC by Brice MEALIER
Modified: 2006-02-02 14:32 UTC (History)
2 users (show)

See Also:
Kernel Version:
Tree: Mainline
Regression: ---

linux-2.6.13/drivers/acpi/events/evgpe.c (21.83 KB, text/plain)
2005-09-14 01:57 UTC, Luming Yu
dmesg output (15.12 KB, text/plain)
2005-09-15 11:25 UTC, Brice MEALIER
.config (48.04 KB, application/octet-stream)
2005-09-17 10:52 UTC, Brice MEALIER
dmesg output no preempt (15.13 KB, text/plain)
2005-09-18 02:13 UTC, Brice MEALIER
diable preempt when holding a semaphore in AML code. (666 bytes, patch)
2005-09-18 08:10 UTC, Luming Yu
Details | Diff
correct return value (469 bytes, patch)
2005-12-30 22:38 UTC, Luming Yu
Details | Diff

Description Brice MEALIER 2005-05-06 09:23:49 UTC
Distribution: Debian Sarge
Hardware Environment: Sony PCG-FR215E
Software Environment: kernel + lastest acpi patch!!
Problem Description:

The battery is randomly recognized at boot time! This is already a long-standing
bug (from 2.6.8 on)

brice@TuxBox:~$ dmesg|grep ACPI
 BIOS-e820: 000000001fef0000 - 000000001fefc000 (ACPI data)
 BIOS-e820: 000000001fefc000 - 000000001ff00000 (ACPI NVS)
ACPI: RSDP (v000 PTLTD                                 ) @ 0x000f6890
ACPI: RSDT (v001 SONY   K5       0x06040000  LTP 0x00000000) @ 0x1fef7647
ACPI: FADT (v001 SONY   K5       0x06040000 PTL_ 0x000f4240) @ 0x1fefbdff
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x06040000  LTP 0x00000001) @ 0x1fefbe73
ACPI: SSDT (v001 PTLTD  POWERNOW 0x06040000  LTP 0x00000001) @ 0x1fefbe9b
ACPI: DSDT (v001  SONY  X0       0x06040000 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x8008
ACPI: setting ELCR to 0200 (from 0a00)
ACPI: Subsystem revision 20050408
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKB] (IRQs *9 10 11 12)
ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs *9 10 11 12)
ACPI: Embedded Controller [EC0] (gpe 1)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PPB_._PRT]
pnp: PnP ACPI init
pnp: PnP ACPI: found 10 devices
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
ACPI wakeup devices: 
ACPI: (supports S0 S3 S4 S5)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.1[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 16 throttling states)
ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 9
ACPI: PCI Interrupt 0000:00:0e.1[B] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:0e.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ
ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ
ACPI: PCI Interrupt 0000:00:10.1[B] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ
ACPI: PCI Interrupt 0000:00:10.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9
ACPI: PCI Interrupt 0000:00:10.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ
ACPI: Battery Slot [BAT1] (battery absent)
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SBTN]
ACPI: Power Button (CM) [PBTN]
ACPI: Lid Switch [LID]
ACPI: Thermal Zone [THRM] (62 C)
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ

Regards, Brice
Comment 1 Len Brown 2005-08-03 19:20:59 UTC
likely this is an EC issue that Luming is looking at -- assigning it to him.
Comment 2 Brice MEALIER 2005-08-04 00:21:57 UTC
The last 2 acpi patches (20050708 and 20050729) solved this issue! The battery
gets now recognized!

Best regards, Brice
Comment 3 Brice MEALIER 2005-08-30 13:19:59 UTC
The bug is back under 2.6.13 and the patch acpi-20050815. Sniff I'm feeling 
depressed, I thought this bug was closed definitively.
Comment 4 Len Brown 2005-09-08 01:36:16 UTC
please try the latest ACPI patch on top of 2.6.13 --
currently acpi-20050902.  Pelease try it with
ec_burst=0 (default) and with ec_burst=1.
Comment 5 Brice MEALIER 2005-09-08 02:14:15 UTC
how do I pass these options?

Using grub?

The default do not recognize the battery every time.

Best regards, Brice
Comment 6 Luming Yu 2005-09-08 02:21:51 UTC
This is an example from my box: 
kernel (hd0,5)/boot/vmlinuz root=/dev/hda6 ec_burst=1 vga=normal splash=silent 
desktop showopts 
Comment 7 Brice MEALIER 2005-09-09 05:38:04 UTC
no changes either using ec_burst=1 or ec_burst=0: the battery is always 
randomly recognized.

Regards, Brice
Comment 8 Luming Yu 2005-09-12 22:44:34 UTC
Please post acpidump output. 
Comment 9 Brice MEALIER 2005-09-12 23:53:08 UTC
please see bug #3750 I reported in which I attached the acpidmp output.

let me know if you need further information.

Best regards, Brice
Comment 10 Luming Yu 2005-09-13 01:46:27 UTC
From _BST, _Q20 will update battery status object, if ec gpe got lost, 
then battery status could be randomly wrong or right. 
Pleas try this debug patch which is against 2.6.13: 
--- linux-2.6.13/drivers/acpi/events/evgpec.0   2005-09-13 16:40:59.716902448 
+++ linux-2.6.13/drivers/acpi/events/evgpe.c    2005-09-13 16:42:19.197819512 
@@ -262,6 +262,7 @@ 
        ACPI_FUNCTION_TRACE ("ev_disable_gpe"); 
+#if 0 
        if (!(gpe_event_info->flags & ACPI_GPE_ENABLE_MASK)) { 
                return_ACPI_STATUS (AE_OK); 
@@ -297,6 +298,7 @@ 
                return_ACPI_STATUS (AE_BAD_PARAMETER); 
        return_ACPI_STATUS (AE_OK); 
Comment 11 Brice MEALIER 2005-09-13 02:29:31 UTC
Comment 12 Luming Yu 2005-09-13 02:37:19 UTC
just try vanilla-2.6.13 without any patch.
Comment 13 Brice MEALIER 2005-09-13 10:15:25 UTC
applying the patch against vanilla 2.6.13 failed:

[brice@TuxBox:linux-2.6.13]$ patch -p1<../acpi.2.6.13.patch 
patching file drivers/acpi/events/evgpe.c
Hunk #1 succeeded at 262 with fuzz 2.
Hunk #2 FAILED at 298.
1 out of 2 hunks FAILED -- saving rejects to file drivers/acpi/events/evgpe.c.rej

Comment 14 Luming Yu 2005-09-14 01:57:24 UTC
Created attachment 6007 [details]

Please try to replace your evgpe.c with the attached one.
Comment 15 Brice MEALIER 2005-09-14 10:21:39 UTC

it doesn't work!
It recompiled a kernel, rebooted but the battery was not recognized...

Best regards, Brice
Comment 16 Brice MEALIER 2005-09-14 10:21:54 UTC

it doesn't work!
It recompiled a kernel, rebooted but the battery was not recognized...

Best regards, Brice
Comment 17 Luming Yu 2005-09-14 17:48:42 UTC
Please build kernel with acpi debug option enabled. 
And post the dmesg. 
Comment 18 Brice MEALIER 2005-09-15 11:25:08 UTC
Created attachment 6032 [details]
dmesg output

Here it is!
dmesg output from a vanilla 2.6.13 (note it has been compiled with

Best regards, Brice
Comment 19 Luming Yu 2005-09-17 10:40:14 UTC
Please post you .config.
If you enabled other preemption model, please try CONFIG_PREEMPT_NONE.

Comment 20 Brice MEALIER 2005-09-17 10:52:54 UTC
Created attachment 6051 [details]

Here it is!

Comment 21 Luming Yu 2005-09-17 19:51:43 UTC
I found this in .config

# CONFIG_SMP is not set

Please config non-preempt kernel.
Comment 22 Brice MEALIER 2005-09-18 02:13:43 UTC
Created attachment 6054 [details]
dmesg output no preempt

It seems to do the trick.

I compiled the kernel with:

# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set

But I have to say I am not really happy to disable the preemption as I am doing
a lot of audio with my box and then need low-latency...

Please tell me when I can re-enable the low-latency!

Best regards, Brice
Comment 23 Luming Yu 2005-09-18 08:10:17 UTC
Created attachment 6055 [details]
diable preempt when holding a semaphore in AML code.

Please test if this patch works with preempt kernel.
Comment 24 Luming Yu 2005-09-20 19:28:29 UTC
I got this mail that confirms the patch works. :

------- Additional Comments From bricem13@yahoo.com  2005-09-19 10:25 -------
Created an attachment (id=6065)
 --> (http://bugzilla.kernel.org/attachment.cgi?id=6065&action=view)
dmesg output with patch preempt


it's fine please tell me when this will be included in the acpi patch as I
generally keep my kernel up-to-date!

Best regards, Brice
Comment 25 Luming Yu 2005-09-25 05:04:50 UTC
*** Bug 5236 has been marked as a duplicate of this bug. ***
Comment 26 Luming Yu 2005-10-23 00:06:47 UTC
*** Bug 3750 has been marked as a duplicate of this bug. ***
Comment 27 Brice MEALIER 2005-11-20 01:25:11 UTC

This bug is still present in

Best regards, Brice
Comment 28 Luming Yu 2005-12-04 03:18:57 UTC
Please try the filed patch. 
The bug should be marked as resolved for Len to push it into base kernel
Comment 29 Brice MEALIER 2005-12-04 04:40:12 UTC
The given patch worked with 2.6.13  as I told it. I filled again against this
bug because it is still in 2.6.14.

Regards, Brice
Comment 30 Luming Yu 2005-12-28 00:59:30 UTC
why the patch is necessary?

The scenario:

\_SB.PCI0.PIB.EC0.MUT0 is acquired by foo (driver executing AML code )

And the execution of foo gets preempted by the thread bar which start the
execution of _Q20. if _Q20 acquire mutext \_SB.PCI0.PIB.EC0.MUT0 with wait value
of 0xffff (forever), then the execution of bar can be finished without any
error. But the key problem is _Q20 acquire mutex MUT0 with wait value of 0x1388
. Then bar could timeout for semaphore MUT0, if foo cannot release MUT0 after
0x1388 milliseconds (5sec), (impossible?),  or bar could not resume execution in
0x1388 milliseconds (5sec) (impossible?), or somthing else ?

Comment 31 Luming Yu 2005-12-30 22:38:00 UTC
Created attachment 6906 [details]
correct return value

Please give it a try without patch of disalbing preempt.
Comment 32 Len Brown 2006-01-03 13:09:51 UTC
patch in comment #31 applied to acpi-test tree.
Brice, can you confirm it helps your machine?
Comment 33 Brice MEALIER 2006-01-18 10:09:53 UTC
please see bug 5051

Regards, Brice
Comment 34 Len Brown 2006-02-02 14:32:51 UTC
Shipped in 2.6.16-rc1-git6 -- closing.

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