Re: lock order reversal and poudriere

[Mark Linimon]

On Sun, May 03, 2020 at 10:04:04AM -0600, Ian Lepore wrote:
> That LOR site hasn't been updated in years.  Many many years.

If someone wants to help me set up a page on the wiki, let me know.
(I have too much on my plate to do it myself.)

mcl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal and poudriere

[Ian Lepore]

On Sat, 2020-05-02 at 20:36 +0200, Kurt Jaeger wrote:
> Hi!
> 
> > > > I am compiling some packages with poudriere on 13-current kernel. I
> > > > noticed some strange messages printed into the terminal and dmesg:
> > > > 
> > > > lock order reversal:
> > > 
> > > [...]
> > > > Are those the debug messages that aren't visible on non-current kernel
> > > > and should they be reported?
> > > 
> > > Yes, they should be checked and reported.
> > > 
> > > For more details see:
> > > 
> > > http://sources.zabbadoz.net/freebsd/lor.html
> > > 
> > > There's a webpage with a list of all known LORs and a way to
> > > report new LORs.
> > Thanks Kurt. I can't find those two specific LORs in the list on that
> > page. The page also says to report them using a link, which leads to 404
> > :-), or on this mailing list, which I did. I am not sure what else should
> > I do.
> 
> I don't know, either 8-} bz@ is in Cc:, so he'll probably know what
> to do.
> 

That LOR site hasn't been updated in years.  Many many years.

The sad truth appears to be that nobody cares about LORs anymore.  The
same ones have been there for years.  Nobody fixes them, nobody does
anything to suppress reporting them.  We just keep pointing new users
to a dead website because that has always been the only response
available.

> > How do I know if I have got a backtrace?
> > 
> > Are those errors:
> > 
> > pid 43297 (conftest), jid 5, uid 0: exited on signal 11
> > 
> > related or it's a different issue?
> 
> I think that's a different issue.
> 

Segfaults and other problems with a program named "conftest" while
building ports is normal.  Autotools' configure script writes and runs
programs named conftest to detect the presence or absence of features
or bugs.  That doesn't mean every failure of a program named conftest
is normal and expected, but in general it's not a thing to worry about.

-- Ian

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal and poudriere

[Grzegorz Junka]

On 03/05/2020 15:00, Niclas Zeising wrote:

On 2020-05-02 20:36, Kurt Jaeger wrote:


I don't know, either 8-} bz@ is in Cc:, so he'll probably know what
to do.


How do I know if I have got a backtrace?

Are those errors:

pid 43297 (conftest), jid 5, uid 0: exited on signal 11

related or it's a different issue?


I think that's a different issue.



conftest is when configure scripts do things.  Configure works a lot 
by compiling (and sometimes running) small snippets of code to figure 
out what's going on.  Sometimes those snippets core dump. It's all 
normal.




Good to know. It's mostly conftest but sometimes others too:

pid 37407 (cc), jid 9, uid 0: exited on signal 6
pid 95358 (conftest), jid 3, uid 0: exited on signal 11
pid 70242 (conftest), jid 9, uid 0: exited on signal 11
pid 27480 (ngc27183), jid 3, uid 0: exited on signal 11

Regards

--GrzegorzJ

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal and poudriere

[Niclas Zeising]

On 2020-05-02 20:36, Kurt Jaeger wrote:

Hi!


I am compiling some packages with poudriere on 13-current kernel. I
noticed some strange messages printed into the terminal and dmesg:

lock order reversal:

[...]

Are those the debug messages that aren't visible on non-current kernel
and should they be reported?

Yes, they should be checked and reported.

For more details see:

http://sources.zabbadoz.net/freebsd/lor.html

There's a webpage with a list of all known LORs and a way to
report new LORs.



Thanks Kurt. I can't find those two specific LORs in the list on that
page. The page also says to report them using a link, which leads to 404
:-), or on this mailing list, which I did. I am not sure what else should
I do.


I don't know, either 8-} bz@ is in Cc:, so he'll probably know what
to do.


How do I know if I have got a backtrace?

Are those errors:

pid 43297 (conftest), jid 5, uid 0: exited on signal 11

related or it's a different issue?


I think that's a different issue.



conftest is when configure scripts do things.  Configure works a lot by 
compiling (and sometimes running) small snippets of code to figure out 
what's going on.  Sometimes those snippets core dump.  It's all normal.

Regards
--
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal and poudriere

[Grzegorz Junka]

On 02/05/2020 10:08, Grzegorz Junka wrote:
I am compiling some packages with poudriere on 13-current kernel. I 
noticed some strange messages printed into the terminal and dmesg:


lock order reversal:
 1st 0xf8010ca78250 zfs (zfs) @ /usr/src-13/sys/kern/vfs_mount.c:1005
 2nd 0xf8010cd37250 devfs (devfs) @ 
/usr/src-13/sys/kern/vfs_mount.c:1016

stack backtrace:
#0 0x80c2d5f1 at witness_debugger+0x71
#1 0x80b92f18 at lockmgr_lock_flags+0x188
#2 0x80cae744 at _vn_lock+0x54
#3 0x80c90756 at vfs_domount+0xd16
#4 0x80c8efd1 at vfs_donmount+0x871
#5 0x80c8e729 at sys_nmount+0x69
#6 0x81060c40 at amd64_syscall+0x140
#7 0x810370a0 at fast_syscall_common+0x101
pid 17216 (conftest), jid 6, uid 0: exited on signal 11
pid 51159 (conftest), jid 6, uid 0: exited on signal 11
pid 23833 (conftest), jid 3, uid 0: exited on signal 11
pid 4916 (conftest), jid 3, uid 0: exited on signal 11

(... then there is a bunch of similar ones, then ...)

pid 14504 (conftest), jid 3, uid 0: exited on signal 11
pid 27466 (conftest), jid 6, uid 0: exited on signal 11
pid 43297 (conftest), jid 5, uid 0: exited on signal 11
lock order reversal:
 1st 0xfe00bc68c030 filedesc structure (filedesc structure) @ 
/usr/src-13/sys/kern/sys_generic.c:1557
 2nd 0xf803baeddbd8 tmpfs (tmpfs) @ 
/usr/src-13/sys/kern/vfs_vnops.c:1553

stack backtrace:
#0 0x80c2d5f1 at witness_debugger+0x71
#1 0x80b946b5 at lockmgr_xlock+0x55
#2 0x80cae744 at _vn_lock+0x54
#3 0x80cad0da at vn_poll+0x3a
#4 0x80c33e19 at kern_poll+0x419
#5 0x80c340df at sys_ppoll+0x6f
#6 0x81060c40 at amd64_syscall+0x140
#7 0x810370a0 at fast_syscall_common+0x101
pid 37533 (conftest), jid 5, uid 0: exited on signal 11
pid 43474 (conftest), jid 5, uid 0: exited on signal 11




I restarted the compilation and again seeing similar LORs:

lock order reversal:
 1st 0xf80115d32068 zfs (zfs) @ /usr/src-13/sys/kern/vfs_mount.c:1005
 2nd 0xf800243d6808 devfs (devfs) @ 
/usr/src-13/sys/kern/vfs_mount.c:1016

stack backtrace:
#0 0x80c2d5f1 at witness_debugger+0x71
#1 0x80b92f18 at lockmgr_lock_flags+0x188
#2 0x80cae744 at _vn_lock+0x54
#3 0x80c90756 at vfs_domount+0xd16
#4 0x80c8efd1 at vfs_donmount+0x871
#5 0x80c8e729 at sys_nmount+0x69
#6 0x81060c40 at amd64_syscall+0x140
#7 0x810370a0 at fast_syscall_common+0x101

lock order reversal:
 1st 0xfe00a7aa49b0 filedesc structure (filedesc structure) @ 
/usr/src-13/sys/kern/sys_generic.c:1557

 2nd 0xf800aa2cdbd8 zfs (zfs) @ /usr/src-13/sys/kern/vfs_vnops.c:1553
stack backtrace:
#0 0x80c2d5f1 at witness_debugger+0x71
#1 0x80b946b5 at lockmgr_xlock+0x55
#2 0x80cae744 at _vn_lock+0x54
#3 0x80cad0da at vn_poll+0x3a
#4 0x80c33e19 at kern_poll+0x419
#5 0x80c339f0 at sys_poll+0x50
#6 0x81060c40 at amd64_syscall+0x140
#7 0x810370a0 at fast_syscall_common+0x101


The page to report still returns 404 :)

--

GrzegorzJ

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal and poudriere

[Kurt Jaeger]

Hi!

> > > I am compiling some packages with poudriere on 13-current kernel. I
> > > noticed some strange messages printed into the terminal and dmesg:
> > > 
> > > lock order reversal:
> > [...]
> > > Are those the debug messages that aren't visible on non-current kernel
> > > and should they be reported?
> > Yes, they should be checked and reported.
> > 
> > For more details see:
> > 
> > http://sources.zabbadoz.net/freebsd/lor.html
> > 
> > There's a webpage with a list of all known LORs and a way to
> > report new LORs.

> Thanks Kurt. I can't find those two specific LORs in the list on that
> page. The page also says to report them using a link, which leads to 404
> :-), or on this mailing list, which I did. I am not sure what else should
> I do.

I don't know, either 8-} bz@ is in Cc:, so he'll probably know what
to do.

> How do I know if I have got a backtrace?
> 
> Are those errors:
> 
> pid 43297 (conftest), jid 5, uid 0: exited on signal 11
> 
> related or it's a different issue?

I think that's a different issue.

-- 
p...@freebsd.org +49 171 3101372  Now what ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal and poudriere

[Grzegorz Junka]

On 02/05/2020 10:54, Kurt Jaeger wrote:

Hi!


I am compiling some packages with poudriere on 13-current kernel. I
noticed some strange messages printed into the terminal and dmesg:

lock order reversal:

[...]

Are those the debug messages that aren't visible on non-current kernel
and should they be reported?

Yes, they should be checked and reported.

For more details see:

http://sources.zabbadoz.net/freebsd/lor.html

There's a webpage with a list of all known LORs and a way to
report new LORs.



Thanks Kurt. I can't find those two specific LORs in the list on that 
page. The page also says to report them using a link, which leads to 404 
:-), or on this mailing list, which I did. I am not sure what else 
should I do. How do I know if I have got a backtrace?


Are those errors:

pid 43297 (conftest), jid 5, uid 0: exited on signal 11

related or it's a different issue?

GrzegorzJ

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal and poudriere

[Kurt Jaeger]

Hi!

> I am compiling some packages with poudriere on 13-current kernel. I
> noticed some strange messages printed into the terminal and dmesg:
> 
> lock order reversal:
[...]
> Are those the debug messages that aren't visible on non-current kernel
> and should they be reported?

Yes, they should be checked and reported.

For more details see:

http://sources.zabbadoz.net/freebsd/lor.html

There's a webpage with a list of all known LORs and a way to
report new LORs.

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal

[Chris H]

On Mon, 26 Feb 2018 08:42:14 +0200 "Andriy Gapon"  said


On 26/02/2018 07:18, Jon Brawn wrote:
> Wotcha!
> 
> So, I’ve been using FreeBSD 12-CURRENT at various svn releases for a while

> now, and I get quite a few “lock order reversal” dumps. The one I’ve got
> on my screen at the moment is for ufs / bufwait / ufs:
> 
> root@brax:/usr/src/stand # lock order reversal:

>  1st 0xfd0003ec17e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2602
>  2nd 0x410efa20 bufwait (bufwait) @
>  /usr/src/sys/ufs/ffs/ffs_vnops.c:282
>  3rd 0xfd00b83ca7e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2602
> stack backtrace:
> #0 0x003b59d4 at witness_debugger+0x64
> #1 0x0032bd34 at __lockmgr_args+0x6ac
> #2 0x005c6af0 at ffs_lock+0x88
> #3 0x00679eb0 at VOP_LOCK1_APV+0xac
> #4 0x00426fa8 at _vn_lock+0x64
> #5 0x00417550 at vget+0x78
> #6 0x00409fdc at vfs_hash_get+0xec
> #7 0x005c2b94 at ffs_vgetf+0x44
> #8 0x005b96a8 at softdep_sync_buf+0x9f4
> #9 0x005c7834 at ffs_syncvnode+0x26c
> #10 0x005a1b5c at ffs_truncate+0x6b0
> #11 0x005ce3cc at ufs_direnter+0x778
> #12 0x005d64bc at ufs_makeinode+0x4b8
> #13 0x005d2b90 at ufs_create+0x38
> #14 0x00677168 at VOP_CREATE_APV+0xac
> #15 0x0042691c at vn_open_cred+0x264
> #16 0x0041fc84 at kern_openat+0x208
> #17 0x0064b59c at do_el0_sync+0x8bc
> 
> Is there something I should be doing to help debug these?


