On Mon, 24 Sep 2001, John Baldwin wrote:
Hmm, that first one is in sysbeep() (the clk one) Ah!
if (!beeping) {
/* enable counter2 output to speaker */
if (pitch) outb(IO_PPI, inb(IO_PPI) | 3);
beeping = period;
changed its locking semantics.)
Another one, on a -current from yesterday, on -alpha:
lock order reversal
1st 0xfc7fcef0 clk @ ../../../alpha/alpha/clock.c:702
2nd 0xfc7f65d8 callout @ ../../../kern/kern_timeout.c:225
ds10#
Hmm, ok, that one is new
:25PM -0700, John Baldwin wrote:
...
p_flag to p_sflag which changed its locking semantics.)
Another one, on a -current from yesterday, on -alpha:
lock order reversal
1st 0xfc7fcef0 clk @ ../../../alpha/alpha/clock.c:702
2nd 0xfc7f65d8 callout
:25PM -0700, John Baldwin wrote:
...
p_flag to p_sflag which changed its locking semantics.)
Another one, on a -current from yesterday, on -alpha:
lock order reversal
1st 0xfc7fcef0 clk @ ../../../alpha/alpha/clock.c:702
2nd 0xfc7f65d8 callout
On Sun, Sep 23, 2001 at 08:49:29PM +0200, Wilko Bulte wrote:
Is there any reason to assume that specifying CPUTYPE ev56 has any
influence on the lock order reversal?
No that I know of. I used to run a -CURRENT DS20 with CPUTYPE=ev56.
To Unsubscribe: send mail to [EMAIL PROTECTED
.)
Another one, on a -current from yesterday, on -alpha:
lock order reversal
1st 0xfc7fcef0 clk @ ../../../alpha/alpha/clock.c:702
2nd 0xfc7f65d8 callout @ ../../../kern/kern_timeout.c:225
ds10#
Hmm, ok, that one is new and is a problem. Can you turn
order reversal
1st 0xfc7fcef0 clk @ ../../../alpha/alpha/clock.c:702
2nd 0xfc7f65d8 callout @ ../../../kern/kern_timeout.c:225
ds10#
Hmm, ok, that one is new and is a problem. Can you turn on WITNESS_DDB (it's
available as the debug.witness_ddb sysctl and loader variableas
On Tue, Sep 18, 2001 at 03:01:25PM -0700, John Baldwin wrote:
On 18-Sep-01 Garrett Wollman wrote:
lock order reversal
1st 0xd3a5c11c process lock @ ../../../vm/vm_glue.c:469
2nd 0xc0e3fe30 lockmgr interlock @ ../../../kern/kern_lock.c:239
This is on relatively old (~ three months
On 19-Sep-01 Wilko Bulte wrote:
On Tue, Sep 18, 2001 at 03:01:25PM -0700, John Baldwin wrote:
On 18-Sep-01 Garrett Wollman wrote:
lock order reversal
1st 0xd3a5c11c process lock @ ../../../vm/vm_glue.c:469
2nd 0xc0e3fe30 lockmgr interlock @ ../../../kern/kern_lock.c:239
lock order reversal
1st 0xd3a5c11c process lock @ ../../../vm/vm_glue.c:469
2nd 0xc0e3fe30 lockmgr interlock @ ../../../kern/kern_lock.c:239
This is on relatively old (~ three months) sources. The first lock is
from swapout_procs(); I assume the second lock actually refers to the
call
On 18-Sep-01 Garrett Wollman wrote:
lock order reversal
1st 0xd3a5c11c process lock @ ../../../vm/vm_glue.c:469
2nd 0xc0e3fe30 lockmgr interlock @ ../../../kern/kern_lock.c:239
This is on relatively old (~ three months) sources. The first lock is
from swapout_procs(); I assume
My apologies for not looking into this more throughly before
posting to the list, but I thought someone might be interested.
The first time I run tcpdump after a reboot, I get this kernel
message:
xl0: promiscuous mode enabled
lock order reversal
1st 0xc04f3fa0 bpf
On 30-Jul-01 Bill Fenner wrote:
This lock order reversal is not a problem. See
http://www.geocrawler.com/lists/3/FreeBSD/147/50/6267627/
for the meta-issue of witness being too verbose; I'd post URL's for
the followup discussion but there wasn't any.
See my response to this thread that I
matusita lock order reversal
matusita 1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487
matusita 2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239
I've caught tracelog of this reversal, with debug.witness_ddb=1.
Here's console log:
lock order reversal
1st 0xc5e3cfdc process
On 27-Jun-01 Makoto MATSUSHITA wrote:
matusita lock order reversal
matusita 1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487
matusita 2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239
I've caught tracelog of this reversal, with debug.witness_ddb=1.
Here's console log
On 22-Jun-01 Makoto MATSUSHITA wrote:
kuriyama I got message below with WITNESS option. Is this safe to ignore?
I've found another WITNESS message (5-current CVSuped Jun/18/2001):
lock order reversal
1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487
2nd 0xc05a9ec0 lockmgr
jhb Can you turn on WITNESS_DDB in your kenrel config file (or set
jhb the debug.witness_ddb loader tunable/sysctl before you get this
jhb reversal) and get a backtrace from ddb?
Yes; I turned 'debug.witness_ddb' on now. I'll send a ddb 'trace'
output if next time lock-order-reversal is happen
'
output if next time lock-order-reversal is happen.
You will have to reboot for it to fire. We only report the first lock order
found between two locks to avoid flooding the console.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
tacho lock order reversal
tacho 1st 0xc03f0140 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1007
tacho 2nd 0xcaec972c vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1016
matusita Exactly the same kernel message was here.
ddb trace output is as follows.
db trace
Debugger(c02bd5ae
I got same backtrace.
Additional daemons: syslogdlock order reversal
1st 0xc044fc80 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:1007
2nd 0xcb1ef8ac vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:1016
Debugger(witness_lock)
Stopped at Debugger+0x44: pushl %ebx
db trace
Debugger(c038c22e) at
tacho lock order reversal
tacho 1st 0xc03f0140 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1007
tacho 2nd 0xcaec972c vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1016
Exactly the same kernel message was here. Revision ID is:
galtvalion % grep FreeBSD: src/sys/ufs/ffs/ffs_vnops.c
Yet another...
Jun 20 19:47:08 hades /boot/kernel/kernel: lock order reversal
Jun 20 19:47:08 hades /boot/kernel/kernel: 1st 0xc04d91a0 mntvnode @
/usr/src/sys/ufs/ffs/ffs_vfsops.c:1007
Jun 20 19:47:08 hades /boot/kernel/kernel: 2nd 0xc3f86b6c vnode interlock @
/usr/src/sys/ufs/ffs
On 21-Jun-01 Jun Kuriyama wrote:
Another message is reported:
lock order reversal
1st 0xc043ad20 dev_pager create @ ../../vm/device_pager.c:142
2nd 0xc0459840 vm @ ../../vm/vm_kern.c:186
Thanks, I'll try and look at this in a bit. I have a big set of locking
changes to the pagers
kuriyama I got message below with WITNESS option. Is this safe to ignore?
I've found another WITNESS message (5-current CVSuped Jun/18/2001):
lock order reversal
1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487
2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239
***
Revision
On 27-May-01 Takeshi Ken Yamada wrote:
Hi!
With recent -current kernel, I get message below with P3@800Mhz X 2
when booting up.
What is wrong?
lock order reversal
1st 0xc04d4ac0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c 1007
2nd 0xdb3001ac vnode interlock @ ../../ufs/ffs
-
From: Takeshi Ken Yamada [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, May 27, 2001 3:42 AM
Subject: Q) lock order reversal
Hi!
With recent -current kernel, I get message below with P3@800Mhz X 2
when booting up.
What is wrong?
lock order reversal
1st 0xc04d4ac0 mntvnode
Hi!
With recent -current kernel, I get message below with P3@800Mhz X 2
when booting up.
What is wrong?
lock order reversal
1st 0xc04d4ac0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c 1007
2nd 0xdb3001ac vnode interlock @ ../../ufs/ffs/ffs_vfsops.c 1016
To Unsubscribe: send mail
John Baldwin [EMAIL PROTECTED] wrote:
my current kernel cvsupped around Apr 14th tells me about
duplicate locks and lock order reversal. Is this reason to worry?
This is a FAQ. Please keep up with -current if you are tracking it.
That's simply impossible. We would need another 24 hours
hello, world\n
my current kernel cvsupped around Apr 14th tells me about
duplicate locks and lock order reversal. Is this reason to worry?
...
Apr 23 22:23:09 hal9000 /boot/kernel/kernel: da0 at ahc0 bus 0 target 2 lun 0
Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: IBM DCAS-34330 S65A Fixed
On 23-Apr-01 Jens Schweikhardt wrote:
hello, world\n
my current kernel cvsupped around Apr 14th tells me about
duplicate locks and lock order reversal. Is this reason to worry?
...
Apr 23 22:23:09 hal9000 /boot/kernel/kernel: da0 at ahc0 bus 0 target 2 lun 0
Apr 23 22:23:10 hal9000 /boot
Hi,
with -current sources (as of -now) I get during startup:
lock order reversal
1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625
2nd 0xc0306840 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940
3rd 0xcbd20a0c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:949
32
Is that bad?
Bye
On 28-Feb-01 Michael Reifenberger wrote:
Hi,
with -current sources (as of -now) I get during startup:
lock order reversal
1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625
2nd 0xc0306840 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940
3rd 0xcbd20a0c vnode interlock @ ../../ufs
Hi,
Booting with a kernel built from today's source (with devfs also in),
I see this lock order reversal message:
###
Routing daemons:.
Doing IPv6 network setup:add net :::0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
net.inet6.ip6.forwarding: 0 - 0
On Tue, Jan 30, 2001 at 01:56:26PM +0200, John Hay wrote:
Booting with a kernel built from today's source (with devfs also in),
I see this lock order reversal message:
###
Routing daemons:.
Doing IPv6 network setup:add net :::0.0.0.0: gateway ::1
add
: promiscuous mode enabled
now ed0 promisc ON if_flags 0x8943 bdg_flags 0x5
lock order reversal
1st fxp0 last acquired @ ../../pci/if_fxp.c:1130
2nd 0xc0f462f4 fxp1 @ ../../pci/if_fxp.c:974
3rd 0xc0f466f4 fxp0 @ ../../pci/if_fxp.c:823
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail
201 - 235 of 235 matches
Mail list logo
