pf reply-to malfunction after r258468 (seems r258479)
I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if it came via tunnel: pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ proto tcp from any to Real_IP_B port 443 And it works at least in r258468. After harware change/reboot yesterday I got strange performance via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing shows packet duplication from reply-to, looks like that: 09:36:59.576405 IP Real_IP_B.443 Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 09:36:59.576413 IP Real_IP_B.443 Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 09:36:59.577583 IP Testbed.4 3775 Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 09:36:59.577713 IP Testbed.43775 Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 ___ 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
pf reply-to malfunction after r258468 (seems r258479)
I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if it came via tunnel: pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ proto tcp from any to Real_IP_B port 443 And it works at least in r258468. After harware change/reboot yesterday I got strange performance via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing shows packet duplication from reply-to, looks like that: 09:36:59.576405 IP Real_IP_B.443 Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 09:36:59.576413 IP Real_IP_B.443 Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 09:36:59.577583 IP Testbed.43775 Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 09:36:59.577713 IP Testbed.43775 Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 ___ 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: pf reply-to malfunction after r258468 (seems r258479)
Vladimir, On Tue, Dec 03, 2013 at 11:52:26AM +0200, Vladimir Sharun wrote: V I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. V I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if V it came via tunnel: V V pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ V proto tcp from any to Real_IP_B port 443 V V And it works at least in r258468. After harware change/reboot yesterday I got strange performance V via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can V saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing V shows packet duplication from reply-to, looks like that: V 09:36:59.576405 IP Real_IP_B.443 Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V 09:36:59.576413 IP Real_IP_B.443 Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V 09:36:59.577583 IP Testbed.43775 Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 V 09:36:59.577713 IP Testbed.43775 Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 I doubt that r258479 can cause a regression in reply-to. Can you please test r258478 and r258479 and confirm or decline that? -- Totus tuus, Glebius. ___ 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[2]: pf reply-to malfunction after r258468 (seems r258479)
Dear Gleb, Is kernel rebuilding enuff ? Vladimir, On Tue, Dec 03, 2013 at 11:52:26AM +0200, Vladimir Sharun wrote: V I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. V I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if V it came via tunnel: V V pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ V proto tcp from any to Real_IP_B port 443 V V And it works at least in r258468. After harware change/reboot yesterday I got strange performance V via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can V saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing V shows packet duplication from reply-to, looks like that: V 09:36:59.576405 IP Real_IP_B.443 Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V 09:36:59.576413 IP Real_IP_B.443 Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V 09:36:59.577583 IP Testbed.43775 Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 V 09:36:59.577713 IP Testbed.43775 Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 I doubt that r258479 can cause a regression in reply-to. Can you please test r258478 and r258479 and confirm or decline that? -- Totus tuus, Glebius. ___ 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: pf reply-to malfunction after r258468 (seems r258479)
On Tue, Dec 03, 2013 at 02:09:14PM +0200, Vladimir Sharun wrote: V Dear Gleb, V Is kernel rebuilding enuff ? Should be enough wrt pf(4), no API or ABI changes in it. -- Totus tuus, Glebius. ___ 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 10.0-BETA4 now available
The fourth BETA build of the 10.0-RELEASE release cycle is now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures. This is expected to be the final BETA build of the 10.0-RELEASE cycle. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal GNATS PR system or here on the -current mailing list. If you would like to use SVN to do a source based update of an existing system, use the stable/10 branch. Important note to freebsd-update(8) users: Please be sure to follow the instructions in the following FreeBSD Errata Notices before upgrading the system to 10.0-BETA4: - EN-13:04.freebsd-update: http://www.freebsd.org/security/advisories/FreeBSD-EN-13:04.freebsd-update.asc - EN-13:05.freebsd-update: http://www.freebsd.org/security/advisories/FreeBSD-EN-13:05.freebsd-update.asc Pre-installed virtual machine images for 10.0-BETA4 are also available for amd64 and i386 architectures. The images are located under the 'snapshots' directory on FTP, here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-BETA4/ The disk images are available in both QCOW2, VHD, and VMDK format. The image download size is approximately 135 MB, which decompress to a 20GB sparse image. The partition layout is: - 512k - freebsd-boot GPT partition type (bootfs GPT label) - 1GB - freebsd-swap GPT partition type (swapfs GPT label) - ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) Changes between -BETA3 and -BETA4 include: - Add preliminary support for RTL8106E, RTL8168G, RTL8168GU, RTL8411B, and RTL8168EP. - Enable fingerprint checking in pkg(8) for FreeBSD-provided binary packages. - Remove the WITH_LIBICONV_COMPAT build option. - Update nvi to 2.1.2. - Various iconv(3) fixes. - Fix mergemaster -U by forcing FreeBSD 9 compatiblity in mtree when mtree is nmtree. - Fix to freebsd-update(8) in generating the list of old files/directories versus new files/directories (FreeBSD-EN-13:05.freebsd-update). == ISO CHECKSUMS == - 10.0-BETA4 amd64: SHA256 (FreeBSD-10.0-BETA4-amd64-bootonly.iso) = f113db8d210d831316c9f41a127781dd28ce782fa8de528cff47f09799fc8f9c SHA256 (FreeBSD-10.0-BETA4-amd64-disc1.iso) = bc85096a98fa261070ae7362225a5b7d63b60bc28525aba0c226917924c5a7ee SHA256 (FreeBSD-10.0-BETA4-amd64-memstick.img) = 4a1b9e0cce18afa2425c1cad685a3462f1a6d1db4e870bb9dd888ad5a4f6d1f5 MD5 (FreeBSD-10.0-BETA4-amd64-bootonly.iso) = 76d1ec5fd97f57c92b2c9dfdf512c388 MD5 (FreeBSD-10.0-BETA4-amd64-disc1.iso) = a3ce29e45a8d718fce09746c6552a45e MD5 (FreeBSD-10.0-BETA4-amd64-memstick.img) = 20e84a31c19697fbc0e46ee34182c4b8 - 10.0-BETA4 i386: SHA256 (FreeBSD-10.0-BETA4-i386-bootonly.iso) = bde072404dd82180a36fea909c10cfff7d1b0361622ae4ecfaf6b5bb07df6670 SHA256 (FreeBSD-10.0-BETA4-i386-disc1.iso) = 9a116fdbe192165c8af985357a07ce7727344f0e93b299900bfcf0fd4bb5bbbd SHA256 (FreeBSD-10.0-BETA4-i386-memstick.img) = 8bd1388553fe0892289e71077973706f55b24c6d0dc111bc502ae24ba44b4588 MD5 (FreeBSD-10.0-BETA4-i386-bootonly.iso) = 4eb173e2ae1da706b2ecb9bc56ba6433 MD5 (FreeBSD-10.0-BETA4-i386-disc1.iso) = 8b5646852ed99644d1cf97ca799188d1 MD5 (FreeBSD-10.0-BETA4-i386-memstick.img) = 9d5911b02554c8984341ea646d8dedfc - 10.0-BETA4 ia64: SHA256 (FreeBSD-10.0-BETA4-ia64-bootonly.iso) = 03ef03299a5717249b67b40b674ad8db139cd8e42839d01c8765a9ec7d04747f SHA256 (FreeBSD-10.0-BETA4-ia64-disc1.iso) = a70ea04f8a56bc6ca40f00b7ede052f3530b16b73a0fcf97ea8d090996f18ff2 SHA256 (FreeBSD-10.0-BETA4-ia64-memstick.img) = cd1de945be58d2410626bdfb0e3c6f5ad195a116b6602f35c606bb9959ec603e MD5 (FreeBSD-10.0-BETA4-ia64-bootonly.iso) = beb2710699be82f7a80df8d27ba876cf MD5 (FreeBSD-10.0-BETA4-ia64-disc1.iso) = 7bb09d29ba0dcb5cc13b9fd994ed2c74 MD5 (FreeBSD-10.0-BETA4-ia64-memstick.img) = 3bb46b075acba974b8c01e95662d3b56 - 10.0-BETA4 powerpc: SHA256 (FreeBSD-10.0-BETA4-powerpc-bootonly.iso) = 58bf6c38fe1a8c0e07d1f3b2a98dc82c70357d89cb0377e82ca845815752e7b3 SHA256 (FreeBSD-10.0-BETA4-powerpc-disc1.iso) = b3c6f64ea5cc61608fdefd9c642399808e8a00c95119f4b623a6cd0ec2163f3f SHA256 (FreeBSD-10.0-BETA4-powerpc-memstick.img) = 1d01fe35eb0b647673fefc1efa76b9eb6c9ea6c96ee76db8c83a08a6922659a1 MD5 (FreeBSD-10.0-BETA4-powerpc-bootonly.iso) = ae55f9dc30d8b4e86436efc11dc03b80 MD5 (FreeBSD-10.0-BETA4-powerpc-disc1.iso) = f97d8475440dea2204ef49a48dd04e3c MD5 (FreeBSD-10.0-BETA4-powerpc-memstick.img) = f7b146dd9edd2c59f566ee98630cfbb1 - 10.0-BETA4 powerpc64: SHA256
Re[2]: pf reply-to malfunction after r258468 (seems r258479)
Dear Gleb, Unfortunately can't boot both revisions kernel, it hangs on trying to mount root from ssdzfs (which is my zfs root). Vladimir, On Tue, Dec 03, 2013 at 11:52:26AM +0200, Vladimir Sharun wrote: V I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. V I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if V it came via tunnel: V V pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ V proto tcp from any to Real_IP_B port 443 V V And it works at least in r258468. After harware change/reboot yesterday I got strange performance V via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can V saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing V shows packet duplication from reply-to, looks like that: V 09:36:59.576405 IP Real_IP_B.443 Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V 09:36:59.576413 IP Real_IP_B.443 Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V 09:36:59.577583 IP Testbed.43775 Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 V 09:36:59.577713 IP Testbed.43775 Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 I doubt that r258479 can cause a regression in reply-to. Can you please test r258478 and r258479 and confirm or decline that? -- Totus tuus, Glebius. ___ 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: pf reply-to malfunction after r258468 (seems r258479)
On Tue, Dec 03, 2013 at 07:54:08PM +0200, Vladimir Sharun wrote: V Dear Gleb, V Unfortunately can't boot both revisions kernel, it hangs on trying to mount root from ssdzfs (which is my zfs root). V Vladimir, You can run the kernel that boots, but update only sys/netpfil/pf directory to suspected revision(s), if you think this is related to changes in pf. -- Totus tuus, Glebius. ___ 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 Sun, Dec 1, 2013 at 3:06 PM, Tijl Coosemans t...@freebsd.org 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. This is nice! Cheers, Antoine ___ 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/01/2013 15:06, 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. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Cheers, Jan Henrik octave-3.6.4_7-fortran_patch-9.2-RELEASE-amd64.log.xz Description: Binary data octave-3.6.4_7-fortran_patch-10.0-BETA4-amd64.log.xz Description: Binary data octave-3.6.4_6-orig-9.2-RELEASE-amd64.log.xz Description: Binary data octave-3.6.4_6-orig-10.0-BETA4-amd64.log.xz Description: Binary data ___ 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 Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: On 12/01/2013 15:06, 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. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Do you define FC in make.conf maybe? ___ 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/03/2013 21:54, Tijl Coosemans wrote: On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: On 12/01/2013 15:06, 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. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Do you define FC in make.conf maybe? No, besides some options (*_SET / *_UNSET) for some unrelated ports, I only have got this in make.conf: WITH_PKGNG=yes WITH_NEW_XORG=yes TEX_DEFAULT=texlive 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 Tue, 03 Dec 2013 22:37:34 +0100 Jan Henrik Sylvester wrote:
On 12/03/2013 21:54, Tijl Coosemans wrote:
On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote:
On 12/01/2013 15:06, Tijl Coosemans wrote:
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.
With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and
10.0-BETA4/amd64 with:
checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77
checking whether we are using the GNU Fortran 77 compiler... no
checking whether f77 accepts -g... no
checking how to get verbose linking output from f77... configure:
WARNING: compilation failed
checking for Fortran 77 libraries of f77...
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... configure: error: in
`/usr/ports/math/octave/work/octave-3.6.4':
configure: error: cannot compile a simple Fortran program
Full logs attached (each with and without your patch).
In both cases, it tries to use f77, while the original port uses gfortran46.
Any idea what is wrong on my system?
Do you define FC in make.conf maybe?
No, besides some options (*_SET / *_UNSET) for some unrelated ports, I
only have got this in make.conf:
Hmm, apparently FC is defined by sys.mk. I've attached a new patch.Index: math/octave/Makefile
===
--- math/octave/Makefile (revision 335568)
+++ 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
configure 2013-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.orig 2013-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:
Re: FreeBSD 10.0-BETA4 now available
from Glen Barber (excerpt): Changes between -BETA3 and -BETA4 include: - Add preliminary support for RTL8106E, RTL8168G, RTL8168GU, RTL8411B, and RTL8168EP. - Enable fingerprint checking in pkg(8) for FreeBSD-provided binary packages. - Remove the WITH_LIBICONV_COMPAT build option. - Update nvi to 2.1.2. - Various iconv(3) fixes. - Fix mergemaster -U by forcing FreeBSD 9 compatiblity in mtree when mtree is nmtree. - Fix to freebsd-update(8) in generating the list of old files/directories versus new files/directories (FreeBSD-EN-13:05.freebsd-update). Would preliminary support for RTL8106E, RTL8168G etc be the re(4) driver? Would these changes be already in HEAD, so if it doesn't work in HEAD on my system, it won't work in 10.0-BETA4? I believe nvi has no -V or --version switch that tells the version without doing anything else (I looked and tried). I noticed NetBSD-current had upgraded nvi but find it very difficult to find latest versions online. Tom ___ 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/04/2013 00:23, Tijl Coosemans wrote: On Tue, 03 Dec 2013 22:37:34 +0100 Jan Henrik Sylvester wrote: On 12/03/2013 21:54, Tijl Coosemans wrote: On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: On 12/01/2013 15:06, Tijl Coosemans wrote: 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. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Do you define FC in make.conf maybe? No, besides some options (*_SET / *_UNSET) for some unrelated ports, I only have got this in make.conf: Hmm, apparently FC is defined by sys.mk. I've attached a new patch. Ok, with the new patch, it compiles and packages on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64. From the new packages, the octave binaries were able to do some simple math. Thanks, 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
10-BETA{3,4} - Consistent Kernel Panics (pf_ioctl.c:1289)
10.0-BETA4 FreeBSD 10.0-BETA4 #0 r258860 KERNCONF: include GENERIC options DDB options ALT_BREAK_TO_DEBUGGER options ROUTETABLES=6 options VIMAGE makeoptions DEBUG=-g device pf device pflog device pfsync device carp Backtrace: (kgdb) bt #0 doadump (textdump=1) at pcpu.h:219 #1 0x808c0005 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x808c03e4 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x80346077 in db_panic (addr=value optimized out, have_addr=value optimized out, count=value optimized out, modif=value optimized out) at /usr/src/sys/ddb/db_command.c:482 #4 0x80345c8d in db_command (cmd_table=value optimized out) at /usr/src/sys/ddb/db_command.c:449 #5 0x80345a04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #6 0x80348370 in db_trap (type=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:231 #7 0x808f9563 in kdb_trap (type=12, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:656 #8 0x80cf0612 in trap_fatal (frame=0xfe085bdeba60, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:877 #9 0x80cf0929 in trap_pfault (frame=0xfe085bdeba60, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:699 #10 0x80cf00b6 in trap (frame=0xfe085bdeba60) at /usr/src/sys/amd64/amd64/trap.c:463 #11 0x80cd6e52 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #12 0x80aca5e3 in pfioctl (dev=0x2, cmd=value optimized out, addr=0xf803ec438000 , flags=value optimized out, td=value optimized out) at /usr/src/sys/netpfil/pf/pf_ioctl.c:1289 #13 0x807b9d5f in devfs_ioctl_f (fp=0xf80014d474b0, com=3417850886, data=0xf803ec438000, cred=value optimized out, td=0xf80014e50920) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #14 0x80910a1e in kern_ioctl (td=0xf80014e50920, fd=value optimized out, com=2) at file.h:319 #15 0x8091079f in sys_ioctl (td=0xf80014e50920, uap=0xfe085bdeca40) at /usr/src/sys/kern/sys_generic.c:702 #16 0x80cf0f47 in amd64_syscall (td=0xf80014e50920, traced=0) at subr_syscall.c:134 #17 0x80cd713b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #18 0x000800dbac2a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) Let me know if anyone needs more debug output. -Alex ** IMPORTANT MESSAGE * This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ** ___ 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
tcl tk ports on FreeBSD 10 amd64
Hi, Sorry for cross posting but this concerns both lists. Over the last month or so I've been upgrading my prod infrastructure from 9 to 10. It's mostly complete except for a number of issues. One issue, just solved today (circumvented is a better word), is exmh crashing 10.0 on amd64 while on i386 there are no issues with exmh. It appears that the tcl and tk ports (all three of them, 8.4, 8.5, and 8.6) will panic 10.0 on amd64 (but not i386) when the ports are built with threading support. I haven't had a chance to look at the dump yet but I had a hunch to test the ports without threading support enabled, making the panic go away. If I don't get to it in time, here is what I haveFatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0x80957aeb stack pointer = 0x28:0xfe00f17f9980 frame pointer = 0x28:0xfe00f17f99a0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 11 (idle: cpu2) trap number = 9 timeout stopping cpus panic: general protection fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00f17f9510 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00f17f95c0 panic() at panic+0x153/frame 0xfe00f17f9640 trap_fatal() at trap_fatal+0x3a2/frame 0xfe00f17f96a0 trap() at trap+0x7bf/frame 0xfe00f17f98c0 calltrap() at calltrap+0x8/frame 0xfe00f17f98c0 --- trap 0x9, rip = 0x80957aeb, rsp = 0xfe00f17f9980, rbp = 0xfe 00f17f99a0 --- cpu_idle_hlt() at cpu_idle_hlt+0x2b/frame 0xfe00f17f99a0 cpu_idle() at cpu_idle+0x93/frame 0xfe00f17f99c0 sched_idletd() at sched_idletd+0x1ee/frame 0xfe00f17f9a70 fork_exit() at fork_exit+0x9a/frame 0xfe00f17f9ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00f17f9ab0 --- trap 0, rip = 0, rsp = 0xfe00f17f9b70, rbp = 0 --- Uptime: 4m42s Dumping 522 out of 5932 MB:..4%..13%..22%..31%..43%..53%..62%..71%..83%..92% so far, Tcl/tk are tickling some bug somewhere. Before anyone suggests memory, I've been able to reproduce this on an Intel Core i3 machine with 6 GB and an AMD X2 5000+, also with 6 GB, both in amd64 mode. Both systems are dual (or multi) boot. The bug does not exhibit itself in i386 mode. It also doesn't exhibit itself when tcl/tk are built without thread support. The only application I know of which tickles the bug is mail/exmh2 (I'm the maintainer) when using a threaded tcl/tk. My 11-CURRENT partition on my laptop is still i386 so I haven't been able to reproduce it under 11 with amd64. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: 10-BETA{3,4} - Consistent Kernel Panics (pf_ioctl.c:1289)
On Wed, Dec 04, 2013 at 10:19:49AM +0800, Wilkinson, Alex wrote: W 10.0-BETA4 FreeBSD 10.0-BETA4 #0 r258860 W W KERNCONF: W W include GENERIC W W options DDB W options ALT_BREAK_TO_DEBUGGER W W options ROUTETABLES=6 W options VIMAGE W W makeoptions DEBUG=-g W W device pf W device pflog W device pfsync W device carp W W W Backtrace: W W (kgdb) bt W #0 doadump (textdump=1) at pcpu.h:219 W #1 0x808c0005 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 W #2 0x808c03e4 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754 W #3 0x80346077 in db_panic (addr=value optimized out, have_addr=value optimized out, count=value optimized out, modif=value optimized out) at /usr/src/sys/ddb/db_command.c:482 W #4 0x80345c8d in db_command (cmd_table=value optimized out) at /usr/src/sys/ddb/db_command.c:449 W #5 0x80345a04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 W #6 0x80348370 in db_trap (type=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:231 W #7 0x808f9563 in kdb_trap (type=12, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:656 W #8 0x80cf0612 in trap_fatal (frame=0xfe085bdeba60, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:877 W #9 0x80cf0929 in trap_pfault (frame=0xfe085bdeba60, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:699 W #10 0x80cf00b6 in trap (frame=0xfe085bdeba60) at /usr/src/sys/amd64/amd64/trap.c:463 W #11 0x80cd6e52 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 W #12 0x80aca5e3 in pfioctl (dev=0x2, cmd=value optimized out, addr=0xf803ec438000 , flags=value optimized out, td=value optimized out) at /usr/src/sys/netpfil/pf/pf_ioctl.c:1289 W #13 0x807b9d5f in devfs_ioctl_f (fp=0xf80014d474b0, com=3417850886, data=0xf803ec438000, cred=value optimized out, td=0xf80014e50920) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 W #14 0x80910a1e in kern_ioctl (td=0xf80014e50920, fd=value optimized out, com=2) at file.h:319 W #15 0x8091079f in sys_ioctl (td=0xf80014e50920, uap=0xfe085bdeca40) at /usr/src/sys/kern/sys_generic.c:702 W #16 0x80cf0f47 in amd64_syscall (td=0xf80014e50920, traced=0) at subr_syscall.c:134 W #17 0x80cd713b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 W #18 0x000800dbac2a in ?? () W Previous frame inner to this frame (corrupt stack?) W Current language: auto; currently minimal W (kgdb) W W Let me know if anyone needs more debug output. I'd like to take a look at the core+kernel. Alternatively, you can provide me with precise reproduce recipe. What arguments to pfctl cause the crash? -- Totus tuus, Glebius. ___ 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: 10-BETA{3,4} - Consistent Kernel Panics (pf_ioctl.c:1289)
On Wed, Dec 04, 2013 at 10:19:49AM +0800, Wilkinson, Alex wrote: W 10.0-BETA4 FreeBSD 10.0-BETA4 #0 r258860 W W KERNCONF: W W include GENERIC W W options DDB W options ALT_BREAK_TO_DEBUGGER W W options ROUTETABLES=6 W options VIMAGE W W makeoptions DEBUG=-g W W device pf W device pflog W device pfsync W device carp W W W Backtrace: W W (kgdb) bt W #0 doadump (textdump=1) at pcpu.h:219 W #1 0x808c0005 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 W #2 0x808c03e4 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754 W #3 0x80346077 in db_panic (addr=value optimized out, have_addr=value optimized out, count=value optimized out, modif=value optimized out) at /usr/src/sys/ddb/db_command.c:482 W #4 0x80345c8d in db_command (cmd_table=value optimized out) at /usr/src/sys/ddb/db_command.c:449 W #5 0x80345a04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 W #6 0x80348370 in db_trap (type=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:231 W #7 0x808f9563 in kdb_trap (type=12, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:656 W #8 0x80cf0612 in trap_fatal (frame=0xfe085bdeba60, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:877 W #9 0x80cf0929 in trap_pfault (frame=0xfe085bdeba60, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:699 W #10 0x80cf00b6 in trap (frame=0xfe085bdeba60) at /usr/src/sys/amd64/amd64/trap.c:463 W #11 0x80cd6e52 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 W #12 0x80aca5e3 in pfioctl (dev=0x2, cmd=value optimized out, addr=0xf803ec438000 , flags=value optimized out, td=value optimized out) at /usr/src/sys/netpfil/pf/pf_ioctl.c:1289 W #13 0x807b9d5f in devfs_ioctl_f (fp=0xf80014d474b0, com=3417850886, data=0xf803ec438000, cred=value optimized out, td=0xf80014e50920) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 W #14 0x80910a1e in kern_ioctl (td=0xf80014e50920, fd=value optimized out, com=2) at file.h:319 W #15 0x8091079f in sys_ioctl (td=0xf80014e50920, uap=0xfe085bdeca40) at /usr/src/sys/kern/sys_generic.c:702 W #16 0x80cf0f47 in amd64_syscall (td=0xf80014e50920, traced=0) at subr_syscall.c:134 W #17 0x80cd713b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 W #18 0x000800dbac2a in ?? () W Previous frame inner to this frame (corrupt stack?) W Current language: auto; currently minimal W (kgdb) W W Let me know if anyone needs more debug output. Does the panic go away if you remove VIMAGE from kernel config? -- Totus tuus, Glebius. ___ 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: 10-BETA{3,4} - Consistent Kernel Panics (pf_ioctl.c:1289)
On Tue, Dec 3, 2013 at 6:19 PM, Wilkinson, Alex alex.wilkin...@cba.com.auwrote: 10.0-BETA4 FreeBSD 10.0-BETA4 #0 r258860 KERNCONF: options VIMAGE makeoptions DEBUG=-g device pf device pflog device pfsync device carp How badly do you need VIMAGE in your kernel config? There are multiple known problems with VIMAGE + pf. See: http://lists.freebsd.org/pipermail/freebsd-virtualization/2013-December/001787.html We need to fix all these problems in FreeBSD, of course, but someone needs to spend the time on it. -- 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
