fxp driver lockups on 4.8r

[Robert Watson]

On Fri, 16 May 2003, Gabriel Tataranu wrote:

> 	I'd like to report strange behavior of fxp driver on 4.8r. The hardware 
> configuration is:
> 	- Intel D845GERG2L motherboard (lan on board)
> 	- Pentium 4 processor and PC2700 memory
> 	- Adaptec 29160N with Seagate 15k3 drives
> 	- 3Com 905C nic
> 	- IDE CDROM
> 
> Once the system has load on intel nic (on the motherboard) and discs
> (like rsync a large directory from a server) the system locks-up
> (console becomes not responsive), the nic is broadcasting IP storms at
> full capacity (so hard that the network switch lock-up) and the disk LED
> is solid bright red (during regular disk access the LED can be solid red
> but not so bright). 

Are you sure it's an IP storm?  Could you send a tcpdump with a few sample
packets from another machine?  I suspect strongly the symptom you're
seeing is that the OS (for whatever reason) has ceased to process fxp
interrupts, and as a result the fxp card has started to spew our link
layer flow control packets.  I run into the same problem when my system
drops into DDB, and ceases to respond.  I recently committed a tunable to
-current to disable flow control for the card.  Note: this is not the same
as solving the source of the problem, which is presumably a bug somewhere,
but this would prevent your switch from hanging when this happens.  To
force your fxp card not to enable flow control (which may be a reasonable
default), find the following lines in src/sys/dev/fxp/if_fxp.c:

        cbp->multi_ia =         0;      /* (don't) accept multiple IAs */
        cbp->mc_all =           sc->flags & FXP_FLAG_ALL_MCAST ? 1 : 0;
 
        if (sc->revision == FXP_REV_82557) {
                /*
                 * The 82557 has no hardware flow control, the values  
                 * below are the defaults for the chip.
                 */

Replace the if statement with:

	if (1) {

This will always disable flow control.  Then comes the second question,
which is why this happened in the first place, but this may be a lot
easier to diagnose without your fxp card going nuts.  I suggest compiling
your kernel with "options DDB" and seeing if you can break into the
debugger when it appears hung. 

> 	The same operation on 3Com card is OK. Same operation on 4.6.2r
> and 4.7r is again OK. The system has no IRQ conflicts. 
> 
> 	I cannot provide a system log since the only way I can restore
> the system to sanity is cold reboot. There are no indication of kernel
> panics (the console just "freeze").
> 
> 	I can provide other details / run some scripts upon request. 
> 
> Regards,
> 
> Gabriel
> _______________________________________________
> freebsd-bugs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
> To unsubscribe, send any mail to "freebsd-bugs-unsubscribe at freebsd.org"
>