The short answer is the driver should never have suggested (via ethtool) that it supports Wake-on-ARP because it does not; i.e. it does not populate the appropriate address tables in hardware, nor is there a way to do that yet. I'll be submitting a patch that removes that option. Wake-on-ARP may be a supported feature in the future, but will require changes to ethtool as well.
>-----Original Message----- >From: Pieper, Jeffrey E [mailto:jeffrey.e.pie...@intel.com] >Sent: Thursday, March 03, 2011 1:44 PM >To: Brandeburg, Jesse; Wyborny, Carolyn >Cc: e1000-devel@lists.sourceforge.net >Subject: Re: [E1000-devel] Wake on ARP not working > >I can reproduce this on my SM w/ 82574 down. > >Jeff > >-----Original Message----- >From: Brandeburg, Jesse [mailto:jesse.brandeb...@intel.com] >Sent: Thursday, March 03, 2011 1:09 PM >To: Mathias Krause; Wyborny, Carolyn >Cc: e1000-devel@lists.sourceforge.net >Subject: Re: [E1000-devel] Wake on ARP not working > > > >On Thu, 3 Mar 2011, Mathias Krause wrote: > >> Hello e1000e developers, >> >> I have a problem getting a specific wake-on-lan combination getting to >> work on my onboard 82574L PCIe adapter. I would like to wake the system >> from S3 by either an ARP request or an unicast packet send to the system, >> e.g. an ICMP packet. What I'm seeing is that wake-on-unicast works, but >> wake-on-arp does not, albeit the adapter is configured to do so: > >Sorry to hear wake on arp is not working, I'm hoping Carolyn can take a >look or our lab can reproduce. > >Wake on arp may not be the best wake behavior however because most systems >receive an arp at least every two minutes from the switch port they are >plugged into. Other machines on your network will also arp for your >machine if they recently contacted it. > >> root@puck:~# ethtool eth0 >> Settings for eth0: >> Supported ports: [ TP ] >> Supported link modes: 10baseT/Half 10baseT/Full >> 100baseT/Half 100baseT/Full >> 1000baseT/Full >> Supports auto-negotiation: Yes >> Advertised link modes: 10baseT/Half 10baseT/Full >> 100baseT/Half 100baseT/Full >> 1000baseT/Full >> Advertised pause frame use: No >> Advertised auto-negotiation: Yes >> Speed: 100Mb/s >> Duplex: Full >> Port: Twisted Pair >> PHYAD: 1 >> Transceiver: internal >> Auto-negotiation: on >> MDI-X: off >> Supports Wake-on: pumbag >> Wake-on: uag >> Current message level: 0x00000001 (1) >> Link detected: yes >> >> "g" is included in the wake-on list to work around the problem and have a >> way to wakeup the system by sending a magic packet. But what I really want >> is to skip this manual step and let the machine wakeup automatically when >> someone wants to access it. >> >> Reading the specification (document number 317694-020, section 5.5.3.1), >> the adapter should wake on ARP request because it wakes up on unicast >> packets directed to the configured IPv4 address. The document states that >> the ARP method and the unicast method are using the same table for IP >> addresses matching (IP4AT), so if it works for the unicast case it should >> work for the ARP case also, shouldn't it? > >I'm not sure that anything programs the IP4AT register, as I don't see it >being used in our drivers. I imagine that is relevant. :-) I think the >problem is the interface to ethtool should provide a way to program the IP >address to the NIC when enabling wake on arp. > >> Any idea why it doesn't work? >> >> I'm running 2.6.37.1. Here is the lspci for completeness: >> >> root@puck:~# lspci >> 00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge (rev 02) >> 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated >Graphics Controller (rev 02) >> 00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics >Controller (rev 02) >> 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI >Controller #4 (rev 02) >> 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI >Controller #5 (rev 02) >> 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI >Controller #6 (rev 02) >> 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI >Controller #2 (rev 02) >> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 >(rev 02) >> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 >(rev 02) >> 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 >(rev 02) >> 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI >Controller #1 (rev 02) >> 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI >Controller #2 (rev 02) >> 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI >Controller #3 (rev 02) >> 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI >Controller #1 (rev 02) >> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) >> 00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface >> Controller >(rev 02) >> 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port >SATA AHCI Controller (rev 02) >> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev >02) >> 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network >Connection >> 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network >Connection >> >> >> Regards, >> Mathias >> >> P.S.: No, it's not possible to add a static ARP entry on every possible >> machine accessing it, so only unicast packets would be generated. > > >------------------------------------------------------------------------------ >What You Don't Know About Data Connectivity CAN Hurt You >This paper provides an overview of data connectivity, details >its effect on application quality, and explores various alternative >solutions. http://p.sf.net/sfu/progress-d2d >_______________________________________________ >E1000-devel mailing list >E1000-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/e1000-devel >To learn more about Intel® Ethernet, visit >http://communities.intel.com/community/wired > >------------------------------------------------------------------------------ >What You Don't Know About Data Connectivity CAN Hurt You >This paper provides an overview of data connectivity, details >its effect on application quality, and explores various alternative >solutions. http://p.sf.net/sfu/progress-d2d >_______________________________________________ >E1000-devel mailing list >E1000-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/e1000-devel >To learn more about Intel® Ethernet, visit >http://communities.intel.com/community/wired ------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