IMO, no. Please ignore LORs involving "bufwait", "filedesc structure",
"syncer"
unless you experience any real problem (like a lock up).

Or build a kernel without WITNESS (and FULL_BUF_TRACKING?) :-)

--Chris


--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal

[Andriy Gapon]

On 26/02/2018 07:18, Jon Brawn wrote:
> Wotcha!
> 
> So, I’ve been using FreeBSD 12-CURRENT at various svn releases for a while 
> now, and I get quite a few “lock order reversal” dumps. The one I’ve got on 
> my screen at the moment is for ufs / bufwait / ufs:
> 
> root@brax:/usr/src/stand # lock order reversal:
>  1st 0xfd0003ec17e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2602
>  2nd 0x410efa20 bufwait (bufwait) @ 
> /usr/src/sys/ufs/ffs/ffs_vnops.c:282
>  3rd 0xfd00b83ca7e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2602
> stack backtrace:
> #0 0x003b59d4 at witness_debugger+0x64
> #1 0x0032bd34 at __lockmgr_args+0x6ac
> #2 0x005c6af0 at ffs_lock+0x88
> #3 0x00679eb0 at VOP_LOCK1_APV+0xac
> #4 0x00426fa8 at _vn_lock+0x64
> #5 0x00417550 at vget+0x78
> #6 0x00409fdc at vfs_hash_get+0xec
> #7 0x005c2b94 at ffs_vgetf+0x44
> #8 0x005b96a8 at softdep_sync_buf+0x9f4
> #9 0x005c7834 at ffs_syncvnode+0x26c
> #10 0x005a1b5c at ffs_truncate+0x6b0
> #11 0x005ce3cc at ufs_direnter+0x778
> #12 0x005d64bc at ufs_makeinode+0x4b8
> #13 0x005d2b90 at ufs_create+0x38
> #14 0x00677168 at VOP_CREATE_APV+0xac
> #15 0x0042691c at vn_open_cred+0x264
> #16 0x0041fc84 at kern_openat+0x208
> #17 0x0064b59c at do_el0_sync+0x8bc
> 
> Is there something I should be doing to help debug these?

IMO, no. Please ignore LORs involving "bufwait", "filedesc structure", "syncer"
unless you experience any real problem (like a lock up).

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lock order reversal [ newbie ] report [2nd one> more of ]

[Jeffrey Bouquet]

On Wed, 22 Feb 2017 21:06:32 -0600, Benjamin Kaduk  wrote:

> Hi Jeffrey,
> 
> Thank you for your enthusiasm in reporting these.
> Unfortunately, it is very likely that these two are "well-known" and
> believed to be harmless, so you have not discovered something
> terribly exciting.
> 
> An old and no-longer particularly maintained listing of these and
> other LORs is at: http://sources.zabbadoz.net/freebsd/lor.html
> 
> -Ben
> 
> On Wed, Feb 22, 2017 at 06:20:08PM -0800, Jeffrey Bouquet wrote:
> > This one at boot:
> > #0 to #10
> > bufwait
> > /usr/src/sys/kern/vfs_bio.c:3500
> > dirhash
> > /usr/src/sys/ufs/ufs/ufs_dirhash.c:201
> > 
> > r313487   12.0-CURRENT Feb 13 2017 
> > 1200020  FWIW 
> > both the above and the below reports...
> > 
> > 
> > 
> > 
> > On Wed, 22 Feb 2017 15:37:21 -0800 (PST), "Jeffrey Bouquet" 
> >  wrote:
> > 
> > > #0 #16 follow:
> > > jotted down :
> > > 
> > > 1. ufs /usr/src/sys/kern/vfs_syscalls.c:3364
> > > 2. bufwait /usr/src/sys/ufs/ffs/ffs_vnops.c:280
> > > 3. ufs /usr/src/sys/kern/vfs_subr.c:2600
> > > 
> > > [ took roxterm out of the xinitrc, system stable seems more than 
> > > yesterday...  too
> > > early to tell, which is/was a 2nd issue...  put in urxvt and st... based 
> > > on TOP memory... ] 
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> > 
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Found a few more in a debug custom kernel that has  9h 54m uptime as of now,
using nextboot, so are maybe not important... just a toy maybe to examine if
anyone has free time and/or has less than 9h uptime issues to remove a few
lock order reversals, in, say, amd64 (i386 here)  if they are common to both but
would crash amd64 more reliably than the good uptime I have as of this
morning...  r318487  Feb 13 2017 12.0-CURRENT 1200020

Thought to email them only because different 'subsystem' messages occur
during the boot verbose process... like 2016, 2017, 2016, 2015... 

Maybe just newbie stuff. Thanks...  ignore the 'speaker' stuff in it... 

Jeff  kernel log messages:
+subsystem 100
+   vm_mem_init(0)... done.
+   vm_page_init(0)... done.
+subsystem 180
+   sysctl_register_all(0)... done.
+   mallocinit(0)... done.
+   malloc_init(_ACPICA)... done.
+   malloc_init(_KBDMUX)... done.
+   malloc_init(_LED)... done.
+   malloc_init(_MALODEV)... done.
+   malloc_init(_MD)... done.
+   malloc_init(_MDSECT)... done.
+   malloc_init(_MFIBUF)... done.
+   malloc_init(_MPR)... done.
+   malloc_init(_MPRSAS)... done.
+   malloc_init(_MPRUSER)... done.
+   malloc_init(_MPT2)... done.
+   malloc_init(_MPSSAS)... done.
+   malloc_init(_MPSUSER)... done.
+   malloc_init(_ACPITASK)... done.
+   malloc_init(_MPTUSER)... done.
+   malloc_init(_MRSAS)... done.
+   malloc_init(_ACPISEM)... done.
+   malloc_init(_CAMCCBQ)... done.
+   malloc_init(_ACPIDEV)... done.
+   malloc_init(_MVS)... done.
+   malloc_init(_MWLDEV)... done.
+   malloc_init(_NETMAP)... done.
+   malloc_init(_PPBUSDEV)... done.
+   malloc_init(_PSTIOP)... done.
+   malloc_init(_PSTRAID)... done.
+   malloc_init(_PUC)... done.
+   malloc_init(_CAMSIM)... done.
+   malloc_init(_ENTROPY)... done.
+   malloc_init(_CAMXPT)... done.
+   malloc_init(_CAMDEV)... done.
+   malloc_init(_CAMCCB)... done.
+   malloc_init(_CAMPATH)... done.
+   malloc_init(_SIIS)... done.
+   malloc_init(_CAMPERIPH)... done.
+   malloc_init(_SNP)... done.
+   malloc_init(_ACPICMBAT)... done.
+   malloc_init(_AC97)... done.
+   malloc_init(_FEEDER)... done.
+   malloc_init(_MIXER)... done.
+   malloc_init(_MIDI)... done.
+   malloc_init(_TWA)... done.
+   malloc_init(_TWE)... done.
+   malloc_init(_TWS)... done.
+   malloc_init(_ACPIPERF)... done.
+   malloc_init(_ACPIPWR)... done.
+   malloc_init(_CAMSCHED)... done.
+   malloc_init(_CAMQ)... done.
+   malloc_init(_SCSICD)... done.
+   malloc_init(_UART)... done.
+   malloc_init(_AGP)... done.
+   malloc_init(_AHCI)... done.
+   malloc_init(_USB)... done.
+   malloc_init(_USBDEV)... done.
+   malloc_init(_SCSICH)... done.
+   malloc_init(_ATADA)... done.
+   malloc_init(_CAMDEVQ)... done.
+   malloc_init(_SCSIDA)... done.
+   malloc_init(_SCSILOW)... done.
+   malloc_init(_AMR)... done.
+   malloc_init(_ATA)... done.
+   malloc_init(_ATADMA)... done.
+   malloc_init(_ATAPCI)... done.
+   malloc_init(_ATHDEV)... done.
+   

Re: Lock order reversal [ newbie ] report [2nd one]

[Benjamin Kaduk]

Hi Jeffrey,

Thank you for your enthusiasm in reporting these.
Unfortunately, it is very likely that these two are "well-known" and
believed to be harmless, so you have not discovered something
terribly exciting.

An old and no-longer particularly maintained listing of these and
other LORs is at: http://sources.zabbadoz.net/freebsd/lor.html

-Ben

On Wed, Feb 22, 2017 at 06:20:08PM -0800, Jeffrey Bouquet wrote:
> This one at boot:
> #0 to #10
> bufwait
> /usr/src/sys/kern/vfs_bio.c:3500
> dirhash
> /usr/src/sys/ufs/ufs/ufs_dirhash.c:201
> 
> r313487   12.0-CURRENT Feb 13 2017 
> 1200020  FWIW 
> both the above and the below reports...
> 
> 
> 
> 
> On Wed, 22 Feb 2017 15:37:21 -0800 (PST), "Jeffrey Bouquet" 
>  wrote:
> 
> > #0 #16 follow:
> > jotted down :
> > 
> > 1. ufs /usr/src/sys/kern/vfs_syscalls.c:3364
> > 2. bufwait /usr/src/sys/ufs/ffs/ffs_vnops.c:280
> > 3. ufs /usr/src/sys/kern/vfs_subr.c:2600
> > 
> > [ took roxterm out of the xinitrc, system stable seems more than 
> > yesterday...  too
> > early to tell, which is/was a 2nd issue...  put in urxvt and st... based on 
> > TOP memory... ] 
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lock order reversal [ newbie ] report [2nd one]

[Jeffrey Bouquet]

This one at boot:
#0 to #10
bufwait
/usr/src/sys/kern/vfs_bio.c:3500
dirhash
/usr/src/sys/ufs/ufs/ufs_dirhash.c:201

r313487   12.0-CURRENT Feb 13 2017 
1200020  FWIW 
both the above and the below reports...




On Wed, 22 Feb 2017 15:37:21 -0800 (PST), "Jeffrey Bouquet" 
 wrote:

> #0 #16 follow:
> jotted down :
> 
> 1. ufs /usr/src/sys/kern/vfs_syscalls.c:3364
> 2. bufwait /usr/src/sys/ufs/ffs/ffs_vnops.c:280
> 3. ufs /usr/src/sys/kern/vfs_subr.c:2600
> 
> [ took roxterm out of the xinitrc, system stable seems more than yesterday... 
>  too
> early to tell, which is/was a 2nd issue...  put in urxvt and st... based on 
> TOP memory... ] 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lock order reversal errors during boot

[mokhi]

I see this LOR often too.
I thought maybe this is happening because of my Virtual Box setting :) (?!?)

On 5/21/16, Will Brokenbourgh  wrote:
> On 05/16/16 00:44, Bjoern A. Zeeb wrote:
>>> On 15 May 2016, at 07:44 , Kurt Jaeger  wrote:
>>>
>>> Hi!
>>>
 I am seeing 'lock order reversal' errors during boot on 11-CURRENT -
 r298793.  A sample error:

 lock order reversal:
   1st 0xf8011280d068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
   2nd 0xfe01ca539400 bufwait (bufwait) @
 /usr/src/sys/ufs/ffs/ffs_vnops.c:263
   3rd 0xf80112a23b78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
 stack backtrace:
 #0 0x80a94bf0 at witness_debugger+0x70
 #1 0x80a94ae4 at witness_checkorder+0xe54
 #2 0x80a0fdd6 at __lockmgr_args+0x4d6
 #3 0x80ce9626 at ffs_lock+0xa6
 [...snip...]

 I'm not sure if this is even something I should report, but better safe
 than sorry, yes?
>>> Yes, and there's even a page to compare your LOR against other ones:
>>>
>>> http://sources.zabbadoz.net/freebsd/lor.html
>>>
>>> Can you try if you find your LOR there ? If not, can you add it
>>> to that page ?
>> No he can’t and I haven’t in years either.   Searching bugs might however
>> be a good idea;  there is a LOR category or tag somewhere.
>>
>> /bz
> Thank you for the replies.
>
> I'm getting these LORs pretty frequently.  Is this a normal occurrence
> for 11-CURRENT or is it only me having this problem?
>
> Thanks
>
> Will Brokenbourgh
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lock order reversal errors during boot

[Will Brokenbourgh]

On 05/16/16 00:44, Bjoern A. Zeeb wrote:

On 15 May 2016, at 07:44 , Kurt Jaeger  wrote:

Hi!


I am seeing 'lock order reversal' errors during boot on 11-CURRENT -
r298793.  A sample error:

