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

[Warner Losh]

On Mar 21, 2018 7:02 AM, "David Wolfskill"  wrote:

On Wed, Mar 21, 2018 at 04:26:57PM +0400, Roman Bogorodskiy wrote:
> ...
> > 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
> .

Hmm...  OK; thanks.  I went ahead and grabbed crash dump; it may be
found at  (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  da...@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.
___
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"

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

[David Wolfskill]

On Wed, Mar 21, 2018 at 04:26:57PM +0400, Roman Bogorodskiy wrote:
> ...
> > 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
> .

Hmm...  OK; thanks.  I went ahead and grabbed crash dump; it may be
found at  (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
-- 
David H. Wolfskill  da...@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.


signature.asc
Description: PGP signature

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

[Warner Losh]

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

Warner

On Wed, Mar 21, 2018 at 6:26 AM, Roman Bogorodskiy 
wrote:

>   David Wolfskill wrote:
>
> > 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
> > da3: Delete methods: 
> > 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:  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
> 0xfe4913c0
> > vpanic() at vpanic+0x18d/frame 0xfe491420
> > panic() at panic+0x43/frame 0xfe491480
> > dadone() at dadone+0x1cc9/frame 0xfe4919e0
> > xpt_done_process() at xpt_done_process+0x390/frame 0xfe491a20
> > xpt_done_td() at xpt_done_td+0xf6/frame 0xfe491a70
> > fork_exit() at fork_exit+0x84/frame 0xfe491ab0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfe491ab0
> > --- 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
>
> > Peace,
> > david
> > --
> > David H. Wolfskillda...@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.
>
>
>
> Roman Bogorodskiy
>
___
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"

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

[Roman Bogorodskiy]

  David Wolfskill wrote:

> 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
> da3: Delete methods: 
> 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:  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 0xfe4913c0
> vpanic() at vpanic+0x18d/frame 0xfe491420
> panic() at panic+0x43/frame 0xfe491480
> dadone() at dadone+0x1cc9/frame 0xfe4919e0
> xpt_done_process() at xpt_done_process+0x390/frame 0xfe491a20
> xpt_done_td() at xpt_done_td+0xf6/frame 0xfe491a70
> fork_exit() at fork_exit+0x84/frame 0xfe491ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe491ab0
> --- 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

> Peace,
> david
> -- 
> David H. Wolfskillda...@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.



Roman Bogorodskiy


signature.asc
Description: PGP signature

"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
da3: Delete methods: 
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:  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 0xfe4913c0
vpanic() at vpanic+0x18d/frame 0xfe491420
panic() at panic+0x43/frame 0xfe491480
dadone() at dadone+0x1cc9/frame 0xfe4919e0
xpt_done_process() at xpt_done_process+0x390/frame 0xfe491a20
xpt_done_td() at xpt_done_td+0xf6/frame 0xfe491a70
fork_exit() at fork_exit+0x84/frame 0xfe491ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe491ab0
--- 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
-- 
David H. Wolfskill  da...@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.


signature.asc
Description: PGP signature