Laptop comes out of suspend on its own

[kimquirk]

B4 unit running build 581, q2c26

Boot up this laptop, after it is up and running sugar, then press the suspend button. About 1 minute later the laptop wakes back up turning the screen on.

Another laptop I have, a C-build with new LX processor, running the same OS and OFW remains suspended after pushing the suspend button. Not sure if this behavior fits into some of the existing suspend/resume issues.

[jg]

I thought we fixed this one, by turning off the 1% ticks....

Richard?

[cjb]

The "disable 1% ticks" patch is still in our tree, so something odd is going on.

[wad]

Is the wireless interface running ? It is certainly capable of bringing a laptop out of suspend --- we see that all the time.

What was printed on the EC serial console when this happened ?

[cjb]

I think Richard ran tests yesterday that confirmed that (on the test laptop) these were indeed wireless wackups, not battery.

[rsmith]

Replying to cjb:

I think Richard ran tests yesterday that confirmed that (on the test laptop) these were indeed wireless wackups, not battery.

Indeed I did. I used a setup with my custom EC code and found that the Battery wakeup were masked correctly and that all the wakeup were from the WLAN. This was just a normal suspend after a default boot.

Javier: What are all the conditions that WLAN asserts the wakeup? Do we have some suspend/resume debugging stuff that is wakeing us up. (No I was not using the auto wakeup firmware)

[jcardona]

The driver currently only enables config.conditions = EHS_WAKE_ON_UNICAST_DATA So only unicast frames addressed to the node should trigger the wake up. Can we be certain that there is no traffic sent to the DUT?

[rsmith]

Replying to jcardona:

The driver currently only enables config.conditions = EHS_WAKE_ON_UNICAST_DATA So only unicast frames addressed to the node should trigger the wake up. Can we be certain that there is no traffic sent to the DUT?

If there was traffic then its via some automatic method from another mesh node. Its been shown to be happening on few different machines with nothing special done to them.

Unfortunately, I cannot seem to duplicate the problem right now. Javier gave me the follwing to do when the problem surfaces again:

Can you capture traffic on the laptop that's showing that behavior before suspending? That's how:

<code> killall NetworkManager echo 0x1 > /sys/class/net/msh0/device/libertas_rtap ifconfig rtap0 up tcpdump -i rtap0 -w capture.dump

You'll need to install tcpdump on the laptops. Probably yum install tcpdump will work. If not, get these rpms:

ftp://chuck.ucs.indiana.edu/pub/array2/linux/fedora/linux/updates/7/i386/tcpdump-3.9.7-1.fc7.i386.rpm ftp://chuck.ucs.indiana.edu/pub/array2/linux/fedora/linux/updates/7/x86_64/libpcap-0.9.7-1.fc7.i386.rpm </code>

[wad]

You can just add a rule to the iptables to cause all incoming/forwarded packets to be logged:

iptables -I INPUT -j LOG iptables -I FORWARD -j LOG

As there is another bug about the packet which wakes up the laptop getting lost (#3733), I doubt this get debugged until that is fixed.

It certainly isn't broadcast packets which are waking it up, see #3732.

As a side note, I have laptops in an ad-hoc network in a network quiet place, and they appear to sit indefinitely in suspend.

[jcardona]

Wireshark screen capture of wackup.cap

[jcardona]

Richard provided a traffic capture file that I've attached to this ticket (wackup.cap).

The attached file is from another XO.  I stopped the capture just after
I saw my XO wakeup with a WLAN SCI.

My XO has a MAC of 00:17:c4:02:30:f9 Mesh IP was set to 172.18.29.246

The capture reveals that there is a Lazy-WDS access point in the vicinity (00:18:f8:e2:68:74) that is generating the wake-up traffic. See this wireshark screen capture.

[jg]

This begs a different question: should we currently configure the system to wakeup?

[rchokshi]

this is also a WDS issue which has been beaten to death several times. I leave it to Kim for now to take the decision for this Trac.

[jcardona]

To disable wireless initiated wake-up, clear the wake-up conditions in if_usb.c on the libertas driver:

static int if_usb_suspend(struct usb_interface *intf, pm_message_t message)
{
        ...
        memset(&config, 0, sizeof(config));
        config.gpio = EHS_GPIO_PIN;
        config.gap = EHS_WAKE_GAP;
-       config.conditions = EHS_WAKE_ON_UNICAST_DATA;

[jcardona]

Closed by unanimous consent.

[dilinger]

Er.. should this change be made in the kernel or not? If it should be, don't close this bug; reassign it to me!

If the change doesn't need to be made, then ignore me.

[cjb]

The change as stated should not be made; we *want* to wake up from suspend due to network traffic.

What we don't want to do is wake up from "sleep", which is when we hit the power button to go to sleep and don't want to wake up again without another power button press. This is moved to #4329.

This looks an annoying mix of OHM and kernel; somehow OHM, or whatever's handling the power button, has to tell the kernel that it wants sleep instead of suspend on the way down.

[cjb]

We've closed this as being caused by Lazy-WDS, yet it seems to happen to just about anyone with an XO. For example, it just happened to me (C-Test, joyride-220) at home, and I'm not aware of anything speaking Lazy-WDS here.

I'd like us to verify that, when we are sure we aren't in the presence of something speaking Lazy-WDS -- yet are otherwise associated to an AP or mesh portal -- we will stay asleep for a long time. I don't know where to find such an environment, though!

[mbletsas]

Chris,

If there are frames addressed to the XO, it will wake up. That's what we designed it to do.

The test to do is to disassociate it from the AP, make it use one of the mesh channels and see what happens then.

M.

[cjb]

The test to do is to disassociate it from the AP, make it use one of the mesh channels and see what happens then.

It wakes up (at 1cc) within thirty seconds. (C2, Joyride-230, Q2D03, 17.p0)

[mbletsas]

Chris,

How about at your home, there are plenty of frames going around for every laptop in OLPC ;-)

[dwmw2]

The current kernel supports the standard wake-on-lan configuration; you can select to wake on unicast, multicast and/or broadcast packets, as well as on MAC events. This should allow userspace to have whatever behaviour it desires.