Re: LOR panic on mount -uw
On Wed, Oct 11, 2017 at 5:18 PM, grarpamp wrote: > Let 12.0-current r324306 amd64 efi boot from usb to installer screen, Another way to trigger this one is boot snapshot install media single user verbose mdmfs -s 10m md /mnt umount -v /mnt [LOR stack backtrace, remains usable] ___ 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: LOR panic on mount -uw
On Thu, Oct 12, 2017 at 11:15 AM, John Baldwin wrote: > In this case the panic is separate from the LOR, and > for a panic we really > need the panic message in addition to the stack trace. With release kernels stack trace appears with this message, then it sits in ddb, forget how to print panic? panic: access but not attached With snapshots, both panic and stacktrace print but it doesn't ddb and goes straight to reboot. I forget how to make those enter ddb or 15sec countdown? In interim.. fatal trap 12 page fault while in kernel mode supervosor read data page not present process = mount I did file a ticket with script so anyone with a blank usb stick can recreate locally. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222948 ___ 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"
@r324591: panic: UNR inconsistency: items 0 found 7 (line 361)
This occurred after I had booted & smoke-tested my laptop, then issued "sudo shutdown -r now"; it's *possible* that there was also a (similar?) problem shutting down yesterday (@r324542), but the screen had gone dark and declined to shed any light, so I'm not sure on that point. uname strings (yesterday & today): FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #429 r324542M/324546:1200051: Thu Oct 12 05:09:28 PDT 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #430 r324591M/324591:1200051: Fri Oct 13 03:58:11 PDT 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 Panic message, kernel buffer & stack trace from today: panic: UNR inconsistency: items 0 found 7 (line 361) Unread portion of the kernel message buffer: <118>Writing entropy file:. <118>Writing early boot entropy file:. <118>. <118>Terminated <118>Oct 13 11:09:19 g1-252 syslogd: exiting on signal 15 <5>wlan0: link state changed to DOWN Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `bufdaemon' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 10 9 9 5 2 2 1 1 1 0 0 0 0 0 done All buffers synced. lock order reversal: 1st 0xf8000efdd5f0 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1274 2nd 0xf8000efdd068 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2768 stack backtrace: #0 0x80a95693 at witness_debugger+0x73 #1 0x80a95512 at witness_checkorder+0xe02 #2 0x80a07e9e at lockmgr_lock_fast_path+0x1ae #3 0x80fb2c20 at VOP_LOCK1_APV+0xe0 #4 0x80b0ed26 at _vn_lock+0x66 #5 0x80afdfd6 at vputx+0x156 #6 0x80af5a38 at dounmount+0x4d8 #7 0x80aff75b at vfs_unmountall+0x6b #8 0x80adb6a3 at bufshutdown+0x393 #9 0x80a31b49 at kern_reboot+0x189 #10 0x80a31964 at sys_reboot+0x3c4 #11 0x80e4ab5b at amd64_syscall+0x7ab #12 0x80e29b5b at Xfast_syscall+0xfb lock order reversal: 1st 0xf8000efde7c8 devfs (devfs) @ /usr/src/sys/kern/vfs_mount.c:1274 2nd 0xf8000efde240 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2768 stack backtrace: #0 0x80a95693 at witness_debugger+0x73 #1 0x80a95512 at witness_checkorder+0xe02 #2 0x80a07e9e at lockmgr_lock_fast_path+0x1ae #3 0x80fb2c20 at VOP_LOCK1_APV+0xe0 #4 0x80b0ed26 at _vn_lock+0x66 #5 0x80afdfd6 at vputx+0x156 #6 0x80af5a38 at dounmount+0x4d8 #7 0x80aff75b at vfs_unmountall+0x6b #8 0x80adb6a3 at bufshutdown+0x393 #9 0x80a31b49 at kern_reboot+0x189 #10 0x80a31964 at sys_reboot+0x3c4 #11 0x80e4ab5b at amd64_syscall+0x7ab #12 0x80e29b5b at Xfast_syscall+0xfb lock order reversal: 1st 0xf8000ee3b7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1274 2nd 0xf8000ee3bd50 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1414 stack backtrace: #0 0x80a95693 at witness_debugger+0x73 #1 0x80a95512 at witness_checkorder+0xe02 #2 0x80a07e9e at lockmgr_lock_fast_path+0x1ae #3 0x80fb2c20 at VOP_LOCK1_APV+0xe0 #4 0x80b0ed26 at _vn_lock+0x66 #5 0x80d3c5f3 at ffs_flushfiles+0x93 #6 0x80d1fef2 at softdep_flushfiles+0x82 #7 0x80d3ebc7 at ffs_unmount+0x77 #8 0x80af5a78 at dounmount+0x518 #9 0x80aff75b at vfs_unmountall+0x6b #10 0x80adb6a3 at bufshutdown+0x393 #11 0x80a31b49 at kern_reboot+0x189 #12 0x80a31964 at sys_reboot+0x3c4 #13 0x80e4ab5b at amd64_syscall+0x7ab #14 0x80e29b5b at Xfast_syscall+0xfb panic: UNR inconsistency: items 0 found 7 (line 361) cpuid = 0 time = 1507892985 KDB: stack backtrace: db_trace_self_wrapper() at 0x803a762b = db_trace_self_wrapper+0x2b/frame 0xfe0ba17c0620 vpanic() at 0x80a3234c = vpanic+0x19c/frame 0xfe0ba17c06a0 kassert_panic() at 0x80a321a6 = kassert_panic+0x126/frame 0xfe0ba17c0710 check_unrhdr() at 0x80a8ea10 = check_unrhdr+0x230/frame 0xfe0ba17c0760 delete_unrhdr() at 0x80a8eb13 = delete_unrhdr+0x13/frame 0xfe0ba17c0780 tmpfs_free_tmp() at 0x83214a4f = tmpfs_free_tmp+0x6f/frame 0xfe0ba17c07a0 tmpfs_unmount() at 0x832152b0 = tmpfs_unmount+0x1f0/frame 0xfe0ba17c07f0 dounmount() at 0x80af5a78 = dounmount+0x518/frame 0xfe0ba17c0860 vfs_unmountall() at 0x80aff75b = vfs_unmountall+0x6b/frame 0xfe0ba17c0890 bufshutdown() at 0x80adb6a3 = bufshutdown+0x393/frame 0xfe0ba17c08e0 kern_reboot() at 0x80a31b49 = kern_reboot+0x189/frame 0xfe0ba17c0920 sys_reboot() at 0x80a31964 = sys_reboot+0x3c4/frame 0xfe0ba17c0980 amd64_syscall() at 0x80e4ab5b = amd64_syscall+0x7ab/frame 0xfe0ba17c0ab0 Xfast_syscall() at 0x80e29b5b = Xfast_syscall+0xfb/fr
Re: @r324591: panic: UNR inconsistency: items 0 found 7 (line 361)
On Fri, Oct 13, 2017 at 04:36:34AM -0700, David Wolfskill wrote: > This occurred after I had booted & smoke-tested my laptop, then > issued "sudo shutdown -r now"; it's *possible* that there was also > a (similar?) problem shutting down yesterday (@r324542), but the > screen had gone dark and declined to shed any light, so I'm not > sure on that point. > > uname strings (yesterday & today): > > FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #429 > r324542M/324546:1200051: Thu Oct 12 05:09:28 PDT 2017 > r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #430 > r324591M/324591:1200051: Fri Oct 13 03:58:11 PDT 2017 > r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > Panic message, kernel buffer & stack trace from today: > > panic: UNR inconsistency: items 0 found 7 (line 361) > Revert r324542 and try again. This revision was not tested with DIAGNOSTIC enabled. ___ 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: @r324591: panic: UNR inconsistency: items 0 found 7 (line 361)
On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote: > ... > > panic: UNR inconsistency: items 0 found 7 (line 361) > > > Revert r324542 and try again. Will do; but I have a few things to get done first, so it may be an hour or so before I can report results. > This revision was not tested with DIAGNOSTIC enabled. Until ... recently, eh? :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Unsubstantiated claims of "Fake News" are evidence that the claimant lies again. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: @r324591: panic: UNR inconsistency: items 0 found 7 (line 361)
On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote: > ... > > panic: UNR inconsistency: items 0 found 7 (line 361) > > > Revert r324542 and try again. > > This revision was not tested with DIAGNOSTIC enabled. OK; I believe we have a winner! Thanks! :-) I copied the head slice from slice 4 to slice 3, used svn merge -c -r324542 ^/head to revert the commit, then booted from slice 3, re-built & installed the kernel. For *that* reboot, I (again) had the screen go dark & unresponsive; typing "reset" (blindly) brought the machine back up. (The file systems had been unmounted cleanly before the panicearlier.) I then rebooted again (now that the new kernel was in place), and there was no issue -- the laptop rebooted normally. Thanks again! Peace, david -- David H. Wolfskill da...@catwhisker.org Unsubstantiated claims of "Fake News" are evidence that the claimant lies again. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: RFC how to use kernel procs/threads efficiently
On 10/10/17 8:33 pm, Rick Macklem wrote: Julian Elischer wrote: [stuff snipped] On 10/10/17 4:25 am, Rick Macklem wrote: --> As such, having a fixed reasonable # of threads is probably the best that can be done. - The current patch has the # of threads as a sysctl with a default of 32. why not set it to ncpu or something? Well, each of these threads will do an RPC, which means a couple of short bursts of CPU and then sleep the rest of the time waiting for the RPC reply to come back from the Data Server. As such, it would seem to me that you would want a lot more threads than CPUs on the machine? However, setting the default to "N * ncpu" seems better than just a fixed "32" to me. (For nfsd, the current default is 8 * ncpu, so maybe that is a good default for this too?) yeah I really just meant "some function of ncpu".. not specifically "ncpu x 1" What do you think? Thanks for the comment, rick ___ 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: @r324591: panic: UNR inconsistency: items 0 found 7 (line 361)
On 10/13/2017 05:33, David Wolfskill wrote: > On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote: >> ... >>> panic: UNR inconsistency: items 0 found 7 (line 361) >>> >> Revert r324542 and try again. >> >> This revision was not tested with DIAGNOSTIC enabled. > OK; I believe we have a winner! Thanks! :-) In that revision I neglected to zero the "first" field of the unrhdr. Sorry about that. I also inadvertently wasn't testing with DIAGNOSTIC on. I will commit a fix. Matt ___ 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: @r324591: panic: UNR inconsistency: items 0 found 7 (line 361)
On Fri, Oct 13, 2017 at 08:48:11AM -0700, Matt Joras wrote: > On 10/13/2017 05:33, David Wolfskill wrote: > > On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote: > >> ... > >>> panic: UNR inconsistency: items 0 found 7 (line 361) > >>> > >> Revert r324542 and try again. > >> > >> This revision was not tested with DIAGNOSTIC enabled. > > OK; I believe we have a winner! Thanks! :-) > > In that revision I neglected to zero the "first" field of the unrhdr. > Sorry about that. I also inadvertently wasn't testing with DIAGNOSTIC > on. I will commit a fix. Cool -- and I'll proceed with building & smoke-testing, as usual. :-) (Next attempt: tomorrow morning.) And yeah -- stuff happens; we're (each) human. :-) > Matt Peace, david -- David H. Wolfskill da...@catwhisker.org Unsubstantiated claims of "Fake News" are evidence that the claimant lies again. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