lock order reversal:
  1st 0xf8011280d068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
  2nd 0xfe01ca539400 bufwait (bufwait) @
/usr/src/sys/ufs/ffs/ffs_vnops.c:263
  3rd 0xf80112a23b78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
stack backtrace:
#0 0x80a94bf0 at witness_debugger+0x70
#1 0x80a94ae4 at witness_checkorder+0xe54
#2 0x80a0fdd6 at __lockmgr_args+0x4d6
#3 0x80ce9626 at ffs_lock+0xa6
[...snip...]

I'm not sure if this is even something I should report, but better safe
than sorry, yes?

Yes, and there's even a page to compare your LOR against other ones:

http://sources.zabbadoz.net/freebsd/lor.html

Can you try if you find your LOR there ? If not, can you add it
to that page ?

No he can’t and I haven’t in years either.   Searching bugs might however be a 
good idea;  there is a LOR category or tag somewhere.

/bz

Thank you for the replies.

I'm getting these LORs pretty frequently.  Is this a normal occurrence 
for 11-CURRENT or is it only me having this problem?


Thanks

Will Brokenbourgh

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lock order reversal errors during boot

[Bjoern A. Zeeb]

> On 15 May 2016, at 07:44 , Kurt Jaeger  wrote:
> 
> Hi!
> 
>> I am seeing 'lock order reversal' errors during boot on 11-CURRENT - 
>> r298793.  A sample error:
>> 
>> lock order reversal:
>>  1st 0xf8011280d068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
>>  2nd 0xfe01ca539400 bufwait (bufwait) @ 
>> /usr/src/sys/ufs/ffs/ffs_vnops.c:263
>>  3rd 0xf80112a23b78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
>> stack backtrace:
>> #0 0x80a94bf0 at witness_debugger+0x70
>> #1 0x80a94ae4 at witness_checkorder+0xe54
>> #2 0x80a0fdd6 at __lockmgr_args+0x4d6
>> #3 0x80ce9626 at ffs_lock+0xa6
>> [...snip...]
>> 
>> I'm not sure if this is even something I should report, but better safe 
>> than sorry, yes?
> 
> Yes, and there's even a page to compare your LOR against other ones:
> 
> http://sources.zabbadoz.net/freebsd/lor.html
> 
> Can you try if you find your LOR there ? If not, can you add it
> to that page ?

No he can’t and I haven’t in years either.   Searching bugs might however be a 
good idea;  there is a LOR category or tag somewhere.

/bz


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lock order reversal errors during boot

[Kurt Jaeger]

Hi!

> I am seeing 'lock order reversal' errors during boot on 11-CURRENT - 
> r298793.  A sample error:
> 
> lock order reversal:
>   1st 0xf8011280d068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
>   2nd 0xfe01ca539400 bufwait (bufwait) @ 
> /usr/src/sys/ufs/ffs/ffs_vnops.c:263
>   3rd 0xf80112a23b78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
> stack backtrace:
> #0 0x80a94bf0 at witness_debugger+0x70
> #1 0x80a94ae4 at witness_checkorder+0xe54
> #2 0x80a0fdd6 at __lockmgr_args+0x4d6
> #3 0x80ce9626 at ffs_lock+0xa6
> [...snip...]
> 
> I'm not sure if this is even something I should report, but better safe 
> than sorry, yes?

Yes, and there's even a page to compare your LOR against other ones:

http://sources.zabbadoz.net/freebsd/lor.html

Can you try if you find your LOR there ? If not, can you add it
to that page ?

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lock order reversal in CURRENT

[Benjamin Kaduk]

On Wed, 24 Feb 2016, Eax Melanhovich wrote:

> Hello.
>
> Yesterday I built a kernel and world using master branch (6a8922d3) of
> FreeBSD GitHub repository (a mirror of SVN as I understand?). Today I
> got a "lock order reversal" report:
>
> http://i.imgur.com/jDZ4A3O.png
>
> According to this FAQ it could be a sign of a deadlock:
>
> https://www.freebsd.org/doc/faq/troubleshoot.html#idp63366608
>
> Do I have to report this issue anywhere except freebsd-current@ ?

That particular one, though not in the table at
http://sources.zabbadoz.net/freebsd/lor.html, seems similar enough to a
ufs/devfs entry that shows up very often and is harmless, to make me think
that just the mail you have sent is quite sufficient.

Thanks,

Ben Kaduk
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal in sys/kern/vfs_mount.c

[Ruslan Mahmatkhanov]

John Baldwin wrote on 08.06.2012 18:45:

On Friday, June 08, 2012 4:21:34 am Ruslan Mahmatkhanov wrote:

Ruslan Mahmatkhanov wrote on 08.06.2012 12:10:

Good day,

After updating to yesterdays -current, I got this on boot:

lock order reversal:
1st 0xfe0007b04c38 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1254
2nd 0xfe0007ed9478 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
_witness_debugger() at _witness_debugger+0x2c
witness_checkorder() at witness_checkorder+0x853
__lockmgr_args() at __lockmgr_args+0x113a
vop_stdlock() at vop_stdlock+0x39
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf
_vn_lock() at _vn_lock+0x47
vget() at vget+0x7b
devfs_allocv() at devfs_allocv+0x13f
devfs_root() at devfs_root+0x4d
dounmount() at dounmount+0x45c
vfs_unmountall() at vfs_unmountall+0x4c
kern_reboot() at kern_reboot+0x84b
sys_reboot() at sys_reboot+0x68
amd64_syscall() at amd64_syscall+0x2e0
Xfast_syscall() at Xfast_syscall+0xf7
--- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ebbc, rsp =
0x7fffd6c8, rbp = 0x65 ---

Reverting to old kernel (that was built about a week ago) helped to
avoid this. Any thoughts?


And this one comes up with the recent update too:

driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
cpu0: ACPI CPU on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
cpu1: ACPI CPU on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
cpu2: ACPI CPU on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
cpu3: ACPI CPU on acpi0

What the additional info should I supply to understand what's wrong?
Here is my full dmesg; http://people.freebsd.org/~rm/dmesg.txt


Is this a verbose boot?  Also, can you try this to get more details in
the log message:



Sorry for delay. This particular panic had triggered by intel video 
driver (x11-drivers/xf86-video-intel v 2.19.0). After I rebuild it with 
new kernel, all is going fine. The panic appeared after GDM login, and I 
was able to catch some driver-related errors in xorg log. Thanks John.


--
Regards,
Ruslan

Tinderboxing kills... the drives.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: lock order reversal in sys/kern/vfs_mount.c

[Ruslan Mahmatkhanov]

Ruslan Mahmatkhanov wrote on 08.06.2012 12:10:

Good day,

After updating to yesterdays -current, I got this on boot:

lock order reversal:
1st 0xfe0007b04c38 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1254
2nd 0xfe0007ed9478 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
_witness_debugger() at _witness_debugger+0x2c
witness_checkorder() at witness_checkorder+0x853
__lockmgr_args() at __lockmgr_args+0x113a
vop_stdlock() at vop_stdlock+0x39
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf
_vn_lock() at _vn_lock+0x47
vget() at vget+0x7b
devfs_allocv() at devfs_allocv+0x13f
devfs_root() at devfs_root+0x4d
dounmount() at dounmount+0x45c
vfs_unmountall() at vfs_unmountall+0x4c
kern_reboot() at kern_reboot+0x84b
sys_reboot() at sys_reboot+0x68
amd64_syscall() at amd64_syscall+0x2e0
Xfast_syscall() at Xfast_syscall+0xf7
--- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ebbc, rsp =
0x7fffd6c8, rbp = 0x65 ---

Reverting to old kernel (that was built about a week ago) helped to
avoid this. Any thoughts?


And this one comes up with the recent update too:

driver bug: Unable to set devclass (class: acpi_sysresource devname: 
(unknown))

driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
cpu0: ACPI CPU on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname: 
(unknown))

cpu1: ACPI CPU on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname: 
(unknown))

cpu2: ACPI CPU on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname: 
(unknown))

cpu3: ACPI CPU on acpi0

What the additional info should I supply to understand what's wrong?
Here is my full dmesg; http://people.freebsd.org/~rm/dmesg.txt

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: lock order reversal in sys/kern/vfs_mount.c

[John Baldwin]

On Friday, June 08, 2012 4:21:34 am Ruslan Mahmatkhanov wrote:
 Ruslan Mahmatkhanov wrote on 08.06.2012 12:10:
  Good day,
 
  After updating to yesterdays -current, I got this on boot:
 
  lock order reversal:
  1st 0xfe0007b04c38 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1254
  2nd 0xfe0007ed9478 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158
  KDB: stack backtrace:
  db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
  kdb_backtrace() at kdb_backtrace+0x37
  _witness_debugger() at _witness_debugger+0x2c
  witness_checkorder() at witness_checkorder+0x853
  __lockmgr_args() at __lockmgr_args+0x113a
  vop_stdlock() at vop_stdlock+0x39
  VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf
  _vn_lock() at _vn_lock+0x47
  vget() at vget+0x7b
  devfs_allocv() at devfs_allocv+0x13f
  devfs_root() at devfs_root+0x4d
  dounmount() at dounmount+0x45c
  vfs_unmountall() at vfs_unmountall+0x4c
  kern_reboot() at kern_reboot+0x84b
  sys_reboot() at sys_reboot+0x68
  amd64_syscall() at amd64_syscall+0x2e0
  Xfast_syscall() at Xfast_syscall+0xf7
  --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ebbc, rsp =
  0x7fffd6c8, rbp = 0x65 ---
 
  Reverting to old kernel (that was built about a week ago) helped to
  avoid this. Any thoughts?
 
 And this one comes up with the recent update too:
 
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
 cpu0: ACPI CPU on acpi0
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 cpu1: ACPI CPU on acpi0
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 cpu2: ACPI CPU on acpi0
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 cpu3: ACPI CPU on acpi0
 
 What the additional info should I supply to understand what's wrong?
 Here is my full dmesg; http://people.freebsd.org/~rm/dmesg.txt

Is this a verbose boot?  Also, can you try this to get more details in
the log message:

Index: subr_bus.c
===
--- subr_bus.c  (revision 236680)
+++ subr_bus.c  (working copy)
@@ -1988,7 +1990,7 @@ device_probe_child(device_t dev, device_t child)
devclass_t dc;
driverlink_t best = NULL;
driverlink_t dl;
-   int result, pri = 0;
+   int error, result, pri = 0;
int hasclass = (child-devclass != NULL);
 
GIANT_REQUIRED;
@@ -2019,17 +2021,18 @@ device_probe_child(device_t dev, device_t child)
else if (result != 0)
continue;
if (!hasclass) {
-   if (device_set_devclass(child,
-   dl-driver-name) != 0) {
+   error = device_set_devclass(child,
+   dl-driver-name);
+   if (error != 0) {
char const * devname =
device_get_name(child);
if (devname == NULL)
devname = (unknown);
printf(driver bug: Unable to set 
devclass (class: %s 
-   devname: %s)\n,
+   devname: %s): %d\n,
dl-driver-name,
-   devname);
+   devname, error);
(void)device_set_driver(child, NULL);
continue;
}


-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: lock order reversal in sys/kern/vfs_mount.c

[Stefan Esser]

Am 08.06.2012 10:10, schrieb Ruslan Mahmatkhanov:
 Good day,
 
 After updating to yesterdays -current, I got this on boot:
 
 lock order reversal:
  1st 0xfe0007b04c38 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1254
  2nd 0xfe0007ed9478 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 kdb_backtrace() at kdb_backtrace+0x37
 _witness_debugger() at _witness_debugger+0x2c
 witness_checkorder() at witness_checkorder+0x853
 __lockmgr_args() at __lockmgr_args+0x113a
 vop_stdlock() at vop_stdlock+0x39
 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf
 _vn_lock() at _vn_lock+0x47
 vget() at vget+0x7b
 devfs_allocv() at devfs_allocv+0x13f
 devfs_root() at devfs_root+0x4d
 dounmount() at dounmount+0x45c
 vfs_unmountall() at vfs_unmountall+0x4c
 kern_reboot() at kern_reboot+0x84b
 sys_reboot() at sys_reboot+0x68
 amd64_syscall() at amd64_syscall+0x2e0
 Xfast_syscall() at Xfast_syscall+0xf7
 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ebbc, rsp =
 0x7fffd6c8, rbp = 0x65 ---
 
 Reverting to old kernel (that was built about a week ago) helped to
 avoid this. Any thoughts?

