"disappearing" ath(4)

[Adrian Chadd]

Okay. Lemme know if it does.

Also I hope we aren't enabling aspm yet. Argh.

Adrian
On Dec 21, 2013 8:49 PM, "Glen Barber" <gjb at freebsd.org> wrote:

> 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" <gjb at 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
> > >
> > >
>