Re: systems with -current wm(4) hang?

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

Thank you very mach for very detailed and lucid survey!

On 2016/05/27 0:23, John D. Baker wrote:
> Using "if_wm.c" r1.407,
> 
> A ThinkPad T42 with:
> 
> wm0 at pci2 dev 1 function 0: Intel i82540EP 1000BASE-T Ethernet (rev. 0x03)
snip
> 
> became unresponsive shortly after netbooting -current.  Following
> reboot, it hung again while performing 'etcupdate' processing.
> 
> 
> An IBM eServer x306, i386 with PCI/PCI-X busses has:
> 
> wm0 at pci1 dev 1 function 0: Intel i82547GI 1000BASE-T Ethernet (rev. 0x00)
snip
> wm1 at pci3 dev 3 function 0: Intel i82541GI 1000BASE-T Ethernet (rev. 0x00)
snip
> 
> and booting from "wm0" hangs during multiuser boot while building the
> "dev" database.
> 
> Booting from "wm1" completes multiuser boot and I was able to complete
> 'etcupdate' and 'postinstall' operations.  I built several packages
> (${WRKOBJDIR} on local disk), but it eventually hung too.
> 
> 
> An amd64-class machine (Dell Optiplex 760) with:
> 
> wm0 at pci0 dev 25 function 0: 82567LM-3 LAN Controller (rev. 0x02)
snip
> 
> Booting an installation built from sources around 201605182230Z, all
> seemed well.  Following an update to a system built from sources around
> 201605201620Z, the machine hung in "/etc/rc.d/fccache" during its first
> boot.  Although the terminal driver responded, one could not drop into
> DDB via the USB keyboard (system is USB-only until I can get the PS/2
> serial adapter cable).  ACPI powerdown via the power switch hung as well,
> so a forced power-off by holding the power button was required.
> 
> On the next boot, it completed startup but hung again during 'xdm'
> initialization requiring another forced power-cycle.  Since disabling
> 'xdm', the machine has now booted multiuser.  Further stress testing
> consisted of recursive 'pkg_delete' of old (GCC 4.8.5-built) packages
> in preparation for rebuilding with GCC 5.3.0.  It eventually hung.
> 
> Using the same machine to investigate:
> 
> wm0 at pci1 dev 0 function 0: Intel i82574L (rev. 0x00)
snip
> 
> booted without problems.  Stress testing building packages did not
> provoke a hang during the time I ran it (around 12 hours).
> 
> Again using the same machine to investigate:
> 
> wm1 at pci4 dev 0 function 0: Intel i82541PI 1000BASE-T Ethernet (rev. 0x05)
snip
> booted without problems.  Stress testing building packages hung rather
> soon after.
> 
> 
> A Dell PowerEdge 750 (i386) with PCI/PCI-X busses and:
> 
> wm0 at pci1 dev 1 function 0: Intel i82547GI 1000BASE-T Ethernet (rev. 0x00)
snip
> 
> wm1 at pci3 dev 2 function 0: Intel i82541GI 1000BASE-T Ethernet (rev. 0x00)
snip
> 
> booting from "wm0" hung during rebuilding "dev" database on first boot.
> As the machine has PS/2 keyboard attached, "Ctrl-Alt-ESC" allowed dropping
> to the debugger to reboot.  Subsequent boots with this interface hung in
> the same place.
> 
> Booting from "wm1" completed startup and 'etcupdate'/'postinstall'
> operations and completed its subsequent boot.  Further stress testing
> building packages ran for a long time, but halted when the machine
> spontaneously shut down and would not remain powered up.
> 
> 
> A Dell PowerEdge 2850 (amd64-class, PCI/PCI-X busses) with:
> 
> wm0 at pci6 dev 7 function 0: Intel i82541GI 1000BASE-T Ethernet (rev. 0x05)
snip
> 
> wm1 at pci7 dev 8 function 0: Intel i82541GI 1000BASE-T Ethernet (rev. 0x05)
snip
> 
> booting from "wm0" hung rebuilding the "dev" database during startup.
> 
> Booting from "wm1" passed the database rebuild but hung while updating
> fontconfig cache.  Subsequent reboot with "wm1" succeeded.  Further
> stress testing building packages eventually hung.
> 
> 
> A Dell PowerEdge SC430 (amd64-class, PCI/PCIe busses) with:
> 
> wm0 at pci2 dev 0 function 0: Intel PRO/1000 PT (82571EB) (rev. 0x06)
snip
> wm1 at pci2 dev 0 function 1: Intel PRO/1000 PT (82571EB) (rev. 0x06)
snip
> 
> booted from "wm0" without problems.  Stress testing building packages did
> not hang during my test period (about 12 hours).
> 
> The "wm1" interface on this card is not bootable.

These ethernet controllers apply to the condition which I think they
can hung. However, hmm, there are many hung patterns unexpectedly.
There can be another bug possibly...

> Now I will update sources (if_wm.c r1.409+) rebuild and see if the
> problem was fixed. 

I expect for if_wm.c r1.409 to resolve the problem for all of above NICs.


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>