likely this is an EC issue that Luming is looking at -- assigning it to him.

The last 2 acpi patches (20050708 and 20050729) solved this issue! The battery
gets now recognized!

Best regards, Brice

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.

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.

how do I pass these options?

Using grub?


The default do not recognize the battery every time.

Best regards, Brice

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 

no changes either using ec_burst=1 or ec_burst=0: the battery is always 
randomly recognized.


Regards, Brice

Please post acpidump output. 

please see bug #3750 I reported in which I attached the acpidmp output.

let me know if you need further information.


Best regards, Brice

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); 
 } 
 

I

just try vanilla-2.6.13 without any patch.

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]$ 

Created attachment 6007 [details]
linux-2.6.13/drivers/acpi/events/evgpe.c

Please try to replace your evgpe.c with the attached one.

hello

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


Best regards, Brice

hello

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


Best regards, Brice

Please build kernel with acpi debug option enabled. 
And post the dmesg. 

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

Please post you .config.
If you enabled other preemption model, please try CONFIG_PREEMPT_NONE.

Created attachment 6051 [details]
.config

Here it is!

Brice

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.

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

Created attachment 6055 [details]
diable preempt when holding a semaphore in AML code.

Please test if this patch works with preempt kernel.

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

*** Bug 5236 has been marked as a duplicate of this bug. ***

*** Bug 3750 has been marked as a duplicate of this bug. ***

Hello

This bug is still present in 2.6.14.2

Best regards, Brice

Please try the filed patch. 
The bug should be marked as resolved for Len to push it into base kernel

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

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 ?

Created attachment 6906 [details]
correct return value

Please give it a try without patch of disalbing preempt.

patch in comment #31 applied to acpi-test tree.
Brice, can you confirm it helps your machine?

please see bug 5051

Regards, Brice

Shipped in 2.6.16-rc1-git6 -- closing.