Re: lock order reversal and poudriere
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
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
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
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
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
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
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
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
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
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 ]
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]
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]
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
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
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
> 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
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
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
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
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
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
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
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
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 .
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 .
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/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 .
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 .
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
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
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
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
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
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
> 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
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
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
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
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
On 12-Mar-2003 Tod McQuillin wrote:
>
> Running -current from March 11 on a dual cpu compaq 5100, there are some
> warnings in the dmesg about the tl ethernet interface.
>
> Here are the warnings:
>
> malloc() of "128" with the following non-sleepablelocks held:
> exclusive sleep mutex tl0 (network driver) r = 0 (0xc4017aa8) locked @
> /usr/src/5-current/src/sys/pci/if_tl.c:1146
It's holding the lock across bus_setup_intr(). You can try the
following patch:
Index: if_tl.c
===
RCS file: /usr/cvs/src/sys/pci/if_tl.c,v
retrieving revision 1.74
diff -u -r1.74 if_tl.c
--- if_tl.c 19 Feb 2003 05:47:41 - 1.74
+++ if_tl.c 12 Mar 2003 15:20:47 -
@@ -1138,12 +1138,11 @@
if (t->tl_name == NULL) {
device_printf(dev, "unknown device!?\n");
- goto fail;
device_printf(dev, "unknown device!?\n");
- goto fail;
RCS file: /usr/cvs/src/sys/pci/if_tl.c,v
retrieving revision 1.74
diff -u -r1.74 if_tl.c
--- if_tl.c 19 Feb 2003 05:47:41 - 1.74
+++ if_tl.c 12 Mar 2003 15:20:47 -
@@ -1138,12 +1138,11 @@
if (t->tl_name == NULL) {
device_printf(dev, "unknown device!?\n");
- goto fail;
+ return (ENXIO);
}
mtx_init(&sc->tl_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
MTX_DEF | MTX_RECURSE);
- TL_LOCK(sc);
/*
* Map control/status registers.
@@ -1348,12 +1347,12 @@
/*
* Call MI attach routine.
*/
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Lock order reversal
Craig Rodrigues 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
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
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
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
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
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:
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
> 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
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
> 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
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
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
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
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..
> 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
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
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
:>: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
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
: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
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
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
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
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
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
I got same backtrace.
Additional daemons: syslogdlock order reversal
1st 0xc044fc80 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:1007
2nd 0xcb1ef8ac vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:1016
Debugger("witness_lock")
Stopped at Debugger+0x44: pushl %ebx
db> trace
Debugger(c038c22e) at Debugger+0x44
witness_lock(cb1ef8ac,8,c03a86d9,3f8) at witness_lock+0x90d
ffs_sync(c10cca00,3,c0cd3e00,c9908dc0,c10cca00,2) at ffs_sync+0x175
sync_fsync(ca368f5c) at sync_fsync+0x18f
sched_sync(0,ca368fa8) at sched_sync+0x16c
fork_exit(c0226ef4,0,ca368fa8) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
db>
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal
tacho> lock order reversal tacho> 1st 0xc03f0140 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1007 tacho> 2nd 0xcaec972c vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1016 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
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
jhb> Can you turn on WITNESS_DDB in your kenrel config file (or set jhb> the debug.witness_ddb loader tunable/sysctl before you get this jhb> reversal) and get a backtrace from ddb? Yes; I turned 'debug.witness_ddb' on now. I'll send a ddb 'trace' output if next time lock-order-reversal is happen. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal
On 22-Jun-01 Makoto MATSUSHITA wrote: > > 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
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
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
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
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
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
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
