----- Original Message ---- > From: Stuart Henderson <s...@spacehopper.org> > To: James Peltier <james_a_pelt...@yahoo.ca> > Cc: Andre Keller <a...@list.ak.cx>; misc@openbsd.org > Sent: Wed, September 22, 2010 12:31:43 PM > Subject: Re: em(4) ierrs [solved] <snip> > > 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.. >
Watching now. :)