I have been getting those for a long time in -CURRENT, but with ZFS
instead of UFS, and during system shutdown, not startup. And this LOR
seems to cause the system to lock-up on shutdown with relatively high
probability (I often have to remove power to halt the system, Since
the ACPI power-off is not issued because of the LOR).

My system is only rebooted from the local console and thus the LOR
is not that much of a problem, and I did not bother to further look
into the cause. But in case of remote system that is rebooted via SSH,
the LOR could be quite a nuisance ...

Regards, STefan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: lock order reversal

[K. Macy]

When WITNESS support was added to lockmgr locks a number of
longstanding LORs were exposed in the process. I can't comment on
whether or not they'll be fixed or the warnings will some day be
silenced.

On Tue, Sep 6, 2011 at 2:58 PM, Vadim Denisov m...@vadimdenisov.ru wrote:
 I install current on last week
 I have some messages in dmesg -a:
 lock order reversal:
  1st 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:425
  2nd 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658
  3rd 0xc7d89168 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:546
 KDB: stack backtrace:
 db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,a363435,...) at
 db_trace_self_wrapper+0x26
 kdb_backtrace(c088dd7b,c0c38d9c,c7535098,c75385d0,ef9e1404,...) at
 kdb_backtrace+0x2a
 _witness_debugger(c0c38d9c,c7d89168,c0c2816c,c75385d0,c0c56442,...) at
 _witness_debugger+0x25
 witness_checkorder(c7d89168,9,c0c56442,222,0,...) at
 witness_checkorder+0x839
 __lockmgr_args(c7d89168,80100,c7d89188,0,0,...) at __lockmgr_args+0x824
 ffs_lock(ef9e152c,c0ecca08,c7dc1c30,80100,c7d89110,...) at ffs_lock+0x8a
 VOP_LOCK1_APV(c0d3c680,ef9e152c,ef9e154c,c0d4caa0,c7d89110,...) at
 VOP_LOCK1_APV+0xb5
 _vn_lock(c7d89110,80100,c0c56442,222,c755ce80,...) at _vn_lock+0x5e
 ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x14fc
 ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13
 vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at
 vfs_donmount+0x1219
 nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84
 syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at
 syscallenter+0x263
 syscall(ef9e1d28) at syscall+0x34
 Xint0x80_syscall() at Xint0x80_syscall+0x21
 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp =
 0xbfbfea9c, ebp = 0xbfbfede8 ---
 lock order reversal:
  1st 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658
  2nd 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:818
 KDB: stack backtrace:
 db_trace_self_wrapper(c0c353ac,662f7366,735f7366,7370616e,2e746f68,...) at
 db_trace_self_wrapper+0x26
 kdb_backtrace(c088dd7b,c0c38d83,c7535098,c7538978,ef9e1404,...) at
 kdb_backtrace+0x2a
 _witness_debugger(c0c38d83,c7563c9c,c0c564a4,c7538978,c0c56442,...) at
 _witness_debugger+0x25
 witness_checkorder(c7563c9c,9,c0c56442,332,c81ba298,...) at
 witness_checkorder+0x839
 __lockmgr_args(c7563c9c,80400,c81ba298,0,0,...) at __lockmgr_args+0x824
 ffs_lock(ef9e152c,e0ef5790,10,80400,c81ba220,...) at ffs_lock+0x8a
 VOP_LOCK1_APV(c0d3c680,ef9e152c,e0ef57ec,c0d4caa0,c81ba220,...) at
 VOP_LOCK1_APV+0xb5
 _vn_lock(c81ba220,80400,c0c56442,332,0,...) at _vn_lock+0x5e
 ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x298e
 ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13
 vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at
 vfs_donmount+0x1219
 nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84
 syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at
 syscallenter+0x263
 syscall(ef9e1d28) at syscall+0x34
 Xint0x80_syscall() at Xint0x80_syscall+0x21
 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp =
 0xbfbfea9c, ebp = 0xbfbfede8 ---
 lock order reversal:
  1st 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:307
  2nd 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1620
 KDB: stack backtrace:
 db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,30323631,...) at
 db_trace_self_wrapper+0x26
 kdb_backtrace(c088dd7b,c0c38d83,c7538978,c75385d0,ef9e16c8,...) at
 kdb_backtrace+0x2a
 _witness_debugger(c0c38d83,c81ba278,c0c2816c,c75385d0,c0c56442,...) at
 _witness_debugger+0x25
 witness_checkorder(c81ba278,9,c0c56442,654,0,...) at
 witness_checkorder+0x839
 __lockmgr_args(c81ba278,8,0,0,0,...) at __lockmgr_args+0x824
 ffs_snapremove(c81ba220,8,c0c3e10a,5e8,c7535098,...) at ffs_snapremove+0x11f
 ffs_truncate(c81ba220,0,0,c00,0,...) at ffs_truncate+0x577
 ufs_inactive(ef9e1a9c,c81ba298,c81ba220,c81ba298,ef9e1ab4,...) at
 ufs_inactive+0x1f8
 VOP_INACTIVE_APV(c0d3c680,ef9e1a9c,c0c40a67,94e,c0d4ca60,...) at
 VOP_INACTIVE_APV+0xa5
 vinactive(c0d3c680,ef9e1ad0,c0c40a67,8a5,0,...) at vinactive+0x8e
 vputx(ef9e1b38,c08febda,c81ba220,ef9e1b14,c0c41f00,...) at vputx+0x2f8
 vput(c81ba220,ef9e1b14,c0c41f00,133,0,...) at vput+0x10
 vn_close(c81ba220,1,c755ce00,c7dc1b80,0,...) at vn_close+0x19a
 vn_closefile(c7c300a8,c7dc1b80,c0c2706c,0,c7c300a8,...) at vn_closefile+0xe4
 _fdrop(c7c300a8,c7dc1b80,0,ef9e1bfc,0,c0ecc9d8,c7dc1c30,c0d28da0,c0ecc9d8,c0c2af54,c7dc1b80,c7b05d2c,4ce,ef9e1c0c,c085d087,c7b05d2c,8,c0c2af54,c7c300a8)
 at _fdrop+0x43
 closef(c7c300a8,c7dc1b80,4ce,ef9e1c30,c7b05d2c,...) at closef+0x2b0
 kern_close(c7dc1b80,4,ef9e1c7c,c0897ff3,c7dc1b80,...) at kern_close+0x139
 close(c7dc1b80,ef9e1cec,ef9e1d28,c0c3767a,0,...) at close+0x1a
 syscallenter(c7dc1b80,ef9e1ce4,ef9e1ce4,0,c0d819f0,...) at
 syscallenter+0x263
 

Re: lock order reversal

[Вадим Денисов]

Thanks, K. Macy

Ok
Sorry to disturb

K. Macy wrote:

When WITNESS support was added to lockmgr locks a number of
longstanding LORs were exposed in the process. I can't comment on
whether or not they'll be fixed or the warnings will some day be
silenced.

On Tue, Sep 6, 2011 at 2:58 PM, Vadim Denisov m...@vadimdenisov.ru wrote:
  

I install current on last week
I have some messages in dmesg -a:
lock order reversal:
 1st 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:425
 2nd 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658
 3rd 0xc7d89168 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:546
KDB: stack backtrace:
db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,a363435,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c088dd7b,c0c38d9c,c7535098,c75385d0,ef9e1404,...) at
kdb_backtrace+0x2a
_witness_debugger(c0c38d9c,c7d89168,c0c2816c,c75385d0,c0c56442,...) at
_witness_debugger+0x25
witness_checkorder(c7d89168,9,c0c56442,222,0,...) at
witness_checkorder+0x839
__lockmgr_args(c7d89168,80100,c7d89188,0,0,...) at __lockmgr_args+0x824
ffs_lock(ef9e152c,c0ecca08,c7dc1c30,80100,c7d89110,...) at ffs_lock+0x8a
VOP_LOCK1_APV(c0d3c680,ef9e152c,ef9e154c,c0d4caa0,c7d89110,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c7d89110,80100,c0c56442,222,c755ce80,...) at _vn_lock+0x5e
ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x14fc
ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13
vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at
vfs_donmount+0x1219
nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84
syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at
syscallenter+0x263
syscall(ef9e1d28) at syscall+0x34
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp =
0xbfbfea9c, ebp = 0xbfbfede8 ---
lock order reversal:
 1st 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658
 2nd 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:818
KDB: stack backtrace:
db_trace_self_wrapper(c0c353ac,662f7366,735f7366,7370616e,2e746f68,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c088dd7b,c0c38d83,c7535098,c7538978,ef9e1404,...) at
kdb_backtrace+0x2a
_witness_debugger(c0c38d83,c7563c9c,c0c564a4,c7538978,c0c56442,...) at
_witness_debugger+0x25
witness_checkorder(c7563c9c,9,c0c56442,332,c81ba298,...) at
witness_checkorder+0x839
__lockmgr_args(c7563c9c,80400,c81ba298,0,0,...) at __lockmgr_args+0x824
ffs_lock(ef9e152c,e0ef5790,10,80400,c81ba220,...) at ffs_lock+0x8a
VOP_LOCK1_APV(c0d3c680,ef9e152c,e0ef57ec,c0d4caa0,c81ba220,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c81ba220,80400,c0c56442,332,0,...) at _vn_lock+0x5e
ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x298e
ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13
vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at
vfs_donmount+0x1219
nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84
syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at
syscallenter+0x263
syscall(ef9e1d28) at syscall+0x34
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp =
0xbfbfea9c, ebp = 0xbfbfede8 ---
lock order reversal:
 1st 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:307
 2nd 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1620
KDB: stack backtrace:
db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,30323631,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c088dd7b,c0c38d83,c7538978,c75385d0,ef9e16c8,...) at
kdb_backtrace+0x2a
_witness_debugger(c0c38d83,c81ba278,c0c2816c,c75385d0,c0c56442,...) at
_witness_debugger+0x25
witness_checkorder(c81ba278,9,c0c56442,654,0,...) at
witness_checkorder+0x839
__lockmgr_args(c81ba278,8,0,0,0,...) at __lockmgr_args+0x824
ffs_snapremove(c81ba220,8,c0c3e10a,5e8,c7535098,...) at ffs_snapremove+0x11f
ffs_truncate(c81ba220,0,0,c00,0,...) at ffs_truncate+0x577
ufs_inactive(ef9e1a9c,c81ba298,c81ba220,c81ba298,ef9e1ab4,...) at
ufs_inactive+0x1f8
VOP_INACTIVE_APV(c0d3c680,ef9e1a9c,c0c40a67,94e,c0d4ca60,...) at
VOP_INACTIVE_APV+0xa5
vinactive(c0d3c680,ef9e1ad0,c0c40a67,8a5,0,...) at vinactive+0x8e
vputx(ef9e1b38,c08febda,c81ba220,ef9e1b14,c0c41f00,...) at vputx+0x2f8
vput(c81ba220,ef9e1b14,c0c41f00,133,0,...) at vput+0x10
vn_close(c81ba220,1,c755ce00,c7dc1b80,0,...) at vn_close+0x19a
vn_closefile(c7c300a8,c7dc1b80,c0c2706c,0,c7c300a8,...) at vn_closefile+0xe4
_fdrop(c7c300a8,c7dc1b80,0,ef9e1bfc,0,c0ecc9d8,c7dc1c30,c0d28da0,c0ecc9d8,c0c2af54,c7dc1b80,c7b05d2c,4ce,ef9e1c0c,c085d087,c7b05d2c,8,c0c2af54,c7c300a8)
at _fdrop+0x43
closef(c7c300a8,c7dc1b80,4ce,ef9e1c30,c7b05d2c,...) at closef+0x2b0
kern_close(c7dc1b80,4,ef9e1c7c,c0897ff3,c7dc1b80,...) at kern_close+0x139
close(c7dc1b80,ef9e1cec,ef9e1d28,c0c3767a,0,...) at close+0x1a
syscallenter(c7dc1b80,ef9e1ce4,ef9e1ce4,0,c0d819f0,...) at
syscallenter+0x263
syscall(ef9e1d28) at syscall+0x34

Re: Lock order reversal .

[Garrett Cooper]

On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com 
wrote:

 A Dmesg.TXT is attached having a lock order reversal .

The mount LOR is well known. The duplicate lock held WITNESS warning with 
em(4) might be of interest though.
Thanks,
-Garrett___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lock order reversal .

[Erik Cederstrand]

Den 07/12/2010 kl. 10.20 skrev Garrett Cooper:

 On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com 
 wrote:
 
 A Dmesg.TXT is attached having a lock order reversal .
 
The mount LOR is well known.

