On Fri, Oct 19, 2001 at 01:02:50PM -0700, John Baldwin wrote:
>
> On 19-Oct-01 Wilko Bulte wrote:
> > Fresh -current kernel on an DS10 Alpha box:
>
> I have untested patches to fix this. Unfortunately they involve fixing the
> locking in teh clock code and I've only done i386 and alpha so far,
On 19-Oct-01 Wilko Bulte wrote:
> Fresh -current kernel on an DS10 Alpha box:
I have untested patches to fix this. Unfortunately they involve fixing the
locking in teh clock code and I've only done i386 and alpha so far, but the
same changes need to be replicated into all the otehr arch's. Alt
Fresh -current kernel on an DS10 Alpha box:
System shutdown time has arrived
Writing entropy file:.
lock order reversal
1st 0xfc7574b0 clk @ ../../../alpha/alpha/clock.c:702
2nd 0xfc7526b0 callout @ ../../../kern/kern_timeout.c:225
witness_lock
Stopped at Debugger+0x34
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;
>
On Mon, 24 Sep 2001, Wilko Bulte wrote:
> I did notice that the default Alpha beep is of a much higher frequency
> than the x86 one. Any relation? (long shot... I suppose)
This bug is well known (including by your mailbox). From mail sent to
your mailbox:
% From [EMAIL PROTECTED] Mon Jun 18 17
19-Sep-01 Wilko Bulte wrote:
> >> > > On Tue, Sep 18, 2001 at 03:01:25PM -0700, John Baldwin wrote:
> >>
> >> ...
> >>
> >> > >> p_flag to p_sflag which changed its locking semantics.)
> >> > >
> >> >
19-Sep-01 Wilko Bulte wrote:
> >> > > On Tue, Sep 18, 2001 at 03:01:25PM -0700, John Baldwin wrote:
> >>
> >> ...
> >>
> >> > >> p_flag to p_sflag which changed its locking semantics.)
> >> > >
> >> >
at 03:01: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
>> > >
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
; 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 0xfc
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. C
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
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
> >
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
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 to
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.
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.
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
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 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, wi
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 rever
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
matusita> Exactly the same kernel message was here.
ddb trace output is as follows.
db> trace
De
ess_ddb' on now. I'll send a ddb 'trace'
> 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
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 i
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
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_lo
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
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
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/ff
lock order reversal
1st 0xc03f0140 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1007
2nd 0xcaec972c vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1016
this is with softupdates enabled, and surprisingly enough it works, but
only on my ThinkPad A21m. a desktop with the same source fails
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
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe:
I got message below with WITNESS option. Is this safe to ignore?
lock order reversal
1st 0xc044c6a0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:478
2nd 0xca35efec vnode interlock @ ../../kern/vfs_subr.c:1926
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL
While doing 'tcpdump gif0' I've got:
- first (no problems here):
lama# tcpdump gif0
tcpdump: syntax error
- second:
rl0: promiscuous mode enabled
lock order reversal
1st 0xc03e10a0 bpf global lock @ /usr/src/sys/net/bpf.c:365
2nd 0xc0c38d6c rl0 @ /
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
Message -
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
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 to
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.
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
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: Fixed Direct
Access
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 0xcbd
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 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 ::ff
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
943 bdg_flags 0x5
fxp1: promiscuous mode enabled
>> now fxp1 promisc ON if_flags 0xffff8943 bdg_flags 0x5
ed0: 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
201 - 244 of 244 matches
Mail list logo
