I doubt lagg(4) is the issue.  I've been doing that evil for years.

I'll kill the *_cs_lowest, and see if that changes anything over the
next few days.

I'm 200% certain lagg(4) is not a factor, but if it continues, I'll
disable that for S&G.

Glen

On Sat, Dec 21, 2013 at 06:44:16PM -0800, Adrian Chadd wrote:
> Yeah. Try killing those. Leave it at c1 and no lagg. C2 and later may be
> triggering some weird stuff.
> 
> Adrian
> On Dec 21, 2013 8:33 PM, "Glen Barber" <g...@freebsd.org> wrote:
> 
> > On Sat, Dec 21, 2013 at 08:17:32AM -0800, Adrian Chadd wrote:
> > > The second possibility is that it's asleep - and no, NIC reads aren't
> > > showing 0xdeadc0de, 0xdeadbeef, etc. So no, it's not that.
> > >
> >
> > I didn't think of this when you first mentioned it, but I recently added
> > this to rc.conf:
> >
> >   performance_cx_lowest="C2"
> >   economy_cx_lowest="C2"
> >
> > Another thing I failed to mention, is the ath(4) is part of lagg(4),
> > accompanied by alc(4).
> >
> > I'm half wondering if the *_cx_lowest is triggering something.  The
> > other half wonders if lagg(4) triggers something funky.
> >
> > > He's also recently opened up his laptop and fiddled around.
> > >
> >
> > "Trust me, I'm an engineer!"
> >
> > > he's going off to do some more testing.
> > >
> >
> > "What can possibly go wrong?"
> >
> > Glen
> >
> >

Attachment: pgpU2upzRUJUc.pgp
Description: PGP signature

Reply via email to