I see that this is the standard response to lot's of LOR reports. It seems to 
be one of the most-reported errors on CURRENT (and it's certainly a loud one), 
but I think a lot of people waste time researching the error and browsing 
Bjoerns LOR page, only to get the above response (not picking on you, Garrett).

Do we have the possibility of silencing well-known and presumably harmless 
LOR's if there isn't sufficient motivation to fix the source?

Erik

Re: Lock order reversal .

[Attilio Rao]

2010/12/7 Erik Cederstrand e...@cederstrand.dk:

 Den 07/12/2010 kl. 10.20 skrev Garrett Cooper:

 On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com 
 wrote:

 A Dmesg.TXT is attached having a lock order reversal .

    The mount LOR is well known.

 I see that this is the standard response to lot's of LOR reports. It seems to 
 be one of the most-reported errors on CURRENT (and it's certainly a loud 
 one), but I think a lot of people waste time researching the error and 
 browsing Bjoerns LOR page, only to get the above response (not picking on 
 you, Garrett).

 Do we have the possibility of silencing well-known and presumably harmless 
 LOR's if there isn't sufficient motivation to fix the source?

Witness has an 'internal blessing list' we never wanted to use in
order to keep them popping up as reminder.
Actually, the fact the LOR is 'known' doesn't mean it is 'analyzed'.
The very few 'Analyzed but harmless' cases in the past have been
handled via _NOWITNESS flags I guess.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lock order reversal .

[Julian Elischer]

On 12/7/10 3:41 AM, Attilio Rao wrote:

2010/12/7 Erik Cederstrande...@cederstrand.dk:

Den 07/12/2010 kl. 10.20 skrev Garrett Cooper:


On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturkm.e.sanlit...@gmail.com  
wrote:


A Dmesg.TXT is attached having a lock order reversal .

The mount LOR is well known.

I see that this is the standard response to lot's of LOR reports. It seems to 
be one of the most-reported errors on CURRENT (and it's certainly a loud one), 
but I think a lot of people waste time researching the error and browsing 
Bjoerns LOR page, only to get the above response (not picking on you, Garrett).

Do we have the possibility of silencing well-known and presumably harmless 
LOR's if there isn't sufficient motivation to fix the source?

Witness has an 'internal blessing list' we never wanted to use in
order to keep them popping up as reminder.
Actually, the fact the LOR is 'known' doesn't mean it is 'analyzed'.
The very few 'Analyzed but harmless' cases in the past have been
handled via _NOWITNESS flags I guess.


the problem is that the witness output tells you the second case (the 
reversed case)
but it doesn't have any clues about the first case (the one that wsa 
the other way around).


An extended witness might use a lot of memory but associate with each 
lock a 'last place called when a lock was already held'
that might give a clue as to where the other instance was. I'm not 
volunteering to write it,
but it might be very worth while.. I'd certainly like to hear other 
ideas as well.




Attilio




___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lock order reversal .

[Matthew Fleming]

On Tue, Dec 7, 2010 at 9:18 AM, Julian Elischer jul...@freebsd.org wrote:
 On 12/7/10 3:41 AM, Attilio Rao wrote:

 2010/12/7 Erik Cederstrande...@cederstrand.dk:

 Den 07/12/2010 kl. 10.20 skrev Garrett Cooper:

 On Dec 7, 2010, at 12:26 AM, Mehmet Erol
 Sanliturkm.e.sanlit...@gmail.com  wrote:

 A Dmesg.TXT is attached having a lock order reversal .

    The mount LOR is well known.

 I see that this is the standard response to lot's of LOR reports. It
 seems to be one of the most-reported errors on CURRENT (and it's certainly a
 loud one), but I think a lot of people waste time researching the error and
 browsing Bjoerns LOR page, only to get the above response (not picking on
 you, Garrett).

 Do we have the possibility of silencing well-known and presumably
 harmless LOR's if there isn't sufficient motivation to fix the source?

 Witness has an 'internal blessing list' we never wanted to use in
 order to keep them popping up as reminder.
 Actually, the fact the LOR is 'known' doesn't mean it is 'analyzed'.
 The very few 'Analyzed but harmless' cases in the past have been
 handled via _NOWITNESS flags I guess.

 the problem is that the witness output tells you the second case (the
 reversed case)
 but it doesn't have any clues about the first case (the one that wsa the
 other way around).

 An extended witness might use a lot of memory but associate with each lock a
 'last place called when a lock was already held'
 that might give a clue as to where the other instance was. I'm not
 volunteering to write it,
 but it might be very worth while.. I'd certainly like to hear other ideas as
 well.

I have a small patch against stable/7 that adds a single bit to each
witness structure so that, if the normal lock order is ever
encountered after a reversal, the stack is printed.  It doesn't help
when the order is defined statically, though.

I could try to roll this up against -CURRENT this weekend.

Thanks,
matthew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: lock order reversal bufwait/dirhash

[Garrett Cooper]

On Jun 9, 2010, at 12:51 AM, Bernd Walter wrote:

 Got this during installworld (source on NFS, destination UFS on CF-card)
 Source is current checked out yesterday.
 
 lock order reversal:
 1st 0xc28b85b4 bufwait (bufwait) @ 
 /data/builder/c13-2010-06-07/head/sys/kern/vfs_bio.c:2575
 2nd 0xc343f000 dirhash (dirhash) @ 
 /data/builder/c13-2010-06-07/head/sys/ufs/ufs/ufs_dirhash.c:283
 KDB: stack backtrace:
 db_trace_self_wrapper(c0905b2b,c0d02c56,c2d3d030,c2d40500,ca657890,...) at 
 db_trace_self_wrapper+0x26
 _witness_debugger(c0d02c56,c343f000,c0d279c2,c2d40500,c0d2762e,...) at 
 _witness_debugger+0x25
 witness_checkorder(c343f000,9,c0d2762e,11b,0,...) at witness_checkorder+0x73c
 _sx_xlock(c343f000,0,c0d2762e,11b,c3a07e80,...) at _sx_xlock+0x51
 ufsdirhash_acquire(e,1828,ca6579f0,c3a07e80,cb2bd814,...) at 
 ufsdirhash_acquire+0x35
 ufsdirhash_add(c3a07e80,ca6579f0,1828,ca657950,ca657954,...) at 
 ufsdirhash_add+0x1f
 ufs_direnter(c3944dd0,c423e220,ca6579f0,ca657bd0,c292ccb0,...) at 
 ufs_direnter+0x894
 ufs_mkdir(ca657bf8,ca657c0c,2,0,0,...) at ufs_mkdir+0x51c
 VOP_MKDIR_APV(c0e0f4c0,ca657bf8,ca657bd0,ca657b3c,2,...) at VOP_MKDIR_APV+0x8e
 kern_mkdirat(c39264e0,ff9c,80513e0,0,1c0,...) at kern_mkdirat+0x240
 kern_mkdir(c39264e0,80513e0,0,1c0,ca657c7c,...) at kern_mkdir+0x2f
 mkdir(c39264e0,ca657cec,ca657d28,c0d014f7,0,...) at mkdir+0x27
 syscallenter(c39264e0,ca657ce4,ca657ce4,0,c0e630c0,...) at syscallenter+0xc6
 syscall(ca657d28) at syscall+0x3a
 Xint0x80_syscall() at Xint0x80_syscall+0x20
 --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x281817cf, esp = 0xbfbfe30c, 
 ebp = 0xbfbfe398 ---

I've seen this for a while, but it was definitely present on the kernel that I 
tried working off of that was from Saturday.
Thanks,
-Garrett___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: lock order reversal bufwait/dirhash

[John Baldwin]

On Wednesday 09 June 2010 3:51:52 am Bernd Walter wrote:
 Got this during installworld (source on NFS, destination UFS on CF-card)
 Source is current checked out yesterday.
 
 lock order reversal:
  1st 0xc28b85b4 bufwait (bufwait) @ 
 /data/builder/c13-2010-06-07/head/sys/kern/vfs_bio.c:2575
  2nd 0xc343f000 dirhash (dirhash) @ 
 /data/builder/c13-2010-06-07/head/sys/ufs/ufs/ufs_dirhash.c:283
 KDB: stack backtrace:

Known false positive.  From ufs_dirhash.c:

/*
 * Locking:
 *
 * The relationship between inode and dirhash is protected either by an
 * exclusive vnode lock or the vnode interlock where a shared vnode lock
 * may be used.  The dirhash_mtx is acquired after the dirhash lock.  To
 * handle teardown races, code wishing to lock the dirhash for an inode
 * when using a shared vnode lock must obtain a private reference on the
 * dirhash while holding the vnode interlock.  They can drop it once they
 * have obtained the dirhash lock and verified that the dirhash wasn't
 * recycled while they waited for the dirhash lock.
 *
 * ufsdirhash_build() acquires a shared lock on the dirhash when it is
 * successful.  This lock is released after a call to ufsdirhash_lookup().
 *
 * Functions requiring exclusive access use ufsdirhash_acquire() which may
 * free a dirhash structure that was recycled by ufsdirhash_recycle().
 *
 * The dirhash lock may be held across io operations.
 *
 * WITNESS reports a lock order reversal between the bufwait lock
 * and the dirhash lock.  However, this specific reversal will not
 * cause a deadlock.  To get a deadlock, one would have to lock a
 * buffer followed by the dirhash while a second thread locked a
 * buffer while holding the dirhash lock.  The second order can happen
 * under a shared or exclusive vnode lock for the associated directory
 * in lookup().  The first order, however, can only happen under an
 * exclusive vnode lock (e.g. unlink(), rename(), etc.).  Thus, for
 * a thread to be doing a bufwait - dirhash order, it has to hold
 * an exclusive vnode lock.  That exclusive vnode lock will prevent
 * any other threads from doing a dirhash - bufwait order.
 */

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: lock order reversal bufwait/dirhash

[Rui Paulo]

On 9 Jun 2010, at 12:58, John Baldwin wrote:

 On Wednesday 09 June 2010 3:51:52 am Bernd Walter wrote:
 Got this during installworld (source on NFS, destination UFS on CF-card)
 Source is current checked out yesterday.
 
 lock order reversal:
 1st 0xc28b85b4 bufwait (bufwait) @ 
 /data/builder/c13-2010-06-07/head/sys/kern/vfs_bio.c:2575
 2nd 0xc343f000 dirhash (dirhash) @ 
 /data/builder/c13-2010-06-07/head/sys/ufs/ufs/ufs_dirhash.c:283
 KDB: stack backtrace:
 
 Known false positive.  From ufs_dirhash.c:
 
 /*
 * Locking:
 *
 * The relationship between inode and dirhash is protected either by an
 * exclusive vnode lock or the vnode interlock where a shared vnode lock
 * may be used.  The dirhash_mtx is acquired after the dirhash lock.  To
 * handle teardown races, code wishing to lock the dirhash for an inode
 * when using a shared vnode lock must obtain a private reference on the
 * dirhash while holding the vnode interlock.  They can drop it once they
 * have obtained the dirhash lock and verified that the dirhash wasn't
 * recycled while they waited for the dirhash lock.
 *
 * ufsdirhash_build() acquires a shared lock on the dirhash when it is
 * successful.  This lock is released after a call to ufsdirhash_lookup().
 *
 * Functions requiring exclusive access use ufsdirhash_acquire() which may
 * free a dirhash structure that was recycled by ufsdirhash_recycle().
 *
 * The dirhash lock may be held across io operations.
 *
 * WITNESS reports a lock order reversal between the bufwait lock
 * and the dirhash lock.  However, this specific reversal will not
 * cause a deadlock.  To get a deadlock, one would have to lock a
 * buffer followed by the dirhash while a second thread locked a
 * buffer while holding the dirhash lock.  The second order can happen
 * under a shared or exclusive vnode lock for the associated directory
 * in lookup().  The first order, however, can only happen under an
 * exclusive vnode lock (e.g. unlink(), rename(), etc.).  Thus, for
 * a thread to be doing a bufwait - dirhash order, it has to hold
 * an exclusive vnode lock.  That exclusive vnode lock will prevent
 * any other threads from doing a dirhash - bufwait order.
 */

Can we tell witness not to complain then?

Regards,
--
Rui Paulo


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: lock order reversal

[Kris Kennaway]

On Sun, Nov 30, 2003 at 07:46:55PM -0500, [EMAIL PROTECTED] wrote:
 Is this a known issue on 5.2 beta 6 sup'ed nov 29/03?

Yes, it's reported on a daily basis and is harmless.

Kris


pgp0.pgp
Description: PGP signature

Re: lock order reversal

[Gordon Tetlow]

