Re: lock order reversal and poudriere

2020-05-03 Thread 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

2020-05-03 Thread 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

2020-05-03 Thread 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

2020-05-03 Thread 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

2020-05-03 Thread 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

2020-05-02 Thread 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

2020-05-02 Thread 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

2020-05-02 Thread 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

2018-02-26 Thread 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

2018-02-25 Thread 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 ]

2017-02-25 Thread 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(&M_ACPICA)... done.
+   malloc_init(&M_KBDMUX)... done.
+   malloc_init(&M_LED)... done.
+   malloc_init(&M_MALODEV)... done.
+   malloc_init(&M_MD)... done.
+   malloc_init(&M_MDSECT)... done.
+   malloc_init(&M_MFIBUF)... done.
+   malloc_init(&M_MPR)... done.
+   malloc_init(&M_MPRSAS)... done.
+   malloc_init(&M_MPRUSER)... done.
+   malloc_init(&M_MPT2)... done.
+   malloc_init(&M_MPSSAS)... done.
+   malloc_init(&M_MPSUSER)... done.
+   malloc_init(&M_ACPITASK)... done.
+   malloc_init(&M_MPTUSER)... done.
+   malloc_init(&M_MRSAS)... done.
+   malloc_init(&M_ACPISEM)... done.
+   malloc_init(&M_CAMCCBQ)... done.
+   malloc_init(&M_ACPIDEV)... done.
+   malloc_init(&M_MVS)... done.
+   malloc_init(&M_MWLDEV)... done.
+   malloc_init(&M_NETMAP)... done.
+   malloc_init(&M_PPBUSDEV)... done.
+   malloc_init(&M_PSTIOP)... done.
+   malloc_init(&M_PSTRAID)... done.
+   malloc_init(&M_PUC)... done.
+   malloc_init(&M_CAMSIM)... done.
+   malloc_init(&M_ENTROPY)... done.
+   malloc_init(&M_CAMXPT)... done.
+   malloc_init(&M_CAMDEV)... done.
+   malloc_init(&M_CAMCCB)... done.
+   malloc_init(&M_CAMPATH)... done.
+   malloc_init(&M_SIIS)... done.
+   malloc_init(&M_CAMPERIPH)... done.
+   malloc_init(&M_SNP)... done.
+   malloc_init(&M_ACPICMBAT)... done.
+   malloc_init(&M_AC97)... done.
+   malloc_init(&M_FEEDER)... done.
+   malloc_init(&M_MIXER)... done.
+   malloc_init(&M_MIDI)... done.
+   malloc_init(&M_TWA)... done.
+   malloc_init(&M_TWE)... done.
+   malloc_init(&M_TWS)... done.
+   malloc_init(&M_ACPIPERF)... done.
+   malloc_init(&M_ACPIPWR)... done.
+   malloc_init(&M_CAMSCHED)... done.
+   malloc_init(&M_CAMQ)... done.
+   malloc_init(&M_SCSICD)... done.
+   malloc_init(&M_UART)... done.
+   malloc_init(&M_AGP)... done.
+   malloc_init(&M_AHCI)... done.
+   malloc_init(&M_USB)... done.
+   malloc_init(&M_USBDEV)... done.
+   malloc_init(&M_SCSICH)... done.
+   malloc_init(&M_ATADA)... done.
+   malloc_init(&M_CAMDEVQ)... done.
+   malloc_init(&M_SCSIDA)... done.
+   malloc_init(&M_SCSILOW)... done.
+   malloc_init(&M_AMR)... done.
+   malloc_init(&M_ATA)... done.
+   malloc_init(&M_ATADMA)... done.

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

2017-02-22 Thread 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]

2017-02-22 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-16 Thread 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

2016-05-15 Thread 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

2016-02-24 Thread 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

2012-06-16 Thread 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:  on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
cpu1:  on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
cpu2:  on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
cpu3:  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

2012-06-08 Thread 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 in sys/kern/vfs_mount.c

2012-06-08 Thread 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:  on acpi0
> driver bug: Unable to set devclass (class: acpi_sysresource devname: 
> (unknown))
> cpu1:  on acpi0
> driver bug: Unable to set devclass (class: acpi_sysresource devname: 
> (unknown))
> cpu2:  on acpi0
> driver bug: Unable to set devclass (class: acpi_sysresource devname: 
> (unknown))
> cpu3:  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

2012-06-08 Thread 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:  on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname: 
(unknown))

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

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

cpu3:  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

2011-09-06 Thread Вадим Денисов

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  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
Xint0x80_syscall() at Xint0x80_

Re: lock order reversal

2011-09-06 Thread 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  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,ef

Re: Lock order reversal .

2010-12-07 Thread Matthew Fleming
On Tue, Dec 7, 2010 at 9:18 AM, Julian Elischer  wrote:
> On 12/7/10 3:41 AM, Attilio Rao wrote:
>>
>> 2010/12/7 Erik Cederstrand:
>>>
>>> Den 07/12/2010 kl. 10.20 skrev Garrett Cooper:
>>>
 On Dec 7, 2010, at 12:26 AM, Mehmet Erol
 Sanliturk  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 .

