Bug 4588

Summary: AE_TIME - Battery not recognized at bootup - PCG-FR215E
Product: ACPI Reporter: Brice MEALIER (bricem13)
Component: Power-BatteryAssignee: Luming Yu (luming.yu)
Status: CLOSED CODE_FIX    
Severity: normal CC: acpi-bugzilla, scottsommerville
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.8.11 Subsystem:
Regression: --- Bisected commit-id:
Attachments: linux-2.6.13/drivers/acpi/events/evgpe.c
dmesg output
.config
dmesg output no preempt
diable preempt when holding a semaphore in AML code.
correct return value

Description Brice MEALIER 2005-05-06 09:23:49 UTC
Distribution: Debian Sarge
Hardware Environment: Sony PCG-FR215E
Software Environment: kernel 2.6.8.11 + 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
                                                         11
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
                                                         11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 9
ACPI: PCI Interrupt 0000:00:0e.1[B] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ
                                                         9
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:0e.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ
                                                         11
ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ
                                                         9
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ
                                                         11
ACPI: PCI Interrupt 0000:00:10.1[B] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ
                                                         9
ACPI: PCI Interrupt 0000:00:10.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ
                                                         11
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9
ACPI: PCI Interrupt 0000:00:10.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ
         
9
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ
                                                         11
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ
                                                         11
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
                                                         11
brice@TuxBox:~$ 


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
Yes, 
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 
+0800 
+++ linux-2.6.13/drivers/acpi/events/evgpe.c    2005-09-13 16:42:19.197819512 
+0800 
@@ -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 @@ 
        default: 
                return_ACPI_STATUS (AE_BAD_PARAMETER); 
        } 
+#endif 
 
        return_ACPI_STATUS (AE_OK); 
 } 
 
Comment 11 Brice MEALIER 2005-09-13 02:29:31 UTC
I
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
[brice@TuxBox:linux-2.6.13]$ 

Comment 14 Luming Yu 2005-09-14 01:57:24 UTC
Created attachment 6007 [details]
linux-2.6.13/drivers/acpi/events/evgpe.c

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

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
hello

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
CONFIG_KALLSYMS_EXTRA_PASS=y)

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]
.config

Here it is!

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

# CONFIG_SMP is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y

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_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_X86_UP_APIC=y


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

Working!!

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
Hello

This bug is still present in 2.6.14.2

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.