witness_lock_list_get: witness exhausted

runs poudriere for amd64+arm builds and I again noticed "witness_lock_list_get: witness exhausted" on the console (which I don't pay much attention to). UNAME: FreeBSD poudriere.gopai.com 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n259872-f948cb717f50: Wed Dec 28 13:13:43 EST 20

Re: usbhid panic when switching vt-s (invariants+witness enabled)

On 9/30/22 12:31, Andriy Gapon wrote: On 26/09/2022 18:13, Hans Petter Selasky wrote: On 9/23/22 23:43, Hans Petter Selasky wrote: vpanic() at 0x808f4c84 = vpanic+0x184/frame 0xfe003590e900 panic() at 0x808f4a33 = panic+0x43/frame 0xfe003590e960 sleepq_add() at

Re: usbhid panic when switching vt-s (invariants+witness enabled)

On 26/09/2022 18:13, Hans Petter Selasky wrote: On 9/23/22 23:43, Hans Petter Selasky wrote: vpanic() at 0x808f4c84 = vpanic+0x184/frame 0xfe003590e900 panic() at 0x808f4a33 = panic+0x43/frame 0xfe003590e960 sleepq_add() at 0x809521ab = sleepq_add+0x37b/frame

Re: usbhid panic when switching vt-s (invariants+witness enabled)

On 9/23/22 23:43, Hans Petter Selasky wrote: vpanic() at 0x808f4c84 = vpanic+0x184/frame 0xfe003590e900 panic() at 0x808f4a33 = panic+0x43/frame 0xfe003590e960 sleepq_add() at 0x809521ab = sleepq_add+0x37b/frame 0xfe003590e9b0 _sleep() at 0x80902118

Re: usbhid panic when switching vt-s (invariants+witness enabled)

On 9/23/22 23:33, Andriy Gapon wrote: It seems that the problem may be related to different keyboard LED states between the VTs.  The system is a fresh stable/13.  The panic looks like an attempt to sleep while in an interrupt thread (a callout?). Hi, I suspect vt_switch_timer must have

usbhid panic when switching vt-s (invariants+witness enabled)

It seems that the problem may be related to different keyboard LED states between the VTs. The system is a fresh stable/13. The panic looks like an attempt to sleep while in an interrupt thread (a callout?). panic: sleepq_add: td 0xf80006af to sleep on wchan 0xf802ea752e08

Re: Can't build with INVARIANTS but not WITNESS

On 4/27/22, John F Carr wrote: > My -CURRENT kernel has INVARIANTS (inherited from GENERIC) but not WITNESS: > > include GENERIC > ident STRIATUS > nooptions WITNESS > nooptions WITNESS_SKIPSPIN > > My kernel build fails: > > /usr/home/jfc/freebsd/sr

Can't build with INVARIANTS but not WITNESS

My -CURRENT kernel has INVARIANTS (inherited from GENERIC) but not WITNESS: include GENERIC ident STRIATUS nooptions WITNESS nooptions WITNESS_SKIPSPIN My kernel build fails: /usr/home/jfc/freebsd/src/sys/kern/vfs_lookup.c:102:13: error: variable 'line' set but not used [-Werror

Re: witness_lock_list_get: witness exhausted

n wrote: >> > >> >> On Tuesday, November 28, 2017 02:46:03 PM Michael Jung wrote: >> >> >> >>> Hi! >> >>> >> >>> I've recently up'd my processor count on our poudriere box and have >> >>> started noticing t

Re: witness_lock_list_get: witness exhausted

! > >>> > >>> I've recently up'd my processor count on our poudriere box and have > >>> started noticing the error > >>> "witness_lock_list_get: witness exhausted" on the console. The kernel > >>> *DOES NOT* crash but I > >>

Re: witness_lock_list_get: witness exhausted

on our poudriere box and have >>> started noticing the error >>> "witness_lock_list_get: witness exhausted" on the console. The kernel >>> *DOES NOT* crash but I >>> thought the report may be useful to someone. >>> >>> $ uname -a >>&g

Re: witness_lock_list_get: witness exhausted

On 2018-01-08 13:39, John Baldwin wrote: On Tuesday, November 28, 2017 02:46:03 PM Michael Jung wrote: Hi! I've recently up'd my processor count on our poudriere box and have started noticing the error "witness_lock_list_get: witness exhausted" on the console. The kernel *DOES

Re: witness_lock_list_get: witness exhausted

On Tuesday, November 28, 2017 02:46:03 PM Michael Jung wrote: > Hi! > > I've recently up'd my processor count on our poudriere box and have > started noticing the error > "witness_lock_list_get: witness exhausted" on the console. The kernel > *DOES NOT* crash bu

witness_lock_list_get: witness exhausted

Hi! I've recently up'd my processor count on our poudriere box and have started noticing the error "witness_lock_list_get: witness exhausted" on the console. The kernel *DOES NOT* crash but I thought the report may be useful to someone. $ uname -a FreeBSD poudriere 12.0-CURRENT Fr

r324870 breaks boot on amd64 with WITNESS (was "svn commit: r324870 - in head/sys: amd64/include kern")

All, I highly advise not upgrading to this revision if you use WITNESS. Please see the attached message for more details and reply to the commit log. Cheers, -Ngie > Begin forwarded message: > > From: "Ngie Cooper (yaneurabeya)" <yaneurab...@gmail.com> > Subj

Re: New warnings from WITNESS

> On 6 Nov 2016, at 19:41, Scott Long wrote: > > >> On Nov 6, 2016, at 11:01 AM, Michael Tuexen wrote: >> >>> On 6 Nov 2016, at 15:39, Konstantin Belousov wrote: >>> >>> On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen

Re: New warnings from WITNESS

> On Nov 6, 2016, at 11:01 AM, Michael Tuexen wrote: > >> On 6 Nov 2016, at 15:39, Konstantin Belousov wrote: >> >> On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen wrote: On 6 Nov 2016, at 13:28, Konstantin Belousov

Re: New warnings from WITNESS

> On 6 Nov 2016, at 15:39, Konstantin Belousov wrote: > > On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen wrote: >>> On 6 Nov 2016, at 13:28, Konstantin Belousov wrote: >>> >>> On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote:

Re: New warnings from WITNESS

On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen wrote: > > On 6 Nov 2016, at 13:28, Konstantin Belousov wrote: > > > > On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote: > >> bus_dmamap_create with the following non-sleepable locks held: > >> exclusive

Re: New warnings from WITNESS

> On 6 Nov 2016, at 13:28, Konstantin Belousov wrote: > > On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote: >> bus_dmamap_create with the following non-sleepable locks held: >> exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ >>

Re: New warnings from WITNESS

On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote: > bus_dmamap_create with the following non-sleepable locks held: > exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ > dev/mpt/mpt.c:2287 > stack backtrace: > #0 0x80ac0300 at witness_debugger+0x70 > #1

New warnings from WITNESS

Dear all, when booting a recent kernel [freebsd12:~] tuexen% uname -a FreeBSD freebsd12.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #702 r308359M: Sun Nov 6 11:55:17 CET 2016 tuexen@freebsd12.testbed:/usr/home/tuexen/head/sys/amd64/compile/SCTP amd64 on a VMWare Fusion VM, I get a lot of

Re: WITNESS messages on 11

I'm not sure, but maybe this is related to [1]. FWIW, according to [2], LORs of witness means deadlock could be happened in that situation (if it's not a false positive), not necessarily an accurate deadlock happening IMO :) I hope it helps :) [1]http://lists.freebsd.org/pipermail/freebsd

