On Mon, 03 Dec 2018 13:19:20 -0800 Jeff Kirsher <jeffrey.t.kirs...@intel.com> wrote:
> 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 > > > > After suspend/resume cycle, IP address is lost. > > > > Device Info: > > $ /sbin/ethtool -i enp12s0 > > driver: igb > > version: 5.4.0-k > > firmware-version: 0. 6-1 > > expansion-rom-version: > > bus-info: 0000:0c:00.0 > > supports-statistics: yes > > supports-test: yes > > supports-eeprom-access: yes > > supports-register-dump: yes > > supports-priv-flags: yes > > > > > > $ 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=128K] > > I/O ports at c000 [size=32] > > Memory at dfb20000 (32-bit, non-prefetchable) [size=16K] > > Capabilities: <access denied> > > Kernel driver in use: igb > > Kernel modules: igb > > > > State before suspend: > > $ ip addr show dev enp12s0 > > 4: enp12s0: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 > > > > State after resume: > > > > $ ip addr show dev enp12s0 > > 4: enp12s0: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 > > > > Doing ifdown/ifup which restarts the DHCP client does restore the > > address. > > > > 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. > 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. Great, thanks. I will reproduce with latest update, and file Debian bug.
