Hi,
Ok, it looks like it's something deep in the ndis driver itself, and
it's likely that we've not set it all up right.
Trouble is, no, you likely won't get symbols from the .dll. :-) So
someone who likes assembly and can read the NDIS spec needs to figure
it out.
Sorry!
-a
On 29 July 2016
On 07/20/2016 15:34, Adrian Chadd wrote:
it's doing that for transmitting packets. can you load the crashdump
into kgdb and get a debug backtrace?
and/or /var/crash/core.txt.X ?
Hi Adrian,
My kgdb kernel crash stack is below.
Do you know is there a way to also generate .symbols file for
oh god damint, wait. It's an AR9227, right?
ok, please just twist my arm to figure out and commit the "am i deaf?
restart please" workaround I think i need for the AR9227/AR9287. Grr.
-a
___
freebsd-wireless@freebsd.org mailing list
On 29 Jul 2016, at 22:43, Adrian Chadd wrote:
> oh god damint, wait. It's an AR9227, right?
Yep.
> ok, please just twist my arm to figure out and commit the "am i deaf?
> restart please" workaround I think i need for the AR9227/AR9287. Grr.
Sorry! If it helps I’m
On Fri, Jul 29, 2016 at 01:43:20PM -0700, Adrian Chadd wrote:
> oh god damint, wait. It's an AR9227, right?
>
> ok, please just twist my arm to figure out and commit the "am i deaf?
> restart please" workaround I think i need for the AR9227/AR9287. Grr.
>
Consider your arm twisted.
Glen
Well after a week of running 11 (BETA1 r303134) I think sadly its worse than
10. No more bf_next errors. Still lots of "ath0: stuck beacon; resetting (bmiss
count 4)”. The main thing though is the the clients drop of the network and
can’t reattach.
Sometimes restarting hostapd is all that is
Hi,
Yeah, the problem is that the NF calibration will time out, and I
don't know if it's logging that by default.
Do sysctl dev.ath.0.hal.debug=0x8 and then see what it lsogging when
things hang.
Thanks!
-adrian
___
freebsd-wireless@freebsd.org