Witness message about lock order reversal on 10 (head)
I got these messages on 10 head, rev.254235, during 'filesystem full' condition. Yuri = log = lock order reversal: 1st 0xff80f7432470 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3054 2nd 0xfe00075b5600 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff8000284440 kdb_backtrace() at kdb_backtrace+0x39/frame 0xff80002844f0 witness_checkorder() at witness_checkorder+0xd4f/frame 0xff8000284580 _sx_xlock() at _sx_xlock+0x75/frame 0xff80002845c0 ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xff8000284600 ufs_direnter() at ufs_direnter+0x688/frame 0xff80002846c0 ufs_mkdir() at ufs_mkdir+0x863/frame 0xff80002848c0 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf0/frame 0xff80002848f0 kern_mkdirat() at kern_mkdirat+0x21a/frame 0xff8000284ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xff8000284bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff8000284bf0 --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x800931e9a, rsp = 0x7fffd798, rbp = 0x7fffdc70 --- lock order reversal: 1st 0xfe0007633840 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1184 2nd 0xfe0007a45240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4346 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff800031f6b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xff800031f760 witness_checkorder() at witness_checkorder+0xd4f/frame 0xff800031f7f0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xff800031f920 ffs_lock() at ffs_lock+0x84/frame 0xff800031f970 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xff800031f9a0 _vn_lock() at _vn_lock+0xab/frame 0xff800031fa10 knlist_remove_kq() at knlist_remove_kq+0x82/frame 0xff800031fa40 knote_fdclose() at knote_fdclose+0xc8/frame 0xff800031fa90 closefp() at closefp+0x64/frame 0xff800031fae0 amd64_syscall() at amd64_syscall+0x265/frame 0xff800031fbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff800031fbf0 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80164537a, rsp = 0x7f7fbf08, rbp = 0x7f7fbf20 --- pid 983 (sendmail), uid 25 inumber 473785 on /: filesystem full pid 1101 (dd), uid 2 inumber 426338 on /: filesystem full lock order reversal: 1st 0xfe0007cbc240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 2nd 0xff80f7894338 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xfe003b531418 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff8000378e60 kdb_backtrace() at kdb_backtrace+0x39/frame 0xff8000378f10 witness_checkorder() at witness_checkorder+0xd4f/frame 0xff8000378fa0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xff80003790d0 ffs_lock() at ffs_lock+0x84/frame 0xff8000379120 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xff8000379150 _vn_lock() at _vn_lock+0xab/frame 0xff80003791c0 vget() at vget+0x70/frame 0xff8000379210 vfs_hash_get() at vfs_hash_get+0xf5/frame 0xff8000379260 ffs_vgetf() at ffs_vgetf+0x41/frame 0xff80003792f0 softdep_sync_buf() at softdep_sync_buf+0x2e4/frame 0xff80003793a0 ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xff8000379420 ffs_truncate() at ffs_truncate+0x5ca/frame 0xff8000379600 ufs_direnter() at ufs_direnter+0x891/frame 0xff80003796c0 ufs_mkdir() at ufs_mkdir+0x863/frame 0xff80003798c0 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf0/frame 0xff80003798f0 kern_mkdirat() at kern_mkdirat+0x21a/frame 0xff8000379ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xff8000379bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff8000379bf0 --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x800931e9a, rsp = 0x7fffd898, rbp = 0x7fffd970 --- ___ 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: /etc/namedb-@ referrs to NIL after crash or typing reboot (not shutdown -r)
On Saturday, August 17, 2013 1:42:07 pm Tim Kientzle wrote: On Aug 17, 2013, at 10:35 AM, O. Hartmann wrote: On Sat, 17 Aug 2013 21:10:49 +0400 Boris Samorodov b...@passap.ru wrote: 17.08.2013 13:36, O. Hartmann пишет: I can reproduceable truncate the link in /etc/ to be NIL by typing simply reboot when rebooting the box Does it make any difference if you use shutdown -r instead? Yes, when using shutdown -r the link isn't broken and the system reboots and operates as expected. Only if I use the quick and dirty way via reboot or after a crash when service named ahs already been started the link is dead. If a crahs occurs BEFORE service named has been started, the recovery is also operable - this is my observation. Does reboot show the same problem If the system has been running for a while (at least 15 minutes or so)? Your broken link sounds like the expected behavior when you do a dirty reboot shortly after the link has been created (before the link contents have been written all the way to disk). reboot shouldn't be a dirty reboot in this sense though. The disks should still be synced if you do a reboot. Only a panic or power failure should give you unsynced disks. -- 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: Witness message about lock order reversal on 10 (head)
It might be the same false positive I saw a couple weeks ago ... Davide said to me: | The LOR is a false positive. | See the comment in sys/ufs/ufs/ufs_dirhash.c | Also, switching motherboards is not related to this in any way. You'll | eventually hit that LOR report, unless you disabled WITNESS. Thanks, -- Davide On Mon, 19 Aug 2013, Yuri wrote: I got these messages on 10 head, rev.254235, during 'filesystem full' condition. Yuri = log = lock order reversal: 1st 0xff80f7432470 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3054 2nd 0xfe00075b5600 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff8000284440 kdb_backtrace() at kdb_backtrace+0x39/frame 0xff80002844f0 witness_checkorder() at witness_checkorder+0xd4f/frame 0xff8000284580 _sx_xlock() at _sx_xlock+0x75/frame 0xff80002845c0 ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xff8000284600 ufs_direnter() at ufs_direnter+0x688/frame 0xff80002846c0 ufs_mkdir() at ufs_mkdir+0x863/frame 0xff80002848c0 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf0/frame 0xff80002848f0 kern_mkdirat() at kern_mkdirat+0x21a/frame 0xff8000284ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xff8000284bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff8000284bf0 --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x800931e9a, rsp = 0x7fffd798, rbp = 0x7fffdc70 --- lock order reversal: 1st 0xfe0007633840 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1184 2nd 0xfe0007a45240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4346 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff800031f6b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xff800031f760 witness_checkorder() at witness_checkorder+0xd4f/frame 0xff800031f7f0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xff800031f920 ffs_lock() at ffs_lock+0x84/frame 0xff800031f970 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xff800031f9a0 _vn_lock() at _vn_lock+0xab/frame 0xff800031fa10 knlist_remove_kq() at knlist_remove_kq+0x82/frame 0xff800031fa40 knote_fdclose() at knote_fdclose+0xc8/frame 0xff800031fa90 closefp() at closefp+0x64/frame 0xff800031fae0 amd64_syscall() at amd64_syscall+0x265/frame 0xff800031fbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff800031fbf0 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80164537a, rsp = 0x7f7fbf08, rbp = 0x7f7fbf20 --- pid 983 (sendmail), uid 25 inumber 473785 on /: filesystem full pid 1101 (dd), uid 2 inumber 426338 on /: filesystem full lock order reversal: 1st 0xfe0007cbc240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 2nd 0xff80f7894338 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xfe003b531418 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff8000378e60 kdb_backtrace() at kdb_backtrace+0x39/frame 0xff8000378f10 witness_checkorder() at witness_checkorder+0xd4f/frame 0xff8000378fa0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xff80003790d0 ffs_lock() at ffs_lock+0x84/frame 0xff8000379120 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xff8000379150 _vn_lock() at _vn_lock+0xab/frame 0xff80003791c0 vget() at vget+0x70/frame 0xff8000379210 vfs_hash_get() at vfs_hash_get+0xf5/frame 0xff8000379260 ffs_vgetf() at ffs_vgetf+0x41/frame 0xff80003792f0 softdep_sync_buf() at softdep_sync_buf+0x2e4/frame 0xff80003793a0 ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xff8000379420 ffs_truncate() at ffs_truncate+0x5ca/frame 0xff8000379600 ufs_direnter() at ufs_direnter+0x891/frame 0xff80003796c0 ufs_mkdir() at ufs_mkdir+0x863/frame 0xff80003798c0 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf0/frame 0xff80003798f0 kern_mkdirat() at kern_mkdirat+0x21a/frame 0xff8000379ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xff8000379bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff8000379bf0 --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x800931e9a, rsp = 0x7fffd898, rbp = 0x7fffd970 --- ___ 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 dan -- Dan Mack ___ 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: USB no proper work
18.08.2013 01:04, Hans Petter Selasky пишет: On 08/17/13 23:55, Alexander Panyushkin wrote: 17.08.2013 19:41, Alexander Motin пишет: On 17.08.2013 09:22, Hans Petter Selasky wrote: On USB device FAT-32 file system. When I removed flash drive, the file system has been unmounted. Hi, The problem might be in the GELI module then. Did you test that Alexander ? Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Device gpt/swap0.eli created. Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Encryption: AES-XTS 128 Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Crypto: software Hint: You can set the following knob to disable the USB waiting at reboot. hw.usb.no_shutdown_wait=1 If set hw.usb.no_shutdown_wait = 1 Reboot successful, but if detach and attach again, USB device not detecting. That seems like encrypted swap. It is probably not on the flash drive. Swap disconnect is a known problem since system may loose part of its kernel address space that may cause immediate panic if we handle disconnect too pedantic. But any way this I think is not our case. unmount the swap did not happiness ___ 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: USB no proper work
On 08/19/13 21:54, Alexander Panyushkin wrote: 18.08.2013 01:04, Hans Petter Selasky пишет: On 08/17/13 23:55, Alexander Panyushkin wrote: 17.08.2013 19:41, Alexander Motin пишет: On 17.08.2013 09:22, Hans Petter Selasky wrote: On USB device FAT-32 file system. When I removed flash drive, the file system has been unmounted. Hi, The problem might be in the GELI module then. Did you test that Alexander ? Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Device gpt/swap0.eli created. Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Encryption: AES-XTS 128 Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Crypto: software Hint: You can set the following knob to disable the USB waiting at reboot. hw.usb.no_shutdown_wait=1 If set hw.usb.no_shutdown_wait = 1 Reboot successful, but if detach and attach again, USB device not detecting. This test is an indication that the USB stack is waiting for the CAM layer to finish detaching its clients. Maybe you can turn on cam debugging to figure out who is leaking a ref. Alexander Motin knows how. --HPS ___ 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
Question about socket timeouts
Hi! Recently I was playing with small socket timeouts. setsockopt(2) SO_RCVTIMEO and found a problem with it: if timeout is small enough read(2) may return before timeout is actually expired. I was unable to reproduce this on linux box. I found that kernel uses a timer with 1/HZ precision so it converts time in microseconds to ticks that's ok linux does it as well. The problem is in details: freebsd uses floor() approach while linux uses ceil(): from FreeBSD's sys/kern/uipc_socket.c: val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; if (val == 0 tv.tv_usec != 0) val = 1; /* at least one tick if tv 0 */ from Linux's net/core/sock.c: *timeo_p = tv.tv_sec*HZ + (tv.tv_usec+(100/HZ-1))/(100/HZ); So, for instance, we have a freebsd system running with kern.hz set 100 and set receive timeout to 25ms that is converted to 2 ticks which is 20ms. In my test program read(2) returns with EAGAIN set in 0.019ms. So the question is: is that a problem or not? -- vitja. ___ 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: Question about socket timeouts
Yes! Please file a PR! -adrian On 19 August 2013 12:33, Vitja Makarov vitja.maka...@gmail.com wrote: Hi! Recently I was playing with small socket timeouts. setsockopt(2) SO_RCVTIMEO and found a problem with it: if timeout is small enough read(2) may return before timeout is actually expired. I was unable to reproduce this on linux box. I found that kernel uses a timer with 1/HZ precision so it converts time in microseconds to ticks that's ok linux does it as well. The problem is in details: freebsd uses floor() approach while linux uses ceil(): from FreeBSD's sys/kern/uipc_socket.c: val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; if (val == 0 tv.tv_usec != 0) val = 1; /* at least one tick if tv 0 */ from Linux's net/core/sock.c: *timeo_p = tv.tv_sec*HZ + (tv.tv_usec+(100/HZ-1))/(100/HZ); So, for instance, we have a freebsd system running with kern.hz set 100 and set receive timeout to 25ms that is converted to 2 ticks which is 20ms. In my test program read(2) returns with EAGAIN set in 0.019ms. So the question is: is that a problem or not? -- vitja. ___ 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 ___ 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: Question about socket timeouts
On Mon, 19 Aug 2013, Adrian Chadd wrote: Yes! Please file a PR! This sorta implies that both are acceptable (although, the Linux behavior seems more desirable). http://austingroupbugs.net/view.php?id=369 On 19 August 2013 12:33, Vitja Makarov vitja.maka...@gmail.com wrote: Hi! Recently I was playing with small socket timeouts. setsockopt(2) SO_RCVTIMEO and found a problem with it: if timeout is small enough read(2) may return before timeout is actually expired. I was unable to reproduce this on linux box. I found that kernel uses a timer with 1/HZ precision so it converts time in microseconds to ticks that's ok linux does it as well. The problem is in details: freebsd uses floor() approach while linux uses ceil(): from FreeBSD's sys/kern/uipc_socket.c: val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; if (val == 0 tv.tv_usec != 0) val = 1; /* at least one tick if tv 0 */ from Linux's net/core/sock.c: *timeo_p = tv.tv_sec*HZ + (tv.tv_usec+(100/HZ-1))/(100/HZ); So, for instance, we have a freebsd system running with kern.hz set 100 and set receive timeout to 25ms that is converted to 2 ticks which is 20ms. In my test program read(2) returns with EAGAIN set in 0.019ms. So the question is: is that a problem or not? -- vitja. -- DE ___ 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
