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: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"
On Fri, Jun 9, 2017 at 3:55 PM, David Wolfskill wrote: ... > Gleb committed r319754; I finally(!) had a chance to revert the > reversion of r319722, then apply r319754 and rebuild; the follow-up > smoke test was successful. ... > [Apparently hald invokes stat(2) on a listening socket, which was ... > unexpected.] This might have been caught by lib/libc/sys/stat_test:stat_socket . If only the compat stuff was working on ci.freebsd.org as well, or the test(s) had been run... -Ngie ___ 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 @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"
On Fri, Jun 09, 2017 at 08:23:55AM -0700, David Wolfskill wrote: > ... > > The main suspect is r319722. > > Try reverting it or downgrading before it (the later might be simple due > > to the patch size). > > > > It was easy enough for me to use "svn diff -c r319722" & > "svn patch --reverse-diff" to effectively revert r319722. > > I re-ran the build after that, and a subsequent reboot allowed me to > "sudo service hald onestart" (which whined a bit about dbus not being > enabled but started it anyway), after which I was able to start xdm -- > so that seems to have been successful. > > Perhaps I'll chat with Gleb a bit later today. :-) (Our cubes are > adjacent.) > ... Gleb committed r319754; I finally(!) had a chance to revert the reversion of r319722, then apply r319754 and rebuild; the follow-up smoke test was successful. > Thanks, Konstantin! :-) > ... And Gleb! :-) [Apparently hald invokes stat(2) on a listening socket, which was ... unexpected.] Peace, david -- David H. Wolfskill da...@catwhisker.org Looking forward to telling Mr. Trump: "You're fired!" See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"
On Fri, Jun 09, 2017 at 04:55:17PM +0300, Konstantin Belousov wrote: > On Fri, Jun 09, 2017 at 05:57:15AM -0700, David Wolfskill wrote: > > Build machine updated from r319689 to r319733 OK; smoke test was > > uneventful. > > > > Laptop updated similarly, but smoke test was a little more "interesting". > > > > Turns out that laptop gets to multi-user mode OK... if I disable > > starting xdm, devd, and hald. But then, issuing "service hald onestart" > > generates the panic in question -- at r319733. At r319689, xdm & > > friends worked fine. > > > > I have placed copies of the /var/crash/*.6 files in > > <http://www.catwhisker.org/~david/FreeBSD/head/hald/> -- along with > > gzipped copies, as well. (It's residential DSL in the US, so there's > > not a huge amount of bandwidth.) > > > > I get the impression that something (ini hald) was trying to use > > the freebsd11 version of stat(), and Something Bad happened: > > > > panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305 > > cpuid = 7 > > time = 1497011454 > > KDB: stack backtrace: > > db_trace_self_wrapper() at 0x803a461b = > > db_trace_self_wrapper+0x2b/frame 0xfe0c268ff600 > > vpanic() at 0x80a1f94c = vpanic+0x19c/frame 0xfe0c268ff680 > > kassert_panic() at 0x80a1f7a6 = kassert_panic+0x126/frame > > 0xfe0c268ff6f0 > > __mtx_lock_flags() at 0x809fedfe = __mtx_lock_flags+0x14e/frame > > 0xfe0c268ff740 > > soo_stat() at 0x80a8f8f0 = soo_stat+0x60/frame 0xfe0c268ff770 > > The main suspect is r319722. > Try reverting it or downgrading before it (the later might be simple due > to the patch size). > It was easy enough for me to use "svn diff -c r319722" & "svn patch --reverse-diff" to effectively revert r319722. I re-ran the build after that, and a subsequent reboot allowed me to "sudo service hald onestart" (which whined a bit about dbus not being enabled but started it anyway), after which I was able to start xdm -- so that seems to have been successful. Perhaps I'll chat with Gleb a bit later today. :-) (Our cubes are adjacent.) Thanks, Konstantin! :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Looking forward to telling Mr. Trump: "You're fired!" See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"
On Fri, Jun 09, 2017 at 05:57:15AM -0700, David Wolfskill wrote: > Build machine updated from r319689 to r319733 OK; smoke test was > uneventful. > > Laptop updated similarly, but smoke test was a little more "interesting". > > Turns out that laptop gets to multi-user mode OK... if I disable > starting xdm, devd, and hald. But then, issuing "service hald onestart" > generates the panic in question -- at r319733. At r319689, xdm & > friends worked fine. > > I have placed copies of the /var/crash/*.6 files in > <http://www.catwhisker.org/~david/FreeBSD/head/hald/> -- along with > gzipped copies, as well. (It's residential DSL in the US, so there's > not a huge amount of bandwidth.) > > I get the impression that something (ini hald) was trying to use > the freebsd11 version of stat(), and Something Bad happened: > > panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305 > cpuid = 7 > time = 1497011454 > KDB: stack backtrace: > db_trace_self_wrapper() at 0x803a461b = > db_trace_self_wrapper+0x2b/frame 0xfe0c268ff600 > vpanic() at 0x80a1f94c = vpanic+0x19c/frame 0xfe0c268ff680 > kassert_panic() at 0x80a1f7a6 = kassert_panic+0x126/frame > 0xfe0c268ff6f0 > __mtx_lock_flags() at 0x809fedfe = __mtx_lock_flags+0x14e/frame > 0xfe0c268ff740 > soo_stat() at 0x80a8f8f0 = soo_stat+0x60/frame 0xfe0c268ff770 The main suspect is r319722. Try reverting it or downgrading before it (the later might be simple due to the patch size). > kern_fstat() at 0x809cb378 = kern_fstat+0xa8/frame 0xfe0c268ff7c0 > freebsd11_fstat() at 0x809cb28d = freebsd11_fstat+0x1d/frame > 0xfe0c268ff930 > amd64_syscall() at 0x80e31fb4 = amd64_syscall+0x5a4/frame > 0xfe0c268ffab0 > Xfast_syscall() at 0x80e12eab = Xfast_syscall+0xfb/frame > 0xfe0c268ffab0 > --- syscall (189, FreeBSD ELF64, freebsd11_fstat), rip = 0x801b4973a, rsp = > 0x7fffe988, rbp = 0x7fffea20 --- > KDB: enter: panic > > > Note: the hald in question was built under FreeBSD stable/11 (as > are all my ports); I noted the existence of, and installed, > ports/misc/compat11s before (re-)creating the crash. (And yes, the > ports that have kernel modules get the kernel modules rebuilt on > head every time I rebuild the kernel on head.) > > With the caveat that I actually use the laptop in my day-to-day > activities, I'm happy to try various combinations of patching, > testing, and reporting results. > > Peace, > david > -- > David H. Wolfskillda...@catwhisker.org > Looking forward to telling Mr. Trump: "You're fired!" > > 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"
Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"
Build machine updated from r319689 to r319733 OK; smoke test was uneventful. Laptop updated similarly, but smoke test was a little more "interesting". Turns out that laptop gets to multi-user mode OK... if I disable starting xdm, devd, and hald. But then, issuing "service hald onestart" generates the panic in question -- at r319733. At r319689, xdm & friends worked fine. I have placed copies of the /var/crash/*.6 files in <http://www.catwhisker.org/~david/FreeBSD/head/hald/> -- along with gzipped copies, as well. (It's residential DSL in the US, so there's not a huge amount of bandwidth.) I get the impression that something (ini hald) was trying to use the freebsd11 version of stat(), and Something Bad happened: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305 cpuid = 7 time = 1497011454 KDB: stack backtrace: db_trace_self_wrapper() at 0x803a461b = db_trace_self_wrapper+0x2b/frame 0xfe0c268ff600 vpanic() at 0x80a1f94c = vpanic+0x19c/frame 0xfe0c268ff680 kassert_panic() at 0x80a1f7a6 = kassert_panic+0x126/frame 0xfe0c268ff6f0 __mtx_lock_flags() at 0x809fedfe = __mtx_lock_flags+0x14e/frame 0xfe0c268ff740 soo_stat() at 0x80a8f8f0 = soo_stat+0x60/frame 0xfe0c268ff770 kern_fstat() at 0x809cb378 = kern_fstat+0xa8/frame 0xfe0c268ff7c0 freebsd11_fstat() at 0x809cb28d = freebsd11_fstat+0x1d/frame 0xfe0c268ff930 amd64_syscall() at 0x80e31fb4 = amd64_syscall+0x5a4/frame 0xfe0c268ffab0 Xfast_syscall() at 0x80e12eab = Xfast_syscall+0xfb/frame 0xfe0c268ffab0 --- syscall (189, FreeBSD ELF64, freebsd11_fstat), rip = 0x801b4973a, rsp = 0x7fffe988, rbp = 0x7fffea20 --- KDB: enter: panic Note: the hald in question was built under FreeBSD stable/11 (as are all my ports); I noted the existence of, and installed, ports/misc/compat11s before (re-)creating the crash. (And yes, the ports that have kernel modules get the kernel modules rebuilt on head every time I rebuild the kernel on head.) With the caveat that I actually use the laptop in my day-to-day activities, I'm happy to try various combinations of patching, testing, and reporting results. Peace, david -- David H. Wolfskill da...@catwhisker.org Looking forward to telling Mr. Trump: "You're fired!" See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
RE: mtx_lock() of spin mutex (null)
On 04-Aug-2003 Holger Kipp wrote:
> Got the following panic on a completely idle -CURRENT from July 26th:
> so this was presumably caused by the daily or weekly jobs.
>
> panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/vfs_subr.c:1186
> Debugger("panic")
> stopped at Debugger +0x54: xchgl %ebx,in_Debugger.0
> db>
if (VOP_GETVOBJECT(vp, &object) == 0) {
VM_OBJECT_LOCK(object);
vm_object_pip_wait(object, "vnvlbx");
VM_OBJECT_UNLOCK(object);
}
That line is the VM_OBJECT_LOCK(). It looks like the mutex hasn't
been initialized and is just all zeros.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mtx_lock() of spin mutex (null)
Got the following panic on a completely idle -CURRENT from July 26th:
so this was presumably caused by the daily or weekly jobs.
panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/vfs_subr.c:1186
Debugger("panic")
stopped at Debugger +0x54: xchgl %ebx,in_Debugger.0
db>
Regards,
Holger Kipp
--
Holger Kipp, Dipl.-Math., Systemadministrator | alogis AG
Fon: +49 (0)30 / 43 65 8 - 114 | Berliner Strasse 26
Fax: +49 (0)30 / 43 65 8 - 214 | D-13507 Berlin Tegel
email: [EMAIL PROTECTED] | http://www.alogis.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
