Regular crash reports on my APU2 2.3.2

  • I keep getting crash reports from my APU2 and submit them but is there any way to find out what the resolution is as it happens constantly.

  • Rebel Alliance Developer Netgate

    Submitting a crash report doesn't trigger anything from us. It stores the report so we can look at it, but we don't look at all the submissions. There are far too many, and most of them are hardware issues.

    I looked for a report from the IP address you used to post this message, but the only one there was a month old and wasn't running 2.3.2. If there is another IP address it could have come from, let me know which subnet it's in (I don't need the full IP address, just the first three parts plus the day it was submitted)

  • Hi Will PM with IP's

  • Rebel Alliance Developer Netgate

    Unfortunately, the panics point to bad hardware, most likely memory:

    db:0:kdb.enter.default>  bt
    Tracing pid 3499 tid 100150 td 0xfffff8006a6834b0
    kdb_enter() at kdb_enter+0x3e/frame 0xfffffe012113f730
    vpanic() at vpanic+0x146/frame 0xfffffe012113f770
    panic() at panic+0x43/frame 0xfffffe012113f7d0
    pmap_remove_pages() at pmap_remove_pages+0x736/frame 0xfffffe012113f8b0
    vmspace_exit() at vmspace_exit+0x9c/frame 0xfffffe012113f8f0
    exit1() at exit1+0x65f/frame 0xfffffe012113f980
    sys_sys_exit() at sys_sys_exit+0xe/frame 0xfffffe012113f990
    amd64_syscall() at amd64_syscall+0x40f/frame 0xfffffe012113fab0
    Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe012113fab0
    --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8008fa14a, rsp = 0x7fffffffec48, rbp = 0x7fffffffec60 ---
    panic: bad pte va 8008a2000 pte 0
    cpuid = 1
    KDB: enter: panic

    The crash is in memory manipulation, an area high unlikely to be a software fault. Furthermore, that panic string indicates a memory location within a page table has spontaneously changed to 0, which wouldn't have happened via software.

    I checked a couple of the other panics and they were different, but still in random low-level areas that generally point to hardware faults.