freebsd-9.0 smartmontools and ada devices
Hi Guys, I have upgraded my desktop from 8.2-stable to 9.0-RC1 (from source), using a GENERIC kernel. I have installed the smartmontools-5.41_3 package from a mirror and found that smartmontools does not like the ada devices anymore. Previously (8.2) I had a GENERIC kernel, with ahci loaded in loader.conf. There an older smartmontools (5.40) worked without a problem on the ada devices. The output of smartctl looks like this: # dolphin# smartctl -a /dev/ada0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ada0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary # Has anybody seen it? John -- John Hay -- j...@meraka.csir.co.za / j...@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: r225932 libsasl undefined references - buildworld failure
On Tue, Oct 18, 2011 at 01:29:38AM +0900, Hajimu UMEMOTO wrote: Hi, On Mon, 17 Oct 2011 16:54:36 +0100 Anton Shterenlikht me...@bristol.ac.uk said: mexas On r225932 with mexas SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 mexas SENDMAIL_LDFLAGS+= -L/usr/local/lib mexas SENDMAIL_LDADD+=-lsasl2 mexas in /etc/make.conf and with cyrus-sasl-2.1.25_1 installed, mexas I get these errors on make buildworld: mexas cc -O2 -pipe -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include -DSASL=2 -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -L/usr/local/lib -o sendmail alias.o arpadate.o bf.o collect.o conf.o control.o convtime.o daemon.o deliver.o domain.o envelope.o err.o headers.o macro.o main.o map.o mci.o milter.o mime.o parseaddr.o queue.o ratectrl.o readcf.o recipient.o savemail.o sasl.o sfsasl.o shmticklib.o sm_resolve.o srvrsmtp.o stab.o stats.o sysexits.o timers.o tls.o trace.o udb.o usersmtp.o util.o version.o -lutil -lwrap /usr/obj/usr/src/usr.sbin/sendmail/../../lib/libsmutil/libsmutil.a /usr/obj/usr/src/usr.sbin/sendmail/../../lib/libsm/libsm.a -lssl -lcrypto -lsasl2 mexas /usr/local/lib/libsasl2.a(otp.o): In function `opie_server_mech_dispose': mexas otp.c:(.text+0x2e52): undefined reference to `opieverify' mexas /usr/local/lib/libsasl2.a(otp.o): In function `opie_server_mech_step': mexas otp.c:(.text+0x3052): undefined reference to `opieverify' mexas otp.c:(.text+0x3542): undefined reference to `opiechallenge' mexas /usr/local/lib/libsasl2.a(gssapi.o): In function `sasl_gss_free_context_contents': mexas gssapi.c:(.text+0x172): undefined reference to `gss_delete_sec_context' mexas gssapi.c:(.text+0x1b2): undefined reference to `gss_release_name' mexas gssapi.c:(.text+0x1f2): undefined reference to `gss_release_name' mexas gssapi.c:(.text+0x232): undefined reference to `gss_release_cred' mexas gssapi.c:(.text+0x272): undefined reference to `gss_release_cred' mexas /usr/local/lib/libsasl2.a(gssapi.o): In function `sasl_gss_seterror_': mexas gssapi.c:(.text+0x7a2): undefined reference to `gss_display_status' mexas gssapi.c:(.text+0x842): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x932): undefined reference to `gss_display_status' mexas gssapi.c:(.text+0x9d2): undefined reference to `gss_release_buffer' mexas /usr/local/lib/libsasl2.a(gssapi.o): In function `gssapi_client_mech_step': mexas gssapi.c:(.text+0xfa2): undefined reference to `gss_delete_sec_context' mexas gssapi.c:(.text+0x10a2): undefined reference to `gss_init_sec_context' mexas gssapi.c:(.text+0x12a2): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x1322): undefined reference to `gss_inquire_context' mexas gssapi.c:(.text+0x1372): undefined reference to `gss_display_name' mexas gssapi.c:(.text+0x1452): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x14f2): undefined reference to `gss_unwrap' mexas gssapi.c:(.text+0x15c2): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x1942): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x1b32): undefined reference to `gss_wrap' mexas gssapi.c:(.text+0x1c72): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x1d52): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x2022): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x2152): undefined reference to `GSS_C_NT_HOSTBASED_SERVICE' mexas gssapi.c:(.text+0x2160): undefined reference to `GSS_C_NT_HOSTBASED_SERVICE' mexas gssapi.c:(.text+0x2172): undefined reference to `gss_import_name' mexas gssapi.c:(.text+0x22b2): undefined reference to `gss_wrap_size_limit' mexas gssapi.c:(.text+0x24d2): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x2582): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x2612): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x26d2): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x2a52): undefined reference to `gss_release_buffer' mexas /usr/local/lib/libsasl2.a(gssapi.o): In function `gssapi_decode_packet': mexas gssapi.c:(.text+0x2be2): undefined reference to `gss_unwrap' mexas gssapi.c:(.text+0x2cd2): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x2d62): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x2e72): undefined reference to `gss_release_buffer' mexas /usr/local/lib/libsasl2.a(gssapi.o): In function `sasl_gss_encode': mexas gssapi.c:(.text+0x2ff2): undefined reference to `gss_wrap' mexas gssapi.c:(.text+0x30c2): undefined reference to `gss_release_buffer' mexas gssapi.c:(.text+0x32f2): undefined reference to `gss_release_buffer' mexas /usr/local/lib/libsasl2.a(gssapi.o): In
Re: freebsd-9.0 smartmontools and ada devices
On Tue, Oct 18, 2011 at 09:39:24AM +0200, John Hay wrote: Hi Guys, I have upgraded my desktop from 8.2-stable to 9.0-RC1 (from source), using a GENERIC kernel. I have installed the smartmontools-5.41_3 package from a mirror and found that smartmontools does not like the ada devices anymore. Previously (8.2) I had a GENERIC kernel, with ahci loaded in loader.conf. There an older smartmontools (5.40) worked without a problem on the ada devices. The output of smartctl looks like this: # dolphin# smartctl -a /dev/ada0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ada0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary # Just to follow up on myself. :-( I have build smartmontools from ports and even though it is the same version, it works. So for me the package amd64/packages-9-current/All/smartmontools-5.41_3.tbz did not work, but the port does. John ___ 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: [RFC] Enable nxstack by default
On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
Hi all!
I think, it's the time to enable the nxstack feature. Any comments,
pros, cons?
I dragged the change long enough for it to miss the 9.0.
After the 9.0 is released, I will flip the switch with the following
change.
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */
+ 1;
+#else
+ 0;
+#endif
SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
nxstack, CTLFLAG_RW, __elfN(nxstack), 0,
__XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) : enable non-executable stack);
diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c
index 7500462..0e27351 100644
--- a/sys/powerpc/aim/mmu_oea64.c
+++ b/sys/powerpc/aim/mmu_oea64.c
@@ -1445,6 +1445,8 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes,
u_int8_t *flags, int wait)
return (void *)va;
}
+extern int elf32_nxstack;
+
void
moea64_init(mmu_t mmu)
{
@@ -1464,6 +1466,8 @@ moea64_init(mmu_t mmu)
uma_zone_set_allocf(moea64_mpvo_zone,moea64_uma_page_alloc);
}
+ elf32_nxstack = 1;
+
moea64_initialized = TRUE;
}
diff --git a/sys/powerpc/booke/machdep.c b/sys/powerpc/booke/machdep.c
index c2b5e6f..82a37e1 100644
--- a/sys/powerpc/booke/machdep.c
+++ b/sys/powerpc/booke/machdep.c
@@ -192,6 +192,8 @@ void print_kernel_section_addr(void);
void print_kenv(void);
u_int booke_init(uint32_t, uint32_t);
+extern int elf32_nxstack;
+
static void
cpu_e500_startup(void *dummy)
{
@@ -227,6 +229,9 @@ cpu_e500_startup(void *dummy)
/* Set up buffers, so they can be used to read disk labels. */
bufinit();
vm_pager_bufferinit();
+
+ /* Cpu supports execution permissions on the pages. */
+ elf32_nxstack = 1;
}
static char *
pgpYBjVPeBl7n.pgp
Description: PGP signature
Re: freebsd-9.0 smartmontools and ada devices
Op di 18 okt 2011 09:39:24 schreef John Hay: Hi Guys, I have upgraded my desktop from 8.2-stable to 9.0-RC1 (from source), using a GENERIC kernel. I have installed the smartmontools-5.41_3 package from a mirror and found that smartmontools does not like the ada devices anymore. Previously (8.2) I had a GENERIC kernel, with ahci loaded in loader.conf. There an older smartmontools (5.40) worked without a problem on the ada devices. The output of smartctl looks like this: # dolphin# smartctl -a /dev/ada0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ada0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary # Has anybody seen it? Yes, but rebuilding smartmontools fixed it for me. ___ 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: freebsd-9.0 smartmontools and ada devices
On Tue, Oct 18, 2011 at 11:02:42AM +0200, John Hay wrote: On Tue, Oct 18, 2011 at 09:39:24AM +0200, John Hay wrote: Hi Guys, I have upgraded my desktop from 8.2-stable to 9.0-RC1 (from source), using a GENERIC kernel. I have installed the smartmontools-5.41_3 package from a mirror and found that smartmontools does not like the ada devices anymore. Previously (8.2) I had a GENERIC kernel, with ahci loaded in loader.conf. There an older smartmontools (5.40) worked without a problem on the ada devices. The output of smartctl looks like this: # dolphin# smartctl -a /dev/ada0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ada0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary # Just to follow up on myself. :-( I have build smartmontools from ports and even though it is the same version, it works. So for me the package amd64/packages-9-current/All/smartmontools-5.41_3.tbz did not work, but the port does. CAM ABI was changed right before RC1. The issue was mentioned in the Ken' announcement. The packages were obviously built with the old headers. pgpCP3eHnNxYY.pgp Description: PGP signature
Re: SPI rework
On Tue, 18 Oct 2011 06:17:46 +0800 Adrian Chadd adr...@freebsd.org wrote: Hi, That sounds logical to me. Maybe getting it done before 9.0-RELEASE is a bit rushed? I can help you test out the flash side of things on my atheros SoC boards. Adrian More thinking give me a better way to fix that. We leave same structure, but remove KASSERT(cmd-tx_cmd_sz == cmd-rx_cmd_sz,); and fix SPI controllers drivers to care about possible different sizes. And of course will fix consumers to set exact what they need. (dev/flash: cmd_tx_sz=1, data_rx_sz=3 for device ID call) That way better because we will have ability to duplex SPI transfers on controllers that able to do that, RT305x SPI will return error in case when sizes specified for both directions. Comments? WBW -- Alexandr Rybalko r...@dlink.ua aka Alex RAY r...@ddteam.net ___ 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: [RFC] Enable nxstack by default
Looks good to me.
On 10/18/11, Kostik Belousov kostik...@gmail.com wrote:
On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
Hi all!
I think, it's the time to enable the nxstack feature. Any comments,
pros, cons?
I dragged the change long enough for it to miss the 9.0.
After the 9.0 is released, I will flip the switch with the following
change.
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */
+ 1;
+#else
+ 0;
+#endif
SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
nxstack, CTLFLAG_RW, __elfN(nxstack), 0,
__XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) : enable non-executable
stack);
diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c
index 7500462..0e27351 100644
--- a/sys/powerpc/aim/mmu_oea64.c
+++ b/sys/powerpc/aim/mmu_oea64.c
@@ -1445,6 +1445,8 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes,
u_int8_t *flags, int wait)
return (void *)va;
}
+extern int elf32_nxstack;
+
void
moea64_init(mmu_t mmu)
{
@@ -1464,6 +1466,8 @@ moea64_init(mmu_t mmu)
uma_zone_set_allocf(moea64_mpvo_zone,moea64_uma_page_alloc);
}
+ elf32_nxstack = 1;
+
moea64_initialized = TRUE;
}
diff --git a/sys/powerpc/booke/machdep.c b/sys/powerpc/booke/machdep.c
index c2b5e6f..82a37e1 100644
--- a/sys/powerpc/booke/machdep.c
+++ b/sys/powerpc/booke/machdep.c
@@ -192,6 +192,8 @@ void print_kernel_section_addr(void);
void print_kenv(void);
u_int booke_init(uint32_t, uint32_t);
+extern int elf32_nxstack;
+
static void
cpu_e500_startup(void *dummy)
{
@@ -227,6 +229,9 @@ cpu_e500_startup(void *dummy)
/* Set up buffers, so they can be used to read disk labels. */
bufinit();
vm_pager_bufferinit();
+
+ /* Cpu supports execution permissions on the pages. */
+ elf32_nxstack = 1;
}
static char *
___
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: zfsloader 9.0 BETA3 r225759 - i/o error - all block copies unavailable
On 10/06/2011 15:36, Andriy Gapon wrote: on 06/10/2011 15:30 Henri Hennebert said the following: The pool is a mirror: [root@morzine ~]# zpool status rpool pool: rpool state: ONLINE scan: scrub repaired 0 in 1h0m with 0 errors on Wed Aug 24 15:04:36 2011 config: NAMESTATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gptid/e915c6a0-fc72-11de-aa21-00e081706b68 ONLINE 0 0 0 gptid/eac8497d-fc72-11de-aa21-00e081706b68 ONLINE 0 0 0 errors: No known data errors and rpool/root is not compressed: [root@morzine ~]# zfs get compression rpool/root NAMEPROPERTY VALUE SOURCE rpool/root compression off inherited from rpool pool is v28 and filesystems are v5 No particular recipes for this environment, just a general suggestion. If you run into a situation like this again, please try to use tools/tools/zfsboottest to diagnose where exactly an error originates. I upgrade another system to 9.0-RC1 and encounter the same problem, this time zfsloader do not run. After mv /mnt/boot /mnt/Boot mkdir /mnt/boot cd /mnt/Boot find . | cpio -pvdmu /mnt/boot FreeBSD boot OK [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 /dev/ada1p2 ZFS: SPA version 28 pool: rpool config: NAME STATE rpool ONLINE mirror ONLINE ada0p2 ONLINE ada1p2 ONLINE ZFS: i/o error - all block copies unavailable can't lookup 10 minutes later: [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 /dev/ada1p2|less ZFS: SPA version 28 pool: rpool config: NAME STATE rpool ONLINE mirror ONLINE ada0p2 ONLINE ada1p2 ONLINE blablabla it seems ok :-o and a other time: [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 segmentation fault... Strange isn't it. Henri ___ 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
mtx_lock() of destroyed mutex on NFS
Hi, as a result of a make buildkernel make installkernel reboot all on NFS I got this with a HEAD SVN source at r226465. I cannot dump unfortunately and it seems I just killed the obj tree for this kernel though it should be very close. Oct 18 10:03:22 lion3 reboot: rebooted by test Oct 18 10:03:22 panic: mtx_lock() of destroyed mutex @ /zoo/bz/HEAD.svn/sys/kern/uipc_socket.c:1022 cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 _mtx_lock_flags() at _mtx_lock_flags+0x130 sosend_dgram() at sosend_dgram+0xbb sosend() at sosend+0x82 clnt_dg_call() at clnt_dg_call+0xb81 clnt_call_private() at clnt_call_private+0xe8 nlm_get_rpc() at nlm_get_rpc+0x187 nlm_host_get_rpc() at nlm_host_get_rpc+0x130 nlm_clearlock() at nlm_clearlock+0x10a nlm_advlock_internal() at nlm_advlock_internal+0x64f nlm_advlock() at nlm_advlock+0x2a nfs_advlock() at nfs_advlock+0x122 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 vn_closefile() at vn_closefile+0xe8 _fdrop() at _fdrop+0x23 closef() at closef+0x5c fdfree() at fdfree+0x1b4 exit1() at exit1+0x31a sigexit() at sigexit+0x8f cursig() at cursig ast() at ast+0x1a9 doreti_ast() at doreti_ast+0x1f KDB: enter: panic [ thread pid 1652 tid 100106 ] Stopped at kdb_enter+0x3b: movq$0,0x80feb2(%rip) db show reg cs0x20 ds0x3b es0x3b003b fs0x1b0013 gs0x1b ss0x28 rax 0x12 rcx 0xfe001a001000 rdx 0 rbx 0x80a2bfa8 __func__.3464+0x111 rsp 0xff85cc173780 rbp 0xff85cc1737a0 rsi 0x80 rdi 0xff85cc173600 r8 0x80a2a498 __func__.6043+0x328 r9 0xff85cc1736b0 r10 0xfe001a001000 r110x1 r120x1 r13 0xfe001a001000 r14 0x3fe r15 0x80a39948 __func__.7715+0x2d3 rip 0x80646c2b kdb_enter+0x3b rflags 0x282 kdb_enter+0x3b: movq$0,0x80feb2(%rip) -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: small devfs.conf patch
on 17/10/2011 23:01 Alexander Best said the following: hi there, any thoughts regarding this change? with the ata subsystem dying, linking to /dev/acd isn't really necessary any more. also a lot of ports nowadays depend on /dev/dvd. IMO, go for it. -- 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: Panics after AHCI timeouts
On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote: On 18 October 2011 03:00, Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote: Hello list! Errr... Replying to myself... Ping? Should I file a PR and put it in the back burner? :) I think filing a PR is a good move. Then just be proactive and poke people about it. It'd be good to get this fixed. :) Done, kern/161768. Question to the list: does anybody see successful recovery from AHCI timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0 branch counts also. That is, there are some kernel messages like this: ahcich0: Timeout on slot 29 port 0 ahcich0: is cs ss rs tfd 40 serr cmd fc17 but then AHCI recovers and the system does not panic? Poking Alexey. ___ 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: Panics after AHCI timeouts
- Original Message - From: Alexey Shuvaev shuv...@physik.uni-wuerzburg.de To: freebsd-current@freebsd.org Sent: Tuesday, October 18, 2011 2:13 PM Subject: Re: Panics after AHCI timeouts On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote: On 18 October 2011 03:00, Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote: Hello list! Errr... Replying to myself... Ping? Should I file a PR and put it in the back burner? :) I think filing a PR is a good move. Then just be proactive and poke people about it. It'd be good to get this fixed. :) Done, kern/161768. Question to the list: does anybody see successful recovery from AHCI timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0 branch counts also. That is, there are some kernel messages like this: ahcich0: Timeout on slot 29 port 0 ahcich0: is cs ss rs tfd 40 serr cmd fc17 but then AHCI recovers and the system does not panic? Not a recent CURRENT but on 8.2-RELEASE we have seen recovery on secondary ssd drives without a panic, but it does generally drop the disk and need a power off, power on to recover the disk properly; although we believe that's a firmware bug on the ssds Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: zfsloader 9.0 BETA3 r225759 - i/o error - all block copies unavailable
on 18/10/2011 13:35 Henri Hennebert said the following: I upgrade another system to 9.0-RC1 and encounter the same problem, this time zfsloader do not run. After mv /mnt/boot /mnt/Boot mkdir /mnt/boot cd /mnt/Boot find . | cpio -pvdmu /mnt/boot FreeBSD boot OK [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 /dev/ada1p2 ZFS: SPA version 28 pool: rpool config: NAME STATE rpool ONLINE mirror ONLINE ada0p2 ONLINE ada1p2 ONLINE ZFS: i/o error - all block copies unavailable can't lookup 10 minutes later: [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 /dev/ada1p2|less ZFS: SPA version 28 pool: rpool config: NAME STATE rpool ONLINE mirror ONLINE ada0p2 ONLINE ada1p2 ONLINE blablabla it seems ok :-o and a other time: [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 segmentation fault... Strange isn't it. I think that it would be smart to not do any filesystem modifications after the problem is detected / reproduced. Also, currently zfsboottest doesn't do much of a problem self-diagnostics, so using gdb or/and adding some printfs in the code are required to understand a nature of a problem. Like what kind of block gives an I/O error, if it actual reading that fails or checksum verification or etc, and so on. -- 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: [RFC] Enable nxstack by default
Hi,
On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov kostik...@gmail.com wrote:
On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
Hi all!
I think, it's the time to enable the nxstack feature. Any comments,
pros, cons?
I dragged the change long enough for it to miss the 9.0.
After the 9.0 is released, I will flip the switch with the following
change.
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */
Why leaving 32bits x86 CPU supporting the NX feature behind ?
- Arnaud
+ 1;
+#else
+ 0;
+#endif
SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
nxstack, CTLFLAG_RW, __elfN(nxstack), 0,
__XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) : enable non-executable
stack);
diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c
index 7500462..0e27351 100644
--- a/sys/powerpc/aim/mmu_oea64.c
+++ b/sys/powerpc/aim/mmu_oea64.c
@@ -1445,6 +1445,8 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes,
u_int8_t *flags, int wait)
return (void *)va;
}
+extern int elf32_nxstack;
+
void
moea64_init(mmu_t mmu)
{
@@ -1464,6 +1466,8 @@ moea64_init(mmu_t mmu)
uma_zone_set_allocf(moea64_mpvo_zone,moea64_uma_page_alloc);
}
+ elf32_nxstack = 1;
+
moea64_initialized = TRUE;
}
diff --git a/sys/powerpc/booke/machdep.c b/sys/powerpc/booke/machdep.c
index c2b5e6f..82a37e1 100644
--- a/sys/powerpc/booke/machdep.c
+++ b/sys/powerpc/booke/machdep.c
@@ -192,6 +192,8 @@ void print_kernel_section_addr(void);
void print_kenv(void);
u_int booke_init(uint32_t, uint32_t);
+extern int elf32_nxstack;
+
static void
cpu_e500_startup(void *dummy)
{
@@ -227,6 +229,9 @@ cpu_e500_startup(void *dummy)
/* Set up buffers, so they can be used to read disk labels. */
bufinit();
vm_pager_bufferinit();
+
+ /* Cpu supports execution permissions on the pages. */
+ elf32_nxstack = 1;
}
static char *
___
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: bsdtar --gname switch
On Oct 17, 2011, at 3:25 PM, Benjamin Kaduk wrote: On Mon, 17 Oct 2011, Romain Garbage wrote: According to bsdtar(1) manpage, tar has a --gname switch that permits to set an arbitrary groupname in the tar archive, but: $ tar -cf foo.tar --gname root bar tar: Option --gname is not supported I get the same error for --uname and --gid switches. I'm running 9.0-BETA3 (r226421). Does this have any chances to be corrected in a not to far away future? This is, at present, a documentation bug. FreeBSD svn revision 207786 was Various manpage updates, including many long-option synonyms that were previously undocumented, which added the gname long-format option to bsdtar.1. However, this option is not present in usr.bin/tar/cmdline.c in FreeBSD head, though it was added in r2349 of upstream libarchive sources on May 1, 2010. So, it looks like it should have been in libarchive since 2.8.4; however, pulling tarballs for 2.8.4 and 2.8.5 it does not seem that gname is listed in cmdline.c for either of them. I'm not familiar with the libarchive release process; Tim, can you shed some insight on what happened here? Looks like the manpage got updated to the latest version from libarchive/trunk. Unfortunately, some of the features described there are not present in libarchive 2.8. It looks like it might be easy to back port some of these features. They don't seem to rely on any of the deeper changes to libarchive internals that have happened since 2.8. Tim ___ 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: Panics after AHCI timeouts
Hi.
Alexey Shuvaev wrote:
On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote:
Errr... Replying to myself... Ping? Should I file a PR and put it
in the back burner? :)
Sorry for not replying, I wasn't home to look on it closely.
In the view of upcoming RELEASE-9.0 I should have reported it earlier,
but it is better later than never... Every time I wanted to report
this, the system was ~one month old and I tried to upgrade it
to see, if the problem was still there, waiting for the next panic...
and when it finally paniced it was one month old again.
[snip]
From core.txt.5:
[snip]
Unread portion of the kernel message buffer:
Memory modified after free 0xfe000416e200(248) val=79e8800 @
0xfe000416e200
panic: Most recently used by cred
cpuid = 2
Uptime: 20h11m1s
Dumping 1308 out of 7914 MB:..2%..12%..21%..31%..41%..51%..62%..71%..81%..91%
[snip]
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:252
252 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:252
#1 0x808234aa in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:430
#2 0x80822f41 in panic (fmt=Variable fmt is not available.
)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0x80a6f7b4 in mtrash_ctor (mem=Variable mem is not available.
) at /usr/src/sys/vm/uma_dbg.c:137
#4 0x80a6f01c in uma_zalloc_arg (zone=0xfe021ffe0700,
udata=0x0,
flags=258) at /usr/src/sys/vm/uma_core.c:2018
#5 0x808108be in malloc (size=Variable size is not available.
) at uma.h:305
#6 0x8081c21f in crget () at /usr/src/sys/kern/kern_prot.c:1809
#7 0x8081c269 in crdup (cr=0xfe0143103300)
at /usr/src/sys/kern/kern_prot.c:1911
#8 0x808c5ca6 in kern_accessat (td=0xfe0007dd7000, fd=-100,
path=0x80065c000 Address 0x80065c000 out of bounds,
pathseg=UIO_USERSPACE, flags=Variable flags is not available.
) at /usr/src/sys/kern/vfs_syscalls.c:2201
#9 0x8086719a in syscallenter (td=0xfe0007dd7000,
sa=0xff8223f67bb0) at /usr/src/sys/kern/subr_trap.c:344
#10 0x80b0b43c in syscall (frame=0xff8223f67c50)
at /usr/src/sys/amd64/amd64/trap.c:910
#11 0x80af617d in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:384
#12 0x00080062dbdc in ?? ()
Previous frame inner to this frame (corrupt stack?)
[snip]
[last message in dmesg]
ahcich0: Timeout on slot 29 port 0
ahcich0: is cs ss rs tfd 40 serr
cm
d fc17
[snip]
Now looking on two you backtraces I don't see anything common between
them. While first crash happened within timer event handler, it was not
AHCI-related event. Second crash happened inside some unrelated syscall.
I may suppose that some memory corruption could cause both, but I have
no idea what it is and how can it be related to AHCI. With the same
effect I could tell that some other hardware problem causes both
problems. Try to collect more statistics.
--
Alexander Motin
___
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: [RFC] Enable nxstack by default
On Tue, 18 Oct 2011, Arnaud Lacombe wrote: Hi, On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov kostik...@gmail.com wrote: On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote: Hi all! I think, it's the time to enable the nxstack feature. Any comments, pros, cons? I dragged the change long enough for it to miss the 9.0. After the 9.0 is released, I will flip the switch with the following change. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 8455f48..926fe64 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, elf_legacy_coredump, 0, ); -static int __elfN(nxstack) = 0; +int __elfN(nxstack) = +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ Why leaving 32bits x86 CPU supporting the NX feature behind ? Most likely because it was assumed that i386 doesn't fully support it. According to ye great Wikipedia, NX support didn't roll into i386 until Prescott, which was pretty late in the non-64-bit capable family of CPUs, as its successor -- Conroe -- was 64-bit. Intel detuned some of the early Dual Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD. There are probably more details in binutils, gcc, etc, that I'm missing and Kostik can expound on. -Garrett___ 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: possible mountroot regression
on 14/10/2011 18:54 Arnaud Lacombe said the following:
Andry Gapon wrote:
Simple: revert to the previous behavior. If a user enters incorrect device
name
(i.e. root mounting fails), then return back to the prompt instead of
panicing.
That should do the job.
- Arnaud
---
sys/kern/vfs_mountroot.c | 45 +++--
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c
index ccbcb33..ae3ffa7 100644
--- a/sys/kern/vfs_mountroot.c
+++ b/sys/kern/vfs_mountroot.c
@@ -481,28 +481,29 @@ parse_dir_ask(char **conf)
printf(\n);
printf( ? List valid disk boot devices\n);
printf( . Yield 1 second (for background tasks)\n);
- printf( empty lineAbort manual input\n);
+ printf( x Abort manual input)\n);
+
+ do {
+ error = EINVAL;
+ printf(\nmountroot );
+ gets(name, sizeof(name), GETS_ECHO);
+ if (name[0] == '?') {
+ printf(\nList of GEOM managed disk devices:\n );
+ g_dev_print();
+ continue;
+ }
+ if (name[0] == '.') {
+ pause(rmask, hz);
+ continue;
+ }
+ if (name[0] == 'x' name[1] == '\0')
+ break;
+ mnt = name;
+ error = parse_mount(mnt);
+ if (error 0)
+ printf(Invalid specification.\n);
+ } while (error != 0);
- again:
- printf(\nmountroot );
- gets(name, sizeof(name), GETS_ECHO);
- if (name[0] == '\0')
- return (0);
- if (name[0] == '?') {
- printf(\nList of GEOM managed disk devices:\n );
- g_dev_print();
- goto again;
- }
- if (name[0] == '.') {
- pause(rmask, hz);
- goto again;
- }
- mnt = name;
- error = parse_mount(mnt);
- if (error == -1) {
- printf(Invalid specification.\n);
- goto again;
- }
return (error);
}
Arnaud,
I like how your change fixes the regression and improves code style.
As you've said, the 'x' change is unrelated. I like it, but it needs to be
discussed and committed separately.
Marcel,
what do you think?
Would you be able to commit a variant of this patch sans the 'x' part?
--
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: PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote: Hello, i recently switched a router in our test-environment to FreeBSD 9.0-Beta3 (and after things didnt worked ... checked out the current RELENG_9 and recompiled kernel world .. ) freebsd-pf archives might be a good start and the better list ... Has anything changed from 8.2 to 9.0 that i missed to consider in configuration? Yes, the implementation was updated ... -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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 NAT issue with 9.0-BETA3 and RELENG_9 'head'
Hello,
i recently switched a router in our test-environment to FreeBSD 9.0-Beta3
(and after things didnt worked ... checked out the current RELENG_9
and recompiled kernel world .. )
Problem:
After 5 - 15 minutes NAT stops working (normal routing still works.)
Network Utilization: about 40 MByte/second, which gets routed
only a few kbit/s are getting natted (NTP Syncs and such ... )
When i took a look on the nat rules (via pfctl -vv -s nat)
the rules gets evaluated; but nothing matches anymore...
State Table helds about 9500 Entrys,
Source Tracking Table about 300
Software / Configuration:
pf, carp
pf.conf:
set limit src-nodes 55
set limit frags 32000
set timeout { adaptive.start 53 adaptive.end 54 }
set timeout src.track 600
set timeout frag 30
set skip on lo0
set skip on igb2
set skip on igb3
set skip on bce0
set skip on bce1
set skip on pfsync0
#set skip on internal
#set skip on carp3internal
nat on public from 10.5.0.0/16 to any - { public }
carp device holding the internal gateway ips (10.5.0.253 .. ),
currently master - no slave
/etc/sysctl.conf:
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.ip.forwarding=1
net.inet.ip.fastforwarding=1
net.inet.icmp.icmplim_output=0
net.inet.icmp.icmplim=0
net.route.netisr_maxqlen=8192
kern.random.sys.harvest.interrupt=0
kern.random.sys.harvest.ethernet=0
kern.random.sys.harvest.point_to_point=0
net.inet.carp.preempt=1
/boot/loader.conf:
net.isr.maxthreads=2
net.isr.defaultqlimit=4096
net.isr.maxqlimit=81920
net.isr.direct=1
net.isr.bindthreads=1
hw.igb.num_queues=2
hw.igb.enable_aim=1
hw.igb.txd=2048
hw.igb.rxd=2048
hw.igb.max_interrupt_rate=8000
hw.intr_storm_threshold=1
kern.ipc.nmbclusters=262144
kern.hz=1000
# sysctl -a hw.igb
hw.igb.rx_process_limit: 100
hw.igb.num_queues: 2
hw.igb.header_split: 0
hw.igb.max_interrupt_rate: 8000
hw.igb.enable_msix: 1
hw.igb.enable_aim: 1
hw.igb.txd: 2048
hw.igb.rxd: 2048
# sysctl -a dev.igb
dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.5
dev.igb.0.%driver: igb
dev.igb.0.%location: slot=0 function=0
dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10e8 subvendor=0x8086
subdevice=0xa02c class=0x02
dev.igb.0.%parent: pci5
dev.igb.0.nvm: -1
dev.igb.0.enable_aim: 1
dev.igb.0.fc: 65536003
dev.igb.0.rx_processing_limit: 100
dev.igb.0.link_irq: 2
dev.igb.0.dropped: 0
dev.igb.0.tx_dma_fail: 0
dev.igb.0.rx_overruns: 0
dev.igb.0.watchdog_timeouts: 0
dev.igb.0.device_control: 1086325313
dev.igb.0.rx_control: 67141634
dev.igb.0.interrupt_mask: 4
dev.igb.0.extended_int_mask: 2147483655
dev.igb.0.tx_buf_alloc: 0
dev.igb.0.rx_buf_alloc: 0
dev.igb.0.fc_high_water: 58976
dev.igb.0.fc_low_water: 58960
dev.igb.0.queue0.no_desc_avail: 0
dev.igb.0.queue0.tx_packets: 28167655
dev.igb.0.queue0.rx_packets: 942710
dev.igb.0.queue0.rx_bytes: 84905673
dev.igb.0.queue0.lro_queued: 0
dev.igb.0.queue0.lro_flushed: 0
dev.igb.0.queue1.no_desc_avail: 0
dev.igb.0.queue1.tx_packets: 27659961
dev.igb.0.queue1.rx_packets: 219218
dev.igb.0.queue1.rx_bytes: 34229378
dev.igb.0.queue1.lro_queued: 0
dev.igb.0.queue1.lro_flushed: 0
dev.igb.0.mac_stats.excess_coll: 0
dev.igb.0.mac_stats.single_coll: 0
dev.igb.0.mac_stats.multiple_coll: 0
dev.igb.0.mac_stats.late_coll: 0
dev.igb.0.mac_stats.collision_count: 0
dev.igb.0.mac_stats.symbol_errors: 0
dev.igb.0.mac_stats.sequence_errors: 0
dev.igb.0.mac_stats.defer_count: 0
dev.igb.0.mac_stats.missed_packets: 0
dev.igb.0.mac_stats.recv_no_buff: 0
dev.igb.0.mac_stats.recv_undersize: 0
dev.igb.0.mac_stats.recv_fragmented: 0
dev.igb.0.mac_stats.recv_oversize: 0
dev.igb.0.mac_stats.recv_jabber: 0
dev.igb.0.mac_stats.recv_errs: 0
dev.igb.0.mac_stats.crc_errs: 0
dev.igb.0.mac_stats.alignment_errs: 0
dev.igb.0.mac_stats.coll_ext_errs: 0
dev.igb.0.mac_stats.xon_recvd: 0
dev.igb.0.mac_stats.xon_txd: 0
dev.igb.0.mac_stats.xoff_recvd: 0
dev.igb.0.mac_stats.xoff_txd: 0
dev.igb.0.mac_stats.total_pkts_recvd: 1277070
dev.igb.0.mac_stats.good_pkts_recvd: 1161923
dev.igb.0.mac_stats.bcast_pkts_recvd: 101354
dev.igb.0.mac_stats.mcast_pkts_recvd: 714
dev.igb.0.mac_stats.rx_frames_64: 102154
dev.igb.0.mac_stats.rx_frames_65_127: 1015473
dev.igb.0.mac_stats.rx_frames_128_255: 6736
dev.igb.0.mac_stats.rx_frames_256_511: 10919
dev.igb.0.mac_stats.rx_frames_512_1023: 1719
dev.igb.0.mac_stats.rx_frames_1024_1522: 24922
dev.igb.0.mac_stats.good_octets_recvd: 123782443
dev.igb.0.mac_stats.good_octets_txd: 55500343847
dev.igb.0.mac_stats.total_pkts_txd: 55828073
dev.igb.0.mac_stats.good_pkts_txd: 55828073
dev.igb.0.mac_stats.bcast_pkts_txd: 5
dev.igb.0.mac_stats.mcast_pkts_txd: 1
dev.igb.0.mac_stats.tx_frames_64: 10267735
Re: [RFC] Enable nxstack by default
Hi, On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper yaneg...@gmail.com wrote: On Tue, 18 Oct 2011, Arnaud Lacombe wrote: Hi, On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov kostik...@gmail.com wrote: On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote: Hi all! I think, it's the time to enable the nxstack feature. Any comments, pros, cons? I dragged the change long enough for it to miss the 9.0. After the 9.0 is released, I will flip the switch with the following change. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 8455f48..926fe64 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, elf_legacy_coredump, 0, ); -static int __elfN(nxstack) = 0; +int __elfN(nxstack) = +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ Why leaving 32bits x86 CPU supporting the NX feature behind ? Most likely because it was assumed that i386 doesn't fully support it. According to ye great Wikipedia, NX support didn't roll into i386 until Prescott, which was pretty late in the non-64-bit capable family of CPUs, as its successor -- Conroe -- was 64-bit. Intel detuned some of the early Dual Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD. There are probably more details in binutils, gcc, etc, that I'm missing and Kostik can expound on. NX support is advertised in the cpuid flags, just add the logic to handle this interface. Kostik's patch is just incomplete, but he's got a commit bit so he can commit it as-is, as he will. If nonexec_stack becomes the default, it should be on every CPU supporting the feature, not just the low-hanging one. - Arnaud ___ 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 NAT issue with 9.0-BETA3 and RELENG_9 'head'
On Tue, Oct 18, 2011 at 6:16 PM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote: Hello, i recently switched a router in our test-environment to FreeBSD 9.0-Beta3 (and after things didnt worked ... checked out the current RELENG_9 and recompiled kernel world .. ) freebsd-pf archives might be a good start and the better list ... Okay, thanks i'll post it there.. i missed that there's also a pf-related list, sorry Has anything changed from 8.2 to 9.0 that i missed to consider in configuration? Yes, the implementation was updated ... -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: [RFC] Enable nxstack by default
On Oct 18, 2011, at 9:26 AM, Arnaud Lacombe wrote: Hi, On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper yaneg...@gmail.com wrote: On Tue, 18 Oct 2011, Arnaud Lacombe wrote: Hi, On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov kostik...@gmail.com wrote: On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote: Hi all! I think, it's the time to enable the nxstack feature. Any comments, pros, cons? I dragged the change long enough for it to miss the 9.0. After the 9.0 is released, I will flip the switch with the following change. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 8455f48..926fe64 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, elf_legacy_coredump, 0, ); -static int __elfN(nxstack) = 0; +int __elfN(nxstack) = +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ Why leaving 32bits x86 CPU supporting the NX feature behind ? Most likely because it was assumed that i386 doesn't fully support it. According to ye great Wikipedia, NX support didn't roll into i386 until Prescott, which was pretty late in the non-64-bit capable family of CPUs, as its successor -- Conroe -- was 64-bit. Intel detuned some of the early Dual Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD. There are probably more details in binutils, gcc, etc, that I'm missing and Kostik can expound on. NX support is advertised in the cpuid flags, just add the logic to handle this interface. Kostik's patch is just incomplete, but he's got a commit bit so he can commit it as-is, as he will. If nonexec_stack becomes the default, it should be on every CPU supporting the feature, not just the low-hanging one. It gets a bit trickier because now you're putting MD code into MI code, but that should be easy enough to abstract out into amd64, i386, etc. Still wondering if the toolchain is lacking support though, because I remember a few committers (dim?, kib?) making some modifications in order to get NX working about a year ago. -Garrett___ 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: [RFC] Enable nxstack by default
On 10/18/11, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper yaneg...@gmail.com wrote:
On Tue, 18 Oct 2011, Arnaud Lacombe wrote:
Hi,
On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov kostik...@gmail.com
wrote:
On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
Hi all!
I think, it's the time to enable the nxstack feature. Any comments,
pros, cons?
I dragged the change long enough for it to miss the 9.0.
After the 9.0 is released, I will flip the switch with the following
change.
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit
*/
Why leaving 32bits x86 CPU supporting the NX feature behind ?
Most likely because it was assumed that i386 doesn't fully support it.
According to ye great Wikipedia, NX support didn't roll into i386 until
Prescott, which was pretty late in the non-64-bit capable family of CPUs,
as
its successor -- Conroe -- was 64-bit. Intel detuned some of the early
Dual
Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD.
There are probably more details in binutils, gcc, etc, that I'm missing
and
Kostik can expound on.
NX support is advertised in the cpuid flags, just add the logic to
handle this interface. Kostik's patch is just incomplete, but he's got
a commit bit so he can commit it as-is, as he will.
If nonexec_stack becomes the default, it should be on every CPU
supporting the feature, not just the low-hanging one.
- Arnaud
the NX detection code already implemented in i386, but this feature
required PAE:
@initializecpu(void):
» » }
#ifdef PAE
» » if ((amd_feature AMDID_NX) != 0) {
» » » uint64_t msr;
» » » msr = rdmsr(MSR_EFER) | EFER_NXE;
» » » wrmsr(MSR_EFER, msr);
» » » pg_nx = PG_NX;
» » }
#endif
» » break
___
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: [RFC] Enable nxstack by default
Hi, On Tue, Oct 18, 2011 at 12:53 PM, Oliver Pinter oliver.p...@gmail.com wrote: On 10/18/11, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper yaneg...@gmail.com wrote: On Tue, 18 Oct 2011, Arnaud Lacombe wrote: Hi, On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov kostik...@gmail.com wrote: On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote: Hi all! I think, it's the time to enable the nxstack feature. Any comments, pros, cons? I dragged the change long enough for it to miss the 9.0. After the 9.0 is released, I will flip the switch with the following change. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 8455f48..926fe64 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, elf_legacy_coredump, 0, ); -static int __elfN(nxstack) = 0; +int __elfN(nxstack) = +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ Why leaving 32bits x86 CPU supporting the NX feature behind ? Most likely because it was assumed that i386 doesn't fully support it. According to ye great Wikipedia, NX support didn't roll into i386 until Prescott, which was pretty late in the non-64-bit capable family of CPUs, as its successor -- Conroe -- was 64-bit. Intel detuned some of the early Dual Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD. There are probably more details in binutils, gcc, etc, that I'm missing and Kostik can expound on. NX support is advertised in the cpuid flags, just add the logic to handle this interface. Kostik's patch is just incomplete, but he's got a commit bit so he can commit it as-is, as he will. If nonexec_stack becomes the default, it should be on every CPU supporting the feature, not just the low-hanging one. - Arnaud the NX detection code already implemented in i386, but this feature required PAE: yes, this is the conclusion I reached too. But this does not change the fact that the VM should know about that, and this is missing from Kostik's patch. I guess the first hunk should read: @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, elf_legacy_coredump, 0, ); -static int __elfN(nxstack) = 0; +int __elfN(nxstack) = +#if defined(PAE) || defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ + 1; +#else + 0; +#endif SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO, nxstack, CTLFLAG_RW, __elfN(nxstack), 0, __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) : enable non-executable stack); - Arnaud ___ 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: [RFC] Enable nxstack by default
On Tue, Oct 18, 2011 at 01:06:27PM -0400, Arnaud Lacombe wrote:
Hi,
On Tue, Oct 18, 2011 at 12:53 PM, Oliver Pinter oliver.p...@gmail.com wrote:
On 10/18/11, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper yaneg...@gmail.com
wrote:
On Tue, 18 Oct 2011, Arnaud Lacombe wrote:
Hi,
On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov kostik...@gmail.com
wrote:
On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
Hi all!
I think, it's the time to enable the nxstack feature. Any comments,
pros, cons?
I dragged the change long enough for it to miss the 9.0.
After the 9.0 is released, I will flip the switch with the following
change.
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit
*/
Why leaving 32bits x86 CPU supporting the NX feature behind ?
Most likely because it was assumed that i386 doesn't fully support it.
According to ye great Wikipedia, NX support didn't roll into i386 until
Prescott, which was pretty late in the non-64-bit capable family of CPUs,
as
its successor -- Conroe -- was 64-bit. Intel detuned some of the early
Dual
Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD.
There are probably more details in binutils, gcc, etc, that I'm missing
and
Kostik can expound on.
NX support is advertised in the cpuid flags, just add the logic to
handle this interface. Kostik's patch is just incomplete, but he's got
a commit bit so he can commit it as-is, as he will.
If nonexec_stack becomes the default, it should be on every CPU
supporting the feature, not just the low-hanging one.
- Arnaud
the NX detection code already implemented in i386, but this feature
required PAE:
yes, this is the conclusion I reached too. But this does not change
the fact that the VM should know about that, and this is missing from
Kostik's patch. I guess the first hunk should read:
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(PAE) || defined(__amd64__) || defined(__powerpc64__) /*
both 64 and 32 bit */
+ 1;
+#else
+ 0;
+#endif
SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
nxstack, CTLFLAG_RW, __elfN(nxstack), 0,
__XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) : enable non-executable
stack);
Your patch is not right, it will cause even more user confusion.
The presence of the PAE kernel does not imply that CPU supports nx.
Below is the updated patch that turns on nxstack by default for the PAE
kernels on NX-capable CPUs. Note that i386 usermode fully supports the
PT_GNU_STACK annotations and cares about not enabling nx on stack pages
unneccessary, but my main target was compat32 on amd64.
The fact that nxstack is not enabled by default does not prevent
administrator from manually enabling the feature.
Since you worried so much about PAE case, I sincerely expect that you
will test the change. Thank you in advance.
diff --git a/sys/i386/i386/initcpu.c b/sys/i386/i386/initcpu.c
index c2daf54..ec77adb 100644
--- a/sys/i386/i386/initcpu.c
+++ b/sys/i386/i386/initcpu.c
@@ -650,6 +650,8 @@ enable_sse(void)
#endif
}
+extern int elf32_nxstack;
+
void
initializecpu(void)
{
@@ -739,6 +741,7 @@ initializecpu(void)
msr = rdmsr(MSR_EFER) | EFER_NXE;
wrmsr(MSR_EFER, msr);
pg_nx = PG_NX;
+ elf32_nxstack = 1;
}
#endif
break;
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */
+ 1;
+#else
+ 0;
+#endif
SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
nxstack, CTLFLAG_RW, __elfN(nxstack), 0,
__XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) : enable non-executable stack);
diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c
index 7500462..0e27351 100644
--- a/sys/powerpc/aim/mmu_oea64.c
+++ b/sys/powerpc/aim/mmu_oea64.c
@@ -1445,6 +1445,8 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes,
u_int8_t
Re: PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
Florian Wilkemeyer wrote: On Tue, Oct 18, 2011 at 6:16 PM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote: Hello, i recently switched a router in our test-environment to FreeBSD 9.0-Beta= 3 (and after things didnt worked ... checked out the current RELENG_9 and recompiled kernel world .. ) freebsd-pf archives might be a good start and the better list ... Okay, thanks i'll post it there.. Did you by chance, run out of state entries? I believe the work-around is to load pf as a module until the issue is fixed. Ian -- Ian Freislich ___ 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
IPv6 accept_rtadv + bfe0
Hi The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do it with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to ifconfig_bge0 in rc.conf it does nothing. grep bfe /etc/rc.conf ifconfig_bfe0=DHCP accept_rtadv ifconfig bfe0 bfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=80008VLAN_MTU,LINKSTATE ether 00:1d:09:a7:41:a8 inet6 fe80::21d:9ff:fea7:41a8%bfe0 prefixlen 64 scopeid 0x9 inet 146.64.80.134 netmask 0xff00 broadcast 146.64.80.255 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active ifconfig bfe0 inet6 accept_rtadv ifconfig bfe0 bfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=80008VLAN_MTU,LINKSTATE ether 00:1d:09:a7:41:a8 inet6 fe80::21d:9ff:fea7:41a8%bfe0 prefixlen 64 scopeid 0x9 inet 146.64.80.134 netmask 0xff00 broadcast 146.64.80.255 inet6 2001:4200:7000:100:21d:9ff:fea7:41a8 prefixlen 64 autoconf nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active uname -a FreeBSD pcbsd-615 9.0-BETA3 FreeBSD 9.0-BETA3 grep v6 /etc/rc.conf ipv6_activate_all_interfaces=YES grep rtadv /etc/sysctl.conf net.inet6.ip6.accept_rtadv=1 Is there anything else that I need to do ? Johann ___ 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: IPv6 accept_rtadv + bfe0
On 18. Oct 2011, at 20:00 , Johann Hugo wrote: Hi The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do it with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to ifconfig_bge0 in rc.conf it does nothing. grep bfe /etc/rc.conf ifconfig_bfe0=DHCP accept_rtadv ifconfig_bfe0=DHCP ifconfig_bfe0_ipv6=inet6 accept_rtadv -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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
About FreeBSD 9.0 release note
Hi, Does someone know where is the draft of FreeBSD 9.0 release note? I would like to check if there is a description about new functions about MLDv2 is included or not. I think the below feature should be included in the release note as IPv6 network is getting popular. - MFC r200871: Use ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave with SSM MLDv2 by default. This is current practice and complies with RFC 4604, as well as being required by production IPv6 networks in Japan. The behaviour may be disabled by setting the net.inet6.mld.use_allow sysctl/tunable to 0. - Best regards, Hideki Yamamoto ___ 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: About FreeBSD 9.0 release note
Hideki Yamamoto hyam...@gmail.com wrote in CAOEiK=_nEJ=9prg1y5fmdbbwyqxypd-3+nyomqa9asekkgh...@mail.gmail.com: hy Hi, hy hy Does someone know where is the draft of FreeBSD 9.0 release note? hy I would like to check if there is a description about new functions hy about MLDv2 is included or not. hy I think the below feature should be included in the release note as hy IPv6 network is getting popular. hy hy - hy MFC r200871: hy Use ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave hy with SSM MLDv2 by default. hy This is current practice and complies with RFC 4604, as well as being hy required by production IPv6 networks in Japan. hy The behaviour may be disabled by setting the net.inet6.mld.use_allow hy sysctl/tunable to 0. hy - I am already working on the relnotes and the above will be included as an improvement of the IPv6 stack. -- Hiroki pgpooCpg10Xx0.pgp Description: PGP signature
Re: About FreeBSD 9.0 release note
On Wed, Oct 19, 2011 at 2:07 AM, Hiroki Sato h...@freebsd.org wrote: Hideki Yamamoto hyam...@gmail.com wrote in CAOEiK=_nEJ=9prg1y5fmdbbwyqxypd-3+nyomqa9asekkgh...@mail.gmail.com: hy Hi, hy hy Does someone know where is the draft of FreeBSD 9.0 release note? hy I would like to check if there is a description about new functions hy about MLDv2 is included or not. hy I think the below feature should be included in the release note as hy IPv6 network is getting popular. hy hy - hy MFC r200871: hy Use ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave hy with SSM MLDv2 by default. hy This is current practice and complies with RFC 4604, as well as being hy required by production IPv6 networks in Japan. hy The behaviour may be disabled by setting the net.inet6.mld.use_allow hy sysctl/tunable to 0. hy - I am already working on the relnotes and the above will be included as an improvement of the IPv6 stack. If you're not complicated. Maybe we should put a draft on the wiki? ___ 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
[head tinderbox] failure on i386/pc98
TB --- 2011-10-18 21:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-18 21:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-18 21:40:00 - cleaning the object tree TB --- 2011-10-18 21:40:33 - cvsupping the source tree TB --- 2011-10-18 21:40:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-18 21:40:53 - building world TB --- 2011-10-18 21:40:53 - CROSS_BUILD_TESTING=YES TB --- 2011-10-18 21:40:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-18 21:40:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-18 21:40:53 - SRCCONF=/dev/null TB --- 2011-10-18 21:40:53 - TARGET=pc98 TB --- 2011-10-18 21:40:53 - TARGET_ARCH=i386 TB --- 2011-10-18 21:40:53 - TZ=UTC TB --- 2011-10-18 21:40:53 - __MAKE_CONF=/dev/null TB --- 2011-10-18 21:40:53 - cd /src TB --- 2011-10-18 21:40:53 - /usr/bin/make -B buildworld World build started on Tue Oct 18 21:40:54 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-18 22:25:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-18 22:25:35 - ERROR: failed to build world TB --- 2011-10-18 22:25:35 - 2065.66 user 475.65 system 2735.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full ___ 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: [RFC] Enable nxstack by default
Hi,
2011/10/18 Kostik Belousov kostik...@gmail.com:
On Tue, Oct 18, 2011 at 01:06:27PM -0400, Arnaud Lacombe wrote:
Hi,
On Tue, Oct 18, 2011 at 12:53 PM, Oliver Pinter oliver.p...@gmail.com
wrote:
On 10/18/11, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper yaneg...@gmail.com
wrote:
On Tue, 18 Oct 2011, Arnaud Lacombe wrote:
Hi,
On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov kostik...@gmail.com
wrote:
On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
Hi all!
I think, it's the time to enable the nxstack feature. Any comments,
pros, cons?
I dragged the change long enough for it to miss the 9.0.
After the 9.0 is released, I will flip the switch with the following
change.
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit
*/
Why leaving 32bits x86 CPU supporting the NX feature behind ?
Most likely because it was assumed that i386 doesn't fully support it.
According to ye great Wikipedia, NX support didn't roll into i386 until
Prescott, which was pretty late in the non-64-bit capable family of CPUs,
as
its successor -- Conroe -- was 64-bit. Intel detuned some of the early
Dual
Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD.
There are probably more details in binutils, gcc, etc, that I'm missing
and
Kostik can expound on.
NX support is advertised in the cpuid flags, just add the logic to
handle this interface. Kostik's patch is just incomplete, but he's got
a commit bit so he can commit it as-is, as he will.
If nonexec_stack becomes the default, it should be on every CPU
supporting the feature, not just the low-hanging one.
- Arnaud
the NX detection code already implemented in i386, but this feature
required PAE:
yes, this is the conclusion I reached too. But this does not change
the fact that the VM should know about that, and this is missing from
Kostik's patch. I guess the first hunk should read:
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(PAE) || defined(__amd64__) || defined(__powerpc64__) /*
both 64 and 32 bit */
+ 1;
+#else
+ 0;
+#endif
SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
nxstack, CTLFLAG_RW, __elfN(nxstack), 0,
__XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) : enable non-executable
stack);
Your patch is not right, it will cause even more user confusion.
The presence of the PAE kernel does not imply that CPU supports nx.
Below is the updated patch that turns on nxstack by default for the PAE
kernels on NX-capable CPUs. Note that i386 usermode fully supports the
PT_GNU_STACK annotations and cares about not enabling nx on stack pages
unneccessary, but my main target was compat32 on amd64.
The fact that nxstack is not enabled by default does not prevent
administrator from manually enabling the feature.
Since you worried so much about PAE case, I sincerely expect that you
will test the change. Thank you in advance.
I will.
Btw, NetBSD has been going down the path of system unit test,
especially of kernel/userland interfaces, and already worked-out the
framework for that. Is that something FreeBSD would be interested in ?
Thanks,
- Arnaud
diff --git a/sys/i386/i386/initcpu.c b/sys/i386/i386/initcpu.c
index c2daf54..ec77adb 100644
--- a/sys/i386/i386/initcpu.c
+++ b/sys/i386/i386/initcpu.c
@@ -650,6 +650,8 @@ enable_sse(void)
#endif
}
+extern int elf32_nxstack;
+
void
initializecpu(void)
{
@@ -739,6 +741,7 @@ initializecpu(void)
msr = rdmsr(MSR_EFER) | EFER_NXE;
wrmsr(MSR_EFER, msr);
pg_nx = PG_NX;
+ elf32_nxstack = 1;
}
#endif
break;
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */
+ 1;
+#else
+ 0;
+#endif
SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
nxstack, CTLFLAG_RW, __elfN(nxstack), 0,
[head tinderbox] failure on i386/i386
TB --- 2011-10-18 21:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-18 21:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-18 21:40:00 - cleaning the object tree TB --- 2011-10-18 21:41:05 - cvsupping the source tree TB --- 2011-10-18 21:41:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-18 21:41:17 - building world TB --- 2011-10-18 21:41:17 - CROSS_BUILD_TESTING=YES TB --- 2011-10-18 21:41:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-18 21:41:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-18 21:41:17 - SRCCONF=/dev/null TB --- 2011-10-18 21:41:17 - TARGET=i386 TB --- 2011-10-18 21:41:17 - TARGET_ARCH=i386 TB --- 2011-10-18 21:41:17 - TZ=UTC TB --- 2011-10-18 21:41:17 - __MAKE_CONF=/dev/null TB --- 2011-10-18 21:41:17 - cd /src TB --- 2011-10-18 21:41:17 - /usr/bin/make -B buildworld World build started on Tue Oct 18 21:41:18 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-18 22:25:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-18 22:25:50 - ERROR: failed to build world TB --- 2011-10-18 22:25:51 - 2066.52 user 476.09 system 2750.65 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ 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
[head tinderbox] failure on amd64/amd64
TB --- 2011-10-18 21:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-18 21:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-18 21:40:00 - cleaning the object tree TB --- 2011-10-18 21:41:04 - cvsupping the source tree TB --- 2011-10-18 21:41:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-18 21:41:17 - building world TB --- 2011-10-18 21:41:17 - CROSS_BUILD_TESTING=YES TB --- 2011-10-18 21:41:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-18 21:41:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-18 21:41:17 - SRCCONF=/dev/null TB --- 2011-10-18 21:41:17 - TARGET=amd64 TB --- 2011-10-18 21:41:17 - TARGET_ARCH=amd64 TB --- 2011-10-18 21:41:17 - TZ=UTC TB --- 2011-10-18 21:41:17 - __MAKE_CONF=/dev/null TB --- 2011-10-18 21:41:17 - cd /src TB --- 2011-10-18 21:41:17 - /usr/bin/make -B buildworld World build started on Tue Oct 18 21:41:17 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-18 22:26:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-18 22:26:44 - ERROR: failed to build world TB --- 2011-10-18 22:26:44 - 2092.45 user 492.93 system 2804.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ 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: About FreeBSD 9.0 release note
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/18/11 15:07, Hiroki Sato wrote: Hideki Yamamoto hyam...@gmail.com wrote in CAOEiK=_nEJ=9prg1y5fmdbbwyqxypd-3+nyomqa9asekkgh...@mail.gmail.com: hy Hi, hy hy Does someone know where is the draft of FreeBSD 9.0 release note? hy I would like to check if there is a description about new functions hy about MLDv2 is included or not. hy I think the below feature should be included in the release note as hy IPv6 network is getting popular. hy hy - hy MFC r200871: hy Use ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave hy with SSM MLDv2 by default. hy This is current practice and complies with RFC 4604, as well as being hy required by production IPv6 networks in Japan. hy The behaviour may be disabled by setting the net.inet6.mld.use_allow hy sysctl/tunable to 0. hy - I am already working on the relnotes and the above will be included as an improvement of the IPv6 stack. Can we have it somewhere (in the CVS or wiki) so we can work together on that? This way also makes translation easier... Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOnf1GAAoJEATO+BI/yjfB7QYH/iWLx4Gme1uR+KAweDABTj2u tBZIHxrD68O1STbeQHM/69zZ5CmsjBmpI7p3smRCII2yI/UZkwWB4EQH9aTZ0ova KT1sLeZgdeCUbA6kg8ok/bZF6Fdo4ZdeOb7ufuDrz6LMbUOQo1NrYhoAZkrjE8/P Qab8rtbLk9doqDV3/wBikr0mgAO/h+IRiZpFso90msT2xYrMhEVvOso3lL9Nsu9V S+Y1dbzbFsSAa25k/l95WJ0C4eh14Zlh7DykdnVgqyo4oy6N0gyfQaS1NYocc268 9Y5juonQh4y58LMwK8jfP0Xl1k6/ZjkNwN+MzboRTvf0Oj0lQY8jKwY0BpQRFX8= =ivPD -END PGP SIGNATURE- ___ 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: [RFC] Enable nxstack by default
In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X
(~nxstack), mprotect restriction, veriexec, mmap randomization[2]...)
[0] http://pax.grsecurity.net/docs/index.html
[1] http://www.netbsd.org/~elad/recent/man/security.8.html
[2] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff
On 10/19/11, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
2011/10/18 Kostik Belousov kostik...@gmail.com:
On Tue, Oct 18, 2011 at 01:06:27PM -0400, Arnaud Lacombe wrote:
Hi,
On Tue, Oct 18, 2011 at 12:53 PM, Oliver Pinter oliver.p...@gmail.com
wrote:
On 10/18/11, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper yaneg...@gmail.com
wrote:
On Tue, 18 Oct 2011, Arnaud Lacombe wrote:
Hi,
On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov
kostik...@gmail.com
wrote:
On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
Hi all!
I think, it's the time to enable the nxstack feature. Any
comments,
pros, cons?
I dragged the change long enough for it to miss the 9.0.
After the 9.0 is released, I will flip the switch with the
following
change.
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32
bit
*/
Why leaving 32bits x86 CPU supporting the NX feature behind ?
Most likely because it was assumed that i386 doesn't fully support
it.
According to ye great Wikipedia, NX support didn't roll into i386
until
Prescott, which was pretty late in the non-64-bit capable family of
CPUs,
as
its successor -- Conroe -- was 64-bit. Intel detuned some of the
early
Dual
Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about
AMD.
There are probably more details in binutils, gcc, etc, that I'm
missing
and
Kostik can expound on.
NX support is advertised in the cpuid flags, just add the logic to
handle this interface. Kostik's patch is just incomplete, but he's got
a commit bit so he can commit it as-is, as he will.
If nonexec_stack becomes the default, it should be on every CPU
supporting the feature, not just the low-hanging one.
- Arnaud
the NX detection code already implemented in i386, but this feature
required PAE:
yes, this is the conclusion I reached too. But this does not change
the fact that the VM should know about that, and this is missing from
Kostik's patch. I guess the first hunk should read:
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
elf_legacy_coredump, 0, );
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(PAE) || defined(__amd64__) || defined(__powerpc64__) /*
both 64 and 32 bit */
+ 1;
+#else
+ 0;
+#endif
SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
nxstack, CTLFLAG_RW, __elfN(nxstack), 0,
__XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) : enable non-executable
stack);
Your patch is not right, it will cause even more user confusion.
The presence of the PAE kernel does not imply that CPU supports nx.
Below is the updated patch that turns on nxstack by default for the PAE
kernels on NX-capable CPUs. Note that i386 usermode fully supports the
PT_GNU_STACK annotations and cares about not enabling nx on stack pages
unneccessary, but my main target was compat32 on amd64.
The fact that nxstack is not enabled by default does not prevent
administrator from manually enabling the feature.
Since you worried so much about PAE case, I sincerely expect that you
will test the change. Thank you in advance.
I will.
Btw, NetBSD has been going down the path of system unit test,
especially of kernel/userland interfaces, and already worked-out the
framework for that. Is that something FreeBSD would be interested in ?
Thanks,
- Arnaud
diff --git a/sys/i386/i386/initcpu.c b/sys/i386/i386/initcpu.c
index c2daf54..ec77adb 100644
--- a/sys/i386/i386/initcpu.c
+++ b/sys/i386/i386/initcpu.c
@@ -650,6 +650,8 @@ enable_sse(void)
#endif
}
+extern int elf32_nxstack;
+
void
initializecpu(void)
{
@@ -739,6 +741,7 @@ initializecpu(void)
msr = rdmsr(MSR_EFER) | EFER_NXE;
wrmsr(MSR_EFER, msr);
pg_nx = PG_NX;
+ elf32_nxstack = 1;
}
#endif
break;
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-10-18 22:26:44 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-18 22:26:44 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-10-18 22:26:44 - cleaning the object tree TB --- 2011-10-18 22:26:58 - cvsupping the source tree TB --- 2011-10-18 22:26:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-10-18 22:27:11 - building world TB --- 2011-10-18 22:27:11 - CROSS_BUILD_TESTING=YES TB --- 2011-10-18 22:27:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-18 22:27:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-18 22:27:11 - SRCCONF=/dev/null TB --- 2011-10-18 22:27:11 - TARGET=powerpc TB --- 2011-10-18 22:27:11 - TARGET_ARCH=powerpc TB --- 2011-10-18 22:27:11 - TZ=UTC TB --- 2011-10-18 22:27:11 - __MAKE_CONF=/dev/null TB --- 2011-10-18 22:27:11 - cd /src TB --- 2011-10-18 22:27:11 - /usr/bin/make -B buildworld World build started on Tue Oct 18 22:27:11 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-18 23:11:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-18 23:11:43 - ERROR: failed to build world TB --- 2011-10-18 23:11:43 - 2031.27 user 451.99 system 2698.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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: IPv6 accept_rtadv + bfe0
On 19/10/2011 08:16, Bjoern A. Zeeb wrote: On 18. Oct 2011, at 20:00 , Johann Hugo wrote: Hi The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do it with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to ifconfig_bge0 in rc.conf it does nothing. grep bfe /etc/rc.conf ifconfig_bfe0=DHCP accept_rtadv ifconfig_bfe0=DHCP ifconfig_bfe0_ipv6=inet6 accept_rtadv So the _ipv6 bit doesn't take care of passing inet6 to ifconfig automatically? Does passing two options work, or do I have to pass them separately? E.g.: ifconfig_bfe0_ipv6=inet6 accept_rtadv -ifdisable or ifconfig_bfe0_ipv6=inet6 accept_rtadv ifconfig_bfe0_ipv6=inet6 -ifdisable Mat ___ 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
[head tinderbox] failure on i386/i386
TB --- 2011-10-19 01:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 01:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-19 01:10:00 - cleaning the object tree TB --- 2011-10-19 01:10:07 - cvsupping the source tree TB --- 2011-10-19 01:10:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-19 01:10:26 - building world TB --- 2011-10-19 01:10:26 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 01:10:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 01:10:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 01:10:26 - SRCCONF=/dev/null TB --- 2011-10-19 01:10:26 - TARGET=i386 TB --- 2011-10-19 01:10:26 - TARGET_ARCH=i386 TB --- 2011-10-19 01:10:26 - TZ=UTC TB --- 2011-10-19 01:10:26 - __MAKE_CONF=/dev/null TB --- 2011-10-19 01:10:26 - cd /src TB --- 2011-10-19 01:10:26 - /usr/bin/make -B buildworld World build started on Wed Oct 19 01:10:26 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-19 01:54:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 01:54:35 - ERROR: failed to build world TB --- 2011-10-19 01:54:35 - 2059.50 user 463.81 system 2675.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ 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
[head tinderbox] failure on i386/pc98
TB --- 2011-10-19 01:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 01:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-19 01:10:00 - cleaning the object tree TB --- 2011-10-19 01:10:07 - cvsupping the source tree TB --- 2011-10-19 01:10:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-19 01:10:26 - building world TB --- 2011-10-19 01:10:26 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 01:10:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 01:10:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 01:10:26 - SRCCONF=/dev/null TB --- 2011-10-19 01:10:26 - TARGET=pc98 TB --- 2011-10-19 01:10:26 - TARGET_ARCH=i386 TB --- 2011-10-19 01:10:26 - TZ=UTC TB --- 2011-10-19 01:10:26 - __MAKE_CONF=/dev/null TB --- 2011-10-19 01:10:26 - cd /src TB --- 2011-10-19 01:10:26 - /usr/bin/make -B buildworld World build started on Wed Oct 19 01:10:26 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-19 01:54:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 01:54:56 - ERROR: failed to build world TB --- 2011-10-19 01:54:57 - 2065.98 user 472.90 system 2696.64 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full ___ 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
[head tinderbox] failure on amd64/amd64
TB --- 2011-10-19 01:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 01:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-19 01:10:00 - cleaning the object tree TB --- 2011-10-19 01:10:07 - cvsupping the source tree TB --- 2011-10-19 01:10:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-19 01:10:26 - building world TB --- 2011-10-19 01:10:26 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 01:10:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 01:10:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 01:10:26 - SRCCONF=/dev/null TB --- 2011-10-19 01:10:26 - TARGET=amd64 TB --- 2011-10-19 01:10:26 - TARGET_ARCH=amd64 TB --- 2011-10-19 01:10:26 - TZ=UTC TB --- 2011-10-19 01:10:26 - __MAKE_CONF=/dev/null TB --- 2011-10-19 01:10:26 - cd /src TB --- 2011-10-19 01:10:26 - /usr/bin/make -B buildworld World build started on Wed Oct 19 01:10:26 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-19 01:55:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 01:55:32 - ERROR: failed to build world TB --- 2011-10-19 01:55:32 - 2091.32 user 476.83 system 2732.58 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ 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
config(8) does not add post-processing for source file with compile-with command in sys/conf/files
when I digged the a PR(bin/160275), I found in_proto.c and
if_ethersubr.c ( see sys/conf/files ) does not get
${NORMAL_CTFCONVERT} post-processing in Makefile
(/usr/obj/usr/src/sys/MYKERNEL/Makefile) generated by config(8), so
the objs does not contain ctf section
In /usr/src/usr.sbin/config/mkmakefile.c, line 746
}
compilewith = ftp-f_compilewith;
if (compilewith == 0) { // no compile-with
const char *ftype = NULL;
switch (ftp-f_type) {
case NORMAL:
ftype = NORMAL;
break;
case PROFILING:
if (!profiling)
continue;
ftype = PROFILE;
break;
default:
fprintf(stderr,
config: don't know rules for %s\n, np);
break;
}
// only add post-processing for source file without compile-with
snprintf(cmd, sizeof(cmd),
${%s_%c%s}\n\t@${NORMAL_CTFCONVERT}, ftype,
toupper(och),
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
*cp = och;
if (strlen(ftp-f_objprefix))
fprintf(f, \t%s $S/%s\n\n, compilewith, np);
else
fprintf(f, \t%s\n\n, compilewith);
}
}
I wonder whether it was NOT allowed to add post-processing to files
with compile-with, license or other issues?
if not a license issue, then I wonder if this fix is OK( I test it on
8-stable with gcc, and 9-stable with both gcc and clang)
diff --git a/usr.sbin/config/mkmakefile.c b/usr.sbin/config/mkmakefile.c
index 2372839..25a85de 100644
--- a/usr.sbin/config/mkmakefile.c
+++ b/usr.sbin/config/mkmakefile.c
@@ -767,6 +767,14 @@ do_rules(FILE *f)
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
+ //handle CTF issule with NORMAL_C and NORMAL_C_NOERROR
+ else if (!strncmp(compilewith, ${NORMAL_C,sizeof(${NORMAL_C))) {
+ snprintf(cmd, sizeof(cmd),
+%s\n\t@${NORMAL_CTFCONVERT}, compilewith);
+ compilewith = cmd;
+ }
___
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
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-10-19 01:55:33 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 01:55:33 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-10-19 01:55:33 - cleaning the object tree TB --- 2011-10-19 01:55:38 - cvsupping the source tree TB --- 2011-10-19 01:55:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-10-19 01:55:49 - building world TB --- 2011-10-19 01:55:49 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 01:55:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 01:55:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 01:55:49 - SRCCONF=/dev/null TB --- 2011-10-19 01:55:49 - TARGET=powerpc TB --- 2011-10-19 01:55:49 - TARGET_ARCH=powerpc TB --- 2011-10-19 01:55:49 - TZ=UTC TB --- 2011-10-19 01:55:49 - __MAKE_CONF=/dev/null TB --- 2011-10-19 01:55:49 - cd /src TB --- 2011-10-19 01:55:49 - /usr/bin/make -B buildworld World build started on Wed Oct 19 01:55:49 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-19 02:40:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 02:40:46 - ERROR: failed to build world TB --- 2011-10-19 02:40:46 - 2044.12 user 459.25 system 2713.24 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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
[head tinderbox] failure on i386/i386
TB --- 2011-10-19 04:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 04:40:01 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-19 04:40:01 - cleaning the object tree TB --- 2011-10-19 04:40:08 - cvsupping the source tree TB --- 2011-10-19 04:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-19 04:40:25 - building world TB --- 2011-10-19 04:40:25 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 04:40:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 04:40:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 04:40:25 - SRCCONF=/dev/null TB --- 2011-10-19 04:40:25 - TARGET=i386 TB --- 2011-10-19 04:40:25 - TARGET_ARCH=i386 TB --- 2011-10-19 04:40:25 - TZ=UTC TB --- 2011-10-19 04:40:25 - __MAKE_CONF=/dev/null TB --- 2011-10-19 04:40:25 - cd /src TB --- 2011-10-19 04:40:25 - /usr/bin/make -B buildworld World build started on Wed Oct 19 04:40:26 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-19 05:25:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 05:25:10 - ERROR: failed to build world TB --- 2011-10-19 05:25:10 - 2090.01 user 465.27 system 2709.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ 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
[head tinderbox] failure on i386/pc98
TB --- 2011-10-19 04:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 04:40:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-19 04:40:01 - cleaning the object tree TB --- 2011-10-19 04:40:08 - cvsupping the source tree TB --- 2011-10-19 04:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-19 04:40:25 - building world TB --- 2011-10-19 04:40:25 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 04:40:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 04:40:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 04:40:25 - SRCCONF=/dev/null TB --- 2011-10-19 04:40:25 - TARGET=pc98 TB --- 2011-10-19 04:40:25 - TARGET_ARCH=i386 TB --- 2011-10-19 04:40:25 - TZ=UTC TB --- 2011-10-19 04:40:25 - __MAKE_CONF=/dev/null TB --- 2011-10-19 04:40:25 - cd /src TB --- 2011-10-19 04:40:25 - /usr/bin/make -B buildworld World build started on Wed Oct 19 04:40:25 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-19 05:25:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 05:25:25 - ERROR: failed to build world TB --- 2011-10-19 05:25:25 - 2092.46 user 475.00 system 2724.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full ___ 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
[head tinderbox] failure on amd64/amd64
TB --- 2011-10-19 04:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 04:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-19 04:40:01 - cleaning the object tree TB --- 2011-10-19 04:40:08 - cvsupping the source tree TB --- 2011-10-19 04:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-19 04:40:25 - building world TB --- 2011-10-19 04:40:25 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 04:40:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 04:40:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 04:40:25 - SRCCONF=/dev/null TB --- 2011-10-19 04:40:25 - TARGET=amd64 TB --- 2011-10-19 04:40:25 - TARGET_ARCH=amd64 TB --- 2011-10-19 04:40:25 - TZ=UTC TB --- 2011-10-19 04:40:25 - __MAKE_CONF=/dev/null TB --- 2011-10-19 04:40:25 - cd /src TB --- 2011-10-19 04:40:25 - /usr/bin/make -B buildworld World build started on Wed Oct 19 04:40:26 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-19 05:25:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 05:25:59 - ERROR: failed to build world TB --- 2011-10-19 05:26:00 - 2118.74 user 477.88 system 2758.97 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ 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
