Re: "disappearing" ath(4)
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" 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" 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 > > > > > > > ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: "disappearing" ath(4)
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" 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 > > > > pgpU2upzRUJUc.pgp Description: PGP signature
Re: "disappearing" ath(4)
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" 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 > > ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: "disappearing" ath(4)
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 pgptVxwVdGbHl.pgp Description: PGP signature
Re: "disappearing" ath(4)
Hi so as I said to glen on IRC. The first possible issue here is that the NIC just disappears for some reason and all register reads are 0x. it's not that. The second possibility is that it's asleep - and no, NIC reads aren't showing 0xdeadc0de, 0xdeadbeef, etc. So no, it's not that. The fact that calibration fails like it does tends to indicate there's some kind of noise spur from somewhere that's pissing the NIC off. It's difficult to establish that without writing code to do capture/dump the raw ADC samples. He's also recently opened up his laptop and fiddled around. he's going off to do some more testing. -a On 20 December 2013 18:39, Glen Barber wrote: > On Fri, Dec 20, 2013 at 09:35:58PM -0500, Glen Barber wrote: >> Hi, >> >> Since last upgrade, it seems every few days (it seems roughly every >> 2 days), my ath(4) disappears, or more specifically, "falls off" enough >> to be unusable. >> > > Adrian pointed out that I forgot to include actually relevant > information. > > Machine runs .0-CURRENT r258761, the wireless card info from dmesg.boot > is: > > ath0: mem 0xde80-0xde80 irq 17 at device 0.0 on > pci2 > ath0: [HT] enabling HT modes > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 RX streams; 1 TX streams > ath0: AR9285 mac 192.2 RF5133 phy 14.0 > ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 > > Glen > ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: "disappearing" ath(4)
On Fri, Dec 20, 2013 at 09:35:58PM -0500, Glen Barber wrote: > Hi, > > Since last upgrade, it seems every few days (it seems roughly every > 2 days), my ath(4) disappears, or more specifically, "falls off" enough > to be unusable. > Adrian pointed out that I forgot to include actually relevant information. Machine runs .0-CURRENT r258761, the wireless card info from dmesg.boot is: ath0: mem 0xde80-0xde80 irq 17 at device 0.0 on pci2 ath0: [HT] enabling HT modes ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9285 mac 192.2 RF5133 phy 14.0 ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 Glen pgpJoQwIdWhvV.pgp Description: PGP signature