On Tue, Nov 25, 2003 at 07:05:36PM -0600, John wrote:
 i was just looking through my daily reports from my new 5.2 beta box and 
 found this in dmesg.
 lock order reversal
  1st 0xc08f7ce0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201
  2nd 0xc1031100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2210

Here is the stack trace for the first one:

lock order reversal
 1st 0xc098e840 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201
 2nd 0xc1031100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2210
Stack backtrace:
backtrace(c089c5dc,c1031100,c08afe80,c08afe80,c08afef6) at backtrace+0x17
witness_lock(c1031100,8,c08afef6,8a2,c10310a0) at witness_lock+0x672
_mtx_lock_flags(c1031100,0,c08afef6,8a2,c55ae000) at _mtx_lock_flags+0xba
_vm_map_lock(c10310a0,c08afef6,8a2,c5394bd0,0) at _vm_map_lock+0x36
vm_map_remove(c10310a0,c55ae000,c55af000,d77e5bf8,c07eacab) at vm_map_remove+0x30
kmem_free(c10310a0,c55ae000,1000,d77e5c28,c07ea6bf) at kmem_free+0x32
page_free(c55ae000,1000,2,0,c55ae000) at page_free+0x3b
zone_drain(c101e000,0,c08b16a1,4b1,0) at zone_drain+0x2cf
zone_foreach(c07ea3f0,d77e5cf0,c07e7b98,c08b154f,0) at zone_foreach+0x45
uma_reclaim(c08b154f,0,c08b14bc,29e,c095bf80) at uma_reclaim+0x17
vm_pageout_scan(0,0,c08b14bc,5a9,1f4) at vm_pageout_scan+0x148
vm_pageout(0,d77e5d48,c0896d18,311,0) at vm_pageout+0x31b
fork_exit(c07e8990,0,d77e5d48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd77e5d7c, ebp = 0 ---


pgp0.pgp
Description: PGP signature

Re: lock order reversal is 5.2-BETA Nov 26

[Mikhail Teterin]

 On Thu, Nov 27, 2003 at 07:16:05PM -0500, Mikhail Teterin wrote:
  It did not crash or anything, but the following is printed on
  console now (addresses ommitted):
  
  lock order reversal
   1st ... UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201
   2nd ... system map (system map) @ /usr/src/sys/vm/vm_map.c:2210
 
 Thanks, this was reported several times already.

How about this one?

lock order reversal
1st 0xc37abad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
2nd 0xc098d020 swap_pager swhash (swap_pager swhash) @ 
/usr/src/sys/vm/swap_pager.c:1838
3rd 0xc1036948 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876

Sorry, backtrace was not logged, so I can not recreate it.

-mi
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: lock order reversal is 5.2-BETA Nov 26

[Kris Kennaway]

On Thu, Nov 27, 2003 at 10:00:54PM -0500, Mikhail Teterin wrote:
  On Thu, Nov 27, 2003 at 07:16:05PM -0500, Mikhail Teterin wrote:
   It did not crash or anything, but the following is printed on
   console now (addresses ommitted):
   
 lock order reversal
  1st ... UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201
  2nd ... system map (system map) @ /usr/src/sys/vm/vm_map.c:2210
  
  Thanks, this was reported several times already.
 
 How about this one?
 
 lock order reversal
 1st 0xc37abad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
 2nd 0xc098d020 swap_pager swhash (swap_pager swhash) @ 
 /usr/src/sys/vm/swap_pager.c:1838
 3rd 0xc1036948 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876

Even more frequently ;-)

Kris


pgp0.pgp
Description: PGP signature

Re: Lock order reversal

[Kris Kennaway]

On Mon, Jul 07, 2003 at 02:26:43PM +0400, Andrew Kolchoogin wrote:

 lock order reversal
  1st 0xc2f4b128 vm object (vm object) @ vm/vm_object.c:432
  2nd 0xc082f110 system map (system map) @ vm/vm_kern.c:325

This is known to be harmless.

Kris


pgp0.pgp
Description: PGP signature

RE: lock order reversal? current with tl ethernet

[Tod McQuillin]

On Wed, 12 Mar 2003, John Baldwin wrote:

 It's holding the lock across bus_setup_intr().  You can try the
 following patch:

 Index: if_tl.c
 ===
 RCS file: /usr/cvs/src/sys/pci/if_tl.c,v
 retrieving revision 1.74
 diff -u -r1.74 if_tl.c
 --- if_tl.c 19 Feb 2003 05:47:41 -  1.74
 +++ if_tl.c 12 Mar 2003 15:20:47 -
 @@ -1138,12 +1138,11 @@

 if (t-tl_name == NULL) {
 device_printf(dev, unknown device!?\n);
 -   goto fail;
 device_printf(dev, unknown device!?\n);
 -   goto fail;
 RCS file: /usr/cvs/src/sys/pci/if_tl.c,v
 retrieving revision 1.74
 diff -u -r1.74 if_tl.c
 --- if_tl.c 19 Feb 2003 05:47:41 -  1.74
 +++ if_tl.c 12 Mar 2003 15:20:47 -
 @@ -1138,12 +1138,11 @@

 if (t-tl_name == NULL) {
 device_printf(dev, unknown device!?\n);
 -   goto fail;
 +   return (ENXIO);
 }

 mtx_init(sc-tl_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
 MTX_DEF | MTX_RECURSE);
 -   TL_LOCK(sc);

 /*
  * Map control/status registers.
 @@ -1348,12 +1347,12 @@
 /*
  * Call MI attach routine.
  */

Thanks John --

This patch looks a little bit mangled to me.  It has two sections talking
about line 1138 of if_tl.c (with two different changes) and a section
talking about line 1348 (with no changes).

I assumed cut and paste error and proceeded along the same lines with this
patch instead:

Index: if_tl.c
===
RCS file: /usr/src/cvs-repo/src/sys/pci/if_tl.c,v
retrieving revision 1.74
diff -u -r1.74 if_tl.c
--- if_tl.c 19 Feb 2003 05:47:41 -  1.74
+++ if_tl.c 13 Mar 2003 00:26:20 -
@@ -1138,12 +1138,11 @@

if (t-tl_name == NULL) {
device_printf(dev, unknown device!?\n);
-   goto fail;
+   return (ENXIO);
}

mtx_init(sc-tl_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
MTX_DEF | MTX_RECURSE);
-   TL_LOCK(sc);

/*
 * Map control/status registers.
@@ -1349,11 +1348,9 @@
 * Call MI attach routine.
 */
ether_ifattach(ifp, sc-arpcom.ac_enaddr);
-   TL_UNLOCK(sc);
return(0);

 fail:
-   TL_UNLOCK(sc);
mtx_destroy(sc-tl_mtx);
return(error);
 }


This has made the messages go away -- thanks for that!  If this is a
correct fix, should I submit a PR to have it committed?
-- 
Tod McQuillin


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: lock order reversal? current with tl ethernet

[John Baldwin]

On 12-Mar-2003 Tod McQuillin wrote:
 
 Running -current from March 11 on a dual cpu compaq 5100, there are some
 warnings in the dmesg about the tl ethernet interface.
 
 Here are the warnings:
 
 malloc() of 128 with the following non-sleepablelocks held:
 exclusive sleep mutex tl0 (network driver) r = 0 (0xc4017aa8) locked @
 /usr/src/5-current/src/sys/pci/if_tl.c:1146

It's holding the lock across bus_setup_intr().  You can try the
following patch:

Index: if_tl.c
===
RCS file: /usr/cvs/src/sys/pci/if_tl.c,v
retrieving revision 1.74
diff -u -r1.74 if_tl.c
--- if_tl.c 19 Feb 2003 05:47:41 -  1.74
+++ if_tl.c 12 Mar 2003 15:20:47 -
@@ -1138,12 +1138,11 @@
 
if (t-tl_name == NULL) {
device_printf(dev, unknown device!?\n);
-   goto fail;
device_printf(dev, unknown device!?\n);
-   goto fail;
RCS file: /usr/cvs/src/sys/pci/if_tl.c,v
retrieving revision 1.74
diff -u -r1.74 if_tl.c
--- if_tl.c 19 Feb 2003 05:47:41 -  1.74
+++ if_tl.c 12 Mar 2003 15:20:47 -
@@ -1138,12 +1138,11 @@
 
if (t-tl_name == NULL) {
device_printf(dev, unknown device!?\n);
-   goto fail;
+   return (ENXIO);
}
 
mtx_init(sc-tl_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
MTX_DEF | MTX_RECURSE);
-   TL_LOCK(sc);
 
/*
 * Map control/status registers.
@@ -1348,12 +1347,12 @@
/*
 * Call MI attach routine.
 */

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
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

[Craig Rodrigues]

On Tue, Jan 28, 2003 at 07:04:07PM -0600, Sean Kelly wrote:
 I just noticed this during bootup. It is repeatable.

See:
http://news.gw.com/freebsd.current/30547

-- 
Craig Rodrigues
http://home.attbi.com/~rodrigc
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Lock order reversal

[Terry Lambert]

Craig Rodrigues wrote:
 On Tue, Jan 28, 2003 at 07:04:07PM -0600, Sean Kelly wrote:
  I just noticed this during bootup. It is repeatable.
 
 See:
 http://news.gw.com/freebsd.current/30547

That's a turn your head and cough patch.  It admits the code
is broken, and leaves it broken.  It also leaves the p-p_fd
dereference for assignment unprotected, where at least with the
reversal, it's protected.

Probably the correct thing to do is to move the assignment out
of the if statement, and then put a reference counter on the
fdp, which, so long as you are not the sole reference, you are
not allowed to delete it (similar to VREF in SVR4/Solaris).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Lock order reversal in if_ether.c

[Andre Guibert de Bruet]

Hello,

I've seen this very same message on one of my -current testboxes. While
we're on the topic of LORs, I've also come across the following:

Jan 27 00:44:57 largo kernel: lock order reversal
Jan 27 00:44:57 largo kernel: 1st 0xc6708314 inp (inp) 
@../../../netinet/tcp_input.c:641
Jan 27 00:44:57 largo kernel: 2nd 0xc0390cec tcp (tcp) @ 
../../../netinet/tcp_usrreq.c:621

and:

Jan 27 09:41:41 largo kernel: lock order reversal
Jan 27 09:41:41 largo kernel: 1st 0xc63d0460 process lock (process lock) @ 
../../../kern/kern_descrip.c:2104
Jan 27 09:41:41 largo kernel: 2nd 0xc63b9c34 filedesc structure (filedesc structure) @ 
../../../kern/kern_descrip.c:2111

largo# uname -a
FreeBSD largo.properkernel.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Jan 27 04:25:33 
EST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LARGO i386

Regards,

 Andre Guibert de Bruet | Enterprise Software Consultant 
 Silicon Landmark, LLC. | http://siliconlandmark.com/

On Mon, 27 Jan 2003, Craig Rodrigues wrote:

 Hi,

 I am seeingthis from a kernel cvsup'd a few days ago:

 login: lock order reversal
  1st 0xc060ad20 arp mutex (arp mutex) @ /usr/src/sys/netinet/if_ether.c:151
  2nd 0xc339097c radix node head (radix node head) @ /usr/src/sys/net/route.c:549

 Thanks.
 --
 Craig Rodrigues
 http://home.attbi.com/~rodrigc
 [EMAIL PROTECTED]

 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

Re: lock order reversal

[Daniel C. Sobral]

Kris Kennaway wrote:


On Mon, Jan 06, 2003 at 06:56:39PM +0100, Ulrich Spoerlein wrote:

On 2003/01/05-00:25:17 leafy wrote:


lock order reversal
Jan  5 00:19:15 leafy kernel: 1st 0xc26b05c0 process lock (process lock)
@/usr/src/sys/kern/kern_descrip.c:2099 Jan  5 00:19:15 leafy kernel: 2nd
0xc2667e34 filedesc structure (filedesc structure) @
/usr/src/sys/kern/kern_descrip.c:2106

The kernel is only about 40 mins old.


This is known and regularly reported here.


i got another LOR when starting up Quake2 (but only once every boot):
acquiring duplicate lock of same type: pcm channel
 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191
 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191


Don't know about this one.


What about this?

lock order reversal
 1st 0xc25afac0 pcm0 (sound softc) @ /usr/src/sys/dev/sound/pci/cmi.c:520
 2nd 0xc25af6c0 pcm0:play:0 (pcm channel) @ 
/usr/src/sys/dev/sound/pcm/channel.c:441

--
Daniel C. Sobral   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Outros:
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]

I've been on a diet for two weeks and all I've lost is two weeks.
		-- Totie Fields


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: lock order reversal

[Kris Kennaway]

