Date: Fri, 14 Apr 2017 10:46:17 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 218653] Intel e1000 network link drops when running freebsd-update to upgrade from 10.3 to 11.0 Message-ID: <bug-218653-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218653 Bug ID: 218653 Summary: Intel e1000 network link drops when running freebsd-update to upgrade from 10.3 to 11.0 Product: Base System Version: 10.3-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: freebsd@t.lastninja.net This is a little difficult to articulate. So at a high-level this is the is= sue I'm seeing: 1. initiate a freebsd-update to upgrade from 10.3-RELEASE to 11.0-RELEASE 2. when metadata files are fetched (using phttpget), the network link completely drops out 3. the ethernet watchdog timer (i assume) detects activity has stalled and drops the queue, disables the link, and enables the link 4. when the link is restored, gunzip fails decompressing the metadata file = and is deemed corrupt, and freebsd-update fails. The hardware I'm running is dated, specifically a supermicro server with a PDSMi motherboard with 2x onboard Intel gigabit NICs. # pciconf -lv | grep em0 -A4 em0@pci0:13:0:0: class=3D0x020000 card=3D0x108c15d9 chip=3D0x108c808= 6 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82573E Gigabit Ethernet Controller (Copper)' class =3D network subclass =3D ethernet [...] # dmesg | grep -i em0 em0: <Intel(R) PRO/1000 Network Connection 7.6.1-k> port 0x4000-0x401f mem 0xe0200000-0xe021ffff irq 16 at device 0.0 on pci13 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:8b:55:de [...] When I run freebsd-update to upgrade from 10.3-RELEASE-p18 to 11.0-RELEASE = the network link drops. This happens specifically when the metadata files are b= eing fetched. I have also removed /var/db/freebsd-update/*.gz to see if that wou= ld fix it, but that didn't do much. I recall also having the same network link drops when I was previously on 9= .1 and upgrading to 10.3. During the "fetching files" phase, it would simply d= rop the network link; freebsd-update was however resilient enough to continue trying until it received the files and performed the upgrade. # freebsd-update upgrade -r 11.0-RELEASE=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 Looking up update.FreeBSD.org mirrors... 4 mirrors found. Fetching metadata signature for 10.3-RELEASE from update5.freebsd.org... do= ne. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic world/base world/doc world/games world/lib32 The following components of FreeBSD do not seem to be installed: Does this look reasonable (y/n)? y Fetching metadata signature for 11.0-RELEASE from update5.freebsd.org... do= ne. Fetching metadata index... done. Fetching 1 metadata patches. done. Applying metadata patches... done. Fetching 1 metadata files... gunzip: (stdin): unexpected end of file metadata is corrupt. # dmesg | tail -n 14 em0: Watchdog timeout Queue[0]-- resetting Interface is RUNNING and ACTIVE em0: TX Queue 0 ------ em0: hw tdh =3D 381, hw tdt =3D 387 em0: Tx Queue Status =3D -2147483648 em0: TX descriptors avail =3D 1018 em0: Tx Descriptors avail failure =3D 0 em0: RX Queue 0 ------ em0: hw rdh =3D 94, hw rdt =3D 93 em0: RX discarded packets =3D 0 em0: RX Next to Check =3D 94 em0: RX Next to Refresh =3D 93 em0: link state changed to DOWN em0: link state changed to UP --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-218653-8>