09.11.2019 19:45, Scott Bennett пишет:
>      The rest of this message was posted a little while ago to the
> freebsd-questions list by mistake.  It was intended for freebsd-stable,
> so I am posting it here now after posting a brief apology on the other
> list.
>      I have had to waste a great deal of time lately in recovering my
> system from crashes due to a kernel bug.  At present, my system is
> FreeBSD hellas 11.3-STABLE FreeBSD 11.3-STABLE #12 r352571: Sat Sep 21 
> 11:39:52 CDT 2019     bennett@hellas:/usr/obj/usr/src/sys/hellas  amd64
> There are actually at least two problems, but this particular one has been
> causing a large portion of my forced reboots.  It usually fails to produce
> a dump and freezes right after the panic and backtrace messages, as it did
> earlier tonight, but Wednesday night it did create a dump, which I am
> keeping in case it should prove helpful in getting the bug identified and
> solved.  I copied the console messages to paper painstakingly by hand.
> They appear to be identical each time, except, of course, for the messages
> that a dump is produced when, indeed, it does produce one.  I am omitting
> those fairly standard messages.
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address   = 0x3b8
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x20:0xffffffff80a4b14c
> stack pointer           = 0x0:0xfffffe012a60ea50
> frame pointer           = 0x0:0xfffffe012a60eae0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 28 (flowcleaner)
> trap number             = 12
> panic: page fault
> cpuid = 2
> KDB: stack backtrace:
> #0 0xffffffff80a94707 at kdb_backtrace+0x67
> #1 0xffffffff80a4fa2e at vpanic+0x17e
> #2 0xffffffff80a4f8a3 at panic+0x43
> #3 0xffffffff80f3a4d0 at trap_pfault+0
> #4 0xffffffff80f3a519 at trap_pfault+0x49
> #5 0xffffffff80f39bad at trap+0x29
> #6 0xffffffff80f19f33 at calltrap+0x8
> #7 0xffffffff80b3bb8d at flowtable_clean_vnet+0x43d
> #8 0xffffffff80b3c758 at flowtable_cleaner+0xc8
> #9 0xffffffff80a12ea2 at fork_exit+0x82
> #10 0xffffffff80flaf4e at fork_trampoline+0xe
>      The machine is ancient.  The CPU is a QX9650 (last group of Core 2
> Quads) with 8 GB of DDR3 memory.
>      If this can be identified as a known bug and a clue provided to a
> patch or a safer version to upgrade to, I would be grateful.  I am getting
> very, very tired of these crashes.
>      The other forced reboots I will describe in a separate message, but
> that problem has existed since the time of 11.2-RELEASE and apparently was
> never investigated, much less fixed, although people began complaining on
> this list and possibly -questions within the first few days after the
> release date.
>      Thanks in advance for any help with this problem!

It seems you have custom kernel with options FLOWTABLE. The code it includes
is known to be buggy, this options was removed from GENERIC many releases ago.
Remove it from your kernel configuration, rebuild kernel and you will be fine.

freebsd-stable@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to