Lid switch detection only works on AC

[cjb]

It seems to be the case that /sys/power/wakeup-source is only correctly set to "lid switch", when we wake up by raising the lid, if AC is plugged in.

Haven't investigated further.

[dilinger]

I'm unable to reproduce this. I have a MP machine, kernel 2.6.22-20080117.1.olpc.a0ca568e912c1c5, and build 657 (no ohm, of course). Regardless of whether or not I'm on battery power, when I 'echo mem > /sys/power/state' and then open the lid, /sys/power/wakeup-source always contains the proper string.

[dilinger]

Ok, I looked at the machine that this was occuring on; it was happening with some wacky firmware (q2068). When I installed q2d09 on it, I was unable to reproduce the problem. Therefore, I'm blaming the EC.

[dilinger]

Oh, richard, this machine is no longer running q2068, btw.. :)

[dilinger]

Here's a rundown of what was happening from the kernel side:

20:37  dilinger> before we check if we were woken up by a lid event, we check 
                 if we were woken up by the EC from an SCI event
20:38  dilinger> that code path was being triggered
20:38  cjb> ok
20:38  dilinger> but since there wasn't actually an SCI waiting in the queue, 
                 wakeup_source became "empty sci"
20:38  cjb> can we make a lid event trump an SCI?  Should we?
20:38  dilinger> i don't think we should
20:39  dilinger> i mean, this isn't a (kernel) bug
20:39  dilinger> PM_GPE0_STS claimed GPIO_WAKEUP_EC was set
20:39  dilinger> it shouldn't have claimed that

Remember to tip your waitress!

[rsmith]

Replying to dilinger:

20:39 dilinger> i mean, this isn't a (kernel) bug 20:39 dilinger> PM_GPE0_STS claimed GPIO_WAKEUP_EC was set 20:39 dilinger> it shouldn't have claimed that }}} Remember to tip your waitress!

I don't tip when they bring me the wrong food.

A few facts I've discovered:

- This problem is not firmware specific. Its sporadic. Both my newer firmwares and Q2D09 will have/not have the issue. The logs below were generated with q2d09. - The EC is indeed sending a SCI 0x01 but it is NOT in response to the lid switch doing anything. Its in response to the kernel talking to the kbc during the normal resume sequence. - The kernel incorrectly thinks that the lid event is an EC SCI of 0x00.

Logs:

First the EC log:

IBF
6c 32
3956020:<- 0
3956023:SCIInhibit On
M
3956061:SCIInhibit Off
IDEL_STATE

3962850:-01,
IBF
6c 34
3962858:-1B,
3962862:<- 0
IBF
6c 24
3962869:WAKE->WLAN
3962875:<- 0
IBF
6c 24
3962882:WAKE->WLAN
3962888:<- 0
IBF
6c 1c
RdMask bb
3962896:<- bb
IBF
6c 1b
3962903:-01,
3962906:D=ff
3962910:-02,
Mask=ff
3962915:1d<-F 0
IBF
6c 84
3962923:<- 0
3963572:Wackup SCI
3963576:SCI:01
IBF
6c 84
3963585:<- 1
IBF
6c 84
3963592:<- 0
IBF
6c 1c
RdMask ff
3964138:<- ff
IBF
6c 1b
3964144:D=bb
Mask=bb
3964151:1d<-F 0
IBF
6c 32
3964159:<- 0
3964162:SCIInhibit On
M
3964200:SCIInhibit Off
IDEL_STATE

Kernel sends a cmd 32 and the corresponding IDEL_STATE (suspend) happens. We see the EC pick up and start processing EC commands a 0x34 an then 2 0x24s _without_ and indication of an SCI happening. Now skip forward until where you see the "Wackup SCI" and the SCI 0x01. Just before that SCI we see the kernel send down a 0x84 command which is "read SCI queue." There has not been an EC SCI so the EC correctly reports zero. Then in response to PS2 traffic from the kernel the EC generates a SCI 0x01. Then the kernel gets the EC SCI and correctly reads an SCI 0x01 and the end of the queue with 2 cmd 0x84's. Then a bit later we go back into suspend.

The corresponding kern.log filtered by 'grep olpc-'

