Bug 12641 - no EC events unless acpi_osi="!Windows 2006"... - Toshiba Satellite L355
no EC events unless acpi_osi="!Windows 2006"... - Toshiba Satellite L355
Status: CLOSED PATCH_ALREADY_AVAILABLE
Product: ACPI
Classification: Unclassified
Component: EC
All Linux
: P1 normal
Assigned To: Alexey Starikovskiy
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-06 09:53 UTC by Adam Pigg
Modified: 2010-10-05 04:52 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.29rc3
Tree: Mainline
Regression: Yes


Attachments
output of lspci -vxxx (27.51 KB, text/plain)
2009-02-06 09:54 UTC, Adam Pigg
Details
output of grep . /sys/firmware/acpi/interrupts/* before unplug (2.08 KB, text/plain)
2009-02-06 09:55 UTC, Adam Pigg
Details
Output from dmidecode (9.05 KB, text/plain)
2009-02-06 09:56 UTC, Adam Pigg
Details
Outout from acpidump (151.67 KB, text/plain)
2009-02-06 09:59 UTC, Adam Pigg
Details
dmesg (35.56 KB, text/plain)
2009-02-09 12:31 UTC, Adam Pigg
Details
contents of /sys/firmware/acpi/interrupts/* with power plugged in (2.08 KB, text/plain)
2009-02-23 10:13 UTC, Adam Pigg
Details
contents of /sys/firmware/acpi/interrupts/* with power not plugged in (2.08 KB, text/plain)
2009-02-23 10:14 UTC, Adam Pigg
Details
dsdt file (298.61 KB, text/x-dsl)
2009-02-24 14:20 UTC, Adam Pigg
Details
acpi devices as windows sees them (82.86 KB, image/png)
2009-03-07 01:47 UTC, Adam Pigg
Details
interrupts before sleep with no ac plugged in (2.08 KB, text/plain)
2009-03-16 09:54 UTC, Adam Pigg
Details
interrupts before sleep with ac plugged in (2.08 KB, text/plain)
2009-03-16 09:55 UTC, Adam Pigg
Details
lspci before sleep (627 bytes, text/plain)
2009-03-16 09:55 UTC, Adam Pigg
Details
interrupts after sleep with ac plugged in (2.08 KB, text/plain)
2009-03-16 09:56 UTC, Adam Pigg
Details
interrupts after sleep with no ac plugged in (2.08 KB, text/plain)
2009-03-16 09:56 UTC, Adam Pigg
Details
lspci after sleep (627 bytes, text/plain)
2009-03-16 09:57 UTC, Adam Pigg
Details
correct lspci before sleep (1.24 KB, text/plain)
2009-03-17 01:48 UTC, Adam Pigg
Details
correct lscpi after sleep....yes theres a difference now! (1.24 KB, text/plain)
2009-03-17 01:49 UTC, Adam Pigg
Details
comment out switch to interrupt mode (541 bytes, patch)
2009-09-16 17:16 UTC, Alexey Starikovskiy
Details | Diff
dmesg (35.42 KB, text/plain)
2009-09-16 18:53 UTC, Adam Pigg
Details
Quirk to enable OSI(Linux) on Satellite L355 (901 bytes, patch)
2009-10-05 22:39 UTC, Alexey Starikovskiy
Details | Diff
Quirk to disable OSI Vista compatiblity (895 bytes, patch)
2010-09-28 21:54 UTC, Len Brown
Details | Diff

Description Adam Pigg 2009-02-06 09:53:39 UTC
Latest working kernel version: Unknown
Earliest failing kernel version: Unknown
Distribution: Mandriva
Hardware Environment: Toshiba Satellite L355
Software Environment: Mandriva Cooker
Problem Description: 
/proc/acpi/ac_adapter/.../state always show the correct state, but 
acpi_listen and lshal --monitor dont see any un/plug events.

Steps to reproduce: Un/plug ac adapter while running acpi_listen
Comment 1 Adam Pigg 2009-02-06 09:54:38 UTC
Created attachment 20132 [details]
output of lspci -vxxx
Comment 2 Adam Pigg 2009-02-06 09:55:57 UTC
Created attachment 20133 [details]
output of grep . /sys/firmware/acpi/interrupts/* before unplug

No point adding the one for after as it is identical
Comment 3 Adam Pigg 2009-02-06 09:56:25 UTC
Created attachment 20134 [details]
Output from dmidecode
Comment 4 Adam Pigg 2009-02-06 09:59:28 UTC
Created attachment 20135 [details]
Outout from acpidump
Comment 5 Zhang Rui 2009-02-08 17:51:10 UTC
hmmm,
you mean /sys/firmware/acpi/interrupts/* don't change after un/plugging the AC adapter?
so "cat /proc/interrupts | grep acpi" also doesn't change, right?
if there is no ACPI interrupt when un/plugging the ACPI adapter, I'm afraid there is nothing we can do here. maybe this is related to the BIOS settings?
Comment 6 ykzhao 2009-02-08 19:00:24 UTC
HI, Adam
    The AC notification event is sent in the acpi _Q13/_Q19 object by ACPI EC device. 
    Maybe this is related with the EC.
    Will you please attach the output of dmesg?
    Thanks.
    
    
Comment 7 ykzhao 2009-02-08 19:31:06 UTC
From the info in http://marc.info/?l=linux-acpi&m=123394625804038&w=2
  it seems that there exists the following message:
   >ACPI: EC: GPE storm detected, transactions will use polling mode
   >ACPI: EC: missing confirmations, switch off interrupt mode.

   And the ac notification event is sent in the ACPI _Q13/_Q19 object of ACPI EC device. Maybe it is related with EC.

Hi, Rui
    How about assign this bug to EC category?
    thanks.
   
    
   
Comment 8 Adam Pigg 2009-02-09 12:30:27 UTC
Inbetween these there was an unplug, a plug, and again.

[piggz@localhost ~]$ cat /proc/interrupts | grep acpi
  9:         99        100   IO-APIC-fasteoi   acpi
[piggz@localhost ~]$ cat /proc/interrupts | grep acpi
  9:         99        100   IO-APIC-fasteoi   acpi
[piggz@localhost ~]$ cat /proc/interrupts | grep acpi
  9:         99        100   IO-APIC-fasteoi   acpi
[piggz@localhost ~]$ cat /proc/interrupts | grep acpi
  9:         99        100   IO-APIC-fasteoi   acpi
Comment 9 Adam Pigg 2009-02-09 12:31:03 UTC
Created attachment 20171 [details]
dmesg
Comment 10 Zhang Rui 2009-02-23 00:28:58 UTC
hi, adam,
please attach the output of "grep . /sys/firmware/acpi/interrupts/*" when you do the test in comment #8.
I need to make sure that ec GPE is disabled at that time.
Comment 11 Adam Pigg 2009-02-23 10:13:27 UTC
Created attachment 20328 [details]
contents of /sys/firmware/acpi/interrupts/* with power plugged in
Comment 12 Adam Pigg 2009-02-23 10:14:11 UTC
Created attachment 20329 [details]
contents of /sys/firmware/acpi/interrupts/* with power not plugged in

its the same as the plugged in version
Comment 13 Zhang Rui 2009-02-23 17:33:31 UTC
well.
there is no ACPI interrupt when un/plugging the AC adapter,
so surely we can not get an ACPI event.
and it seems that this is what it's designed to be.
I guess you can not get this ACPI event on any distribution/kernel version, right?

It would be interesting to know how it works in windows, or else I have to close this because it doesn't look like a software "bug".
Comment 14 Adam Pigg 2009-02-24 13:41:24 UTC
I'd swear that i actually saw it working once (and only once)  i remember seeing the battery monitor in kde change state as i un/plugged the ac.  I remember thinking 'oh, a kernel update must have fixed it' but when i rebooted it didnt work.  So, i dont know.  How does /proc/acpi/ac_adapter.../state get the correct state?

Is there anything i could do in windows maybe to help...surely it works there.
Comment 15 Adam Pigg 2009-02-24 13:54:34 UTC
I found this thread suggesting a buggy dsdt.
http://bbs.archlinux.org/viewtopic.php?id=65004
Comment 16 Adam Pigg 2009-02-24 14:19:23 UTC
I dont know if it means anything bad, but i get these error compiling the dsdt
/home/piggz/dsdt.dsl  2888:             Method (_OSC, 5, NotSerialized)
Warning  1075 -                                    ^ Reserved method has too many arguments (_OSC requires 4)

/home/piggz/dsdt.dsl  2904:                             And (CAPB, 0xFFFFFFFC)
Warning  1104 -      Result is not used, operator has no effect ^

Are these messages anything to worry about?
ACPI: EC: Look up EC in DSDT
ACPI: BIOS _OSI(Linux) query ignored
ACPI: EC: non-query interrupt received, switching to interrupt mode
ACPI: EC: GPE storm detected, transactions will use polling mode
ACPI: EC: missing confirmations, switch off interrupt mode.
ACPI: Interpreter enabled
Comment 17 Adam Pigg 2009-02-24 14:20:37 UTC
Created attachment 20354 [details]
dsdt file
Comment 18 Zhang Rui 2009-02-24 17:05:22 UTC
(In reply to comment #14)
> How does /proc/acpi/ac_adapter.../state get
> the correct state?
> 
because an ACPI method (_PSR) is always reflecting the actual ac status.
when you read it, ACPI ac driver invokes this ACPI method, and get the correct AC status.
But un/plugging AC adapter is another story, when you un/plug the AC adapter, OS doesn't receive a notification, which is usually an ACPI interrupt. So the HAL doesn't know this change, and it won't invoke the _PSR to get the new AC status.

Comment 19 Zhang Rui 2009-02-24 17:10:01 UTC
have you ever tried any earlier kernel releases?
there are a lot of ec changes recently.
please try kernel 2.6.25/26/27/28 to see if any of these kernels work for you.
Comment 20 Adam Pigg 2009-02-25 01:09:29 UTC
Ive tried .28 and .22, neither worked.  I can try some others tonight.  What do you think about rebuilding the dsdt? pointless?
Comment 21 Zhang Rui 2009-02-25 01:20:04 UTC
it doesn't help

the most important is to see if there is any kernel which can export an ACPI interrupt when un/plugging the AC adapter.
Comment 22 Adam Pigg 2009-03-07 01:46:55 UTC
Ive managed to install windows xp on a usb external hard disk to see if it works ok there, and it does.  Using all standard drivers from windows, nothing from toshiba required.  The battery icon in the systray appears/disappears when plugged/unplugged.
Comment 23 Adam Pigg 2009-03-07 01:47:51 UTC
Created attachment 20450 [details]
acpi devices as windows sees them
Comment 24 Adam Pigg 2009-03-07 01:48:50 UTC
is there anything i could do in windows to help debug?
Comment 25 Adam Pigg 2009-03-07 08:21:26 UTC
I found a working kernel!!
kernel-linus-2.6.27-0.rc8.3.1mdv
from mandriva 2009.0.  I assume the final 2.6.27 is ok, but i dont have any packages for that.

Both lshal --monitor and acpi_listen show the ac adapter being un/plugged.
Comment 26 Adam Pigg 2009-03-15 15:45:45 UTC
Ive just observed it working in a 2.6.29rc kernel aswell.  Not on startup though.  It started to work after being put to sleep/woken up.  That must help!! :)
Comment 27 Zhang Rui 2009-03-15 18:58:25 UTC
so the ACPI interrupts/GPE0x17 increase when you re-do the test in comment #8/#10, right?

(In reply to comment #26)
> Ive just observed it working in a 2.6.29rc kernel as well.  Not on startup
> though.  It started to work after being put to sleep/woken up.  That must
> help!! :)
> 
Great work! Adam.
it starts to work after a suspend-to-memory cycle, right?
this is only true for 2.6.29-rc kernel, or for all the kernel you've tested, say 2.6.28?

In 2.6.29-rc, please attach the output of "lspci -vvxxx -s 00:1f.0" both before and after the s3..
Comment 28 Adam Pigg 2009-03-16 09:54:45 UTC
Created attachment 20547 [details]
interrupts before sleep with no ac plugged in
Comment 29 Adam Pigg 2009-03-16 09:55:17 UTC
Created attachment 20548 [details]
interrupts before sleep with ac plugged in
Comment 30 Adam Pigg 2009-03-16 09:55:44 UTC
Created attachment 20549 [details]
lspci before sleep
Comment 31 Adam Pigg 2009-03-16 09:56:12 UTC
Created attachment 20550 [details]
interrupts after sleep with ac plugged in
Comment 32 Adam Pigg 2009-03-16 09:56:38 UTC
Created attachment 20551 [details]
interrupts after sleep with no ac plugged in
Comment 33 Adam Pigg 2009-03-16 09:57:01 UTC
Created attachment 20552 [details]
lspci after sleep
Comment 34 Zhang Rui 2009-03-17 00:25:52 UTC
sorry, you need to use "lspci -vvxxx -s 00:1f.0" instead of "lspci -vvxx -s 00:1f.0"
Comment 35 Adam Pigg 2009-03-17 01:48:59 UTC
Created attachment 20563 [details]
correct lspci before sleep
Comment 36 Adam Pigg 2009-03-17 01:49:29 UTC
Created attachment 20564 [details]
correct lscpi after sleep....yes theres a difference now!
Comment 37 Zhang Rui 2009-03-17 02:21:17 UTC
what if you run "setpci -s 00:1f.0 0xa0.w=0x0a00" before suspend and un/plug the AC?

the problem doesn't exist after a suspend-to-memory cycle, right?
is this only true for 2.6.29-rc kernel, or for all the kernel you've tested,
say 2.6.28?
Comment 38 Anonymous Emailer 2009-03-17 02:49:40 UTC
Reply-To: piggz1@gmail.com

Do you mean to run that command to see if it fixes it without having to do a
suspend/resume?

After a suspend-to-mem cycle, all battery monitoring works fine, lshal
--monitor, and the kde4 battery applet both detect and react to the ac being
un/plugged.

Im having trouble finding a binary 2.6.28....i'll probably have to build
from src to test it.

I'll be able to try it later, im away from the machine atm.

On Tue, Mar 17, 2009 at 9:21 AM, <bugme-daemon@bugzilla.kernel.org> wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=12641
>
>
>
>
>
> ------- Comment #37 from rui.zhang@intel.com  2009-03-17 02:21 -------
> what if you run "setpci -s 00:1f.0 0xa0.w=0x0a00" before suspend and
> un/plug
> the AC?
>
> the problem doesn't exist after a suspend-to-memory cycle, right?
> is this only true for 2.6.29-rc kernel, or for all the kernel you've
> tested,
> say 2.6.28?
>
>
> --
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
Do you mean to run that command to see if it fixes it without having to do a suspend/resume?<br><br>After a suspend-to-mem cycle, all battery monitoring works fine, lshal --monitor, and the kde4 battery applet both detect and react to the ac being un/plugged.<br>
<br>Im having trouble finding a binary 2.6.28....i&#39;ll probably have to build from src to test it.<br><br>I&#39;ll be able to try it later, im away from the machine atm.<br><br><div class="gmail_quote">On Tue, Mar 17, 2009 at 9:21 AM,  <span dir="ltr">&lt;<a href="mailto:bugme-daemon@bugzilla.kernel.org">bugme-daemon@bugzilla.kernel.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><a href="http://bugzilla.kernel.org/show_bug.cgi?id=12641" target="_blank">http://bugzilla.kernel.org/show_bug.cgi?id=12641</a><br>

<br>
<br>
<br>
<br>
<br>
</div>------- Comment #37 from <a href="mailto:rui.zhang@intel.com">rui.zhang@intel.com</a> 
Comment 39 Adam Pigg 2009-03-17 04:04:24 UTC
I tried that command on a fresh boot and nothing seems to have happened, gpe17 remains constant
Comment 40 showard314 2009-05-20 23:41:22 UTC
Hi,

This bug has been reported in ubuntu:
https://bugs.launchpad.net/ubuntu/+source/hal/+bug/213128

more information is available there, but here's a summary:

versions
acpi 1.2
kernel 2.6.28-11.42

hal properly reports battery charging/discharging state but incorrectly reports whether the AC adapter is unplugged.

lshal output when unplugged or plugged in both indicates:
ac_adapter.present = true (bool)

in Jaunty:
acpi -V (plugged in)
     Battery 0: Charging, 81%, 04:06:26 until charged
     Battery 0: design capacity 53280 mAh, last full capacity 50890 mAh = 95%
  AC Adapter 0: on-line
     Thermal 0: ok, 47.0 degrees C
     Cooling 0: LCD 0 of 8
     Cooling 1: Processor 0 of 10
     Cooling 2: Processor 0 of 10

acpi -V (unplugged)
     Battery 0: Discharging, 81%, 02:16:47 remaining
     Battery 0: design capacity 53280 mAh, last full capacity 50890 mAh = 95%
  AC Adapter 0: on-line
     Thermal 0: ok, 47.0 degrees C
     Cooling 0: LCD 0 of 8
     Cooling 1: Processor 0 of 10
     Cooling 2: Processor 0 of 10
Comment 41 Adam Pigg 2009-05-21 09:09:24 UTC
Any more ideas as to how to fix this as we know it works after a sleep?

What else can i do (after getting my laptop back from repair as the ac socket snapped off the main board :/ !)

Cheers
Comment 42 Adam Pigg 2009-07-10 18:28:48 UTC
Ping :)  no idea?
Comment 43 Len Brown 2009-08-13 03:08:15 UTC
adam, do you have a system to test on?
is this still a problem with the latest stable kernel?
Comment 44 Adam Pigg 2009-08-13 17:07:29 UTC
Hi Len, yes i still have the laptop and still have problems (currently using  2.6.31-desktop-0.rc5)
Comment 45 Adam Pigg 2009-09-15 18:45:56 UTC
hmmm, ive just observed it working, using kernel 2.6.31-desktop-2mnb

[root@localhost piggz]# lshal --monitor

Start monitoring devicelist:
-------------------------------------------------
19:41:07.268: computer_power_supply_battery_BAT0 property battery.remaining_time = 2795 (0xaeb)
19:41:07.269: computer_power_supply_battery_BAT0 property battery.charge_level.percentage = 31 (0x1f)
19:41:07.271: computer_power_supply_battery_BAT0 property battery.charge_level.rate = 68756 (0x10c94)
19:41:07.271: computer_power_supply_battery_BAT0 property battery.charge_level.current = 23998 (0x5dbe)
19:41:07.272: computer_power_supply_battery_BAT0 property battery.reporting.current = 1015 (0x3f7)
19:41:07.273: computer_power_supply_battery_BAT0 property battery.reporting.rate = 2908 (0xb5c)
19:41:07.273: computer_power_supply_ac_adapter_ADP0 property ac_adapter.present = false
19:41:07.550: computer property power_management.is_powersave_set = true
19:41:11.739: computer_power_supply_ac_adapter_ADP0 property ac_adapter.present = true
19:41:11.742: computer_power_supply_battery_BAT0 property battery.remaining_time = 2859 (0xb2b)
19:41:11.744: computer_power_supply_battery_BAT0 property battery.charge_level.rate = 67219 (0x10693)
19:41:11.745: computer_power_supply_battery_BAT0 property battery.reporting.rate = 2843 (0xb1b)
19:41:12.037: computer property power_management.is_powersave_set = false
^C
[root@localhost piggz]# ac
ac                 accept             accton             aclocal-1.11       aclocal-1.9        acpi               acpidump           acpitool           activation-client
ac3dec             accept-cups        aclocal            aclocal-1.8        aconnect           acpid              acpi_listen        acpixtract         acyclic
[root@localhost piggz]# acp
acpi         acpid        acpidump     acpi_listen  acpitool     acpixtract
[root@localhost piggz]# acpi_listen --help
Usage: acpi_listen [OPTIONS]
  -c, --count       Set the maximum number of events.
  -s, --socketfile  Use the specified socket file.
  -t, --time        Listen for the specified time (in seconds).
  -v, --version     Print version information.
  -h, --help        Print this message.
[root@localhost piggz]# acpi_listen
ac_adapter ADP0 00000000 00000000
battery BAT0 00000080 00000001
battery BAT0 00000081 00000001
ac_adapter ADP0 00000000 00000001
battery BAT0 00000080 00000001
battery BAT0 00000081 00000001
q^C
Comment 46 Adam Pigg 2009-09-15 19:22:08 UTC
hmm, i take it back, i rebooted and now it doesnt work, and i dont know why!!!!!!!!!
Comment 47 Alexey Starikovskiy 2009-09-15 19:27:35 UTC
First time, did you reboot from windows into linux?
Comment 48 Adam Pigg 2009-09-15 19:36:32 UTC
no, i dont have windows.....i did reboot from a different kernel, kernel-tmb-2.3.31-2 which is a mandriva kernel based on 2.6.31, but with some experimental patches.

When it was working, i remember the following from the end of dmesg:
ACPI: EC: missing confirmations, switch off interrupt mode.

I dont have that line anymore in dmesg
Comment 49 Alexey Starikovskiy 2009-09-15 19:47:19 UTC
Well, we could try to emulate effect of this warning...
Please comment out whole if() statement at drivers/acpi/ec.c:595
Comment 50 Adam Pigg 2009-09-16 16:53:16 UTC
My ec.c seems different to yours, line 595 is the return from acpi_ec_gpe_handler.

Do you mean to comment out lines in acpi_ec_wait?

If you're on irc, im piggz.
Comment 51 Alexey Starikovskiy 2009-09-16 17:16:03 UTC
Created attachment 23102 [details]
comment out switch to interrupt mode

Here is the patch, please check if it helps
Comment 52 Adam Pigg 2009-09-16 18:52:55 UTC
bah, ran out if disk space building kernel....working around..... in the mean time i rebooted into kernel-tmb, and acpi is working again, dmesg attached.
Comment 53 Adam Pigg 2009-09-16 18:53:56 UTC
Created attachment 23104 [details]
dmesg

dmesg output
Comment 54 Adam Pigg 2009-09-18 19:58:16 UTC
Ive built a vanilla kernel with the patch applied (using the .config from tmb and doing make oldconfig).  I dont get the message above, and it doesnt work.  I also cant get any other kernel to work anymore.  Ive seen it work with both mnb and tmb kernels, but not all the time, and dont know what to do to make it work.
Comment 55 Alexey Starikovskiy 2009-09-18 22:05:21 UTC
if patch does not help, then message was irrelevant to the problem.
please try to remove all the power from notebook (e.g. power off, _disconnect_ ac power plug and remove battery), this might help with stuck EC.
Comment 56 Adam Pigg 2009-10-02 19:38:46 UTC
\o/

Ive rebooted about 10 times now and can regularly make it work/not work.

Its quite simple really (which is even more frustrating!:)

I checked back through the comments, and read posts on the ubuntu and archlinux threads, and got pointed to the gentoo wiki on dsdt.  I know ive looked at this in the past but figured i'd look again.

Then i read about linux ignoring _OSI(Linux), and learned of acpi_osi="".

I disassembled by dsdt, and found the what is at the end of the post.

i set acpi_osi="Linux" on the cmdline, and it now works perfectly.  With this set i get this message from the kernel:
[    0.000000] ACPI: Added _OSI(Linux)
[    0.104794] ACPI: BIOS _OSI(Linux) query honored via cmdline

as opposed to ACPI: BIOS _OSI(Linux) query ignored.

Ive also tried other values such as "Windows 2001 SP2" and "Windows 2006 SP2", but these dont work, all i see in the kernel log is that the query for Linux was ignored.

Anyway, atm im happy, power events are now working.



=======================================================
Snipping from dsdt:

If (CondRefOf (_OSI, Local0))
                {
                    If (_OSI ("Linux"))
                    {
                        Store (0x03E8, OSYS)
                    }
                    Else
                    {
                        Store (0x07D0, OSYS)
                        If (_OSI ("Windows 2001"))
                        {
                            Store (0x07D1, OSYS)
                        }

                        If (_OSI ("Windows 2001 SP1"))
                        {
                            Store (0x07D1, OSYS)
                        }

                        If (_OSI ("Windows 2001 SP2"))
                        {
                            Store (0x07D2, OSYS)
                        }

                        If (_OSI ("Windows 2006"))
                        {
                            Store (0x07D6, OSYS)
                        }

                        If (LNotEqual (OSYS, 0x07D6))
                        {
                            If (_OSI ("Windows 2006 SP1"))
                            {
                                Store (0x07D6, OSYS)
                            }
                            Else
                            {
                                If (_OSI ("Windows 2006 SP2"))
                                {
                                    Store (0x07D6, OSYS)
                                }
                            }
                        }
                    }
                }
                Else
                {
                    Store (0x07D0, OSYS)
                }
Comment 57 Alexey Starikovskiy 2009-10-05 22:39:05 UTC
Created attachment 23273 [details]
Quirk to enable OSI(Linux) on Satellite L355

Please check if this patch is sufficient without cmdline osi=... string.
Comment 58 Zhang Rui 2010-03-26 02:56:13 UTC
does the laptop also work if you boot with acpi_osi="!Windows 2006" AND acpi_osi="!Windows 2006 SP1"?
Comment 59 Adam Pigg 2010-03-27 07:46:47 UTC
No, ive tried with both of them and it doesnt work.  Any idea which kernel the above patch will be in?  Anything else you'd like me to try?
Comment 60 Adam Pigg 2010-03-27 07:47:37 UTC
Did you mean to have both acpi_osi lines on the cmdline at the same time?
Comment 61 Adam Pigg 2010-03-27 07:54:06 UTC
Interesting...it DOES work if both are on the cmdline :) ......... so what doe that mean, it likes to mimic a Windows 2001 SP2?  I will see if this makes sleep/resume work (and re-open that bug)
Comment 62 Zhang Rui 2010-03-29 01:50:51 UTC
this is a piece of code in EC _REG method.

                                If (LGreater (OSYS, 0x07D5))
                                {
                                    WREC (0xDB, One, Zero, One)
                                    FLNK (0x14, One)
                                    Store (One, HKEM)
                                    WREC (0xDB, 0x10, 0x04, One)
                                    Store (One, HSEM)
                                    WREC (0xDB, 0x20, 0x05, One)
                                    If (LNotEqual (EVCT, Zero))
                                    {
                                        FLNK (0x11, EVCT)
                                        Store (And (KYB0, 0xFF), HSWK)
                                        Store (Zero, KYB0)
                                    }

                                    FLNK (0x10, One)
                                    FLNK (0x15, 0xFF)
                                }
                                Else
                                {
                                    WREC (0xDB, One, Zero, Zero)
                                    FLNK (0x15, 0xFF)
                                }
Not sure if this causes the problem.
Comment 63 Len Brown 2010-09-28 21:40:49 UTC
is this summary correct?

acpi_osi="Linux" WORKS
acpi_osi="!Windows 2006" FAILS
acpi_osi="!Windows 2006" acpi_osi="!Windows 2006 SP1" WORKS

Note that ACPICA in Linux does not claim compatibility
with "Windows 2006 SP2" -- so that check in the AML is a no-op.
Comment 64 Len Brown 2010-09-28 21:54:19 UTC
Created attachment 31772 [details]
Quirk to disable OSI Vista compatiblity

please test this patch.  It deletes Vista OSI compatibility
directly rather than indirectly as was done with the previous
patch that used OSI(Linux).
Comment 65 Len Brown 2010-10-02 02:01:28 UTC
commit 7a1d602f5fc35d14907b7da98d5627acb69589d1
Author: Len Brown <len.brown@intel.com>
Date:   Tue Sep 28 17:51:51 2010 -0400

    ACPI: EC: add Vista incompatibility DMI entry for Toshiba Satellite L355

shipped in Linux-2.6.36-rc6-git2
closed
Comment 66 Adam Pigg 2010-10-02 09:33:40 UTC
You happy even though i didnt test from comment 63 yet?
Comment 67 Len Brown 2010-10-05 04:52:22 UTC
Never too late to supply test results, however, in the absence
of test results, sometimes we have to guess...

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