Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

[K. Macy]

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

[K. Macy]

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

[K. Macy]

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

[Andrey V. Elsukov]

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

[Mark Johnston]

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

[David Wolfskill]

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

r291494 PANIC mtx_lock() of spin mutex @ /usr/src/sys/kern/vfs_subr.c:512

[Michael Jung]

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: r291494 PANIC mtx_lock() of spin mutex @ /usr/src/sys/kern/vfs_subr.c:512

[Mateusz Guzik]

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"

panic: mtx_lock() of spin mutex in ip_output.c

[Steven G. Kargl]

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 in ip_output.c

[Steve Kargl]

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 return to continue, or q return 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 0xc050c9c4 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:216
#15 0xc04e8332 in ithread_loop (arg=0xc1d16d00)
at /usr/src/sys/kern/kern_intr.c:540
#16 0xc04e7334 in fork_exit (callout=0xc04e81a0

Re: panic: mtx_lock() of spin mutex in ip_output.c

[Sam Leffler]

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

[Steven G. Kargl]

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

[Lars Eggert]

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 remaining
panic: witness_destroy: lock (sleep mutex) pseudofs_vncache is not 
initialized
cpuid = 1; lapic.id = 0200
boot

Re: panic: mtx_lock() of spin mutex

[John Baldwin]

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

[Lars Eggert]

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

[Lars Eggert]

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]

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

[Lars Eggert]

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]

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]

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

[John Baldwin]

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

panic: mtx_lock() of spin mutex

[Lars Eggert]

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

Re: panic: mtx_lock() of spin mutex

[Lars Eggert]

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

Re: panic: mtx_lock() of spin mutex

[Lars Eggert]

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