Bug 7466
|
Description
Olivier Mondoloni
2006-11-07 11:19:13 UTC
Created attachment 9421 [details]
dmesg display battery method parse execution error
Created attachment 9422 [details]
dmidecode from mitac 8375
Created attachment 9423 [details]
acpidump from mitac 8375
Created attachment 9424 [details]
lspci -vv from mitac 8375
Created attachment 9425 [details]
proc interrupts from mitac 8375
I try to pass the acpi_serialize parameter at boot to my kernel but nothing change. Thanks in advance. Olivier Please try the latest rc, 2.6.19-rc4 is available now. I have already tested 2.6.19-rc4 linux kernel and the problem is still here. Same problem with 2.6.19-rc5 linux kernel. > Most recent kernel where this bug did not occur: 2.6.18
Can you confirm that 2.6.18 kernel works correctly?
Also, please try boot the latest kernel with ec_intr=0.
With ec_intr=0 as kernel parameter, my problem has gone. Thanks Olivier. (no problem with 2.6.18 linux kernel)
> With ec_intr=0 as kernel parameter, my problem has gone.
Which kernel did you use? Is it possible to check the kernel 2.6.19-rc1?
It tested the ec_intr kernel parameter with 2.6.19-rc5. Important: Is it possible to verify the kernel 2.6.19-rc1? I.e. the kernel 2.6.19-rc1 fails with ec_intr=1 but works with ec_intr=0. Please send the dmesg of failure. Created attachment 9512 [details]
dmesg with kernel parameter ec_intr=0
No problem for battery level.
Created attachment 9513 [details]
dmesg with kernel parameter ec_intr=1
No problem at all also with battery level. It seems strange.
This two dmesg come from 2.6.19-rc1 linux kernel. Created attachment 9522 [details]
Always re-enable GPE at exit from notify handler
Could you please try if this patch makes difference?
Created attachment 9528 [details]
dmesg from kernel patch ec
The battery level problem is back with ec_intr value as default (ec_intr in
interrupt mode). Look at my dmesg.
Tested with 2.6.19-rc5.
Please copy 2.6.18 drivers/acpi/ec.c to your 2.6.19-rc5 tree, recompile and verify the problem. Created attachment 9532 [details]
dmesg from ec 2.6.18 series on 2.6.19-rc5
Something is strange. After the charging process of my battery, the level
reaches 100% which is normal but in my dmesg, I have ACPI errors related to EC,
AE_TIME.
This is for 2.6.19-rc5: Please remove patch from bug 5534 comment 159 (don't defer release of global lock) i.e. patch -R ... and check the problem (I mean the battery state and error messages). Please perform it for both ec.c - 2.6.18 and 2.6.19-rc5. Thanks for the help. Created attachment 9549 [details]
dmesg from 2.6.19-rc5 without defergloballock patch
Without the defergloballock patch and with the 2.6.19-rc5 ec, the battery level
is always weird with 849%. I am going to try 2.6.19-rc5 kernel with 2.6.18 ec.c
now.
Created attachment 9551 [details]
2.6.19-rc5 dmesg 2.6.18 ec (patch -R) defergloballock
I try this at the end:
patch -R defergloballock on my 2.6.19-rc5 kernel
2.6.18 ec.c on 2.6.19-rc5
The result is that battery level seems working because it shows when my battery
is charged 100% of the capacity (not a weird number like 819).
Created attachment 9559 [details]
2.6.19-rc5 dmesg 2.6.18 ec (patch -R) defergloballock fix
Today with the lastest patching procedure, I have ACPI error messages but the
battery level is good.
Sorry.
This is for 2.6.19-rc5: Please remove patch defergloballock; ec.c should be from 2.6.19-rc5; please apply the patch from comment #18 (GPE in ec.c) and check the problem (dmesg, state) Thanks. Created attachment 9571 [details] 2.6.19-rc5 dmesg with ec (comment#18) Always weird battery level(749%) and acpi errors (errors and exceptions). Created attachment 9573 [details]
Yield on deferred queue
Please try this patch on top of rc6-git2.
Created attachment 9579 [details]
2.6.19-rc6-git2 dmesg with yield deferred queue patch
Always acpi errors and exceptions messages but battery level reported is good
(100% of the capacity after a charging process).
Created attachment 9590 [details]
Changes to handling query events in EC
Thanks, could you please add this patch to the mix?
Created attachment 9595 [details]
2.6.19-rc6-git2 dmesg with mix patch
Always ACPI errors and exceptions but battery level reported after charging
process is good (100%).
Created attachment 9612 [details]
Make expect_event atomic and set it before writing to EC.
Please test if this patch makes difference...
Created attachment 9621 [details]
2.6.19-rc6-git2 dmesg with expect event atomic patch
Battery level appears to be good (100% of the capacity) but I always have acpi
errors and exceptions.
continue.
Do you see any other evaluation of _Qxx methods after the "EC: evaluating _Q01" ? I also had one day "EC: evaluating _Q09" . Created attachment 9632 [details]
several ec evaluating from my computer
Created attachment 9633 [details]
kernel log since ec evaluating
Created attachment 9634 [details]
Moved checks for completion around
Thanks,
Here is one more patch to test... If it does not help, could you try to change
EC_DELAY in the beginning of drivers/acpi/ec.c to 500?
What are the patches that they have to be applied on my kernel ? Only the last one ? On which kernel version ? On 2.6.19-rc6, the last patch produces errors when I try to apply it. Line 924 to be more precise. Created attachment 9641 [details]
Patch for 19-rc6
Sorry, my bad... Here is proper patch.
Created attachment 9644 [details]
Smaller patch
This one should be better...
Created attachment 9651 [details]
kernel log (lastest patch applied)
The lastest patch to 2.6.19-rc6 kernel produces acpi errors and displays
battery level as null but my battery is 32%(when I reboot to a non-patched
kernel) at the moment when the problem occured.
Created attachment 9652 [details]
proc acpi battery BAT0 info when the problem occured
Created attachment 9653 [details]
proc acpi battery BAT0 state when the problem occured
Created attachment 9654 [details]
proc acpi battery BAT0 right info
Created attachment 9655 [details]
proc acpi battery BAT0 right state
Could you try to change ACPI_EC_DELAY from 50 to 500 in the drivers/acpi/ec.c? It's in testing. Created attachment 9672 [details]
Check for event arrived once again after timeout.
From you latest log it looks like interrupt did not arrive, while status value
did change. I added a check to always check status field, even if we did not
get an interrupt. Please try.
Created attachment 9691 [details] kernel log with attachment #9644 [details] ACPI_EC_DELAY=500 It works great with ACPI_EC_DELAY=500 . Nice job. Could you please put it under some stress load, like doing ------------------------------------ while true; do cat /proc/acpi/battery/*/* & cat /proc/acpi/thermal_zone/*/* & done ------------------------------------ ? Could you also check if delay increase helps without any patches? Created attachment 9705 [details]
kernel log with the lastest patch
No problems at all with this patch under big stress load (heavy compilation of
programs). Battery level after charging is at 100% of its capacity with no acpi
errors.
Problem after complete charge of my battery. "ACPI : read EC, IB not empty" My battery is charged but it shows me 0% of the capacity. Is it the last past patch? Or is it unpatched kernel with only DELAY changes?
If you applied the patch, could you try to replace these back:
if (!acpi_ec_check_status(ec, ACPI_EC_EVENT_IBF_0)) {
by
status = acpi_ec_wait(ec, ACPI_EC_EVENT_IBF_0);
if (status) {
I am going to try your change for status. My problem related to IB not empty occured on a kernel with the lastest patch you have done. Stay tune, I try your fix. Created attachment 9734 [details]
kernel log with status patch without DELAY changes
I try your fix for status but without changing DELAY. I have ACPI errors and my
battery level is 849% of its capacity.
The kernel use is 2.6.19 with the lastest patch applied and status fix (but
without changing DELAY).
Created attachment 9744 [details]
Combined patch with increased ACPI_EC_DELAY
It seems that increasing ACPI_EC_DELAY is always needed.
Here is a combined patch with already increased delay. Please test.
Created attachment 9758 [details]
kernel log related to combined patch with ec_delay #att9744
With the lastest patch (Attachement #9744), my laptop works flawlessly. My
battery level displayed is good (100% of its capacity). No acpi errors occured.
Great.
Created attachment 9771 [details]
kernel log related to combined patch with ec_delay #att9744
Today, it's very weird. I have acpi errors but the battery level is good (100%
of its capacity).
Sorry.
I try in my kernel config to change timer frequency 100 hz to 250 hz. It seems that on a non patched kernel my level battery is working good. I try this setting on 2.6.19.1 linux kernel (non patched). Timer frequency is the solution ? I am going to use my notebook with this kernel during this week. See you soon. No problems, no acpi errors today with timer frequency 250 hz and no patched kernel. Today no problems. Timer value at 250Hz seems to fix the problem (acpi errors). I think you can close this bug report. Please perform stress test on 250Hz and 100Hz kernels - run in a loop 'cat /proc/acpi/battery/*/*' for a long time concurrently and check dmesg on errors. Please post the full dmesg for both cases. Created attachment 9925 [details]
stress load test program
Created attachment 9926 [details]
dmesg timer 250Hz from stress load program
just after 1 minute of program execution.
Thanks, But, what about 100Hz + patches? I suggest test battery about 10 mins. I would to test it but my kernel crash after just 1 minute of testing. > I would to test it but my kernel crash after just 1 minute of testing.
Do you have any logs of crash?
Is it 100Hz kernel? And what about 10 min testing on 250Hz?
Created attachment 9943 [details]
kernel log from 10 mins of stress load prog 250Hz
Created attachment 9944 [details]
kernel log from 10 mins of stress load prog 100Hz+patches
> I think you can close this bug report.
Please reopen the bug if problem will appear in future kernel versions.
|