Re: [E1000-devel] em1 is visible to iproute2 but not ethtool or tcpdump

[Andy L. <lu...@am...>]

On Thu, Mar 14, 2013 at 1:45 PM, Allan, Bruce W <bru...@in...> wrote:
>> -----Original Message-----
>> From: net...@vg... [mailto:netdev-
>> ow...@vg...] On Behalf Of Andy Lutomirski
>> Sent: Thursday, March 14, 2013 9:54 AM
>> To: Network Development
>> Cc: e10...@li...
>> Subject: em1 is visible to iproute2 but not ethtool or tcpdump
>>
>> My e1000e device is em1.  It has this rather strange behavior on
>> Fedora's 3.8.1 (although 3.7.something did the same thing, I believe):
>>
>> $ ip link show dev em1
>> 6: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
>> pfifo_fast
>> state DOWN qlen 1000
>>     link/ether f0:de:f1:59:f6:c9 brd ff:ff:ff:ff:ff:ff
>> $ strace -e socket,ioctl ethtool em1
>> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
>> Settings for em1:
>> ioctl(3, SIOCETHTOOL, 0x7fffa6c554d0)   = -1 ENODEV (No such device)
>> Cannot get device settings: No such device
>> ioctl(3, SIOCETHTOOL, 0x7fffa6c554d0)   = -1 ENODEV (No such device)
>> Cannot get wake-on-lan settings: No such device
>> ioctl(3, SIOCETHTOOL, 0x7fffa6c554d0)   = -1 ENODEV (No such device)
>> Cannot get message level: No such device
>> ioctl(3, SIOCETHTOOL, 0x7fffa6c554d0)   = -1 ENODEV (No such device)
>> Cannot get link status: No such device
>> No data available
>> +++ exited with 75 +++
>> $ sudo tcpdump -i em1
>> tcpdump: em1: SIOETHTOOL(ETHTOOL_GTSO) ioctl failed: No such device
>>
>> A sufficient number of rmmod/modprobe cycles will make it work.
>>
>> This is, perhaps, helpful:
>>
>> $ sudo ip link set dev em1 name foobar
>> RTNETLINK answers: Device or resource busy
>> $ sudo ip link set dev em1 down
>> $ sudo ip link set dev em1 name foobar
>> $ sudo ethtool foobar
>> Settings for foobar:
>>       Supported ports: [ TP ]
>>       Supported link modes:   10baseT/Half 10baseT/Full
>>                               100baseT/Half 100baseT/Full
>>                               1000baseT/Full
>>       Supported pause frame use: No
>>       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: Unknown!
>>       Duplex: Unknown! (255)
>>       Port: Twisted Pair
>>       PHYAD: 1
>>       Transceiver: internal
>>       Auto-negotiation: on
>>       MDI-X: Unknown
>>       Supports Wake-on: pumbg
>>       Wake-on: g
>>       Current message level: 0x00000007 (7)
>>                              drv probe link
>>       Link detected: no
>> $ sudo ip link set dev foobar name em1
>> $ sudo ethtool em1
>> Settings for em1:
>>       Supported ports: [ TP ]
>>       Supported link modes:   10baseT/Half 10baseT/Full
>>                               100baseT/Half 100baseT/Full
>>                               1000baseT/Full
>>       Supported pause frame use: No
>>       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: Unknown!
>>       Duplex: Unknown! (255)
>>       Port: Twisted Pair
>>       PHYAD: 1
>>       Transceiver: internal
>>       Auto-negotiation: on
>>       MDI-X: Unknown
>>       Supports Wake-on: pumbg
>>       Wake-on: g
>>       Current message level: 0x00000007 (7)
>>                              drv probe link
>>       Link detected: no
>> $
>>
>> This bug (?) isn't a show-stopper, but it's rather annoying.  I
>> suspect a core networking bug, not an e1000e bug, but I cc'd the e1000
>> people just in case.
>
> This sounds related to some runtime power management (RPM) issues that have
> already been fixed.  First check whether RPM is enabled for your device - the file
> /sys/devices/pciNNNN:NN/NNNN:NN:NN.N/power/control (where NNNN... is
> the PCI domain, bus, slot and function of your device) will contain "auto" when it
> is enabled.  To disable RPM for that device, change the value in the file to "on".

Seems to work.  Oddly, I'm pretty sure I've seen this bug even when
something's plugged in.

Is the fix heading to stable?

--Andy