Ticket #3504 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

Laptop comes out of suspend on its own

Reported by: kimquirk Owned by: kimquirk
Priority: high Milestone: Update.1
Component: wireless Version:
Keywords: Cc: jg, rsmith, cjb, dilinger, mbletsas, rchokshi, dwmw2
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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.

Attachments

wackup.cap (0.7 MB) - added by jcardona 7 years ago.
wackups-culprit.png (182.9 kB) - added by jcardona 7 years ago.
Wireshark screen capture of wackup.cap

Change History

  Changed 7 years ago by jg

  • cc dilinger added
  • owner changed from hughsient@… to David.Lin
  • component changed from power manager (OHM) to embedded controller
  • milestone changed from Untriaged to Trial-3

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

Richard?

  Changed 7 years ago by cjb

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

  Changed 7 years ago by 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 ?

follow-up: ↓ 5   Changed 7 years ago by cjb

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

in reply to: ↑ 4   Changed 7 years ago by rsmith

  • owner changed from David.Lin to jcardona

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)

follow-up: ↓ 7   Changed 7 years ago by 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?

in reply to: ↑ 6   Changed 7 years ago by rsmith

  • component changed from embedded controller to wireless

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>

  Changed 7 years ago by 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.

Changed 7 years ago by jcardona

  Changed 7 years ago by jcardona

  • cc mbletsas, rchokshi added

Changed 7 years ago by jcardona

Wireshark screen capture of wackup.cap

  Changed 7 years ago by 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.

  Changed 7 years ago by jg

  • milestone changed from Untriaged to First Deployment, V1.0

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

  Changed 7 years ago by rchokshi

  • owner changed from jcardona to kimquirk

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.

  Changed 7 years ago by 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;

  Changed 7 years ago by jcardona

Closed by unanimous consent.

  Changed 7 years ago by jcardona

  • status changed from new to closed
  • resolution set to fixed

  Changed 7 years ago by 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.

  Changed 7 years ago by 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.

follow-up: ↓ 19   Changed 7 years ago by cjb

  • status changed from closed to reopened
  • resolution deleted

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!

in reply to: ↑ 18   Changed 7 years ago by 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.

  Changed 7 years ago by 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)

  Changed 7 years ago by mbletsas

Chris,

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

  Changed 7 years ago by dwmw2

  • cc dwmw2 added
  • status changed from reopened to closed
  • resolution set to fixed

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.

Note: See TracTickets for help on using tickets.