> Ok then, remove the debugging (WITNESS, INVARIANT*), leave in place
> KDB and DDB, add GDB and try at least to get a coredump when it
> deadlocks.
OK, will do. Am building a KDB/GDB/DDB kenel now.
-pete.
___
freebsd-stable@freebsd.org mailing list
htt
2010/1/19 Pete French :
>> May you post your kernel config?
>
> sure...
>
> include GENERIC
> ident DEBUG
> options KDB
> options DDB
> options WITNESS
> options INVARIANT_SUPPORT
> options IN
> May you post your kernel config?
sure...
include GENERIC
ident DEBUG
options KDB
options DDB
options WITNESS
options INVARIANT_SUPPORT
options INVARIANTS
That one doesnt lockup, or
2010/1/18 Pete French :
>> One may never know, try without WITNESS but still the same setup.
>
> Well, I have been running like this for three days with no lockups
> dissapointingly. I just saw that you commited the lock patches, so
> am going to update to the latest STABLE and go back to GENERIC t
> One may never know, try without WITNESS but still the same setup.
Well, I have been running like this for three days with no lockups
dissapointingly. I just saw that you commited the lock patches, so
am going to update to the latest STABLE and go back to GENERIC to see if
that still locks up (as
2010/1/15 Pete French :
> Well, the machine has been running the WITNESS + INVARIANTS kernel
> for 20 hours now without locking up.This looks like what I
> saw before - compiling in WITNESS stops it locking up -(
>
> Is there any use in my runing a kernel with just INVARIANTS to see if
> that will
Well, the machine has been running the WITNESS + INVARIANTS kernel
for 20 hours now without locking up.This looks like what I
saw before - compiling in WITNESS stops it locking up -(
Is there any use in my runing a kernel with just INVARIANTS to see if
that will lcok ? I know it locks with KDN and
2010/1/14 Pete French :
>> INVARIANTS requires INVARIANT_SUPPORT [sic] in the kernel config (see
>> comments in GENERIC).
>
> Ah, right, that would explain it. Thanks!
INVARIANT_SUPPORT is made mandatory in order to allow non-INVARIANT
kernel to be able to handle INVARIANT compiled modules.
Atti
> INVARIANTS requires INVARIANT_SUPPORT [sic] in the kernel config (see
> comments in GENERIC).
Ah, right, that would explain it. Thanks!
-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To uns
On Jan 14, 2010, at 2:11 PM, Pete French wrote:
>> Also enable INVARIANTS.
>
> Including INVARIANTS stops my kernel from building. It
> has been this way since 8.0 (this is why I only
> had WITNESS compiled in). It fails with many many
> errors like this:
>
> /usr/src/sys/vm/vm_map.c:575: undef
> Also enable INVARIANTS.
Including INVARIANTS stops my kernel from building. It
has been this way since 8.0 (this is why I only
had WITNESS compiled in). It fails with many many
errors like this:
/usr/src/sys/vm/vm_map.c:575: undefined reference to `_mtx_assert'
My kernel config file looks like
2010/1/14 Pete French :
>> http://www.freebsd.org/~attilio/lockmgr_fix8.diff
>>
>> I'm seeking for testers here.
>> Any report would be very much appreciated.
>
> I tested the patch on my machine which locks up, and I am afraid that it
> still locks, even with the patch applied. The last things on
> http://www.freebsd.org/~attilio/lockmgr_fix8.diff
>
> I'm seeking for testers here.
> Any report would be very much appreciated.
I tested the patch on my machine which locks up, and I am afraid that it
still locks, even with the patch applied. The last things on the console
before the lock are.
> In order to allow a MFC, a similar approach, being a bit sub-optimal,
> but not breaking ABI, has been prepared for STABLE_8:
> http://www.freebsd.org/~attilio/lockmgr_fix8.diff
>
> I'm seeking for testers here.
> Any report would be very much appreciated.
I'll give this a shot - I ahve a machin
As people following HEAD may have seen, around 1 month ago a fix to
lockmgr(9) has been committed that should prevent a deadlock for that
primitive (the fixup is composed by r200447,201703,201709-201710).
As long as the approach choosen in HEAD is optimal, unluckilly it does
introduce an ABI breaka
15 matches
Mail list logo
