Re: Possible fxp(4) problem in -CURRENT

From: Bill Paul (wpaul_at_FreeBSD.ORG)
Date: 10/18/05

  • Next message: FreeBSD Tinderbox: "[head tinderbox] failure on i386/i386" 
    To: dan@mail.neosystem.cz (Dan Bilik)
Date: Tue, 18 Oct 2005 20:30:12 +0000 (GMT)

    > On Mon, 17 Oct 2005 11:46:55 +0200
    > Dan Bilik <dan@mail.neosystem.cz> wrote:
    >
    > > Situation:
    > > Single-purpose machines only serving http requests for static content,
    > > ...
    > > Problem:
    > > After some time of serving requests the ethernet interface in the
    > > machine stops communicating on the wire. It does not respond to any
    > > packets (ping, http, nfs, ssh) and vmstat(8) shows stopped interrupt
    > > ...
    >
    > Some fresh additional info:
    >
    > Today one of the problem machines got stuck again. I was able to log on
    > through second functional interface and watch it more closely. Sending
    > packets from the box worked (its arp requests were appearing on other
    > boxes in the subnet) but it could not receive any packet. And another
    > thing... It seems that running tcpdump (ie. entering and leaving
    > promiscuous mode) on the interface resolved the problem
    > and made the machine to appear back on the network. It's running
    > with no problem from that moment.
    >
    > Any ideas what's going on here? Does it make sense to anyone?
    >
    > Dan

    With the fxp driver, running entering promiscuous mode implies
    reinitializing the NIC from the ground up. The fxp_ioctl() handler
    will call fxp_init() when any of the flags change, like IFF_PROMISC,
    so running tcpdump is equivalent to doing "ifconfig fxp0 up" in
    this case. It should come as no surprise that reinitializing
    the card brings it back to life.

    There's a couple reasons why you could be getting into this state:

    - The chip has experienced an RX overrun, where all of the descriptors
      in its RX DMA ring have been filled by the chip before the driver
      has had a chance to drain them. When this happens, the chip may
      require the RX unit to be resumed.

    - For some reason, the RX handler code in the driver has fallen out
      of sync with the chip, i.e. the current descriptor index has gotten
      clobbered, or maybe the chip was restarted and the index wasn't properly
      reset.

    In both of these cases, calling fxp_init() will reinitialize the RX
    unit and get the chip working again.

    RX overruns are obviously the result of a very busy network (or a very
    busy host processor that can't service the NIC frequently enough to
    drain the RX ring). If the network is busy, it would be with a lot of
    small packets. With heavy streaming traffic, you'd get a lot of large
    frames, and with 1500 byte frames you max out a 100Mbps ethernet at
    only about 8100 frames/second. By contrast, it takes 148000 frames/sec
    to max out a 100Mbps pipe with 64 byte frames.

    Ideally, the driver should recover gracefully from an RX overrun, though
    I'll bet a quarter nobody's really tested it very thoroughly. ("I can
    browse the intarweb so it must be ok!") Also, I discovered recently
    that the chip can do really strange things if you make the mistake
    of issuing an RX unit start command twice, instead of just once.
    (If you do this, it's apparently possible for the chip to DMA into
    the same packet buffer twice, which has the effect of clobbering a
    packet after it's already been passed to the stack for processing.)

    You should run vmstat -i or something to monitor the interrupt rate
    on the failing interface and see if it peaks right before it goes
    deaf.

    -Bill 

    --
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul@windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: FreeBSD Tinderbox: "[head tinderbox] failure on i386/i386"

    Relevant Pages

    • Re: Nmap questions concering my router
      ... that may have to be fetched) is downloaded as one connection. ... >> all addresses (and may listen using just one interface to receive all ... sends packets to the correct protocol driver ... wire to an IP packet, and hands this to the IP driver which strips off ...
      (comp.security.firewalls)
    • Re: Stuck creating sysfs hooks for a driver..
      ... You must stay away from writing a driver for the board itself. ... 1* A driver for the SPI interface of your board (basically a parallel ... port SPI bridge). ... This driver doesn't care about what chip is ...
      (Linux-Kernel)
    • mbuf/mbuf cluster adjustments (bcm driver)
      ... I've finally managed to get back to work on the bcm driver for Broadcom 440x ... chip prepends to an incoming packet. ... the driver preallocates a load of mbuf clusters for the chip to ... I don't think it is meant for use with mbuf clusters. ...
      (freebsd-hackers)
    • Re: [PATCH] Ethernet cleanup; 802.1p input and M_PROMISC
      ... shouldn't call ether_inputif the interface isn't running. ... important IFF_DRV_RUNNING state is checked outside of a driver. ... source of synthetic traffic decides to inject a packet as though ... If all callers of ether_inputwere in real and conformant ...
      (freebsd-net)
    • Re: How do I name my network interface?
      ... >> Having done that I conclude it is a Realtek 8201BL chip. ... >> be another rl interface, ... > The re nor the rl driver seem to support the 8201BL. ...
      (freebsd-questions)
    Loading