Re: Seen this lock order reversal?
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;
timeout(sysbeepstop, (void *)NULL, period);
}
This is the problem code. Hmmm. The i386 code seems b0rked. It doesn't have
enough locks! Eck. hmm, the pc98 code doesn't even _use_ the mutex but still
depends on disable/enable intr. Eek. I'll work at this later on today.
Better yet, even the i386 code doesn't even use disable/enable_intr() or
splhigh/splx()() in sysbeepstop(). However, since nothing much accesses
the PPI register, I think there is only an unimportant race between
sysbeep() and sysbeepstop().
There are some more interesting races in clock.c. E.g., rtcin() is locked
by splhigh(), so calling it from the fast interrupt handler rtcintr() would
be invalid even if splhigh() were not a no-op.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seen this lock order reversal?
On 23-Sep-01 Wilko Bulte wrote:
On Thu, Sep 20, 2001 at 07:40:52PM +0200, Wilko Bulte wrote:
On Wed, Sep 19, 2001 at 01:32:28PM -0700, John Baldwin wrote:
On 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.)
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 on WITNESS_DDB
(it's
available as the debug.witness_ddb sysctl and loader variableas well) and
then
get me a traceback in ddb?
I built a GENERIC with WITNESS_DDB. Sofar (of course... :-/ ) no
reproduction of the problem. I'm running buildworlds, any other good
suggestions to help trigger it are welcome
Bah. I cannot reproduce this on my DS10.
Is there any reason to assume that specifying CPUTYPE ev56 has any
influence on the lock order reversal? By default world is built with
ev4, but I have gone to ev56 now. Rumor has it that results in 'less
buggy' code.
No. Hmmm. You didn't have any KTR traces enabled did you?
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;
timeout(sysbeepstop, (void *)NULL, period);
}
This is the problem code. Hmmm. The i386 code seems b0rked. It doesn't have
enough locks! Eck. hmm, the pc98 code doesn't even _use_ the mutex but still
depends on disable/enable intr. Eek. I'll work at this later on today.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seen this lock order reversal?
On Mon, Sep 24, 2001 at 12:33:32PM -0700, John Baldwin wrote:
On 23-Sep-01 Wilko Bulte wrote:
On Thu, Sep 20, 2001 at 07:40:52PM +0200, Wilko Bulte wrote:
On Wed, Sep 19, 2001 at 01:32:28PM -0700, John Baldwin wrote:
On 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.)
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 on WITNESS_DDB
(it's
available as the debug.witness_ddb sysctl and loader variableas well) and
then
get me a traceback in ddb?
I built a GENERIC with WITNESS_DDB. Sofar (of course... :-/ ) no
reproduction of the problem. I'm running buildworlds, any other good
suggestions to help trigger it are welcome
Bah. I cannot reproduce this on my DS10.
Is there any reason to assume that specifying CPUTYPE ev56 has any
influence on the lock order reversal? By default world is built with
ev4, but I have gone to ev56 now. Rumor has it that results in 'less
buggy' code.
No. Hmmm. You didn't have any KTR traces enabled did you?
No.
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;
timeout(sysbeepstop, (void *)NULL, period);
}
This is the problem code. Hmmm. The i386 code seems b0rked. It doesn't have
enough locks! Eck. hmm, the pc98 code doesn't even _use_ the mutex but still
depends on disable/enable intr. Eek. I'll work at this later on today.
I did notice that the default Alpha beep is of a much higher frequency
than the x86 one. Any relation? (long shot... I suppose)
W/
--
| / o / /_ _ email: [EMAIL PROTECTED]
|/|/ / / /( (_) Bulte Arnhem, The Netherlands
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seen this lock order reversal?
On Mon, Sep 24, 2001 at 12:33:32PM -0700, John Baldwin wrote: On 23-Sep-01 Wilko Bulte wrote: On Thu, Sep 20, 2001 at 07:40:52PM +0200, Wilko Bulte wrote: On Wed, Sep 19, 2001 at 01:32:28PM -0700, John Baldwin wrote: On 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.) 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 on WITNESS_DDB (it's available as the debug.witness_ddb sysctl and loader variableas well) and then get me a traceback in ddb? I built a GENERIC with WITNESS_DDB. Sofar (of course... :-/ ) no reproduction of the problem. I'm running buildworlds, any other good suggestions to help trigger it are welcome Bah. I cannot reproduce this on my DS10. Is there any reason to assume that specifying CPUTYPE ev56 has any influence on the lock order reversal? By default world is built with ev4, but I have gone to ev56 now. Rumor has it that results in 'less buggy' code. No. Hmmm. You didn't have any KTR traces enabled did you? Hmm, that first one is in sysbeep() (the clk one) Ah! grrIt is easy to nuke the system once you know what is wrong: type ^G on the console and *bang* you are in DDB ;) -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seen this 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] with unsubscribe freebsd-current in the body of the message
Re: Seen this lock order reversal?
On Thu, Sep 20, 2001 at 07:40:52PM +0200, Wilko Bulte wrote: On Wed, Sep 19, 2001 at 01:32:28PM -0700, John Baldwin wrote: On 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.) 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 on WITNESS_DDB (it's available as the debug.witness_ddb sysctl and loader variableas well) and then get me a traceback in ddb? I built a GENERIC with WITNESS_DDB. Sofar (of course... :-/ ) no reproduction of the problem. I'm running buildworlds, any other good suggestions to help trigger it are welcome Bah. I cannot reproduce this on my DS10. Is there any reason to assume that specifying CPUTYPE ev56 has any influence on the lock order reversal? By default world is built with ev4, but I have gone to ev56 now. Rumor has it that results in 'less buggy' code. Wilko -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seen this lock order reversal?
On Wed, Sep 19, 2001 at 01:32:28PM -0700, John Baldwin wrote: On 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.) 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 on WITNESS_DDB (it's available as the debug.witness_ddb sysctl and loader variableas well) and then get me a traceback in ddb? I built a GENERIC with WITNESS_DDB. Sofar (of course... :-/ ) no reproduction of the problem. I'm running buildworlds, any other good suggestions to help trigger it are welcome W/ -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seen this lock order reversal?
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) sources. The first lock is from swapout_procs(); I assume the second lock actually refers to the call to lockmgr(vm-vm_map.lock, ...) further down in the same function. If this has been fixed already, let me know. (It doesn't seem to have hurt anything.) It is old, but I think it has been fixed recently as a side effect of the KSE commit. (In terms of the pre-KSE kernel, the P_DEADLKTREAT flag moved from 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 @ ../../../kern/kern_timeout.c:225 ds10# -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seen this lock order reversal?
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 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 lockmgr(vm-vm_map.lock, ...) further down in the same function. If this has been fixed already, let me know. (It doesn't seem to have hurt anything.) It is old, but I think it has been fixed recently as a side effect of the KSE commit. (In terms of the pre-KSE kernel, the P_DEADLKTREAT flag moved from 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 @ ../../../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 well) and then get me a traceback in ddb? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Seen this lock order reversal?
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 lockmgr(vm-vm_map.lock, ...) further down in the same function. If this has been fixed already, let me know. (It doesn't seem to have hurt anything.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Seen this lock order reversal?
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 the second lock actually refers to the call to lockmgr(vm-vm_map.lock, ...) further down in the same function. If this has been fixed already, let me know. (It doesn't seem to have hurt anything.) It is old, but I think it has been fixed recently as a side effect of the KSE commit. (In terms of the pre-KSE kernel, the P_DEADLKTREAT flag moved from p_flag to p_sflag which changed its locking semantics.) -GAWollman -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
xl0 lock order reversal
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 global lock @ ../../../net/bpf.c:365 2nd 0xc16beb9c xl0 @ ../../../pci/if_xl.c:2824 I'm running a mostly generic 5.0 kernel built from sources down loaded Jul 30 03:36 with a 1GHz Athlon system; the only difference from the GENERIC config is: device acpica options ACPI_DEBUG profile 1 On a related note, I've noticed that when doing compiles and other high load activities, my systems spends allot of time (nearly 50%) in witness_lock(), which not only has a nested loop in it, but also seems to do spin locking. Are spinlock's really a good idea on a single processor system (which is what I have)? thanx, brad ACPI debug layer 0x0 debug level 0x0 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Jul 28 13:10:18 MDT 2001 [EMAIL PROTECTED]:/scratch/5.0/src/sys/i386/compile/ACPI Calibrating clock(s) ... TSC clock: 1010038034 Hz, i8254 clock: 1193295 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: AMD Athlon(tm) Processor (1009.95-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044b18,AMIE,DSP,3DNow! Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 268369920 (262080K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00607000 - 0x0ffe7fff, 262017024 bytes (63969 pages) avail memory = 255184896 (249204K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fdb40 bios32: Entry = 0xfdb50 (c00fdb50) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb71 pnpbios: Found PnP BIOS data at 0xc00f7710 pnpbios: Entry = f:6604 Rev = 1.0 Other BIOS signatures found: Preloaded elf kernel kernel at 0xc05e1000. Preloaded elf module snd_sb16.ko at 0xc05e109c. Preloaded elf module snd_sbc.ko at 0xc05e113c. Preloaded elf module snd_pcm.ko at 0xc05e11dc. Preloaded elf module bktr.ko at 0xc05e127c. Preloaded elf module bktr_mem.ko at 0xc05e1318. Preloaded elf module joy.ko at 0xc05e13b8. bktr_mem: memory holder loaded null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled WARNING: Driver mistake: destroy_dev on 154/0 Math emulator present apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 acpi0: AMIINT on motherboard acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge on acpi0 pci0: physical bus=0 map[10]: type 3, range 32, base e800, size 26, enabled map[14]: type 3, range 32, base eedfe000, size 12, enabled map[18]: type 4, range 32, base dc00, size 2, port disabled found- vendor=0x1022, dev=0x7006, revid=0x25 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 found- vendor=0x1022, dev=0x7007, revid=0x01 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 found- vendor=0x1022, dev=0x7408, revid=0x01 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base f000, size 4, enabled found- vendor=0x1022, dev=0x7409, revid=0x07 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 found- vendor=0x1022, dev=0x740b, revid=0x03 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 map[10]: type 1, range 32, base efffe000, size 12, enabled found- vendor=0x1022, dev=0x740c, revid=0x06 bus=0, slot=7, func=4 class=0c-03-10, hdrtype=0x00, mfdev=0 intpin=d, irq=7 map[10]: type 3, range 32, base eedff000, size 12, enabled found- vendor=0x109e, dev=0x0350, revid=0x12 bus=0, slot=10, func=0 class=04-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=9 map[10]: type 4, range 32, base de00, size 7, enabled map[14]: type 1, range 32, base ef80, size 7
Re: xl0 lock order reversal
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 just sent out earlier this morning. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
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 lock @ ../../vm/vm_glue.c:487 2nd 0xc05a9f80 lockmgr interlock @ ../../kern/kern_lock.c:239 Debugger(witness_lock) Stopped at Debugger+0x44: pushl %ebx db trace Debugger(c02bd5ae) at Debugger+0x44 witness_lock(c05a9f80,8,c02b8d54,ef) at witness_lock+0x90d lockmgr(c5dbe7d0,12,0,c5420640) at lockmgr+0x97 swapout_procs(1,c02686e0,c5420640,0,c582df94) at swapout_procs+0xc46 vm_daemon(0,c582dfa8) at vm_daemon+0x128 fork_exit(c02686e0,0,c582dfa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db I don't know whether it is reproducible, but it's early morning (6 AM), mkisofs(1) is just running to make an ISO image for me (for backup). -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
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: lock order reversal 1st 0xc5e3cfdc process lock @ ../../vm/vm_glue.c:487 2nd 0xc05a9f80 lockmgr interlock @ ../../kern/kern_lock.c:239 Debugger(witness_lock) Stopped at Debugger+0x44: pushl %ebx db trace Debugger(c02bd5ae) at Debugger+0x44 witness_lock(c05a9f80,8,c02b8d54,ef) at witness_lock+0x90d lockmgr(c5dbe7d0,12,0,c5420640) at lockmgr+0x97 swapout_procs(1,c02686e0,c5420640,0,c582df94) at swapout_procs+0xc46 vm_daemon(0,c582dfa8) at vm_daemon+0x128 fork_exit(c02686e0,0,c582dfa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db I don't know whether it is reproducible, but it's early morning (6 AM), mkisofs(1) is just running to make an ISO image for me (for backup). Ok, this one is due to braindeadedness in lockmgr(), and will just have to stay the way it is until vm map locks switch to being sx locks instead of lockmgr locks. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
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 interlock @ ../../kern/kern_lock.c:239 Can you turn on WITNESS_DDB in your kenrel config file (or set the debug.witness_ddb loader tunable/sysctl before you get this reversal) and get a backtrace from ddb? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
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. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
On 22-Jun-01 Makoto MATSUSHITA wrote: 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. 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 Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
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) at Debugger+0x44 witness_lock(c5ce622c,8,c02cde39,3f8) at witness_lock+0x90d ffs_sync(c089f200,3,c05adc00,c5420200,c089f200,2) at ffs_sync+0x175 sync_fsync(c5831f5c) at sync_fsync+0x18f sched_sync(0,c5831fa8) at sched_sync+0x16c fork_exit(c01e839c,0,c5831fa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
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 Debugger+0x44 witness_lock(cb1ef8ac,8,c03a86d9,3f8) at witness_lock+0x90d ffs_sync(c10cca00,3,c0cd3e00,c9908dc0,c10cca00,2) at ffs_sync+0x175 sync_fsync(ca368f5c) at sync_fsync+0x18f sched_sync(0,ca368fa8) at sched_sync+0x16c fork_exit(c0226ef4,0,ca368fa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
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 ffs_vnops.c: * $FreeBSD: src/sys/ufs/ffs/ffs_vnops.c,v 1.79 2001/05/01 08:34:44 phk Exp $ It's 5-current CVSuped a few days ago. There are two UFS filesystems in this note PC, and one of them employs softupdate. galtvalion % mount -t ufs /dev/ad0s1a on / (ufs, local, noatime) /dev/ad0s1e on /pub (ufs, local, noatime, soft-updates) -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lock order reversal
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/ffs_vfsops.c:1016 The revision of the referenced file is: /usr/src/sys/ufs/ffs/ffs_vfsops.c: $FreeBSD: src/sys/ufs/ffs/ffs_vfsops.c,v 1.155 2001/05/29 21:21:49 phk Exp $ -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
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 that I might ask you to try to see if you can still reproduce this. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
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 ID of these files are: % cd /usr/src/sys; grep FreeBSD: vm/vm_glue.c kern/kern_lock.c vm/vm_glue.c: * $FreeBSD: src/sys/vm/vm_glue.c,v 1.114 2001/05/23 22:35:45 jhb Exp $ kern/kern_lock.c: * $FreeBSD: src/sys/kern/kern_lock.c,v 1.46 2001/04/28 12:11:01 alfred Exp $ -- - Makoto MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Q) lock order reversal
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/ffs_vfsops.c 1016 This is a FAQ. These reversals have been around for a long time, we just haven't had the tools to find them before. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Q) lock order reversal
Hi, I've got exactly the same with a 5.0-20010514-CURRENT snapshot from current.freebsd.org. BTW, it is running on a notebook, and the newcard kernel runs very well, nice job ! -- --- -- [EMAIL PROTECTED] --- - Original 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 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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
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 @ ../../ufs/ffs/ffs_vfsops.c 1007 2nd 0xdb3001ac vnode interlock @ ../../ufs/ffs/ffs_vfsops.c 1016 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: duplicate locks and lock order reversal
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 per day to follow all mailing lists on a daily basis. Some people of us have a day job and a family. ;-) If it's a FAQ, we should IMHO maintain this as a document, sorta like /usr/src/UPDATING is being maintained. Something like /usr/src/ERRATA or that? When branching off into -stable, this file can be left out. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
duplicate locks and lock order reversal
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 Direct Access SCSI-2 device Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: 20.000MB/s transfers (20.000MHz, offset 15) Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Apr 23 22:23:10 hal9000 /boot/kernel/kernel: acquring duplicate lock of same type: allproc Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 1st @ /usr/src/sys/kern/kern_proc.c:584 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 2nd @ /usr/src/sys/kern/kern_proc.c:143 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: lock order reversal Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 1st vnode interlock last acquired @ /usr/src/sys/kern/vfs_vnops.c:625 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 2nd 0xc03c0120 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:967 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 3rd 0xc8f68eac vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:976 Apr 23 22:23:10 hal9000 lpd[315]: lpd startup: logging=0 Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0 at ahc0 bus 0 target 3 lun 0 Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: YAMAHA CRW6416S 1.0b Removable CD-ROM SCSI-2 device Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: 10.000MB/s transfers (10.000MHz, offset 15) Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Apr 23 22:26:44 hal9000 /boot/kernel/kernel: i4b: unit 0, assigned TEI = 126 = 0x7e Apr 23 22:27:08 hal9000 /boot/kernel/kernel: [agree] Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: duplicate locks and lock order reversal
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/kernel/kernel: da0: IBM DCAS-34330 S65A Fixed Direct Access SCSI-2 device Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: 20.000MB/s transfers (20.000MHz, offset 15) Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Apr 23 22:23:10 hal9000 /boot/kernel/kernel: acquring duplicate lock of same type: allproc Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 1st @ /usr/src/sys/kern/kern_proc.c:584 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 2nd @ /usr/src/sys/kern/kern_proc.c:143 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: lock order reversal Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 1st vnode interlock last acquired @ /usr/src/sys/kern/vfs_vnops.c:625 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 2nd 0xc03c0120 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:967 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 3rd 0xc8f68eac vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:976 Apr 23 22:23:10 hal9000 lpd[315]: lpd startup: logging=0 Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0 at ahc0 bus 0 target 3 lun 0 Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: YAMAHA CRW6416S 1.0b Removable CD-ROM SCSI-2 device Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: 10.000MB/s transfers (10.000MHz, offset 15) Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Apr 23 22:26:44 hal9000 /boot/kernel/kernel: i4b: unit 0, assigned TEI = 126 = 0x7e Apr 23 22:27:08 hal9000 /boot/kernel/kernel: [agree] This is a FAQ. Please keep up with -current if you are tracking it. These are known and not a problem right now. The VFS reversals have been around for a long time unfortunately, and the allproc warning is due to witness still needing some work to better handle recursing on sx locks. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lock order reversal under -current
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! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: lock order reversal under -current
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/ffs/ffs_vfsops.c:949 32 Is that bad? Yes and no. It's a bug yes, but it has probably been around since at least 4.4BSD, so you can ignore it for now. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lock order reversal message
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 net.inet6.ip6.accept_rtadv: 0 - 0 net.inet6.ip6.accept_rtadv: 0 - 1 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:644 2nd 0xc02d5280 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940 3rd 0xc85d314c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:949 add net fe80::: gateway ::1 add net ff02::: gateway fe80::2a0:c9ff:fe8d:7c5f%fxp0 ND default interface = fxp0 IPv4 mapped IPv6 address support=YES. Additional daemons: syslogd. ### The machine is a SMP box, if that makes a difference. It does not seem to cause harm because it continue booting and I can log in. The disks are scsi on an adaptec ahc controller, with most partitions on da0 and /usr/obj a link to a partition on da2. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal message
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 net ::0.0.0.0: gateway ::1 net.inet6.ip6.forwarding: 0 - 0 net.inet6.ip6.accept_rtadv: 0 - 0 net.inet6.ip6.accept_rtadv: 0 - 1 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:644 2nd 0xc02d5280 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940 3rd 0xc85d314c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:949 add net fe80::: gateway ::1 add net ff02::: gateway fe80::2a0:c9ff:fe8d:7c5f%fxp0 ND default interface = fxp0 IPv4 mapped IPv6 address support=YES. Additional daemons: syslogd. ### The machine is a SMP box, if that makes a difference. It does not seem to cause harm because it continue booting and I can log in. This shouldn't be a problem. The lock order reversal has been there for a long time and hasn't caused any problems, but since simplelocks were used before, we didn't have any diagnostics to tell us it was there. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lock order reversal messages?
n 0 cd0: TOSHIBA CD-ROM XM-6201TA 1030 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! fxp0: promiscuous mode enabled now fxp0 promisc ON if_flags 0x8943 bdg_flags 0x5 fxp1: promiscuous mode enabled now fxp1 promisc ON if_flags 0x8943 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 @ ../../pci/if_fxp.c:974 3rd 0xc0f466f4 fxp0 @ ../../pci/if_fxp.c:823 -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
