Bug 12011 - battery status info dissapears in 2.6.27.5 - MSI GX700, EX600 laptops
battery status info dissapears in 2.6.27.5 - MSI GX700, EX600 laptops
Status: CLOSED UNREPRODUCIBLE
Product: ACPI
Classification: Unclassified
Component: EC
All Linux
: P1 high
Assigned To: Alexey Starikovskiy
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-11 10:23 UTC by Zygfryd Homonto
Modified: 2015-05-13 08:25 UTC (History)
14 users (show)

See Also:
Kernel Version: 2.6.27.5
Tree: Mainline
Regression: Yes


Attachments
dmesg.log (35.26 KB, text/x-log)
2008-11-12 04:39 UTC, Zygfryd Homonto
Details
Enable EC region handlers before bus_scan (3.82 KB, patch)
2008-11-12 06:21 UTC, Alexey Starikovskiy
Details | Diff
dmesg.log (35.71 KB, text/x-log)
2008-11-12 08:05 UTC, Zygfryd Homonto
Details
dmesg.log acpi OK (35.36 KB, text/x-log)
2008-11-12 10:50 UTC, Zygfryd Homonto
Details
dmesg.log acpi NOT ok (35.36 KB, text/x-log)
2008-11-12 10:50 UTC, Zygfryd Homonto
Details
dmesg.log acpi NOT ok 2 (35.47 KB, text/x-log)
2008-11-12 11:56 UTC, Zygfryd Homonto
Details
dmesg.log debug on (461.42 KB, text/x-log)
2008-11-13 01:22 UTC, Zygfryd Homonto
Details
patch for ec.c (1.77 KB, text/x-patch)
2009-02-07 09:35 UTC, Timo Tretter
Details
ec patch (1.25 KB, text/x-patch)
2009-02-11 01:49 UTC, Timo Tretter
Details
ec patch 3 (737 bytes, text/x-patch)
2009-02-11 16:45 UTC, Timo Tretter
Details
ec patch 4 (329 bytes, patch)
2009-02-14 12:00 UTC, Timo Tretter
Details | Diff
udelay(500) patch (331 bytes, text/x-patch)
2009-02-16 09:41 UTC, Zygfryd Homonto
Details
Add 500us delay only for MSI machines. (1.71 KB, patch)
2009-02-17 07:36 UTC, Alexey Starikovskiy
Details | Diff
Add 500us delay only for MSI machines (v2.6.28) (1.34 KB, patch)
2009-02-17 08:45 UTC, Alexey Starikovskiy
Details | Diff
patched ec.c with patch from #75 (27.92 KB, text/x-csrc)
2009-02-17 11:31 UTC, Zygfryd Homonto
Details
Add 500us delay only for MSI machines (v2.6.28) (1.33 KB, patch)
2009-02-17 11:50 UTC, Alexey Starikovskiy
Details | Diff
Add 500us delay only for MSI machines (v2.6.28) (1.40 KB, patch)
2009-02-17 13:56 UTC, Alexey Starikovskiy
Details | Diff
Add 500us delay only for MSI machines (v2.6.28) (1.40 KB, patch)
2009-02-17 23:14 UTC, Alexey Starikovskiy
Details | Diff
Add 500us delay only for MSI machines (v2.6.28) (1.44 KB, patch)
2009-02-18 09:04 UTC, Alexey Starikovskiy
Details | Diff
full dmidecode output (9.52 KB, text/plain)
2009-02-18 10:58 UTC, Tom-Steve Watzke
Details
Add 500us delay only for MSI machines (v2.6.28) (1.44 KB, patch)
2009-02-18 11:24 UTC, Alexey Starikovskiy
Details | Diff
merge modes and disable burst (9.53 KB, patch)
2009-04-05 06:59 UTC, Alexey Starikovskiy
Details | Diff
merge modes and disable burst #2 (11.65 KB, patch)
2009-04-06 12:14 UTC, Alexey Starikovskiy
Details | Diff

Description Zygfryd Homonto 2008-11-11 10:23:49 UTC
Latest working kernel version: 2.6.27.4
Earliest failing kernel version: 
Distribution: not related as it is already in http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.5.tar.bz2
Hardware Environment: MSI GX700, EX600 laptops, maybe others from MSI
Software Environment:
Problem Description: battery again is not visible by acpi