Jan 25 07:24:04 localhost kernel: [   19.140520] olpc-ec:  running cmd 0x32
Jan 25 07:24:04 localhost kernel: [    0.005687] olpc-ec:  running cmd 0x34
Jan 25 07:24:04 localhost kernel: [    0.016751] olpc-ec:  running cmd 0x24
Jan 25 07:24:04 localhost kernel: [    0.029804] olpc-ec:  running cmd 0x24
Jan 25 07:24:04 localhost kernel: [    0.042857] olpc-ec:  running cmd 0x1c
Jan 25 07:24:04 localhost kernel: [    0.050898] olpc-ec:  received 0xbb
Jan 25 07:24:04 localhost kernel: [    0.050914] olpc-ec:  running cmd 0x1b
Jan 25 07:24:04 localhost kernel: [    0.053940] olpc-ec:  sending cmd arg 0xff
Jan 25 07:24:04 localhost kernel: [    0.054828] platform olpc-battery.0: EARLY resume
Jan 25 07:24:04 localhost kernel: [    0.068184] olpc-ec:  running cmd 0x84
Jan 25 07:24:04 localhost kernel: [    0.075222] olpc-ec:  received 0x0
Jan 25 07:24:04 localhost kernel: [    0.075328] olpc-pm:  SCI 0x0 received
Jan 25 07:24:04 localhost kernel: [    1.127124] platform olpc-battery.0: resuming
Jan 25 07:24:04 localhost kernel: [    1.180575] olpc-ec:  running cmd 0x84
Jan 25 07:24:04 localhost kernel: [    1.187617] olpc-ec:  received 0x1
Jan 25 07:24:04 localhost kernel: [    1.187632] olpc-pm:  SCI 0x1 received
Jan 25 07:24:04 localhost kernel: [    1.187649] olpc-ec:  running cmd 0x84
Jan 25 07:24:04 localhost kernel: [    1.195691] olpc-ec:  received 0x0
Jan 25 07:24:04 localhost kernel: [    1.195857] olpc-pm:  SCI 0x0 received
Jan 25 07:24:04 localhost kernel: [    1.231490] platform olpc-battery.0: suspend
Jan 25 07:24:04 localhost kernel: [    1.280754] platform olpc-battery.0: LATE suspend
Jan 25 07:24:04 localhost kernel: [    1.281191] olpc-ec:  running cmd 0x1c
Jan 25 07:24:04 localhost kernel: [    1.290235] olpc-ec:  received 0xff
Jan 25 07:24:04 localhost kernel: [    1.290252] olpc-ec:  running cmd 0x1b
Jan 25 07:24:04 localhost kernel: [    1.292276] olpc-ec:  sending cmd arg 0xbb
Jan 25 07:24:04 localhost kernel: [    1.304326] olpc-ec:  running cmd 0x32

This matches the EC log perfectly. The kernel issues cmd 32 and then goes into suspend. It gets woken up by a the lid event and then runs a few EC commands. The kernel issues a 0x84 because it thinks it was woken up by the EC. The result is zero since the SCI queue is empty. Then a real EC SCI shows up a bit later the kernel reads the 0x01 and finishes the SCI queue. Then goes back to sleep because it has missed detecting that a lid event was the real source of the wakeup.

[gnu]

I am seeing a similar problem. On my MP, serial CSN7500230F, I have seen several times where it gets "stuck" thinking that it needs to stay suspended with the screen off.

The latest time, I was using it as an ebook reader and had flipped the screen over to turn it off. The backlight went off, and I went to sleep. Upon awakening, I brought the laptop to its power plug, opened it, and plugged it in. (I could've plugged it in before or after opening it - not sure). It is currently sitting in front of me, suspended, refusing to come out. The LEDs show WiFi keyhole on, occasional blinking circle-in-circle, yellow battery, and on/off is blinking briefly about every 2.5 seconds. If I hit the space bar, the power light immediately comes on, for about a second, then goes right off, without brightening the screen. (The lid is fully open.) If I move continuously on the touchpad, the power light immediately comes on, stays on for about 1 second, goes off for about a quarter second, comes back on, goes off, comes back on, goes off, as long as I persist. Using the "down" rocker key has the same effect as the space bar. Only the Power button brings the system back to life (and then it processes all those keys that I've been hitting).

When it suspends from having the lid closed, it should un-suspend when you open the lid. Ideally it would do that AS you were opening the lid, so you'd never see it suspend at all; the screen would be ready by the time you can see it.

[gnu]

The release notes should mention that if the system suspends and can't get up again, the power button will restore it.

[wmb@…]

Experiments with OFW suggest that the 5536 often reports that an SCI event occurred after wakeup, even though the scope shows that no such event actually happened.

I can't find any way to fix that in hardware. Consequently, it would be prudent to change the kernel to recognize a lid wakeup properly, even if it is coincident with a spurious SCI event report.

My test procedure:

a) Connect a scope to SCI# (e.g. low side of R201).

b) Set scope to trigger on falling edge, threshold 3.0V (signal high/idle level is ~3.3V)

c) Disconnect AC, powering XO from battery only

d) Boot to ok prompt.

e) Observe that SCI# pulses low every now and then, indicating 1% changes in battery charge

f) lid-wakeup \ Add the lid switch to the list of wakeup events

h) ok -1 18 acpi-l! \ This clears any leftover wakeup event status bits

i) Set scope to "one-shot trigger"

j) ok s

k) Wave a magnet near the lid switch (by the mic light) to wakeup

l) ok 18 acpi-l@ dup . 18 acpi-l!

m) Observe that the value is c0000000 - the 80000000 bit indicates SCI, 40000000 is lid

n) Repeat i-m until you see a case where the scope did not trigger, but the value was still c0000000. In my setup, it happens pretty much every time (the c0000000 happens every time, and most of the time, there is no actual SCI event. Real SCI events only occur when a battery charge state report coincides with the test.)

[gregorio]

Added to release notes. http://wiki.laptop.org/go/Release_Notes/8.2.0-detailed-version#Open_Power_Issues

I said: * <trac>6192</trac> Sometimes the system may suspend and not wake up again. In this case, pressing the power button may wake it up again.

Feel free to update that with exactly what kind of suspend and if you should just tap the power button or hold it down, or anything else.

Thanks,

Greg S

[cjb]

Hi Greg,

I think this is fixed, actually. (But I guess it's okay to have a relnote about it even if the relnote doesn't apply.)

I'll close this bug; I'm happy with the lid behavior at the moment.