WITNESS messages on 11

I saw this every time I tried to install 11 from the VM image recently. While copying over the ports tree with the command "nc | tar xzf -" I get the messages, see below. Yuri lock order reversal: 1st 0xfe003ca55570 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3512 2nd

Re: Is a high witness refcount indicative of a missing unlock?

On Sunday, March 29, 2015 02:29:42 PM Lars wrote: Hi, I am poking around for a cause for my repeating deadlock issues on my system based on r 279869. ddb show witness show the “vnode interlock” and the “zfs” locks both with reference counts over 200K. Obviously they are related

Re: Is a high witness refcount indicative of a missing unlock?

from the ddb kernel debugger (man 8 ddb) using the “show witness” command Lars On Mar 29, 2015, at 19:14, Shane Ambler free...@shaneware.biz wrote: On 30/03/2015 05:59, Lars wrote: Hi, I am poking around for a cause for my repeating deadlock issues on my system based on r 279869. ddb show

Re: Is a high witness refcount indicative of a missing unlock?

On 30/03/2015 05:59, Lars wrote: Hi, I am poking around for a cause for my repeating deadlock issues on my system based on r 279869. ddb show witness show the “vnode interlock” and the “zfs” locks both with reference counts over 200K. Obviously they are related, and there is a find

Is a high witness refcount indicative of a missing unlock?

