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
if_ath - should it be compiled without ath_hal support?
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.. TIA! -Garrett Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc5ec97f0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0c58968 stack pointer = 0x28:0xd87e2bfc frame pointer = 0x28:0xd87e2c78 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (ath0 taskq) Physical memory: 1001 MB Dumping 103 MB: 88 72 56 40 24 8 ... (kgdb) list 3659m-m_pkthdr.rcvif = ifp; 3660m-m_pkthdr.len = len; 3661} 3662 3663ifp-if_ipackets++; 3664sc-sc_stats.ast_ant_rx[rs-rs_antenna]++; 3665 3666/* 3667 * Populate the rx status block. When there are bpf 3668 * listeners we do the additional work to provide (kgdb) p sc-sc_stats.ast_ant_rx $6 = {0, 3458, 0, 0, 0, 0, 0, 0} (kgdb) p rs-rs_antenna $7 = 8399232 (kgdb) ___ 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