Steps to reproduce: install newest kernel 2.6.27.5 and problem is back again

I checked what you have done in patch for 2.6.26 (patch: http://bugzilla.kernel.org/show_bug.cgi?id=9823#c53 http://bugzilla.kernel.org/attachment.cgi?id=17174&action=view ) and it was working ok as patch for 2.6.26 as well as early 2.6.27 kernels
but since 2.6.27.5 this DISAPPEARED from ec.c !!!

it was:
static int acpi_ec_wait(struct acpi_ec *ec, enum ec_event event, int force_poll)
{
	atomic_set(&ec->irq_count, 0);
	if (likely(test_bit(EC_FLAGS_GPE_MODE, &ec->flags)) &&
	    likely(!force_poll)) {
		if (wait_event_timeout(ec->wait, acpi_ec_check_status(ec, event),
				       msecs_to_jiffies(ACPI_EC_DELAY)))
			return 0;
		clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
		if (acpi_ec_check_status(ec, event)) {
			/* missing GPEs, switch back to poll mode */
			if (printk_ratelimit())
				pr_info(PREFIX "missing confirmations, "
						"switch off interrupt mode.\n");
			ec_switch_to_poll_mode(ec);
			ec_schedule_ec_poll(ec);
			return 0;
		}
	} else {
		unsigned long delay = jiffies + msecs_to_jiffies(ACPI_EC_DELAY);
		clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
		while (time_before(jiffies, delay)) {
			if (acpi_ec_check_status(ec, event))
				return 0;
			msleep(1);
		}
		if (acpi_ec_check_status(ec,event))
			return 0;
	}
	pr_err(PREFIX "acpi_ec_wait timeout, status = 0x%2.2x, event = %s\n",
		acpi_ec_read_status(ec),
		(event == ACPI_EC_EVENT_OBF_1) ? "\"b0=1\"" : "\"b1=0\"");
	return -ETIME;
}

now it is: 


static int acpi_ec_wait(struct acpi_ec *ec)
{
	if (wait_event_timeout(ec->wait, ec_transaction_done(ec),
			       msecs_to_jiffies(ACPI_EC_DELAY)))
		return 0;
	/* missing GPEs, switch back to poll mode */
	if (printk_ratelimit())
		pr_info(PREFIX "missing confirmations, "
				"switch off interrupt mode.\n");
	set_bit(EC_FLAGS_NO_GPE, &ec->flags);
	clear_bit(EC_FLAGS_GPE_MODE, &ec->flags);
	return 1;
}


I'm not developer, but it BREAKS my acpi events: 
2.6.27.5:
cat /proc/acpi/battery/BAT1/info  
present:                 no 


while with 2.6.27.4:
cat /proc/acpi/battery/BAT1/info 
present:                 yes
design capacity:         4400 mAh
last full capacity:      3201 mAh
battery technology:      rechargeable
design voltage:          10800 mV
design capacity warning: 0 mAh
design capacity low:     0 mAh
capacity granularity 1:  1 mAh
capacity granularity 2:  1 mAh
model number:            MS-1719

serial number:           

battery type:            LION

OEM info:                MSI Corp.

shit, I was waiting almost 1 year to see my battery properly working under Linux and few days ago problem came back ;-(
Comment 1 Alexey Starikovskiy 2008-11-11 12:19:39 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?
Comment 2 Zygfryd Homonto 2008-11-11 22:20:10 UTC
(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 ?
Comment 3 Alexey Starikovskiy 2008-11-11 22:43:39 UTC
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.
Comment 4 Zygfryd Homonto 2008-11-12 04:39:04 UTC
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
Comment 5 Alexey Starikovskiy 2008-11-12 06:21:48 UTC
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.
Comment 6 Zygfryd Homonto 2008-11-12 06:40:47 UTC
(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 ?
Comment 7 Alexey Starikovskiy 2008-11-12 08:01:34 UTC
right.
Comment 8 Zygfryd Homonto 2008-11-12 08:05:35 UTC
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:~$
Comment 9 Alexey Starikovskiy 2008-11-12 08:51:36 UTC
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.
Comment 10 Zygfryd Homonto 2008-11-12 09:26:47 UTC
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
Comment 11 Alexey Starikovskiy 2008-11-12 09:38:52 UTC
sensors and hwmon are essentially same thing, in kernel they are named "hwmon subsystem", in userspace there is lm_sensors project.
Comment 12 Zygfryd Homonto 2008-11-12 09:47:05 UTC
(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... ;)
Comment 13 Alexey Starikovskiy 2008-11-12 10:02:55 UTC
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 :)
Comment 14 Zygfryd Homonto 2008-11-12 10:21:36 UTC
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 !
Comment 15 Alexey Starikovskiy 2008-11-12 10:36:09 UTC
please provide dmesg before and after error.
Comment 16 Zygfryd Homonto 2008-11-12 10:50:09 UTC
Created attachment 18826 [details]
dmesg.log acpi OK
Comment 17 Zygfryd Homonto 2008-11-12 10:50:41 UTC
Created attachment 18827 [details]
dmesg.log acpi NOT ok
Comment 18 Alexey Starikovskiy 2008-11-12 11:23:35 UTC
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.

Comment 19 Zygfryd Homonto 2008-11-12 11:56:41 UTC
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:~$
Comment 20 Alexey Starikovskiy 2008-11-12 12:09:44 UTC
please uncomment #define DEBUG at /drivers/acpi/ec.c and do dmesg again -- might be in this case we see something. 
Comment 21 Zygfryd Homonto 2008-11-13 01:22:26 UTC
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$
Comment 22 Alexey Starikovskiy 2008-11-13 12:42:17 UTC
Zygryd,
please check if limit ACPI_EC_STORM_THRESHOLD to 1 helps.
Comment 23 Cenk Limni 2008-12-16 03:59:04 UTC
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
Comment 24 Vojtech Gondzala 2009-01-04 04:49:35 UTC
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.

Comment 25 Leonid Podolny 2009-01-09 09:33:58 UTC
(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.
Comment 26 Zygfryd Homonto 2009-01-09 11:10:41 UTC
I'm testing ACPI_EC_STORM_THRESHOLD=1 as well 
so far so good
lets see it later
Comment 27 Zygfryd Homonto 2009-01-09 22:14:51 UTC
not WORKING !, even with ACPI_EC_STORM_THRESHOLD=1

# acpi -V
     Thermal 1: ok, 144.0 degrees C
  AC Adapter 1: off-line
Comment 28 Leonid Podolny 2009-01-10 10:44:20 UTC
Same here, it took a while, but it dissapeared again.
Comment 29 Zygfryd Homonto 2009-01-18 19:30:21 UTC
is there ANY hope ACPI will work perfect as in 2.6.27-5 and earliers ?
Comment 30 Alexey Starikovskiy 2009-01-19 02:21:08 UTC
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.
Comment 31 Timo Tretter 2009-02-05 04:45:58 UTC
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.
Comment 32 Timo Tretter 2009-02-07 09:35:49 UTC
Created attachment 20155 [details]
patch for ec.c
Comment 33 Timo Tretter 2009-02-07 09:38:36 UTC
i've created a patch. this works for me.
you may want to tell me wich of these lines are really needed.
Comment 34 Zygfryd Homonto 2009-02-07 12:41:59 UTC
I'm compiling...
Comment 35 Zygfryd Homonto 2009-02-09 03:06:34 UTC
so far working, gimme more observation period - so far so good ;-)
Comment 36 Zygfryd Homonto 2009-02-10 10:50:01 UTC
3 days already working superb, I would ask you to put this patch in kernel stream, would you ?
Comment 37 Timo Tretter 2009-02-10 12:07:34 UTC
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.
Comment 38 Zygfryd Homonto 2009-02-10 12:11:18 UTC
as long as it works properly ... I don't care ;)
thanks for your time sir
hopefully it will go to stream
Comment 39 Alexey Starikovskiy 2009-02-10 13:56:23 UTC
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.
Comment 40 Zygfryd Homonto 2009-02-10 20:02:53 UTC
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 :-)
Comment 41 Alexey Starikovskiy 2009-02-10 23:49:17 UTC
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.


Comment 42 Zygfryd Homonto 2009-02-11 01:49:01 UTC
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

Comment 43 Timo Tretter 2009-02-11 01:49:06 UTC
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.
Comment 44 Alexey Starikovskiy 2009-02-11 01:54:31 UTC
you may skip 'make prepare' 
Comment 45 Alexey Starikovskiy 2009-02-11 01:56:09 UTC
Timo,
What happens if you try to remove udelay() on line 267?
Comment 46 Timo Tretter 2009-02-11 02:25:03 UTC
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.
Comment 47 Zygfryd Homonto 2009-02-11 03:21:19 UTC
shall we start this try-and-fail procedure with any order or just "lets remove this or maybe that delay and see" ? 
Comment 48 Alexey Starikovskiy 2009-02-11 03:30:40 UTC
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...
Comment 49 Zygfryd Homonto 2009-02-11 06:03:17 UTC
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
Comment 50 Timo Tretter 2009-02-11 16:45:25 UTC
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.
Comment 51 Zygfryd Homonto 2009-02-11 19:55:22 UTC
building...
Comment 52 Tom-Steve Watzke 2009-02-12 06:12:53 UTC
ec3.patch (1 delay) works for me, tested for about 46 minutes. Before this patch, the acpi bug happend after a few minutes.
Comment 53 Zygfryd Homonto 2009-02-12 07:35:29 UTC
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
Comment 54 Alexey Starikovskiy 2009-02-12 08:59:50 UTC
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?
Comment 55 Zygfryd Homonto 2009-02-12 10:19:09 UTC
compiling ;)
Comment 56 Timo Tretter 2009-02-12 11:32:57 UTC
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.
Comment 57 Zygfryd Homonto 2009-02-12 18:56:40 UTC
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
Comment 58 Timo Tretter 2009-02-13 09:58:07 UTC
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.
Comment 59 Zygfryd Homonto 2009-02-13 10:01:00 UTC
MSI GX700
Comment 60 Timo Tretter 2009-02-14 12:00:33 UTC
Created attachment 20245 [details]
ec patch 4

full discharging/charging cycle tested on a MSI PR200
Comment 61 Tom-Steve Watzke 2009-02-16 02:01:20 UTC
ec4.patch (msleep)  works for me too, uptime now 1h 41m.
Tested on Medion Akoya MD 96652, discharged and charging works fine.
Comment 62 Zygfryd Homonto 2009-02-16 02:13:10 UTC
lets wait 2 more days guys, mine is ok too, but lets wait
Comment 63 Zygfryd Homonto 2009-02-16 08:16:50 UTC
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
Comment 64 Timo Tretter 2009-02-16 09:29:54 UTC
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.
Comment 65 Zygfryd Homonto 2009-02-16 09:41:10 UTC
Created attachment 20261 [details]
udelay(500) patch

do you mean this patch ec5.patch ?
Comment 66 Timo Tretter 2009-02-16 09:42:58 UTC
yes
Comment 67 Zygfryd Homonto 2009-02-16 11:37:47 UTC
ec5.patch seems to work properly with AC, let me test longer will see
hopefuly it might go to upstream soon ;)
Comment 68 Zygfryd Homonto 2009-02-16 11:38:45 UTC
ups, not ec5.patch but udelay(500) patch from #65
Comment 69 Vojtech Gondzala 2009-02-16 13:50:13 UTC
Hi, ec4.patch works fine for me (pr210). I'm running on kernel 2.6.28.5 with ec4, uptime 1 day.
Comment 70 Zygfryd Homonto 2009-02-17 02:43:03 UTC
ok, udelay(500) patch from #65 seems to be perfect for both: battery and AC adapter
closing ? upstreaming ? :-)
Comment 71 Alexey Starikovskiy 2009-02-17 07:36:28 UTC
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.
Comment 72 Zygfryd Homonto 2009-02-17 07:48:13 UTC
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 :-(
Comment 73 Alexey Starikovskiy 2009-02-17 08:06:27 UTC
Did you apply it to 2.6.28?
Comment 74 Zygfryd Homonto 2009-02-17 08:18:00 UTC
yes, if I compile 29 my whole system will be at least "disappointed"  - last kernel in archlinux is 2.6.28.5
Comment 75 Alexey Starikovskiy 2009-02-17 08:45:30 UTC
Created attachment 20274 [details]
Add 500us delay only for MSI machines (v2.6.28)

same patch for v.2.6.28
Comment 76 Zygfryd Homonto 2009-02-17 11:28:32 UTC
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
------------
Comment 77 Zygfryd Homonto 2009-02-17 11:31:37 UTC
Created attachment 20275 [details]
patched ec.c with patch from #75
Comment 78 Zygfryd Homonto 2009-02-17 11:35:36 UTC
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 
Comment 79 Zygfryd Homonto 2009-02-17 11:44:24 UTC
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 */

Comment 80 Timo Tretter 2009-02-17 11:45:36 UTC
change the declaration to EC_FLAGS_ASUS_MSI. this will work
Comment 81 Zygfryd Homonto 2009-02-17 11:49:21 UTC
this is what I'm testing now :-)
but actually I removed ASUS from all 3 occurences as it is MSI related - not ASUS 
Comment 82 Alexey Starikovskiy 2009-02-17 11:50:12 UTC
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.
Comment 83 Zygfryd Homonto 2009-02-17 13:16:40 UTC
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 ?
Comment 84 Alexey Starikovskiy 2009-02-17 13:56:01 UTC
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.
Comment 85 Zygfryd Homonto 2009-02-17 22:32:34 UTC
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 ?
Comment 86 Zygfryd Homonto 2009-02-17 22:51:41 UTC
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 ...
Comment 87 Alexey Starikovskiy 2009-02-17 23:14:41 UTC
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...
Comment 88 Zygfryd Homonto 2009-02-17 23:49:23 UTC
compiling ;)
Comment 89 Zygfryd Homonto 2009-02-18 00:49:15 UTC
dear Alexyey, it works fine !
thanks
Comment 90 Tom-Steve Watzke 2009-02-18 07:12:30 UTC
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.
Comment 91 Tom-Steve Watzke 2009-02-18 07:27:08 UTC
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
Comment 92 Alexey Starikovskiy 2009-02-18 07:30:01 UTC
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...
Comment 93 Tom-Steve Watzke 2009-02-18 07:40:41 UTC
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).
Comment 94 Zygfryd Homonto 2009-02-18 07:43:44 UTC
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:~$ 
Comment 95 Tom-Steve Watzke 2009-02-18 07:52:56 UTC
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
---
Comment 96 Alexey Starikovskiy 2009-02-18 09:04:48 UTC
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.
Comment 97 Marko Vukicevic 2009-02-18 09:34:34 UTC
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!
Comment 98 Timo Tretter 2009-02-18 09:39:26 UTC
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
Comment 99 Tom-Steve Watzke 2009-02-18 09:40:09 UTC
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.
Comment 100 Zygfryd Homonto 2009-02-18 09:42:20 UTC
I might be wrong but it is not about MSI motherboard but about MSI BIOS which fails with kernel/acpi
Comment 101 Alexey Starikovskiy 2009-02-18 09:44:56 UTC
> 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.