Hi, I am poking around for a cause for my repeating deadlock issues on my system based on r 279869. ddb show witness show the “vnode interlock” and the “zfs” locks both with reference counts over 200K. Obviously they are related, and there is a find running (all the filesystems on this machine

Re: witness and modules.

modules with witness definitions when linking with a kernel compiled with witness? This was true at one stage but I remember some work was done to make them compatible. You should not need this. modules always call functions in the kernel for lock operations and this functions are what invoke

Re: witness and modules.

Elischer wrote: Do we need to compile all modules with witness definitions when linking with a kernel compiled with witness? This was true at one stage but I remember some work was done to make them compatible. You should not need this. modules always call functions in the kernel for lock operations

Re: witness and modules.

, John Baldwin wrote: On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote: Do we need to compile all modules with witness definitions when linking with a kernel compiled with witness? This was true at one stage but I remember some work was done to make them compatible. You

Re: witness and modules.

On Dec 1, 2014, at 10:08 PM, Julian Elischer jul...@freebsd.org wrote: On 12/1/14, 11:39 PM, John Baldwin wrote: On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote: Do we need to compile all modules with witness definitions when linking with a kernel compiled with witness

Re: witness and modules.

On 12/3/14, 12:24 AM, Warner Losh wrote: On Dec 1, 2014, at 10:08 PM, Julian Elischer jul...@freebsd.org wrote: On 12/1/14, 11:39 PM, John Baldwin wrote: On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote: Do we need to compile all modules with witness definitions when linking

Re: witness and modules.

On 12/3/14, 12:24 AM, Warner Losh wrote: On Dec 1, 2014, at 10:08 PM, Julian Elischer jul...@freebsd.org wrote: On 12/1/14, 11:39 PM, John Baldwin wrote: On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote: Do we need to compile all modules with witness definitions when linking

Re: witness and modules.

On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote: Do we need to compile all modules with witness definitions when linking with a kernel compiled with witness? This was true at one stage but I remember some work was done to make them compatible. You should not need this. modules

Re: witness and modules.

On 12/1/14, 11:39 PM, John Baldwin wrote: On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote: Do we need to compile all modules with witness definitions when linking with a kernel compiled with witness? This was true at one stage but I remember some work was done to make them

witness and modules.

Do we need to compile all modules with witness definitions when linking with a kernel compiled with witness? This was true at one stage but I remember some work was done to make them compatible. ___ freebsd-current@freebsd.org mailing list http

Re: WITNESS observes 2 LORs on Boot of Release 10.1

On 11/22/2014 03:51 PM, Benjamin Kaduk wrote: On Fri, 21 Nov 2014, Ellis H. Wilson III wrote: Before I start, and this is mainly geared to my responder Benjamin Kaduk, based on your response, are you suggesting that the cnputc WITNESS panic you expected to happen is now completely unavoidable

Re: WITNESS observes 2 LORs on Boot of Release 10.1

On Fri, 21 Nov 2014, Ellis H. Wilson III wrote: Before I start, and this is mainly geared to my responder Benjamin Kaduk, based on your response, are you suggesting that the cnputc WITNESS panic you expected to happen is now completely unavoidable in FreeBSD 10? I.E., is this a spinlock

Re: WITNESS observes 2 LORs on Boot of Release 10.1

/random/random_harvestq.c, sys/dev/syscons/syscons.c, and sys/kern/subr_sleepqueue.c. Before I start, and this is mainly geared to my responder Benjamin Kaduk, based on your response, are you suggesting that the cnputc WITNESS panic you expected to happen is now completely unavoidable in FreeBSD 10

WITNESS observes 2 LORs on Boot of Release 10.1

Hi all, I'm observing the following two WITNESS LORs being thrown upon boot-up of 10.0 and I was tracking current, hoping they would go away by 10.1, but it seems they persist as shown below. I suspect this is because current is being built with WITNESS on but also with SKIPSPIN on. So

Re: WITNESS observes 2 LORs on Boot of Release 10.1

week. I'm happy to open a bug on this if that's the desirable course of action, or to even assist in fixing it, but I wanted to first see if anybody knew about these already (they didn't show up on the known LORs list on quick perusal) or if this was simply a case of WITNESS being overly

Re: WITNESS observes 2 LORs on Boot of Release 10.1

On 11/18/2014 05:39 PM, Benjamin Kaduk wrote: On Tue, 18 Nov 2014, Ellis H. Wilson III wrote: I'm observing the following two WITNESS LORs being thrown upon boot-up of 10.0 and I was tracking current, hoping they would go away by 10.1, but it seems they persist as shown below. I suspect

WITNESS: unable to allocate a new witness object

I'm trying to set up textdump(4). On boot I see: WITNESS: unable to allocate a new witness object also Expensive timeout(9) function: 0x9ffc00e222e0(0xa09ed320) 0.002434387 s kickstart. Does the first indicate I haven't set up WITNESS correctly? What does the second tell me

Re: WITNESS: unable to allocate a new witness object

On Tue, Oct 15, 2013 at 4:17 PM, Anton Shterenlikht me...@bris.ac.uk wrote: I'm trying to set up textdump(4). On boot I see: WITNESS: unable to allocate a new witness object also It means that you run out of WITNESS object on the free list. Expensive timeout(9) function

Witness message about lock order reversal on 10 (head)

I got these messages on 10 head, rev.254235, during 'filesystem full' condition. Yuri = log = lock order reversal: 1st 0xff80f7432470 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3054 2nd 0xfe00075b5600 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack

Re: Witness message about lock order reversal on 10 (head)

WITNESS. Thanks, -- Davide On Mon, 19 Aug 2013, Yuri wrote: I got these messages on 10 head, rev.254235, during 'filesystem full' condition. Yuri = log = lock order reversal: 1st 0xff80f7432470 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3054 2nd 0xfe00075b5600 dirhash

Re: Spurious witness warning when destroying spin mtx

On Saturday, November 24, 2012 10:01:39 am Attilio Rao wrote: On Sat, Nov 24, 2012 at 3:08 AM, Ryan Stone ryst...@gmail.com wrote: Today I saw a spurious witness warning for acquiring duplicate lock of same type. The root cause is that when running mtx_destroy on a spinlock that is held

Re: Spurious witness warning when destroying spin mtx

On Friday, November 23, 2012 10:08:28 PM Ryan Stone wrote: Today I saw a spurious witness warning for acquiring duplicate lock of same type. The root cause is that when running mtx_destroy on a spinlock that is held by the current thread, mtx_destroy calls spinlock_exit() before calling

Re: Spurious witness warning when destroying spin mtx

On Sat, Nov 24, 2012 at 3:01 PM, Attilio Rao atti...@freebsd.org wrote: On Sat, Nov 24, 2012 at 3:08 AM, Ryan Stone ryst...@gmail.com wrote: Today I saw a spurious witness warning for acquiring duplicate lock of same type. The root cause is that when running mtx_destroy on a spinlock

Re: Spurious witness warning when destroying spin mtx

On Sat, Nov 24, 2012 at 3:08 AM, Ryan Stone ryst...@gmail.com wrote: Today I saw a spurious witness warning for acquiring duplicate lock of same type. The root cause is that when running mtx_destroy on a spinlock that is held by the current thread, mtx_destroy calls spinlock_exit() before

Re: Spurious witness warning when destroying spin mtx

On Sat, Nov 24, 2012 at 10:01 AM, Attilio Rao atti...@freebsd.org wrote: I seriously wonder why right now we don't assume the lock is unheld. There are likely historically reasons for that, but I would like to know which one are those and eventually fix them out. FWIK, all the other locking

Re: Spurious witness warning when destroying spin mtx

On Sat, Nov 24, 2012 at 3:46 PM, Ryan Stone ryst...@gmail.com wrote: On Sat, Nov 24, 2012 at 10:01 AM, Attilio Rao atti...@freebsd.org wrote: I seriously wonder why right now we don't assume the lock is unheld. There are likely historically reasons for that, but I would like to know which

Re: Spurious witness warning when destroying spin mtx

On Sat, Nov 24, 2012 at 3:51 PM, Attilio Rao atti...@freebsd.org wrote: On Sat, Nov 24, 2012 at 3:46 PM, Ryan Stone ryst...@gmail.com wrote: On Sat, Nov 24, 2012 at 10:01 AM, Attilio Rao atti...@freebsd.org wrote: I seriously wonder why right now we don't assume the lock is unheld. There are

Spurious witness warning when destroying spin mtx

Today I saw a spurious witness warning for acquiring duplicate lock of same type. The root cause is that when running mtx_destroy on a spinlock that is held by the current thread, mtx_destroy calls spinlock_exit() before calling WITNESS_UNLOCK, which opens up a window in which the CPU can

Re: new panic in cpu_reset() with WITNESS

is a convenience reference to the whole thread on gmane: http://thread.gmane.org/gmane.os.freebsd.current/139307 A short summary. Prerequisites: an SMP x86 system, its kernel is configured with WITNESS !WITNESS_SKIPSPIN (this is important) and a system uses serial console via uart

Re: new panic in cpu_reset() with WITNESS

who might get interested here is a convenience reference to the whole thread on gmane: http://thread.gmane.org/gmane.os.freebsd.current/139307 A short summary. Prerequisites: an SMP x86 system, its kernel is configured with WITNESS !WITNESS_SKIPSPIN (this is important) and a system uses

Re: locks under printf(9) and WITNESS

BTW, I see another LOR with spinlocks, maybe harmless. o sysbeep() is called from syscons code and it calls timeout() which introduces the following order: scrlock - callout. o The callout code programming of event timers introduces the following order (via callout_new_inserted ==

Re: new panic in cpu_reset() with WITNESS

on 24/01/2012 14:32 Gleb Smirnoff said the following: Yes, now: Rebooting... lock order reversal: 1st 0x80937140 smp rendezvous (smp rendezvous) @ /usr/src/head/sys/kern/kern_shutdown.c:542 2nd 0xfe0001f5d838 uart_hwmtx (uart_hwmtx) @

Re: new panic in cpu_reset() with WITNESS

On Mon, Jan 23, 2012 at 06:56:08PM +0200, Andriy Gapon wrote: A on 23/01/2012 18:46 Gleb Smirnoff said the following: A On Mon, Jan 23, 2012 at 06:43:23PM +0200, Andriy Gapon wrote: A A db bt A A Tracing pid 1 tid 11 td 0xfe0001d5e000 A A kdb_enter() at kdb_enter+0x3b A A panic()

Re: new panic in cpu_reset() with WITNESS

on 24/01/2012 13:54 Gleb Smirnoff said the following: On Mon, Jan 23, 2012 at 06:56:08PM +0200, Andriy Gapon wrote: A on 23/01/2012 18:46 Gleb Smirnoff said the following: A On Mon, Jan 23, 2012 at 06:43:23PM +0200, Andriy Gapon wrote: A A db bt A A Tracing pid 1 tid 11 td

Re: new panic in cpu_reset() with WITNESS

On Tue, Jan 24, 2012 at 02:09:03PM +0200, Andriy Gapon wrote: A on 24/01/2012 13:54 Gleb Smirnoff said the following: A On Mon, Jan 23, 2012 at 06:56:08PM +0200, Andriy Gapon wrote: A A on 23/01/2012 18:46 Gleb Smirnoff said the following: A A On Mon, Jan 23, 2012 at 06:43:23PM +0200, Andriy

Re: new panic in cpu_reset() with WITNESS

between A T r229851 and r229932, that happens on shutdown if A T kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. A A I've run through binary search and panic was introduced A by r229854. A A A Which means that it was introduced by one of the earlier commits (probably A mine

Re: locks under printf(9) and WITNESS [Was: new panic in cpu_reset() with WITNESS]

). But there are a A number of console-specific locks (scrlock, uart_hwmtx, syscons video lock) A which are acquired under cnputs_mtx, but which are *not* marked as A MTX_NOWITNESS. More, they are specified in the witness order_lists as if we A certainly know a correct order for them. A I think

Re: new panic in cpu_reset() with WITNESS

post) should help against this panic on boot. A BTW, do you get any other LOR reports _before_ you do a reboot? I have some, but I don't think they are related. A Can you try to change printfs in witness to db_printfs? Perhaps this will allow A to get the details of the LOR in uart_cnputc. Maybe

Re: locks under printf(9) and WITNESS [Was: new panic in cpu_reset() with WITNESS]

be A called in any locking context (even during normal operation). But there are a A number of console-specific locks (scrlock, uart_hwmtx, syscons video lock) A which are acquired under cnputs_mtx, but which are *not* marked as A MTX_NOWITNESS. More, they are specified in the witness order_lists

Re: new panic in cpu_reset() with WITNESS

. A Can you try to change printfs in witness to db_printfs? Perhaps this will allow A to get the details of the LOR in uart_cnputc. Maybe that will reveal some A important additional details. Should I do s/printf/db_printf/ throughout entire subr_witness.c, or only in special places? I think

Re: new panic in cpu_reset() with WITNESS

On Mon, Jan 23, 2012 at 04:01:20PM +0200, Andriy Gapon wrote: A A Can you try to change printfs in witness to db_printfs? Perhaps this will allow A A to get the details of the LOR in uart_cnputc. Maybe that will reveal some A A important additional details. A A Should I do s/printf

Re: new panic in cpu_reset() with WITNESS

On Mon, Jan 23, 2012 at 08:24:10PM +0400, Gleb Smirnoff wrote: T On Mon, Jan 23, 2012 at 04:01:20PM +0200, Andriy Gapon wrote: T A A Can you try to change printfs in witness to db_printfs? Perhaps this will allow T A A to get the details of the LOR in uart_cnputc. Maybe that will reveal some

Re: new panic in cpu_reset() with WITNESS

on 23/01/2012 18:26 Gleb Smirnoff said the following: Sorry. I was testing wrong kernel. The substitute doesn't help. Panic trace is almost the same: db bt Tracing pid 1 tid 11 td 0xfe0001d5e000 kdb_enter() at kdb_enter+0x3b panic() at panic+0x1c7 _mtx_lock_spin_flags() at

Re: new panic in cpu_reset() with WITNESS

On Mon, Jan 23, 2012 at 06:43:23PM +0200, Andriy Gapon wrote: A db bt A Tracing pid 1 tid 11 td 0xfe0001d5e000 A kdb_enter() at kdb_enter+0x3b A panic() at panic+0x1c7 A _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f A cnputs() at cnputs+0x7a A vprintf() at vprintf+0xcb A

Re: new panic in cpu_reset() with WITNESS

on 23/01/2012 18:46 Gleb Smirnoff said the following: On Mon, Jan 23, 2012 at 06:43:23PM +0200, Andriy Gapon wrote: A db bt A Tracing pid 1 tid 11 td 0xfe0001d5e000 A kdb_enter() at kdb_enter+0x3b A panic() at panic+0x1c7 A _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f A

Re: new panic in cpu_reset() with WITNESS

if A T kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. A A I've run through binary search and panic was introduced A by r229854. A A A Which means that it was introduced by one of the earlier commits (probably A mine). Thank you for this investigative work! A Although, to be frank

Re: new panic in cpu_reset() with WITNESS

on 20/01/2012 17:41 Gleb Smirnoff said the following: On Tue, Jan 17, 2012 at 03:02:42PM +0400, Gleb Smirnoff wrote: T New panic has been introduced somewhere between T r229851 and r229932, that happens on shutdown if T kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. I've run

locks under printf(9) and WITNESS [Was: new panic in cpu_reset() with WITNESS]

, syscons video lock) which are acquired under cnputs_mtx, but which are *not* marked as MTX_NOWITNESS. More, they are specified in the witness order_lists as if we certainly know a correct order for them. I think that the msgbuf mutex also deserves mentioning in this context. I think that all