On Mon, Jan 06, 2003 at 06:56:39PM +0100, Ulrich Spoerlein wrote:
 On 2003/01/05-00:25:17 leafy wrote:
 
 lock order reversal
 Jan  5 00:19:15 leafy kernel: 1st 0xc26b05c0 process lock (process lock)
 @/usr/src/sys/kern/kern_descrip.c:2099 Jan  5 00:19:15 leafy kernel: 2nd
 0xc2667e34 filedesc structure (filedesc structure) @
 /usr/src/sys/kern/kern_descrip.c:2106
 
 The kernel is only about 40 mins old.

This is known and regularly reported here.

 i got another LOR when starting up Quake2 (but only once every boot):
 acquiring duplicate lock of same type: pcm channel
  1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191
  2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191

Don't know about this one.

Kris



msg49907/pgp0.pgp
Description: PGP signature

Re: lock order reversal

[Ulrich Spoerlein]

On 2003/01/05-00:25:17 leafy wrote:

lock order reversal
Jan  5 00:19:15 leafy kernel: 1st 0xc26b05c0 process lock (process lock)
@/usr/src/sys/kern/kern_descrip.c:2099 Jan  5 00:19:15 leafy kernel: 2nd
0xc2667e34 filedesc structure (filedesc structure) @
/usr/src/sys/kern/kern_descrip.c:2106

The kernel is only about 40 mins old.

/me too.

updated world + kernel sometime yesterday (2003/01/05) and was about
updating linux_base when a kernel panic occured.
# portupgrade linux_base
...
panic: lockmgr: pid 3171, not exclusive lock holder
(sorry, i don't have more details :(

after rebooting i got this on bootup:
Mounting root from ufs:/dev/ad0s3a
WARNING: / was not properly dismounted
lock order reversal
 1st 0xc340f068 process lock (process lock) @
/usr/src/sys/kern/kern_descrip.c:2099
 2nd 0xc33e9634 filedesc structure (filedesc structure) @
/usr/src/sys/kern/kern_descrip.c:2106


i got another LOR when starting up Quake2 (but only once every boot):
acquiring duplicate lock of same type: pcm channel
 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191
 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191





msg49774/pgp0.pgp
Description: PGP signature

Re: lock order reversal / could sleep with process lock:

[Alex Zepeda]

On Sun, Aug 18, 2002 at 05:27:13PM -0700, Alex Zepeda wrote:

 Should I set debug.witness_ddb to 1 and get a trace from it?  Or has this 
 one already been seen?

It already fell over in exec, here's what it said:

GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bremfree: bp 0xc42410a0 not locked
panic messages:
---
panic: Most recently used by temp

cpuid = 0; lapic.id = 

syncing disks... panic: bremfree: bp 0xc42410a0 not locked
cpuid = 0; lapic.id = 
Uptime: 4h13m25s
Dumping 127 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112
---
#0  doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0  doadump () at ../../../kern/kern_shutdown.c:213
#1  0xc02216b1 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2  0xc02218d3 in panic () at ../../../kern/kern_shutdown.c:493
#3  0xc0255f71 in bremfree (bp=0xc42410a0) at ../../../kern/vfs_bio.c:633
#4  0xc02582ba in getblk (vp=0xc1b4c940, blkno=2883984, size=8192, slpflag=0, 
slptimeo=0) at ../../../kern/vfs_bio.c:2318
#5  0xc025605f in breadn (vp=0xc1b4c940, blkno=2883984, size=8192, 
rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0x0)
at ../../../kern/vfs_bio.c:691
#6  0xc025602c in bread (vp=0xc1b4c940, blkno=2883984, size=8192, cred=0x0, 
bpp=0xc9b2b904) at ../../../kern/vfs_bio.c:673
#7  0xc02d16d9 in ffs_update (vp=0xc1bd8128, waitfor=0)
at ../../../ufs/ffs/ffs_inode.c:102
#8  0xc02e1bf9 in ffs_fsync (ap=0xc9b2b97c) at ../../../ufs/ffs/ffs_vnops.c:292
#9  0xc02e1122 in ffs_sync (mp=0xc1b93a00, waitfor=2, cred=0xc0bace80, 
td=0xc03eda40) at vnode_if.h:545
#10 0xc0265860 in sync (td=0xc03eda40, uap=0x0)
at ../../../kern/vfs_syscalls.c:129
#11 0xc022131e in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#12 0xc02218d3 in panic () at ../../../kern/kern_shutdown.c:493
#13 0xc03021ec in mtrash_ctor (mem=0xc2093400, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:135
#14 0xc030113f in uma_zalloc_arg (zone=0xc0b859c0, udata=0x0, flags=0)
at ../../../vm/uma_core.c:1358
#15 0xc0218824 in malloc (size=6, type=0xc03f02c0, flags=0)
at ../../../kern/kern_malloc.c:171
#16 0xc0204324 in exec_elf32_imgact (imgp=0xc9b2bbc0) at imgact_elf.c:806
#17 0xc020e544 in execve (td=0xc1f1ed80, uap=0xc9b2bd14)
at ../../../kern/kern_exec.c:270
#18 0xc033a7a4 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 136140320, tf_ebp = 
-1077948136, tf_isp = -911032972, tf_ebx = 136156240, tf_edx = 136150624, tf_ecx = 5, 
tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134908427, tf_cs = 31, tf_eflags = 
642, tf_esp = -1077948356, tf_ss = 47})
at ../../../i386/i386/trap.c:1050
#19 0xc0326c1d in Xint0x80_syscall () at /var/tmp//ccTCRbXy.s:141
---Can't read userspace from dump, or kernel process---

(kgdb) quit

- alex

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: lock order reversal and panic in kern_descrip.c

[Jun Kuriyama]

At Mon, 22 Apr 2002 07:32:39 -0500,
Jacques A. Vidrine [EMAIL PROTECTED] wrote:
 Does it happen every time?  I cannot reproduce it.

Yes.

 What is odd is that fdcheckstd() is only called when exec'ing a
 set[ug]id executable -- any idea what set[ug]id program is being
 exec'd here?

I have no idea about this.  I'm portupgrade'ing linux_base,
linux-netscape-* port and I'll try this again.

  #14 0xc019d01b in fdcheckstd (td=0xe7f8ed50)
  at ../../../kern/kern_descrip.c:1532
  #15 0xc01a04e2 in execve (td=0xe7f8ed50, uap=0xe805bcdc)
  at ../../../kern/kern_exec.c:372
 
 My -CURRENT is a few days old.  I'll see if updating allows me to
 reproduce the problem.

A kern_descrip.c is updated by tanimura after your r1.137.  Could you
try with r1.138?


-- 
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 and panic in kern_descrip.c

[Jacques A. Vidrine]

On Mon, Apr 22, 2002 at 11:28:41AM +0900, Jun Kuriyama wrote:
 
 Today's -current kernel.  This happend when I invoke linux-netscape.

Does it happen every time?  I cannot reproduce it.

What is odd is that fdcheckstd() is only called when exec'ing a
set[ug]id executable -- any idea what set[ug]id program is being
exec'd here?

 #14 0xc019d01b in fdcheckstd (td=0xe7f8ed50)
 at ../../../kern/kern_descrip.c:1532
 #15 0xc01a04e2 in execve (td=0xe7f8ed50, uap=0xe805bcdc)
 at ../../../kern/kern_exec.c:372

My -CURRENT is a few days old.  I'll see if updating allows me to
reproduce the problem.

Cheers,
-- 
Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/
NTT/Verio SME  . FreeBSD UNIX .   Heimdal Kerberos
[EMAIL PROTECTED] .  [EMAIL PROTECTED]  .  [EMAIL PROTECTED]
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: lock order reversal and panic in kern_descrip.c

[Jacques A. Vidrine]

On Mon, Apr 22, 2002 at 10:35:49PM +0900, Jun Kuriyama wrote:
 A kern_descrip.c is updated by tanimura after your r1.137.  Could you
 try with r1.138?

Just updated to today's -CURRENT.  I still cannot reproduce the issue.

I'm curious ... could you send the output of 

  pkg_info -L linux-netscape-navigator-4.79 | xargs ls -l

?

Also, does `/compat/linux/bin/sh' blow up for you?

Cheers,
-- 
Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/
NTT/Verio SME  . FreeBSD UNIX .   Heimdal Kerberos
[EMAIL PROTECTED] .  [EMAIL PROTECTED]  .  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: lock order reversal and panic in kern_descrip.c

[Jun Kuriyama]

At Mon, 22 Apr 2002 11:09:26 -0500,
Jacques A. Vidrine [EMAIL PROTECTED] wrote:
 I'm curious ... could you send the output of 
 
   pkg_info -L linux-netscape-navigator-4.79 | xargs ls -l

Attached.

 Also, does `/compat/linux/bin/sh' blow up for you?

No, I can invoke this without problem...


-- 
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
 [EMAIL PROTECTED] // FreeBSD Project


-r-xr-xr-x  1 root  wheel  293 Apr 22 22:37 /usr/local/bin/navigator-linux-4.79
-r--r--r--  1 root  wheel16934 Oct 17  2001 /usr/local/lib/netscape-linux/LICENSE
-r--r--r--  1 root  wheel   323710 Oct 17  2001 
/usr/local/lib/netscape-linux/Netscape.ad
-r--r--r--  1 root  wheel16731 Oct 17  2001 /usr/local/lib/netscape-linux/README
-r--r--r--  1 root  wheel 4674 Oct 18  1994 /usr/local/lib/netscape-linux/XKeysymDB
-r--r--r--  1 root  wheel 4568 Oct 17  2001 
/usr/local/lib/netscape-linux/bookmark.htm
-r--r--r--  1 root  wheel 5861 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/aix/font.properties
-r--r--r--  1 root  wheel 6069 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/aix/font.properties.cs
-r--r--r--  1 root  wheel 6073 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/aix/font.properties.hu
-r--r--r--  1 root  wheel 9941 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/aix/font.properties.ja
-r--r--r--  1 root  wheel 7744 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/aix/font.properties.ko
-r--r--r--  1 root  wheel 6070 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/aix/font.properties.pl
-r--r--r--  1 root  wheel 6071 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/aix/font.properties.ru
-r--r--r--  1 root  wheel 7708 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/aix/font.properties.zh
-r--r--r--  1 root  wheel 8893 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/aix/font.properties.zh_TW
-r--r--r--  1 root  wheel  981 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/awt.properties
-r--r--r--  1 root  wheel 7304 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties
-r--r--r--  1 root  wheel 7757 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.cs
-r--r--r--  1 root  wheel 7713 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.el
-r--r--r--  1 root  wheel 7758 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.hu
-r--r--r--  1 root  wheel13029 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.ja
-r--r--r--  1 root  wheel 9033 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.ko
-r--r--r--  1 root  wheel 7771 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.lt
-r--r--r--  1 root  wheel 7771 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.lv
-r--r--r--  1 root  wheel 7758 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.pl
-r--r--r--  1 root  wheel 7711 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.ru
-r--r--r--  1 root  wheel 7721 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.tr
-r--r--r--  1 root  wheel 8976 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.zh
-r--r--r--  1 root  wheel 8984 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.zh_GB2312
-r--r--r--  1 root  wheel23909 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.zh_TW
-r--r--r--  1 root  wheel 8737 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.zh_TW_Big5
-r--r--r--  1 root  wheel23946 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/font.properties.zh_TW_CNS11643
-r-xr-xr-x  1 root  wheel11179 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/hpux/font.properties
-r-xr-xr-x  1 root  wheel 8364 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/hpux/font.properties.bg
-r-xr-xr-x  1 root  wheel 8672 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/hpux/font.properties.cs
-r-xr-xr-x  1 root  wheel 8360 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/hpux/font.properties.el
-r-xr-xr-x  1 root  wheel 8670 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/hpux/font.properties.hr
-r-xr-xr-x  1 root  wheel 8676 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/hpux/font.properties.hu
-r-xr-xr-x  1 root  wheel17681 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/hpux/font.properties.ja
-r-xr-xr-x  1 root  wheel14797 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/hpux/font.properties.ko
-r-xr-xr-x  1 root  wheel 8673 Oct  5  1998 
/usr/local/lib/netscape-linux/java/classes/hpux/font.properties.pl
-r-xr-xr-x  1 root  wheel 8665 Oct  5  1998 

Re: lock order reversal and panic in kern_descrip.c

[Jacques A. Vidrine]

On Tue, Apr 23, 2002 at 01:20:07AM +0900, Jun Kuriyama wrote:
 At Mon, 22 Apr 2002 11:09:26 -0500,
 Jacques A. Vidrine [EMAIL PROTECTED] wrote:
  I'm curious ... could you send the output of 
  
