Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716
Chalk another review fail up to shuffling patches between git and phab.
Sorry for the inconvenience.
-M
On Wed, Apr 11, 2018 at 10:26 AM, K. Macy wrote:
> Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line.
> -M
>
> On Wed, Apr 11, 2018 at 10:24 AM, K. Macy wrote:
>> Sorry about that. It looks like my review must have been missing a line.
>>
>> @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)
>>
>> _iflib_assert(sctx);
>>
>> - CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
>> -
>> + CTX_LOCK_INIT(ctx);
>> + STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
>> ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER);
>> if (ifp == NULL) {
>> device_printf(dev, "can not allocate ifnet structure\n");
>> @@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void
>> *uniq, int cpu, char *name)
>> }
>>
>> void
>>
>> On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill
>> wrote:
>>> This was running:
>>>
>>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156
>>> r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018
>>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
>>> amd64
>>>
>>> during boot, after updating from:
>>>
>>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155
>>> r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018
>>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
>>> amd64
>>>
>>> (My build machine, which uses an re((4) NIC, did not encounter the issue.)
>>>
>>> It appears that r332389 is implicated.
>>>
>>> ...
>>> Unread portion of the kernel message buffer:
>>>
>>> __curthread () at ./machine/pcpu.h:230
>>> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
>>> (kgdb) #0 __curthread () at ./machine/pcpu.h:230
>>> #1 doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
>>> #2 0x80433f4c in db_fncall_generic (addr=,
>>> rv=, nargs=, args=)
>>> at /usr/src/sys/ddb/db_command.c:609
>>> #3 db_fncall (dummy1=, dummy2=,
>>> dummy3=, dummy4=)
>>> at /usr/src/sys/ddb/db_command.c:657
>>> #4 0x80433a99 in db_command (last_cmdp=,
>>> cmd_table=, dopager=)
>>> at /usr/src/sys/ddb/db_command.c:481
>>> #5 0x80433814 in db_command_loop ()
>>> at /usr/src/sys/ddb/db_command.c:534
>>> #6 0x80436a3f in db_trap (type=, code=>> out>)
>>> at /usr/src/sys/ddb/db_main.c:250
>>> #7 0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
>>> at /usr/src/sys/kern/subr_kdb.c:697
>>> #8 0x80f7eaa8 in trap (frame=0xfe4377a0)
>>> at /usr/src/sys/amd64/amd64/trap.c:548
>>> #9
>>> #10 kdb_enter (why=0x811df9d4 "panic", msg=)
>>> at /usr/src/sys/kern/subr_kdb.c:479
>>> #11 0x80b2feda in vpanic (fmt=,
>>> ap=0xfe437910)
>>> at /usr/src/sys/kern/kern_shutdown.c:826
>>> #12 0x80b2fca0 in kassert_panic (
>>> fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
>>> at /usr/src/sys/kern/kern_shutdown.c:723
>>> #13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0,
>>> file=0x81113c90 "/usr/src/sys/net/iflib.c", line=>> out>)
>>> at /usr/src/sys/kern/kern_mutex.c:246
>>> #14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
>>> at /usr/src/sys/net/iflib.c:3716
>>> #15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
>>> at /usr/src/sys/kern/subr_gtaskqueue.c:331
>>> #16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
>>> at /usr/src/sys/kern/subr_gtaskqueue.c:506
>>> #17 0x80af0064 in fork_exit (
>>> callout=0x80b73540 ,
>>> arg=0xfe0844223008, frame=0xfe437ac0)
>>> at /usr/src/sys/kern/kern_fork.c:1039
>>> #18
>>> (kgdb)
>>>
>>> If the dump would be useful, I can put it up for access.
>>>
>>> Peace,
>>> david
>>> --
>>> David H. Wolfskill da...@catwhisker.org
>>> Well, what did you EXPECT from Trump? He has a history of breaking
>>> promises.
>>>
>>> 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: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716
Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line.
-M
On Wed, Apr 11, 2018 at 10:24 AM, K. Macy wrote:
> Sorry about that. It looks like my review must have been missing a line.
>
> @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)
>
> _iflib_assert(sctx);
>
> - CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
> -
> + CTX_LOCK_INIT(ctx);
> + STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
> ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER);
> if (ifp == NULL) {
> device_printf(dev, "can not allocate ifnet structure\n");
> @@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void
> *uniq, int cpu, char *name)
> }
>
> void
>
> On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill wrote:
>> This was running:
>>
>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156
>> r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018
>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
>> amd64
>>
>> during boot, after updating from:
>>
>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155
>> r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018
>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
>> amd64
>>
>> (My build machine, which uses an re((4) NIC, did not encounter the issue.)
>>
>> It appears that r332389 is implicated.
>>
>> ...
>> Unread portion of the kernel message buffer:
>>
>> __curthread () at ./machine/pcpu.h:230
>> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
>> (kgdb) #0 __curthread () at ./machine/pcpu.h:230
>> #1 doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
>> #2 0x80433f4c in db_fncall_generic (addr=,
>> rv=, nargs=, args=)
>> at /usr/src/sys/ddb/db_command.c:609
>> #3 db_fncall (dummy1=, dummy2=,
>> dummy3=, dummy4=)
>> at /usr/src/sys/ddb/db_command.c:657
>> #4 0x80433a99 in db_command (last_cmdp=,
>> cmd_table=, dopager=)
>> at /usr/src/sys/ddb/db_command.c:481
>> #5 0x80433814 in db_command_loop ()
>> at /usr/src/sys/ddb/db_command.c:534
>> #6 0x80436a3f in db_trap (type=, code=> out>)
>> at /usr/src/sys/ddb/db_main.c:250
>> #7 0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
>> at /usr/src/sys/kern/subr_kdb.c:697
>> #8 0x80f7eaa8 in trap (frame=0xfe4377a0)
>> at /usr/src/sys/amd64/amd64/trap.c:548
>> #9
>> #10 kdb_enter (why=0x811df9d4 "panic", msg=)
>> at /usr/src/sys/kern/subr_kdb.c:479
>> #11 0x80b2feda in vpanic (fmt=, ap=0xfe437910)
>> at /usr/src/sys/kern/kern_shutdown.c:826
>> #12 0x80b2fca0 in kassert_panic (
>> fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
>> at /usr/src/sys/kern/kern_shutdown.c:723
>> #13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0,
>> file=0x81113c90 "/usr/src/sys/net/iflib.c", line=)
>> at /usr/src/sys/kern/kern_mutex.c:246
>> #14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
>> at /usr/src/sys/net/iflib.c:3716
>> #15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
>> at /usr/src/sys/kern/subr_gtaskqueue.c:331
>> #16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
>> at /usr/src/sys/kern/subr_gtaskqueue.c:506
>> #17 0x80af0064 in fork_exit (
>> callout=0x80b73540 ,
>> arg=0xfe0844223008, frame=0xfe437ac0)
>> at /usr/src/sys/kern/kern_fork.c:1039
>> #18
>> (kgdb)
>>
>> If the dump would be useful, I can put it up for access.
>>
>> Peace,
>> david
>> --
>> David H. Wolfskill da...@catwhisker.org
>> Well, what did you EXPECT from Trump? He has a history of breaking promises.
>>
>> 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: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716
Sorry about that. It looks like my review must have been missing a line.
@@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)
_iflib_assert(sctx);
- CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
-
+ CTX_LOCK_INIT(ctx);
+ STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER);
if (ifp == NULL) {
device_printf(dev, "can not allocate ifnet structure\n");
@@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void
*uniq, int cpu, char *name)
}
void
On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill wrote:
> This was running:
>
> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156
> r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> amd64
>
> during boot, after updating from:
>
> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155
> r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> amd64
>
> (My build machine, which uses an re((4) NIC, did not encounter the issue.)
>
> It appears that r332389 is implicated.
>
> ...
> Unread portion of the kernel message buffer:
>
> __curthread () at ./machine/pcpu.h:230
> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) #0 __curthread () at ./machine/pcpu.h:230
> #1 doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
> #2 0x80433f4c in db_fncall_generic (addr=,
> rv=, nargs=, args=)
> at /usr/src/sys/ddb/db_command.c:609
> #3 db_fncall (dummy1=, dummy2=,
> dummy3=, dummy4=)
> at /usr/src/sys/ddb/db_command.c:657
> #4 0x80433a99 in db_command (last_cmdp=,
> cmd_table=, dopager=)
> at /usr/src/sys/ddb/db_command.c:481
> #5 0x80433814 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:534
> #6 0x80436a3f in db_trap (type=, code=)
> at /usr/src/sys/ddb/db_main.c:250
> #7 0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
> at /usr/src/sys/kern/subr_kdb.c:697
> #8 0x80f7eaa8 in trap (frame=0xfe4377a0)
> at /usr/src/sys/amd64/amd64/trap.c:548
> #9
> #10 kdb_enter (why=0x811df9d4 "panic", msg=)
> at /usr/src/sys/kern/subr_kdb.c:479
> #11 0x80b2feda in vpanic (fmt=, ap=0xfe437910)
> at /usr/src/sys/kern/kern_shutdown.c:826
> #12 0x80b2fca0 in kassert_panic (
> fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
> at /usr/src/sys/kern/kern_shutdown.c:723
> #13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0,
> file=0x81113c90 "/usr/src/sys/net/iflib.c", line=)
> at /usr/src/sys/kern/kern_mutex.c:246
> #14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
> at /usr/src/sys/net/iflib.c:3716
> #15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
> at /usr/src/sys/kern/subr_gtaskqueue.c:331
> #16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
> at /usr/src/sys/kern/subr_gtaskqueue.c:506
> #17 0x80af0064 in fork_exit (
> callout=0x80b73540 ,
> arg=0xfe0844223008, frame=0xfe437ac0)
> at /usr/src/sys/kern/kern_fork.c:1039
> #18
> (kgdb)
>
> If the dump would be useful, I can put it up for access.
>
> Peace,
> david
> --
> David H. Wolfskill da...@catwhisker.org
> Well, what did you EXPECT from Trump? He has a history of breaking promises.
>
> 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: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716
On 11.04.2018 20:02, Mark Johnston wrote: >> It appears that r332389 is implicated. > > I'm seeing this too, under bhyve with e1000 emulation. Reverting r332389 > fixes the problem. I have this problem too. And reverting r332389 fixes it. em0@pci0:0:25:0:class=0x02 card=0x20088086 chip=0x15028086 rev=0x04 hdr=0x00 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716
On Wed, Apr 11, 2018 at 04:39:58AM -0700, David Wolfskill wrote: > This was running: > > FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156 > r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 > r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 > > during boot, after updating from: > > FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155 > r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 > r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 > > (My build machine, which uses an re((4) NIC, did not encounter the issue.) > > It appears that r332389 is implicated. I'm seeing this too, under bhyve with e1000 emulation. Reverting r332389 fixes the problem. ___ 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"
panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716
This was running:
FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156
r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018
r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64
during boot, after updating from:
FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155
r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018
r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64
(My build machine, which uses an re((4) NIC, did not encounter the issue.)
It appears that r332389 is implicated.
...
Unread portion of the kernel message buffer:
__curthread () at ./machine/pcpu.h:230
230 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0 __curthread () at ./machine/pcpu.h:230
#1 doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
#2 0x80433f4c in db_fncall_generic (addr=,
rv=, nargs=, args=)
at /usr/src/sys/ddb/db_command.c:609
#3 db_fncall (dummy1=, dummy2=,
dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:657
#4 0x80433a99 in db_command (last_cmdp=,
cmd_table=, dopager=)
at /usr/src/sys/ddb/db_command.c:481
#5 0x80433814 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:534
#6 0x80436a3f in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:250
#7 0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
at /usr/src/sys/kern/subr_kdb.c:697
#8 0x80f7eaa8 in trap (frame=0xfe4377a0)
at /usr/src/sys/amd64/amd64/trap.c:548
#9
#10 kdb_enter (why=0x811df9d4 "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:479
#11 0x80b2feda in vpanic (fmt=, ap=0xfe437910)
at /usr/src/sys/kern/kern_shutdown.c:826
#12 0x80b2fca0 in kassert_panic (
fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
at /usr/src/sys/kern/kern_shutdown.c:723
#13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0,
file=0x81113c90 "/usr/src/sys/net/iflib.c", line=)
at /usr/src/sys/kern/kern_mutex.c:246
#14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
at /usr/src/sys/net/iflib.c:3716
#15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
at /usr/src/sys/kern/subr_gtaskqueue.c:331
#16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
at /usr/src/sys/kern/subr_gtaskqueue.c:506
#17 0x80af0064 in fork_exit (
callout=0x80b73540 ,
arg=0xfe0844223008, frame=0xfe437ac0)
at /usr/src/sys/kern/kern_fork.c:1039
#18
(kgdb)
If the dump would be useful, I can put it up for access.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Well, what did you EXPECT from Trump? He has a history of breaking promises.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: r291494 PANIC mtx_lock() of spin mutex @ /usr/src/sys/kern/vfs_subr.c:512
On Wed, Dec 02, 2015 at 12:35:23PM -0500, Michael Jung wrote: > Since upgrading to r291494 from r290716 my system reliably panics > when running poudriere. > > Dump header from device: /dev/da2p1 > Architecture: amd64 > Architecture Version: 2 > Dump Length: 4301131776 > Blocksize: 512 > Dumptime: Wed Dec 2 12:10:06 2015 > Hostname: bsd11 > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 11.0-CURRENT #9 r291494: Mon Nov 30 > 13:21:08 EST 2015 > mikej@bsd11:/usr/obj/usr/src/sys/GENERIC > Panic String: mtx_lock() of spin mutex @ > /usr/src/sys/kern/vfs_subr.c:512 > Dump Parity: 2232113789 > Bounds: 1 > Dump Status: good > > > > https://charon.gopai.com/crash/info.1 > > https://charon.gppai.com/crash/core.txt.1 > > https://charon.gopai.com/crash/vmcore.1 > > I could not find a reference to this panic. > please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204949 -- Mateusz Guzik ___ 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"
r291494 PANIC mtx_lock() of spin mutex @ /usr/src/sys/kern/vfs_subr.c:512
Since upgrading to r291494 from r290716 my system reliably panics when running poudriere. Dump header from device: /dev/da2p1 Architecture: amd64 Architecture Version: 2 Dump Length: 4301131776 Blocksize: 512 Dumptime: Wed Dec 2 12:10:06 2015 Hostname: bsd11 Magic: FreeBSD Kernel Dump Version String: FreeBSD 11.0-CURRENT #9 r291494: Mon Nov 30 13:21:08 EST 2015 mikej@bsd11:/usr/obj/usr/src/sys/GENERIC Panic String: mtx_lock() of spin mutex @ /usr/src/sys/kern/vfs_subr.c:512 Dump Parity: 2232113789 Bounds: 1 Dump Status: good https://charon.gopai.com/crash/info.1 https://charon.gppai.com/crash/core.txt.1 https://charon.gopai.com/crash/vmcore.1 I could not find a reference to this panic. Regards, --mikej ___ 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: mtx_lock() of spin mutex in ip_output.c
Sam Leffler wrote: > On Friday 07 November 2003 12:54 pm, Steve Kargl wrote: > > On Fri, Nov 07, 2003 at 11:31:45AM -0800, Steven G. Kargl wrote: > > > I have a Dell 4150 laptop using dhcp and ntpd on the > > > xl0 interface. I did "ifconfig xl0 down" and received > > > the following panic (hand transcribed :-( ). > > > > > > panic: mtx_lock() of spin mutex (null) @ > > > /usr/src/sys/netinet/ip_output.c:266 Stack backtrace: > > > backtrace() > > > panic() > > > panic: process 414(ntpd):2 Giant but isn't blocked on a mutex > > > > > Make sure you have rev 1.250 of ip_input.c. > Okay. I'll update my source tree. This panic occurred for sources circa 31 Oct 03. I'm going to be offline for the next week, so I won't be able to pursue this until then. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: mtx_lock() of spin mutex in ip_output.c
On Friday 07 November 2003 12:54 pm, Steve Kargl wrote: > On Fri, Nov 07, 2003 at 11:31:45AM -0800, Steven G. Kargl wrote: > > I have a Dell 4150 laptop using dhcp and ntpd on the > > xl0 interface. I did "ifconfig xl0 down" and received > > the following panic (hand transcribed :-( ). > > > > panic: mtx_lock() of spin mutex (null) @ > > /usr/src/sys/netinet/ip_output.c:266 Stack backtrace: > > backtrace() > > panic() > > panic: process 414(ntpd):2 Giant but isn't blocked on a mutex > > > > In ddb> I get, > > > > Debugger() > > panic() > > propagate_priority() > > _mtx_lock_sleep() > > _mtx_lock_flags() > > softclock() > > ithread_loop() > > fork_exit() > > fork_trampoline() > > > > I have a crash dump and kernel.debug if further info is need Make sure you have rev 1.250 of ip_input.c. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: mtx_lock() of spin mutex in ip_output.c
On Fri, Nov 07, 2003 at 11:31:45AM -0800, Steven G. Kargl wrote:
> I have a Dell 4150 laptop using dhcp and ntpd on the
> xl0 interface. I did "ifconfig xl0 down" and received
> the following panic (hand transcribed :-( ).
>
> panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266
> Stack backtrace:
> backtrace()
> panic()
> panic: process 414(ntpd):2 Giant but isn't blocked on a mutex
>
> In ddb> I get,
>
> Debugger()
> panic()
> propagate_priority()
> _mtx_lock_sleep()
> _mtx_lock_flags()
> softclock()
> ithread_loop()
> fork_exit()
> fork_trampoline()
>
> I have a crash dump and kernel.debug if further info is need
>
See the gdb -k trace below for further details. Note,
for some unknown reason, I issued a "panic" command at
the ddb> prompt instead of calling dodump directly, so
I think the dump I have below is not the actually trace
we need.
--
Steve
Script started on Fri Nov 7 11:40:42 2003
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266
panic messages:
---
panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266
Stack backtrace:
panic: process 414(ntpd):2 holds Giant but isn't blocked on a mutex
panic: from debugger
Uptime: 1m32s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
Reading symbols from
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/vesa/vesa.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/vesa/vesa.ko.debug
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/snd_ich.ko...done.
Loaded symbols for /boot/kernel/snd_ich.ko
Reading symbols from
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/agp/agp.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/agp/agp.ko.debug
Reading symbols from /boot/kernel/radeon.ko...done.
Loaded symbols for /boot/kernel/radeon.ko
Reading symbols from
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /boot/kernel/blank_saver.ko...done.
Loaded symbols for /boot/kernel/blank_saver.ko
Reading symbols from
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/MOBILE/modules/usr/src/sys/modules/linux/linux.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc04fc14c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04fc4d7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc043cf42 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc043cea2 in db_command (last_cmdp=0xc068a6c0, cmd_table=0x0,
aux_cmd_tablep=0xc065db30, aux_cmd_tablep_end=0xc065db34)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc043cfe5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc043ffe5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc05fd3ac in kdb_trap (type=3, code=0, regs=0xd77cabb0)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc060e20a in trap (frame=
{tf_fs = 24, tf_es = -1066794992, tf_ds = -679739376, tf_edi = 0, tf_esi =
-1067168428, tf_ebp = -679695364, tf_isp = -679695396, tf_ebx = 0, tf_edx = 0, tf_ecx
= 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067461020, tf_cs = 8,
tf_eflags = 662, tf_esp = -1067090437, tf_ss = -1067165548})
at /usr/src/sys/i386/i386/trap.c:582
#9 0xc05fed98 in calltrap () at {standard input}:102
#10 0xc04fc465 in panic (
fmt=0xc0644d54 "process %d(%s):%d holds %s but isn't blocked on a mutex\n")
at /usr/src/sys/kern/kern_shutdown.c:534
#11 0xc04f23d1 in propagate_priority (td=0x0)
at /usr/src/sys/kern/kern_mutex.c:166
#12 0xc04f2b19 in _mtx_lock_sleep (m=0xc069dc80, opts=0,
---Type to continue, or q to quit---
file=0xc0646935 "/usr/src/sys/kern/kern_timeout.c", line=216)
at /usr/src/sys/kern/kern_mutex.c:635
#13 0xc04f2567 in _mtx_lock_flags (m=0xc069dc80, opts=0,
file=0xc0646935 "/usr/src/sys/kern/kern_timeout.c", line=216)
at /usr/src/sys/kern/kern_mutex.c:333
#14 0xc050c9c
panic: mtx_lock() of spin mutex in ip_output.c
I have a Dell 4150 laptop using dhcp and ntpd on the xl0 interface. I did "ifconfig xl0 down" and received the following panic (hand transcribed :-( ). panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266 Stack backtrace: backtrace() panic() panic: process 414(ntpd):2 Giant but isn't blocked on a mutex In ddb> I get, Debugger() panic() propagate_priority() _mtx_lock_sleep() _mtx_lock_flags() softclock() ithread_loop() fork_exit() fork_trampoline() I have a crash dump and kernel.debug if further info is need -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: mtx_lock() of spin mutex
John, John Baldwin wrote: On 26-Nov-2002 Lars Eggert wrote: >#12 0xc02a93e6 in do_dup (td=0xc60a2a80, type=DUP_FIXED, old=-1, new=4, > retval=0xc60a2b18) at /usr/src/sys/kern/kern_descrip.c:485 Hmm, old = -1, this might be fixed by a patch I committed today to fix bugs in do_dup(). Please try revision 1.169 of kern_descrip.c and let me know if it is still broken. Thanks. looks good, can't reproduce the panic anymore. Will keep an eye out for it in the future. Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic: mtx_lock() of spin mutex
On 26-Nov-2002 Lars Eggert wrote:
> John Baldwin wrote:
>
>> On 18-Oct-2002 Lars Eggert wrote:
>>
>> >John Baldwin wrote:
>> >
>> >>What is line 488 of src/sys/kern/kern_descrip.c?
>> >
>> >fhold(fp) in do_dup().
>
> Still see this issue on today's -current. It's easily reproducible with
> a simple "cd ~sunhee" in a tcsh, where ~sunhee is on NFS:
>
> panic: mtx_lock() of spin mutex D\^QR\M-@\M-TR\M-@ \M^UV\M-@\^D @
> /usr/src/sys/kern/kern_descrip.c:485
> cpuid = 1; lapic.id = 0200
> panic: from debugger
> cpuid = 1; lapic.id = 0200
> boot() called on cpu#1
> Uptime: 2m28s
> pfs_vncache_unload(): 3 entries remaining
> Dumping 1023 MB
> 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
> 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
> 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
> 896 912 928 944 960 976 992 1008
> ---
>#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:233
> 233 dumpsys(&dumper);
> (kgdb) bt
>#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:233
>#1 0xc02c737e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
>#2 0xc02c7977 in panic (fmt=0xc0466524 "from debugger")
> at /usr/src/sys/kern/kern_shutdown.c:517
>#3 0xc01533d2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
>#4 0xc015320c in db_command (last_cmdp=0xc04d78a0, cmd_table=0x0,
> aux_cmd_tablep=0xc04cede0, aux_cmd_tablep_end=0xc04cede4)
> at /usr/src/sys/ddb/db_command.c:346
>#5 0xc015344a in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
>#6 0xc01560e5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
>#7 0xc0426547 in kdb_trap (type=3, code=0, regs=0xe0b40be8)
> at /usr/src/sys/i386/i386/db_interface.c:166
>#8 0xc043e63d in trap (frame=
>{tf_fs = 24, tf_es = -1068957680, tf_ds = 16, tf_edi =
> -972412288, tf_esi = 256, tf_ebp = -525071308, tf_isp = -525071340,
> tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err =
> 0, tf_eip = -1069389686, tf_cs = 8, tf_eflags = 642, tf_esp =
> -1068771002, tf_ss = -1068921887})
> at /usr/src/sys/i386/i386/trap.c:603
>#9 0xc0427d18 in calltrap () at {standard input}:99
>#10 0xc02c795f in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
>#11 0xc02bda97 in _mtx_lock_flags (m=0xc0521154, opts=0,
> file=0xc0495d47 "/usr/src/sys/kern/kern_descrip.c", line=485)
> at /usr/src/sys/kern/kern_mutex.c:325
>#12 0xc02a93e6 in do_dup (td=0xc60a2a80, type=DUP_FIXED, old=-1, new=4,
> retval=0xc60a2b18) at /usr/src/sys/kern/kern_descrip.c:485
Hmm, old = -1, this might be fixed by a patch I committed today to fix
bugs in do_dup(). Please try revision 1.169 of kern_descrip.c and let
me know if it is still broken. Thanks.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: mtx_lock() of spin mutex
John Baldwin wrote:
On 18-Oct-2002 Lars Eggert wrote:
>John Baldwin wrote:
>
>>What is line 488 of src/sys/kern/kern_descrip.c?
>
>fhold(fp) in do_dup().
Still see this issue on today's -current. It's easily reproducible with
a simple "cd ~sunhee" in a tcsh, where ~sunhee is on NFS:
panic: mtx_lock() of spin mutex D\^QR\M-@\M-TR\M-@ \M^UV\M-@\^D @
/usr/src/sys/kern/kern_descrip.c:485
cpuid = 1; lapic.id = 0200
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 2m28s
pfs_vncache_unload(): 3 entries remaining
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:233
233 dumpsys(&dumper);
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:233
#1 0xc02c737e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc02c7977 in panic (fmt=0xc0466524 "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc01533d2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc015320c in db_command (last_cmdp=0xc04d78a0, cmd_table=0x0,
aux_cmd_tablep=0xc04cede0, aux_cmd_tablep_end=0xc04cede4)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc015344a in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc01560e5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc0426547 in kdb_trap (type=3, code=0, regs=0xe0b40be8)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc043e63d in trap (frame=
{tf_fs = 24, tf_es = -1068957680, tf_ds = 16, tf_edi =
-972412288, tf_esi = 256, tf_ebp = -525071308, tf_isp = -525071340,
tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err =
0, tf_eip = -1069389686, tf_cs = 8, tf_eflags = 642, tf_esp =
-1068771002, tf_ss = -1068921887})
at /usr/src/sys/i386/i386/trap.c:603
#9 0xc0427d18 in calltrap () at {standard input}:99
#10 0xc02c795f in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc02bda97 in _mtx_lock_flags (m=0xc0521154, opts=0,
file=0xc0495d47 "/usr/src/sys/kern/kern_descrip.c", line=485)
at /usr/src/sys/kern/kern_mutex.c:325
#12 0xc02a93e6 in do_dup (td=0xc60a2a80, type=DUP_FIXED, old=-1, new=4,
retval=0xc60a2b18) at /usr/src/sys/kern/kern_descrip.c:485
#13 0xc02a8643 in dup2 (td=0x0, uap=0x0)
at /usr/src/sys/kern/kern_descrip.c:174
#14 0xc043f2c6 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 4, tf_esi
= 135641600, tf_ebp = -1078050424, tf_isp = -525070988, tf_ebx = -1,
tf_edx = -1078051696, tf_ecx = 135671808, tf_eax = 90, tf_trapno = 12,
tf_err = 2, tf_eip = 134843455, tf_cs = 31, tf_eflags = 646, tf_esp =
-1078051652, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#15 0xc0427d6d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
(kgdb) up 12
(kgdb) list
480 *retval = new;
481 FILEDESC_UNLOCK(fdp);
482 return (0);
483 }
484 fp = fdp->fd_ofiles[old];
485 fhold(fp);
486
487 /*
488 * Expand the table for the new descriptor if needed. This may
489 * block and drop and reacquire the filedesc lock.
The console log has some additional messages anout mutexes, interrupts,
before it spirals down an endless loop of "xlock already held" messages:
panic: mtx_lock() of spin mutex D^QR@TR@ ^UV@^D @
/usr/src/sys/kern/kern_descrip.c:485
cpuid = 1; lapic.id = 0200
Debugger("panic")
Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c0498be1,200,c0497e25,e0b40c70,1) at Debugger+0x5a
panic(c0497e25,c0520f94,c0495d47,1e5,e0b40cb4) at panic+0x12f
_mtx_lock_flags(c0521154,0,c0495d47,1e5,c7078500) at _mtx_lock_flags+0xa7
do_dup(c60a2a80,1,,4,c60a2b18) at do_dup+0xe6
dup2(c60a2a80,e0b40d10,c04bff99,407,c65db418) at dup2+0x33
syscall(2f,2f,bfbf002f,4,815ba00) at syscall+0x3c6
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (90, FreeBSD ELF32, dup2), eip = 0x8098c3f, esp =
0xbfbe3cbc, ebp = 0xbfbe4188 ---
db> panic
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 2m28s
pfs_vncache_unload(): 3 entries remaining
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008
Dump complete
Terminate ACPI
panic: absolutely cannot call smp_ipi_shootdown with interrupts already
disabled
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 2m28s
mpt0: soft reset failed: device not running
mpt1: soft reset failed: device not running
pfs_vncache_unload(): 3 entries rem
Re: panic: mtx_lock() of spin mutex
John Baldwin wrote: On 18-Oct-2002 Lars Eggert wrote: >John Baldwin wrote: > >>What is line 488 of src/sys/kern/kern_descrip.c? > >fhold(fp) in do_dup(). Hrm. You can try adding some KASSERT()'s that the reference count of that struct file isn't zero or negative. Did that, and the KASSERT never fired. I'm still seing this problem on yesterday's -current. It seems to only happen when accessing files on NFS file systems. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic: mtx_lock() of spin mutex
Lars Eggert wrote:
John Baldwin wrote:
> On 18-Oct-2002 Lars Eggert wrote:
>> John Baldwin wrote:
>>
>>> What is line 488 of src/sys/kern/kern_descrip.c?
>>
>> fhold(fp) in do_dup().
>
> Hrm. You can try adding some KASSERT()'s that the reference
> count of that struct file isn't zero or negative.
fd_refcnt is an u_short, but I've added a KASSERT that makes sure it's
not zero, and will test.
Just got the panic again, the KASSERT didn't fire, so the ref count is >
0. Here's a backtrace with today's -current:
[root@nik: /etc] gdb -k /usr/obj/usr/src/sys/KERNEL-1.10/kernel.debug
/var/crash/vmcore.2
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: from debugger
panic messages:
---
panic: mtx_lock() of spin mutex duI\M-@\M-4qI\M-@`\M^NN\M-@\^D @
/usr/src/sys/kern/kern_descrip.c:486
cpuid = 1; lapic.id = 0200
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 19m11s
pfs_vncache_unload(): 6 entries remaining
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:224
224 dumpsys(&dumper);
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:224
#1 0xc02779de in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc0277fd7 in panic (fmt=0xc0413704 "from debugger") at
/usr/src/sys/kern/kern_shutdown.c:508
#3 0xc01509d2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc015080c in db_command (last_cmdp=0xc047bce0, cmd_table=0x0,
aux_cmd_tablep=0xc04732dc,
aux_cmd_tablep_end=0xc04732e0) at /usr/src/sys/ddb/db_command.c:346
#5 0xc0150a4a in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc01536f5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc03d47f7 in kdb_trap (type=3, code=0, regs=0xeb73dbe8) at
/usr/src/sys/i386/i386/db_interface.c:166
#8 0xc03ec35a in trap (frame=
{tf_fs = 24, tf_es = -1069350896, tf_ds = 16, tf_edi =
-955428240, tf_esi = 256, tf_ebp = -344728524, tf_isp = -344728556,
tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err =
0, tf_eip = -1069724870, tf_cs = 8, tf_eflags = 658, tf_esp =
-1069144858, tf_ss = -1069294790}) at /usr/src/sys/i386/i386/trap.c:605
#9 0xc03d5fc8 in calltrap () at {standard input}:99
#10 0xc0277fbf in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:494
#11 0xc026da07 in _mtx_lock_flags (m=0xc0497574, opts=0, file=0xc043acbf
"/usr/src/sys/kern/kern_descrip.c", line=486)
at /usr/src/sys/kern/kern_mutex.c:318
#12 0xc0259541 in do_dup (td=0xc70d5270, type=DUP_FIXED, old=-1, new=4,
retval=0xc70d5304)
at /usr/src/sys/kern/kern_descrip.c:486
#13 0xc0258793 in dup2 (td=0x0, uap=0x0) at
/usr/src/sys/kern/kern_descrip.c:174
#14 0xc03ed066 in syscall (frame=
{tf_fs = 135594031, tf_es = -1078067153, tf_ds = -1078067153,
tf_edi = 4, tf_esi = 135637504, tf_ebp = -1078036088, tf_isp =
-344728204, tf_ebx = -1, tf_edx = -1078037360, tf_ecx = 136126464,
tf_eax = 90, tf_trapno = 12, tf_err = 2, tf_eip = 134842063, tf_cs = 31,
tf_eflags = 646, tf_esp = -1078037316, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1071
#15 0xc03d601d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
(kgdb) up 12
#12 0xc0259541 in do_dup (td=0xc70d5270, type=DUP_FIXED, old=-1, new=4,
retval=0xc70d5304)
at /usr/src/sys/kern/kern_descrip.c:486
486 fhold(fp);
(kgdb) list
481 FILEDESC_UNLOCK(fdp);
482 return (0);
483 }
484 fp = fdp->fd_ofiles[old];
485 KASSERT(fdp->fd_refcnt != 0, ("reference count is zero"));
486 fhold(fp);
487
488 /*
489 * Expand the table for the new descriptor if needed. This may
490 * block and drop and reacquire the filedesc lock.
Lars
--
Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
Re: panic: mtx_lock() of spin mutex
John Baldwin wrote: On 18-Oct-2002 Lars Eggert wrote: John Baldwin wrote: What is line 488 of src/sys/kern/kern_descrip.c? fhold(fp) in do_dup(). Hrm. You can try adding some KASSERT()'s that the reference count of that struct file isn't zero or negative. fd_refcnt is an u_short, but I've added a KASSERT that makes sure it's not zero, and will test. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic: mtx_lock() of spin mutex
On 18-Oct-2002 Lars Eggert wrote: > John Baldwin wrote: > >> >> What is line 488 of src/sys/kern/kern_descrip.c? > > fhold(fp) in do_dup(). Hrm. You can try adding some KASSERT()'s that the reference count of that struct file isn't zero or negative. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mtx_lock() of spin mutex
John Baldwin wrote: What is line 488 of src/sys/kern/kern_descrip.c? fhold(fp) in do_dup(). Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
RE: panic: mtx_lock() of spin mutex
On 17-Oct-2002 Lars Eggert wrote:
> Hi,
>
> I'm tracking down a lock order reversal for hsu@, and just came across
> this other locking panic twice in the last few hours. I run with WITNESS
> and WITNESS_SKIPSPIN, and have never seen this happen unless I set
> debug.witness_ddb=1. The name of the mutex looks definitly fishy.
>
> Let me knowif I can provide more information (tried to get a core dump,
> but machine hung hard after typing "panic".)
>
> panic: mtx_lock() of spin mutex $,J@4(J@^@^GN@^D @
> /usr/src/sys/kern/kern_descrip.c:488
> cpuid = 1; lapic.id = 0200
> Debugger("panic")
> Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0
> db> trace
> Debugger(c043d4b2,200,c043c6ef,eb519c70,1) at Debugger+0x5a
> panic(c043c6ef,c04a2a74,c043a64f,1e8,eb519cb4) at panic+0x12f
> _mtx_lock_flags(c04a2c34,0,c043a64f,1e8,c7238c00) at _mtx_lock_flags+0xa7
> do_dup(c69fb9c0,1,,4,c69fba54) at do_dup+0xe6
> dup2(c69fb9c0,eb519d10,c046443d,42d,c69fa3e8) at dup2+0x33
> syscall(2f,2f,2f,4,815aa00) at syscall+0x406
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (90, FreeBSD ELF32, dup2), eip = 0x80986cf, esp =
> 0xbfbe74bc, ebp = 0xbfbe7988 ---
> db> panic
> panic: from debugger
> cpuid = 1; lapic.id = 0200
> boot() called on cpu#1
What is line 488 of src/sys/kern/kern_descrip.c?
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: mtx_lock() of spin mutex
Lars Eggert wrote: Note that the panic message makes a lot more sense this time around: Argh; which I maybe should have included in the fist place. Typescript attached. Sorry, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute typescript Description: application/java-vm smime.p7s Description: S/MIME Cryptographic Signature
Re: panic: mtx_lock() of spin mutex
Lars Eggert wrote:
I'm tracking down a lock order reversal for hsu@, and just came across
this other locking panic twice in the last few hours.
Found a way to reproduce this at will (shell tab-completion on a
filename on an NFS-mounted file system), and managed to get a core dump.
Note that the panic message makes a lot more sense this time around:
panic: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0200
fault virtual address = 0x2887ff38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0259253
stack pointer = 0x10:0xeb505c94
frame pointer = 0x10:0xeb505cc0
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 2720 (tcsh)
panic: from debugger
cpuid = 1; lapic.id = 0200
Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 1; lapic.id = 0200
instruction pointer = 0x8:0xc03d44ca
stack pointer = 0x10:0xeb505a0c
frame pointer = 0x10:0xeb505a18
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = 2720 (tcsh)
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 8m43s
pfs_vncache_unload(): 3 entries remaining
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:224
224 dumpsys(&dumper);
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:224
#1 0xc027768e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc0277c87 in panic (fmt=0xc0413084 "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:508
#3 0xc01507a2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc01505dc in db_command (last_cmdp=0xc047b5e0, cmd_table=0x0,
aux_cmd_tablep=0xc0472bfc, aux_cmd_tablep_end=0xc0472c00)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc015081a in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc01534c5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc03d4187 in kdb_trap (type=12, code=0, regs=0xeb505c54)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc03ec41c in trap_fatal (frame=0xeb505c54, eva=0)
at /usr/src/sys/i386/i386/trap.c:841
#9 0xc03ec16a in trap_pfault (frame=0xeb505c54, usermode=0, eva=680001336)
at /usr/src/sys/i386/i386/trap.c:760
#10 0xc03ebcce in trap (frame=
{tf_fs = -1068498920, tf_es = 16, tf_ds = -953876464, tf_edi =
-953858560, tf_esi = -965994304, tf_ebp = -347054912, tf_isp =
-347054976, tf_ebx = 680001280, tf_edx = -953876480, tf_ecx = 4, tf_eax
= -1, tf_trapno = 12, tf_err = 0, tf_eip = -1071279533, tf_cs = 8,
tf_eflags = 66178, tf_esp = -953858508, tf_ss = 0}) at
/usr/src/sys/i386/i386/trap.c:446
#11 0xc03d5938 in calltrap () at {standard input}:99
#12 0xc02584c3 in dup2 (td=0x0, uap=0x0)
at /usr/src/sys/kern/kern_descrip.c:174
#13 0xc03ec9f6 in syscall (frame=
{tf_fs = 47, tf_es = -65489, tf_ds = -1078001617, tf_edi = 4,
tf_esi = 135637504, tf_ebp = -1078036088, tf_isp = -347054732, tf_ebx =
-1, tf_edx = -1078037360, tf_ecx = 136105984, tf_eax = 90, tf_trapno =
12, tf_err = 2, tf_eip = 134842063, tf_cs = 31, tf_eflags = 646, tf_esp
= -1078037316, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1071
#14 0xc03d598d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
--
Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
panic: mtx_lock() of spin mutex
Hi,
I'm tracking down a lock order reversal for hsu@, and just came across
this other locking panic twice in the last few hours. I run with WITNESS
and WITNESS_SKIPSPIN, and have never seen this happen unless I set
debug.witness_ddb=1. The name of the mutex looks definitly fishy.
Let me knowif I can provide more information (tried to get a core dump,
but machine hung hard after typing "panic".)
panic: mtx_lock() of spin mutex $,J@4(J@^@^GN@^D @
/usr/src/sys/kern/kern_descrip.c:488
cpuid = 1; lapic.id = 0200
Debugger("panic")
Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c043d4b2,200,c043c6ef,eb519c70,1) at Debugger+0x5a
panic(c043c6ef,c04a2a74,c043a64f,1e8,eb519cb4) at panic+0x12f
_mtx_lock_flags(c04a2c34,0,c043a64f,1e8,c7238c00) at _mtx_lock_flags+0xa7
do_dup(c69fb9c0,1,,4,c69fba54) at do_dup+0xe6
dup2(c69fb9c0,eb519d10,c046443d,42d,c69fa3e8) at dup2+0x33
syscall(2f,2f,2f,4,815aa00) at syscall+0x406
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (90, FreeBSD ELF32, dup2), eip = 0x80986cf, esp =
0xbfbe74bc, ebp = 0xbfbe7988 ---
db> panic
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Lars
--
Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