Re: new panic in cpu_reset() with WITNESS

WITNESS and doesn't have WITNESS_SKIPSPIN. I've run through binary search and panic was introduced by r229854. Which means that it was introduced by one of the earlier commits (probably mine). Thank you for this investigative work! Although, to be frank and honest, I still don't see how

Re: locks under printf(9) and WITNESS [Was: new panic in cpu_reset() with WITNESS]

). But there are a number of console-specific locks (scrlock, uart_hwmtx, syscons video lock) which are acquired under cnputs_mtx, but which are *not* marked as MTX_NOWITNESS. More, they are specified in the witness order_lists as if we certainly know a correct order for them. I think that the msgbuf mutex also

Re: new panic in cpu_reset() with WITNESS

On Tue, Jan 17, 2012 at 03:02:42PM +0400, Gleb Smirnoff wrote: T New panic has been introduced somewhere between T r229851 and r229932, that happens on shutdown if T kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. I've run through binary search and panic was introduced by r229854

new panic in cpu_reset() with WITNESS

New panic has been introduced somewhere between r229851 and r229932, that happens on shutdown if kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. Uptime: 1h0m17s Rebooting... panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500 cpuid

Re: new panic in cpu_reset() with WITNESS

2012/1/17 Gleb Smirnoff gleb...@freebsd.org:  New panic has been introduced somewhere between r229851 and r229932, that happens on shutdown if kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. Uptime: 1h0m17s Rebooting... panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx

