amd64/82425: fxp0: device timeout, fxp interface dies on 5.4/amd64/smp under load

[Christian]

>Number:         82425
>Category:       amd64
>Synopsis:       fxp0: device timeout, fxp interface dies on 5.4/amd64/smp under load
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-amd64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jun 19 18:40:18 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Christian
>Release:        FreeBSD 5.4-STABLE
>Organization:
>Environment:
FreeBSD nox.internal.net 5.4-STABLE FreeBSD 5.4-STABLE #2: Sat Jun 18 22:29:48 BST 2005     root at nox.internal.net:/usr/obj/usr/src/sys/NOX  amd64

>Description:
With the machine operating as a server under greater than moderate network traffic load, the fxp interface becomes dysfunctional, printing a message "fxp0: device timeout" on the console. While fxp0 is still marked 'up' as per ifconfig, it doesn't tx/rx any traffic at all. The machine also no longer responds to external pings.

The problem machine is a dual-Opteron system, running an SMP kernel.
>How-To-Repeat:
option 1: using the rsync port. Using a second machine, attempt to perform a large rsync to the problem machine. Attempting to send a Maildir mail folder hierarchy with about 318MB in about 36000 files causes fxp0 on the problem machine to die, sometimes only a few dozen files into the rsync.

option 2: using nfs. Setup the problem machine as an nfs server, and attempt to copy the above mail directory to the nfs share on the problem machine. fxp0 on the problem machine will die with "fxp0: device timeout".
>Fix:
no fix known, rebooting the problem machine brings fxp0 back to life.
>Release-Note:
>Audit-Trail:
>Unformatted: