lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXrOxSOiczSLNSd3=bTHZX+G5NUQ+mvBDC71SX4PTkSPA@mail.gmail.com>
Date:	Thu, 14 Mar 2013 15:43:17 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"Allan, Bruce W" <bruce.w.allan@...el.com>
Cc:	Network Development <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
Subject: Re: em1 is visible to iproute2 but not ethtool or tcpdump

On Thu, Mar 14, 2013 at 1:45 PM, Allan, Bruce W <bruce.w.allan@...el.com> wrote:
>> -----Original Message-----
>> From: netdev-owner@...r.kernel.org [mailto:netdev-
>> owner@...r.kernel.org] On Behalf Of Andy Lutomirski
>> Sent: Thursday, March 14, 2013 9:54 AM
>> To: Network Development
>> Cc: e1000-devel@...ts.sourceforge.net
>> 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