Comment 102 Zygfryd Homonto 2009-02-18 09:57:28 UTC
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:~$ 
Comment 103 Alexey Starikovskiy 2009-02-18 10:01:01 UTC
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.

Comment 104 Tom-Steve Watzke 2009-02-18 10:58:49 UTC
Created attachment 20302 [details]
full dmidecode output

full dmidecode as requested
Comment 105 Alexey Starikovskiy 2009-02-18 11:24:46 UTC
Created attachment 20303 [details]
Add 500us delay only for MSI machines (v2.6.28)

Let's check for "Notebook" then too...
Comment 106 Tom-Steve Watzke 2009-02-18 11:59:39 UTC
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. :)
Comment 107 Timo Tretter 2009-02-18 12:00:35 UTC
don't you think a test for "notebook" goes to far? or are there just msi notebooks using this manufactor key?
Comment 108 Marko Vukicevic 2009-02-18 12:17:10 UTC
(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... 
Comment 109 Alexey Starikovskiy 2009-02-18 12:47:09 UTC
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.
Comment 110 Zygfryd Homonto 2009-02-18 13:53:26 UTC
(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 !
Comment 111 Timo Tretter 2009-02-20 11:07:01 UTC
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.
Comment 112 Zygfryd Homonto 2009-02-20 11:19:25 UTC
this ACPI problem happened only ones, 2 days ago
since then never happened again
strange ? UFO ? or what ?
Comment 113 Timo Tretter 2009-02-20 12:02:18 UTC
ok, i think it's ready for upstream...
Comment 114 Zygfryd Homonto 2009-02-20 12:04:42 UTC
lets close it then
I'd like to see it in upstream
where will it go: 29 only or 28 as well ?
Comment 115 Len Brown 2009-02-21 09:18:44 UTC
patch in comment #105 applied to acpi-test
Comment 116 Len Brown 2009-02-22 17:46:40 UTC
5423a0cb3f74c16e90683f8ee1cec6c240a9556e
ACPI: EC: Add delay for slow MSI controller

shipped in 2.6.29-rc5-git7

closed.
Comment 117 r0mik 2009-03-03 08:15:28 UTC
hi,
gentoo-2.6.28-r2, notebook msi ex700. kernel patched with last patch (udelau(500);)
bug is repeated after 20-24 hours.

Comment 118 Tom-Steve Watzke 2009-03-04 10:14:14 UTC
Hi, do you get a line executing the command:
$ dmesg | grep MSI
ACPI: EC: Enabling special treatment for EC from MSI.

???
Comment 119 r0mik 2009-03-04 11:43:15 UTC
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
Comment 120 Zygfryd Homonto 2009-03-04 11:52:25 UTC
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)
Comment 121 Zygfryd Homonto 2009-03-05 01:50:49 UTC
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
Comment 122 r0mik 2009-03-06 21:03:27 UTC
hmm,
gentoo-2.6.29-rc6-git7, up over 2 day - without bugs (udelau(500))
Comment 123 r0mik 2009-03-06 21:06:11 UTC
(In reply to comment #122)
> hmm,
> gentoo-2.6.29-rc6-git7, up over 2 day - without bugs (udelau(500))
> 

udelau(550)
sorry
Comment 124 Zygfryd Homonto 2009-03-08 03:47:07 UTC
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:~$ 
Comment 125 Unnamed_Hero 2009-03-12 02:03:20 UTC
Udelay (550)
Works for me for a week with several plug/unplug cycles without any errors
Comment 126 r0mik 2009-03-12 02:09:03 UTC
yes,
kernel from git and udelau(550) works over 4 days....
Comment 127 Alexey Starikovskiy 2009-04-05 06:59:10 UTC
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.
Comment 128 Unnamed_Hero 2009-04-06 05:41:36 UTC
>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
Comment 129 Alexey Starikovskiy 2009-04-06 12:14:32 UTC
Created attachment 20830 [details]
merge modes and disable burst #2

does this patch work?
Comment 130 Unnamed_Hero 2009-04-06 14:47:54 UTC
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
Comment 131 Unnamed_Hero 2009-04-07 06:43:29 UTC
Bad news... Battery "lost" again after 25 minutes of uptime, with no errors in logs
Comment 132 Unnamed_Hero 2009-05-03 05:06:16 UTC
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.
Comment 133 Marten Jan 2009-05-03 10:49:53 UTC
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
Comment 134 Andreu Montiel 2009-05-12 06:32:50 UTC
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.
Comment 135 Andreu Montiel 2009-05-14 15:25:02 UTC
The battery monitor failed again :( Lasts much more than before to fail though
Comment 136 Len Brown 2009-08-13 03:16:16 UTC
closed due to inactivity for 3 months.
please re-open if this is still a problem in 2.6.30.stable
Comment 137 Unnamed_Hero 2009-08-29 18:57:33 UTC
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.
Comment 138 Mihail Kasadjikov 2010-03-05 14:00:01 UTC
The problem still exists in 2.6.33 on MSI S271 laptop.
My comments in bug 14446.
Comment 139 Lv Zheng 2015-05-13 08:25:58 UTC
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

Note You need to log in before you can comment on or make changes to this bug.