pkg_info -L linux-netscape-navigator-4.79 | xargs ls -l
 
 Attached.

No setuid executables ... it's a mystery to me how one encounters this
code path when running netscape :-(

-- 
Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/
NTT/Verio SME  . FreeBSD UNIX .   Heimdal Kerberos
[EMAIL PROTECTED] .  [EMAIL PROTECTED]  .  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: lock order reversal and panic in kern_descrip.c

[Jun Kuriyama]

 No setuid executables ... it's a mystery to me how one encounters this
 code path when running netscape :-(

Hmmm, after patch about FILEDESC_LOCK (1.139), my netscape can run
correctly.  (@_@)


-- 
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 with pcm..

[cameron grant]

 and the sound cracks/stops playing for the fraction of a second. seems
 like it happens more often during disk or network activity ( i mount
 /usr/ports via nfs, and when i build a port it happens all the time). the
 soundcard is a sblive. i searched the archive for this problem, but didnt
 find anything, so i thought i report it. would be cool if someone has a
 fix for that.

known issue, will be fixed sometime soon.

-cg



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Lock order reversal while playing mp3s

[Simon Dick]

On Wed, Nov 21, 2001 at 09:37:43AM +, Simon Dick wrote:
 I get the following lock order reversal when playing mp3s on my Vaio
 PCG-F807K laptop:
 lock order reversal
  1st 0xc399a840 pcm0:play:0 @ 
/usr/src/sys/modules/sound/pcm/../../../dev/sound/pcm/dsp.c:936
  2nd 0xc399ad80 pcm0 @ 
/usr/src/sys/modules/sound/pcm/../../../dev/sound/pcm/sound.c:132
 
 simond@laptop:~$ cat /dev/sndstat 
 FreeBSD Audio Driver (newpcm)
 Installed devices:
 pcm0: Yamaha DS-1E (YMF744) at memory 0xfedf8000 irq 9 (4p/2r/0v channels duplex 
default)
 
 My dmesg is attached.

And now my *real* dmesg is attached :)

-- 
Simon Dick  [EMAIL PROTECTED]
Why do I get this urge to go bowling everytime I see Tux?


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 #1: Tue Nov 20 17:30:10 GMT 2001
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPTOP
Preloaded elf kernel /boot/kernel/kernel at 0xc04fe000.
Preloaded elf module /boot/kernel/cd9660.ko at 0xc04fe0a8.
Preloaded elf module /boot/kernel/msdosfs.ko at 0xc04fe154.
Preloaded elf module /boot/kernel/ntfs.ko at 0xc04fe200.
Preloaded elf module /boot/kernel/procfs.ko at 0xc04fe2ac.
Preloaded elf module /boot/kernel/md.ko at 0xc04fe358.
Preloaded elf module /boot/kernel/linux.ko at 0xc04fe400.
Preloaded elf module /boot/kernel/ipfw.ko at 0xc04fe4ac.
Preloaded elf module /boot/kernel/if_wi.ko at 0xc04fe558.
Preloaded elf module /boot/kernel/snd_ds1.ko at 0xc04fe604.
Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04fe6b0.
Preloaded elf module /boot/kernel/usb.ko at 0xc04fe75c.
Preloaded elf module /boot/kernel/ugen.ko at 0xc04fe804.
Preloaded elf module /boot/kernel/uhid.ko at 0xc04fe8b0.
Preloaded elf module /boot/kernel/ums.ko at 0xc04fe95c.
Preloaded elf module /boot/kernel/umass.ko at 0xc04fea04.
Preloaded elf module /boot/kernel/agp.ko at 0xc04feab0.
Preloaded elf module /boot/kernel/atspeaker.ko at 0xc04feb58.
Preloaded elf module /boot/kernel/nfsclient.ko at 0xc04fec08.
Preloaded elf module /boot/kernel/fdc.ko at 0xc04fecb8.
Preloaded elf module /boot/kernel/if_ed.ko at 0xc04fed60.
Preloaded elf module /boot/kernel/miibus.ko at 0xc04fee0c.
Preloaded elf module /boot/kernel/snp.ko at 0xc04feeb8.
Preloaded elf module /boot/kernel/nmdm.ko at 0xc04fef60.
Preloaded elf module /boot/kernel/acpi.ko at 0xc04ff00c.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 645207024 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (645.21-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x686  Stepping = 6
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 268369920 (262080K bytes)
avail memory = 255623168 (249632K bytes)
Pentium Pro MTRR support enabled
VESA: v2.0, 8128k memory, flags:0x0, mode table:0xc0328842 (122)
VESA: ATI MACH64
Using $PIR table, 8 entries at 0xc00fdf40
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: SONY   K2   on motherboard
Timecounter ACPI  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0
acpi_cpu0: CPU on acpi0
acpi_tz0: thermal zone on acpi0
acpi_button0: Power Button on acpi0
acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: PCI bus on acpi_pcib0
agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0x4000-0x40ff at device 
0.0 on pci0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: display, VGA at device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0xfc90-0xfc9f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xfca0-0xfcbf irq 9 at device 
7.2 on pci0
usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
intpm0: Intel 82371AB Power management controller port 0x1040-0x104f irq 9 at device 
7.3 on pci0
intpm0: I/O mapped 1040
intpm0: intr IRQ 9 enabled revision 0
smbus0: System Management Bus on intsmb0
smb0: SMBus general purpose I/O on smbus0
intpm0: PM I/O mapped 8000 
pci0: serial bus, FireWire at device 8.0 (no driver attached)
pcm0: Yamaha DS-1E (YMF744) port 0xfc8c-0xfc8f,0xfcc0-0xfcff mem 
0xfedf8000-0xfedf irq 9 at device 9.0 on pci0
pci0: simple comms at device 10.0 (no driver attached)
acpi_pcib0: device is routed to IRQ 9
pcic0: Ricoh RL5C478 PCI-CardBus Bridge irq 9 at device 12.0 on pci0
pcic0: PCI Memory allocated: 0x4400
pccard0: PC Card bus (classic) on pcic0
acpi_pcib0: device is routed to IRQ 9
pcic1: Ricoh RL5C478 PCI-CardBus Bridge irq 9 at device 12.1 on pci0
pcic1: PCI Memory allocated: 0x44001000
pccard1: PC Card bus (classic) on pcic1
atspeaker0 

RE: lock order reversal for today's -CURRENT

[John Baldwin]

On 14-Nov-01 David Wolfskill wrote:
 Built  booted today's -CURRENT; saw the following on the console  in
 /var/log/messages:
 
 Nov 14 08:59:25 localhost /boot/kernel/kernel: lock order reversal
 Nov 14 08:59:25 localhost /boot/kernel/kernel: 1st 0xc0427980 dev_pager
 create @ /usr/src/sys/vm/device_pager.c:143
 Nov 14 08:59:25 localhost /boot/kernel/kernel: 2nd 0xc03feca0 pool mutex @
 /usr/src/sys/kern/kern_sx.c:329

This is due to the sx worker locks not using MTX_NOWITNESS with the pool mutex
changes.  It's not a problem though.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
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: RE: lock order reversal for today's -CURRENT

[Matthew Dillon]

:On 14-Nov-01 David Wolfskill wrote:
: Built  booted today's -CURRENT; saw the following on the console  in
: /var/log/messages:
: 
: Nov 14 08:59:25 localhost /boot/kernel/kernel: lock order reversal
: Nov 14 08:59:25 localhost /boot/kernel/kernel: 1st 0xc0427980 dev_pager
: create @ /usr/src/sys/vm/device_pager.c:143
: Nov 14 08:59:25 localhost /boot/kernel/kernel: 2nd 0xc03feca0 pool mutex @
: /usr/src/sys/kern/kern_sx.c:329
:
:This is due to the sx worker locks not using MTX_NOWITNESS with the pool mutex
:changes.  It's not a problem though.
:
:-- 
:
:John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/

Would it make sense for me to add a new MTX flag that disables certain 
non-applicable warnings?

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: RE: lock order reversal for today's -CURRENT

[John Baldwin]

On 14-Nov-01 Matthew Dillon wrote:
 
:On 14-Nov-01 David Wolfskill wrote:
: Built  booted today's -CURRENT; saw the following on the console  in
: /var/log/messages:
: 
: Nov 14 08:59:25 localhost /boot/kernel/kernel: lock order reversal
: Nov 14 08:59:25 localhost /boot/kernel/kernel: 1st 0xc0427980 dev_pager
: create @ /usr/src/sys/vm/device_pager.c:143
: Nov 14 08:59:25 localhost /boot/kernel/kernel: 2nd 0xc03feca0 pool mutex @
: /usr/src/sys/kern/kern_sx.c:329
:
:This is due to the sx worker locks not using MTX_NOWITNESS with the pool
:mutex
:changes.  It's not a problem though.
:
:-- 
:
:John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
 
 Would it make sense for me to add a new MTX flag that disables certain 
 non-applicable warnings?

Err, that's what MTX_NOWITNESS sort of does.  This one is a bit hard, as you
need a way to tell witness to ignore the lock orders between the reader writer
locks and the smaller locks used in implementing those locks.  Using
MTX_NOWITNESS on the sx worker locks worked great for this.  If the sx locks
had their own pool of MTX_NOWITNESS locks that would work fine.  They could
share this pool with the lockmgr worker locks as well.  They shouldn't be used
for anything else, however.  This is why I wanted to allow for multiple pools.

   -Matt
   Matthew Dillon 
   [EMAIL PROTECTED]

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
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: RE: lock order reversal for today's -CURRENT

[Matthew Dillon]

::This is due to the sx worker locks not using MTX_NOWITNESS with the pool
::mutex
::changes.  It's not a problem though.
::
::-- 
::
::John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
: 
: Would it make sense for me to add a new MTX flag that disables certain 
: non-applicable warnings?
:
:Err, that's what MTX_NOWITNESS sort of does.  This one is a bit hard, as you
:need a way to tell witness to ignore the lock orders between the reader writer
:locks and the smaller locks used in implementing those locks.  Using
:MTX_NOWITNESS on the sx worker locks worked great for this.  If the sx locks
:had their own pool of MTX_NOWITNESS locks that would work fine.  They could
:share this pool with the lockmgr worker locks as well.  They shouldn't be used
:for anything else, however.  This is why I wanted to allow for multiple pools.
:
:-- 
:
:John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/

I'm not against the concept of multiple pools, but I'm not really
for it either.  The various mutexes are already far too complex
for their own good... look at SX locks, for example.  The
struct sx is about 8 times as big as it needs to be to implement
reasonable functionality.  I would scrap the upgrade and 
downgrade API and I would scrap the condition variables
and go with a simple shared/exclusive counter.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: RE: lock order reversal for today's -CURRENT

[Glenn Gombert]

  Is there a good , current description of how  why  the various mutexe's
 conditon variables are used for somewhere?? I see what they are doing
in the code, but would like to get the big picture of why they are used
in one place (and not another type)..

Thanks,
Glenn G.

 
 I'm not against the concept of multiple pools, but I'm not really
 for it either.  The various mutexes are already far too complex
 for their own good... look at SX locks, for example.  The
 struct sx is about 8 times as big as it needs to be to implement
 reasonable functionality.  I would scrap the upgrade and 
 downgrade API and I would scrap the condition variables
 and go with a simple shared/exclusive counter.
 
   -Matt
   Matthew Dillon 
   [EMAIL PROTECTED]
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 

__
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: lock order reversal on Alpha

[Wilko Bulte]

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, but the
 same changes need to be replicated into all the otehr arch's.  Alternatively,
 we should have MI devices for the RTC and i8254 timers so that this code
 wouldn't be duplicated all over the place.  *sigh*
 
 If this is a UP box you should be able to just continue from this for now.

DS10 is UP yes. Tonight it ran a successful buildworld so it is not
always panicing ;)

-- 
|   / 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: lock order reversal on Alpha

[John Baldwin]

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.  Alternatively,
we should have MI devices for the RTC and i8254 timers so that this code
wouldn't be duplicated all over the place.  *sigh*

If this is a UP box you should be able to just continue from this 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

Re: lock order reversal

[Makoto MATSUSHITA]

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

[John Baldwin]

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

[John Baldwin]

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

[Makoto MATSUSHITA]

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

[John Baldwin]

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

[Makoto MATSUSHITA]

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

[Jun Kuriyama]

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

[Makoto MATSUSHITA]

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

Re: lock order reversal

[John Baldwin]

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

[Makoto MATSUSHITA]

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: lock order reversal under -current

[John Baldwin]

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

Re: lock order reversal message

[Jason Evans]

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