Date: Wed, 24 Oct 2012 08:18:34 -0400 From: Justin Hibbits <chmeeedalf@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-wireless@freebsd.org Subject: Re: data storage interrupt with if_ath(4) on PowerPC Message-ID: <CAHSQbTCJr7PZOC1x-NJt0PbS5ZZQ8CEeV47oWXQQXS2Ym5079Q@mail.gmail.com> In-Reply-To: <CAJ-VmomP8xxXrsLOoNsMJULx7jXUkikA8p%2BM6Aw8hKjaVk8XFQ@mail.gmail.com> References: <20121023230652.206fb4ea@narn.knownspace> <CAJ-VmomP8xxXrsLOoNsMJULx7jXUkikA8p%2BM6Aw8hKjaVk8XFQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 23, 2012 at 11:37 PM, Adrian Chadd <adrian@freebsd.org> wrote: > On 23 October 2012 20:06, Justin Hibbits <chmeeedalf@gmail.com> wrote: > > With an Atheros 5416 card from Adrian Chadd in my PowerBook G4, I get a > > Data Storage Interrupt after a few minutes. It's pretty reproducible: > > > > * load if_ath/if_ath_pci > > * ifconfig wlan0 create wlandev ath0 > > * ifconfig wlan0 up > > * ifconfig wlan0 bgscan (fails with "Operation not supported") > > * ifconfig wlan0 list scan > > ... wait ... > > * ifconfig wland0 list scan (another just for good measure) > > ... wait ... > > > > After a few minutes it kernel panics. > > Ew! > Ew indeed. > > > I've attached the dcons ddb session output. Quick synopsis: It > > crashes in memcpy() crossing a page boundary. Backtrace: > > Is that actually a bad thing? What's a "data storage interrupt" ? > In this case it is a bad thing, otherwise it wouldn't panic :). Think of it as the equivalent of an x86 'page fault in kernel mode'. > > Adrian > > > fatal kernel trap: > > > > exception = 0x300 (data storage interrupt) > > virtual address = 0xd1b72000 > > srr0 = 0x5d44b4 > > srr1 = 0x9032 > > lr = 0xd1ab0fa4 > > curthread = 0x189fbc0 > > pid = 0, comm = ath0 net80211 taskq > > > > Tracing pid 0 tid 100075 td 0x189fbc0 > > 0xe21139f4: at m_pkthdr_init+0x5c > > 0xe2113a14: at ieee80211_send_probereq+0x14c > > 0xe2113a74: at ieee80211_probe_curchan+0x11c > > 0xe2113aa4: at scan_curchan+0x7c > > 0xe2113ac4: at scan_task+0x29c > > 0xe2113b14: at taskqueue_run_locked+0xd4 > > 0xe2113b44: at taskqueue_thread_loop+0x6c > > 0xe2113b64: at fork_exit+0x88 > > 0xe2113b84: at fork_trampoline+0xc > > > > The m_pkthdr_init in the backtrace is misleading, I think. > > > > I can provide any more data that's needed. > > > > > > - Justin > - Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTCJr7PZOC1x-NJt0PbS5ZZQ8CEeV47oWXQQXS2Ym5079Q>