> > I, unfortunately, am still experiencing livelocks on my em interfaces on my
>Dell
>
> > R200 server in bridging mode. I'm going to have to schedule an upgrade to
>the
>
> > latest snapshot first to see if that clears up any issues, but barring that
>I'm
>
> > not sure where to look. Perhaps I'll also try the UP kernel.
>
> the "livelock" counter means a timeout wasn't reached in time,
> indicating the system being too busy to run userland.
> (see m_cltick(), m_cldrop() etc in sys/kern/uipc_mbuf.c,
> and the video from asiabsdcon starting about 15 minutes into
>
http://www.youtube.com/watch?v=fv-AQJqUzRI).
>
> when this happens, nics with drivers using the MCLGETI mechanism
> halve the size of their receive rings, so that packets drop
> earlier, more effectively limiting system load than if they
> were allowed to proceed up the network stack.
>
> so for some reason or other the timeout wasn't processed
> quickly enough and the system responds in this way to limit
> the overload. so the challenge is to identify what causes
> the system to become non-responsive (could be in the network
> stack or could be for other reasons) and work out ways
> to alleviate that..
>