From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Kirsher Subject: Re: No address after suspend/resume with 4.18 Date: Mon, 03 Dec 2018 13:19:20 -0800 Message-ID: References: <20181130152615.6082a4da@xeon-e3> Reply-To: jeffrey.t.kirsher@intel.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-gPovnkekFuPd+M6ujo25" Cc: netdev@vger.kernel.org To: Stephen Hemminger Return-path: Received: from mga07.intel.com ([134.134.136.100]:2101 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725952AbeLCVS7 (ORCPT ); Mon, 3 Dec 2018 16:18:59 -0500 In-Reply-To: <20181130152615.6082a4da@xeon-e3> Sender: netdev-owner@vger.kernel.org List-ID: --=-gPovnkekFuPd+M6ujo25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2018-11-30 at 15:26 -0800, Stephen Hemminger wrote: > On my box with Debian testing, I see a new problem with > suspend/resume of wired network device. > Using stock Debian kernel 4.18.0-2-amd64 >=20 > After suspend/resume cycle, IP address is lost. >=20 > Device Info: > $ /sbin/ethtool -i enp12s0 > driver: igb > version: 5.4.0-k > firmware-version: 0. 6-1 > expansion-rom-version:=20 > bus-info: 0000:0c:00.0 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: yes > supports-register-dump: yes > supports-priv-flags: yes >=20 >=20 > $ lspci -v -s 0000:0c:00.0 > 0c:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network > Connection (rev 03) > Subsystem: Gigabyte Technology Co., Ltd I211 Gigabit Network > Connection > Flags: bus master, fast devsel, latency 0, IRQ 17, NUMA node 0 > Memory at dfb00000 (32-bit, non-prefetchable) [size=3D128K] > I/O ports at c000 [size=3D32] > Memory at dfb20000 (32-bit, non-prefetchable) [size=3D16K] > Capabilities: > Kernel driver in use: igb > Kernel modules: igb >=20 > State before suspend: > $ ip addr show dev enp12s0 > 4: enp12s0: mtu 1500 qdisc mq state > UP group default qlen 1000 > link/ether 1c:1b:0d:0a:4b:0e brd ff:ff:ff:ff:ff:ff > inet 192.168.1.18/24 brd 192.168.1.255 scope global enp12s0 > valid_lft forever preferred_lft forever >=20 > State after resume: >=20 > $ ip addr show dev enp12s0 > 4: enp12s0: mtu 1500 qdisc mq state > UP group default qlen 1000 > link/ether 1c:1b:0d:0a:4b:0e brd ff:ff:ff:ff:ff:f >=20 > Doing ifdown/ifup which restarts the DHCP client does restore the > address. >=20 > Not sure if this is a kernel issue with carrier handling, Intel > driver issue, or DHCP client issue. We have not been able to reproduce this using Fedora and 4.18 kernel.=20 This looks to be a Debian/DHCP client specific issue, we are continuing our reproduction efforts but with Debian to see if we can determine a root cause. --=-gPovnkekFuPd+M6ujo25 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiTyZWz+nnTrOJ1LZ5W/vlVpL7c4FAlwFndgACgkQ5W/vlVpL 7c4x+BAAhThe51o2SxZWrexLjNc3bU6xKbElqtDxBSm63Uy8UP/A6FPtgKpCFZJ4 gOshJzmFgRuxCIQqoVwiuB/oHwLSet5It0+2ShdJBp+sCdxDmPHWr6ey1kN0l13Z NraKJrTnEl94vKtmcolgETcmKdz1eeHqVDVFpovAtaGVuoNAlwRXc3y+MXscvU/T PD3S8q2SwFT4WS7wmQSe3LdWlOSLHmf9D5hbE3iXN+W6LvRE9Cfv3sli5zIDCq+l n4Bmjqs8929DP5k6g3rGAx8rBrv9acF1YUnphVYQvMd1QSqtMdyZ2WUI2pzH3Gqs 2uogw9X+2QuusrDhTyGPnYT+4jDMa3CzvlPceWqlURSjY4+gLdbjo+FWxknkCmVB BV9CNtyJ5gvbmEN/qDsF5YcC5oNmwZ0g/OPbRrqJGT+TgixSGrr8Ipd25o/pWe5B DMT5dKbqfEISXVwbiR25IbZGSJ7Z01MQcVyp+JJ71NcRlpBxmlrjYrw07fo1tzU8 8a5ZPMwT6FmBJIqS39ddFtxji0JEXEXim4qzczCmZLGVVv2QUYmMgc+IQx5PzMj9 bFztsVVWPNzI6lZlnLRC4yq1KqrKyDfynn81SW0M0KcXVoTuS2t/qVqxJGU7WTSZ v37vB0MubKRSFsHco3AWuyS0vrE4aQAWWWlg+5nycol8/ic1qeE= =qkTy -----END PGP SIGNATURE----- --=-gPovnkekFuPd+M6ujo25--