Sorry but it appears I dont have the core so am not able to match it up. Mostly likely another will happen later today though as ive now fixed dumpdev on the box
On 5 October 2015 at 08:05, krad <[email protected]> wrote: > I will have to have a look when i get home as the box is down at present. > Probably another panic 8( > > On 5 October 2015 at 06:26, Konstantin Belousov <[email protected]> > wrote: > >> On Sun, Oct 04, 2015 at 07:31:43PM +0100, krad wrote: >> > Is anyone else having problems with squid core dumping on Freebsd >> 10-stable >> > when using the transparent caching feature. It started happening >> recently >> > after I re enabled ipv6 on my network. It may just be coincidence >> though. >> > It has even caused the odd kernel panic but not every time. >> > >> > FreeBSD xx 10.2-STABLE FreeBSD 10.2-STABLE #6: Wed Sep 9 16:01:15 BST >> 2015 >> > root@r2:/build/stable/usr/obj/build/stable/usr/src/sys/me amd64 >> > >> > >> > Oct 4 17:13:09 hunters6 kernel: Fatal trap 12: page fault while in >> kernel >> > mode >> > Oct 4 17:13:09 hunters6 kernel: cpuid = 1; apic id = 02 >> > Oct 4 17:13:09 hunters6 kernel: fault virtual address = 0x28 >> > Oct 4 17:13:09 hunters6 kernel: fault code = supervisor >> read >> > data, page not present >> > Oct 4 17:13:09 hunters6 kernel: instruction pointer = >> > 0x20:0xffffffff807f27a9 >> > Oct 4 17:13:09 hunters6 kernel: stack pointer = >> > 0x28:0xfffffe011be4a390 >> > Oct 4 17:13:09 hunters6 kernel: frame pointer = >> > 0x28:0xfffffe011be4a3f0 >> > Oct 4 17:13:09 hunters6 kernel: code segment = base 0x0, >> limit >> > 0xfffff, type 0x1b >> > Oct 4 17:13:09 hunters6 kernel: = DPL 0, pres 1, long 1, def32 0, gran >> 1 >> > Oct 4 17:13:09 hunters6 kernel: processor eflags = interrupt >> > enabled, resume, IOPL = 0 >> > Oct 4 17:13:09 hunters6 kernel: current process = 10269 >> > (squid) >> > Oct 4 17:13:09 hunters6 kernel: trap number = 12 >> > Oct 4 17:13:09 hunters6 kernel: panic: page fault >> > Oct 4 17:13:09 hunters6 kernel: cpuid = 1 >> > Oct 4 17:13:09 hunters6 kernel: KDB: stack backtrace: >> > Oct 4 17:13:09 hunters6 kernel: #0 0xffffffff8062f920 at >> kdb_backtrace+0x60 >> > Oct 4 17:13:09 hunters6 kernel: #1 0xffffffff805f48f6 at vpanic+0x126 >> > Oct 4 17:13:09 hunters6 kernel: #2 0xffffffff805f47c3 at panic+0x43 >> > Oct 4 17:13:09 hunters6 kernel: #3 0xffffffff808c5eeb at >> trap_fatal+0x36b >> > Oct 4 17:13:09 hunters6 kernel: #4 0xffffffff808c61ed at >> trap_pfault+0x2ed >> > Oct 4 17:13:09 hunters6 kernel: #5 0xffffffff808c588a at trap+0x47a >> > Oct 4 17:13:09 hunters6 kernel: #6 0xffffffff808abb52 at calltrap+0x8 >> > Oct 4 17:13:09 hunters6 kernel: #7 0xffffffff807d3a9f at >> > in6_mapped_peeraddr+0xcf >> Please obtain the source file/line number of in6_mapped_peeraddr+0xcf. >> Do you have core dump for the panic ? >> >> > Oct 4 17:13:09 hunters6 kernel: #8 0xffffffff805b0048 at >> > export_fd_to_sb+0x6c8 >> > Oct 4 17:13:09 hunters6 kernel: #9 0xffffffff805af880 at >> > kern_proc_filedesc_out+0x3d0 >> > Oct 4 17:13:09 hunters6 kernel: #10 0xffffffff8059c7bd at >> > note_procstat_files+0xfd >> > Oct 4 17:13:09 hunters6 kernel: #11 0xffffffff8059a3a4 at >> > elf64_coredump+0x314 >> > Oct 4 17:13:09 hunters6 kernel: #12 0xffffffff805f7f4c at sigexit+0xb6c >> > Oct 4 17:13:09 hunters6 kernel: #13 0xffffffff805f85a6 at postsig+0x286 >> > Oct 4 17:13:09 hunters6 kernel: #14 0xffffffff806403f7 at ast+0x427 >> > >> > > _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
