"panic: Unholding 5 with cnt = 0" head/amd64 @r331290

[David Wolfskill]

This is on my build machine, running a GENERIC kernel. (Laptop is still
building lib32 shim libraries as I type).

Here's a copy/paste from the serial console:

da3: Attempt to query device size failed: NOT READY, Medium not present
da3: quirks=0x2<NO_6_BYTE>
da3: Delete methods: <NONE(*),ZERO>
GEOM: new disk da1
GEOM: new disk da2
GEOM: new disk da3
(da1:umass-sim0:0:0:1): PREVENT ALLOW MEDIUM REMOVAL not supported.
ugen0.4: <Broadcom Corp BCM43142A0> at usbus0
(dpanic: Unholding 5 with cnt = 0
cpuid = 3
time = 1521633742
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00004913c0
vpanic() at vpanic+0x18d/frame 0xfffffe0000491420
panic() at panic+0x43/frame 0xfffffe0000491480
dadone() at dadone+0x1cc9/frame 0xfffffe00004919e0
xpt_done_process() at xpt_done_process+0x390/frame 0xfffffe0000491a20
xpt_done_td() at xpt_done_td+0xf6/frame 0xfffffe0000491a70
fork_exit() at fork_exit+0x84/frame 0xfffffe0000491ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000491ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 15 tid 100065 ]
Stopped at kdb_enter+0x3b: movq $0,kdb_why
db>


Anything I can/should do to poke at it before trying to capture a dump?

Peace,
david

[Roman Bogorodskiy]

Post by David Wolfskill
This is on my build machine, running a GENERIC kernel. (Laptop is still
building lib32 shim libraries as I type).
da3: Attempt to query device size failed: NOT READY, Medium not present
da3: quirks=0x2<NO_6_BYTE>
da3: Delete methods: <NONE(*),ZERO>
GEOM: new disk da1
GEOM: new disk da2
GEOM: new disk da3
(da1:umass-sim0:0:0:1): PREVENT ALLOW MEDIUM REMOVAL not supported.
ugen0.4: <Broadcom Corp BCM43142A0> at usbus0
(dpanic: Unholding 5 with cnt = 0
cpuid = 3
time = 1521633742
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00004913c0
vpanic() at vpanic+0x18d/frame 0xfffffe0000491420
panic() at panic+0x43/frame 0xfffffe0000491480
dadone() at dadone+0x1cc9/frame 0xfffffe00004919e0
xpt_done_process() at xpt_done_process+0x390/frame 0xfffffe0000491a20
xpt_done_td() at xpt_done_td+0xf6/frame 0xfffffe0000491a70
fork_exit() at fork_exit+0x84/frame 0xfffffe0000491ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000491ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 15 tid 100065 ]
Stopped at kdb_enter+0x3b: movq $0,kdb_why
db>
Anything I can/should do to poke at it before trying to capture a dump?

Looks like it's related to:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226510#c18

Post by David Wolfskill
Peace,
david
--
An investigator who doesn't make a perp nervous isn't doing his job.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.

Roman Bogorodskiy

[Warner Losh]

i've reverted r331273. In trying to fix the too many refs problem, I
created the too few refs problem.

Warner

Post by David Wolfskill

Post by David Wolfskill
This is on my build machine, running a GENERIC kernel. (Laptop is still
building lib32 shim libraries as I type).
da3: Attempt to query device size failed: NOT READY, Medium not present
da3: quirks=0x2<NO_6_BYTE>
da3: Delete methods: <NONE(*),ZERO>
GEOM: new disk da1
GEOM: new disk da2
GEOM: new disk da3
(da1:umass-sim0:0:0:1): PREVENT ALLOW MEDIUM REMOVAL not supported.
ugen0.4: <Broadcom Corp BCM43142A0> at usbus0
(dpanic: Unholding 5 with cnt = 0
cpuid = 3
time = 1521633742
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame

0xfffffe00004913c0

Post by David Wolfskill
vpanic() at vpanic+0x18d/frame 0xfffffe0000491420
panic() at panic+0x43/frame 0xfffffe0000491480
dadone() at dadone+0x1cc9/frame 0xfffffe00004919e0
xpt_done_process() at xpt_done_process+0x390/frame 0xfffffe0000491a20
xpt_done_td() at xpt_done_td+0xf6/frame 0xfffffe0000491a70
fork_exit() at fork_exit+0x84/frame 0xfffffe0000491ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000491ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 15 tid 100065 ]
Stopped at kdb_enter+0x3b: movq $0,kdb_why
db>
Anything I can/should do to poke at it before trying to capture a dump?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226510#c18

Post by David Wolfskill
Peace,
david
--
An investigator who doesn't make a perp nervous isn't doing his job.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.

Roman Bogorodskiy

[David Wolfskill]

Post by Roman Bogorodskiy
...

Post by David Wolfskill
Anything I can/should do to poke at it before trying to capture a dump?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226510#c18
.....

Hmm... OK; thanks. I went ahead and grabbed crash dump; it may be
found at <http://www.catwhisker.org/~david/FreeBSD/head/r331290/> (along
with core.txt).

Also, my laptop (running a kernel based on GENERIC, but with a few bits
snipped out and things like IPFIREWALL_DEFAULT_TO_ACCEPT turned off) did
not exhibit an issue.

I am presently re-building head @r331290 on each machine (on a different
slice); this time, without the Forth loader stuff being built (and with
the Lua loader stuff being built). I mention this, not because I think
the loader has anything to do with this, but because at this time, I
have but a single failure out of two possible; smoke-testing the current
builds will provide a chance to see if I somehow did something weird to
the build machine earlier.

Anyway, Warner should know how to reach me. :-)

Peace,
david

[Warner Losh]

Post by Roman Bogorodskiy
...

Post by David Wolfskill
Anything I can/should do to poke at it before trying to capture a dump?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226510#c18
.....

Hmm... OK; thanks. I went ahead and grabbed crash dump; it may be
found at <http://www.catwhisker.org/~david/FreeBSD/head/r331290/> (along
with core.txt).

Also, my laptop (running a kernel based on GENERIC, but with a few bits
snipped out and things like IPFIREWALL_DEFAULT_TO_ACCEPT turned off) did
not exhibit an issue.

I am presently re-building head @r331290 on each machine (on a different
slice); this time, without the Forth loader stuff being built (and with
the Lua loader stuff being built). I mention this, not because I think
the loader has anything to do with this, but because at this time, I
have but a single failure out of two possible; smoke-testing the current
builds will provide a chance to see if I somehow did something weird to
the build machine earlier.

Anyway, Warner should know how to reach me. :-)



The fix is in 331291.. at least the back out for other issues...

Warner

Peace,
david
--
David H. Wolfskill ***@catwhisker.org
An investigator who doesn't make a perp nervous isn't doing his job.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.