Bug 12011
|
Description
Zygfryd Homonto
2008-11-11 10:23:49 UTC
Zygfryd, Poll functionality was moved into separate function -- ec_poll, this is why it is absent in ec_wait. There is a #12004 patch about the same issue, could you please try patches from there? (In reply to comment #1) > Zygfryd, > Poll functionality was moved into separate function -- ec_poll, this is why > it > is absent in ec_wait. > There is a #12004 patch about the same issue, could you please try patches > from > there? > all patches or just ec.c ? we are talking about this: http://bugzilla.kernel.org/show_bug.cgi?id=12004#c42 right ? Yes, you may just replace drivers/acpi/ec.c with one from the tarball in comment #42. Or, you may apply patch series to your file to get same result. Created attachment 18822 [details]
dmesg.log
not working sir - dmesg attached, plus some other info here:
14:35:16 papio@baboon:~$ acpi -V
Thermal 1: ok, 144.0 degrees C
AC Adapter 1: off-line
14:35:20 papio@baboon:~$ cat /proc/acpi/battery/BAT1/info
present: no
14:35:28 papio@baboon:~$ cat /proc/acpi/battery/BAT1/
alarm info state
14:35:28 papio@baboon:~$ cat /proc/acpi/battery/BAT1/state
present: no
14:35:35 papio@baboon:~$ cat /proc/acpi/ac_adapter/ADP1/state
state: off-line
14:35:41 papio@baboon:~$ uname -a
Linux baboon 2.6.27-ARCH #1 SMP PREEMPT Wed Nov 12 14:10:47 EET 2008 i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux
Created attachment 18823 [details]
Enable EC region handlers before bus_scan
This patch was added to mainline in order to fix your case. Please try.
(In reply to comment #5) > Created an attachment (id=18823) [details] > Enable EC region handlers before bus_scan > > This patch was added to mainline in order to fix your case. Please try. > let me understand it clearly: first new ec.c from comment #1 and on top on this patch from #5 and recompile - right ? right. Created attachment 18824 [details]
dmesg.log
did not help at all:
18:04:04 papio@baboon:~$ acpi -V
Thermal 1: ok, 144.0 degrees C
AC Adapter 1: off-line
18:04:08 papio@baboon:~$ cat /proc/acpi/battery/BAT1/state
present: no
18:04:16 papio@baboon:~$ cat /proc/acpi/battery/BAT1/info
present: no
18:04:20 papio@baboon:~$ uname -a
Linux baboon 2.6.27-ARCH #1 SMP PREEMPT Wed Nov 12 17:23:32 EET 2008 i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux
18:04:32 papio@baboon:~$
ACPI: AC Adapter [ADP1] (on-line) Marking TSC unstable due to TSC halts in idle ACPI: Battery Slot [BAT1] (battery present) input: Power Button (FF) as /class/input/input3 ACPI: Power Button (FF) [PWRF] input: Lid Switch as /class/input/input4 ACPI: Lid Switch [LID0] input: Sleep Button (CM) as /class/input/input5 ACPI: Sleep Button (CM) [SLPB] input: Power Button (CM) as /class/input/input6 ACPI: Power Button (CM) [PWRB] thermal LNXTHERM:01: registered as thermal_zone0 ACPI: Thermal Zone [THRM] (75 C) It was ok before you loaded this: i801_smbus 0000:00:1f.3: PCI INT C -> GSI 17 (level, low) -> IRQ 17 please do not load it and ACPI will work. Actually, there are lots of hwmon drivers which kill ACPI -- just use one of them, either ACPI or hwmon. did you mean: "don't load sensors" ? lm_sensors is the only one I'm using, which loads coretemp module I have no idea what is responsible for these 2 lines: (if this is what you mean: "it was ok before..." thermal LNXTHERM:01: registered as thermal_zone0 ACPI: Thermal Zone [THRM] (75 C) in my /etc/rc.conf I have daemons: hal - which loads acpid sensors - which loads sensors and module: acpi-cpufreq but I don't this one makes a difference sensors and hwmon are essentially same thing, in kernel they are named "hwmon subsystem", in userspace there is lm_sensors project. (In reply to comment #11) > sensors and hwmon are essentially same thing, in kernel they are named "hwmon > subsystem", in userspace there is lm_sensors project. > super, but still I don't get what you meant by saying: "please do not load it and ACPI will work. Actually, there are lots of hwmon drivers which kill ACPI -- just use one of them, either ACPI or hwmon. " if you can just gimme a hint which way I should... ;) you could disable hwmon at kernel compile time under "drivers->hwmon". You could find /etc/lm_sensors or something similar and make sure it's empty. I'm not very familiar with hwmon, as I am "from other camp" and usually just can't have them enabled for the reasons above. So, if nothing helps -- try Google :) I uninstalled lm_sensors - same problem as above - what is strange: it is not broken immediatelly: it stops working withing few minutes I could try this "drivers->hwmon" in kernel and recompile again and see but, that was not a case in 2.6.27.4 - everything was OK ! please provide dmesg before and after error. Created attachment 18826 [details]
dmesg.log acpi OK
Created attachment 18827 [details]
dmesg.log acpi NOT ok
did you post same file twice? your not-ok file has same ACPI information (battery and AC both present, temp=96C (quite high)), no errors. Created attachment 18828 [details]
dmesg.log acpi NOT ok 2
currently acpi not ok, so dmesg again
21:18:03 papio@baboon:~$ cat /proc/acpi/battery/BAT1/info
present: no
21:55:19 papio@baboon:~$ acpi -V
Thermal 1: ok, 144.0 degrees C
AC Adapter 1: off-line
21:55:23 papio@baboon:~$ dmesg > dmesg-NOTOK-2.log
21:55:36 papio@baboon:~$
please uncomment #define DEBUG at /drivers/acpi/ec.c and do dmesg again -- might be in this case we see something. Created attachment 18844 [details]
dmesg.log debug on
11:17:05 papio@baboon:/home/tmp$ dmesg > dmesg-acpi-debug-ON.log
11:17:16 papio@baboon:/home/tmp$ acpi -V
Thermal 1: ok, 144.0 degrees C
AC Adapter 1: off-line
11:17:21 papio@baboon:/home/tmp$ cat /proc/acpi/battery/BAT1/info
present: no
11:17:28 papio@baboon:/home/tmp$ cat /proc/acpi/battery/BAT1/state
present: no
11:17:31 papio@baboon:/home/tmp$
Zygryd, please check if limit ACPI_EC_STORM_THRESHOLD to 1 helps. Hi there I have an MSI Vr330X laptop and i have a similar problem..Some time after using my distro It says that "Warning! Your battery status is critical" and it shows %0 in the battery-meter applet. Either when i'm studying with battery or AC online. A few minutes ago it said the same again. Here's my "cat /proc/acpi/battery/BAT1/info" output bash-3.2# cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: charged present rate: unknown remaining capacity: unknown present voltage: 10000 mV bash-3.2# cat /proc/acpi/battery/BAT1/info present: yes design capacity: 4400 mAh last full capacity: 3888 mAh battery technology: rechargeable design voltage: 11100 mV design capacity warning: 0 mAh design capacity low: 0 mAh capacity granularity 1: 1 mAh capacity granularity 2: 1 mAh model number: MS-1326 serial number: battery type: LION OEM info: MSI Corp. And here's the State output bash-3.2# cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: charged present rate: unknown remaining capacity: unknown present voltage: 10000 mV Hi all, I've same problem on 2.6.28, in 2.6.27.x was all right. Battery monitor and ifo about thermal zone works about 2 hours, and then its fail, notebook is MS1222 (MSI PR210) cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 5233 mAh present voltage: 16723 mV cat /proc/acpi/battery/BAT1/info present: yes design capacity: 5200 mAh last full capacity: 5233 mAh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 0 mAh design capacity low: 0 mAh capacity granularity 1: 1 mAh capacity granularity 2: 1 mAh model number: MS-1222 serial number: battery type: LION OEM info: MSI Corp. (In reply to comment #22) > Zygryd, > please check if limit ACPI_EC_STORM_THRESHOLD to 1 helps. > Alexey, I seem to have the very same issue with MSI PR200, and for now, reducing ACPI_EC_STORM_THRESHOLD seems to help. I'm testing ACPI_EC_STORM_THRESHOLD=1 as well so far so good lets see it later not WORKING !, even with ACPI_EC_STORM_THRESHOLD=1
# acpi -V
Thermal 1: ok, 144.0 degrees C
AC Adapter 1: off-line
Same here, it took a while, but it dissapeared again. is there ANY hope ACPI will work perfect as in 2.6.27-5 and earliers ? Zygfryd, you mention 9823 bug, but it only touch systems there EC driver works in poll mode. your "ok" log shows that EC driver works in interrupt mode, thus 9823 changes should not matter. I don't have access to your broken HW, so my abilities to experiment for workarounds are severely limited. you may try to play with changing values of ACPI_EC_UDELAY to 500, or even change udelay() back to msleep(1). You also may try to insert udelay() into various places of acpi_ec_transaction_unlocked(), especially after command write. I've a MSI PR200 (also System76 daru2). This laptops have the same Problem. ACPI works only in poll mode. Since kernel 2.6.27.5 the EC starts in interrupt mode automaticly. I'm testing some of the changes Alexey Starikovskiy mentioned. I've changed ACPI_EC_UDELAY to 500 and add some udelay() calls in acpi_ec_transaction_unlocked(). Until now the acpi seems to work better. but i can't say if this works for longer time. Created attachment 20155 [details]
patch for ec.c
i've created a patch. this works for me. you may want to tell me wich of these lines are really needed. I'm compiling... so far working, gimme more observation period - so far so good ;-) 3 days already working superb, I would ask you to put this patch in kernel stream, would you ? I think my patch is just an nasty workaround. Just added various dalays in acpi_ec_transaction_unlocked() but I don't know which of them are really needed. as long as it works properly ... I don't care ;) thanks for your time sir hopefully it will go to stream This patch is not ready for upstream -- it adds several delays for no reason given. Please break this patch into single string patches (as all these modifications are independent) and check, which of them fixes the problem. is there ANY possibility to avoid 9 x compiling and 9 x 3 days observation perdiod ? of course I will do this but this will take me a month to be 100% which one udelay is responsible for doing the job please :-) If you remove them all, you should have your failure pretty soon, it is not 3+ days. So try one string at a time until you get no failure... Compiling of single file does not take long -- it is a matter of minutes... 100->500 us change is first thing to check 4 udelay() under spinlock_irqsave() should be last thing to try -- I don't expect them to fix anything, but they are increasing time of disabled interrupts considerably. hmm, would you tell me how to compile only part of the kernel instead of full ? I'm on archlinux and compiling the kernel fully by means of commands: make prepare make bzImage modules this hint would spare lots of time for me as full compilation takes around 40 min Created attachment 20187 [details]
ec patch
You can test these patch. i removed some of the delays and it seems to work as well. but i tested it just for an hour.
you may skip 'make prepare' Timo, What happens if you try to remove udelay() on line 267? i'll test it the next hours. i think the delay on line 278 could also be removed, but it's hard to say because sometimes the failure doens't appear for hours. just changing the delay time doesn't fix the problem. shall we start this try-and-fail procedure with any order or just "lets remove this or maybe that delay and see" ? Please start with removing all delays from under spinlocked context, e.g. #267 from last patch. Please try to remove as many other delays until it breaks again... I'm testing now with: define ACPI_EC_UDELAY 500 and first 2: udelay(ACPI_EC_UDELAY); so no delay after "spin_lock_irqsave" lets see the results in few days Created attachment 20205 [details]
ec patch 3
could you please try this patch. i removed all but one delay and it seems to work for me.
building... ec3.patch (1 delay) works for me, tested for about 46 minutes. Before this patch, the acpi bug happend after a few minutes. ec3.patch (1 delay) works for me too (already for 10h) but I already experienced that acpi disappeared after 24h so I'd like to suggest to wait 2 more days before closing this bug it is possible to put msleep(1) instead of udelay(500) in this place. and it also should be better. Could you please try it? compiling ;) ok, i changed the ACPI_EC_UDELAY value back to 100 and add instead of a udelay a msleep(1). it looks good, but i think we need some days of testing. without any delay it crashed just at startup, so there is definitly a change. ok, msleep does not work for me - although battery seems ok but AC adapter is very often not recognized which means any power management system is useless pluging in/out AC adapter kills acpid so I revert to patch ec3.patch (1 delay) and here AC adapter works properly Zygfryd: what laptop model do you have? I'm testing on a MSI PR200, for me does msleep work fine. I'll do some more testing over the weekend. MSI GX700 Created attachment 20245 [details]
ec patch 4
full discharging/charging cycle tested on a MSI PR200
ec4.patch (msleep) works for me too, uptime now 1h 41m. Tested on Medion Akoya MD 96652, discharged and charging works fine. lets wait 2 more days guys, mine is ok too, but lets wait as I said in #57: with msleep battery works ok but AC adapter does not report properly - reverting to "ACPI_EC_UDELAY 500" and "+ udelay(ACPI_EC_UDELAY);" fixes this problem immediately Zygfryd: could you please test with ACPI_EC_UDELAY 100 and a udelay(500) in acpi_ec_transaction_unlocked() to show if the ACPI_EC_UDELAY change is really needed. Created attachment 20261 [details]
udelay(500) patch
do you mean this patch ec5.patch ?
yes ec5.patch seems to work properly with AC, let me test longer will see hopefuly it might go to upstream soon ;) ups, not ec5.patch but udelay(500) patch from #65 Hi, ec4.patch works fine for me (pr210). I'm running on kernel 2.6.28.5 with ec4, uptime 1 day. ok, udelay(500) patch from #65 seems to be perfect for both: battery and AC adapter closing ? upstreaming ? :-) Created attachment 20272 [details]
Add 500us delay only for MSI machines.
Please check if this patch works too. It is same 500us delay, but limited to only MSI machines, so if it still works for you there is no need to wait for 2 days...
Thanks.
17:46:48 papio@baboon:/home/install/linux/arch/local-abs/kernel26-2.6.28.5-1-udelay/src/linux-2.6.28$ patch --verbose -Np1 -i ../ec6-msi.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c |index a7bf017..c97aee3 100644 |--- a/drivers/acpi/ec.c |+++ b/drivers/acpi/ec.c -------------------------- Patching file drivers/acpi/ec.c using Plan A... Hunk #1 succeeded at 150 with fuzz 2 (offset 30 lines). Hunk #2 FAILED at 291. Hunk #3 FAILED at 1003. Hunk #4 FAILED at 1016. 3 out of 4 hunks FAILED -- saving rejects to file drivers/acpi/ec.c.rej done hmm, for me it looks like errors :-( Did you apply it to 2.6.28? yes, if I compile 29 my whole system will be at least "disappointed" - last kernel in archlinux is 2.6.28.5 Created attachment 20274 [details]
Add 500us delay only for MSI machines (v2.6.28)
same patch for v.2.6.28
unfortunatelly patch from #75 breaks compilation of kernel both: vanilla 2.6.28 and 2.6.28.5 many errors: -------- drivers/acpi/ec.c: In function ‘acpi_ec_transaction_unlocked’: drivers/acpi/ec.c:290: error: ‘EC_FLAGS_ASUS_MSI’ undeclared (first use in this function) drivers/acpi/ec.c:290: error: (Each undeclared identifier is reported only once drivers/acpi/ec.c:290: error: for each function it appears in.) drivers/acpi/ec.c: In function ‘acpi_ec_ecdt_probe’: drivers/acpi/ec.c:996: error: ‘EC_FLAGS_ASUS_MSI’ undeclared (first use in this function) make[2]: *** [drivers/acpi/ec.o] Error 1 make[1]: *** [drivers/acpi] Error 2 make[1]: *** Waiting for unfinished jobs.... LD sound/built-in.o ------------ and finally failing 'make" after: ------------ CC [M] fs/xfs/support/uuid.o LD [M] fs/xfs/xfs.o LD fs/built-in.o ------------ Created attachment 20275 [details]
patched ec.c with patch from #75
I might be wrong but first you declare: +static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */ and then you say: + if (EC_FLAGS_ASUS_MSI) and IMHO they just don't match (missing 'ASUS' in declaration) but I might be wrong and this also does not match:
+ if (dmi_name_in_vendors("Micro-Star"))
+ EC_FLAGS_ASUS_MSI = 1;
with:
+static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
change the declaration to EC_FLAGS_ASUS_MSI. this will work this is what I'm testing now :-) but actually I removed ASUS from all 3 occurences as it is MSI related - not ASUS Created attachment 20276 [details]
Add 500us delay only for MSI machines (v2.6.28)
Right, was not able to make my mind if I should join ASUS and MSI problems or not... Here is the compilable patch, if you did not get it yet yourself.
ok, compiled, installed the behaviour is exactly the same as in #63 - power manager from KDE does not see that AC has been unplugged so, what now ? Created attachment 20279 [details]
Add 500us delay only for MSI machines (v2.6.28)
Please check if dmesg has this new output "Enabling special treatment for EC from MSI". If not, please send output of dmidecode.
08:23:37 papio@baboon:~$ dmesg | grep MSI
ACPI: EC: Enabling special treatment for EC from MSI.
but again: battery is ok, "acpi -V" shows ok
but some power managers have problems to see if AC is on or off line
08:25:31 papio@baboon:~$ acpi -V
Battery 0: Discharging, 93%, 00:52:45 remaining
Battery 0: design capacity 4400 mAh, last full capacity 2509 mAh = 57%
AC Adapter 0: off-line
Thermal 0: ok, 53.0 degrees C
Cooling 0: Processor 0 of 3
Cooling 1: Processor 0 of 3
Cooling 2: LCD 3 of 6
this might be related to something else (KDE power manager) but, with patch "udelay(500) patch" it is ok, while with both: mslepp and your last patch "Add 500us delay only for MSI machines (v2.6.28)" it shows this AC problems
so, what then ? of course having properly working ACPI is one thing, but why some user space behaves differently ?
more, KDE power manager gets the status of AC (on/off-line) from the boot time - not from the start of KDE itself - and it does not change during the time anymore - even if AC connected/disconnected I know it might be not related but ... Created attachment 20293 [details]
Add 500us delay only for MSI machines (v2.6.28)
It is my fault again, sorry...
ACPI_EC_DELAY is already 500, do not multiply it by 5...
compiling ;) dear Alexyey, it works fine ! thanks It does not work for me! My Gnome power applet switched to red after 10 minutes, acpi in /proc has no longer information about the battery (present: no), although I have a MSI-Corp. board and similar battery model no. ec4.patch works ... latest patch not! Some more information about my system: # cat /proc/acpi/battery/BAT1/info present: yes design capacity: 5200 mAh last full capacity: 5026 mAh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 0 mAh design capacity low: 0 mAh capacity granularity 1: 1 mAh capacity granularity 2: 1 mAh model number: MS-1221 serial number: battery type: LION OEM info: MSI Corp. # uname -a Linux Sa-Matra 2.6.28-gentoo-r2 #2 SMP PREEMPT Wed Feb 18 16:15:07 CET 2009 i686 Intel(R) Core(TM)2 Duo CPU T5450 @ 1.66GHz GenuineIntel GNU/Linux Tom, the only difference between two patches is udelay(500) and udelay(ACPI_EC_DELAY). ACPI_EC_DELAY is 500, so there is no difference -- either both patches don't work, or both do... Alexey, I mean attachment id=20293: You added some flags, which only should apply the delay for MSI machines, yet i don't get a dmesg line like in comment #85 (about enabling EC special treatment). on my MSI GX700 laptop it is: 17:43:14 papio@baboon:~$ sudo dmidecode | grep MSI Manufacturer: MSI 17:43:21 papio@baboon:~$ sudo dmidecode | grep Micro Manufacturer: Micro-Star International 17:43:27 papio@baboon:~$ on my Medion Akoya MD 96652 laptop it is: # dmidecode | grep Manu Manufacturer: Notebook Manufacturer: Notebook Manufacturer: MICRO-STAR INT'L CO.,LTD. Manufacturer: Intel Manufacturer: Manufacturer0 Manufacturer: Manufacturer1 Manufacturer: Manufacturer2 Manufacturer: Manufacturer3 The 2nd manufacturer is in the following section: --- Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Notebook Product Name: SIM2120 Version: 1058 --- Created attachment 20297 [details]
Add 500us delay only for MSI machines (v2.6.28)
I wonder how many different spellings they have?.. Please check if this patch triggers delay for you.
My MSI EX610X with 4 GB 800 MHz DDR2 and 7200/16 SATA is not booting often enough in Intrepid x86_64 due to this bug... As you may guess, I am a Windows-affected person, dancing close to the edge of slipping into Linux waters. And it is soooo tempting! Just to mention, after a days and nights of setting everything proper on my laptop, this has been the only and therefore quite annoying issue! So, I am kindly asking you to direct me (or send link/tutorial) how to apply this patch. My working kernel is most recent from Ubuntu repo 2.6.27.11-generic. I have never compiled a kernel nor applied a patch. And would like to do it without loosing/reseting all adjustments I have made on this laptop so far. Or I can just sit and wait for an official update... Thanks in advance! there is a easy way to get the patch into intrepid. I'm also running ubuntu. take a look at the first post from here: http://ubuntuforums.org/showthread.php?t=1055188&page=3 Hmm ... strange, does not work ... still no line like >> ACPI: EC: Enabling special treatment for EC from MSI. << and after 10 minutes it became "red" again. Do you know, which section the function is looking at? I noticed the following: -- Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: MICRO-STAR INT'L CO.,LTD. -- The other manufacturer are "Notebook", etc; like in Comment #95. I might be wrong but it is not about MSI motherboard but about MSI BIOS which fails with kernel/acpi > So, I am kindly asking you to direct me (or send link/tutorial) how to apply > this patch. start here (2nd option): https://help.ubuntu.com/community/Kernel/Compile to apply patch -- in terminal, go to kernel source top directory and enter: "patch -p1 -i ec_add_delay*patch" follow the rest of the link above. Good luck, Alex. hmm, mine stoped working too:
19:56:12 papio@baboon:~$ acpi -V
AC Adapter 0: off-line
Thermal 0: critical, 144.0 degrees C
Cooling 0: Processor 0 of 3
Cooling 1: Processor 0 of 3
Cooling 2: LCD 3 of 6
19:57:04 papio@baboon:~$ cat /proc/acpi/battery/BAT1/state
present: no
19:57:14 papio@baboon:~$
bugme-daemon@bugzilla.kernel.org wrote: > ------- Comment #99 from twatzke@htwm.de 2009-02-18 09:40 ------- > Hmm ... strange, does not work ... still no line like >>> ACPI: EC: Enabling special treatment for EC from MSI. << > and after 10 minutes it became "red" again. Please attach full dmidecode output from your machine. Created attachment 20302 [details]
full dmidecode output
full dmidecode as requested
Created attachment 20303 [details]
Add 500us delay only for MSI machines (v2.6.28)
Let's check for "Notebook" then too...
Alexey: OK, the patch containing "Notebook" DOES work for me. Thanks, now the line is printed. Let's see, if it works for Zygfryd's too; so it can be closed now. :) don't you think a test for "notebook" goes to far? or are there just msi notebooks using this manufactor key? (In reply to comment #98) > there is a easy way to get the patch into intrepid. I'm also running ubuntu. > take a look at the first post from here: > http://ubuntuforums.org/showthread.php?t=1055188&page=3 > I have done it this way! And it's working as it should! Thanx to Alexey also and rest of you dealing with issues like this one... All the best and keep up the good work! P.S. I'm starting to like very much what I see... This delay is just a delay. Processor does nothing, but eats electricity for half microsecond... hopefully, some interrupt will be serviced during this time and it will not be wasted completely. If OEM does not care to differentiate itself by filling DMI, there is not much we can do. The other way would be to introduce kernel parameter, and then ask every user with such machine to learn how to set it. (In reply to comment #105) > Created an attachment (id=20303) [details] > Add 500us delay only for MSI machines (v2.6.28) > > Let's check for "Notebook" then too... > in my case the problem is that dmesg shows your printout: 23:49:14 papio@baboon:/home$ dmesg | grep MSI ACPI: EC: Enabling special treatment for EC from MSI. but again, battery fails so, what I see in your new patch is to make sure delay occurs but it occurs in my case, just ... does not work in 9h - just stopped working ! Zygfryd: did you do some more tests? for me the patch works fine. maybe change the time of the delay...so 1 microsecond was to much for your notebook, maybe a half microsecond is still to long. you should try udelay(400) or even less. this ACPI problem happened only ones, 2 days ago since then never happened again strange ? UFO ? or what ? ok, i think it's ready for upstream... lets close it then I'd like to see it in upstream where will it go: 29 only or 28 as well ? patch in comment #105 applied to acpi-test 5423a0cb3f74c16e90683f8ee1cec6c240a9556e ACPI: EC: Add delay for slow MSI controller shipped in 2.6.29-rc5-git7 closed. hi, gentoo-2.6.28-r2, notebook msi ex700. kernel patched with last patch (udelau(500);) bug is repeated after 20-24 hours. Hi, do you get a line executing the command: $ dmesg | grep MSI ACPI: EC: Enabling special treatment for EC from MSI. ??? yes, this string is present i am apply patch for 2.6.28 and use prepatched gentoo-2.6.29-rc6-git7 - bug is repeated I increased the delay to 550ms, and wait for the result ..... / sorry for my english for me it happened 2 times since I applied the patch - I cannot say in which conditions so it means I can confirm what is r0mik saying (in 2.6.28 patched) just happened:
11:35:39 root@baboon:/mnt/homebackup/hda3-home# acpi -V
AC Adapter 0: off-line
Thermal 0: critical, 144.0 degrees C
Cooling 0: Processor 0 of 3
Cooling 1: Processor 0 of 3
Cooling 2: LCD 3 of 6
11:48:12 root@baboon:/mnt/homebackup/hda3-home# cat /proc/acpi/battery/BAT1/state
present: no
11:48:21 root@baboon:/mnt/homebackup/hda3-home# cat /proc/acpi/battery/BAT1/info
present: no
and my laptop just stayed connected to AC
hmm, gentoo-2.6.29-rc6-git7, up over 2 day - without bugs (udelau(500)) (In reply to comment #122) > hmm, > gentoo-2.6.29-rc6-git7, up over 2 day - without bugs (udelau(500)) > udelau(550) sorry I changed to 600 and this does not help either:
12:46:59 papio@baboon:~$ acpi -V
AC Adapter 0: off-line
Thermal 0: critical, 144.0 degrees C
Cooling 0: Processor 0 of 3
Cooling 1: Processor 0 of 3
Cooling 2: LCD 3 of 6
12:47:01 papio@baboon:~$
Udelay (550) Works for me for a week with several plug/unplug cycles without any errors yes, kernel from git and udelau(550) works over 4 days.... Created attachment 20809 [details]
merge modes and disable burst
Please check if this patch works on your hardware.
Burst mode should be automatically disabled by controller, if it is not accessed for 400us. Now there is a delay of 500us and some are saying that 550us is even better. Thus, enabling of burst mode in first place seems to be a wrong move.
>Please check if this patch works on your hardware.
tested on a 2.6.29.1 kernel, test failed. After I unplug a power cable, my battery state changed to discharging at 99% capacity (normal), then changed to 100% capacity with charging state (no power cable), then changed to "no apadter present".
Now my battery state changed every 10 second to charging/missing/discharging
550us is rock-stable for me.
model number: MS-1719
And - a 1000us value from vanilla kernel is not stable too
Created attachment 20830 [details]
merge modes and disable burst #2
does this patch work?
Yes, it works for me for one not-full-discharge (up to 30%) to full charge cycle (about 2 hours). Continue testing. Only one note - Unplugging/plugging power cable events recognized with ~10 seconds delay Bad news... Battery "lost" again after 25 minutes of uptime, with no errors in logs Is any new workarounds? Because even udelau (550) hack not too good after closer look. I'm using a XFCE and xfce4-power-manager. Last one have an feature - notifications on battery state changed. And when battery is recharging it sending notifications too often. I've made some observations, and... In a normal state my /proc/acpi/battery/BAT1/state contains present: yes capacity state: ok charging state: charging present rate: 827 mA remaining capacity: 1142 mAh present voltage: 11980 mV When a notification is appeared - it contains present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 1159 mAh present voltage: 11961 mV next moment it contains valid "charging" state again. So, the problem still exist for me. Ad #40: avoiding 9 compiles: Assuming only one udelay is responsible to do the job, you could use a bisection method: Put all udelays in a set of 'possibly responsible udelays' Compile with half the udelays enabled. Test If it works fine: the disabled udelays can be removed from the set else: the enabled udelays can be removed from the set Repeat until the set contains only one udelay Each compile halves the set, so in 4 compile cycles, the responsible udelay is found. Notice, this algorithm relies on the assumption that only one udelay is responsible. If it is a combination of udelays then the algorithm will fail to find the right combination. Last but not least: I am a newbie here. I would like to know whether this comment is helpful or stating the obvious. So far, on my MSI-PR200, the patched kernel works fine. Marten Jan I've been using the patch with udelay(550) on my GX700 laptop for a week and I don't have any acpi problem so far. The battery monitor failed again :( Lasts much more than before to fail though closed due to inactivity for 3 months. please re-open if this is still a problem in 2.6.30.stable Sorry, but problem still exists in 30.5. Symptoms are the same as above. What info Can i provide to help you? I'm not skilled in c programming, but I'll try my best. The problem still exists in 2.6.33 on MSI S271 laptop. My comments in bug 14446. Hi, Can anyone here try the upstream kernel without this quirk. We are about to remove the quirk as it is covered by the following commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9e295ac Thanks in advance. Best regards -Lv |