On Fri, Jan 26, 2018 at 5:29 AM, David Wolfskill <da...@catwhisker.org>

> This is on my "build machine" (laptop is still building updated ports
> for today, so I don't know yet whether or not it encounters this.)

Running a kernel with INVARIANTS, right?

> I had performed a source-based update from r328393 to r328436,
> rebooted, performed "make delete-old-libs", and all seemed well.

This has my change 328415 in it.

> I then issued "sudo shutdown -p now", and serial console shows:
> panic: Unholding 6 with cnt = -559038242
> cpuid = 3
> time = 1516968697
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe00004288c0
> vpanic() at vpanic+0x18d/frame 0xfffffe0000428920
> panic() at panic+0x43/frame 0xfffffe0000428980
> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfffffe00004289a0
> g_disk_providergone() at g_disk_providergone+0x25/frame 0xfffffe00004289d0
> g_destroy_provider() at g_destroy_provider+0xae/frame 0xfffffe00004289f0
> g_wither_washer() at g_wither_washer+0x87/frame 0xfffffe0000428a30
> g_run_events() at g_run_events+0x3ca/frame 0xfffffe0000428a70
> fork_exit() at fork_exit+0x84/frame 0xfffffe0000428ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000428ab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
> [ thread pid 13 tid 100044 ]
> Stopped at      kdb_enter+0x3b: movq    $0,kdb_why
> db>

That's no good. We're releasing a reference to the da peripheral because
geom has finished with the disk and is giving us a final callback so we can
drop the reference we took when we created the geom. Trouble is, cnt should
be like 1 always for this code, but it's not. It looks like it may be bytes
to a pointer :(

> As noted, this is a build machine, and it was to be powered off for
> the rest of the day anyway, so I don't need to get it up & running
> immediately: I can poke at the ddb prompt, given some clues.

I don't suppose you can attach kgdb to this machine? I'd be interested to
see what the contents of the softc are...a

> Same system had completed a source-based update for stable/11 from
> r328392 to r328429 earlier today without incident (using a different
> slice of the boot drive).

Thanks for the report. This is quite troubling.

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

Reply via email to