[Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227213 Eugene Grosbein changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-stable@FreeBSD.org Summary|FreeBSD 10.4 kernel |FreeBSD 10.4 kernel |deadlocks with i7-7700 /|deadlocks on sysctlmemlock |ASUS PRIME H270M-PLUS | -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS
On 02/04/2018 18:35, Eugene Grosbein wrote: Use such debugging kernel to drop to the debugger when deadlock occurs using Ctr-Alt-ESC and type "call doadump", you should get crashdump anyway. Then use "reboot" or just power cycle to get crashdump stored to /var/crash. Then fill a PR and reply with the number. Thank you. Please see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227213 Hopefully I've provided links to the necessary files. Let me know if anything else is useful! Best regards, Mark -- Mark Knight ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS
02.04.2018 23:41, Mark Knight пишет: > On 02/04/2018 14:44, Eugene Grosbein wrote: >> 3. Boot new kernel using nextboot(8) and see if it will crash instead of >> deadlock >> and if so, fill the PR to Bugzilla. > > Thanks again. Drat, no crash. The only difference was a few new errors during > the boot - which I'm assuming are unrelated. Add to /etc/sysctl.conf: debug.kdb.break_to_debugger=1 Use such debugging kernel to drop to the debugger when deadlock occurs using Ctr-Alt-ESC and type "call doadump", you should get crashdump anyway. Then use "reboot" or just power cycle to get crashdump stored to /var/crash. Then fill a PR and reply with the number. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS
On 02/04/2018 14:44, Eugene Grosbein wrote: 3. Boot new kernel using nextboot(8) and see if it will crash instead of deadlock and if so, fill the PR to Bugzilla. Thanks again. Drat, no crash. The only difference was a few new errors during the boot - which I'm assuming are unrelated. Apr 2 17:27:58 shrewd kernel: [16] lock order reversal: Apr 2 17:27:58 shrewd kernel: [16] 1st 0xf80077653418 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2253 Apr 2 17:27:58 shrewd kernel: [16] 2nd 0xfe03dbe7d218 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 Apr 2 17:27:58 shrewd kernel: [16] 3rd 0xf80077c089a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2253 Apr 2 17:27:58 shrewd kernel: [16] KDB: stack backtrace: Apr 2 17:27:58 shrewd kernel: [16] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0462049b30 Apr 2 17:27:58 shrewd kernel: [16] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0462049be0 Apr 2 17:27:58 shrewd kernel: [16] witness_checkorder() at witness_checkorder+0xe2b/frame 0xfe0462049c70 Apr 2 17:27:58 shrewd kernel: [16] __lockmgr_args() at __lockmgr_args+0x988/frame 0xfe0462049d90 Apr 2 17:27:58 shrewd kernel: [16] ffs_lock() at ffs_lock+0x84/frame 0xfe0462049de0 Apr 2 17:27:58 shrewd kernel: [16] VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe0462 Apr 2 17:27:58 shrewd kernel: 049e10 Apr 2 17:27:59 shrewd kernel: [16] _vn_lock() at _vn_lock+0xaa/frame 0xfe0462049e80 Apr 2 17:27:59 shrewd kernel: [16] vget() at vget+0x67/frame 0xfe0462049ec0 Apr 2 17:27:59 shrewd kernel: [16] vfs_hash_get() at vfs_hash_get+0xe1/frame 0xfe0462049f10 Apr 2 17:27:59 shrewd kernel: [16] ffs_vgetf() at ffs_vgetf+0x40/frame 0xfe0462049fa0 Apr 2 17:27:59 shrewd kernel: [16] softdep_sync_buf() at softdep_sync_buf+0xa25/frame 0xfe046204a090 Apr 2 17:27:59 shrewd kernel: [16] ffs_syncvnode() at ffs_syncvnode+0x286/frame 0xfe046204a110 Apr 2 17:27:59 shrewd kernel: [16] ffs_truncate() at ffs_truncate+0x6a9/frame 0xfe046204a2f0 Apr 2 17:27:59 shrewd kernel: [16] ufs_direnter() at ufs_direnter+0x7c8/frame 0xfe046204a3b0 Apr 2 17:27:59 shrewd kernel: [16] ufs_makeinode() at ufs_makeinode+0x5d9/frame 0xfe046204a570 Apr 2 17:27:59 shrewd kernel: [16] ufs_create() at ufs_create+0x34/frame 0xfe046204a590 Apr 2 17:27:59 shrewd kernel: [16] VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe046204a5c0 Apr 2 17:27:59 shrewd kernel: [16] vn_open_cred() at vn_open_cred+0x2c3/frame 0xfe046204a720 Apr 2 17:27:59 shrewd kernel: [16] kern_openat() at kern_openat+0x26f/frame 0xfe046204a8a0 Apr 2 17:27:59 shrewd kernel: [16] amd64_syscall() at amd64_syscall+0x2c6/frame 0xfe046204a9b0 Apr 2 17:27:59 shrewd kernel: [16] Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe046204a9b0 Apr 2 17:27:59 shrewd kernel: [16] --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x801fcc9aa, rsp = 0x7fffdfdf9c38, rbp = 0x7fffdfdf9c60 --- Apr 2 17:28:48 shrewd kernel: [66] lock order reversal: Apr 2 17:28:48 shrewd kernel: [66] 1st 0xfe03dbf949f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3130 Apr 2 17:28:48 shrewd kernel: [66] 2nd 0xf8000b741000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:280 Apr 2 17:28:48 shrewd kernel: [66] KDB: stack backtrace: Apr 2 17:28:48 shrewd kernel: [66] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0462185130 Apr 2 17:28:48 shrewd kernel: [66] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe04621851e0 Apr 2 17:28:48 shrewd kernel: [66] witness_checkorder() at witness_checkorder+0xe2b/frame 0xfe0462185270 Apr 2 17:28:48 shrewd kernel: [66] _sx_xlock() at _sx_xlock+0x75/frame 0xfe04621852b0 Apr 2 17:28:48 shrewd kernel: [66] ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfe04621852f0 Apr 2 17:28:48 shrewd kernel: [66] ufs_direnter() at ufs_direnter+0x622/frame 0xfe04621853b0 Apr 2 17:28:48 shrewd kernel: [66] ufs_makeinode() at ufs_makeinode+0x5d9/frame 0xfe0462185570 Apr 2 17:28:48 shrewd kernel: [66] ufs_create() at ufs_create+0x34/frame 0xfe0462185590 Apr 2 17:28:48 shrewd kernel: [66] VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe04621855c0 Apr 2 17:28:48 shrewd kernel: [66] vn_open_cred() at vn_open_cred+0x2c3/frame 0xfe0462185720 Apr 2 17:28:48 shrewd kernel: [66] kern_openat() at kern_openat+0x26f/frame 0xfe04621858a0 Apr 2 17:28:48 shrewd kernel: [66] amd64_syscall() at amd64_syscall+0x2c6/frame 0xfe04621859b0 Apr 2 17:28:48 shrewd kernel: [66] Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe04621859b0 Apr 2 17:28:48 shrewd kernel: [66] --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x80174cb7a, rsp = 0x7fff7f58, rbp = 0x7fff7fd0 --- -- Mark Knight ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any
ZFS panic, ARC compression?
Hi, Anyone offer any suggestions about this? kernel: panic: solaris assert: arc_decompress(buf) == 0 (0x5 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, line: 4923 kernel: cpuid = 1 kernel: KDB: stack backtrace: kernel: #0 0x80aadac7 at kdb_backtrace+0x67 kernel: #1 0x80a6bba6 at vpanic+0x186 kernel: #2 0x80a6ba13 at panic+0x43 kernel: #3 0x8248023c at assfail3+0x2c kernel: #4 0x8218e2e0 at arc_read+0x9f0 kernel: #5 0x82198e5e at dbuf_read+0x69e kernel: #6 0x821b3db4 at dnode_hold_impl+0x194 kernel: #7 0x821a11dd at dmu_bonus_hold+0x1d kernel: #8 0x8220fb05 at zfs_zget+0x65 kernel: #9 0x82227d42 at zfs_dirent_lookup+0x162 kernel: #10 0x82227e07 at zfs_dirlook+0x77 kernel: #11 0x8223fcea at zfs_lookup+0x44a kernel: #12 0x822403fd at zfs_freebsd_lookup+0x6d kernel: #13 0x8104b963 at VOP_CACHEDLOOKUP_APV+0x83 kernel: #14 0x80b13816 at vfs_cache_lookup+0xd6 kernel: #15 0x8104b853 at VOP_LOOKUP_APV+0x83 kernel: #16 0x80b1d151 at lookup+0x701 kernel: #17 0x80b1c606 at namei+0x486 Roughly 24 hours earlier (during the scrub), there was: ZFS: vdev state changed, pool_guid=11921811386284628759 vdev_guid=1644286782598989949 ZFS: vdev state changed, pool_guid=11921811386284628759 vdev_guid=17800276530669255627 % uname -a FreeBSD xxx 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40 UTC 2017 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 % % zpool status pool: zroot state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: scrub repaired 15.7M in 2h37m with 1 errors on Sun Apr 1 09:44:39 2018 config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0p4 ONLINE 0 0 0 ada1p4 ONLINE 0 0 0 errors: 1 data errors, use '-v' for a list % The affected file (in a snapshot) is unimportant. This pool is a daily rsync backup and contains about 120 snapshots. No device or SMART errors were logged. -- Bob Bishop r...@gid.co.uk ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS
On 02.04.2018 19:27, Mark Knight wrote: >> What does it show if you press "CTRL-T" to see a status of "hung" process? > > Typically CTRL-T shows [sysctl mem]. In some circumstances I can CTRL-C > (e.g. if su hangs), in others I cannot (e.g. with sudo). > >> Does it help if you comment out the line mentioning /dev/console in the >> /etc/syslog.conf >> and apply the change with killall -1 syslogd ? > > Doing that "killall -HUP syslogd" hangs with (sysctl mem) - as does > "service syslogd restart" but after a fresh reboot, no - removing that > line didn't help at all. Thanks for getting my hopes up :) > > Moving ~/myuser/.bashrc out of the way (it really doesn't contain much > apart from setting a bunch of aliases), allows me to login as myself, > but "sudo -u myuser -s" still hangs. > > I just got a truss output of "sudo -u myuser -s" per the file below, > perhaps that contains a clue? > > # sudo -u myuser -s >& sudo.truss.log > > http://www.knigma.org/scratch/sudo.truss.log > > Flipping back to a 10.3 kernel makes everything happy (just as well, as > the machine in question is my main router/firewall, so it's a right pain > when it's not working). > > Thanks in advance for any fresh ideas; I'm really not sure where to go > with this! 1. Make sure you have kernel dumps enabled. Verify that dump can be properly generated and saved after reboot using "sysctl debug.kdb.panic=1" (this produced a panic). You should have crashdump in /var/crash after reboot. 2. Rebuild kernel using new updated sources but this time add to its config file: options KDB # Enable kernel debugger support. options KDB_UNATTENDED options KDB_TRACE options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed 3. Boot new kernel using nextboot(8) and see if it will crash instead of deadlock and if so, fill the PR to Bugzilla. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS
On 02/04/2018 06:56, Eugene Grosbein wrote: What does it show if you press "CTRL-T" to see a status of "hung" process? Typically CTRL-T shows [sysctl mem]. In some circumstances I can CTRL-C (e.g. if su hangs), in others I cannot (e.g. with sudo). Does it help if you comment out the line mentioning /dev/console in the /etc/syslog.conf and apply the change with killall -1 syslogd ? Doing that "killall -HUP syslogd" hangs with (sysctl mem) - as does "service syslogd restart" but after a fresh reboot, no - removing that line didn't help at all. Thanks for getting my hopes up :) Moving ~/myuser/.bashrc out of the way (it really doesn't contain much apart from setting a bunch of aliases), allows me to login as myself, but "sudo -u myuser -s" still hangs. I just got a truss output of "sudo -u myuser -s" per the file below, perhaps that contains a clue? # sudo -u myuser -s >& sudo.truss.log http://www.knigma.org/scratch/sudo.truss.log Flipping back to a 10.3 kernel makes everything happy (just as well, as the machine in question is my main router/firewall, so it's a right pain when it's not working). Thanks in advance for any fresh ideas; I'm really not sure where to go with this! -- Mark Knight ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
