On Wed, Sep 19, 2018 at 01:01:52PM -0700, Steve Kargl wrote:
> I have the kernel and core file if more information is needed.
>
> % cat info.2
> Dump header from device: /dev/ada0p3
Architecture: amd64
> Architecture Version: 2
> Dump Length: 2348281856
> Blocksize: 512
> Compression: none
> Dumptime: Wed Sep 19 12:29:59 2018
> Hostname: troutmask.apl.washington.edu
> Magic: FreeBSD Kernel Dump
> Version String: FreeBSD 12.0-ALPHA4 #0 r338505: Thu Sep 6 13:45:34 PDT 2018
> ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/amd64.amd64/sys/SPEW
> Panic String: page fault
> Dump Parity: 2676008548
> Bounds: 2
> Dump Status: good
>
> % more core.txt.2
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 11
> fault virtual address = 0xffffb8000719a428
This seems to be the result of a bit-flip. cred is 0xffffb8000719a400,
which is almost but not quite in the direct map. In particular we have:
(kgdb) frame 10
#10 0xffffffff8083e07d in vm_object_destroy (object=<optimized out>) at
/usr/src/sys/vm/vm_object.c:703
703 swap_release_by_cred(object->charge, object->cred);
(kgdb) p object
$8 = <optimized out>
(kgdb) p *(vm_object_t)$r13
$9 = {
...
cred = 0xffffb8000719a400,
charge = 28672,
umtx_data = 0x0
}
(kgdb) p *(struct ucred *)0xfffff8000719a400
$10 = {
cr_ref = 5737,
cr_uid = 1001,
cr_ruid = 1001,
cr_svuid = 1001,
cr_ngroups = 7,
cr_rgid = 1001,
cr_svgid = 1001,
cr_uidinfo = 0xfffff80007285500,
cr_ruidinfo = 0xfffff80007285500,
cr_prison = 0xffffffff80a9de10 <prison0>,
... <more sane-looking ucred fields>
That is, flipping one of the bits in the fault address leads me to a
valid ucred. This could in principle be the result of a software bug,
but I'd be more inclined to suspect the hardware.
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
