>Number:         10359
>Category:       kern
>Synopsis:       fxp driver gets "device timeout"
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 13 20:22:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Hal Murray
>Release:        1.4Z
>Organization:
        Systems Research Center, Compaq Computer Corporation
>Environment:
Alpha
System: NetBSD mckinley 1.4Z NetBSD 1.4Z (MIATA) #4: Fri Jun 9 04:01:32 PDT 2000
 murray@mckinley:/usr/src/sys/arch/alpha/compile/MIATA alpha


>Description:

(from a driver that was modified to print more info)

Jun 13 20:15:14 foraker /netbsd: fxp2: device timeout: txdirty=3, txpending=128, snd.ifq_len=50
Jun 13 20:16:09 foraker /netbsd: fxp2: device timeout: txdirty=96, txpending=128, snd.ifq_len=50
Jun 13 20:16:14 foraker /netbsd: fxp2: device timeout: txdirty=96, txpending=128, snd.ifq_len=30
Jun 13 20:16:20 foraker /netbsd: fxp2: device timeout: txdirty=65, txpending=128, snd.ifq_len=50
Jun 13 20:16:25 foraker /netbsd: fxp2: device timeout: txdirty=51, txpending=128, snd.ifq_len=22

I have some tests that provoke this problem without dropping any 
packets.  I think that means the packets are getting sent correctly 
but the cleanup routine isn't getting called. 

I've never seen it happen when txpending wasn't 128.

I haven't noticed any troubles with similar gear and tests on i386. 

>How-To-Repeat:

        I think any heavy network activity will do it if you wait 
        a while.  I've seen it on moderate activity too.  Most of 
        my tests will make it happen in under a minute. 


>Fix:
        ??

>Release-Note:
>Audit-Trail:
>Unformatted: