Date: Sun, 18 May 2003 15:01:03 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Gabriel Tataranu <tgabi@belent.com> Cc: freebsd-bugs@freebsd.org Subject: Re: fxp driver lockups on 4.8r Message-ID: <Pine.NEB.3.96L.1030518145713.42953c-100000@fledge.watson.org> In-Reply-To: <200305161758.08030.tgabi@belent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
> To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030518145713.42953c-100000>