2010-12-07 Thread Julian Elischer

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

2010/12/7 Erik Cederstrand:

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


On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk  
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 .

2010-12-07 Thread Attilio Rao
2010/12/7 Erik Cederstrand :
>
> Den 07/12/2010 kl. 10.20 skrev Garrett Cooper:
>
>> On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk  
>> 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 .

2010-12-07 Thread Erik Cederstrand

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

> On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk  
> 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 .

2010-12-07 Thread Garrett Cooper
On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk  
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 bufwait/dirhash

2010-06-09 Thread 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 bufwait/dirhash

2010-06-09 Thread 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

2010-06-09 Thread 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

2003-12-01 Thread 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 is 5.2-BETA Nov 26

2003-11-27 Thread 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 is 5.2-BETA Nov 26

2003-11-27 Thread 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

2003-11-27 Thread 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

2003-07-10 Thread Kris Kennaway
On Thu, Jul 10, 2003 at 11:58:14AM +0200, Gordon Bergling wrote:
> Hi,
> 
> getting this on a -current from 'Jul  6 23:16:01 CEST 2003'.
> I'll recieve this error a few minutes ago directly after booting the
> system. No user where logged in this time.

FAQ..it's harmless

Kris


pgp0.pgp
Description: PGP signature


Re: Lock order reversal

2003-07-07 Thread 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

2003-03-13 Thread 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

2003-03-12 Thread 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

2003-01-28 Thread 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

2003-01-28 Thread 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 in if_ether.c

2003-01-27 Thread 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

2003-01-10 Thread 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

2003-01-09 Thread 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

2003-01-06 Thread 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:

2002-08-19 Thread 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

2002-04-22 Thread 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 and panic in kern_descrip.c

2002-04-22 Thread 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

2002-04-22 Thread Jun Kuriyama

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

Hmm, I can reproduce this even after upgrading related ports...


-- 
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

2002-04-22 Thread 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 
/usr/local/lib/netscape-lin

Re: lock order reversal and panic in kern_descrip.c

2002-04-22 Thread 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

2002-04-22 Thread 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

2002-04-22 Thread 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 with pcm..

2001-11-30 Thread 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

2001-11-21 Thread 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:  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=0x383f9ff
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:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
Timecounter "ACPI"  frequency 3579545 Hz
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
acpi_cpu0:  on acpi0
acpi_tz0:  on acpi0
acpi_button0:  on acpi0
acpi_pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on acpi_pcib0
agp0:  mem 0x4000-0x40ff at device 
0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xfc90-0xfc9f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0:  port 0xfca0-0xfcbf irq 9 at device 
7.2 on pci0
usb0:  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:  port 0x1040-0x104f irq 9 at device 
7.3 on pci0
intpm0: I/O mapped 1040
intpm0: intr IRQ 9 enabled revision 0
smbus0:  on intsmb0
smb0:  on smbus0
intpm0: PM I/O mapped 8000 
pci0:  at device 8.0 (no driver attached)
pcm0:  port 0xfc8c-0xfc8f,0xfcc0-0xfcff mem 
0xfedf8000-0xfedf irq 9 at device 9.0 on pci0
pci0:  at device 10.0 (no driver attached)
acpi_pcib0: device is routed to IRQ 9
pcic0:  irq 9 at device 12.0 on pci0
pcic0: PCI Memory allocated: 0x4400
pccard0:  on pcic0
acpi_pcib0: device is routed to IRQ 9
pcic1:  irq 9 at device 12.1 on pci0
pcic1: PCI Memory allocated: 0x44001000
pccard1:  on pcic1
atspeaker0 port 0x61 on acpi0
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
psm0:  irq 12 on atkbdc0
psm0: model GlidePoint, device ID 0
acpi_ec0:  port 0x66,0x62 on acpi0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
ppc0 port 0x778-0x77a,0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
fdc0:  port 0x3f7,0x3f0-0x3f5 irq 6 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1

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

2001-11-14 Thread 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: RE: lock order reversal for today's -CURRENT

2001-11-14 Thread 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

2001-11-14 Thread 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

2001-11-14 Thread 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: lock order reversal for today's -CURRENT

2001-11-14 Thread 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: lock order reversal on Alpha

2001-10-20 Thread 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

2001-10-19 Thread 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

2001-06-26 Thread 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

2001-06-26 Thread 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

2001-06-22 Thread 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

2001-06-22 Thread 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

2001-06-22 Thread 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

2001-06-22 Thread 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

2001-06-22 Thread 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

2001-06-21 Thread 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

2001-06-21 Thread 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

2001-06-21 Thread 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

2001-06-20 Thread Jun Kuriyama


Another message is reported:

lock order reversal
 1st 0xc043ad20 dev_pager create @ ../../vm/device_pager.c:142
 2nd 0xc0459840 vm @ ../../vm/vm_kern.c:186


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

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



RE: lock order reversal under -current

2001-02-28 Thread 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

2001-01-30 Thread 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