[no subject]
I started some ports to compile inside a bhyve instance: root@vm:~ # uname -a FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r259250: Thu Dec 12 14:17:32 EET 2013 r...@vm.mkushnir.zapto.org:/ usr/obj/usr/src.svnup/sys/MAREK amd64 and left it running unattended. Approx. 2 hours later the host went to panic. The bhyve instance survived after the panic and I could be able to complete my ports compilation. core.txt attached (gzipped) ___ 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
11.0-CURRENT panic while running a bhyve instance
Forgot to fill the Subject: header, re-posting it fixed. -- Markiyan -- Forwarded message -- From: Markiyan Kushnir markiyan.kush...@gmail.com Date: 2013/12/13 Subject: To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org I started some ports to compile inside a bhyve instance: root@vm:~ # uname -a FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r259250: Thu Dec 12 14:17:32 EET 2013 r...@vm.mkushnir.zapto.org:/ usr/obj/usr/src.svnup/sys/MAREK amd64 and left it running unattended. Approx. 2 hours later the host went to panic. The bhyve instance survived after the panic and I could be able to complete my ports compilation. core.txt attached (gzipped) ___ 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: vt-enabled 11.0-CURRENT + radeonkms boot load = direct rendering disabled in X
On 10.12.2013 12:21, Markiyan Kushnir wrote: Hello, Hi! First, a quick note: freebsd-current@ and current@ are the same list. There seems to be a difference in how Xorg server can use direct rendering depending when radeonkms.ko was loaded: at boot time vs. at a later time (but not necessarily at X startup time). The difference is that direct rendering could not be enabled for X in the former case. In the latter case, direct rendering was successfully enabled. The problem is that if you load radeonkms from the loader or you build it into your kernel, it can't load the relevant firmware(s): error: [drm:pid0:r600_init_microcode] *ERROR* r600_cp: Failed to load firmware radeonkmsfw_RV710_pfp error: [drm:pid0:rv770_startup] *ERROR* Failed to load firmware! This is because /boot isn't available at the time the card is initialized: / is not mounted yet. The solution is to load firmware(s) from the loader too (or build them into the kernel). To know which firmware(s) are used by your card, you can boot without radeonkms, kldload it after the computer booted, and run: kldstat | grep radeonkmsfw -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: libc++ vs. libstdc++ usage in the ports tree
Please commit (Approved by: portmgr(bapt)) if needed regards, Bapt On Sun, Dec 01, 2013 at 03:06:40PM +0100, Tijl Coosemans wrote: On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. I have a preliminary patch for math/octave that I wanted to test on redports first, but it is down at the moment so here it is. The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. Index: math/octave/Makefile === --- math/octave/Makefile (revision 335379) +++ math/octave/Makefile (working copy) @@ -3,7 +3,7 @@ PORTNAME=octave PORTVERSION= 3.6.4 -PORTREVISION=6 +PORTREVISION=7 CATEGORIES= math MASTER_SITES=ftp://ftp.gnu.org/gnu/octave/ \ ftp://ftp.u-aizu.ac.jp/pub/SciEng/numanal/Octave/bleeding-edge/ @@ -32,7 +32,7 @@ LIB_DEPENDS=GraphicsMagick:${PORTSDIR}/ umfpack.1:${PORTSDIR}/math/suitesparse \ glpk:${PORTSDIR}/math/glpk -USES=charsetfix gmake perl5 pkgconfig +USES=charsetfix fortran gmake perl5 pkgconfig USE_BZIP2= yes USE_PERL5= build USE_TEX= dvipsk:build @@ -74,8 +74,6 @@ BLAS= -lptf77blas LAPACK= -lalapack -lptcblas .endif -USE_FORTRAN= yes - OCTAVE_VERSION= ${PORTVERSION} GNU_HOST=${ARCH}-portbld-freebsd${OSREL} PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} GNU_HOST=${GNU_HOST} @@ -140,7 +138,8 @@ post-install: ${ECHO_CMD} @dirrm share/octave ${WRKDIR}/PLIST cd ${WRKDIR} ; ${SED} -i -e /PLIST/ r PLIST ${TMPPLIST} -check: +check: regression-test +regression-test: build (cd ${WRKSRC}; ${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_ARGS} check) .include bsd.port.post.mk Index: math/octave/files/patch-configure === --- math/octave/files/patch-configure (revision 0) +++ math/octave/files/patch-configure (working copy) @@ -0,0 +1,11 @@ +--- configure.orig 2013-02-21 21:21:49.0 +0100 configure2013-11-22 20:34:49.0 +0100 +@@ -58248,7 +58248,7 @@ + main () + { + +- std::unordered_map m; ++ std::unordered_mapint, int m; + + ; + return 0; Property changes on: math/octave/files/patch-configure ___ Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: math/octave/files/patch-libgnu-math.in.h === --- math/octave/files/patch-libgnu-math.in.h (revision 0) +++ math/octave/files/patch-libgnu-math.in.h (working copy) @@ -0,0 +1,11 @@ +--- libgnu/math.in.h.orig2013-02-21 21:21:17.0 +0100 libgnu/math.in.h 2013-11-22 12:35:47.0 +0100 +@@ -17,7 +17,7 @@ +You should have received a copy of the GNU General Public License +along with this program. If not, see http://www.gnu.org/licenses/. */ + +-#ifndef _@GUARD_PREFIX@_MATH_H ++#if 1 + + #if __GNUC__ = 3 + @PRAGMA_SYSTEM_HEADER@ Property changes on: math/octave/files/patch-libgnu-math.in.h ___ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: math/octave/files/patch-liboctave-eigs-base.cc === ---
Re: libc++ vs. libstdc++ usage in the ports tree
Hi all Does anybody please commit the patch? My FreeBSD machine is down due to power outage for next week. Also I'll be very busy in the next week. Best, Nakata Maho From: Steve Kargl s...@troutmask.apl.washington.edu Subject: Re: libc++ vs. libstdc++ usage in the ports tree Date: Thu, 12 Dec 2013 17:12:04 -0800 On Sun, Dec 01, 2013 at 03:06:40PM +0100, Tijl Coosemans wrote: On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. I have a preliminary patch for math/octave that I wanted to test on redports first, but it is down at the moment so here it is. The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. -- Steve ___ 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: libc++ vs. libstdc++ usage in the ports tree
On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. Committed in r336344. ___ 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
[SOLVED]Re: vt-enabled 11.0-CURRENT + radeonkms boot load = direct rendering disabled in X
2013/12/13 Jean-Sébastien Pédron dumbb...@freebsd.org: On 10.12.2013 12:21, Markiyan Kushnir wrote: Hello, Hi! First, a quick note: freebsd-current@ and current@ are the same list. thanks, I will know now. There seems to be a difference in how Xorg server can use direct rendering depending when radeonkms.ko was loaded: at boot time vs. at a later time (but not necessarily at X startup time). The difference is that direct rendering could not be enabled for X in the former case. In the latter case, direct rendering was successfully enabled. The problem is that if you load radeonkms from the loader or you build it into your kernel, it can't load the relevant firmware(s): error: [drm:pid0:r600_init_microcode] *ERROR* r600_cp: Failed to load firmware radeonkmsfw_RV710_pfp error: [drm:pid0:rv770_startup] *ERROR* Failed to load firmware! This is because /boot isn't available at the time the card is initialized: / is not mounted yet. The solution is to load firmware(s) from the loader too (or build them into the kernel). To know which firmware(s) are used by your card, you can boot without radeonkms, kldload it after the computer booted, and run: kldstat | grep radeonkmsfw yes, it turns out that the issue was logged in dmesg, and I should have noticed it. Thanks agian, Jean-Sébastien -- Markiyan. -- Jean-Sébastien Pédron ___ 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: libc++ vs. libstdc++ usage in the ports tree
On 12/13/2013 14:47, Tijl Coosemans wrote: On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. Committed in r336344. Thank you! Is it exactly the same as you attached here: http://lists.freebsd.org/pipermail/freebsd-current/2013-December/046986.html Or should I rebuild on my machines? Cheers, Jan Henrik ___ 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: libc++ vs. libstdc++ usage in the ports tree
On Fri, 13 Dec 2013 15:49:19 +0100 Jan Henrik Sylvester wrote: On 12/13/2013 14:47, Tijl Coosemans wrote: On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. Committed in r336344. Thank you! Is it exactly the same as you attached here: http://lists.freebsd.org/pipermail/freebsd-current/2013-December/046986.html Or should I rebuild on my machines? If you applied the patch to a subversion checkout you may get a conflict on Mk/Uses/fortran.mk and math/octave/Makefile when updating which you can resolve using the 'tf' option (theirs-full). Besides that the patches are functionally the same so you don't have to rebuild anything. ___ 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: vt-enabled 11.0-CURRENT + radeonkms boot load = direct rendering disabled in X
Are you able to make it do delayed firmware loading? Adrian On Dec 13, 2013 3:23 AM, Jean-Sébastien Pédron dumbb...@freebsd.org wrote: On 10.12.2013 12:21, Markiyan Kushnir wrote: Hello, Hi! First, a quick note: freebsd-current@ and current@ are the same list. There seems to be a difference in how Xorg server can use direct rendering depending when radeonkms.ko was loaded: at boot time vs. at a later time (but not necessarily at X startup time). The difference is that direct rendering could not be enabled for X in the former case. In the latter case, direct rendering was successfully enabled. The problem is that if you load radeonkms from the loader or you build it into your kernel, it can't load the relevant firmware(s): error: [drm:pid0:r600_init_microcode] *ERROR* r600_cp: Failed to load firmware radeonkmsfw_RV710_pfp error: [drm:pid0:rv770_startup] *ERROR* Failed to load firmware! This is because /boot isn't available at the time the card is initialized: / is not mounted yet. The solution is to load firmware(s) from the loader too (or build them into the kernel). To know which firmware(s) are used by your card, you can boot without radeonkms, kldload it after the computer booted, and run: kldstat | grep radeonkmsfw -- Jean-Sébastien Pédron ___ 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: vt-enabled 11.0-CURRENT + radeonkms boot load = direct rendering disabled in X
Le 13/12/2013 19:24, Adrian Chadd a écrit : Are you able to make it do delayed firmware loading? Delayed until / is mounted? In this case, doesn't loading radeonkms from rc.conf achieve the same result? Firmwares are loaded early during card initialization. -- Jean-Sébastien Pédron ___ 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: libc++ vs. libstdc++ usage in the ports tree
On Fri, Dec 13, 2013 at 02:47:23PM +0100, Tijl Coosemans wrote: On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. Committed in r336344. Thank you!!! Doing a 'pkg delete -fR' on all installed ports except pkg, pkg, and portmaster, of course, removed everything but those 3 ports. % portmaster math/octave causes 208 ports to be built and installed. The resulting octave now functions. -- Steve ___ 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: r259072 is not a happy camper...
In message 201312091216.04052@freebsd.org, John Baldwin writes: On Saturday, December 07, 2013 2:32:56 pm Poul-Henning Kamp wrote: kdb_backtrace() at kdb_backtrace+0x39/frampanic: bad stray interrupt cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe011120e9e0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011120ea90 vpanic() at vpanic+0x126/frame 0xfe011120ead0 kassert_panic() at kassert_panic+0x136/frame 0xfe011120eb40 intr_event_handle() at intr_event_handle+0x11d/frame 0xfe011120eb90 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe011120ebc0 lapic_handle_intr() at lapic_handle_intr+0x73/frame 0xfe011120ebf0 Xapic_isr1() at Xapic_isr1+0xa4/frame 0xfe011120ebf0 --- interrupt, rip = 0x11f7b11, rsp = 0x7fff8b50, rbp = 0x7fff8b80 --- KDB: enter: panic [ thread pid 72149 tid 100102 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db Hmmm. Maybe do 'show lapic' and 'show apic' in ddb and paste that here? sorry about the delay... db show lapic lapic ID = 2 version = 1.0 max LVT = 5 SVR = ff (enabled) TPR = 00 In-service Interrupts: TMR Interrupts: IRR Interrupts: irr1: 30 irr7: f9 db show apic Interrupts bound to lapic 0 vec 0x31 - IRQ 0 vec 0x32 - IRQ 8 vec 0x33 - IRQ 256 vec 0x34 - IRQ 257 vec 0x35 - IRQ 258 vec 0x36 - IRQ 259 vec 0x3b - IRQ 264 vec 0x40 - IRQ 269 vec 0x42 - IRQ 16 vec 0x48 - IRQ 21 vec 0x4a - IRQ 7 vec 0xef - lapic timer Interrupts bound to lapic 1 vec 0x30 - IRQ 1 vec 0x31 - IRQ 9 vec 0x32 - IRQ 17 vec 0x33 - IRQ 22 vec 0x34 - IRQ 260 vec 0x35 - IRQ 265 vec 0xef - lapic timer Interrupts bound to lapic 2 vec 0x30 - IRQ 4 vec 0x31 - IRQ 14 vec 0x32 - IRQ 18 vec 0x33 - IRQ 261 vec 0x34 - IRQ 263 vec 0x35 - IRQ 266 vec 0xef - lapic timer Interrupts bound to lapic 3 vec 0x30 - IRQ 6 vec 0x31 - IRQ 15 vec 0x32 - IRQ 19 vec 0x33 - IRQ 262 vec 0x34 - IRQ 267 vec 0x35 - IRQ 268 vec 0xef - lapic timer -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: 11.0-CURRENT panic while running a bhyve instance
On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote: Forgot to fill the Subject: header, re-posting it fixed. The mailing lists strips attachments, can you post it at a URL? -- Markiyan -- Forwarded message -- From: Markiyan Kushnir markiyan.kush...@gmail.com Date: 2013/12/13 Subject: To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org I started some ports to compile inside a bhyve instance: root@vm:~ # uname -a FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r259250: Thu Dec 12 14:17:32 EET 2013 r...@vm.mkushnir.zapto.org:/ usr/obj/usr/src.svnup/sys/MAREK amd64 and left it running unattended. Approx. 2 hours later the host went to panic. The bhyve instance survived after the panic and I could be able to complete my ports compilation. core.txt attached (gzipped) ___ 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 -- 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
kasserts behind invariants
I guess this may have been argued before, but I don't see why we would want to hide specific things like: sys/kern/subr_lock.c /* Check for double-init and zero object. */ KASSERT(!lock_initalized(lock), (lock \%s\ %p already initialized, name, lock)); If I hadn't completely missed the fact that I had INVARIANTS activated, I'd never have found out why this vendor driver was being so completely stupid and crashing my machine. If I find things like this that I want old KASSERT behavior on (panic if true) and I don't want to run INVARIANTS, is that possible? sean ___ 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: r259072 is not a happy camper...
On Friday, December 13, 2013 3:36:37 pm Poul-Henning Kamp wrote: In message 201312091216.04052@freebsd.org, John Baldwin writes: On Saturday, December 07, 2013 2:32:56 pm Poul-Henning Kamp wrote: kdb_backtrace() at kdb_backtrace+0x39/frampanic: bad stray interrupt cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe011120e9e0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011120ea90 vpanic() at vpanic+0x126/frame 0xfe011120ead0 kassert_panic() at kassert_panic+0x136/frame 0xfe011120eb40 intr_event_handle() at intr_event_handle+0x11d/frame 0xfe011120eb90 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe011120ebc0 lapic_handle_intr() at lapic_handle_intr+0x73/frame 0xfe011120ebf0 Xapic_isr1() at Xapic_isr1+0xa4/frame 0xfe011120ebf0 --- interrupt, rip = 0x11f7b11, rsp = 0x7fff8b50, rbp = 0x7fff8b80 --- KDB: enter: panic [ thread pid 72149 tid 100102 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db Hmmm. Maybe do 'show lapic' and 'show apic' in ddb and paste that here? sorry about the delay... db show lapic lapic ID = 2 version = 1.0 max LVT = 5 SVR = ff (enabled) TPR = 00 In-service Interrupts: Hmm, this is empty. It should not be empty. :( Never the less, the panic is further down than I thought it was. The system thinks it had a valid IRQ that required an ithread to be scheduled, but when it went to schedule the ithread, there was no thread to schedule: static int intr_event_schedule_thread(struct intr_event *ie) { struct intr_entropy entropy; struct intr_thread *it; struct thread *td; struct thread *ctd; struct proc *p; /* * If no ithread or no handlers, then we have a stray interrupt. */ if (ie == NULL || TAILQ_EMPTY(ie-ie_handlers) || ie-ie_thread == NULL) return (EINVAL); Does it get a crashdump if you try? -- 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: 11.0-CURRENT panic while running a bhyve instance
2013/12/13 John Baldwin j...@freebsd.org: On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote: Forgot to fill the Subject: header, re-posting it fixed. The mailing lists strips attachments, can you post it at a URL? Shared here: https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing -- Markiyan. -- Markiyan -- Forwarded message -- From: Markiyan Kushnir markiyan.kush...@gmail.com Date: 2013/12/13 Subject: To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org I started some ports to compile inside a bhyve instance: root@vm:~ # uname -a FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r259250: Thu Dec 12 14:17:32 EET 2013 r...@vm.mkushnir.zapto.org:/ usr/obj/usr/src.svnup/sys/MAREK amd64 and left it running unattended. Approx. 2 hours later the host went to panic. The bhyve instance survived after the panic and I could be able to complete my ports compilation. core.txt attached (gzipped) ___ 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 -- 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: kasserts behind invariants
On 12/13/13 1:50 PM, Sean Bruno wrote: I guess this may have been argued before, but I don't see why we would want to hide specific things like: sys/kern/subr_lock.c /* Check for double-init and zero object. */ KASSERT(!lock_initalized(lock), (lock \%s\ %p already initialized, name, lock)); If I hadn't completely missed the fact that I had INVARIANTS activated, I'd never have found out why this vendor driver was being so completely stupid and crashing my machine. If I find things like this that I want old KASSERT behavior on (panic if true) and I don't want to run INVARIANTS, is that possible? I don't understand the question, do you want to move it from INVARIANTS to under just a plain if(condition)? -Alfred ___ 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: kasserts behind invariants
On Fri, 2013-12-13 at 14:43 -0800, Alfred Perlstein wrote: On 12/13/13 1:50 PM, Sean Bruno wrote: I guess this may have been argued before, but I don't see why we would want to hide specific things like: sys/kern/subr_lock.c /* Check for double-init and zero object. */ KASSERT(!lock_initalized(lock), (lock \%s\ %p already initialized, name, lock)); If I hadn't completely missed the fact that I had INVARIANTS activated, I'd never have found out why this vendor driver was being so completely stupid and crashing my machine. If I find things like this that I want old KASSERT behavior on (panic if true) and I don't want to run INVARIANTS, is that possible? I don't understand the question, do you want to move it from INVARIANTS to under just a plain if(condition)? -Alfred ___ In this specific instance, it would have been much better to simply panic if(condition) than silently allowing the vendor driver to do something stupid like initialize a mutex twice. sean ___ 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: 11.0-CURRENT panic while running a bhyve instance
Hi Markiyan, On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir markiyan.kush...@gmail.com wrote: 2013/12/13 John Baldwin j...@freebsd.org: On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote: Forgot to fill the Subject: header, re-posting it fixed. The mailing lists strips attachments, can you post it at a URL? Shared here: https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing Thanks. It looks like something funky going on with the vcpu state. Do you know if there was any access to the VM via 'bhyvectl' close to the time of the panic? best Neel -- Markiyan. -- Markiyan -- Forwarded message -- From: Markiyan Kushnir markiyan.kush...@gmail.com Date: 2013/12/13 Subject: To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org I started some ports to compile inside a bhyve instance: root@vm:~ # uname -a FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r259250: Thu Dec 12 14:17:32 EET 2013 r...@vm.mkushnir.zapto.org:/ usr/obj/usr/src.svnup/sys/MAREK amd64 and left it running unattended. Approx. 2 hours later the host went to panic. The bhyve instance survived after the panic and I could be able to complete my ports compilation. core.txt attached (gzipped) ___ 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 -- 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 ___ 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: libc++ vs. libstdc++ usage in the ports tree
Many thanks! From: Tijl Coosemans t...@freebsd.org Subject: Re: libc++ vs. libstdc++ usage in the ports tree Date: Fri, 13 Dec 2013 14:47:23 +0100 On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. Committed in r336344. ___ 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: kasserts behind invariants
on 14/12/2013 01:05 Sean Bruno said the following: In this specific instance, it would have been much better to simply panic if(condition) than silently allowing the vendor driver to do something stupid like initialize a mutex twice. I like Solaris/illumos approach of having ASSERT and VERIFY macros. ASSERT is compiled out when DEBUG is not set while VERIFY is always kept. -- Andriy Gapon ___ 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: boot failure after upgrade to HEAD from svn: zfs i/o error - all block copies unavailable invalid format
Now , I'm recovery my OS. I installed freebsd11 on a new disk ,and copy every thing to it. 2013/12/12 乔楚 honestq...@gmail.com Have you updated bootcode then? After make installkernel make installworld reboot, boot error. Yes ,I can import in -currentr258961( http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20131205-r258961-memstick.img ). Now, I install -currentr258961 on an new disk, and copy every from old disk to new disk. 2013/12/12 Volodymyr Kostyrko c.kw...@gmail.com 10.12.2013 18:59, 乔楚 wrote: *Today, after **upgrade to HEAD from svn, My FreeBSD can't boot.* *Error message:* *ZFS: i/o error all block copies unavailable **Invalid format* I see you are using GPT. Have you updated bootcode then? Can you import your pool from any HEAD snapshot? -- Sphinx of black quartz, judge my vow. ___ 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: 11.0-CURRENT panic while running a bhyve instance
2013/12/14 Neel Natu neeln...@gmail.com: Hi Markiyan, On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir markiyan.kush...@gmail.com wrote: 2013/12/13 John Baldwin j...@freebsd.org: On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote: Forgot to fill the Subject: header, re-posting it fixed. The mailing lists strips attachments, can you post it at a URL? Shared here: https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing Thanks. It looks like something funky going on with the vcpu state. Do you know if there was any access to the VM via 'bhyvectl' close to the time of the panic? Well, I don't know if there was. I would set up the same scenario again + a script running on the host querying bhyvectl. May be I would catch it again. Please let me know if all it makes sense, and if so, how it can be made better. -- Markiyan. best Neel -- Markiyan. -- Markiyan -- Forwarded message -- From: Markiyan Kushnir markiyan.kush...@gmail.com Date: 2013/12/13 Subject: To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org I started some ports to compile inside a bhyve instance: root@vm:~ # uname -a FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r259250: Thu Dec 12 14:17:32 EET 2013 r...@vm.mkushnir.zapto.org:/ usr/obj/usr/src.svnup/sys/MAREK amd64 and left it running unattended. Approx. 2 hours later the host went to panic. The bhyve instance survived after the panic and I could be able to complete my ports compilation. core.txt attached (gzipped) ___ 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 -- 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 ___ 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