From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751540AbeDYJrI (ORCPT ); Wed, 25 Apr 2018 05:47:08 -0400 Received: from mail-wr0-f173.google.com ([209.85.128.173]:37830 "EHLO mail-wr0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751212AbeDYJrF (ORCPT ); Wed, 25 Apr 2018 05:47:05 -0400 X-Google-Smtp-Source: AIpwx49gqLtNl64Gc2duA1b9DRvWlPBXnoB93Ce4xhU1+A0ZddDn84RDdvWSJTGq8kXw4e8oUJGnqA== From: Holger Schurig To: Alexander Duyck Cc: Jeff Kirsher , intel-wired-lan , LKML Subject: Re: [BUG] igb: reconnecting of cable not always detected In-Reply-To: References: <87h8o0ocul.fsf@gmail.com> Date: Wed, 25 Apr 2018 11:47:02 +0200 Message-ID: <877eovobxl.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alex, (Sent a 2nd time, this time with "Reply to all" and without HTML, so that it hits the kernel archives as well. Sorry for the noise. > Sounds like the link is failing to re-establish. You might double > check a few things. One is to verify if the link partner is > recognizing the link as coming up or not. It turns on differently. Before I remove the cable, the LED on the TP LINK "TL SG-108" was green. After removing the cable, the LED went off. After reinserting the cable, it became orange after some while. Green LED means 1000 MB/s, orange LED means 10/100 MB/s. I have a different, even older switch: "Allnet ALL8039". Here the same: the switch detects a link, but igb not. > If you could also provide an "lspci -vvv" 02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- and "ethtool -i" for the driver: igb version: 5.4.0-k firmware-version: 3.20, 0x80000553 expansion-rom-version: bus-info: 0000:02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes One thing that is interesting is how igb reacts to ethtool inquiries once it goes into the failed state. You inquired for "ethtool -i eth0", but in the failed state I only get this: Cannot restart autonegotiation: No such device But eth0 is of course still there, "ip -d link show eth0" shows: 2: eth0: mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether 00:13:95:1a:54:33 brd ff:ff:ff:ff:ff:ff promiscuity 0 numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535 Other ethtool commands also don't report any information once the link went bogus. Here one output from "ethtool eth0": Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: off (auto) Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes ... and here another: Settings for eth0: Cannot get device settings: No such device Cannot get wake-on-lan settings: No such device Cannot get message level: No such device Cannot get link status: No such device Settings for eth0: No data available I'm willing to pepper the source with printk, if this helps :-) Greetings, Holger