Ticket #12605 (closed defect: fixed)

Opened 18 months ago

Last modified 6 months ago

8787/mwifiex wakes up on all multicast frames

Reported by: dsd Owned by: pgf
Priority: high Milestone: 13.2.0
Component: kernel Version: not specified
Keywords: Cc: shep, jvonau, sridhar
Action Needed: test in build Verified: no
Deployments affected: Australia Blocked By:
Blocking:

Description

Testing 13.1.0 build 35 on XO-4 C1 with 8787 wireless connected to an AP.

The XO idle suspends as normal, but after a short period of time (usually less than 2 seconds), the power LED and serial console show that the system has woken up. It immediately goes back to sleep, but then wakes up again after a short time. And so on.

This seems to happen close to 100% of the time, but does not happen with my XO-4 B1 with 8686 wireless.

Repeating the test without connecting to the network, the system now seems to be sleeping happily. So this may be related to 8787.

Attachments

dmesg.txt (46.9 kB) - added by dsd 18 months ago.
dmesg capture of the rapid sleep/wakeup/sleep/... cycle

Change History

Changed 18 months ago by dsd

dmesg capture of the rapid sleep/wakeup/sleep/... cycle

Changed 18 months ago by shep

  • cc shep added

Changed 18 months ago by shep

I saw this problem in my testing a few nights ago on a hotel wireless network while I was traveling. I made this problem go away then by editing powerd to change the wol setting to be just u instead of um. (This was on a 1.2 GHz XO-4 C1, Q7B21, EC 0.4.01, build 34, kernel f80b9e7, powerd.conf config_WAKE_ON_WLAN=yes, rm /etc/powerd/flags/inhibit-suspend, ssh from the XO to my mail server where I ran "while sleep 30 && date ; do : ; done" so the ssh traffic was my intended source of wakeups.)

Changed 18 months ago by dsd

#12609 also suggests that this is related to mwifiex/8787 and has some tcpdump diagnosis.

Changed 16 months ago by dsd

  • milestone changed from 4-software to 13.2.0

Changed 16 months ago by sridhar

  • deployment_affected set to Australia

Changed 16 months ago by sridhar

  • cc jvonau, sridhar added

Changed 16 months ago by dsd

Checking the command format, both 8686 and 8787 have the same granularity of host sleep wakeup conditions: a bitfield of broadcast, unicast, mac event, multicast.

The documentation doesn't explain if multicast means "any multicast packet on the network" or "multicast packets in a multicast group that we are present".

Both drivers have code to program the multicast group list to the hardware.

Changed 16 months ago by dsd

Tested 8686, things work as desired.

On the XO:

echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Now use mjoin on the XO from https://lkml.org/lkml/2004/8/5/143

and ping 224.1.1.37 from another host while the XO is asleep. While mjoin is running, the XO wakes up to the multicast ping. At other times, it stays asleep.

Changed 16 months ago by dsd

  • next_action changed from never set to add to build
  • summary changed from XO-4 C1 only suspends for a brief period of time to 8787/mwifiex wakes up on all multicast frames

I confirmed experimentally on a quiet network that all multicast packets were waking up the 8787 system, even when the system did not have that particular multicast address assigned.

Fixed in arm-3.5 84c2bb7effacced073495e823270e6d6323aa3e0. mwifiex was setting the 'wakeup on all multicast' bit rather than just programming the selective multicast address list defined by the upper layers.

Changed 16 months ago by dsd

  • next_action changed from add to build to test in build

Test in 13.2.0 build 6.

Changed 6 months ago by pgf

closing, assumed fixed.

Changed 6 months ago by pgf

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.