Date: Wed, 29 Jun 2011 08:03:36 +0200 From: Bernhard Schmidt <bschmidt@freebsd.org> To: freebsd-current@freebsd.org Cc: Stefan Esser <st_esser@t-online.de>, Adrian Chadd <adrian@freebsd.org> Subject: Re: Panic in ieee80211 tx mgmt timeout Message-ID: <201106290803.36647.bschmidt@freebsd.org> In-Reply-To: <BANLkTiknrezs%2BsxC4x9KcM0LJSs_fU_mdg@mail.gmail.com> References: <4E099EB2.7050902@freebsd.org> <BANLkTiknrezs%2BsxC4x9KcM0LJSs_fU_mdg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, June 29, 2011 03:50:08 Adrian Chadd wrote: > This is kinda strange; that symbol doesn't exist in the net80211 or ath source. > > What the heck? > > > > adrian > > > > On 28 June 2011 17:28, Stefan Esser <st_esser@t-online.de> wrote: > > Hi, > > > > is this a known issue? > > > > My -CURRENT system (r223560M, amd64, 8GB, Atheros WLAN) panics after > > minutes to hours of uptime with the following message: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 0 > > fault virtual address = 0xffffff807f502000 > > fault code = supervisor data read, page not present > > ... > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 11 (swi4: clock) > > [ thread pid 11 tid 1000012 ] > > Stopped at ieee80211_tx_mgmt_timeout+0x1: movq (%rdi),%rdi > > > > db> bt > > Tracing pid 11 tid 100012 td 0xfffffe00032e0000 > > ieee80211_tx_mgmt_timeout() at ieee80211_tx_mgmt_timeout+0x1 > > intr_event_execute_handlers() at intr_event_execute_handlers+0x66 > > ithread_loop() at ithread_loop+0x96 > > fork_exit() at fork_exit+0x11d > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xffffff8000288d00, rbp = 0 --- > > > > This panic message is manually transcribed, since the GPT-only > > partitioning prevents dumping of a kernel core. (Why, BTW?) > > I could add a swap partition on a MBR disk, if a core dump seems > > neccessary to diagnose the problem. I'm also willing to wait for that > > panic to occur again and to gather more debug output. > > > > > > Other information: The Atheros WLAN in this system is unused (not > > associated) but both ath0 and wlan0 were "UP" at the time of the panic. > > > > Initial testing shows the system to be stable with both wlan0 and ath0 > > set to "down" after boot. But still, the timeout should not panic the > > kernel, if WLAN is active but not fully configured (e.g. no SSID). > > > > Any ideas? It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC requests. Afaik there is even a similar PR about that. Adrian, you've got a AP set up to drop either a AUTH or ASSOC response frame? -- Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106290803.36647.bschmidt>