Re: if_ath - should it be compiled without ath_hal support?
On Wed, Aug 24, 2011 at 10:37 PM, Adrian Chadd adr...@freebsd.org wrote:
Hi,
...
Well, the ath_hal code should be built in as part of the ath module.
ath needs ath_hal to speak to the MAC/baseband/radio. There's no need
for #ifdef's to guard them as .. well, they're needed.
Ok.
I'd like to eventually split out the ath_hal again into a separate
module and re-instate the separation between HAL and driver code
(primarily to enforce cleaner code and more stable APIs.)
Good to know. I was just a bit confused with the manpages that say
they're optional after I discovered looking at the driver that they're
hardwired in.
If you're seeing issues like the above, chances are that you're seeing
some corruption. Can you please print out the whole value of *rs (ie,
all the fields of the ath_rx_status struct) so I can see how valid it
is?
Sure:
(kgdb) p *rs
$1 = {rs_datalen = 244, rs_status = 0 '\0', rs_phyerr = 0 '\0',
rs_rssi = 0 '\0', rs_keyix = 127 '\177', rs_rate = 27 '\033', rs_more
= 0 '\0', rs_tstamp = 2097280, rs_antenna = 8399232, rs_rssi_ctl =
0\200), rs_rssi_ext = \200\000\037, rs_isaggr = 1 '\001',
rs_moreaggr = 1 '\001', rs_num_delims = 0 '\0', rs_flags = 252 'ü',
rs_evm0 = 0, rs_evm1 = 0, rs_evm2 = 0, rs_evm3 = 0, rs_evm4 = 0}
Thanks!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: if_ath - should it be compiled without ath_hal support?
that looks a bit special.
On 29 August 2011 07:38, Garrett Cooper yaneg...@gmail.com wrote:
I'd like to eventually split out the ath_hal again into a separate
module and re-instate the separation between HAL and driver code
(primarily to enforce cleaner code and more stable APIs.)
Good to know. I was just a bit confused with the manpages that say
they're optional after I discovered looking at the driver that they're
hardwired in.
I plan on fleshing out the driver documentation in the Wiki a little more.
Like everything, all I need is time. :)
If you're seeing issues like the above, chances are that you're seeing
some corruption. Can you please print out the whole value of *rs (ie,
all the fields of the ath_rx_status struct) so I can see how valid it
is?
Sure:
(kgdb) p *rs
$1 = {rs_datalen = 244, rs_status = 0 '\0', rs_phyerr = 0 '\0',
rs_rssi = 0 '\0', rs_keyix = 127 '\177', rs_rate = 27 '\033', rs_more
= 0 '\0', rs_tstamp = 2097280, rs_antenna = 8399232, rs_rssi_ctl =
0\200), rs_rssi_ext = \200\000\037, rs_isaggr = 1 '\001',
rs_moreaggr = 1 '\001', rs_num_delims = 0 '\0', rs_flags = 252 'ü',
rs_evm0 = 0, rs_evm1 = 0, rs_evm2 = 0, rs_evm3 = 0, rs_evm4 = 0}
It doesn't look like garbage to begin with .. and then it does.
How have you compiled it? Some of those fields are currently optional
(ie, require the AR5416 (11n) support to be enabled) - have you
somehow managed to compile part of the code with it, part of the code
without it?
Which NIC is this for again? AR9285?
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: if_ath - should it be compiled without ath_hal support?
On Sun, Aug 28, 2011 at 5:21 PM, Adrian Chadd adr...@freebsd.org wrote:
that looks a bit special.
On 29 August 2011 07:38, Garrett Cooper yaneg...@gmail.com wrote:
I'd like to eventually split out the ath_hal again into a separate
module and re-instate the separation between HAL and driver code
(primarily to enforce cleaner code and more stable APIs.)
Good to know. I was just a bit confused with the manpages that say
they're optional after I discovered looking at the driver that they're
hardwired in.
I plan on fleshing out the driver documentation in the Wiki a little more.
Like everything, all I need is time. :)
If you're seeing issues like the above, chances are that you're seeing
some corruption. Can you please print out the whole value of *rs (ie,
all the fields of the ath_rx_status struct) so I can see how valid it
is?
Sure:
(kgdb) p *rs
$1 = {rs_datalen = 244, rs_status = 0 '\0', rs_phyerr = 0 '\0',
rs_rssi = 0 '\0', rs_keyix = 127 '\177', rs_rate = 27 '\033', rs_more
= 0 '\0', rs_tstamp = 2097280, rs_antenna = 8399232, rs_rssi_ctl =
0\200), rs_rssi_ext = \200\000\037, rs_isaggr = 1 '\001',
rs_moreaggr = 1 '\001', rs_num_delims = 0 '\0', rs_flags = 252 'ü',
rs_evm0 = 0, rs_evm1 = 0, rs_evm2 = 0, rs_evm3 = 0, rs_evm4 = 0}
It doesn't look like garbage to begin with .. and then it does.
How have you compiled it? Some of those fields are currently optional
(ie, require the AR5416 (11n) support to be enabled) - have you
somehow managed to compile part of the code with it, part of the code
without it?
Just
options ATH_DEBUG
in my $KERNCONF and I built the ath and ath_pci modules.
Which NIC is this for again? AR9285?
Yup:
ath0@pci0:2:0:0:class=0x028000 card=0x10891a3b chip=0x002b168c
rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR9285 Wireless Network Adapter (PCI-Express)'
class = network
Thanks!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: if_ath - should it be compiled without ath_hal support?
On 29 August 2011 08:42, Garrett Cooper yaneg...@gmail.com wrote: Which NIC is this for again? AR9285? Yup: Hm, the code which sets rs_antenna should set it to something valid (in ar5416/ar5416_recv.c) : rs-rs_antenna = MS(ads-ds_rxstatus3, AR_RxAntenna); and that's an 24 bit field. And that code needed to be called and have it return HAL_OK for it to be used. So somehow your antenna configuration at the time of the crash was .. strange. Let me see why exactly that would have such a configuration and I'll get back to you. (It may be that a simple array bounds check is enough.) Adrian Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: if_ath - should it be compiled without ath_hal support?
Hi, On 25 August 2011 12:49, Garrett Cooper yaneg...@gmail.com wrote: I ran into the panic shown below because it appears that some array indexing went off into the weeds. I haven't seen this happen but once though when running a buildworld last night using r225089 on i386. This begs the question - is it wise to compile if_ath without ath_hal support today? I've been doing this recently because ath_hal isn't available under /sys/modules , and unless I unload the module, things like suspend and resume don't work because if_ath doesn't support suspend/resume yet). There are a lot of references to the ath_hal APIs in if_ath.c now that don't have #ifdefs guarding them as well which concern me.. Well, the ath_hal code should be built in as part of the ath module. ath needs ath_hal to speak to the MAC/baseband/radio. There's no need for #ifdef's to guard them as .. well, they're needed. I'd like to eventually split out the ath_hal again into a separate module and re-instate the separation between HAL and driver code (primarily to enforce cleaner code and more stable APIs.) If you're seeing issues like the above, chances are that you're seeing some corruption. Can you please print out the whole value of *rs (ie, all the fields of the ath_rx_status struct) so I can see how valid it is? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
