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
