Re: sbuf-related panic
Craig Rodrigues rodr...@freebsd.org writes: On Tue, Mar 17, 2015 at 11:49 AM, Mark Felder f...@freebsd.org wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. The Jenkins build which boots a VM and runs the kyua tests is kernel panicking in sbuf as well: https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/853/console Why those builds do not contain svn revision or git commit? FreeBSD 11.0-CURRENT #26: Tue Mar 17 08:06:04 UTC 2015 jenk...@jenkins-10.freebsd.org:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/sys/GENERIC amd64 Maybe I have overlooked something, but with svn or git revision/commit bisection would be very simple. -- Nikola ___ 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: sbuf-related panic
On Tue, 2015-03-17 at 12:14 -0700, Craig Rodrigues wrote: On Tue, Mar 17, 2015 at 11:57 AM, Ian Lepore i...@freebsd.org wrote: There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. Can you run the kyua tests on your system? https://wiki.freebsd.org/201411DevAndVendorSummit?action=AttachFiledo=viewtarget=kyua_jenkins.pdf Those tests seem to be reproducibly triggering the problem. Triggering it wasn't the problem, understanding why it didn't used to fail and now it does was the tricky bit. :) It turns out it never failed before because nobody had tried to use default allocations (pointer and size zero) with sbuf_new_for_sysctl() before, and it didn't fail for me while I was testing my changes because I had commented-out INVARIANTS in my kernel config and forgotten that (doh!) so none of the assertions were actually being tested. So I fixed my test environment, then I fixed the code. Hopefully it's all better now. -- Ian ___ 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: sbuf-related panic
On Tue, Mar 17, 2015 at 5:08 PM, Ian Lepore i...@freebsd.org wrote: I had commented-out INVARIANTS in my kernel config and forgotten that (doh!) so none of the assertions were actually being tested. FYI: there is now a GENERIC-NODEBUG kernel config checked into head so you can just buildkernel/installkernel with KERNCONF=GENERIC-NODEBUG when you want to run without invariants/witness/etc. ___ 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: sbuf-related panic
On Tue, Mar 17, 2015 at 11:49 AM, Mark Felder f...@freebsd.org wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. The Jenkins build which boots a VM and runs the kyua tests is kernel panicking in sbuf as well: https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/853/console You might want to see if that build passes before updating. -- Craig ___ 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: sbuf-related panic
On Tue, 2015-03-17 at 13:49 -0500, Mark Felder wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. -- Ian ___ 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: sbuf-related panic
On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. ___ 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: sbuf-related panic
On Tue, Mar 17, 2015 at 11:57 AM, Ian Lepore i...@freebsd.org wrote: There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. Can you run the kyua tests on your system? https://wiki.freebsd.org/201411DevAndVendorSummit?action=AttachFiledo=viewtarget=kyua_jenkins.pdf Those tests seem to be reproducibly triggering the problem. -- Craig ___ 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: sbuf-related panic
On Tue, 2015-03-17 at 14:14 -0500, Mark Felder wrote: On Tue, Mar 17, 2015, at 13:57, Ian Lepore wrote: On Tue, 2015-03-17 at 13:49 -0500, Mark Felder wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. Is the previous snapshot -- r279813 -- old enough to have missed the related changes? I'm just trying to get a machine up from 10.1-RELEASE to relatively CURRENT quickly. That should be safe, my series of sbuf changes that broke things started at r279992. -- Ian ___ 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: sbuf-related panic
On Tue, Mar 17, 2015, at 13:57, Ian Lepore wrote: On Tue, 2015-03-17 at 13:49 -0500, Mark Felder wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. Is the previous snapshot -- r279813 -- old enough to have missed the related changes? I'm just trying to get a machine up from 10.1-RELEASE to relatively CURRENT quickly. ___ 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
sbuf-related panic
On amd64, doing a Poudriere run. On r280133: (kgdb) bt #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 ) at pcpu.h:219 #1 0x809726a5 in kern_reboot (howto=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0x80972c98 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:747 #3 0x80972ac2 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:635 #4 0x809bd5bd in sbuf_delete (s=0xfe085d468750) at /usr/src/sys/kern/subr_sbuf.c:103 #5 0x809669dd in sysctl_kern_proc_args (oidp=value optimized out, arg1=value optimized out, arg2=value optimized out, req=0xfe085d468868) at /usr/src/sys/kern/kern_proc.c:1858 #6 0x8097e7b4 in sysctl_root_handler_locked (oid=0x81533738, arg1=0xfe085d46893c, arg2=1, req=0xfe085d468868) at /usr/src/sys/kern/kern_sysctl.c:183 #7 0x8097e038 in sysctl_root (arg1=value optimized out, arg2=value optimized out) at /usr/src/sys/kern/kern_sysctl.c:1660 #8 0x8097e5b2 in userland_sysctl (td=value optimized out, name=0xfe085d468930, namelen=value optimized out, old=value optimized out, oldlenp=value optimized out, inkernel=value optimized out, new=value optimized out, newlen=value optimized out, retval=value optimized out, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1764 #9 0x8097e3e4 in sys___sysctl (td=0xf802521324b0, uap=0xfe085d468a40) at /usr/src/sys/kern/kern_sysctl.c:1690 #10 0x80da1bca in amd64_syscall (td=0xf802521324b0, traced=0) at subr_syscall.c:133 #11 0x80d7f3cb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #12 0x02759e502b7a in ?? () signature.asc Description: This is a digitally signed message part
Re: sbuf-related panic
On Mon, 2015-03-16 at 14:03 -0400, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: (kgdb) bt #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 ) at pcpu.h:219 #1 0x809726a5 in kern_reboot (howto=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0x80972c98 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:747 #3 0x80972ac2 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:635 #4 0x809bd5bd in sbuf_delete (s=0xfe085d468750) at /usr/src/sys/kern/subr_sbuf.c:103 #5 0x809669dd in sysctl_kern_proc_args (oidp=value optimized out, arg1=value optimized out, arg2=value optimized out, req=0xfe085d468868) at /usr/src/sys/kern/kern_proc.c:1858 #6 0x8097e7b4 in sysctl_root_handler_locked (oid=0x81533738, arg1=0xfe085d46893c, arg2=1, req=0xfe085d468868) at /usr/src/sys/kern/kern_sysctl.c:183 #7 0x8097e038 in sysctl_root (arg1=value optimized out, arg2=value optimized out) at /usr/src/sys/kern/kern_sysctl.c:1660 #8 0x8097e5b2 in userland_sysctl (td=value optimized out, name=0xfe085d468930, namelen=value optimized out, old=value optimized out, oldlenp=value optimized out, inkernel=value optimized out, new=value optimized out, newlen=value optimized out, retval=value optimized out, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1764 #9 0x8097e3e4 in sys___sysctl (td=0xf802521324b0, uap=0xfe085d468a40) at /usr/src/sys/kern/kern_sysctl.c:1690 #10 0x80da1bca in amd64_syscall (td=0xf802521324b0, traced=0) at subr_syscall.c:133 #11 0x80d7f3cb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #12 0x02759e502b7a in ?? () That one should be fixed in r280149, sorry about that. For some reason I never hit the triggering condition in testing, but it seems that just about everyone else in the world did. :/ There are a couple locking-related fixes still needed which might trigger a witness warning, they should be fixed soon as well. -- Ian ___ 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: sbuf-related panic
On Mar 16, 2015, at 14:03, Shawn Webb shawn.w...@hardenedbsd.org wrote: On amd64, doing a Poudriere run. On r280133: (kgdb) bt #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 ) at pcpu.h:219 #1 0x809726a5 in kern_reboot (howto=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0x80972c98 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:747 #3 0x80972ac2 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:635 #4 0x809bd5bd in sbuf_delete (s=0xfe085d468750) at /usr/src/sys/kern/subr_sbuf.c:103 #5 0x809669dd in sysctl_kern_proc_args (oidp=value optimized out, arg1=value optimized out, arg2=value optimized out, req=0xfe085d468868) at /usr/src/sys/kern/kern_proc.c:1858 #6 0x8097e7b4 in sysctl_root_handler_locked (oid=0x81533738, arg1=0xfe085d46893c, arg2=1, req=0xfe085d468868) at /usr/src/sys/kern/kern_sysctl.c:183 #7 0x8097e038 in sysctl_root (arg1=value optimized out, arg2=value optimized out) at /usr/src/sys/kern/kern_sysctl.c:1660 #8 0x8097e5b2 in userland_sysctl (td=value optimized out, name=0xfe085d468930, namelen=value optimized out, old=value optimized out, oldlenp=value optimized out, inkernel=value optimized out, new=value optimized out, newlen=value optimized out, retval=value optimized out, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1764 #9 0x8097e3e4 in sys___sysctl (td=0xf802521324b0, uap=0xfe085d468a40) at /usr/src/sys/kern/kern_sysctl.c:1690 #10 0x80da1bca in amd64_syscall (td=0xf802521324b0, traced=0) at subr_syscall.c:133 #11 0x80d7f3cb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #12 0x02759e502b7a in ?? () Ian's working on a few issues that have been reported to him by jhb, kib, and a few others. ___ 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