Re: new panic in cpu_reset() with WITNESS

On Tue, Jan 17, 2012 at 07:34:23AM -0800, m...@freebsd.org wrote: m 2012/1/17 Gleb Smirnoff gleb...@freebsd.org: m  New panic has been introduced somewhere between m r229851 and r229932, that happens on shutdown if m kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. m m Uptime: 1h0m17s m

Re: new panic in cpu_reset() with WITNESS

on 17/01/2012 17:34 m...@freebsd.org said the following: 2012/1/17 Gleb Smirnoff gleb...@freebsd.org: New panic has been introduced somewhere between r229851 and r229932, that happens on shutdown if kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. [**] Uptime: 1h0m17s Rebooting

Re: witness_lock_list_get: witness exhausted

On Tuesday, August 16, 2011 5:59:53 pm Peter Jeremy wrote: I'm getting the above message when running Peter Holm's stress test with INCARNATIONS=150 on a 16-core sparc. Does this mean LOCK_CHILDCOUNT is too low or does it indicate a leak in witness lock_list_entry's somewhere? Most likely

witness_lock_list_get: witness exhausted

I'm getting the above message when running Peter Holm's stress test with INCARNATIONS=150 on a 16-core sparc. Does this mean LOCK_CHILDCOUNT is too low or does it indicate a leak in witness lock_list_entry's somewhere? The comment on LOCK_CHILDCOUNT indicates it is dimensioned to allow 2048

