Date: Sat, 12 Sep 2015 15:32:30 +0300 From: Alexander V. Chernikov <melifaro@freebsd.org> To: hiren panchasara <hiren@strugglingcoder.info>, Hans Petter Selasky <hps@selasky.org> Cc: "freebsd-current@FreeBSD.org" <freebsd-current@freebsd.org>, "jch@FreeBSD.org" <jch@freebsd.org> Subject: Re: Panic on kldload/kldunload in/near callout Message-ID: <1405441442061150@web27j.yandex.ru> In-Reply-To: <20150911232154.GS64965@strugglingcoder.info> References: <20150910192351.GF64965@strugglingcoder.info> <55F27D68.6080501@selasky.org> <20150911232154.GS64965@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
12.09.2015, 02:22, "hiren panchasara" <hiren@strugglingcoder.info>: > On 09/11/15 at 09:06P, Hans Petter Selasky wrote: >> On 09/10/15 21:23, hiren panchasara wrote: >> > I am on 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r286760M: Thu Sep 10 >> > 08:15:43 MST 2015 >> > >> > I get random (1 out of 10 tries) panics when I do: >> > # kldunload dummynet ; kldunload ipfw ;kldload ipfw ; kldload dummynet >> > >> > I used to get panics on a couple months old -head also. >> > >> > kernel trap 12 with interrupts disabled >> > >> > Fatal trap 12: page fault while in kernel mode >> > cpuid = 0; apic id = 00 >> > fault virtual address = 0xffffffff8225cf58 >> > fault code = supervisor read data, page not present >> > instruction pointer = 0x20:0xffffffff80aad500 >> > stack pointer = 0x28:0xfffffe1f9d588700 >> > frame pointer = 0x28:0xfffffe1f9d588790 >> > code segment = base 0x0, limit 0xfffff, type 0x1b >> > = DPL 0, pres 1, long 1, def32 0, gran 1 >> > >> > Following https://www.freebsd.org/doc/faq/advanced.html, I did: >> > # nm -n /boot/kernel/kernel | grep ffffffff80aad500 >> > # nm -n /boot/kernel/kernel | grep ffffffff80aad50 >> > # nm -n /boot/kernel/kernel | grep ffffffff80aad5 >> > # nm -n /boot/kernel/kernel | grep ffffffff80aad >> > ffffffff80aad030 t itimers_event_hook_exec >> > ffffffff80aad040 t realtimer_expire >> > ffffffff80aad360 T callout_process >> > ffffffff80aad6b0 t softclock_call_cc >> > ffffffff80aadc10 T softclock >> > ffffffff80aadd20 T timeout >> > ffffffff80aade90 T callout_reset_sbt_on >> > >> > So I guess " ffffffff80aad360 T callout_process" is the closest match? >> > >> > I'll try to get real dump to get more information but that may take a >> > while. >> > >> > ccing jch and hans who've been playing in this area. >> >> Hi, >> >> Possibly it means some timer was not drained before the module was >> unloaded. It is not enough to only stop timers before freeing its >> memory. Or maybe a timer was restarted after drain. >> >> Can you get the full backtrace and put debugging symbols into the kernel? > > I'll try to get it. Meanwhile I am getting another panic on idle box: > http://pastebin.com/9qJTFMik The easiest explanation could be lack of lla_create() result check, fixed in r286945. This panic is triggered by fast interface down-up (or just up), when ARP packet is received but there are no (matching) IPv4 prefix on the interface. If this is not the case (e.g. it paniced w/o any interface changes and there were no other subnets in given L2 segment) I'd be happy to debug this further. > > This "looks" similar to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156026 which got fixed > via https://svnweb.freebsd.org/base?view=revision&revision=r214675 > "Don't leak the LLE lock if the arptimer callout is pending or > inactive." > > Is what I am seeing similar to this? > > I'll try and get more info. > > Cheers, > Hiren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1405441442061150>