Date: Wed, 24 Aug 2011 21:49:09 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: if_ath - should it be compiled without ath_hal support? Message-ID: <CAGH67wRz6X=ZU0AZFM1G-fo=NKHNVV7SD547KD-BBp4VOofDaw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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 0xfffff, 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
3659 m->m_pkthdr.rcvif = ifp;
3660 m->m_pkthdr.len = len;
3661 }
3662
3663 ifp->if_ipackets++;
3664 sc->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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wRz6X=ZU0AZFM1G-fo=NKHNVV7SD547KD-BBp4VOofDaw>