Questions about witness reports on sparc64

. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0: Sun Feb 28 23:19:48 EST 2010 r...@moon.ipv6.fetissov.org:/usr/obj/usr/src/sys/GENERIC sparc64 WARNING: WITNESS option enabled, expect reduced performance. real memory = 4294967296 (4096 MB

Re: Questions about witness reports on sparc64

On Thu, Mar 4, 2010 at 7:19 PM, Nikolai Fetissov nikolai-free...@fetissov.org wrote: Folks, I'm pretty new here, so feel free to use the clue stick :) Playing with current- on Sun Fire V210 I see more or less consistent lock reversal reports like the following: : My questions are - is it

patch to let witness monitor the mtx pool

I've been running with the patch below for a little while now. It helped me find a situation where a thread attemped to grab a pool mutex while it already held one, which I suspect could have caused a deadlock in certain circumstances. In any case, this was illegal because these mutexes are only

fun with WITNESS and pool mutex

When I was attempting to debug a system deadlock problem where the culprit process was sleeping on a pool mutex, I noticed that show witness in ddb doesn't report anything about this particular mutex flavor. I discovered that witness doesn't monitor these mutexes because mtx_pool_setup() calls

Re: fun with WITNESS and pool mutex

On 18 Jun, I wrote: When I was attempting to debug a system deadlock problem where the culprit process was sleeping on a pool mutex, I noticed that show witness in ddb doesn't report anything about this particular mutex flavor. I discovered that witness doesn't monitor these mutexes because

2 tcp/ip witness warnings

hi, Expirementing today with netgraph sockets hit into these two cases: 1: lock order reversal 1st 0xc27658b4 inp (inp) @ /home/phantom/src5/sys/netinet/tcp_input.c:640 2nd 0xc031832c tcp (tcp) @ /home/phantom/src5/sys/netinet/tcp_usrreq.c:621 Stack backtrace:

Re:2 tcp/ip witness warnings

Thanks for reporting these. NFS has this same problem with sowakeup(). You can find an old patch I made for this at http://www.freebsd.org/~hsu/hammer.diff It takes a big hammer to the problem and is less than elegant, so I haven't committed it. I hope to have time to address this

witness needs DDB

subr_witness.c now needs DDB option enabled, otherwise can not be compiled. please fix it. David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message

Re: Witness problem with sound

On Wednesday 05 March 2003 07:42, Pete Carah wrote: I don't know how system-specific this problem is, but: Sony VAIO R505ES Sound is Intel ICH3 + Yamaha. This or something closely related has been happening for weeks. Several times earlier this week and last week sound panic'd, and also

RE: witness: nfs buf queue

queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 ... Witness didn't used to complain about these until my recent commits, so these could be old bugs that we are just now seeing. It does look like all the lock functions in inmem() use LK_NOWAIT which is exempted from

Re: witness: nfs buf queue

nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 ... Witness didn't used to complain about these until my recent commits, so these could be old bugs that we are just now seeing. It does look

Re: witness: nfs buf queue

/vfs_bio.c:2107 Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 ... Witness didn't used to complain about these until my recent commits, so these could be old bugs that we

witness: nfs buf queue

Doing a kernel build over NFS on today's -current gives a pile of following error messages during the final link phase: Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 Acquiring

WITNESS panic in netinet/tcp_input.c

It seems like I'm being handed kernel panics on a platter today. I just got a WITNESS-related one in /usr/src/sys/netinet/tcp_input.c:2190. And actually, in the process of writing this message the first time, it happened again. I've since booted to an older kernel. The kernel this comes from

RE: witness_get: witness exhausted?

On 03-Mar-2003 Andrew Gallatin wrote: I'm developing a character driver which tracks a lot of state on a per-open basis. I've got several mutexes in there which are initialzed at open, and destroyed at close. After a few dozen opens, witness seems to croak with: witness_get

RE: witness_get: witness exhausted?

John Baldwin writes: Unfortunately dead witnesses may still be stuck in the lock order hierarchy and I haven't figured out yet how to properly handle the case of free'ing a witness structure from the tree while preserving the correct lock orders. You can try Ah, I think I see

  1   2   >