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 > > > >
Description: PGP signature