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 abo
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);
>
> -
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(c
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 ch
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
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
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
>
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
eived
> > > 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):
llowing 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
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 (nul
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 4
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
l 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
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@T
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 ne
f 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
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
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]> <><
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
ness_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_descri
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: applic
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 t
et 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 Deb
24 matches
Mail list logo
