Bug 4980
|
Description
Oleksij Rempel (fishor)
2005-08-01 10:05:59 UTC
Some additional information would be helpful, e.g.: - are there any messages or anything else that would give a hint about the cause of the problem? - your .config - the output of "dmesg -s 1000000" OK :-) With kernel 2.6.13-rc4 i get: PM: Preparing system for mem sleep Stopping tasks: =========================================================================| usb 1-2.3: usb suspend usb 1-2.1: usb suspend usb 1-2: usb suspend uhci_hcd 0000:00:07.2: suspend_rh usb usb1: usb suspend uhci_hcd 0000:00:07.2: uhci_suspend uhci_hcd 0000:00:07.2: --> PCI D0/legacy PM: Entering mem sleep //////////////////////end///////////////////////////// with 2.6.13-rc4-mm1 some thing like this (i cant get dmesg for this): PM: Preparing system for mem sleep Stopping tasks: =========================================================================| usb 1-2.3: no poweroff yet, suspend insteat usb 1-2.1: no poweroff yet, suspend insteat usb 1-2: no poweroff yet, suspend insteat uhci_hcd 0000:00:07.2: suspend_rh acpi can't get interrupt ... bla bla uhci_hcd 0000:00:07.2: no poweroff yet, suspend insteat Created attachment 5458 [details]
kernel config
Created attachment 5459 [details]
dmesg 2.6.13-rc4-mm1
Created attachment 5460 [details]
lspci
Created attachment 5461 [details]
dsdt
Kernel 2.6.13-rc5 tested. Still can't get mem sleep. Now it's looks like:
usb 1-2.3: usb suspend
usb 1-2.1: usb suspend
usb 1-2: usb suspend
acpi cannot get interup for device 0000:00:0c.0
acpi cannot get interup for device 0000:00:0d.0
usb usb1: usb suspend
and freez!
0000:00:0c.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev 12) 0000:00:0d.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0c) This is probably related to the PCI Interrupt Link suspend/resume changes. We changed that code after 2.6.13-rc5, so if you can test the latest linus git-tree, or -rc6 when that appears, it would be great. OK!I tested latest linus git-tree. It's can s3 suspens and resume but now: sleep button don't working and $ cat /proc/acpi/battery/BAT0/info present: no they are pluget! with kernel 2.6.13-rc5-mm1 all working properly. Thanks for reporting back, I guess latest Linus's git tree also fixes the issue, right? I tested latest git. It's can suspend and resume but after resume it's lost battery. Before suspend battery wose present. Created attachment 5558 [details]
dmesg-git 2005.08.09
How about unload battery driver and load it after resume? Did the system ever fully work before? I never compile it like a module. But i will try :-) > Did the system ever fully work before?
Yes. If you mean suspend, resume and battery. I thin with kernel 2.6.13-rc1-mm1
With WinXp all this futures and some more working wery good :-( I tryed to unload battery module and load it agen after resume.It schow battery as present but wrong batt_info and all acpi events blocked (Power and sleep button not worked). Here is /proc/acpi/battery/info output: This is OK. ///////////////////begin//////////////// present: yes design capacity: 3800 mAh last full capacity: 3248 mAh battery technology: rechargeable design voltage: 7400 mV design capacity warning: 330 mAh design capacity low: 99 mAh capacity granularity 1: 16 mAh capacity granularity 2: 16 mAh model number: serial number: battery type: LION OEM info: Samsung ////////////////////end//////////////////// this is after resume it's wrong /////////////////begine/////////////// present: yes design capacity: 972800 mAh last full capacity: 831488 mAh battery technology: unknown design voltage: 1894400 mV design capacity warning: 84480 mAh design capacity low: 25344 mAh capacity granularity 1: 4096 mAh capacity granularity 2: 4096 mAh model number: serial number: battery type: LION OEM info: Samsung ////////////////end/////////////////////// Might be an EC issue. Did other ACPI devices like AC adapter which uses EC also work (state is ok) after resume? Please make sure your kernel version is using polling mode ec driver (2.6.13-rc6 has it). I use git three it's using polling mode > ec.c > static int acpi_ec_polling_mode = EC_POLLING; if it's correct, i use this to update git-kernel: > cd linux-2.6 > rsync -a --verbose --stats --progress \ > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \ > .git/ After resume ac-adapter show online, power and sleep buttons are working. But if i change it to offline it will newer go back, power and sleep buttons not working eny more. All this looks like Bug#: 4506 wich was fixed with kernel 2.6.13-rc1-mm1 Tested. With ec_burst=1 boot option all ewents working properly. Please summarize what is failing in the latest Linus tree, and if it a regression compared to an earlier release such as 2.6.12, or if it is something that has never worked. If the behaviuor is different in the latest -mm, that is always useful to know, but we can close a bug only when the fix has shipped in Linus' tree. kernel: |2.6.12.3|2.6.13-rc6|2.6.13-rc6+ec_burst=1 power_btn |work. |block.if |work sleep_btn |work. |block.if |work batt_info |wrong |real.if |work suspen_resume |work. |work. |work 2.6.13 results are the same as 2.6.13-rc6, yes? Good to know that ec_burst=1 fixes everything in 2.6.13. But it is a regression that 2.6.13 requires the ec_burst=1 parameter when 2.6.12 did not, yes? Does 2.6.13 work with ec_burst=0 if the latest patch in bug 3851 is applied? This patch is ready in stable 2.6.13. May be you mean other patch. Plese give me direct link. the released 2.6.13 doesn't have latest ec patch filed at bug 3851. It would be great if you can test them to see if it works too. Another point is if ec_burst=1 fix a real bug, not a regression that leaked into base kerne before. *** Bug 4535 has been marked as a duplicate of this bug. *** I tested kernel 2.6.13+patch result negative. For example after disconecting ac_adapter batt_info show proper info but not worked after ac wose connectet agene. Actually not battareys only, power and sleep battons not working too. Did you supply boot option ec_burst=1? If yes, please post dmesg. No i tested with ec_burst=0. But today i tested with ec_burst=1 ang get worst result alredy after boot nothing worked (i mean batt. & buttons) Created attachment 5912 [details]
dmesg-2.6.13+patch+ec_burst=0
Created attachment 5913 [details]
dmesg-2.6.13+patch+ec_burst=1
very strange!!! You have ever said everything works with 2.6.13-rc6+ec_burst=1 So, please verfy if 2.6.13-rc6 works with patch at http://bugzilla.kernel.org/show_bug.cgi?id=3851#c73. With this patch it's never worked. I tested this patch for about one month and it didn't worked. I wrote it you! Is some thing chenged in this time with this patch ore Kerenl? Kernel 2.6.13+ec_burst=1 stil the beste what i have on this laptop. Ok, please post /proc/interrupt before and after cat battery info. According to comment#c73, 2.6.13-rc6 works. Please retest it . Sorry, I quoted wrong number. It should be comment #23 Interrupts with 2.6.13-rc6 no ec_burst=1.
====================Before sleep=============================
CPU0
0: 1230652 XT-PIC timer
1: 193 XT-PIC i8042
2: 0 XT-PIC cascade
7: 0 XT-PIC parport0
8: 4 XT-PIC rtc
9: 340 XT-PIC acpi
10: 53603 XT-PIC uhci_hcd:usb1, Allegro
11: 2331 XT-PIC yenta, eth0
12: 110 XT-PIC i8042
14: 24268 XT-PIC ide0
15: 19158 XT-PIC ide1
NMI: 0
ERR: 0
========================After sleep================
CPU0
0: 1292307 XT-PIC timer
1: 243 XT-PIC i8042
2: 0 XT-PIC cascade
7: 0 XT-PIC parport0
8: 4 XT-PIC rtc
9: 375 XT-PIC acpi
10: 60437 XT-PIC Allegro, uhci_hcd:usb1
11: 2383 XT-PIC yenta, eth0
12: 274 XT-PIC i8042
14: 25128 XT-PIC ide0
15: 20083 XT-PIC ide1
NMI: 0
ERR: 0
Please test linux-2.6.14-rc1 with ec_burst=0 and ec_burst=1. If you find any issue, please cat and post /proc/interrupts before and after that test. kernel: |2.6.14-rc1|2.6.14-rc1|2.6.13 |2.6.13 boot_opt: |ec_burst=0|ec_burts=1|ec_burst=0|ec_burst=1| after- |boot|sleep|boot|sleep|boot|sleep|boot|sleep| power_btn |ok |no |no |no |ok |no |ok |ok | sleep_btn |ok |no |no |no |ok |no |ok |ok | batt |ok |no |no |no |ok |no |ok |ok | ac_adapter |ok |no |ok |ok |ok |no |ok |ok | suspen_resume |ok |ok |ok |ok |ok |ok |ok |ok | kernel 2.6.14-rc1 with ec_burst=0 schow the same result as 2.6.13 with same boot option. WIth ec_burst=1 2.6.14-rc1 schow worst result. /proc/interrupts are alwey same as in Comment #37 . 2.6.14-rc1-mm1 not tested. I'm surprised by the results of the worst 2.6.14-rc1 ec_burst=1 result. Please build kernel with acpi debug option enabled , and post dmesg of 2.6.14- rc1 ec_burst=1. It is very important to cat and post /proc/interrupts before and after query battery info, because ec_burst=1 is pure interrupt based. I want to make sure if acpi interrupt gets increment when you query battery info. Please also post acpidump output. I disabled acpid and xorg to preserv battery cheking and the kernel was kompiled
with acpi-debug. The ac and battery modules was kompiled as modules and loaded
after boot.Here is the interrupt output before modprobe & cat and after.
CPU0
0: 76383 XT-PIC timer
1: 91 XT-PIC i8042
2: 0 XT-PIC cascade
7: 0 XT-PIC parport0
8: 4 XT-PIC rtc
9: 143 XT-PIC acpi
10: 190 XT-PIC uhci_hcd:usb1, Allegro
11: 88 XT-PIC yenta, eth0
12: 1964 XT-PIC i8042
14: 2234 XT-PIC ide0
15: 758 XT-PIC ide1
NMI: 0
ERR: 0
CPU0
0: 145314 XT-PIC timer
1: 328 XT-PIC i8042
2: 0 XT-PIC cascade
7: 0 XT-PIC parport0
8: 4 XT-PIC rtc
9: 180 XT-PIC acpi
10: 190 XT-PIC uhci_hcd:usb1, Allegro
11: 128 XT-PIC yenta, eth0
12: 3134 XT-PIC i8042
14: 2286 XT-PIC ide0
15: 1846 XT-PIC ide1
NMI: 0
ERR: 0
Created attachment 6052 [details]
dmesg-2.6.14-rc1-mm1
Comment on attachment 6052 [details]
dmesg-2.6.14-rc1-mm1
ec_burst=1
Created attachment 6053 [details]
acpidump
From the log, Battery 0 is absent. Thanks for these info. Could you confirm ACPI interrupt can get increased by pressing power button before and after loading battery module? I suspect this is a irq issue rather than ec driver issue. I'm sorry i didn't anderstood what do you meen. Please sey primitiv what i need to do :) 1. boot kernel linux-2.6.14-rc1 with ec_burst=1 . 2. login 3. kill acpid 4. cat /proc/interrupts 5. press power button 6. cat /proc/interrupts 7. load battery module 8. cat /proc/interrupts 9. press power button 10. cat /proc/interrupts 11. run dmesg , and post dmesg output. Hi Alexey, Could you repost the testing results. I cannot access them. Thanks, Luming Created attachment 6065 [details]
dmesg+debug_patch
Created attachment 6066 [details]
script output 2.6.14-rc1 ec_burst=1
The above logs show battery status works with 2.6.14-rc1 burst=1. But your previous reports clearly show battery is not present with 2.6.14-rc1 burst=1. I don't know why. This is complitly wrong status. I mean no as not OK. Bat it's looks like bead idea. I will write wrong insteat. Sorry. what do you mean? Do you mean the battery info is wrong? Or do you mean the battery shouldn't be present? From the ec access log, ec driver looks fine. Could you reproduce the issue of baterry-not-present, and post the log. Thanks very much. The battery output is wrong like Comment #18 . baterry-not-present is kernel 2.6.14-rc1-mm1's issue. Oh, I didn't notice that. Could you apply that debugging patch against 2.6.13. I suppose it should work. Please do same test as 2.6.14-rc1 and post the log. I want to see what's the difference in accessing ec. Created attachment 6078 [details]
script output 2.6.13 ec_burst=1
Created attachment 6079 [details]
dmesg 2.6.13+debug_patch
Created attachment 6083 [details]
against 2.6.14-rc1
From the log, I found some difference in ec reading like:
2.6.14-rc1: (Wrong!)
read [00] from address[88]
read [d8] from address[89]
read [0e] from address[8a]
2.6.13: (correct)
read [d8] from address[88]
read [0e] from address[89]
read [00] from address[8a]
I suspect acpi_ec_burst_wait return too soon before data ready in ec output
data buffer.
Please test patch at http://bugzilla.kernel.org/attachment.cgi?id=6083&action=view Created attachment 6084 [details]
script output 2.6.14-rc1-mm1 ec_burst=1
Created attachment 6085 [details]
dmesg 2.6.14-rc1-mm1+debug_patch
I'm not sure what could cause battery absent issue in 2.6.14-rc1-mm1. But 2.6.14-rc1 issue should be resolved first. So, please patch the following patch against 2.6.14-rc1 http://bugzilla.kernel.org/attachment.cgi?id=6083&action=view And see if battery status can work as expected. Thanks very much. About in two hours it will be ready. Created attachment 6086 [details]
dmesg 2.6.14-rc1+debug_patch+last_patch
Batt info is correct!
Created attachment 6087 [details]
patch against 2.6.14-rc1
This is update one. Please test it.
If it do solve your problem, I will push the patch to Len.
It's working but some times it schow strang walue: present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 3312 mAh present voltage: 8192 mV root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 9440496 mAh present voltage: 8192 mV root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 3312 mAh present voltage: 8192 mV Created attachment 6089 [details]
dmesg 2.6.13+debug_patch+update_patch
It's working.
Please post log for 2.6.14-rc1+debug_patch+update_patch when battery behaves correct and wrong. I want to understand the difference in ec reading. Does that update_patch fix battery-absent issue for 2.6.14-rc1-mm1? correct Sep 22 22:03:07 localhost kernel: Read [f0] from address [bc] Sep 22 22:03:07 localhost kernel: Read [0c] from address [bd] Sep 22 22:03:07 localhost kernel: Read [00] from address [be] Sep 22 22:03:07 localhost kernel: Read [00] from address [bf] wrong Sep 22 22:03:08 localhost kernel: Read [f0] from address [bc] Sep 22 22:03:08 localhost kernel: Read [0c] from address [bd] Sep 22 22:03:08 localhost kernel: Read [90] from address [be] Sep 22 22:03:08 localhost kernel: Read [00] from address [bf] correct root@lopi:/home/lex# echo "cat batt info" >> /var/log/kern.log && cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 3312 mAh present voltage: 8192 mV wrong root@lopi:/home/lex# echo "cat batt info" >> /var/log/kern.log && cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 9440496 mAh present voltage: 8192 mV wrong Sep 22 22:29:42 localhost kernel: Read [f0] from address [bc] Sep 22 22:29:42 localhost kernel: Read [0c] from address [bd] Sep 22 22:29:42 localhost kernel: Read [00] from address [be] Sep 22 22:29:42 localhost kernel: Read [90] from address [bf] present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: -1879044880 mAh present voltage: 8192 mV and this is wrong too Sep 22 22:31:29 localhost kernel: Read [f0] from address [bc] Sep 22 22:31:29 localhost kernel: Read [90] from address [bd] Sep 22 22:31:29 localhost kernel: Read [00] from address [be] Sep 22 22:31:29 localhost kernel: Read [00] from address [bf] wrong present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 37104 mAh present voltage: 8192 mV Please do: boot 2.6.14-rc1+debug_patch+update_patch echo -n 0x10 > /proc/acpi/debug_layer echo -n 0x10 > /proc/acpi/debug_level Keep testing battery status until wrong, Then Please post full log. I suspect the OBF bit is always 1 on your laptop's EC controller. Could you confirm MS windows works well? Yes Ms Windows working well without any extra firmware from manufacture. I can make some screenschot if you need. I tested kernel 2.6.14-rc1-mm1 with update patch - it's working :) . Created attachment 6106 [details]
debug batt output
present: yes
capacity state: ok
charging state: charged
present rate: 0 mA
remaining capacity: 3296 mAh
present voltage: 8192 mV
root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state
present: yes
capacity state: ok
charging state: charged
present rate: 0 mA
remaining capacity: -1879044896 mAh
present voltage: 8192 mV
//////////////////////////////////////////////////////This is last one
root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state
present: yes
capacity state: ok
charging state: charged
present rate: 0 mA
remaining capacity: 3296 mAh
present voltage: 8192 mV
I maked one shot more
Created attachment 6109 [details]
latest patch against 2.6.14-rc1
Please test the latest patch against 2.6.14-rc1.
root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 3360 mAh present voltage: 8192 mV root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 36896 mAh present voltage: 8192 mV root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 3360 mAh present voltage: 8192 mV Execute Method: [\_SB_.BAT0._BST] (Node c7fc8c88) Read [20] from address [bc] Read [0d] from address [bd] Read [00] from address [be] Read [00] from address [bf] Execute Method: [\_SB_.BAT0._BST] (Node c7fc8c88) Read [20] from address [bc] Read [90] from address [bd] Read [00] from address [be] Read [00] from address [bf] Execute Method: [\_SB_.BAT0._BST] (Node c7fc8c88) Read [20] from address [bc] Read [0d] from address [bd] Read [00] from address [be] Read [00] from address [bf] root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 3360 mAh present voltage: 8192 mV root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 9440544 mAh present voltage: 8192 mV root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 3360 mAh present voltage: 8192 mV Execute Method: [\_SB_.BAT0._BST] (Node c7fc8c88) Read [20] from address [bc] Read [0d] from address [bd] Read [00] from address [be] Read [00] from address [bf] Execute Method: [\_SB_.ADP0._PSR] (Node c7fc89c8) Read [c8] from address [c4] Read [80] from address [c5] Read [00] from address [c6] Read [00] from address [c7] Execute Method: [\_SB_.BAT0._BST] (Node c7fc8c88) Read [20] from address [bc] Read [0d] from address [bd] Read [00] from address [be] Read [00] from address [bf] Output with new patch Do you need all dmesg output ore it's enaf? Created attachment 6114 [details]
patch-take-2 against 2.6.14-rc1
Please test this one, and post log.
root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 3344 mAh present voltage: 8192 mV root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 36880 mAh present voltage: 8192 mV Execute Method: [\_SB_.BAT0._BST] (Node c7fc8c88) Read [10] from address [bc] Read [0d] from address [bd] Read [00] from address [be] Read [00] from address [bf] Execute Method: [\_SB_.BAT0._BST] (Node c7fc8c88) Read [10] from address [bc] Read [90] from address [bd] Read [00] from address [be] Read [00] from address [bf] Execute Method: [\_SB_.BAT0._BST] (Node c7fc8c88) root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: -1879044848 mAh present voltage: 8192 mV root@lopi:/home/lex# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 3344 mAh present voltage: 8192 mV Execute Method: [\_SB_.ADP0._PSR] (Node c7fc89c8) Read [c8] from address [c4] Read [80] from address [c5] Read [00] from address [c6] Read [00] from address [c7] Execute Method: [\_SB_.BAT0._BST] (Node c7fc8c88) Read [10] from address [bc] Read [0d] from address [bd] Read [00] from address [be] Read [00] from address [bf] This is result with new patch. May be it's not realy importent? One more quastion. On this laptop is "undock" wich not working with linux but working well with windows without extra software, if i press it i get: Execute Method: [\_SB_.PCI0.ISA_.EC0_._Q0C] (Node c7fc3b88) Execute Method: [\_SB_.DDCK._STA] (Node c7fc86c8) Is it hotbuttons or motherboard issue ? How i need to post it? i meen undock button Please post dmesg. Did you see "Error in acpi_ec_enter_burst_mode" in dmesg? As for DOCK, linux needs a dock driver, but it isn't ready. Created attachment 6124 [details]
dmesg 2.6.14-rc1+debug_patch+last_patch
There is no "Error in acpi_ec_enter_burst_mode" messages.
About comment Comment #78 . I thing it's not only Execute Method issue. In dmesg you'l see meany examples wich come with wrong output but with corret to. Do you anderstand what i meen? But always if read bite is 90 output is wrong. Not sure why. From the latest dmesg, there aren't error messages clue to the root cause. I suspect OBF flag got set before the data became ready. Another possibility is EC just return 0x90. Created attachment 6127 [details]
patch-take-2 against 2.6.14-rc1
patch-take3 against 2.6.14-rc1
Please test it. The patch invokes leave burst mode.
Created attachment 6134 [details]
dmesg 2.6.14-rc1+debug_patch+last_patch3
Still same issue: wrong output if 90. But it's happening only one time per 20 tests. I tested sleep and resume with and without ac. It's working realy good. All buttons are working and etc. Hmm, interesting. Did you enable preempt? If yes, would you please try disabling preempt. CONFIG_PREEMPT_NONE=y But still same issue. Oh, could you test if this issue only happens with ec_burst=1 on 2.6.14-rc1? Does ec_burst=0 have this issue on 2.6.14-rc1? No ec_burst=0 don't have this one but after resume some thing couse battery absent issue. Created attachment 6135 [details]
patch-take-4 against 2.6.14-rc1
PLease test patch-take4 that just remove burst mode related calls.
Because 0x90 means burst mode ACK, I want to see if this debug patch
can have some postive effect.
Created attachment 6165 [details]
dmesg-2.6.14-rc1+patch4
Patch tested. I didn't get any wrong outputs! Sleep,resume, buttonsn and
battery info are working properly.
Thanks a lot for your testing reports. I think the ec controller of this laptop has some unexpected behavior that confused EC driver. So, I think it is NOT safe to enter burst mode for this laptop. Maybe this rule can apply to others. Since my latest patch works, I will push it to Len after clean up. Thanks again. Thenk you too :) But haow about ec_burst=0 it's not realy working on this laptop. Created attachment 6171 [details]
cleanup version of patch-take-4
To comment# 97, ec_burst=0 use polling to operate ec. ec_burst=1 is based on interrupt for ec operations. Polling depends on ec status bits to determine if data is ready. if status bit is wrong, polling will be wrong too. Maybe this is reason why ec_burst=0 doesn't work after resume. And ec_burst=1 will be enabled by default. Patch is tested. All working! Thenk you wery match! *** Bug 5713 has been marked as a duplicate of this bug. *** patch in comment 98 applied to acpi-test tree some time ago, should go into 2.6.16 when it opens. Shipped in 2.6.16-rc1-git6 -- closing. Alexey, we are about to try to enable burst mode in EC again, as a patch for bug #9341. Could you check if this patch does not break your machine? Unfortunately, I have not the laptop any more :( |