... And to be clear, this is the trace from a spontaneous reboot (that dumped core). Another instance dropped me into the kernel debugger (indicating it had stopped in something to do w wapbl), but I didn't get copies that stack.
On 10/1/16, Jaromir Dolecek <jaromir.dolecek%gmail.com@localhost> wrote:Here's a gdb backtrace from a core dump:
> If you can get just a short traceback (which particular wapbl
> function(s) for example), it would help to figure possible problem.
#0 0xffffffff80119a85 in cpu_reboot (howto=howto@entry=260,
bootstr=bootstr@entry=0x0) at
/usr/src/sys/arch/amd64/amd64/machdep.c:676
syncdone = false
s = <optimized out>
#1 0xffffffff8086e3dc in vpanic (fmt=fmt@entry=0xffffffff80ed1503
"trap", ap=ap@entry=0xfffffe804105cb28) at
/usr/src/sys/kern/subr_prf.c:342
ci = <optimized out>
oci = <optimized out>
bootopt = 260
scratchstr = "trap", '\000' <repeats 379 times>
#2 0xffffffff8086e490 in panic (fmt=fmt@entry=0xffffffff80ed1503
"trap") at /usr/src/sys/kern/subr_prf.c:258
ap = <error reading variable ap (Attempt to dereference a
generic pointer.)>
#3 0xffffffff8011b706 in trap (frame=0xfffffe804105cc60) at
/usr/src/sys/arch/amd64/amd64/trap.c:298
p = <optimized out>
pcb = <optimized out>
vframe = <optimized out>
ksi = {ksi_flags = 1, ksi_list = {tqe_next = 0x0, tqe_prev =
0x0}, ksi_info = {_signo = 11, _code = 2, _errno = 0, _pad = 0,
_reason = {_rt = {_pid = 0, _uid = 0, _value = {sival_int = 6,
sival_ptr = 0x6}}, _child = {_pid = 0, _uid = 0,
_status = 6, _utime = 0, _stime = 0}, _fault = {_addr = 0x0, _trap =
6, _trap2 = 0, _trap3 = 0}, _poll = {_band = 0, _fd = 6}}},
ksi_lid = 0}
_onfault_ = <optimized out>
type = 6
error = <optimized out>
cr2 = <optimized out>
pfail = <optimized out>
#4 0xffffffff8010115e in alltraps ()
No symbol table info available.
#5 0xffffffff808cad70 in wapbl_write_revocations
(offp=0xfffffe804105cdc8, wl=0xfffffe811ce15688) at
/usr/src/sys/kern/vfs_wapbl.c:2343
wc = 0xfffffe811c747908
blocklen = <optimized out>
off = 6082048
wd = 0xfffffe81deaddead
error = <optimized out>
#6 wapbl_flush (wl=0xfffffe811ce15688, waitfor=waitfor@entry=0) at
/usr/src/sys/kern/vfs_wapbl.c:1618
bp = <optimized out>
we = <optimized out>
off = 6081536
head = <optimized out>
tail = <optimized out>
delta = 0
flushsize = 6996480
reserved = <optimized out>
error = <optimized out>
__func__ = "wapbl_flush"
#7 0xffffffff807a45c1 in ffs_sync (mp=0xfffffe811c95b008, waitfor=3,
cred=0xfffffe811e145f00) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1975
vp = 0x0
ump = 0xfffffe8108092b08
fs = 0xfffffe811beb5008
marker = 0xfffffe810a8b7930
error = <optimized out>
allerror = 0
is_suspending = <optimized out>
ctx = {waitfor = 3, is_suspending = false}
__func__ = "ffs_sync"
#8 0xffffffff808baaa1 in VFS_SYNC (mp=0xfffffe811c95b008,
a=<optimized out>, b=<optimized out>) at
/usr/src/sys/kern/vfs_subr.c:1358
error = <optimized out>
#9 0xffffffff808bad20 in sched_sync (arg=<optimized out>) at
/usr/src/sys/kern/vfs_subr.c:785
slp = <optimized out>
vp = <optimized out>
mp = 0xfffffe811c95b008
nmp = 0xfffffe811c95b008
starttime = 1475352687
synced = true
#10 0xffffffff801008d7 in lwp_trampoline ()
> The changes to vfs_wapbl.c were fairly minor so far. I would
> understand new panics, but it would be strange if they caused faults.
>
> Maybe if you can try to downgrade ufs/ffs/ffs_alloc.c before rev.
> 1.152. It's possible there is some interaction with wapbl which might
> cause troubles there.
>
> Keep me on CC please, I'm working currently on WAPBL and planning some
> further changes, so I'll fix any regressions asap.
>
> Jaromir
>
> 2016-10-01 22:50 GMT+02:00 bch <brad.harder%gmail.com@localhost>:
>> On Oct 1, 2016 1:44 PM, "bch" <brad.harder%gmail.com@localhost> wrote:
>>>
>>> This appears to be trashing files, too, based on what I see trying to
>>> CVS
>>> update
>>
>> Incl. author of potential troublesome commit.
>>
>>> On Oct 1, 2016 1:32 PM, "bch" <brad.harder%gmail.com@localhost> wrote:
>>>>
>>>>
>>>> My system is unstable w latest src. Appears to fault in wapbl
>>>> functions.
>>>> Sadly, this appears to correspond w updates in network interfaces, so my
>>>> .38
>>>> backup kernel won't cooperate with my .39 userland to bring up the
>>>> network
>>>> and update src and poll the machine for more info and send that out.
>