From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 03:23:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 603166B7; Sun, 24 Nov 2013 03:23:38 +0000 (UTC) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 346BA2A88; Sun, 24 Nov 2013 03:23:38 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 4241A613D; Sat, 23 Nov 2013 22:23:29 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Z0pOp5/n+45+IXivgEZrwAJdFtvHVLGqNtmZzxixlk5O0CRPDnggv9I4MKBy9+5CO 1ypPzZhGHHbNYlW0MpNZZKRYReD6qLjPL+M2w0MLQho6NDtoBSkmFXSkx4GsLM7 Message-ID: <5291712E.305@protected-networks.net> Date: Sat, 23 Nov 2013 22:23:26 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current Subject: gcc in -current broken X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pfg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 03:23:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After SVN r258501, I get .. ===> gnu/usr.bin/cc/cc1 (all) - --- cc1-dummy --- cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H - -DPREFIX=\"/usr/obj/usr/src/tmp/usr\" - -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber - -std=gnu89 -I/usr/obj/usr/src/tmp/legacy/usr/include -static - -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o c-lang.o /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a - -legacy /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o): In function `preprocess_file': c-ppoutput.c:(.text+0xc75): undefined reference to `_cpp_preprocess_dir_only' /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o): In function `compute_may_aliases': tree-ssa-alias.c:(.text+0x64cb): undefined reference to `strict_aliasing_warning_backend' *** [cc1-dummy] Error code 1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlKRcS4ACgkQQv9rrgRC1JIb8wCglaUhK0AjvtDvF7RW7GZT8H3d 2I0AoI57UJNDpmZebf7SYsP9QdgsfvFx =y9Yf -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 04:07:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE34DABA for ; Sun, 24 Nov 2013 04:07:57 +0000 (UTC) Received: from nm33-vm5.bullet.mail.bf1.yahoo.com (nm33-vm5.bullet.mail.bf1.yahoo.com [72.30.239.205]) by mx1.freebsd.org (Postfix) with SMTP id 4B49E2BFB for ; Sun, 24 Nov 2013 04:07:56 +0000 (UTC) Received: from [98.139.212.150] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 24 Nov 2013 04:04:39 -0000 Received: from [98.139.211.198] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 24 Nov 2013 04:04:39 -0000 Received: from [127.0.0.1] by smtp207.mail.bf1.yahoo.com with NNFMP; 24 Nov 2013 04:04:39 -0000 X-Yahoo-Newman-Id: 749447.67733.bm@smtp207.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: mM6qMiIVM1lhLSyJQuGMOZqrv4ISl5co5.cww_.Cx3h8vaD OrZec4IVG1GZtAZ5DJFYJboi20VsOpNFi.frUOTERJtQLPTrX_0pA0SXAnLt jBCvIzzzt4lyn8s78rleeqovx.AIzJVtFrTd49sN6m8XBqfxMngKx7Po8Ub_ GbysOopE2Hg0SCPKjKmPkMenFKnyfw16pAVjnspu379UpytLtjrupIxYqZZ9 HQcpKgKx7l6UU1ziI34PQBmYmawPriD1kf2RxzGlLJLCRrdVUIL_m3gFpGGJ N5gmVDqMu6g2c07AStgjgXDErm_1M3YQytJLkarqn0Knh3Ni84QC4n6WcSuG 3CglZBtRN_jlyfjdwt0Dg5XRWsQPxviDemicv5V0o66jNPT0EudhYy64r2IL 0ban.xxOCoeKn066JS8of6dLdfoIfn3e.P.BNwlx2BoAZb1TTGjvENTnWtsq hJjCwVE67S6HS3WPt4Uf38QfRUQ.dmzFHo6wwwgcOGdF4tGeEpePmampLrHN BAHl9DKpaM_z_WVzvEiip_hvH_ll.iJaNTpl1jNiVIWqPthDsHcGA_w-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp207.mail.bf1.yahoo.com with SMTP; 23 Nov 2013 20:04:39 -0800 PST Message-ID: <52917AD4.7050907@FreeBSD.org> Date: Sat, 23 Nov 2013 23:04:36 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Michael Butler , freebsd-current Subject: Re: gcc in -current broken References: <5291712E.305@protected-networks.net> In-Reply-To: <5291712E.305@protected-networks.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 04:07:57 -0000 On 23.11.2013 22:23, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > After SVN r258501, I get .. > > ===> gnu/usr.bin/cc/cc1 (all) > - --- cc1-dummy --- > cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H > - -DPREFIX=\"/usr/obj/usr/src/tmp/usr\" > - -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools > - -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools > - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc > - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config > - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include > - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include > - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber > - -std=gnu89 -I/usr/obj/usr/src/tmp/legacy/usr/include -static > - -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o > c-lang.o > /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a > /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a > /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a > /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a > - -legacy > /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o): > In function `preprocess_file': > c-ppoutput.c:(.text+0xc75): undefined reference to > `_cpp_preprocess_dir_only' > /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o): > In function `compute_may_aliases': > tree-ssa-alias.c:(.text+0x64cb): undefined reference to > `strict_aliasing_warning_backend' > *** [cc1-dummy] Error code 1 Ugh... can't believe it .... I found the issue.. just one missing commit in gnu/../../libcpp. Will be fixed shortly. Thanks! Pedro. From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 07:43:37 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30D75C51 for ; Sun, 24 Nov 2013 07:43:37 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D74C238E for ; Sun, 24 Nov 2013 07:43:36 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAO7hU9e026518 for ; Sat, 23 Nov 2013 23:43:34 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311240743.rAO7hU9e026518@gw.catspoiler.org> Date: Sat, 23 Nov 2013 23:43:30 -0800 (PST) From: Don Lewis Subject: panic: double fault with 11.0-CURRENT r258504 To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 07:43:37 -0000 I upgraded my 11.0-CURRENT machine to r258504 to get past the uma panic that I stumbled across earlier. Now I got this when I started upgrading ports: Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc0b158e0 esp = 0xe4f62000 ebp = 0xe4f62010 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c113340c,2,10000000,c15a0cf0,c15a0ce8,...) at db_trace_self_wrapper+0x2d/frame 0xc15a0cb0 kdb_backtrace(c12f143f,0,c12f2aea,c15a0d6c,0,...) at kdb_backtrace+0x30/frame 0xc15a0d18 vpanic(c15a0d6c,c15a0d84,c0fc14fb,c12f2aea,0,...) at vpanic+0x11f/frame 0xc15a0d54 panic(c12f2aea,0,0,0,e4f62010,...) at panic+0x12/frame 0xc15a0d60 dblfault_handler() at dblfault_handler+0xab/frame 0xc15a0d60 --- trap 0x17, eip = 0xc0b158e0, esp = 0xe4f62000, ebp = 0xe4f62010 --- vprintf(c12f2900,c,fffffe7f,fffffeff,bfff75ed,...) at vprintf/frame 0xe4f62010 trap(e4f62164) at trap+0x18a/frame 0xe4f62158 calltrap() at calltrap+0x6/frame 0xe4f62158 --- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f621a4, ebp = 0xe4f62270 --- kvprintf(c12f2900,c0b15210,e4f62290,a,e4f6235c,...) at kvprintf+0x1cd/frame 0xe4f62270 vprintf(c12f2900,e4f6235c,e4f6235c) at vprintf+0x7f/frame 0xe4f6233c printf(c12f2900,c,ffefdfff,ebefefff,dfdffedf,...) at printf+0x1b/frame 0xe4f62350 trap(e4f624a4) at trap+0x18a/frame 0xe4f62498 calltrap() at calltrap+0x6/frame 0xe4f62498 --- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f624e4, ebp = 0xe4f625b0 --- kvprintf(c12f2900,c0b15210,e4f625d0,a,e4f6269c,...) at kvprintf+0x1cd/frame 0xe4f625b0 vprintf(c12f2900,e4f6269c,e4f6269c) at vprintf+0x7f/frame 0xe4f6267c printf(c12f2900,c,5fd7ff5f,ba77f7fb,bfffb7ff,...) at printf+0x1b/frame 0xe4f62690 trap(e4f627e4) at trap+0x18a/frame 0xe4f627d8 calltrap() at calltrap+0x6/frame 0xe4f627d8 --- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f62824, ebp = 0xe4f628f0 --- kvprintf(c12f2900,c0b15210,e4f62910,a,e4f629dc,...) at kvprintf+0x1cd/frame 0xe4f628f0 vprintf(c12f2900,e4f629dc,e4f629dc) at vprintf+0x7f/frame 0xe4f629bc printf(c12f2900,c,0,80000000,c0,...) at printf+0x1b/frame 0xe4f629d0 trap(e4f62b20) at trap+0x18a/frame 0xe4f62b14 calltrap() at calltrap+0x6/frame 0xe4f62b14 --- trap 0xc, eip = 0xc0afe270, esp = 0xe4f62b60, ebp = 0xe4f62b78 --- tdq_choose(c141e090,4,c113144d,917,c2425c80,...) at tdq_choose+0x60/frame 0xe4f62b78 sched_choose(e4f62c00,c0afc511,c141e090,14,c113144d,...) at sched_choose+0x4c/frame 0xe4f62ba4 choosethread(c141e090,14,c113144d,78b,c141e116,...) at choosethread+0x1f/frame 0xe4f62bac sched_switch(c8f04000,0,608,1b7,ef2,...) at sched_switch+0x361/frame 0xe4f62c00 mi_switch(608,0,c112f4e4,d3,c,...) at mi_switch+0x1c9/frame 0xe4f62c34 critical_exit(0,2,c113144d,411,c141e108,...) at critical_exit+0xa4/frame 0xe4f62c50 sched_idletd(0,e4f62d08,c1128634,3db,0,...) at sched_idletd+0x1d6/frame 0xe4f62ccc fork_exit(c0afeb00,0,e4f62d08) at fork_exit+0x7f/frame 0xe4f62cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xe4f62cf4 --- trap 0, eip = 0, esp = 0xe4f62d40, ebp = 0 --- KDB: enter: panic (kgdb) list *tdq_choose+0x60 0xc0afe270 is in tdq_choose (/usr/src/sys/kern/sched_ule.c:1334). 1329 td = runq_choose(&tdq->tdq_realtime); 1330 if (td != NULL) 1331 return (td); 1332 td = runq_choose_from(&tdq->tdq_timeshare, tdq->tdq_ridx); 1333 if (td != NULL) { 1334 KASSERT(td->td_priority >= PRI_MIN_BATCH, 1335 ("tdq_choose: Invalid priority on timeshare queue %d", 1336 td->td_priority)); 1337 return (td); 1338 } (kgdb) bt #0 doadump (textdump=-1051128300) at pcpu.h:233 #1 0xc052766d in db_fncall (dummy1=-1051051648, dummy2=0, dummy3=-1051063684, dummy4=0xc15a0a54 "") at /usr/src/sys/ddb/db_command.c:578 #2 0xc0527357 in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:449 #3 0xc0527090 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xc0529922 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xc0b0ff38 in kdb_trap (type=, code=, tf=) at /usr/src/sys/kern/subr_kdb.c:656 #6 0xc0fc0c07 in trap (frame=) at /usr/src/sys/i386/i386/trap.c:712 #7 0xc0faa0ec in calltrap () at /usr/src/sys/i386/i386/exception.s:170 #8 0xc0b0f7bd in kdb_enter (why=0xc112ee39 "panic", msg=) at cpufunc.h:71 #9 0xc0ad6a93 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:747 #10 0xc0ad6ad2 in panic (fmt=0xc12f2aea "double fault") at /usr/src/sys/kern/kern_shutdown.c:683 #11 0xc0fc14fb in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:1072 #12 0x00000000 in ?? () From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 07:44:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51158D6C; Sun, 24 Nov 2013 07:44:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A2FA23A2; Sun, 24 Nov 2013 07:44:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAO7iR7K081016; Sun, 24 Nov 2013 02:44:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAO7iRtN081015; Sun, 24 Nov 2013 07:44:27 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 07:44:27 GMT Message-Id: <201311240744.rAO7iRtN081015@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 07:44:28 -0000 TB --- 2013-11-24 07:36:16 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 07:36:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 07:36:16 - starting HEAD tinderbox run for mips/mips TB --- 2013-11-24 07:36:16 - cleaning the object tree TB --- 2013-11-24 07:36:16 - /usr/local/bin/svn stat /src TB --- 2013-11-24 07:36:19 - At svn revision 258506 TB --- 2013-11-24 07:36:20 - building world TB --- 2013-11-24 07:36:20 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 07:36:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 07:36:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 07:36:20 - SRCCONF=/dev/null TB --- 2013-11-24 07:36:20 - TARGET=mips TB --- 2013-11-24 07:36:20 - TARGET_ARCH=mips TB --- 2013-11-24 07:36:20 - TZ=UTC TB --- 2013-11-24 07:36:20 - __MAKE_CONF=/dev/null TB --- 2013-11-24 07:36:20 - cd /src TB --- 2013-11-24 07:36:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 07:36:26 UTC 2013 >>> 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 [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips3\" -I/obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/mips.mips/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips3\" -I/obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/mips.mips/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips3\" -I/obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/mips.mips/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips3\" -I/obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/mips.mips/src/tmp/legacy/usr/include -static -L/obj/mips.mips/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o c-lang.o /obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a /obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc! 1/../libiberty/libiberty.a -legacy /obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o)(.text+0xbce): In function `preprocess_file': : undefined reference to `_cpp_preprocess_dir_only' /obj/mips.mips/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o)(.text+0x6083): In function `compute_may_aliases': : undefined reference to `strict_aliasing_warning_backend' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1 *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 07:44:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 07:44:27 - ERROR: failed to build world TB --- 2013-11-24 07:44:27 - 393.51 user 60.53 system 490.96 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 07:46:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D694FEE3; Sun, 24 Nov 2013 07:46:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9EA8623BD; Sun, 24 Nov 2013 07:46:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAO7aFTN038783; Sun, 24 Nov 2013 02:36:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAO7aF9J038782; Sun, 24 Nov 2013 07:36:15 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 07:36:15 GMT Message-Id: <201311240736.rAO7aF9J038782@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 07:46:25 -0000 TB --- 2013-11-24 07:27:51 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 07:27:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 07:27:51 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-11-24 07:27:51 - cleaning the object tree TB --- 2013-11-24 07:27:51 - /usr/local/bin/svn stat /src TB --- 2013-11-24 07:27:55 - At svn revision 258506 TB --- 2013-11-24 07:27:56 - building world TB --- 2013-11-24 07:27:56 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 07:27:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 07:27:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 07:27:56 - SRCCONF=/dev/null TB --- 2013-11-24 07:27:56 - TARGET=ia64 TB --- 2013-11-24 07:27:56 - TARGET_ARCH=ia64 TB --- 2013-11-24 07:27:56 - TZ=UTC TB --- 2013-11-24 07:27:56 - __MAKE_CONF=/dev/null TB --- 2013-11-24 07:27:56 - cd /src TB --- 2013-11-24 07:27:56 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 07:28:03 UTC 2013 >>> 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 [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64.ia64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64.ia64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64.ia64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64.ia64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -static -L/obj/ia64.ia64/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o c-lang.o /obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a /obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a -legacy /obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o)(.text+0xbce): In function `preprocess_file': : undefined reference to `_cpp_preprocess_dir_only' /obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o)(.text+0x6083): In function `compute_may_aliases': : undefined reference to `strict_aliasing_warning_backend' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1 *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 07:36:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 07:36:15 - ERROR: failed to build world TB --- 2013-11-24 07:36:15 - 399.66 user 57.27 system 504.31 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 07:52:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3D642B5; Sun, 24 Nov 2013 07:52:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D964241F; Sun, 24 Nov 2013 07:52:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAO7qlrI060287; Sun, 24 Nov 2013 02:52:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAO7qlpQ060286; Sun, 24 Nov 2013 07:52:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 07:52:47 GMT Message-Id: <201311240752.rAO7qlpQ060286@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 07:52:51 -0000 TB --- 2013-11-24 07:44:27 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 07:44:27 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 07:44:27 - starting HEAD tinderbox run for mips64/mips TB --- 2013-11-24 07:44:27 - cleaning the object tree TB --- 2013-11-24 07:44:27 - /usr/local/bin/svn stat /src TB --- 2013-11-24 07:44:30 - At svn revision 258506 TB --- 2013-11-24 07:44:31 - building world TB --- 2013-11-24 07:44:31 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 07:44:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 07:44:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 07:44:31 - SRCCONF=/dev/null TB --- 2013-11-24 07:44:31 - TARGET=mips TB --- 2013-11-24 07:44:31 - TARGET_ARCH=mips64 TB --- 2013-11-24 07:44:31 - TZ=UTC TB --- 2013-11-24 07:44:31 - __MAKE_CONF=/dev/null TB --- 2013-11-24 07:44:31 - cd /src TB --- 2013-11-24 07:44:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 07:44:38 UTC 2013 >>> 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 [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -DMIPS_ABI_DEFAULT=ABI_64 -I/obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/mips.mips64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -DMIPS_ABI_DEFAULT=ABI_64 -I/obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/mips.mips64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -DMIPS_ABI_DEFAULT=ABI_64 -I/obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/mips.mips64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/mips.mips64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -DMIPS_ABI_DEFAULT=ABI_64 -I/obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/mips.mips64/src/tmp/legacy/usr/include -static -L/obj/mips.mips64/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o c-lang.o /obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a /obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1/../libiberty/libib! erty.a -legacy /obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o)(.text+0xbce): In function `preprocess_file': : undefined reference to `_cpp_preprocess_dir_only' /obj/mips.mips64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o)(.text+0x6083): In function `compute_may_aliases': : undefined reference to `strict_aliasing_warning_backend' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1 *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 07:52:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 07:52:47 - ERROR: failed to build world TB --- 2013-11-24 07:52:47 - 394.15 user 75.17 system 500.10 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 08:04:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B514F5F3; Sun, 24 Nov 2013 08:04:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8AA5324B4; Sun, 24 Nov 2013 08:04:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAO84oDr099569; Sun, 24 Nov 2013 03:04:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAO84oU4099568; Sun, 24 Nov 2013 08:04:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 08:04:50 GMT Message-Id: <201311240804.rAO84oU4099568@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 08:04:51 -0000 TB --- 2013-11-24 07:52:47 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 07:52:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 07:52:47 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-24 07:52:47 - cleaning the object tree TB --- 2013-11-24 07:52:47 - /usr/local/bin/svn stat /src TB --- 2013-11-24 07:52:51 - At svn revision 258506 TB --- 2013-11-24 07:52:52 - building world TB --- 2013-11-24 07:52:52 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 07:52:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 07:52:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 07:52:52 - SRCCONF=/dev/null TB --- 2013-11-24 07:52:52 - TARGET=powerpc TB --- 2013-11-24 07:52:52 - TARGET_ARCH=powerpc TB --- 2013-11-24 07:52:52 - TZ=UTC TB --- 2013-11-24 07:52:52 - __MAKE_CONF=/dev/null TB --- 2013-11-24 07:52:52 - cd /src TB --- 2013-11-24 07:52:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 07:52:58 UTC 2013 >>> 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 [...] In file included from /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools/tm.h:11, from /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c:26: /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config/freebsd.h:77:1: warning: this is the location of the previous definition cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/powerpc.powerpc/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/powerpc.powerpc/src/tmp/legacy/usr/include -static -L/obj/powerpc.powerpc/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o c-lang.o /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1/../libiberty! /libiberty.a -legacy /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o)(.text+0xbce): In function `preprocess_file': : undefined reference to `_cpp_preprocess_dir_only' /obj/powerpc.powerpc/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o)(.text+0x6083): In function `compute_may_aliases': : undefined reference to `strict_aliasing_warning_backend' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1 *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 08:04:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 08:04:50 - ERROR: failed to build world TB --- 2013-11-24 08:04:50 - 593.75 user 73.98 system 722.80 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 08:11:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D09A7809; Sun, 24 Nov 2013 08:11:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99F0A2514; Sun, 24 Nov 2013 08:11:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAO8BTSq016152; Sun, 24 Nov 2013 03:11:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAO8BTaX016151; Sun, 24 Nov 2013 08:11:29 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 08:11:29 GMT Message-Id: <201311240811.rAO8BTaX016151@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 08:11:30 -0000 TB --- 2013-11-24 06:55:33 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 06:55:33 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 06:55:33 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-11-24 06:55:33 - cleaning the object tree TB --- 2013-11-24 06:55:33 - /usr/local/bin/svn stat /src TB --- 2013-11-24 06:56:01 - At svn revision 258506 TB --- 2013-11-24 06:56:02 - building world TB --- 2013-11-24 06:56:02 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 06:56:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 06:56:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 06:56:02 - SRCCONF=/dev/null TB --- 2013-11-24 06:56:02 - TARGET=pc98 TB --- 2013-11-24 06:56:02 - TARGET_ARCH=i386 TB --- 2013-11-24 06:56:02 - TZ=UTC TB --- 2013-11-24 06:56:02 - __MAKE_CONF=/dev/null TB --- 2013-11-24 06:56:02 - cd /src TB --- 2013-11-24 06:56:02 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 06:56:10 UTC 2013 >>> 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 [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/pc98.i386/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/pc98.i386/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/pc98.i386/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/pc98.i386/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/pc98.i386/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/pc98.i386/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/pc98.i386/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/pc98.i386/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/pc98.i386/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/pc98.i386/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/pc98.i386/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/pc98.i386/src/tmp/legacy/usr/include -static -L/obj/pc98.i386/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o c-lang.o /obj/pc98.i386/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a /obj/pc98.i386/src/tmp/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /obj/pc98.i386/src/tmp/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /obj/pc98.i386/src/tmp/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a -legacy /obj/pc98.i386/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o)(.text+0xbce): In function `preprocess_file': : undefined reference to `_cpp_preprocess_dir_only' /obj/pc98.i386/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o)(.text+0x6083): In function `compute_may_aliases': : undefined reference to `strict_aliasing_warning_backend' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1 *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 08:11:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 08:11:29 - ERROR: failed to build world TB --- 2013-11-24 08:11:29 - 3887.56 user 401.28 system 4556.02 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 08:20:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 130C4B44; Sun, 24 Nov 2013 08:20:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D0273257E; Sun, 24 Nov 2013 08:20:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAO8K9Rq085237; Sun, 24 Nov 2013 03:20:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAO8K9Va085233; Sun, 24 Nov 2013 08:20:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 08:20:09 GMT Message-Id: <201311240820.rAO8K9Va085233@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 08:20:11 -0000 TB --- 2013-11-24 08:11:29 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 08:11:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 08:11:29 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-11-24 08:11:29 - cleaning the object tree TB --- 2013-11-24 08:11:29 - /usr/local/bin/svn stat /src TB --- 2013-11-24 08:12:28 - At svn revision 258506 TB --- 2013-11-24 08:12:29 - building world TB --- 2013-11-24 08:12:29 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 08:12:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 08:12:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 08:12:29 - SRCCONF=/dev/null TB --- 2013-11-24 08:12:29 - TARGET=sparc64 TB --- 2013-11-24 08:12:29 - TARGET_ARCH=sparc64 TB --- 2013-11-24 08:12:29 - TZ=UTC TB --- 2013-11-24 08:12:29 - __MAKE_CONF=/dev/null TB --- 2013-11-24 08:12:29 - cd /src TB --- 2013-11-24 08:12:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 08:12:37 UTC 2013 >>> 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 [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/sparc64.sparc64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/sparc64.sparc64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/sparc64.sparc64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/sparc64.sparc64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -static -L/obj/sparc64.sparc64/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o c-lang.o /obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a /obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1/../libiberty! /libiberty.a -legacy /obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o)(.text+0xbce): In function `preprocess_file': : undefined reference to `_cpp_preprocess_dir_only' /obj/sparc64.sparc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o)(.text+0x6083): In function `compute_may_aliases': : undefined reference to `strict_aliasing_warning_backend' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1 *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 08:20:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 08:20:09 - ERROR: failed to build world TB --- 2013-11-24 08:20:09 - 355.49 user 56.44 system 519.30 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 08:20:27 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 632A9C72; Sun, 24 Nov 2013 08:20:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2BDCC2595; Sun, 24 Nov 2013 08:20:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAO8KQeg086094; Sun, 24 Nov 2013 03:20:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAO8KQMv086088; Sun, 24 Nov 2013 08:20:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 08:20:26 GMT Message-Id: <201311240820.rAO8KQMv086088@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 08:20:27 -0000 TB --- 2013-11-24 08:04:51 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 08:04:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 08:04:51 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-11-24 08:04:51 - cleaning the object tree TB --- 2013-11-24 08:04:51 - /usr/local/bin/svn stat /src TB --- 2013-11-24 08:05:10 - At svn revision 258506 TB --- 2013-11-24 08:05:11 - building world TB --- 2013-11-24 08:05:11 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 08:05:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 08:05:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 08:05:11 - SRCCONF=/dev/null TB --- 2013-11-24 08:05:11 - TARGET=powerpc TB --- 2013-11-24 08:05:11 - TARGET_ARCH=powerpc64 TB --- 2013-11-24 08:05:11 - TZ=UTC TB --- 2013-11-24 08:05:11 - __MAKE_CONF=/dev/null TB --- 2013-11-24 08:05:11 - cd /src TB --- 2013-11-24 08:05:11 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 08:05:23 UTC 2013 >>> 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 [...] In file included from /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools/tm.h:12, from /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c:26: /src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config/freebsd.h:77:1: warning: this is the location of the previous definition cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/powerpc.powerpc64/src/tmp/usr\" -DCROSS_DIRECTORY_STRUCTURE -I/obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../cc_tools -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/powerpc.powerpc64/src/tmp/legacy/usr/include -static -L/obj/powerpc.powerpc64/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o c-lang.o /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/! cc1/../libiberty/libiberty.a -legacy /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o)(.text+0xbce): In function `preprocess_file': : undefined reference to `_cpp_preprocess_dir_only' /obj/powerpc.powerpc64/src/tmp/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o)(.text+0x6083): In function `compute_may_aliases': : undefined reference to `strict_aliasing_warning_backend' *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc1 *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 08:20:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 08:20:26 - ERROR: failed to build world TB --- 2013-11-24 08:20:26 - 604.16 user 85.09 system 935.21 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 16:14:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2902763; Sun, 24 Nov 2013 16:14:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5320127E2; Sun, 24 Nov 2013 16:14:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAOGETe6098862; Sun, 24 Nov 2013 11:14:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAOGESsr098855; Sun, 24 Nov 2013 16:14:28 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 16:14:28 GMT Message-Id: <201311241614.rAOGESsr098855@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 16:14:31 -0000 TB --- 2013-11-24 14:40:44 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 14:40:44 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 14:40:44 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-11-24 14:40:44 - cleaning the object tree TB --- 2013-11-24 14:41:05 - /usr/local/bin/svn stat /src TB --- 2013-11-24 14:41:08 - At svn revision 258507 TB --- 2013-11-24 14:41:09 - building world TB --- 2013-11-24 14:41:09 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:41:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:41:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:41:09 - SRCCONF=/dev/null TB --- 2013-11-24 14:41:09 - TARGET=ia64 TB --- 2013-11-24 14:41:09 - TARGET_ARCH=ia64 TB --- 2013-11-24 14:41:09 - TZ=UTC TB --- 2013-11-24 14:41:09 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:41:09 - cd /src TB --- 2013-11-24 14:41:09 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 14:41:16 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 16:14:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 16:14:28 - ERROR: failed to build world TB --- 2013-11-24 16:14:28 - 4365.38 user 759.71 system 5624.12 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 16:41:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03DCAF8D for ; Sun, 24 Nov 2013 16:41:32 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C5ACB28F9 for ; Sun, 24 Nov 2013 16:41:31 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id n16so3427096oag.9 for ; Sun, 24 Nov 2013 08:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WzsuXf1q+3coa8yGfU6IKJWbvvpkEaIE2SY5FFrjIEU=; b=CBVvHgF/+g7dc1HSHabQb09sgYaVsip0pAX5hgbYUdnBQjsVhkBhwaG++yNp+Y58he 5tVP9Lwxle2cB9g1q9vJmFz6O42tPoKuzAcm9IERi3gjvuxeqnjBjCXE4kW6EMURhB/8 1lZY4vlkJBp1hF6ojO35tY8abJzEKYiQ3JNkCRRzy9u3HEm4neAnqekZW6EimaNkX9jk dOBSKPmfDSex95Hbnuo08R7F/L+e0F1SqG4KiQ/WG6RN5H8IOASvgkO2Y1x57ib/KNGO oO0zuyhJJmwj66XwZEqlCbUkXoKMdz0at6mSGD/Acif2VHJ4Gibc82Bbcvd41d5Eyl2k nE9w== MIME-Version: 1.0 X-Received: by 10.60.98.168 with SMTP id ej8mr1143650oeb.45.1385311291006; Sun, 24 Nov 2013 08:41:31 -0800 (PST) Received: by 10.182.78.100 with HTTP; Sun, 24 Nov 2013 08:41:30 -0800 (PST) In-Reply-To: <7076908.jUUDNzHvnc@lumiwa.farms.net> References: <7076908.jUUDNzHvnc@lumiwa.farms.net> Date: Sun, 24 Nov 2013 11:41:30 -0500 Message-ID: Subject: Re: problems From: Joe Nosay To: Ajtim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 16:41:32 -0000 Edit the Makefile to include" USE_GCC= yes" - sans quotation marks - with nvi or another editor. Some programs will not compile with the new Clang default. On Sat, Nov 23, 2013 at 7:48 AM, Ajtim wrote: > Hi! > > I tried to build some programs on FreeBSD 10.0-BETA3 and as they told me > there is not a problem to build on FreeBSD 9.2 for example (amd64) but on > my system doesn't work: > > math/sage > k3b-kde4 > multimedia/vlc > audio/last.fm > > There are more but the above four I like to have. > > What is your experience, please? > > Thank you. > > -- > Mitja > ------- > http://www.redbubble.com/people.lumiwa > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 17:31:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5BC39DA for ; Sun, 24 Nov 2013 17:31:09 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87C322B0F for ; Sun, 24 Nov 2013 17:31:09 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id ii20so5390672qab.8 for ; Sun, 24 Nov 2013 09:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=XQAd3O595rUcSAZzOGM6ok34i0z3ft51SVeH1ZcSAL0=; b=pXSjKJqZPdti/YOtguZVCF1pS+wDvdHWTjULrGYmfFMeZinoPLdBLvf1lnU7S4/LYY LW3PKnDHFDjdQbcgosxte3bBwqBQRf/h0rr3AwvZEFhzRJsGd8J2k2Hy85tdLS8kVKxl 68qHj7Z9Uszt4x+205VHdSyRQf6OOKyN4lWQaFekLn8XndFuaeYfBf1yzfreUg49uOoC eihJSvy7VEHESuohzRoRe94sfRELwPGgfgEGZ7e0/Mdz9NX01y7UnlqbKEE5VKqQ4ol3 oQ65Vv9TGcFEY8gOVaiiny8kWL76EuVv2lIWK3KhK4ATs3sLLL75bc1Xm389gbVoweNB thVg== X-Received: by 10.224.45.197 with SMTP id g5mr40116213qaf.2.1385314268692; Sun, 24 Nov 2013 09:31:08 -0800 (PST) Received: from lumiwa.farms.net (pool-70-105-224-61.port.east.myfairpoint.net. [70.105.224.61]) by mx.google.com with ESMTPSA id k11sm67347500qab.3.2013.11.24.09.31.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Nov 2013 09:31:07 -0800 (PST) From: Ajtim To: Joe Nosay Subject: Re: problems Date: Sun, 24 Nov 2013 12:31:04 -0500 Message-ID: <1687164.D0bsi2sOL3@lumiwa.farms.net> User-Agent: KMail/4.11.3 (FreeBSD/10.0-BETA3; KDE/4.11.3; amd64; ; ) In-Reply-To: References: <7076908.jUUDNzHvnc@lumiwa.farms.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 17:31:09 -0000 On Sunday 24 November 2013 11:41:30 Joe Nosay wrote: > Edit the Makefile to include" USE_GCC= yes" - sans quotation marks - with > nvi or another editor. > Some programs will not compile with the new Clang default. > > > On Sat, Nov 23, 2013 at 7:48 AM, Ajtim wrote: > > > Hi! > > > > I tried to build some programs on FreeBSD 10.0-BETA3 and as they told me > > there is not a problem to build on FreeBSD 9.2 for example (amd64) but on > > my system doesn't work: > > > > math/sage > > k3b-kde4 > > multimedia/vlc > > audio/last.fm > > > > There are more but the above four I like to have. > > > > What is your experience, please? > > > > Thank you. > > > > -- > > Mitja > > ------- > > http://www.redbubble.com/people.lumiwa > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > I did try to use "USE_GCC=any "and it didn't work. -- Mitja ------- http://www.redbubble.com/people.lumiwa From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 17:46:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 689A1ECB; Sun, 24 Nov 2013 17:46:55 +0000 (UTC) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 257322BC6; Sun, 24 Nov 2013 17:46:54 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.5.2 olymp.kibab.com BF39C3F447 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kibab.com; s=default; t=1385315213; bh=m1JaC73PHdoBY8P+CQ+G+IjrFmu2KoeI/G2EHQa6mvc=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Qg6rmajcQp2o8t/+eCNW4CjHSKKtRGBibVvJ/1glqjxmKGe4IHwIckwI8pLyCePTS h2vE4MrukEb5YOxMiVl1Ki4TfSr2u+8IbnE30t1jvLS5Hy7iZOmyrMzmf5+teatq7x lDt3LueDAe9YjZSDAasZefgnV4M0Vm2ncWyTkE00= Message-ID: <52923B8A.6080405@kibab.com> Date: Sun, 24 Nov 2013 18:46:50 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: Dimitry Andric Subject: Re: i386 update to latest -HEAD broke things References: <7F77CAD4-3C04-4285-B6CF-DCEA35DC2390@FreeBSD.org> In-Reply-To: <7F77CAD4-3C04-4285-B6CF-DCEA35DC2390@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Gg4lgQeufwDLVHPKn6rfeRkff0rgkKhmo" Cc: Adrian Chadd , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 17:46:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Gg4lgQeufwDLVHPKn6rfeRkff0rgkKhmo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 22.11.13 11:49, Dimitry Andric wrote: > On 22 Nov 2013, at 04:23, Adrian Chadd wrote: >> I just updated a laptop from a month old -HEAD to the latest -HEAD. >> Things .. didn't work. >> >> * No processes ran - they'd complain about being out of anonymous memo= ry >> * /rescue/sh works fine, but /rescue/dhclient seems to be doing the >> wrong thing with regards to which dhclient-script it calls >> * .. and /rescue/dhclient-script also references things in /, which >> doesn't work. Grr. > I think the fix for llvm PR 15086 (done in r258455) is causing these > problems, since upstream apparently reported miscompilations with it > (which I haven't seen, but maybe I was just lucky). I will revert that= > tonight after $WORK, but if you can test reverting it locally, please > do. >=20 > -Dimitry >=20 I had the same problem with -CURRENT on i386 h/w. After updating to the r258507 (git ecc1dc84), where the r258455 is already reverted, it works again. Thanks! --=20 Regards, Ilya Bakulin --Gg4lgQeufwDLVHPKn6rfeRkff0rgkKhmo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKSO40ACgkQo9vlj1oadwhXOACfW8XYS3ZAFP6vXjJsH12yXa7j uHIAoNi6LhCRBhZ3p367Dv4oCf6uZ/Lm =JkTW -----END PGP SIGNATURE----- --Gg4lgQeufwDLVHPKn6rfeRkff0rgkKhmo-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 18:55:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D62639BD; Sun, 24 Nov 2013 18:55:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92D0E2F6A; Sun, 24 Nov 2013 18:55:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAOIt1Hm001335; Sun, 24 Nov 2013 13:55:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAOIt1nU001329; Sun, 24 Nov 2013 18:55:01 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 18:55:01 GMT Message-Id: <201311241855.rAOIt1nU001329@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 18:55:06 -0000 TB --- 2013-11-24 16:14:29 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 16:14:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 16:14:29 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-24 16:14:29 - cleaning the object tree TB --- 2013-11-24 16:14:43 - /usr/local/bin/svn stat /src TB --- 2013-11-24 16:14:47 - At svn revision 258507 TB --- 2013-11-24 16:14:48 - building world TB --- 2013-11-24 16:14:48 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 16:14:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 16:14:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 16:14:48 - SRCCONF=/dev/null TB --- 2013-11-24 16:14:48 - TARGET=powerpc TB --- 2013-11-24 16:14:48 - TARGET_ARCH=powerpc TB --- 2013-11-24 16:14:48 - TZ=UTC TB --- 2013-11-24 16:14:48 - __MAKE_CONF=/dev/null TB --- 2013-11-24 16:14:48 - cd /src TB --- 2013-11-24 16:14:48 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 16:14:54 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 18:55:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 18:55:01 - ERROR: failed to build world TB --- 2013-11-24 18:55:01 - 7994.15 user 1054.55 system 9631.80 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 19:11:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E47C443B for ; Sun, 24 Nov 2013 19:11:22 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B2085206F for ; Sun, 24 Nov 2013 19:11:22 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wp18so3338333obc.2 for ; Sun, 24 Nov 2013 11:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zCOqbWIr2x+R3m69FNHXwZPg89Xike36K/erA3g6SCk=; b=Ts/5SdwuwYWqu21otkWw9Ac3uX+/4dabs+Tqk4cbdTOhb7xb+jlI+oHGGmv5jBQ6ZO d+nCQzLsK/pHmtFWTwLFxqS/NVGwE2l7ZptjJzo4ctiREGxUFJM2BB4acARN1vnCXPg6 cD9eSgsipMxjmp9NgaCAQe9hoSvvl1izTfAxtFPFH6MVh5/x1e9HqFYi8whYbYKchh1l ozQuy/JtY5PA0mlT8d6mEz1hnEn5xetU0xkr2beQbLRoSdfkEBDhR2hiWQdfZMiepCG0 dk5NwqxA7nsEWpSlyHcvdcwRyhgJ94dOleUxunoOGLyLE18cCbGrkUsPy7ESukQPl0lx oMfQ== MIME-Version: 1.0 X-Received: by 10.182.102.7 with SMTP id fk7mr21583799obb.28.1385320281390; Sun, 24 Nov 2013 11:11:21 -0800 (PST) Received: by 10.182.78.100 with HTTP; Sun, 24 Nov 2013 11:11:21 -0800 (PST) In-Reply-To: <1687164.D0bsi2sOL3@lumiwa.farms.net> References: <7076908.jUUDNzHvnc@lumiwa.farms.net> <1687164.D0bsi2sOL3@lumiwa.farms.net> Date: Sun, 24 Nov 2013 14:11:21 -0500 Message-ID: Subject: Re: problems From: Joe Nosay To: Ajtim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 19:11:23 -0000 Give me a moment On Sun, Nov 24, 2013 at 12:31 PM, Ajtim wrote: > On Sunday 24 November 2013 11:41:30 Joe Nosay wrote: > > Edit the Makefile to include" USE_GCC= yes" - sans quotation marks - with > > nvi or another editor. > > Some programs will not compile with the new Clang default. > > > > > > On Sat, Nov 23, 2013 at 7:48 AM, Ajtim wrote: > > > > > Hi! > > > > > > I tried to build some programs on FreeBSD 10.0-BETA3 and as they told > me > > > there is not a problem to build on FreeBSD 9.2 for example (amd64) but > on > > > my system doesn't work: > > > > > > math/sage > > > k3b-kde4 > > > multimedia/vlc > > > audio/last.fm > > > > > > There are more but the above four I like to have. > > > > > > What is your experience, please? > > > > > > Thank you. > > > > > > -- > > > Mitja > > > ------- > > > http://www.redbubble.com/people.lumiwa > > > > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > > > I did try to use "USE_GCC=any "and it didn't work. > > -- > Mitja > ------- > http://www.redbubble.com/people.lumiwa > > From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 19:14:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D2B765D for ; Sun, 24 Nov 2013 19:14:47 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD3B2209A for ; Sun, 24 Nov 2013 19:14:46 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wp4so3364826obc.13 for ; Sun, 24 Nov 2013 11:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FReX19Ho5WEOQ4CbAXeOQOrXusHeP/o5MEF63S79R3Y=; b=PfpBJgVmcvPkHBGGJ5d/CrfamRlhJ0egw/5oj/ih568JIcCbsIDRNoVAGdBOGyL4Bc V/Nk2K6/XDknLsU1q4MylSMRpbVOdEd51a4AAvWTcbXa7hrV9ldSHBG+cRZ/MrC7o/cK h+10+dtzqwInebNVZVltScsEJJ8ZZFU48EEW6HBLXwTWUMaytGaDgjfYmH8kJuuMXpyZ 4QJrjuDznozJesLaIflX+Ob8u0qcTw0rNwU23OTRUaxMrQpAsJPPZ+zV1hAnDLz5uoOA 9rQMZ3/OsBqHNJnFWHBgLobnTx8DI6xoE0U5knQ0O+zV5KaOg/quI10ZPiS/eH8j7I1i L4fA== MIME-Version: 1.0 X-Received: by 10.60.179.113 with SMTP id df17mr21637008oec.16.1385320486145; Sun, 24 Nov 2013 11:14:46 -0800 (PST) Received: by 10.182.78.100 with HTTP; Sun, 24 Nov 2013 11:14:46 -0800 (PST) In-Reply-To: References: <7076908.jUUDNzHvnc@lumiwa.farms.net> <1687164.D0bsi2sOL3@lumiwa.farms.net> Date: Sun, 24 Nov 2013 14:14:46 -0500 Message-ID: Subject: Re: problems From: Joe Nosay To: Ajtim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 19:14:47 -0000 You need to have thew output in a text such as "make >& output.txt" in order for others to know what is going on with your system. On Sun, Nov 24, 2013 at 2:11 PM, Joe Nosay wrote: > Give me a moment > > > On Sun, Nov 24, 2013 at 12:31 PM, Ajtim wrote: > >> On Sunday 24 November 2013 11:41:30 Joe Nosay wrote: >> > Edit the Makefile to include" USE_GCC= yes" - sans quotation marks - >> with >> > nvi or another editor. >> > Some programs will not compile with the new Clang default. >> > >> > >> > On Sat, Nov 23, 2013 at 7:48 AM, Ajtim wrote: >> > >> > > Hi! >> > > >> > > I tried to build some programs on FreeBSD 10.0-BETA3 and as they told >> me >> > > there is not a problem to build on FreeBSD 9.2 for example (amd64) >> but on >> > > my system doesn't work: >> > > >> > > math/sage >> > > k3b-kde4 >> > > multimedia/vlc >> > > audio/last.fm >> > > >> > > There are more but the above four I like to have. >> > > >> > > What is your experience, please? >> > > >> > > Thank you. >> > > >> > > -- >> > > Mitja >> > > ------- >> > > http://www.redbubble.com/people.lumiwa >> > > >> > > _______________________________________________ >> > > freebsd-current@freebsd.org mailing list >> > > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > > To unsubscribe, send any mail to " >> freebsd-current-unsubscribe@freebsd.org" >> > > >> >> I did try to use "USE_GCC=any "and it didn't work. >> >> -- >> Mitja >> ------- >> http://www.redbubble.com/people.lumiwa >> >> > From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 19:23:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92A41D1F; Sun, 24 Nov 2013 19:23:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E2842110; Sun, 24 Nov 2013 19:23:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAOJNqqL067886; Sun, 24 Nov 2013 14:23:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAOJNqDm067885; Sun, 24 Nov 2013 19:23:52 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 19:23:52 GMT Message-Id: <201311241923.rAOJNqDm067885@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 19:23:53 -0000 TB --- 2013-11-24 18:20:00 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 18:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 18:20:00 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-11-24 18:20:00 - cleaning the object tree TB --- 2013-11-24 18:20:22 - /usr/local/bin/svn stat /src TB --- 2013-11-24 18:20:26 - At svn revision 258507 TB --- 2013-11-24 18:20:27 - building world TB --- 2013-11-24 18:20:27 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 18:20:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 18:20:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 18:20:27 - SRCCONF=/dev/null TB --- 2013-11-24 18:20:27 - TARGET=sparc64 TB --- 2013-11-24 18:20:27 - TARGET_ARCH=sparc64 TB --- 2013-11-24 18:20:27 - TZ=UTC TB --- 2013-11-24 18:20:27 - __MAKE_CONF=/dev/null TB --- 2013-11-24 18:20:27 - cd /src TB --- 2013-11-24 18:20:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 18:20:34 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 19:23:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 19:23:52 - ERROR: failed to build world TB --- 2013-11-24 19:23:52 - 3010.01 user 535.59 system 3831.53 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 19:59:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DD78F0B for ; Sun, 24 Nov 2013 19:59:56 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BF7F2291 for ; Sun, 24 Nov 2013 19:59:56 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id o15so2292661qap.18 for ; Sun, 24 Nov 2013 11:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=PutwyfV4QVtoROqkRFKWU8HrzCgPOkPM0Pe5XHZGlW0=; b=vasribnM7CVWdX5Zy1vxvuSAffaxn+EGYwY6CLWe1s6FziOdhdEam3QVZtJbQLHMyy h+lQZ9CDiNjCxQEtHTxNzCKovZATywUGJx6UP6eLmAIF3AtvVoT1JMhsexdyONwXI7fI PMXVq1G/mJO4NOQE8Q+9yPe0bBf9god2xPGTNQxYf8ib7hqwBVul2yih3ZQTeEihQ2nQ /HTU59fJVW8WVfTTqyDnfsG9OBgGcBJaIeZVaPjR+zpK0WJYs92SB8Rp+n4DGBV3r7yV ODBfv5oHObUuAGPmizpy0nL+D8blndz2B32dNXC8ta949ouTCCu0rcJmLrS5RMv96tkQ hKsw== X-Received: by 10.224.151.79 with SMTP id b15mr9158277qaw.28.1385323195563; Sun, 24 Nov 2013 11:59:55 -0800 (PST) Received: from lumiwa.farms.net (pool-70-105-224-61.port.east.myfairpoint.net. [70.105.224.61]) by mx.google.com with ESMTPSA id h9sm111553985qaq.9.2013.11.24.11.59.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Nov 2013 11:59:54 -0800 (PST) From: Ajtim To: Joe Nosay Subject: Re: problems Date: Sun, 24 Nov 2013 14:58:30 -0500 Message-ID: <3410216.CuObByAguk@lumiwa.farms.net> User-Agent: KMail/4.11.3 (FreeBSD/10.0-BETA3; KDE/4.11.3; amd64; ; ) In-Reply-To: References: <7076908.jUUDNzHvnc@lumiwa.farms.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1620225.5HGOvhmCvD" Content-Transfer-Encoding: 7Bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 19:59:56 -0000 This is a multi-part message in MIME format. --nextPart1620225.5HGOvhmCvD Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Sunday 24 November 2013 14:14:46 Joe Nosay wrote: > You need to have thew output in a text such as "make >& output.txt" in > order for others to know what is going on with your system. > > > On Sun, Nov 24, 2013 at 2:11 PM, Joe Nosay wrote: > > > Give me a moment > > > > > > On Sun, Nov 24, 2013 at 12:31 PM, Ajtim wrote: > > > >> On Sunday 24 November 2013 11:41:30 Joe Nosay wrote: > >> > Edit the Makefile to include" USE_GCC= yes" - sans quotation marks - > >> with > >> > nvi or another editor. > >> > Some programs will not compile with the new Clang default. > >> > > >> > > >> > On Sat, Nov 23, 2013 at 7:48 AM, Ajtim wrote: > >> > > >> > > Hi! > >> > > > >> > > I tried to build some programs on FreeBSD 10.0-BETA3 and as they told > >> me > >> > > there is not a problem to build on FreeBSD 9.2 for example (amd64) > >> but on > >> > > my system doesn't work: > >> > > > >> > > math/sage > >> > > k3b-kde4 > >> > > multimedia/vlc > >> > > audio/last.fm > >> > > > >> > > There are more but the above four I like to have. > >> > > > >> > > What is your experience, please? > >> > > > >> > > Thank you. > >> > > > >> > > -- > >> > > Mitja > >> > > ------- > >> > > http://www.redbubble.com/people.lumiwa > >> > > > >> > > _______________________________________________ > >> > > freebsd-current@freebsd.org mailing list > >> > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > > To unsubscribe, send any mail to " > >> freebsd-current-unsubscribe@freebsd.org" > >> > > > >> > >> I did try to use "USE_GCC=any "and it didn't work. > >> > >> -- > >> Mitja > >> ------- > >> http://www.redbubble.com/people.lumiwa > >> > >> > > Here is for example output for audio/last.fm. -- Mitja ------- http://www.redbubble.com/people.lumiwa --nextPart1620225.5HGOvhmCvD Content-Disposition: attachment; filename="output.txt" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1"; name="output.txt" =3D=3D=3D> Building for last.fm-1.5.4.26862 --- sub-src-libUnicorn-all-ordered --- cd src/libUnicorn/ && /usr/bin/make -f Makefile all --- sub-src-libMoose-all-ordered --- cd src/libMoose/ && /usr/bin/make -f Makefile all --- sub-src-libFingerprint-fplib-pro_qmake-fplib-pro-all-ordered --- cd src/libFingerprint/fplib/pro_qmake/ && /usr/bin/make -f Makefile.fpl= ib all --- sub-src-libFingerprint-all-ordered --- cd src/libFingerprint/ && /usr/bin/make -f Makefile all --- sub-src-all-ordered --- cd src/ && /usr/bin/make -f Makefile all --- ../bin/last.fm --- g++46 -Wl,-O1 -pthread -Wl,-rpath,/usr/local/lib/qt4 -o ../bin/last.fm = ../build/last.fm/release/main.o ../build/last.fm/release/container.o = ../build/last.fm/release/settingsdialog.o ../build/last.fm/release/abo= utdialog.o ../build/last.fm/release/Scrobbler-1.2.o ../build/last.fm/= release/simplewizard.o ../build/last.fm/release/configwizard.o ../bui= ld/last.fm/release/wizardinfopage.o ../build/last.fm/release/WizardBoo= tstrapSelectorPage.o ../build/last.fm/release/wizardmediadeviceconfirm= page.o ../build/last.fm/release/wizardloginpage.o ../build/last.fm/re= lease/wizardprogresspage.o ../build/last.fm/release/wizardselectplugin= page.o ../build/last.fm/release/wizardbootstrappage.o ../build/last.f= m/release/addplayerdialog.o ../build/last.fm/release/loginwidget.o ..= /build/last.fm/release/updateinfogetter.o ../build/last.fm/release/com= ponentinfo.o ../build/last.fm/release/plugininfo.o ../build/last.fm/r= elease/appinfo.o ../build/last.fm/release/versionnumber.o ../build/la= st.fm/release/FileVersionInfo.o ../build/last.fm/release/autoupdater.o= ../build/last.fm/release/updatewizard.o ../build/last.fm/release/wiz= ardselectupdatespage.o ../build/last.fm/release/playerlistener.o ../b= uild/last.fm/release/playercommandparser.o ../build/last.fm/release/pl= ayerconnection.o ../build/last.fm/release/iconshack.o ../build/last.f= m/release/systray.o ../build/last.fm/release/progressframe.o ../build= /last.fm/release/checkdirtree.o ../build/last.fm/release/deleteuserdia= log.o ../build/last.fm/release/failedlogindialog.o ../build/last.fm/r= elease/toolbarvolumeslider.o ../build/last.fm/release/tagdialog.o ../= build/last.fm/release/ShareDialog.o ../build/last.fm/release/lastfmapp= lication.o ../build/last.fm/release/AudioController.o ../build/last.f= m/release/Radio.o ../build/last.fm/release/RadioPlaylist.o ../build/l= ast.fm/release/XspfResolver.o ../build/last.fm/release/MediaDeviceScro= bbler.o ../build/last.fm/release/SideBarView.o ../build/last.fm/relea= se/SideBarModel.o ../build/last.fm/release/SideBarDelegate.o ../build= /last.fm/release/SideBarTreeStyle.o ../build/last.fm/release/SideBarTo= olTipLabel.o ../build/last.fm/release/SideBarRevealPopup.o ../build/l= ast.fm/release/MetaDataWidget.o ../build/last.fm/release/TagListWidget= .o ../build/last.fm/release/TrackProgressFrame.o ../build/last.fm/rel= ease/RestStateWidget.o ../build/last.fm/release/DiagnosticsDialog.o .= ./build/last.fm/release/User.o ../build/last.fm/release/RestStateMessa= ge.o ../build/last.fm/release/ProxyOutput.o ../build/last.fm/release/= AbstractBootstrapper.o ../build/last.fm/release/AbstractFileBootstrapp= er.o ../build/last.fm/release/WizardTwiddlyBootstrapPage.o ../build/l= ast.fm/release/simplewizard_mac.o ../build/last.fm/release/winstyleove= rrides.o ../build/last.fm/release/moc_container.o ../build/last.fm/re= lease/moc_settingsdialog.o ../build/last.fm/release/moc_aboutdialog.o = ../build/last.fm/release/moc_Scrobbler-1.2.o ../build/last.fm/release= /moc_simplewizard.o ../build/last.fm/release/moc_configwizard.o ../bu= ild/last.fm/release/moc_wizardinfopage.o ../build/last.fm/release/moc_= WizardBootstrapSelectorPage.o ../build/last.fm/release/moc_wizardmedia= deviceconfirmpage.o ../build/last.fm/release/moc_wizardloginpage.o ..= /build/last.fm/release/moc_wizardprogresspage.o ../build/last.fm/relea= se/moc_wizardselectpluginpage.o ../build/last.fm/release/moc_wizardboo= tstrappage.o ../build/last.fm/release/moc_addplayerdialog.o ../build/= last.fm/release/moc_loginwidget.o ../build/last.fm/release/moc_updatei= nfogetter.o ../build/last.fm/release/moc_autoupdater.o ../build/last.= fm/release/moc_updatewizard.o ../build/last.fm/release/moc_wizardselec= tupdatespage.o ../build/last.fm/release/moc_playerlistener.o ../build= /last.fm/release/moc_playerconnection.o ../build/last.fm/release/moc_s= ystray.o ../build/last.fm/release/moc_progressframe.o ../build/last.f= m/release/moc_checkdirtree.o ../build/last.fm/release/moc_deleteuserdi= alog.o ../build/last.fm/release/moc_failedlogindialog.o ../build/last= .fm/release/moc_toolbarvolumeslider.o ../build/last.fm/release/moc_tag= dialog.o ../build/last.fm/release/moc_ShareDialog.o ../build/last.fm/= release/moc_lastfmapplication.o ../build/last.fm/release/moc_AudioCont= roller.o ../build/last.fm/release/moc_Radio.o ../build/last.fm/releas= e/moc_RadioPlaylist.o ../build/last.fm/release/moc_MediaDeviceScrobble= r.o ../build/last.fm/release/moc_SideBarView.o ../build/last.fm/relea= se/moc_SideBarModel.o ../build/last.fm/release/moc_SideBarDelegate.o = ../build/last.fm/release/moc_MetaDataWidget.o ../build/last.fm/release= /moc_TagListWidget.o ../build/last.fm/release/moc_TrackProgressFrame.o= ../build/last.fm/release/moc_DiagnosticsDialog.o ../build/last.fm/re= lease/moc_User.o ../build/last.fm/release/moc_RestStateWidget.o ../bu= ild/last.fm/release/moc_RestStateMessage.o ../build/last.fm/release/mo= c_ProxyOutput.o ../build/last.fm/release/moc_AbstractBootstrapper.o .= ./build/last.fm/release/moc_AbstractFileBootstrapper.o ../build/last.f= m/release/moc_itunesdevice.o ../build/last.fm/release/moc_WizardTwiddl= yBootstrapPage.o ../build/last.fm/release/moc_simplewizard_mac.o ../b= uild/last.fm/release/qrc_last.fm.o -L/usr/local/lib/qt4 -L/usr/local= /lib -L/usr/ports/audio/last.fm/work/last.fm-1.5.4.26862/bin -lMoose -l= LastFmTools -L/usr/ports/audio/last.fm/work/last.fm-1.5.4.26862/bin -lL= astFmFingerprint -lmad -lfftw3f -lQtSql -L/usr/local/lib/qt4 -L/usr/loc= al/lib -lQtXml -lQtGui -lQtNetwork -lQtCore /usr/local/bin/ld: ../build/last.fm/release/AbstractBootstrapper.o: und= efined reference to symbol 'gzclose@@ZLIB_1.2.4.0' /usr/local/bin/ld: note: 'gzclose@@ZLIB_1.2.4.0' is defined in DSO //li= b/libz.so.6 so try adding it to the linker command line //lib/libz.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status *** [../bin/last.fm] Error code 1 make[2]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862/s= rc 1 error make[2]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862/s= rc *** [sub-src-all-ordered] Error code 2 make[1]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862 1 error make[1]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862 =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the fail= ure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/audio/last.fm --nextPart1620225.5HGOvhmCvD-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 20:24:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6549753; Sun, 24 Nov 2013 20:24:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8EF4823DA; Sun, 24 Nov 2013 20:24:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAOKORB8036073; Sun, 24 Nov 2013 15:24:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAOKORXb036072; Sun, 24 Nov 2013 20:24:27 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 20:24:27 GMT Message-Id: <201311242024.rAOKORXb036072@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 20:24:34 -0000 TB --- 2013-11-24 17:52:32 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-24 17:52:32 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 17:52:32 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-11-24 17:52:32 - cleaning the object tree TB --- 2013-11-24 17:52:51 - /usr/local/bin/svn stat /src TB --- 2013-11-24 17:53:05 - At svn revision 258507 TB --- 2013-11-24 17:53:06 - building world TB --- 2013-11-24 17:53:06 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 17:53:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 17:53:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 17:53:06 - SRCCONF=/dev/null TB --- 2013-11-24 17:53:06 - TARGET=powerpc TB --- 2013-11-24 17:53:06 - TARGET_ARCH=powerpc64 TB --- 2013-11-24 17:53:06 - TZ=UTC TB --- 2013-11-24 17:53:06 - __MAKE_CONF=/dev/null TB --- 2013-11-24 17:53:06 - cd /src TB --- 2013-11-24 17:53:06 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 17:53:14 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-24 20:24:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 20:24:27 - ERROR: failed to build world TB --- 2013-11-24 20:24:27 - 7983.24 user 897.23 system 9115.12 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 24 22:04:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3535F02 for ; Sun, 24 Nov 2013 22:04:13 +0000 (UTC) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 67C7F2860 for ; Sun, 24 Nov 2013 22:04:13 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id t7so3033314qeb.20 for ; Sun, 24 Nov 2013 14:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=VqHo6w7FtWMNiwL5GN7b2lsM624kCFoWmLUS1WhHKIU=; b=eHhg8tvAOOdPdHimAmw8hJyneu1NRir7VvGcUkn1fOFfgAvyUt9GEpSI+/GVxsORhu M7oOcLMkGXNqu/r7kh2tCPzal25pCAdvNZX4I1pITMKMCvu4TvpbhlkTI7PswPUfx4VI eHshNeQqf2ilVLWInLOHuKFsfNRtc8m2e+fOYX3KMf764DYiZwoNI1y/B3Lj81Ni3JLl 9yDo0ExwhOvg9brLLyYXABuYyrRli5sRG32yVInCX4j8MknoZo64c/2/Kz2ROCRE/HNc cxHDHe0ezmNttyGf1lz8eb4PhBEpB0wSEdgNc8cuceTTRpIUK8OagHS4dmf1bbJBZxu7 V6CA== X-Received: by 10.224.111.197 with SMTP id t5mr40956618qap.49.1385330652588; Sun, 24 Nov 2013 14:04:12 -0800 (PST) Received: from lumiwa.farms.net (pool-70-105-224-61.port.east.myfairpoint.net. [70.105.224.61]) by mx.google.com with ESMTPSA id x10sm28239097qas.5.2013.11.24.14.04.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Nov 2013 14:04:12 -0800 (PST) From: Ajtim To: freebsd-current Subject: Fwd: Re: problems Date: Sun, 24 Nov 2013 17:04:10 -0500 Message-ID: <2398456.xteR5Q2DSP@lumiwa.farms.net> User-Agent: KMail/4.11.3 (FreeBSD/10.0-BETA3; KDE/4.11.3; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 22:04:13 -0000 ---------- Forwarded Message ---------- Subject: Re: problems Date: Sunday 24 November 2013, 17:02:32 From: Ajtim To: Stefan Esser On Sunday 24 November 2013 21:21:29 you wrote: > The linker does no longer automatically load indirectly required > libraries (required by libraries, not the program itself). > > Regards, STefan Is it a future or improvement of coming FreeBSD 10.0 because on 9.2 for example you don't need to anything. -- Mitja ------- http://www.redbubble.com/people.lumiwa ----------------------------------------- -- Mitja ------- http://www.redbubble.com/people.lumiwa From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 01:14:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3337A848 for ; Mon, 25 Nov 2013 01:14:33 +0000 (UTC) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0863209A for ; Mon, 25 Nov 2013 01:14:32 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.7/8.14.7) with ESMTP id rAP1BuI0009520 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT) for ; Sun, 24 Nov 2013 17:11:57 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201311250111.rAP1BuI0009520@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 Nov 2013 17:11:51 -0800 To: freebsd-current@freebsd.org From: Manfred Antar Subject: Buildworld broken with WITHOUT_DYNAMICROOT=yes in src.conf Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, MISSING_MID,URIBL_BLOCKED autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: rAP1BuI0009520 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 01:14:33 -0000 Since the changes to libc in the last few weeks. building world fails in /bin/csh cc -O2 -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -static -o csh sh.o sh.dir.o sh.dol.o sh.err.o sh.exec.o sh.char.o sh.exp.o sh.file.o sh.func.o sh.glob.o sh.hist.o sh.init.o sh.lex.o sh.misc.o sh.parse.o sh.print.o sh.proc.o sh.sem.o sh.set.o sh.time.o glob.o mi.termios.o tw.help.o tw.init.o tw.parse.o tw.spell.o tw.comp.o tw.color.o ed.chared.o ed.defns.o ed.init.o ed.inputl.o ed.refresh.o ed.screen.o ed.xmap.o ed.term.o tc.alloc.o tc.bind.o tc.const.o tc.disc.o tc.func.o tc.nls.o tc.os.o tc.printf.o tc.prompt.o tc.sched.o tc.sig.o tc.str.o tc.vers.o tc.who.o tc.defs.o -ltermcap -lcrypt sh.func.o: In function `nlsclose': /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:(.text+0x2753): undefined reference to `iconv_close' sh.func.o: In function `nlsinit': /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:(.text+0x2874): undefined reference to `iconv_open' sh.func.o: In function `iconv_catgets': /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:(.text+0x3f9a): undefined reference to `iconv' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 If I add -lc_nonshared to the LADD= line it builds fine cc -O2 -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -static -o csh sh.o sh.dir.o sh.dol.o sh.err.o sh.exec.o sh.char.o sh.exp.o sh.file.o sh.func.o sh.glob.o sh.hist.o sh.init.o sh.lex.o sh.misc.o sh.parse.o sh.print.o sh.proc.o sh.sem.o sh.set.o sh.time.o glob.o mi.termios.o tw.help.o tw.init.o tw.parse.o tw.spell.o tw.comp.o tw.color.o ed.chared.o ed.defns.o ed.init.o ed.inputl.o ed.refresh.o ed.screen.o ed.xmap.o ed.term.o tc.alloc.o tc.bind.o tc.const.o tc.disc.o tc.func.o tc.nls.o tc.os.o tc.printf.o tc.prompt.o tc.sched.o tc.sig.o tc.str.o tc.vers.o tc.who.o tc.defs.o -ltermcap -lcrypt -lc_nonshared Not sure what rule to use. I don't know how many people use WITHOUT_DYNAMICROOT I like it though. Manfred ======================== || null@pozo.com || || || ======================== From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 01:19:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3E05A28; Mon, 25 Nov 2013 01:19:53 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CB3DE20D0; Mon, 25 Nov 2013 01:19:53 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 98D6513CBD; Mon, 25 Nov 2013 01:19:51 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 98D6513CBD Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 24 Nov 2013 20:19:49 -0500 From: Glen Barber To: Manfred Antar Subject: Re: Buildworld broken with WITHOUT_DYNAMICROOT=yes in src.conf Message-ID: <20131125011949.GC1627@glenbarber.us> References: <201311250111.rAP1BuI0009520@pozo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/e2eDi0V/xtL+Mc8" Content-Disposition: inline In-Reply-To: <201311250111.rAP1BuI0009520@pozo.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 01:19:54 -0000 --/e2eDi0V/xtL+Mc8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 24, 2013 at 05:11:51PM -0800, Manfred Antar wrote: > Since the changes to libc in the last few weeks. > building world fails in /bin/csh >=20 > cc -O2 -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcs= h -D_PATH_TCSHELL=3D'"/bin/csh"' -DHAVE_ICONV -std=3Dgnu99 -Qunused-argumen= ts -fstack-protector -Wsystem-headers -Wno-pointer-sign -Wno-empty-body -Wn= o-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parenthe= ses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-e= num -Wno-knr-promoted-parameter -Wno-parentheses -static -o csh sh.o sh.di= r.o sh.dol.o sh.err.o sh.exec.o sh.char.o sh.exp.o sh.file.o sh.func.o sh.g= lob.o sh.hist.o sh.init.o sh.lex.o sh.misc.o sh.parse.o sh.print.o sh.proc.= o sh.sem.o sh.set.o sh.time.o glob.o mi.termios.o tw.help.o tw.init.o tw.pa= rse.o tw.spell.o tw.comp.o tw.color.o ed.chared.o ed.defns.o ed.init.o ed.i= nputl.o ed.refresh.o ed.screen.o ed.xmap.o ed.term.o tc.alloc.o tc.bind.o t= c.const.o tc.disc.o tc.func.o tc.nls.o tc.os.o tc.printf.o tc.prompt.o tc.s= ched.o tc.sig.o tc.str.o tc.vers.o tc.who.o tc.defs.o -ltermcap -lcrypt > sh.func.o: In function `nlsclose': > /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:(.text+0x2753): undefined r= eference to `iconv_close' > sh.func.o: In function `nlsinit': > /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:(.text+0x2874): undefined r= eference to `iconv_open' > sh.func.o: In function `iconv_catgets': > /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:(.text+0x3f9a): undefined r= eference to `iconv' > cc: error: linker command failed with exit code 1 (use -v to see invocati= on) > *** Error code 1 >=20 > If I add -lc_nonshared to the LADD=3D line it builds fine=20 >=20 > cc -O2 -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcs= h -D_PATH_TCSHELL=3D'"/bin/csh"' -DHAVE_ICONV -std=3Dgnu99 -Qunused-argumen= ts -fstack-protector -Wsystem-headers -Wno-pointer-sign -Wno-empty-body -Wn= o-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parenthe= ses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-e= num -Wno-knr-promoted-parameter -Wno-parentheses -static -o csh sh.o sh.di= r.o sh.dol.o sh.err.o sh.exec.o sh.char.o sh.exp.o sh.file.o sh.func.o sh.g= lob.o sh.hist.o sh.init.o sh.lex.o sh.misc.o sh.parse.o sh.print.o sh.proc.= o sh.sem.o sh.set.o sh.time.o glob.o mi.termios.o tw.help.o tw.init.o tw.pa= rse.o tw.spell.o tw.comp.o tw.color.o ed.chared.o ed.defns.o ed.init.o ed.i= nputl.o ed.refresh.o ed.screen.o ed.xmap.o ed.term.o tc.alloc.o tc.bind.o t= c.const.o tc.disc.o tc.func.o tc.nls.o tc.os.o tc.printf.o tc.prompt.o tc.s= ched.o tc.sig.o tc.str.o tc.vers.o tc.who.o tc.defs.o -ltermcap -lcrypt -lc= _nonshared >=20 > Not sure what rule to use. > I don't know how many people use WITHOUT_DYNAMICROOT > I like it though. > Manfred >=20 I think WITHOUT_DYNAMICROOT=3D1 has nothing to do with this. I worked around it by setting WITHOUT_NLS_CATALOGS=3D1 (see src.conf(5)). The relevant parts of the contrib/tcsh/sh.func.c are: 2578 # if defined(HAVE_ICONV) && defined(HAVE_NL_LANGINFO) 2579 char * 2580 iconv_catgets(nl_catd ctd, int set_id, int msg_id, const char *s) 2581 { 2582 static char *buf =3D NULL; 2583 static size_t buf_size =3D 0; Glen --/e2eDi0V/xtL+Mc8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSkqW1AAoJELls3eqvi17QBgQQALwY2MkyavKLPmyXUcjMl2OT Ec2tmJ765C7+3NWWFL+zKDHPealk27m8h2BVCWXVTfJB6803jVdXJLEav3PM5Kjj I3UHF8A0p6nmyErqO2VuVK6lU/1bAEk67nbkBJZ7liUR13iGW+YXcPFQMq1XF0Q1 zT1XDr088m4Wm+vRJ0zXQSwckFWrsZSfMjKQ28Hm+Bh/MEmEhWoYrjBcdVyBFH/g 8gZ19NbO26lKt1u9KrYkuq/Gqo1Gfy5YtO5MoY86Yl9p6IBZYJCPl8Gqj/OOYYo6 NvmQDBnNXEp2EQPWgfJT5PR0w3niCletRnTEnqPvMXEvrqm+c9kviFVX/ugISPcH dvNblGJyURsZVpR2w19tnjRksAGPNw3zmtxQiRqFBfNh/XN7SSk7iqsDNoiBjJ0g NEjtk5Kd2y34PHxwo+FHhhuFN6DZpLaKj3sWr7ifwplCSvm0pPoF0hyLYIa5T6xp S7DGWUWToUk6QhHJySwoL1tNGGKr+pAPkGQ7MLCgqUpBWgHVi312/r/RE+O0MIn0 18Ir0yVSuCEd/KDzXcdOO/rhbxZRHtb4KGek2TbIgBKKzm71A7ZHt//3Qm1SfAhd hRvovTNAKLw09pbvYjvr1Im2O1EY5xOSC94DjWfdGkgwkXrOrs+0NPSUVCK9Arqk nli4Gs1izB6AHZjI8bkk =3rqL -----END PGP SIGNATURE----- --/e2eDi0V/xtL+Mc8-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 01:23:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65D27B5C; Mon, 25 Nov 2013 01:23:06 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D8E72117; Mon, 25 Nov 2013 01:23:05 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 1C50E13CF8; Mon, 25 Nov 2013 01:23:04 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 1C50E13CF8 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 24 Nov 2013 20:23:02 -0500 From: Glen Barber To: Manfred Antar Subject: Re: Buildworld broken with WITHOUT_DYNAMICROOT=yes in src.conf Message-ID: <20131125012302.GD1627@glenbarber.us> References: <201311250111.rAP1BuI0009520@pozo.com> <20131125011949.GC1627@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+B+y8wtTXqdUj1xM" Content-Disposition: inline In-Reply-To: <20131125011949.GC1627@glenbarber.us> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 01:23:06 -0000 --+B+y8wtTXqdUj1xM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 24, 2013 at 08:19:49PM -0500, Glen Barber wrote: > I think WITHOUT_DYNAMICROOT=3D1 has nothing to do with this. I worked > around it by setting WITHOUT_NLS_CATALOGS=3D1 (see src.conf(5)). >=20 I'm sorry, I misread a part of your email. I'll rebuild without WITHOUT_NLS_CATALOGS=3D1 and your LADD fix. If this fixes the problem (and passes 'make universe') will commit your fix. Thanks. Glen --+B+y8wtTXqdUj1xM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSkqZ1AAoJELls3eqvi17Q14MP/jVANqDyYZUa43HpWQPM59O7 Jxs9syIPLDUsFM/OCX9AkmiwSo0c+anJI6n4vo4NXaLsx9trL1V0Pe0NcK+6EBcn 69OIVC4KsFegxBbAj9ZM2p1sKNaDw40igB0oF6j7A3+dQyaFR/miMrHKa0iguplf 2n6k7N8lN4sjCiPwZaU65Gki6v5vhoLYBznMkT3Suf4zyRsjhdjT+y9S7KWiwy1N KErPBNK/yizZu/XsExgaECv4PvolemZDuPd2rKck1FSuXAdMJ58vWKXyfOjbgbWK V0QWd5APF4HVgMtpqKSPqkYed8InOFf60mKZOjniKJdPmP3IpUkLfIBhx8HRU6uC 6GFhG8ziK1w4BbWhuGnUj7R1dHh4iqs9++lKwoRUO8q7IOg6mCONbl/VXfkA8Bni 5Gyx8uyIYsIsaopFY/tqLvMFTLLNcRjOryA4X2KdML+P3OYqLYpbCavzQT+8XJMe QvfR6WU5+lW8XgevFXl0/e8ZMeqtNpr3gyHxxM6SA7oGLA3/7G+CrTZxcwsh5BfJ VxcbAAWDM9XFAzRxFSb+f3ZcdFJQxWXUIaDuxCO3ZGe89qMlYa9+ZtBtz9lpunXp b04EQhb7i6FzX2GlUc8Kppnoj6UFINSUXCFr9zCvpvtIhzKZl0gmlO6j6LiP4HxY Lknu4cOyE5GRsWjVjIXO =rlsC -----END PGP SIGNATURE----- --+B+y8wtTXqdUj1xM-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 01:29:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DC2DF11; Mon, 25 Nov 2013 01:29:30 +0000 (UTC) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED32D2155; Mon, 25 Nov 2013 01:29:29 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.7/8.14.7) with ESMTP id rAP1TJfQ033437 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Sun, 24 Nov 2013 17:29:20 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201311250129.rAP1TJfQ033437@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 Nov 2013 17:29:14 -0800 To: Glen Barber From: Manfred Antar Subject: Re: Buildworld broken with WITHOUT_DYNAMICROOT=yes in src.conf In-Reply-To: <20131125012302.GD1627@glenbarber.us> References: <201311250111.rAP1BuI0009520@pozo.com> <20131125011949.GC1627@glenbarber.us> <20131125012302.GD1627@glenbarber.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, MISSING_MID,URIBL_BLOCKED autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: rAP1TJfQ033437 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 01:29:30 -0000 At 05:23 PM 11/24/2013, Glen Barber wrote: >On Sun, Nov 24, 2013 at 08:19:49PM -0500, Glen Barber wrote: >> I think WITHOUT_DYNAMICROOT=1 has nothing to do with this. I worked >> around it by setting WITHOUT_NLS_CATALOGS=1 (see src.conf(5)). >> > >I'm sorry, I misread a part of your email. > >I'll rebuild without WITHOUT_NLS_CATALOGS=1 and your LADD fix. If this >fixes the problem (and passes 'make universe') will commit your fix. > >Thanks. > >Glen > > Sounds good. adding -lc_nonshared to LAAD enables me to build /bin and /sbin statically /bin/csh/Makefile was the only one I had to change all the rest of /bin and /sbin built fine ======================== || null@pozo.com || || || ======================== From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 03:44:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 714C9271; Mon, 25 Nov 2013 03:44:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2D4B8277B; Mon, 25 Nov 2013 03:44:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAP3ifou064660; Sun, 24 Nov 2013 22:44:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAP3if3K064653; Mon, 25 Nov 2013 03:44:41 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 03:44:41 GMT Message-Id: <201311250344.rAP3if3K064653@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 03:44:43 -0000 TB --- 2013-11-25 02:10:28 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-25 02:10:28 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 02:10:28 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-11-25 02:10:28 - cleaning the object tree TB --- 2013-11-25 02:11:35 - /usr/local/bin/svn stat /src TB --- 2013-11-25 02:11:39 - At svn revision 258526 TB --- 2013-11-25 02:11:40 - building world TB --- 2013-11-25 02:11:40 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 02:11:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 02:11:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 02:11:40 - SRCCONF=/dev/null TB --- 2013-11-25 02:11:40 - TARGET=ia64 TB --- 2013-11-25 02:11:40 - TARGET_ARCH=ia64 TB --- 2013-11-25 02:11:40 - TZ=UTC TB --- 2013-11-25 02:11:40 - __MAKE_CONF=/dev/null TB --- 2013-11-25 02:11:40 - cd /src TB --- 2013-11-25 02:11:40 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 25 02:11:46 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-25 03:44:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 03:44:41 - ERROR: failed to build world TB --- 2013-11-25 03:44:41 - 4364.75 user 759.90 system 5653.09 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 04:17:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E66AB61E; Mon, 25 Nov 2013 04:17:30 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BECBE2890; Mon, 25 Nov 2013 04:17:30 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id E1279153DA; Mon, 25 Nov 2013 04:17:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us E1279153DA Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 24 Nov 2013 23:17:24 -0500 From: Glen Barber To: Manfred Antar Subject: Re: Buildworld broken with WITHOUT_DYNAMICROOT=yes in src.conf Message-ID: <20131125041724.GA2310@glenbarber.us> References: <201311250111.rAP1BuI0009520@pozo.com> <20131125011949.GC1627@glenbarber.us> <20131125012302.GD1627@glenbarber.us> <201311250129.rAP1TJfQ033437@pozo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <201311250129.rAP1TJfQ033437@pozo.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 04:17:31 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 24, 2013 at 05:29:14PM -0800, Manfred Antar wrote: > adding -lc_nonshared to LAAD enables me to build /bin and /sbin statically > /bin/csh/Makefile was the only one I had to change all the rest of /bin a= nd /sbin built fine >=20 Hmm, I'm not sure if bin/csh/ should require -c_nonshared unconditionally. I've done some testing with WITHOUT_DYNAMICROOT=3D1, WITHOUT_ICONV=3D1, WITH_ICONV=3D1, WITH_DYNAMICROOT=3D1, and am getting different results with regard to what iconv_*() are included... Glen --17pEHd4RhPHOinZp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSks9UAAoJELls3eqvi17QjGsP/j34oaY1lITmyN7SOPEyEhsw YLhjkNg+vXJ1u8Aktu05b7WZUn5SQEfhxu8gawWB/TlEZrA7W0nP8nHdd51sDCMj 9H9U7/p2a1dj1EiYT2aHHX4Wl7N6gQDmWeLSPmUd++v1A+LXyjD18+gdkCU9wXfX vQKrWqmlLKYIjiB/d16TMdRtjlF8H2rvIQIMhEQH3YQiTsOlXOptf+5PjsyBT59t +6X38VMTUrYiD4axWe7R8/Lm7A1LyQmbIlnyHMsPXZP2WY9XLhgD2JrBVl4gFt+f fNyJYY1sMpr2J59wtgaQfysok0iwWBGIoGMdP6+rZZpZUC0cwIQtvhDDu5yKTvJu yNl2/nAC+huQitoQykI3303hD9sNBKeLJJhsNGTfGOC8f//cMnO/G0l3AJApspWv f9qy0PPYxQAgVv1+C+hlWH5eE4iBXO8raTStrT6to2fralpDjwDxn9lihRwH66A4 QQOWkcINWxmpXh7gknzc19/sAi3Tw6S9qhUrnm/5jMgFLV49ksNzinztDtys+m+E r+711icSnGqwhxFWPaaPGNMCBNdZ9bd6VBUBcrQiZK2pjYa8UMv8w6mpkbAJHNkw G6ZE5FZXY2QoOobabCPhnq2pFGkhtxvTJu6sKxcp4WzyBL1PYBF1amMVgl1RhVHF txdJNIB2BUVwPgqshN11 =O1QP -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 04:42:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D647A88; Mon, 25 Nov 2013 04:42:03 +0000 (UTC) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 06CF129C7; Mon, 25 Nov 2013 04:42:02 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.7/8.14.7) with ESMTP id rAP4freb002330 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Sun, 24 Nov 2013 20:41:54 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201311250441.rAP4freb002330@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 Nov 2013 20:41:48 -0800 To: Glen Barber From: Manfred Antar Subject: Re: Buildworld broken with WITHOUT_DYNAMICROOT=yes in src.conf In-Reply-To: <20131125041724.GA2310@glenbarber.us> References: <201311250111.rAP1BuI0009520@pozo.com> <20131125011949.GC1627@glenbarber.us> <20131125012302.GD1627@glenbarber.us> <201311250129.rAP1TJfQ033437@pozo.com> <20131125041724.GA2310@glenbarber.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, MISSING_MID,URIBL_BLOCKED autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: rAP4freb002330 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 04:42:03 -0000 At 08:17 PM 11/24/2013, Glen Barber wrote: >On Sun, Nov 24, 2013 at 05:29:14PM -0800, Manfred Antar wrote: >> adding -lc_nonshared to LAAD enables me to build /bin and /sbin statically >> /bin/csh/Makefile was the only one I had to change all the rest of /bin and /sbin built fine >> > >Hmm, I'm not sure if bin/csh/ should require -c_nonshared >unconditionally. > >I've done some testing with WITHOUT_DYNAMICROOT=1, WITHOUT_ICONV=1, >WITH_ICONV=1, WITH_DYNAMICROOT=1, and am getting different results with >regard to what iconv_*() are included... > >Glen > > I think it only needs it if you want a static csh. my src.conf : #WITHOUT_DYNAMICROOT=yes WITH_IDEA=yes # Don't die on warnings NO_WERROR= WERROR= WITH_GCC=yes WITH_GNUCXX=yes can you some kind of conditional if WITHOUT_DYNAMICROOT=yes then LADD+= -lc_nonshared ======================== || null@pozo.com || || || ======================== From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 04:48:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3654BCD; Mon, 25 Nov 2013 04:48:57 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1CC029E8; Mon, 25 Nov 2013 04:48:57 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 2626615666; Mon, 25 Nov 2013 04:48:56 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 2626615666 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 24 Nov 2013 23:48:54 -0500 From: Glen Barber To: Manfred Antar Subject: Re: Buildworld broken with WITHOUT_DYNAMICROOT=yes in src.conf Message-ID: <20131125044854.GC2310@glenbarber.us> References: <201311250111.rAP1BuI0009520@pozo.com> <20131125011949.GC1627@glenbarber.us> <20131125012302.GD1627@glenbarber.us> <201311250129.rAP1TJfQ033437@pozo.com> <20131125041724.GA2310@glenbarber.us> <201311250441.rAP4freb002330@pozo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CblX+4bnyfN0pR09" Content-Disposition: inline In-Reply-To: <201311250441.rAP4freb002330@pozo.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 04:48:58 -0000 --CblX+4bnyfN0pR09 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 24, 2013 at 08:41:48PM -0800, Manfred Antar wrote: > At 08:17 PM 11/24/2013, Glen Barber wrote: > >On Sun, Nov 24, 2013 at 05:29:14PM -0800, Manfred Antar wrote: > >> adding -lc_nonshared to LAAD enables me to build /bin and /sbin static= ally > >> /bin/csh/Makefile was the only one I had to change all the rest of /bi= n and /sbin built fine > >>=20 > > > >Hmm, I'm not sure if bin/csh/ should require -c_nonshared > >unconditionally. > > > >I've done some testing with WITHOUT_DYNAMICROOT=3D1, WITHOUT_ICONV=3D1, > >WITH_ICONV=3D1, WITH_DYNAMICROOT=3D1, and am getting different results w= ith > >regard to what iconv_*() are included... > > > >Glen > > > > >=20 > I think it only needs it if you want a static csh. > my src.conf : >=20 > #WITHOUT_DYNAMICROOT=3Dyes=20 > WITH_IDEA=3Dyes > # Don't die on warnings > NO_WERROR=3D > WERROR=3D > WITH_GCC=3Dyes > WITH_GNUCXX=3Dyes >=20 > can you some kind of conditional >=20 > if WITHOUT_DYNAMICROOT=3Dyes then LADD+=3D -lc_nonshared=20 >=20 Yes, that is what I am doing, but also getting unexpected results. Latest diff I tried is: Index: Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile (revision 258538) +++ Makefile (working copy) @@ -42,6 +42,9 @@ =20 DPADD=3D ${LIBTERMCAP} ${LIBCRYPT} LDADD=3D -ltermcap -lcrypt +.if ${MK_ICONV} !=3D "no" && ${MK_DYNAMICROOT} !=3D "yes" +LDADD+=3D -lc_nonshared +.endif =20 LINKS=3D ${BINDIR}/csh ${BINDIR}/tcsh =20 Glen --CblX+4bnyfN0pR09 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSkta2AAoJELls3eqvi17QEKIQAJOsKWk6mvly0m+Q5WcF7oZo JOX1hq7+qOE/UjJXpt5VD8xfCcz0rwwN+AArwdEwf6VWYc+670jgEgQ/GA3QqPhX 6vntEFZCtvIHY+YdSY+CKITuo7dR8iSF4UUvBDLo2/9rv6d8kt8vTfzTZceIx2b/ C7gRV8Thv88gYqLRepvc+ffrNlgTjXGHZhxbiL89QZNMXPHk6vrbfUtlazOlH0Pn +klsWWonvYrCmUtIXcHmCf1K/VSsmYpCAcBL81nHiXtHxHQAXaQTM6/njJnXoeQJ EqA95YNax2gtyaZIV0Ic3hv9CHJTIbLvp+rAsoe2y398r8WbbFeFzyA1Xb4/uSh1 fToBTmjZVcTXpcdJoO7esFfwSxQhGf4awcZ3FUjfzEtv20wIjz6MguPzYa8cW82X gMcPIB7UWtUhbHurXodXbf3iwaaMoD63aPyT6zSjlp0WDzD7Q0u1sfNtwzmO2Cd1 xC3mipxAF6aRomKNsEdTB5/qeyESmQq8/isdXSgI+cmzlBfSuSSeS8LCxfByqvbp Lot2nfaKsC3lCvFz0LkELOvxxBtdUUQPh4r70s9lSybiTPeWc6QKkymI8g5M9FK2 I6uh9rlfdNXv/2J1ZwfxvknTrefgJI1HBNt2UQgmqPK/q/edJ8nzCj35TopSx7n2 9Yxsk9pin8qMMDIKxo9m =0sNg -----END PGP SIGNATURE----- --CblX+4bnyfN0pR09-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 06:25:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7368999E; Mon, 25 Nov 2013 06:25:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 307232D94; Mon, 25 Nov 2013 06:25:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAP6PuHN068263; Mon, 25 Nov 2013 01:25:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAP6PuAs068258; Mon, 25 Nov 2013 06:25:56 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 06:25:56 GMT Message-Id: <201311250625.rAP6PuAs068258@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 06:25:58 -0000 TB --- 2013-11-25 03:44:41 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-25 03:44:41 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 03:44:41 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-25 03:44:42 - cleaning the object tree TB --- 2013-11-25 03:45:55 - /usr/local/bin/svn stat /src TB --- 2013-11-25 03:45:58 - At svn revision 258526 TB --- 2013-11-25 03:45:59 - building world TB --- 2013-11-25 03:45:59 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 03:45:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 03:45:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 03:45:59 - SRCCONF=/dev/null TB --- 2013-11-25 03:45:59 - TARGET=powerpc TB --- 2013-11-25 03:45:59 - TARGET_ARCH=powerpc TB --- 2013-11-25 03:45:59 - TZ=UTC TB --- 2013-11-25 03:45:59 - __MAKE_CONF=/dev/null TB --- 2013-11-25 03:45:59 - cd /src TB --- 2013-11-25 03:45:59 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 25 03:46:06 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-25 06:25:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 06:25:56 - ERROR: failed to build world TB --- 2013-11-25 06:25:56 - 7994.40 user 1057.90 system 9674.55 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 06:53:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98894148; Mon, 25 Nov 2013 06:53:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 552C82ED4; Mon, 25 Nov 2013 06:53:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAP6rqBK030599; Mon, 25 Nov 2013 01:53:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAP6rqNq030598; Mon, 25 Nov 2013 06:53:52 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 06:53:52 GMT Message-Id: <201311250653.rAP6rqNq030598@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 06:53:53 -0000 TB --- 2013-11-25 05:49:03 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-25 05:49:03 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 05:49:03 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-11-25 05:49:04 - cleaning the object tree TB --- 2013-11-25 05:50:17 - /usr/local/bin/svn stat /src TB --- 2013-11-25 05:50:20 - At svn revision 258526 TB --- 2013-11-25 05:50:21 - building world TB --- 2013-11-25 05:50:21 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 05:50:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 05:50:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 05:50:21 - SRCCONF=/dev/null TB --- 2013-11-25 05:50:21 - TARGET=sparc64 TB --- 2013-11-25 05:50:21 - TARGET_ARCH=sparc64 TB --- 2013-11-25 05:50:21 - TZ=UTC TB --- 2013-11-25 05:50:21 - __MAKE_CONF=/dev/null TB --- 2013-11-25 05:50:21 - cd /src TB --- 2013-11-25 05:50:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 25 05:50:28 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-25 06:53:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 06:53:52 - ERROR: failed to build world TB --- 2013-11-25 06:53:52 - 3010.95 user 539.19 system 3888.29 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 07:42:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C728C8F for ; Mon, 25 Nov 2013 07:42:58 +0000 (UTC) Received: from potato.growveg.org (growveg-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:3d2::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E32E92141 for ; Mon, 25 Nov 2013 07:42:57 +0000 (UTC) Received: from john by potato.growveg.org with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Vkqoo-0008Xe-0c for freebsd-current@freebsd.org; Mon, 25 Nov 2013 07:42:54 +0000 Date: Mon, 25 Nov 2013 07:42:54 +0000 From: John To: freebsd-current@freebsd.org Subject: make buildworld fails for 10-stable Message-ID: <20131125074253.GA13828@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 07:42:58 -0000 Hello currents, On FreeBSD 10.0-BETA1 #0 r256628 I do the following: root@dev-0:/usr/src # cd .. root@dev-0:/usr # rm -rf obj root@dev-0:/usr # mkdir obj root@dev-0:/usr # svnlite co https://svn0.eu.FreeBSD.org/base/stable/10 /usr/src UU src/Makefile.inc1 Checked out revision 258536. root@dev-0:/usr # cd src root@dev-0:/usr/src # make clean && make clean && make buildworld [lots of output] The build fails with: -------------------------------------------------------------- >>> stage 2.3: build tools -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp VERSION="FreeBSD 10.0-BETA3 amd64 1000502" MAKEFLAGS="-m /usr/src/tools/build/mk -m /usr/src/share/mk" COMPILER_TYPE=clang make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 DESTDIR= BOOTSTRAPPING=1000500 SSP_CFLAGS= -DNO_LINT -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD build-tools ===> bin/csh (obj,build-tools) grep 'ERR_' /usr/src/bin/csh/../../contrib/tcsh/sh.err.c | grep '^#define' >> sh.err.h clang -E -O2 -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/tc.const.c /usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h /usr/src/bin/csh/../../contrib/tcsh/config_f.h /usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const | grep 'Char STR' | sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char \1[];/' | sort >> tc.const.h clang -o gethost -L/usr/obj/usr/src/tmp/legacy/usr/lib -O2 -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/gethost.c /usr/bin/ld: cannot find /usr/lib/libc_nonshared.a clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[3]: stopped in /usr/src/bin/csh *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src root@dev-0:/usr/src # Can anyone help please? thanks, -- John From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 07:51:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43036FEA; Mon, 25 Nov 2013 07:51:20 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A985621D3; Mon, 25 Nov 2013 07:51:19 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAP7pAYx010405; Mon, 25 Nov 2013 09:51:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAP7pAYx010405 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAP7pAp6010404; Mon, 25 Nov 2013 09:51:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Nov 2013 09:51:10 +0200 From: Konstantin Belousov To: Glen Barber Subject: Re: Buildworld broken with WITHOUT_DYNAMICROOT=yes in src.conf Message-ID: <20131125075110.GL59496@kib.kiev.ua> References: <201311250111.rAP1BuI0009520@pozo.com> <20131125011949.GC1627@glenbarber.us> <20131125012302.GD1627@glenbarber.us> <201311250129.rAP1TJfQ033437@pozo.com> <20131125041724.GA2310@glenbarber.us> <201311250441.rAP4freb002330@pozo.com> <20131125044854.GC2310@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1AMxIamHFXrJUbFZ" Content-Disposition: inline In-Reply-To: <20131125044854.GC2310@glenbarber.us> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, peter@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 07:51:20 -0000 --1AMxIamHFXrJUbFZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 24, 2013 at 11:48:54PM -0500, Glen Barber wrote: > On Sun, Nov 24, 2013 at 08:41:48PM -0800, Manfred Antar wrote: > > At 08:17 PM 11/24/2013, Glen Barber wrote: > > >On Sun, Nov 24, 2013 at 05:29:14PM -0800, Manfred Antar wrote: > > >> adding -lc_nonshared to LAAD enables me to build /bin and /sbin stat= ically > > >> /bin/csh/Makefile was the only one I had to change all the rest of /= bin and /sbin built fine > > >>=20 > > > > > >Hmm, I'm not sure if bin/csh/ should require -c_nonshared > > >unconditionally. > > > > > >I've done some testing with WITHOUT_DYNAMICROOT=3D1, WITHOUT_ICONV=3D1, > > >WITH_ICONV=3D1, WITH_DYNAMICROOT=3D1, and am getting different results= with > > >regard to what iconv_*() are included... > > > > > >Glen > > > > > > > >=20 > > I think it only needs it if you want a static csh. > > my src.conf : > >=20 > > #WITHOUT_DYNAMICROOT=3Dyes=20 > > WITH_IDEA=3Dyes > > # Don't die on warnings > > NO_WERROR=3D > > WERROR=3D > > WITH_GCC=3Dyes > > WITH_GNUCXX=3Dyes > >=20 > > can you some kind of conditional > >=20 > > if WITHOUT_DYNAMICROOT=3Dyes then LADD+=3D -lc_nonshared=20 > >=20 >=20 > Yes, that is what I am doing, but also getting unexpected results. >=20 > Latest diff I tried is: >=20 > Index: Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Makefile (revision 258538) > +++ Makefile (working copy) > @@ -42,6 +42,9 @@ > =20 > DPADD=3D ${LIBTERMCAP} ${LIBCRYPT} > LDADD=3D -ltermcap -lcrypt > +.if ${MK_ICONV} !=3D "no" && ${MK_DYNAMICROOT} !=3D "yes" > +LDADD+=3D -lc_nonshared > +.endif > =20 > LINKS=3D ${BINDIR}/csh ${BINDIR}/tcsh > =20 No, this is wrong. As is, static linking is broken and the hack above only fixes one case. What is needed is inclusion of the lib/libc_nonshared object files into static libc.a. I am not sure how to express this in our build system. --1AMxIamHFXrJUbFZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSkwFtAAoJEJDCuSvBvK1BfYUQAImcyOwRPjO/FY47AFfwkBqD DPAuQ/AQHtoAY5Pg9aQSEiydgZGoWeBVTcujpQKJBFcMJC3sHN3oAxOQuJvze9el Cfp/kX3CntgI73Kzajq0E7h9D8s1wpfM2hprWpQOKaQWZ2Iu1qgluypuvf2oBd3O yR8xgHQOtT1z35jvsaLHPQP5Fcoyx4onL2izOaVpl15b8blgeZchip73g8iqhHOO Osr+syfmc58ncNnX7aOuS8ik+Z0Mb0tu8KW0cN2FjoyhxGR1u0HXeVrTQxCieJZ6 CuBVBrhpUDvVF2ZNGE/t83DyB9QhkbyCWXRUGCj+koW0Hl2AV68asBxYHQDqXSJ7 a9IciuK/Ms1wp/TIYUsLKTpwOMx0eymakPYG7GWu5gT4pDo4fSqFB+XpBvxN8R7m dh86gSC2WgnU1FN1EupFHN8lw4idSkJTvQsxAcHGiKwUbNi+lJYesxXlban2QE2K yyq8V57PBgpdNxYVUBKZ7YkDXPA3ihCMJWjbz3FouSPFEVDTbBmCM3Kgiaf/UcQt R8QSseOvnk3Qiv+C8VOA4wJuXuC3trodoUvFlyQF2MaQgGCJnwViFOtRKI3sj5Cg VlrarJRZRF6vJuWzE1UXnVH2pfnqKLQWEUwifEZgxqymJBJHo/7jFgk8xs0W148C tA5Oe5r/sl+HAxLcAFru =Y45F -----END PGP SIGNATURE----- --1AMxIamHFXrJUbFZ-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 07:54:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00FEE37D; Mon, 25 Nov 2013 07:54:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0EF32200; Mon, 25 Nov 2013 07:54:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAP7sRNS098670; Mon, 25 Nov 2013 02:54:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAP7sQdg098669; Mon, 25 Nov 2013 07:54:26 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 07:54:26 GMT Message-Id: <201311250754.rAP7sQdg098669@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 07:54:35 -0000 TB --- 2013-11-25 05:21:51 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-25 05:21:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 05:21:51 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-11-25 05:21:52 - cleaning the object tree TB --- 2013-11-25 05:23:06 - /usr/local/bin/svn stat /src TB --- 2013-11-25 05:23:19 - At svn revision 258526 TB --- 2013-11-25 05:23:20 - building world TB --- 2013-11-25 05:23:20 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 05:23:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 05:23:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 05:23:20 - SRCCONF=/dev/null TB --- 2013-11-25 05:23:20 - TARGET=powerpc TB --- 2013-11-25 05:23:20 - TARGET_ARCH=powerpc64 TB --- 2013-11-25 05:23:20 - TZ=UTC TB --- 2013-11-25 05:23:20 - __MAKE_CONF=/dev/null TB --- 2013-11-25 05:23:20 - cd /src TB --- 2013-11-25 05:23:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 25 05:23:28 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-25 07:54:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 07:54:26 - ERROR: failed to build world TB --- 2013-11-25 07:54:26 - 7985.38 user 904.53 system 9155.03 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 08:10:53 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB1E2C67; Mon, 25 Nov 2013 08:10:53 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AC1F2342; Mon, 25 Nov 2013 08:10:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAP8Al7v014582; Mon, 25 Nov 2013 10:10:47 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAP8Al7v014582 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAP8AljC014576; Mon, 25 Nov 2013 10:10:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Nov 2013 10:10:47 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131125081047.GN59496@kib.kiev.ua> References: <201311240743.rAO7hU9e026518@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nqw1/iq3c1XOUvXw" Content-Disposition: inline In-Reply-To: <201311240743.rAO7hU9e026518@gw.catspoiler.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 08:10:53 -0000 --nqw1/iq3c1XOUvXw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 23, 2013 at 11:43:30PM -0800, Don Lewis wrote: > I upgraded my 11.0-CURRENT machine to r258504 to get past the uma panic > that I stumbled across earlier. Now I got this when I started upgrading > ports: >=20 > Unread portion of the kernel message buffer: >=20 > Fatal double fault: > eip =3D 0xc0b158e0 > esp =3D 0xe4f62000 > ebp =3D 0xe4f62010 > cpuid =3D 0; apic id =3D 00 > panic: double fault > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper(c113340c,2,10000000,c15a0cf0,c15a0ce8,...) at db_tr= ace_self_wrapper+0x2d/frame 0xc15a0cb0 > kdb_backtrace(c12f143f,0,c12f2aea,c15a0d6c,0,...) at kdb_backtrace+0x30/f= rame 0xc15a0d18 > vpanic(c15a0d6c,c15a0d84,c0fc14fb,c12f2aea,0,...) at vpanic+0x11f/frame 0= xc15a0d54 > panic(c12f2aea,0,0,0,e4f62010,...) at panic+0x12/frame 0xc15a0d60 > dblfault_handler() at dblfault_handler+0xab/frame 0xc15a0d60 > --- trap 0x17, eip =3D 0xc0b158e0, esp =3D 0xe4f62000, ebp =3D 0xe4f62010= --- > vprintf(c12f2900,c,fffffe7f,fffffeff,bfff75ed,...) at vprintf/frame 0xe4f= 62010 > trap(e4f62164) at trap+0x18a/frame 0xe4f62158 > calltrap() at calltrap+0x6/frame 0xe4f62158 > --- trap 0xc, eip =3D 0xc0b145dd, esp =3D 0xe4f621a4, ebp =3D 0xe4f62270 = --- > kvprintf(c12f2900,c0b15210,e4f62290,a,e4f6235c,...) at kvprintf+0x1cd/fra= me 0xe4f62270 > vprintf(c12f2900,e4f6235c,e4f6235c) at vprintf+0x7f/frame 0xe4f6233c > printf(c12f2900,c,ffefdfff,ebefefff,dfdffedf,...) at printf+0x1b/frame 0x= e4f62350 > trap(e4f624a4) at trap+0x18a/frame 0xe4f62498 > calltrap() at calltrap+0x6/frame 0xe4f62498 > --- trap 0xc, eip =3D 0xc0b145dd, esp =3D 0xe4f624e4, ebp =3D 0xe4f625b0 = --- > kvprintf(c12f2900,c0b15210,e4f625d0,a,e4f6269c,...) at kvprintf+0x1cd/fra= me 0xe4f625b0 > vprintf(c12f2900,e4f6269c,e4f6269c) at vprintf+0x7f/frame 0xe4f6267c > printf(c12f2900,c,5fd7ff5f,ba77f7fb,bfffb7ff,...) at printf+0x1b/frame 0x= e4f62690 > trap(e4f627e4) at trap+0x18a/frame 0xe4f627d8 > calltrap() at calltrap+0x6/frame 0xe4f627d8 > --- trap 0xc, eip =3D 0xc0b145dd, esp =3D 0xe4f62824, ebp =3D 0xe4f628f0 = --- > kvprintf(c12f2900,c0b15210,e4f62910,a,e4f629dc,...) at kvprintf+0x1cd/fra= me 0xe4f628f0 > vprintf(c12f2900,e4f629dc,e4f629dc) at vprintf+0x7f/frame 0xe4f629bc > printf(c12f2900,c,0,80000000,c0,...) at printf+0x1b/frame 0xe4f629d0 > trap(e4f62b20) at trap+0x18a/frame 0xe4f62b14 > calltrap() at calltrap+0x6/frame 0xe4f62b14 > --- trap 0xc, eip =3D 0xc0afe270, esp =3D 0xe4f62b60, ebp =3D 0xe4f62b78 = --- > tdq_choose(c141e090,4,c113144d,917,c2425c80,...) at tdq_choose+0x60/frame= 0xe4f62b78 > sched_choose(e4f62c00,c0afc511,c141e090,14,c113144d,...) at sched_choose+= 0x4c/frame 0xe4f62ba4 > choosethread(c141e090,14,c113144d,78b,c141e116,...) at choosethread+0x1f/= frame 0xe4f62bac > sched_switch(c8f04000,0,608,1b7,ef2,...) at sched_switch+0x361/frame 0xe4= f62c00 > mi_switch(608,0,c112f4e4,d3,c,...) at mi_switch+0x1c9/frame 0xe4f62c34 > critical_exit(0,2,c113144d,411,c141e108,...) at critical_exit+0xa4/frame = 0xe4f62c50 > sched_idletd(0,e4f62d08,c1128634,3db,0,...) at sched_idletd+0x1d6/frame 0= xe4f62ccc > fork_exit(c0afeb00,0,e4f62d08) at fork_exit+0x7f/frame 0xe4f62cf4 > fork_trampoline() at fork_trampoline+0x8/frame 0xe4f62cf4 > --- trap 0, eip =3D 0, esp =3D 0xe4f62d40, ebp =3D 0 --- > KDB: enter: panic >=20 > (kgdb) list *tdq_choose+0x60 > 0xc0afe270 is in tdq_choose (/usr/src/sys/kern/sched_ule.c:1334). > 1329 td =3D runq_choose(&tdq->tdq_realtime); > 1330 if (td !=3D NULL) > 1331 return (td); > 1332 td =3D runq_choose_from(&tdq->tdq_timeshare, tdq->tdq_ridx); > 1333 if (td !=3D NULL) { > 1334 KASSERT(td->td_priority >=3D PRI_MIN_BATCH, > 1335 ("tdq_choose: Invalid priority on timeshare queue %d", > 1336 td->td_priority)); > 1337 return (td); > 1338 } >=20 > (kgdb) bt > #0 doadump (textdump=3D-1051128300) at pcpu.h:233 > #1 0xc052766d in db_fncall (dummy1=3D-1051051648, dummy2=3D0, dummy3=3D-= 1051063684,=20 > dummy4=3D0xc15a0a54 "") at /usr/src/sys/ddb/db_command.c:578 > #2 0xc0527357 in db_command (cmd_table=3D) > at /usr/src/sys/ddb/db_command.c:449 > #3 0xc0527090 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 > #4 0xc0529922 in db_trap (type=3D, code=3D0) > at /usr/src/sys/ddb/db_main.c:231 > #5 0xc0b0ff38 in kdb_trap (type=3D,=20 > code=3D, tf=3D) > at /usr/src/sys/kern/subr_kdb.c:656 > #6 0xc0fc0c07 in trap (frame=3D) > at /usr/src/sys/i386/i386/trap.c:712 > #7 0xc0faa0ec in calltrap () at /usr/src/sys/i386/i386/exception.s:170 > #8 0xc0b0f7bd in kdb_enter (why=3D0xc112ee39 "panic", msg=3D) > at cpufunc.h:71 > #9 0xc0ad6a93 in vpanic (fmt=3D, ap=3D) > at /usr/src/sys/kern/kern_shutdown.c:747 > #10 0xc0ad6ad2 in panic (fmt=3D0xc12f2aea "double fault") > at /usr/src/sys/kern/kern_shutdown.c:683 > #11 0xc0fc14fb in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:10= 72 > #12 0x00000000 in ?? () It seems to be a corruption of the td and probably curthread. Is it repeatable easily ? If yes, you could try to manually inspect first elements in the (idle) runq queue of the tdq_cpu[paniced cpu]. --nqw1/iq3c1XOUvXw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIbBAEBAgAGBQJSkwYGAAoJEJDCuSvBvK1B08QP9R7nxcxz0UFC/F783Oe2lVbe iEtmyLKHdJ0qDE5xhcqWw4LOA+kEGWnWItNdH3OjBtwhwv4mo03y1gJO9Bvmn4lz Ja34J1qYQgiyWcUKsIobsjZRZwZfAK32YIrtkPq6FCOhz6l08KYJcSMWLhG9MgDk HZAMaJBWwljtAItl38ZXYqfwLsuQfjVQIRpITNB2f0ckj1p6DznwekFQNsCACA5Z kyqyZIm8FiTO9TDeY6/JD+h2EpKRdxExsD0uBpIyT6Uz9uSq99xFzk7QF6dYRrGU 73gM47CqDreT6BqP+kieAJ46aVLxvLqVJs8QLEZQhxdptRBX7xocCoZVWWylZLeQ cSJMShcifRqwZDSEAohuZSaT1X3+iCbjgp5Zgqk9fLif+k1xzxJHGFY80m6aCh9B URlAKGDf8Iv6k3BaQ35jG5bc7i1KJXXi2MlfYg2Juz+tqqSRNRg21tg9fHUNTXKf pVblKRqLLCyVg2v41+9Oyzd7maZlhjh11nUsDCWIg/Kqo0xYgo/2Y27ck/USsn3R uorfBZ23osp2IWnu1Xau6iH806N7c9KSCTaT2TjZB7kBQ57PFT1nhtCXP1V5/gjW p6Bim2ze3ZNMxDTuYofqWxhQL2PDYeQAxWGK/q0CJjsJ1JufP472RpSndLQ40Z85 M5S0jbAGnFPZSmxGFv4= =OBoQ -----END PGP SIGNATURE----- --nqw1/iq3c1XOUvXw-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 08:27:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0568856D for ; Mon, 25 Nov 2013 08:27:58 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DEDB2450 for ; Mon, 25 Nov 2013 08:27:57 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id q59so3569228wes.27 for ; Mon, 25 Nov 2013 00:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+vXPC4vB5Ht8rQF4rR/aTExneipV1C8J8Ddi0a82Ibk=; b=dUYwN/uH87+uzplaoiBPw9aeC07Ct8pySR/jhpq8omALV67HqDwGLIIMNwE5RbXzRP 6bpfPRhKvhhZZdALa/KkwJXZ7Afrvl68bRZGD2qTKoq+xoeO7kUv3C1f5t58/Peqg9Ft y8qpN6aDPWguIwDZXL5nE3LsXCQoHW5AGYxPyGc5LBJ8jCR3YcU5kjEdnn0Iu3SJUNOV QJYghyHRT79yfAglY1rcYRIWv+YUc6cH3qVoU2wJt3ya5Wlz9f0AOkPp6IBnxRtF5ZwD IJkqrWQSjs/EAi0TgLSTbO+n9AZCHhgaXVrTZIMShKs4JbwLcf5ImeqrDGivTusuMaMZ CfYw== MIME-Version: 1.0 X-Received: by 10.180.9.74 with SMTP id x10mr11713477wia.56.1385368075823; Mon, 25 Nov 2013 00:27:55 -0800 (PST) Received: by 10.217.0.143 with HTTP; Mon, 25 Nov 2013 00:27:55 -0800 (PST) Date: Mon, 25 Nov 2013 12:27:55 +0400 Message-ID: Subject: panic: sbdrop in sbcut_internal From: Sergey Kandaurov To: current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 08:27:58 -0000 Seen this on head while doing two `/etc/rc.d/netif restart wlan0' in parallel. Thanks our shiny new compiler I can not examine local vars. $FreeBSD: head/sys/kern/uipc_sockbuf.c 256185 2013-10-09 11:57:53Z glebius $ Unread portion of the kernel message buffer: <118>Nov 24 20:35:52 omg wpa_supplicant[55133]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Operation not supported panic: sbdrop cpuid = 0 #2 0xffffffff805904b4 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff805fe2eb in sbcut_internal (sb=, len=) at /usr/src/sys/kern/uipc_sockbuf.c:859 #4 0xffffffff805fd368 in sbflush_internal (sb=0xfffff8000b4b0348) at /usr/src/sys/kern/uipc_sockbuf.c:821 #5 0xffffffff805fd4a2 in sbdestroy (sb=0xfffff8000b4b0348, so=0xfffff8000b4b02b8) at /usr/src/sys/kern/uipc_sockbuf.c:339 #6 0xffffffff805ff300 in sofree (so=0xfffff8000b4b02b8) at /usr/src/sys/kern/uipc_socket.c:752 #7 0xffffffff805ff7d2 in soclose (so=) at /usr/src/sys/kern/uipc_socket.c:837 #8 0xffffffff805502f9 in _fdrop (fp=0xfffff8000b4d5370, td=0x0) at file.h:342 #9 0xffffffff80552b97 in closef (fp=, td=) at /usr/src/sys/kern/kern_descrip.c:2315 #10 0xffffffff805505f5 in closefp (fdp=0xfffff8000b3bb800, fd=, fp=0xfffff8000b4d5370, td=0xfffff8000b036490, holdleaders=) at /usr/src/sys/kern/kern_descrip.c:1159 #11 0xffffffff807c23c7 in amd64_syscall (td=0xfffff8000b036490, traced=0) at subr_syscall.c:134 (kgdb) f 3 #3 0xffffffff805fe2eb in sbcut_internal (sb=, len=) at /usr/src/sys/kern/uipc_sockbuf.c:859 859 panic("sbdrop"); (kgdb) list 854 mfree = NULL; 855 856 while (len > 0) { 857 if (m == 0) { 858 if (next == 0) 859 panic("sbdrop"); 860 m = next; 861 next = m->m_nextpkt; 862 continue; 863 } -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 08:39:15 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 385E3CC8 for ; Mon, 25 Nov 2013 08:39:15 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2AB9259B for ; Mon, 25 Nov 2013 08:39:14 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAP8d1cg031434; Mon, 25 Nov 2013 00:39:05 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311250839.rAP8d1cg031434@gw.catspoiler.org> Date: Mon, 25 Nov 2013 00:39:01 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131125081047.GN59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 08:39:15 -0000 On 25 Nov, Konstantin Belousov wrote: > On Sat, Nov 23, 2013 at 11:43:30PM -0800, Don Lewis wrote: >> I upgraded my 11.0-CURRENT machine to r258504 to get past the uma panic >> that I stumbled across earlier. Now I got this when I started upgrading >> ports: >> >> Unread portion of the kernel message buffer: >> >> Fatal double fault: >> eip = 0xc0b158e0 >> esp = 0xe4f62000 >> ebp = 0xe4f62010 >> cpuid = 0; apic id = 00 >> panic: double fault >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper(c113340c,2,10000000,c15a0cf0,c15a0ce8,...) at db_trace_self_wrapper+0x2d/frame 0xc15a0cb0 >> kdb_backtrace(c12f143f,0,c12f2aea,c15a0d6c,0,...) at kdb_backtrace+0x30/frame 0xc15a0d18 >> vpanic(c15a0d6c,c15a0d84,c0fc14fb,c12f2aea,0,...) at vpanic+0x11f/frame 0xc15a0d54 >> panic(c12f2aea,0,0,0,e4f62010,...) at panic+0x12/frame 0xc15a0d60 >> dblfault_handler() at dblfault_handler+0xab/frame 0xc15a0d60 >> --- trap 0x17, eip = 0xc0b158e0, esp = 0xe4f62000, ebp = 0xe4f62010 --- >> vprintf(c12f2900,c,fffffe7f,fffffeff,bfff75ed,...) at vprintf/frame 0xe4f62010 >> trap(e4f62164) at trap+0x18a/frame 0xe4f62158 >> calltrap() at calltrap+0x6/frame 0xe4f62158 >> --- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f621a4, ebp = 0xe4f62270 --- >> kvprintf(c12f2900,c0b15210,e4f62290,a,e4f6235c,...) at kvprintf+0x1cd/frame 0xe4f62270 >> vprintf(c12f2900,e4f6235c,e4f6235c) at vprintf+0x7f/frame 0xe4f6233c >> printf(c12f2900,c,ffefdfff,ebefefff,dfdffedf,...) at printf+0x1b/frame 0xe4f62350 >> trap(e4f624a4) at trap+0x18a/frame 0xe4f62498 >> calltrap() at calltrap+0x6/frame 0xe4f62498 >> --- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f624e4, ebp = 0xe4f625b0 --- >> kvprintf(c12f2900,c0b15210,e4f625d0,a,e4f6269c,...) at kvprintf+0x1cd/frame 0xe4f625b0 >> vprintf(c12f2900,e4f6269c,e4f6269c) at vprintf+0x7f/frame 0xe4f6267c >> printf(c12f2900,c,5fd7ff5f,ba77f7fb,bfffb7ff,...) at printf+0x1b/frame 0xe4f62690 >> trap(e4f627e4) at trap+0x18a/frame 0xe4f627d8 >> calltrap() at calltrap+0x6/frame 0xe4f627d8 >> --- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f62824, ebp = 0xe4f628f0 --- >> kvprintf(c12f2900,c0b15210,e4f62910,a,e4f629dc,...) at kvprintf+0x1cd/frame 0xe4f628f0 >> vprintf(c12f2900,e4f629dc,e4f629dc) at vprintf+0x7f/frame 0xe4f629bc >> printf(c12f2900,c,0,80000000,c0,...) at printf+0x1b/frame 0xe4f629d0 >> trap(e4f62b20) at trap+0x18a/frame 0xe4f62b14 >> calltrap() at calltrap+0x6/frame 0xe4f62b14 >> --- trap 0xc, eip = 0xc0afe270, esp = 0xe4f62b60, ebp = 0xe4f62b78 --- >> tdq_choose(c141e090,4,c113144d,917,c2425c80,...) at tdq_choose+0x60/frame 0xe4f62b78 >> sched_choose(e4f62c00,c0afc511,c141e090,14,c113144d,...) at sched_choose+0x4c/frame 0xe4f62ba4 >> choosethread(c141e090,14,c113144d,78b,c141e116,...) at choosethread+0x1f/frame 0xe4f62bac >> sched_switch(c8f04000,0,608,1b7,ef2,...) at sched_switch+0x361/frame 0xe4f62c00 >> mi_switch(608,0,c112f4e4,d3,c,...) at mi_switch+0x1c9/frame 0xe4f62c34 >> critical_exit(0,2,c113144d,411,c141e108,...) at critical_exit+0xa4/frame 0xe4f62c50 >> sched_idletd(0,e4f62d08,c1128634,3db,0,...) at sched_idletd+0x1d6/frame 0xe4f62ccc >> fork_exit(c0afeb00,0,e4f62d08) at fork_exit+0x7f/frame 0xe4f62cf4 >> fork_trampoline() at fork_trampoline+0x8/frame 0xe4f62cf4 >> --- trap 0, eip = 0, esp = 0xe4f62d40, ebp = 0 --- >> KDB: enter: panic >> >> (kgdb) list *tdq_choose+0x60 >> 0xc0afe270 is in tdq_choose (/usr/src/sys/kern/sched_ule.c:1334). >> 1329 td = runq_choose(&tdq->tdq_realtime); >> 1330 if (td != NULL) >> 1331 return (td); >> 1332 td = runq_choose_from(&tdq->tdq_timeshare, tdq->tdq_ridx); >> 1333 if (td != NULL) { >> 1334 KASSERT(td->td_priority >= PRI_MIN_BATCH, >> 1335 ("tdq_choose: Invalid priority on timeshare queue %d", >> 1336 td->td_priority)); >> 1337 return (td); >> 1338 } >> >> (kgdb) bt >> #0 doadump (textdump=-1051128300) at pcpu.h:233 >> #1 0xc052766d in db_fncall (dummy1=-1051051648, dummy2=0, dummy3=-1051063684, >> dummy4=0xc15a0a54 "") at /usr/src/sys/ddb/db_command.c:578 >> #2 0xc0527357 in db_command (cmd_table=) >> at /usr/src/sys/ddb/db_command.c:449 >> #3 0xc0527090 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 >> #4 0xc0529922 in db_trap (type=, code=0) >> at /usr/src/sys/ddb/db_main.c:231 >> #5 0xc0b0ff38 in kdb_trap (type=, >> code=, tf=) >> at /usr/src/sys/kern/subr_kdb.c:656 >> #6 0xc0fc0c07 in trap (frame=) >> at /usr/src/sys/i386/i386/trap.c:712 >> #7 0xc0faa0ec in calltrap () at /usr/src/sys/i386/i386/exception.s:170 >> #8 0xc0b0f7bd in kdb_enter (why=0xc112ee39 "panic", msg=) >> at cpufunc.h:71 >> #9 0xc0ad6a93 in vpanic (fmt=, ap=) >> at /usr/src/sys/kern/kern_shutdown.c:747 >> #10 0xc0ad6ad2 in panic (fmt=0xc12f2aea "double fault") >> at /usr/src/sys/kern/kern_shutdown.c:683 >> #11 0xc0fc14fb in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:1072 >> #12 0x00000000 in ?? () > > It seems to be a corruption of the td and probably curthread. > > Is it repeatable easily ? If yes, you could try to manually inspect first > elements in the (idle) runq queue of the tdq_cpu[paniced cpu]. It doesn't seem to be very repeatable. It crashed after a few hours of port building last time. It's currently been building ports for 10 1/2 hours at this point. I don't suspect a random memory error because it's got ECC RAM. From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 10:14:39 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C9AA6DF; Mon, 25 Nov 2013 10:14:39 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 204A42BDD; Mon, 25 Nov 2013 10:14:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA17966; Mon, 25 Nov 2013 12:14:30 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VktBV-000M4d-OV; Mon, 25 Nov 2013 12:14:29 +0200 Message-ID: <529322E1.1060105@FreeBSD.org> Date: Mon, 25 Nov 2013 12:13:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: FreeBSD Current Subject: gdb has outdated knowledge of signal trampolines X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Luca Pizzamiglio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 10:14:39 -0000 It seems that placement of signal trampolines was changed a while ago. Possibly with the introduction of the shared page, but I am not sure. Unfortunately, neither the gdb in base nor the ports gdb were updated to account for the new location. And thus, for example: (kgdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008032c89a7 in nsProfileLock::FatalSignalHandler (signo=6, info=, context=0x7ffffb197630) at /usr/obj/ports/usr/ports/www/firefox/work/mozilla-release/obj-x86_64-unknown-freebsd11.0/toolkit/profile/nsProfileLock.cpp:180 #2 0x0000000800f90596 in handle_signal (actp=, sig=6, info=0x7ffffb1979a0, ucp=0x7ffffb197630) at /usr/src/lib/libthr/thread/thr_sig.c:237 #3 0x0000000800f9013f in thr_sighandler (sig=6, info=0x0, _ucp=0x7ffffb197630) at /usr/src/lib/libthr/thread/thr_sig.c:182 #4 0x00007ffffffff003 in ?? () #5 0x0000000800f90010 in ?? () at /usr/src/lib/libthr/thread/thr_sig.c:566 from /lib/libthr.so.3 #6 0x0000000000000000 in ?? () Obviously, the gdb is confused after the frame that has 0x00007ffffffff003. I looked only at amd64 code, but I believe that other platforms (all of them?) are affected as well. The following proof of concept patch for the base gdb seems to fix the case of native debugging on amd64 (target case was not tested). diff --git a/contrib/gdb/gdb/amd64fbsd-nat.c b/contrib/gdb/gdb/amd64fbsd-nat.c index f083734..d49dc45 100644 --- a/contrib/gdb/gdb/amd64fbsd-nat.c +++ b/contrib/gdb/gdb/amd64fbsd-nat.c @@ -212,24 +212,23 @@ Please report this to .", SC_RBP_OFFSET = offset; - /* FreeBSD provides a kern.ps_strings sysctl that we can use to + /* FreeBSD provides a kern.usrstack sysctl that we can use to locate the sigtramp. That way we can still recognize a sigtramp if its location is changed in a new kernel. Of course this is still based on the assumption that the sigtramp is placed - directly under the location where the program arguments and - environment can be found. */ + directly at usrstack. */ { int mib[2]; - long ps_strings; + long usrstack; size_t len; mib[0] = CTL_KERN; - mib[1] = KERN_PS_STRINGS; - len = sizeof (ps_strings); - if (sysctl (mib, 2, &ps_strings, &len, NULL, 0) == 0) + mib[1] = KERN_USRSTACK; + len = sizeof (usrstack); + if (sysctl (mib, 2, &usrstack, &len, NULL, 0) == 0) { - amd64fbsd_sigtramp_start_addr = ps_strings - 32; - amd64fbsd_sigtramp_end_addr = ps_strings; + amd64fbsd_sigtramp_start_addr = usrstack; + amd64fbsd_sigtramp_end_addr = usrstack + 0x20; } } } diff --git a/contrib/gdb/gdb/amd64fbsd-tdep.c b/contrib/gdb/gdb/amd64fbsd-tdep.c index e4e02ab..87c1484 100644 --- a/contrib/gdb/gdb/amd64fbsd-tdep.c +++ b/contrib/gdb/gdb/amd64fbsd-tdep.c @@ -86,8 +86,8 @@ static int amd64fbsd_r_reg_offset[] = }; /* Location of the signal trampoline. */ -CORE_ADDR amd64fbsd_sigtramp_start_addr = 0x7fffffffffc0; -CORE_ADDR amd64fbsd_sigtramp_end_addr = 0x7fffffffffe0; +CORE_ADDR amd64fbsd_sigtramp_start_addr = 0x7ffffffff000; +CORE_ADDR amd64fbsd_sigtramp_end_addr = 0x7ffffffff020; /* From . */ int amd64fbsd_sc_reg_offset[] = -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 11:50:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F2455AE for ; Mon, 25 Nov 2013 11:50:38 +0000 (UTC) Received: from CMEXEDGE2.ext.emulex.com (cmexedge2.ext.emulex.com [138.239.224.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 819C22368 for ; Mon, 25 Nov 2013 11:50:38 +0000 (UTC) Received: from CMEXHTCAS1.ad.emulex.com (138.239.115.217) by CMEXEDGE2.ext.emulex.com (138.239.224.100) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 25 Nov 2013 03:35:35 -0800 Received: from CMEXMB1.ad.emulex.com ([169.254.1.137]) by CMEXHTCAS1.ad.emulex.com ([2002:8aef:73d9::8aef:73d9]) with mapi id 14.03.0146.002; Mon, 25 Nov 2013 03:35:31 -0800 From: Venkata Duvvuru To: "freebsd-current@freebsd.org" Subject: sysctl add macros Thread-Topic: sysctl add macros Thread-Index: Ac7py2Eb3GYul2HXQGupi09t7TvnXQ== Date: Mon, 25 Nov 2013 11:35:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [138.239.141.36] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 11:50:38 -0000 Hi, I'm unable to figure out how to add an unsigned short or an unsigned char v= alues to a sysctl node. SYSCTL_ADD_INT, SYSCTL_ADD_UINT, etc., are present but to add a char or a s= hort values I couldn't find any macros. Could you please let me know how to add them? /Venkat. From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 12:16:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B37CC8C; Mon, 25 Nov 2013 12:16:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4310F252D; Mon, 25 Nov 2013 12:16:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAPCGPvd090872; Mon, 25 Nov 2013 07:16:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAPCGOXW090862; Mon, 25 Nov 2013 12:16:24 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 12:16:24 GMT Message-Id: <201311251216.rAPCGOXW090862@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 12:16:26 -0000 TB --- 2013-11-25 08:00:21 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-25 08:00:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 08:00:21 - starting HEAD tinderbox run for arm/arm TB --- 2013-11-25 08:00:21 - cleaning the object tree TB --- 2013-11-25 08:00:21 - /usr/local/bin/svn stat /src TB --- 2013-11-25 08:00:26 - At svn revision 258542 TB --- 2013-11-25 08:00:27 - building world TB --- 2013-11-25 08:00:27 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 08:00:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 08:00:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 08:00:27 - SRCCONF=/dev/null TB --- 2013-11-25 08:00:27 - TARGET=arm TB --- 2013-11-25 08:00:27 - TARGET_ARCH=arm TB --- 2013-11-25 08:00:27 - TZ=UTC TB --- 2013-11-25 08:00:27 - __MAKE_CONF=/dev/null TB --- 2013-11-25 08:00:27 - cd /src TB --- 2013-11-25 08:00:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 25 08:00:36 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Nov 25 11:06:01 UTC 2013 TB --- 2013-11-25 11:06:01 - generating LINT kernel config TB --- 2013-11-25 11:06:01 - cd /src/sys/arm/conf TB --- 2013-11-25 11:06:01 - /usr/bin/make -B LINT TB --- 2013-11-25 11:06:01 - cd /src/sys/arm/conf TB --- 2013-11-25 11:06:01 - /usr/sbin/config -m LINT TB --- 2013-11-25 11:06:01 - building LINT kernel TB --- 2013-11-25 11:06:01 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 11:06:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 11:06:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 11:06:01 - SRCCONF=/dev/null TB --- 2013-11-25 11:06:01 - TARGET=arm TB --- 2013-11-25 11:06:01 - TARGET_ARCH=arm TB --- 2013-11-25 11:06:01 - TZ=UTC TB --- 2013-11-25 11:06:01 - __MAKE_CONF=/dev/null TB --- 2013-11-25 11:06:01 - cd /src TB --- 2013-11-25 11:06:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 25 11:06:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Nov 25 11:30:27 UTC 2013 TB --- 2013-11-25 11:30:27 - cd /src/sys/arm/conf TB --- 2013-11-25 11:30:27 - /usr/sbin/config -m AC100 TB --- 2013-11-25 11:30:27 - skipping AC100 kernel TB --- 2013-11-25 11:30:27 - cd /src/sys/arm/conf TB --- 2013-11-25 11:30:27 - /usr/sbin/config -m ARMADAXP TB --- 2013-11-25 11:30:27 - skipping ARMADAXP kernel TB --- 2013-11-25 11:30:27 - cd /src/sys/arm/conf TB --- 2013-11-25 11:30:27 - /usr/sbin/config -m ARNDALE TB --- 2013-11-25 11:30:27 - skipping ARNDALE kernel TB --- 2013-11-25 11:30:27 - cd /src/sys/arm/conf TB --- 2013-11-25 11:30:27 - /usr/sbin/config -m ATMEL TB --- 2013-11-25 11:30:27 - building ATMEL kernel TB --- 2013-11-25 11:30:27 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 11:30:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 11:30:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 11:30:27 - SRCCONF=/dev/null TB --- 2013-11-25 11:30:27 - TARGET=arm TB --- 2013-11-25 11:30:27 - TARGET_ARCH=arm TB --- 2013-11-25 11:30:27 - TZ=UTC TB --- 2013-11-25 11:30:27 - __MAKE_CONF=/dev/null TB --- 2013-11-25 11:30:27 - cd /src TB --- 2013-11-25 11:30:27 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Mon Nov 25 11:30:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Mon Nov 25 11:34:16 UTC 2013 TB --- 2013-11-25 11:34:16 - cd /src/sys/arm/conf TB --- 2013-11-25 11:34:16 - /usr/sbin/config -m AVILA TB --- 2013-11-25 11:34:16 - skipping AVILA kernel TB --- 2013-11-25 11:34:16 - cd /src/sys/arm/conf TB --- 2013-11-25 11:34:16 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-11-25 11:34:16 - skipping BEAGLEBONE kernel TB --- 2013-11-25 11:34:16 - cd /src/sys/arm/conf TB --- 2013-11-25 11:34:16 - /usr/sbin/config -m BWCT TB --- 2013-11-25 11:34:16 - building BWCT kernel TB --- 2013-11-25 11:34:16 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 11:34:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 11:34:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 11:34:16 - SRCCONF=/dev/null TB --- 2013-11-25 11:34:16 - TARGET=arm TB --- 2013-11-25 11:34:16 - TARGET_ARCH=arm TB --- 2013-11-25 11:34:16 - TZ=UTC TB --- 2013-11-25 11:34:16 - __MAKE_CONF=/dev/null TB --- 2013-11-25 11:34:16 - cd /src TB --- 2013-11-25 11:34:16 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Mon Nov 25 11:34:17 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Mon Nov 25 11:36:52 UTC 2013 TB --- 2013-11-25 11:36:52 - cd /src/sys/arm/conf TB --- 2013-11-25 11:36:52 - /usr/sbin/config -m CAMBRIA TB --- 2013-11-25 11:36:52 - skipping CAMBRIA kernel TB --- 2013-11-25 11:36:52 - cd /src/sys/arm/conf TB --- 2013-11-25 11:36:52 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-11-25 11:36:52 - building CNS11XXNAS kernel TB --- 2013-11-25 11:36:52 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 11:36:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 11:36:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 11:36:52 - SRCCONF=/dev/null TB --- 2013-11-25 11:36:52 - TARGET=arm TB --- 2013-11-25 11:36:52 - TARGET_ARCH=arm TB --- 2013-11-25 11:36:52 - TZ=UTC TB --- 2013-11-25 11:36:52 - __MAKE_CONF=/dev/null TB --- 2013-11-25 11:36:52 - cd /src TB --- 2013-11-25 11:36:52 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Mon Nov 25 11:36:52 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Mon Nov 25 11:40:29 UTC 2013 TB --- 2013-11-25 11:40:29 - cd /src/sys/arm/conf TB --- 2013-11-25 11:40:29 - /usr/sbin/config -m COSMIC TB --- 2013-11-25 11:40:29 - skipping COSMIC kernel TB --- 2013-11-25 11:40:29 - cd /src/sys/arm/conf TB --- 2013-11-25 11:40:29 - /usr/sbin/config -m CRB TB --- 2013-11-25 11:40:29 - skipping CRB kernel TB --- 2013-11-25 11:40:29 - cd /src/sys/arm/conf TB --- 2013-11-25 11:40:29 - /usr/sbin/config -m CUBIEBOARD TB --- 2013-11-25 11:40:29 - skipping CUBIEBOARD kernel TB --- 2013-11-25 11:40:29 - cd /src/sys/arm/conf TB --- 2013-11-25 11:40:29 - /usr/sbin/config -m CUBIEBOARD2 TB --- 2013-11-25 11:40:29 - skipping CUBIEBOARD2 kernel TB --- 2013-11-25 11:40:29 - cd /src/sys/arm/conf TB --- 2013-11-25 11:40:29 - /usr/sbin/config -m DB-78XXX TB --- 2013-11-25 11:40:29 - building DB-78XXX kernel TB --- 2013-11-25 11:40:29 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 11:40:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 11:40:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 11:40:29 - SRCCONF=/dev/null TB --- 2013-11-25 11:40:29 - TARGET=arm TB --- 2013-11-25 11:40:29 - TARGET_ARCH=arm TB --- 2013-11-25 11:40:29 - TZ=UTC TB --- 2013-11-25 11:40:29 - __MAKE_CONF=/dev/null TB --- 2013-11-25 11:40:29 - cd /src TB --- 2013-11-25 11:40:29 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Mon Nov 25 11:40:29 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Mon Nov 25 11:43:43 UTC 2013 TB --- 2013-11-25 11:43:43 - cd /src/sys/arm/conf TB --- 2013-11-25 11:43:43 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-11-25 11:43:43 - building DB-88F5XXX kernel TB --- 2013-11-25 11:43:43 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 11:43:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 11:43:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 11:43:43 - SRCCONF=/dev/null TB --- 2013-11-25 11:43:43 - TARGET=arm TB --- 2013-11-25 11:43:43 - TARGET_ARCH=arm TB --- 2013-11-25 11:43:43 - TZ=UTC TB --- 2013-11-25 11:43:43 - __MAKE_CONF=/dev/null TB --- 2013-11-25 11:43:43 - cd /src TB --- 2013-11-25 11:43:43 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Mon Nov 25 11:43:43 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Mon Nov 25 11:46:53 UTC 2013 TB --- 2013-11-25 11:46:53 - cd /src/sys/arm/conf TB --- 2013-11-25 11:46:53 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-11-25 11:46:53 - building DB-88F6XXX kernel TB --- 2013-11-25 11:46:53 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 11:46:53 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 11:46:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 11:46:53 - SRCCONF=/dev/null TB --- 2013-11-25 11:46:53 - TARGET=arm TB --- 2013-11-25 11:46:53 - TARGET_ARCH=arm TB --- 2013-11-25 11:46:53 - TZ=UTC TB --- 2013-11-25 11:46:53 - __MAKE_CONF=/dev/null TB --- 2013-11-25 11:46:53 - cd /src TB --- 2013-11-25 11:46:53 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Mon Nov 25 11:46:54 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Mon Nov 25 11:50:12 UTC 2013 TB --- 2013-11-25 11:50:12 - cd /src/sys/arm/conf TB --- 2013-11-25 11:50:12 - /usr/sbin/config -m DIGI-CCWMX53 TB --- 2013-11-25 11:50:12 - skipping DIGI-CCWMX53 kernel TB --- 2013-11-25 11:50:12 - cd /src/sys/arm/conf TB --- 2013-11-25 11:50:12 - /usr/sbin/config -m DOCKSTAR TB --- 2013-11-25 11:50:12 - building DOCKSTAR kernel TB --- 2013-11-25 11:50:12 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 11:50:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 11:50:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 11:50:12 - SRCCONF=/dev/null TB --- 2013-11-25 11:50:12 - TARGET=arm TB --- 2013-11-25 11:50:12 - TARGET_ARCH=arm TB --- 2013-11-25 11:50:12 - TZ=UTC TB --- 2013-11-25 11:50:12 - __MAKE_CONF=/dev/null TB --- 2013-11-25 11:50:12 - cd /src TB --- 2013-11-25 11:50:12 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Mon Nov 25 11:50:12 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Mon Nov 25 11:53:08 UTC 2013 TB --- 2013-11-25 11:53:08 - cd /src/sys/arm/conf TB --- 2013-11-25 11:53:08 - /usr/sbin/config -m DREAMPLUG-1001 TB --- 2013-11-25 11:53:08 - building DREAMPLUG-1001 kernel TB --- 2013-11-25 11:53:08 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 11:53:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 11:53:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 11:53:08 - SRCCONF=/dev/null TB --- 2013-11-25 11:53:08 - TARGET=arm TB --- 2013-11-25 11:53:08 - TARGET_ARCH=arm TB --- 2013-11-25 11:53:08 - TZ=UTC TB --- 2013-11-25 11:53:08 - __MAKE_CONF=/dev/null TB --- 2013-11-25 11:53:08 - cd /src TB --- 2013-11-25 11:53:08 - /usr/bin/make -B buildkernel KERNCONF=DREAMPLUG-1001 >>> Kernel build for DREAMPLUG-1001 started on Mon Nov 25 11:53:08 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DREAMPLUG-1001 completed on Mon Nov 25 11:58:42 UTC 2013 TB --- 2013-11-25 11:58:42 - cd /src/sys/arm/conf TB --- 2013-11-25 11:58:42 - /usr/sbin/config -m EA3250 TB --- 2013-11-25 11:58:42 - building EA3250 kernel TB --- 2013-11-25 11:58:42 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 11:58:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 11:58:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 11:58:42 - SRCCONF=/dev/null TB --- 2013-11-25 11:58:42 - TARGET=arm TB --- 2013-11-25 11:58:42 - TARGET_ARCH=arm TB --- 2013-11-25 11:58:42 - TZ=UTC TB --- 2013-11-25 11:58:42 - __MAKE_CONF=/dev/null TB --- 2013-11-25 11:58:42 - cd /src TB --- 2013-11-25 11:58:42 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Mon Nov 25 11:58:42 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EA3250 completed on Mon Nov 25 12:01:49 UTC 2013 TB --- 2013-11-25 12:01:49 - cd /src/sys/arm/conf TB --- 2013-11-25 12:01:49 - /usr/sbin/config -m EB9200 TB --- 2013-11-25 12:01:49 - building EB9200 kernel TB --- 2013-11-25 12:01:49 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 12:01:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 12:01:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 12:01:49 - SRCCONF=/dev/null TB --- 2013-11-25 12:01:49 - TARGET=arm TB --- 2013-11-25 12:01:49 - TARGET_ARCH=arm TB --- 2013-11-25 12:01:49 - TZ=UTC TB --- 2013-11-25 12:01:49 - __MAKE_CONF=/dev/null TB --- 2013-11-25 12:01:49 - cd /src TB --- 2013-11-25 12:01:49 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Mon Nov 25 12:01:49 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EB9200 completed on Mon Nov 25 12:05:21 UTC 2013 TB --- 2013-11-25 12:05:21 - cd /src/sys/arm/conf TB --- 2013-11-25 12:05:21 - /usr/sbin/config -m EFIKA_MX TB --- 2013-11-25 12:05:21 - skipping EFIKA_MX kernel TB --- 2013-11-25 12:05:21 - cd /src/sys/arm/conf TB --- 2013-11-25 12:05:21 - /usr/sbin/config -m EP80219 TB --- 2013-11-25 12:05:21 - skipping EP80219 kernel TB --- 2013-11-25 12:05:21 - cd /src/sys/arm/conf TB --- 2013-11-25 12:05:21 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-11-25 12:05:21 - building ETHERNUT5 kernel TB --- 2013-11-25 12:05:21 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 12:05:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 12:05:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 12:05:21 - SRCCONF=/dev/null TB --- 2013-11-25 12:05:21 - TARGET=arm TB --- 2013-11-25 12:05:21 - TARGET_ARCH=arm TB --- 2013-11-25 12:05:21 - TZ=UTC TB --- 2013-11-25 12:05:21 - __MAKE_CONF=/dev/null TB --- 2013-11-25 12:05:21 - cd /src TB --- 2013-11-25 12:05:21 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Mon Nov 25 12:05:21 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ETHERNUT5 completed on Mon Nov 25 12:15:58 UTC 2013 TB --- 2013-11-25 12:15:58 - cd /src/sys/arm/conf TB --- 2013-11-25 12:15:58 - /usr/sbin/config -m GUMSTIX TB --- 2013-11-25 12:15:58 - building GUMSTIX kernel TB --- 2013-11-25 12:15:58 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 12:15:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 12:15:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 12:15:58 - SRCCONF=/dev/null TB --- 2013-11-25 12:15:58 - TARGET=arm TB --- 2013-11-25 12:15:58 - TARGET_ARCH=arm TB --- 2013-11-25 12:15:58 - TZ=UTC TB --- 2013-11-25 12:15:58 - __MAKE_CONF=/dev/null TB --- 2013-11-25 12:15:58 - cd /src TB --- 2013-11-25 12:15:58 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Mon Nov 25 12:15:58 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] 4. Running pass 'ARM Instruction Selection' on function '@smc_task_rx' cc: error: unable to execute command: Abort trap: 6 (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: arm--freebsd11.0-gnueabi Thread model: posix cc: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. cc: note: diagnostic msg: Error generating preprocessed source(s). *** Error code 254 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/GUMSTIX *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-25 12:16:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 12:16:24 - ERROR: failed to build GUMSTIX kernel TB --- 2013-11-25 12:16:24 - 11645.27 user 2482.21 system 15362.95 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 12:36:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C1C415A; Mon, 25 Nov 2013 12:36:46 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB5192638; Mon, 25 Nov 2013 12:36:45 +0000 (UTC) Received: from [192.168.2.2] (unknown [77.243.161.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B998B5C43; Mon, 25 Nov 2013 13:36:33 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_6B476347-C466-46E3-838F-F7C305574CDE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Buildworld broken with WITHOUT_DYNAMICROOT=yes in src.conf From: Dimitry Andric In-Reply-To: <20131125075110.GL59496@kib.kiev.ua> Date: Mon, 25 Nov 2013 13:36:15 +0100 Message-Id: <063D36C2-E1D0-449E-A662-0CCA5A9B887E@FreeBSD.org> References: <201311250111.rAP1BuI0009520@pozo.com> <20131125011949.GC1627@glenbarber.us> <20131125012302.GD1627@glenbarber.us> <201311250129.rAP1TJfQ033437@pozo.com> <20131125041724.GA2310@glenbarber.us> <201311250441.rAP4freb002330@pozo.com> <20131125044854.GC2310@glenbarber.us> <20131125075110.GL59496@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1822) Cc: Glen Barber , freebsd-current , peter@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 12:36:46 -0000 --Apple-Mail=_6B476347-C466-46E3-838F-F7C305574CDE Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 25 Nov 2013, at 08:51, Konstantin Belousov wrote: > On Sun, Nov 24, 2013 at 11:48:54PM -0500, Glen Barber wrote: ... >> Index: Makefile >> =================================================================== >> --- Makefile (revision 258538) >> +++ Makefile (working copy) >> @@ -42,6 +42,9 @@ >> >> DPADD= ${LIBTERMCAP} ${LIBCRYPT} >> LDADD= -ltermcap -lcrypt >> +.if ${MK_ICONV} != "no" && ${MK_DYNAMICROOT} != "yes" >> +LDADD+= -lc_nonshared >> +.endif >> >> LINKS= ${BINDIR}/csh ${BINDIR}/tcsh >> > > No, this is wrong. As is, static linking is broken and the hack above > only fixes one case. > > What is needed is inclusion of the lib/libc_nonshared object files into > static libc.a. I am not sure how to express this in our build system. Hi Kostik, You can add the additional object files to ${STATICOBJS}. These will only be built for the static and profiled libraries. See for example gnu/lib/libgcc/Makefile or lib/libc++/Makefile. -Dimitry --Apple-Mail=_6B476347-C466-46E3-838F-F7C305574CDE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKTREoACgkQsF6jCi4glqOEIgCfZ33y/qfivaOAlC3s3px0qJXx MsoAnibbBjhrkxVRp/QGFZvI7OBp5+T4 =QfPp -----END PGP SIGNATURE----- --Apple-Mail=_6B476347-C466-46E3-838F-F7C305574CDE-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 12:54:51 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 900086EB for ; Mon, 25 Nov 2013 12:54:51 +0000 (UTC) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D1D22747 for ; Mon, 25 Nov 2013 12:54:50 +0000 (UTC) Received: from ul9n (199.102.77.238) by DB3PR06MB172.eurprd06.prod.outlook.com (10.141.1.151) with Microsoft SMTP Server (TLS) id 15.0.800.7; Mon, 25 Nov 2013 12:54:42 +0000 Date: Mon, 25 Nov 2013 12:54:31 +0000 From: Anthony Perkins To: Subject: Patch: Add option to fmt to ignore email reply lines Message-ID: <20131125125430.GC67451@ul9n> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-Originating-IP: [199.102.77.238] X-ClientProxiedBy: BL2PR03CA001.namprd03.prod.outlook.com (10.255.109.18) To DB3PR06MB172.eurprd06.prod.outlook.com (10.141.1.151) X-Forefront-PRVS: 0041D46242 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(199002)(189002)(66654002)(56776001)(81686001)(568964001)(54316002)(47446002)(80976001)(63696002)(69226001)(56816003)(77096001)(74366001)(33716001)(87266001)(33656001)(512954002)(79102001)(76796001)(74502001)(74662001)(31966008)(76786001)(81816001)(71186001)(81342001)(83506001)(76176001)(46102001)(51856001)(66066001)(54356001)(42186004)(53806001)(74876001)(80022001)(74706001)(50986001)(49866001)(47736001)(81542001)(65816001)(47976001)(84326002)(85306002)(4396001)(59766001)(87976001)(83072001)(76482001)(83322001)(77982001)(19580395003); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR06MB172; H:ul9n; CLIP:199.102.77.238; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: acperkins.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 12:54:51 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline I've added an option to 'fmt' to ignore lines beginning with the greater-than symbol, so that whole email replies can be piped through fmt (e.g. via vi from mutt) without needing to repeat the command for each of my paragraphs. This is my first real patch, so I would appreciate any feedback. Many thanks, Anthony --LQksG6bCIzRHxTLp Content-Type: text/x-diff; charset="us-ascii" Content-Disposition: attachment; filename="ignore-email-replies.diff" Index: fmt.1 =================================================================== --- fmt.1 (revision 258550) +++ fmt.1 (working copy) @@ -99,6 +99,10 @@ .Fl p flag, any change in the amount of whitespace at the start of a line results in a new paragraph being begun. +.It Fl r +Ignore lines beginning with a +.Ql \&> +(greater-than) character, marking email replies. .It Fl s Collapse whitespace inside lines, so that multiple whitespace characters are turned into a single space. Index: fmt.c =================================================================== --- fmt.c (revision 258550) +++ fmt.c (working copy) @@ -227,6 +227,7 @@ static const wchar_t *sentence_enders=L".?!"; /* Double-space after these */ static int grok_mail_headers=0; /* treat embedded mail headers magically? */ static int format_troff=0; /* Format troff? */ +static int format_email_replies=1; /* Format email replies? */ static int n_errors=0; /* Number of failed files. Return on exit. */ static wchar_t *output_buffer=0; /* Output line will be built here */ @@ -266,7 +267,7 @@ /* 1. Grok parameters. */ - while ((ch = getopt(argc, argv, "0123456789cd:hl:mnpst:w:")) != -1) + while ((ch = getopt(argc, argv, "0123456789cd:hl:mnprst:w:")) != -1) switch(ch) { case 'c': centerP = 1; @@ -294,6 +295,9 @@ case 'p': allow_indented_paragraphs = 1; continue; + case 'r': + format_email_replies = 0; + continue; case 's': coalesce_spaces_P = 1; continue; @@ -328,6 +332,7 @@ " -m try to make sure mail header lines stay separate\n" " -n format lines beginning with a dot\n" " -p allow indented paragraphs\n" +" -r ignore lines beginning with a greater-than sign\n" " -s coalesce whitespace inside lines\n" " -t have tabs every columns\n" " -w set maximum width to \n" @@ -419,6 +424,7 @@ /* We need a new paragraph if and only if: * this line is blank, * OR it's a troff request (and we don't format troff), + * OR it's not an email reply, prefixed with ">" * OR it's a mail header, * OR it's not a mail header AND the last line was one, * OR the indentation has changed @@ -427,6 +433,7 @@ */ if ( length==0 || (line[0]=='.' && !format_troff) + || (line[0]=='>' && !format_email_replies) || header_type==hdr_Header || (header_type==hdr_NonHeader && prev_header_type>hdr_NonHeader) || (np!=last_indent @@ -437,7 +444,8 @@ first_indent = np; last_indent = np; if (header_type==hdr_Header) last_indent=2; /* for cont. lines */ - if (length==0 || (line[0]=='.' && !format_troff)) { + if (length==0 || (line[0]=='.' && !format_troff) || + (line[0]=='>' && !format_email_replies)) { if (length==0) putwchar('\n'); else --LQksG6bCIzRHxTLp-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 14:14:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB1C5D08; Mon, 25 Nov 2013 14:14:07 +0000 (UTC) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FDC82C56; Mon, 25 Nov 2013 14:14:07 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id ECC5860DB; Mon, 25 Nov 2013 09:13:59 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=CEa/vafMiKOLGT5nrHmWBZzCLyKP/TKD8CJ6pdLXcgKXhFouBM8ID2nbrl4BggRzh +C97c+4ZpE4ffXxDMp85KpMfIL+0+spScG8ZZy9yI4vUL3LlrCj0AKtM8X75oWP Message-ID: <52935B26.9010105@protected-networks.net> Date: Mon, 25 Nov 2013 09:13:58 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current , dumbbell@freebsd.org Subject: SVN r258549 breaks -current compiled with gcc X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:14:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As follows: - --- drm_linux_list_sort.o --- cc1: warnings being treated as errors /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_linux_list_sort.c: In function 'drm_le_cmp': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_linux_list_sort.c:45: warning: cast discards qualifiers from pointer target type /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_linux_list_sort.c:46: warning: cast discards qualifiers from pointer target type *** [drm_linux_list_sort.o] Error code 1 imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlKTWyYACgkQQv9rrgRC1JIv9ACggu06a5cfI2u6zt/45gLW/VU6 /sAAoICTUVfOskh4H0O5uJcVX31ceddX =qONm -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 14:45:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 730F3A66 for ; Mon, 25 Nov 2013 14:45:43 +0000 (UTC) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3755F2EB8 for ; Mon, 25 Nov 2013 14:45:43 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VkxPu-000N5o-O6; Mon, 25 Nov 2013 15:45:39 +0100 Message-ID: <5293628A.6080508@FreeBSD.org> Date: Mon, 25 Nov 2013 15:45:30 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Michael Butler , freebsd-current Subject: Re: SVN r258549 breaks -current compiled with gcc References: <52935B26.9010105@protected-networks.net> In-Reply-To: <52935B26.9010105@protected-networks.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tsNu2uBWFEXPwoB2s6TED9han7bgqAtEb" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:45:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tsNu2uBWFEXPwoB2s6TED9han7bgqAtEb Content-Type: multipart/mixed; boundary="------------040905040508070108060501" This is a multi-part message in MIME format. --------------040905040508070108060501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 25.11.2013 15:13, Michael Butler wrote: > --- drm_linux_list_sort.o --- > cc1: warnings being treated as errors > /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_linux_list_sort.c:= > In function 'drm_le_cmp': > /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_linux_list_sort.c:= 45: > warning: cast discards qualifiers from pointer target type Hello! Can you try the attached patch? I got rid of __DECONST() because clang didn't complain, sorry... --=20 Jean-S=E9bastien P=E9dron --------------040905040508070108060501 Content-Type: text/x-patch; name="drm_linux_list_sort-deconst.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="drm_linux_list_sort-deconst.patch" diff --git a/sys/dev/drm2/drm_linux_list_sort.c b/sys/dev/drm2/drm_linux_= list_sort.c index ae4cd64..19c5c9e 100644 --- a/sys/dev/drm2/drm_linux_list_sort.c +++ b/sys/dev/drm2/drm_linux_list_sort.c @@ -42,8 +42,8 @@ drm_le_cmp(void *priv, const void *d1, const void *d2) struct drm_list_sort_thunk *thunk; =20 thunk =3D priv; - le1 =3D *(struct list_head **)d1; - le2 =3D *(struct list_head **)d2; + le1 =3D *(__DECONST(struct list_head **, d1)); + le2 =3D *(__DECONST(struct list_head **, d2)); return ((thunk->cmp)(thunk->priv, le1, le2)); } =20 --------------040905040508070108060501-- --tsNu2uBWFEXPwoB2s6TED9han7bgqAtEb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKTYpIACgkQa+xGJsFYOlOZ3QCguc2wZe+iHUAZjyOnALmatY0z 4rEAoNRIaWM4LcZa+nnXQWavccuTgKsH =JsTs -----END PGP SIGNATURE----- --tsNu2uBWFEXPwoB2s6TED9han7bgqAtEb-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 14:48:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9F64C87 for ; Mon, 25 Nov 2013 14:48:25 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 96ED12EDE for ; Mon, 25 Nov 2013 14:48:25 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id m1so4438917oag.31 for ; Mon, 25 Nov 2013 06:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4LLxAk/WIBuHKrpoj44uUxELPrpCdHCT7/W7Pmm8qkc=; b=qO4gfd+TQzPdk7EbOBItNK/+4XoAPBmHFab7TJnMGnpcHmxh5cTGmAyOv02qJXkj35 RMiwM2uN9lLHfw2AifbRpZM6MjR0blb7/6x2FouVCxFYAuaEzSlvvo/VU0ntdRsH1BQT Dxof5vOXnDDzJbtFd44VwTEHjdiid38fey2lnatCf/aIqXHtU1Dwg1OtG6DxfEdoB4V/ epuLDBBYRZZN7prc6rLuwLKWWLBj6+zq9Ip23MXvhc5Lkm4I4zg0ToqxGno6piw4I/6S lH94hxLVypn+Nd5583LPs3HvsbogNbzO/BCeI9eJNMBfD9GXQ/lr2bKje9v4+SdD3lTa 94/A== MIME-Version: 1.0 X-Received: by 10.60.50.168 with SMTP id d8mr228152oeo.77.1385390904832; Mon, 25 Nov 2013 06:48:24 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.182.110.195 with HTTP; Mon, 25 Nov 2013 06:48:24 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Nov 2013 06:48:24 -0800 X-Google-Sender-Auth: bvMBkAJxGtHJ1yli3VaOWaMDcPY Message-ID: Subject: Re: sysctl add macros From: Matthew Fleming To: Venkata Duvvuru Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:48:25 -0000 On Mon, Nov 25, 2013 at 3:35 AM, Venkata Duvvuru < VenkatKumar.Duvvuru@emulex.com> wrote: > Hi, > I'm unable to figure out how to add an unsigned short or an unsigned char > values to a sysctl node. > SYSCTL_ADD_INT, SYSCTL_ADD_UINT, etc., are present but to add a char or a > short values I couldn't find any macros. > > Could you please let me know how to add them? > FreeBSD does not have any sysctl handlers for 1 or 2 byte values. FreeBSD code that wants to do this has used int or u_int instead of a smaller type. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 14:50:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA042DAC; Mon, 25 Nov 2013 14:50:32 +0000 (UTC) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B47A2F1E; Mon, 25 Nov 2013 14:50:32 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 08C9660DB; Mon, 25 Nov 2013 09:50:30 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=MVePf4/ijTeZgcbQCZQpezwOdH5EE8+mGFmV0lO4fXF2G0+UKJuZpJ+wRbP22Mkw2 2UH3U9Yv1uWZ8HZXjbVjYSeNwuyVVlwrEF+6+1PO4phgz29bqRzFXvnYJQLUmxj Message-ID: <529363B5.8020207@protected-networks.net> Date: Mon, 25 Nov 2013 09:50:29 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , freebsd-current Subject: Re: SVN r258549 breaks -current compiled with gcc References: <52935B26.9010105@protected-networks.net> <5293628A.6080508@FreeBSD.org> In-Reply-To: <5293628A.6080508@FreeBSD.org> X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:50:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/25/13 09:45, Jean-Sébastien Pédron wrote: > On 25.11.2013 15:13, Michael Butler wrote: >> --- drm_linux_list_sort.o --- >> cc1: warnings being treated as errors >> /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_linux_list_sort.c: >> In function 'drm_le_cmp': >> /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_linux_list_sort.c:45: >> warning: cast discards qualifiers from pointer target type > > Hello! > > Can you try the attached patch? > > I got rid of __DECONST() because clang didn't complain, sorry... That fixed it - thanks! :-) imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlKTY7UACgkQQv9rrgRC1JKqEgCgoMTBkjDdNrrA94Jry1lOKB30 Sk4AoKiaOo8ZPyEAxR2FxjAbpbRHpw6v =fcGs -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 14:58:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47EF0F8; Mon, 25 Nov 2013 14:58:53 +0000 (UTC) Received: from CMEXEDGE1.ext.emulex.com (cmexedge1.ext.emulex.com [138.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 251142F91; Mon, 25 Nov 2013 14:58:53 +0000 (UTC) Received: from CMEXHTCAS1.ad.emulex.com (138.239.115.217) by CMEXEDGE1.ext.emulex.com (138.239.224.99) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 25 Nov 2013 06:59:06 -0800 Received: from CMEXMB1.ad.emulex.com ([169.254.1.137]) by CMEXHTCAS1.ad.emulex.com ([2002:8aef:73d9::8aef:73d9]) with mapi id 14.03.0146.002; Mon, 25 Nov 2013 06:58:51 -0800 From: Venkata Duvvuru To: Matthew Fleming Subject: RE: sysctl add macros Thread-Topic: sysctl add macros Thread-Index: Ac7py2Eb3GYul2HXQGupi09t7TvnXQAZRFYAABCOHkA= Date: Mon, 25 Nov 2013 14:58:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.226.252.30] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:58:53 -0000 The problem with using int or u_int for 1 or 2 byte values is that while pr= inting these 1 or 2 byte values I observed that sysctl module is considerin= g 4 bytes. Hence I see an undesired output. It is actually considering the = next two bytes also as the value. /Venkat. From: mdf356@gmail.com [mailto:mdf356@gmail.com] On Behalf Of Matthew Flemi= ng Sent: Monday, November 25, 2013 8:18 PM To: Venkata Duvvuru Cc: freebsd-current@freebsd.org Subject: Re: sysctl add macros On Mon, Nov 25, 2013 at 3:35 AM, Venkata Duvvuru > wrote: Hi, I'm unable to figure out how to add an unsigned short or an unsigned char v= alues to a sysctl node. SYSCTL_ADD_INT, SYSCTL_ADD_UINT, etc., are present but to add a char or a s= hort values I couldn't find any macros. Could you please let me know how to add them? FreeBSD does not have any sysctl handlers for 1 or 2 byte values. FreeBSD = code that wants to do this has used int or u_int instead of a smaller type. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 15:18:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5501AAB3; Mon, 25 Nov 2013 15:18:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0FC9A20F9; Mon, 25 Nov 2013 15:18:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAPFIgx9094654; Mon, 25 Nov 2013 10:18:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAPFIg7u094648; Mon, 25 Nov 2013 15:18:42 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 15:18:42 GMT Message-Id: <201311251518.rAPFIg7u094648@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 15:18:44 -0000 TB --- 2013-11-25 13:43:32 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-25 13:43:32 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 13:43:32 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-11-25 13:43:32 - cleaning the object tree TB --- 2013-11-25 13:44:53 - /usr/local/bin/svn stat /src TB --- 2013-11-25 13:44:58 - At svn revision 258542 TB --- 2013-11-25 13:44:59 - building world TB --- 2013-11-25 13:44:59 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 13:44:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 13:44:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 13:44:59 - SRCCONF=/dev/null TB --- 2013-11-25 13:44:59 - TARGET=ia64 TB --- 2013-11-25 13:44:59 - TARGET_ARCH=ia64 TB --- 2013-11-25 13:44:59 - TZ=UTC TB --- 2013-11-25 13:44:59 - __MAKE_CONF=/dev/null TB --- 2013-11-25 13:44:59 - cd /src TB --- 2013-11-25 13:44:59 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 25 13:45:07 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-25 15:18:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 15:18:42 - ERROR: failed to build world TB --- 2013-11-25 15:18:42 - 4352.02 user 745.08 system 5709.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 17:21:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35A534FD for ; Mon, 25 Nov 2013 17:21:42 +0000 (UTC) Received: from forward14.mail.yandex.net (forward14.mail.yandex.net [95.108.130.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB65329DA for ; Mon, 25 Nov 2013 17:21:41 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward14.mail.yandex.net (Yandex) with ESMTP id D4EE71980B20 for ; Mon, 25 Nov 2013 21:21:27 +0400 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id B6AFB7E050B for ; Mon, 25 Nov 2013 21:21:27 +0400 (MSK) Received: from unknown (unknown [178.76.234.16]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTP id eLK4uOXvoW-LRW0GHMP; Mon, 25 Nov 2013 21:21:27 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1385400087; bh=xCU/xMIOHmKMpu9hIGsNvaXvcUwEFSGgBK4WoXNkfEo=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=eBoShRCrOdXRbqUA/GH4whJbcwXbPusmy98sxVKp6pWVEsI1Vdv+4+zRvJ/ODqzx+ 3EbyeFWFycIAdLUc8m/PbdeowE+s/qGfhpJTO0TJ1ItMoH6aYWGGXJXYxJbGkm4uUz c2v5KMkVFdkfF1lKl0xD/KGqwljbX6+0J2eTodIM= Authentication-Results: smtp11.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <52938713.3010707@yandex.ru> Date: Mon, 25 Nov 2013 21:21:23 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: FreeBSD Current Subject: security/nmap runtime on -current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 17:21:42 -0000 Any simple command like `nmap -p80 localhost` fails with this: Starting Nmap 6.40 ( http://nmap.org ) at 2013-11-25 21:17 MSK Assertion failed: (rc == 0), function collect_dnet_interfaces, file netutil.cc, line 1326. Abort (core dumped) Does anybody have a clue? There is similar report w/o feedback: http://comments.gmane.org/gmane.os.freebsd.devel.ports/114620 PS. FreeBSD 11.0-CURRENT #37 r258192 -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 17:35:40 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 662789BE; Mon, 25 Nov 2013 17:35:40 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D05F52AB4; Mon, 25 Nov 2013 17:35:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAPHZRwo033437; Mon, 25 Nov 2013 19:35:27 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAPHZRwo033437 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAPHZRWj033436; Mon, 25 Nov 2013 19:35:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Nov 2013 19:35:27 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: gdb has outdated knowledge of signal trampolines Message-ID: <20131125173527.GP59496@kib.kiev.ua> References: <529322E1.1060105@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Aw0In/cjXooETgsz" Content-Disposition: inline In-Reply-To: <529322E1.1060105@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current , Luca Pizzamiglio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 17:35:40 -0000 --Aw0In/cjXooETgsz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2013 at 12:13:53PM +0200, Andriy Gapon wrote: >=20 > It seems that placement of signal trampolines was changed a while ago. P= ossibly > with the introduction of the shared page, but I am not sure. > Unfortunately, neither the gdb in base nor the ports gdb were updated to = account > for the new location. >=20 > And thus, for example: > (kgdb) bt > #0 thr_kill () at thr_kill.S:3 > #1 0x00000008032c89a7 in nsProfileLock::FatalSignalHandler (signo=3D6, > info=3D, context=3D0x7ffffb197630) > at > /usr/obj/ports/usr/ports/www/firefox/work/mozilla-release/obj-x86_64-unkn= own-freebsd11.0/toolkit/profile/nsProfileLock.cpp:180 > #2 0x0000000800f90596 in handle_signal (actp=3D, sig=3D6, > info=3D0x7ffffb1979a0, ucp=3D0x7ffffb197630) at /usr/src/lib/libthr/threa= d/thr_sig.c:237 > #3 0x0000000800f9013f in thr_sighandler (sig=3D6, info=3D0x0, _ucp=3D0x7= ffffb197630) > at /usr/src/lib/libthr/thread/thr_sig.c:182 > #4 0x00007ffffffff003 in ?? () > #5 0x0000000800f90010 in ?? () at /usr/src/lib/libthr/thread/thr_sig.c:5= 66 from > /lib/libthr.so.3 > #6 0x0000000000000000 in ?? () >=20 > Obviously, the gdb is confused after the frame that has 0x00007ffffffff00= 3. >=20 > I looked only at amd64 code, but I believe that other platforms (all of t= hem?) > are affected as well. >=20 > The following proof of concept patch for the base gdb seems to fix the ca= se of > native debugging on amd64 (target case was not tested). >=20 > diff --git a/contrib/gdb/gdb/amd64fbsd-nat.c b/contrib/gdb/gdb/amd64fbsd-= nat.c > index f083734..d49dc45 100644 > --- a/contrib/gdb/gdb/amd64fbsd-nat.c > +++ b/contrib/gdb/gdb/amd64fbsd-nat.c > @@ -212,24 +212,23 @@ Please report this to .", >=20 > SC_RBP_OFFSET =3D offset; >=20 > - /* FreeBSD provides a kern.ps_strings sysctl that we can use to > + /* FreeBSD provides a kern.usrstack sysctl that we can use to > locate the sigtramp. That way we can still recognize a sigtramp > if its location is changed in a new kernel. Of course this is > still based on the assumption that the sigtramp is placed > - directly under the location where the program arguments and > - environment can be found. */ > + directly at usrstack. */ > { > int mib[2]; > - long ps_strings; > + long usrstack; > size_t len; >=20 > mib[0] =3D CTL_KERN; > - mib[1] =3D KERN_PS_STRINGS; > - len =3D sizeof (ps_strings); > - if (sysctl (mib, 2, &ps_strings, &len, NULL, 0) =3D=3D 0) > + mib[1] =3D KERN_USRSTACK; > + len =3D sizeof (usrstack); > + if (sysctl (mib, 2, &usrstack, &len, NULL, 0) =3D=3D 0) > { > - amd64fbsd_sigtramp_start_addr =3D ps_strings - 32; > - amd64fbsd_sigtramp_end_addr =3D ps_strings; > + amd64fbsd_sigtramp_start_addr =3D usrstack; > + amd64fbsd_sigtramp_end_addr =3D usrstack + 0x20; > } > } > } > diff --git a/contrib/gdb/gdb/amd64fbsd-tdep.c b/contrib/gdb/gdb/amd64fbsd= -tdep.c > index e4e02ab..87c1484 100644 > --- a/contrib/gdb/gdb/amd64fbsd-tdep.c > +++ b/contrib/gdb/gdb/amd64fbsd-tdep.c > @@ -86,8 +86,8 @@ static int amd64fbsd_r_reg_offset[] =3D > }; >=20 > /* Location of the signal trampoline. */ > -CORE_ADDR amd64fbsd_sigtramp_start_addr =3D 0x7fffffffffc0; > -CORE_ADDR amd64fbsd_sigtramp_end_addr =3D 0x7fffffffffe0; > +CORE_ADDR amd64fbsd_sigtramp_start_addr =3D 0x7ffffffff000; > +CORE_ADDR amd64fbsd_sigtramp_end_addr =3D 0x7ffffffff020; >=20 > /* From . */ > int amd64fbsd_sc_reg_offset[] =3D >=20 Yes, your observation is correct, but the patch could be improved. Specifically, the location of the signal trampoline code which you hard-coded into the patch is not guaranteed to be stable, and in fact somewhat depends on the order of ABI sysvecs registration. The size of the signal trampoline is not fixed as well. Real solution is to start provide vdso for signal trampolines, which is probably the only real reason to have vdso at all. But this is labor-intensive and I am not convinced that the ABI changes are worth it right now. Instead, I propose the following sysctl helper which should provide the same 'hackish' way to get the trampoline location, which would work both for 64bit and 32bit, for later on i386 and amd64. For core files, this is as bad as before since we cannot guarantee stability of the trampoline location. Could you update your gdb patch to use the KERN_PROC_SIGTRAMP from the patch below ? If this works out, I will add initialization of sv_szsigcode for ABIs which do not use shared page. Thank you for looking into this. sys/compat/freebsd32/freebsd32.h | 6 +++++ sys/kern/kern_proc.c | 58 ++++++++++++++++++++++++++++++++++++= ++++ sys/sys/sysctl.h | 1 + sys/sys/user.h | 6 +++++ 4 files changed, 71 insertions(+) diff --git a/sys/compat/freebsd32/freebsd32.h b/sys/compat/freebsd32/freebs= d32.h index 8376e95..94f886e 100644 --- a/sys/compat/freebsd32/freebsd32.h +++ b/sys/compat/freebsd32/freebsd32.h @@ -362,6 +362,12 @@ struct kinfo_proc32 { int ki_tdflags; }; =20 +struct kinfo_sigtramp32 { + uint32_t ksigtramp_start; + uint32_t ksigtramp_end; + uint32_t ksigtramp_spare[4]; +}; + struct kld32_file_stat_1 { int version; /* set to sizeof(struct kld_file_stat_1) */ char name[MAXPATHLEN]; diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c index 9968e76..2e6bc32 100644 --- a/sys/kern/kern_proc.c +++ b/sys/kern/kern_proc.c @@ -2632,6 +2632,60 @@ errout: return (error); } =20 +static int +sysctl_kern_proc_sigtramp(SYSCTL_HANDLER_ARGS) +{ + int *name =3D (int *)arg1; + u_int namelen =3D arg2; + struct proc *p; + struct kinfo_sigtramp kst; + const struct sysentvec *sv; + int error; +#ifdef COMPAT_FREEBSD32 + struct kinfo_sigtramp32 kst32; +#endif + + if (namelen !=3D 1) + return (EINVAL); + + error =3D pget((pid_t)name[0], PGET_CANDEBUG, &p); + if (error !=3D 0) + return (error); + sv =3D p->p_sysent; +#ifdef COMPAT_FREEBSD32 + if ((req->flags & SCTL_MASK32) !=3D 0) { + bzero(&kst32, sizeof(kst32)); + if (SV_PROC_FLAG(p, SV_ILP32)) { + if (sv->sv_sigcode_base !=3D 0) { + kst32.ksigtramp_start =3D sv->sv_sigcode_base; + kst32.ksigtramp_end =3D sv->sv_sigcode_base + + *sv->sv_szsigcode; + } else { + kst32.ksigtramp_start =3D sv->sv_psstrings - + *sv->sv_szsigcode; + kst32.ksigtramp_end =3D sv->sv_psstrings; + } + } + PROC_UNLOCK(p); + error =3D SYSCTL_OUT(req, &kst32, sizeof(kst32)); + return (error); + } +#endif + bzero(&kst, sizeof(kst)); + if (sv->sv_sigcode_base !=3D 0) { + kst.ksigtramp_start =3D (char *)sv->sv_sigcode_base; + kst.ksigtramp_end =3D (char *)sv->sv_sigcode_base + + *sv->sv_szsigcode; + } else { + kst.ksigtramp_start =3D (char *)sv->sv_psstrings - + *sv->sv_szsigcode; + kst.ksigtramp_end =3D (char *)sv->sv_psstrings; + } + PROC_UNLOCK(p); + error =3D SYSCTL_OUT(req, &kst, sizeof(kst)); + return (error); +} + SYSCTL_NODE(_kern, KERN_PROC, proc, CTLFLAG_RD, 0, "Process table"); =20 SYSCTL_PROC(_kern_proc, KERN_PROC_ALL, all, CTLFLAG_RD|CTLTYPE_STRUCT| @@ -2740,3 +2794,7 @@ static SYSCTL_NODE(_kern_proc, KERN_PROC_UMASK, umask= , CTLFLAG_RD | static SYSCTL_NODE(_kern_proc, KERN_PROC_OSREL, osrel, CTLFLAG_RW | CTLFLAG_ANYBODY | CTLFLAG_MPSAFE, sysctl_kern_proc_osrel, "Process binary osreldate"); + +static SYSCTL_NODE(_kern_proc, KERN_PROC_SIGTRAMP, sigtramp, CTLFLAG_RD | + CTLFLAG_MPSAFE, sysctl_kern_proc_sigtramp, + "Process signal trampoline location"); diff --git a/sys/sys/sysctl.h b/sys/sys/sysctl.h index 64292ba..8e70a12 100644 --- a/sys/sys/sysctl.h +++ b/sys/sys/sysctl.h @@ -530,6 +530,7 @@ SYSCTL_ALLOWED_TYPES(UINT64, uint64_t *a; unsigned long= long *b; ); #define KERN_PROC_PS_STRINGS 38 /* get ps_strings location */ #define KERN_PROC_UMASK 39 /* process umask */ #define KERN_PROC_OSREL 40 /* osreldate for process binary */ +#define KERN_PROC_SIGTRAMP 41 /* signal trampoline location */ =20 /* * KERN_IPC identifiers diff --git a/sys/sys/user.h b/sys/sys/user.h index d2e2b6e..e926fe8 100644 --- a/sys/sys/user.h +++ b/sys/sys/user.h @@ -498,6 +498,12 @@ struct kinfo_kstack { int _kkst_ispare[16]; /* Space for more stuff. */ }; =20 +struct kinfo_sigtramp { + void *ksigtramp_start; + void *ksigtramp_end; + void *ksigtramp_spare[4]; +}; + #ifdef _KERNEL /* Flags for kern_proc_out function. */ #define KERN_PROC_NOTHREADS 0x1 --Aw0In/cjXooETgsz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSk4peAAoJEJDCuSvBvK1B3nwQAJ5hKH7epNixI4H3qAt/fpel X2JfUui1MbR6HpuIdTArylwwPdic2JvRhRbhdxNvEy3mbS3zSVKK32MakZvwExnt kVh+HljDkapHg61/Z8cNM9hF94a1db45zueVm6KTXHEHx2O4fawusWQ2ShRjIsp0 ZZv2HlEa2zo+DpHUstIDcPZwjSaew7ac5ExORg32XseqrbbXWAtUUz6kzdCtEvIs U6lK2gnFBgjdKc5hAxwOMFOlLncXT/FDQykB8W9SvqQDa147s1iNAHwTDmRlGMPa EVWd1mjlWV7haYWomEAXMkGbSLGLDElGAMqmXJbEfWPavJXLGATBgOCgec1q1n3f 9zO2CX2xFVL48Z0txk5uhdKChntQvvU0rrSuD+6E4dLQQbAKQxTZczV4Nem8qx+j 7ED3ysDYzqnGP//U1wY/t3omfzPScOAtjZI9j5S6iSIw1Xg5a/GEO2f23uMM+8VI RrIPES0V79J/NDjcZfR4SolFD95ocqqq3FjFH1lSLWcPZdcRtdQ6yTgSDTbPEXLM vRP12d+JZUcesf/4BsTutP/bP3+/hiRV6NFxzFWFTL/rlghiveisgMqo/Of61ldi G4elxwO6cU0BH0E7bnHUB+n+UZ2rxDfpWmj5IgRXTuCIRP3txjVqvg1D+D5vd5HF paO4OEYDNZ+kECW/lpXA =q/dW -----END PGP SIGNATURE----- --Aw0In/cjXooETgsz-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 17:41:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88F35CA1 for ; Mon, 25 Nov 2013 17:41:20 +0000 (UTC) Received: from forward14.mail.yandex.net (forward14.mail.yandex.net [IPv6:2a02:6b8:0:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B06E2B45 for ; Mon, 25 Nov 2013 17:41:20 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward14.mail.yandex.net (Yandex) with ESMTP id D7676198198A for ; Mon, 25 Nov 2013 21:41:17 +0400 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id B98E016A0A0F for ; Mon, 25 Nov 2013 21:41:17 +0400 (MSK) Received: from unknown (unknown [178.76.234.16]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTP id K9Cz4GLRZG-fHp8FRDu; Mon, 25 Nov 2013 21:41:17 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1385401277; bh=/0mWQYxffdSOn/VFsOcXnRQUvTQpIklR/3zQT7Wsmlk=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=rxCbpzq9D/0qWE+wnO5vALKlYOi2bbQmRjxRB7/DuJjwNA/gWOJ0BT56yFrQ8OeIO FOhQVwI0WT/N62aNCp9jIwVvczM+tk8gI/ohh8bYPgXervixg2GPHiBP+4eebXhFcq 4P6LEyJJE5UvrPlKpcsdISG8T9cSDC4FJYWIn0Tk= Authentication-Results: smtp12.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <52938BB9.8010806@yandex.ru> Date: Mon, 25 Nov 2013 21:41:13 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: FreeBSD Current Subject: Re: security/nmap runtime on -current References: <52938713.3010707@yandex.ru> In-Reply-To: <52938713.3010707@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 17:41:20 -0000 Ruslan Makhmatkhanov wrote on 25.11.2013 21:21: > > Any simple command like `nmap -p80 localhost` fails with this: > > Starting Nmap 6.40 ( http://nmap.org ) at 2013-11-25 21:17 MSK > Assertion failed: (rc == 0), function collect_dnet_interfaces, file > netutil.cc, line 1326. > Abort (core dumped) > > Does anybody have a clue? > > There is similar report w/o feedback: > http://comments.gmane.org/gmane.os.freebsd.devel.ports/114620 > > PS. FreeBSD 11.0-CURRENT #37 r258192 K, respond to myself. This upstream commit fixing the issue: https://github.com/nmap/nmap/commit/542b0af577dabab68a63b5c20b36c6ec9061b77d#diff-d604578eada1b9284c2f74ba369b7ab9 I just submitted ports/184288 with this. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 18:00:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 564F960C; Mon, 25 Nov 2013 18:00:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1019E2C21; Mon, 25 Nov 2013 18:00:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAPI0TOs005129; Mon, 25 Nov 2013 13:00:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAPI0Tu0005122; Mon, 25 Nov 2013 18:00:29 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 18:00:29 GMT Message-Id: <201311251800.rAPI0Tu0005122@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 18:00:31 -0000 TB --- 2013-11-25 15:18:42 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-25 15:18:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 15:18:42 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-25 15:18:42 - cleaning the object tree TB --- 2013-11-25 15:19:51 - /usr/local/bin/svn stat /src TB --- 2013-11-25 15:19:54 - At svn revision 258542 TB --- 2013-11-25 15:19:55 - building world TB --- 2013-11-25 15:19:55 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 15:19:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 15:19:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 15:19:55 - SRCCONF=/dev/null TB --- 2013-11-25 15:19:55 - TARGET=powerpc TB --- 2013-11-25 15:19:55 - TARGET_ARCH=powerpc TB --- 2013-11-25 15:19:55 - TZ=UTC TB --- 2013-11-25 15:19:55 - __MAKE_CONF=/dev/null TB --- 2013-11-25 15:19:55 - cd /src TB --- 2013-11-25 15:19:55 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 25 15:20:03 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-25 18:00:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 18:00:29 - ERROR: failed to build world TB --- 2013-11-25 18:00:29 - 8005.01 user 1033.00 system 9706.59 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 18:02:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 076469FD; Mon, 25 Nov 2013 18:02:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B5A862C7A; Mon, 25 Nov 2013 18:02:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAPI2fc5013776; Mon, 25 Nov 2013 13:02:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAPI2f2h013773; Mon, 25 Nov 2013 18:02:41 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 18:02:41 GMT Message-Id: <201311251802.rAPI2f2h013773@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 18:02:43 -0000 TB --- 2013-11-25 16:56:11 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-25 16:56:11 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 16:56:11 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-11-25 16:56:12 - cleaning the object tree TB --- 2013-11-25 16:57:14 - /usr/local/bin/svn stat /src TB --- 2013-11-25 16:57:18 - At svn revision 258542 TB --- 2013-11-25 16:57:19 - building world TB --- 2013-11-25 16:57:19 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 16:57:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 16:57:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 16:57:19 - SRCCONF=/dev/null TB --- 2013-11-25 16:57:19 - TARGET=sparc64 TB --- 2013-11-25 16:57:19 - TARGET_ARCH=sparc64 TB --- 2013-11-25 16:57:19 - TZ=UTC TB --- 2013-11-25 16:57:19 - __MAKE_CONF=/dev/null TB --- 2013-11-25 16:57:19 - cd /src TB --- 2013-11-25 16:57:19 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 25 16:57:26 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-25 18:02:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 18:02:41 - ERROR: failed to build world TB --- 2013-11-25 18:02:41 - 3047.90 user 557.99 system 3989.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 19:05:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A11D4554; Mon, 25 Nov 2013 19:05:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 112E92146; Mon, 25 Nov 2013 19:05:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAPJ5Ywu092830; Mon, 25 Nov 2013 14:05:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAPJ5XgI092829; Mon, 25 Nov 2013 19:05:33 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 19:05:33 GMT Message-Id: <201311251905.rAPJ5XgI092829@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 19:05:35 -0000 TB --- 2013-11-25 16:29:52 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-25 16:29:52 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 16:29:52 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-11-25 16:29:52 - cleaning the object tree TB --- 2013-11-25 16:31:22 - /usr/local/bin/svn stat /src TB --- 2013-11-25 16:31:28 - At svn revision 258542 TB --- 2013-11-25 16:31:29 - building world TB --- 2013-11-25 16:31:29 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 16:31:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 16:31:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 16:31:29 - SRCCONF=/dev/null TB --- 2013-11-25 16:31:29 - TARGET=powerpc TB --- 2013-11-25 16:31:29 - TARGET_ARCH=powerpc64 TB --- 2013-11-25 16:31:29 - TZ=UTC TB --- 2013-11-25 16:31:29 - __MAKE_CONF=/dev/null TB --- 2013-11-25 16:31:29 - cd /src TB --- 2013-11-25 16:31:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 25 16:31:37 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1296: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1297: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1298: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1301: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1302: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c: In function 'parsefsinfo': /src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-nfs.c:1496: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop. bmake[4]: stopped in /src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/tcpdump *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-25 19:05:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 19:05:33 - ERROR: failed to build world TB --- 2013-11-25 19:05:33 - 8029.74 user 914.82 system 9341.66 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 19:25:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 984C0490; Mon, 25 Nov 2013 19:25:05 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1637522AE; Mon, 25 Nov 2013 19:25:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAPJOws0056698; Mon, 25 Nov 2013 21:24:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAPJOws0056698 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAPJOwwf056697; Mon, 25 Nov 2013 21:24:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Nov 2013 21:24:58 +0200 From: Konstantin Belousov To: Dimitry Andric Subject: Re: Buildworld broken with WITHOUT_DYNAMICROOT=yes in src.conf Message-ID: <20131125192458.GQ59496@kib.kiev.ua> References: <201311250111.rAP1BuI0009520@pozo.com> <20131125011949.GC1627@glenbarber.us> <20131125012302.GD1627@glenbarber.us> <201311250129.rAP1TJfQ033437@pozo.com> <20131125041724.GA2310@glenbarber.us> <201311250441.rAP4freb002330@pozo.com> <20131125044854.GC2310@glenbarber.us> <20131125075110.GL59496@kib.kiev.ua> <063D36C2-E1D0-449E-A662-0CCA5A9B887E@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="31nJFIgEO4c66g5r" Content-Disposition: inline In-Reply-To: <063D36C2-E1D0-449E-A662-0CCA5A9B887E@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Glen Barber , freebsd-current , peter@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 19:25:05 -0000 --31nJFIgEO4c66g5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2013 at 01:36:15PM +0100, Dimitry Andric wrote: > On 25 Nov 2013, at 08:51, Konstantin Belousov wrote: > > On Sun, Nov 24, 2013 at 11:48:54PM -0500, Glen Barber wrote: > ... > >> Index: Makefile > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- Makefile (revision 258538) > >> +++ Makefile (working copy) > >> @@ -42,6 +42,9 @@ > >>=20 > >> DPADD=3D ${LIBTERMCAP} ${LIBCRYPT} > >> LDADD=3D -ltermcap -lcrypt > >> +.if ${MK_ICONV} !=3D "no" && ${MK_DYNAMICROOT} !=3D "yes" > >> +LDADD+=3D -lc_nonshared > >> +.endif > >>=20 > >> LINKS=3D ${BINDIR}/csh ${BINDIR}/tcsh > >>=20 > >=20 > > No, this is wrong. As is, static linking is broken and the hack above > > only fixes one case. > >=20 > > What is needed is inclusion of the lib/libc_nonshared object files into > > static libc.a. I am not sure how to express this in our build system. >=20 > Hi Kostik, >=20 > You can add the additional object files to ${STATICOBJS}. These will > only be built for the static and profiled libraries. See for example > gnu/lib/libgcc/Makefile or lib/libc++/Makefile. >=20 The patch we ended up with is available at http://people.freebsd.org/~kib/misc/iconv_static_linking.1.patch --31nJFIgEO4c66g5r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSk6QJAAoJEJDCuSvBvK1BU5UP/173BRM9yTAtdAN49eA7ZpfC /TZR7GhGhUnlavmB0JZ/j4OL+aG+0+8keoqj/pRkx1MYI2OFQKeLV+MrFjnjNPuJ CrsZhz/4SD1JSt/PgMUpq8VDz2xucMO0Yhm/jtzLEpt2NpHYkaOBHofNAnPLAgSS uZkitXtyS1/wK1uxtvt9JqOXmvb2xO1cAKzCyCU3+MQm9+HhsIOUAEcEXCuf+FdO 7R0KdpveQ9KHJMtiNF2Y5gF4nENEfGhYQ03GR1FaohbzPZsvzu78MnosgM7XySs9 R+cb2kj0M7pDRj+v7fHdt2d3qSaYUtwPty8yVihzcjI24VRh/m0SmFAYaGq403Sw Q351w8vjT1HAMI19m9S8siwzdRARGfMegv4IfT96o5qH6XWORgcWHO0dtoe5s81n YU/8YlOxff4kyFRg4k9QiqkOLCvoPJVEqgR55bBy9T2JigX+VmAwLgsdgNzzxAuk FT0aMHoi72/YlNbF0MlW5eBfuUyUyrp3GUNn4YtaPqlIAyZ27dNvAZGUwukk2EtO c4+Ruxr8iMuUM9vxbJFDleftkQkH3I0eW8E/AIPV8XXrBWY3NmEQaQhXkBG96NRG toEdjFp3+yLXNcFSXZoNioJ8/MCbY25c/trznjNYonM5PRTmwKymTuN4255ZWUmC r0rcyZC7L5UIMpFEv4Xr =2FUy -----END PGP SIGNATURE----- --31nJFIgEO4c66g5r-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 25 21:58:22 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBE8A3EE; Mon, 25 Nov 2013 21:58:22 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B59682CA2; Mon, 25 Nov 2013 21:58:22 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Vl4Ad-0006fL-V7; Mon, 25 Nov 2013 21:58:21 +0000 Subject: Re: Patch: Add option to fmt to ignore email reply lines Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/signed; boundary="Apple-Mail=_01428EC3-4302-44E9-B0D4-5A48571181F2"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark Robert Vaughan Murray In-Reply-To: <20131125125430.GC67451@ul9n> Date: Mon, 25 Nov 2013 21:58:12 +0000 Message-Id: References: <20131125125430.GC67451@ul9n> To: Anthony Perkins X-Mailer: Apple Mail (2.1822) X-SA-Score: -1.0 Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 21:58:23 -0000 --Apple-Mail=_01428EC3-4302-44E9-B0D4-5A48571181F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 25 Nov 2013, at 12:54, Anthony Perkins wrote: > I've added an option to 'fmt' to ignore lines beginning with the > greater-than symbol, so that whole email replies can be piped through > fmt (e.g. via vi from mutt) without needing to repeat the command > for each of my paragraphs. >=20 > This is my first real patch, so I would appreciate any feedback. I=92ve not tried your patch, but I like the idea. When using NMH, I like to use a paragraph reformatter before sending, and fmt(1) was terrible because (as you note) it can=92t handle the reply quoting. You may want to extend your idea a bit and do what par = (ports/textproc/par) does. This is a paragraph reformatter that takes the quoting into = account, replacing it after the paragraph wrapping. M --=20 Mark R V Murray --Apple-Mail=_01428EC3-4302-44E9-B0D4-5A48571181F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUpPH+t58vKOKE6LNAQp0HAQAlWPQUlmQ3KvnVWje39TxztLyOMQTHIzN fb/pcOlG6VnRCm+NmeLpBTdGEpmKhGH8KE1CyWOxDgTS6G1Olk4pdZaZDUoOJ4sK yvyqWvNV71eM8mnm5QXlndlAj53CdAZrMXvhqrASw4hzziUasCi6rpAv8RhJN7ry OrV5aeUKVPg= =XFgz -----END PGP SIGNATURE----- --Apple-Mail=_01428EC3-4302-44E9-B0D4-5A48571181F2-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 06:32:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6392ABE; Tue, 26 Nov 2013 06:32:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F1E32556; Tue, 26 Nov 2013 06:32:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAQ6WN4s031689; Tue, 26 Nov 2013 01:32:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAQ6WN3N031685; Tue, 26 Nov 2013 06:32:23 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 26 Nov 2013 06:32:23 GMT Message-Id: <201311260632.rAQ6WN3N031685@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 06:32:25 -0000 TB --- 2013-11-26 03:25:36 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-26 03:25:36 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-26 03:25:36 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-26 03:25:36 - cleaning the object tree TB --- 2013-11-26 03:27:25 - /usr/local/bin/svn stat /src TB --- 2013-11-26 03:27:43 - At svn revision 258581 TB --- 2013-11-26 03:27:44 - building world TB --- 2013-11-26 03:27:44 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 03:27:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 03:27:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 03:27:44 - SRCCONF=/dev/null TB --- 2013-11-26 03:27:44 - TARGET=powerpc TB --- 2013-11-26 03:27:44 - TARGET_ARCH=powerpc TB --- 2013-11-26 03:27:44 - TZ=UTC TB --- 2013-11-26 03:27:44 - __MAKE_CONF=/dev/null TB --- 2013-11-26 03:27:44 - cd /src TB --- 2013-11-26 03:27:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 26 03:27:51 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Nov 26 06:04:38 UTC 2013 TB --- 2013-11-26 06:04:38 - generating LINT kernel config TB --- 2013-11-26 06:04:38 - cd /src/sys/powerpc/conf TB --- 2013-11-26 06:04:38 - /usr/bin/make -B LINT TB --- 2013-11-26 06:04:38 - cd /src/sys/powerpc/conf TB --- 2013-11-26 06:04:38 - /usr/sbin/config -m LINT TB --- 2013-11-26 06:04:38 - building LINT kernel TB --- 2013-11-26 06:04:38 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 06:04:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 06:04:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 06:04:38 - SRCCONF=/dev/null TB --- 2013-11-26 06:04:38 - TARGET=powerpc TB --- 2013-11-26 06:04:38 - TARGET_ARCH=powerpc TB --- 2013-11-26 06:04:38 - TZ=UTC TB --- 2013-11-26 06:04:38 - __MAKE_CONF=/dev/null TB --- 2013-11-26 06:04:38 - cd /src TB --- 2013-11-26 06:04:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 26 06:04:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Nov 26 06:23:48 UTC 2013 TB --- 2013-11-26 06:23:48 - cd /src/sys/powerpc/conf TB --- 2013-11-26 06:23:48 - /usr/sbin/config -m GENERIC TB --- 2013-11-26 06:23:48 - building GENERIC kernel TB --- 2013-11-26 06:23:48 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 06:23:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 06:23:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 06:23:48 - SRCCONF=/dev/null TB --- 2013-11-26 06:23:48 - TARGET=powerpc TB --- 2013-11-26 06:23:48 - TARGET_ARCH=powerpc TB --- 2013-11-26 06:23:48 - TZ=UTC TB --- 2013-11-26 06:23:48 - __MAKE_CONF=/dev/null TB --- 2013-11-26 06:23:48 - cd /src TB --- 2013-11-26 06:23:48 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Nov 26 06:23:48 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:189: warning: redundant redeclaration of 'nfscl_attrcache_flush_done_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:76: warning: previous declaration of 'nfscl_attrcache_flush_done_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:190: warning: redundant redeclaration of 'nfscl_attrcache_get_hit_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:77: warning: previous declaration of 'nfscl_attrcache_get_hit_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:191: warning: redundant redeclaration of 'nfscl_attrcache_get_miss_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:78: warning: previous declaration of 'nfscl_attrcache_get_miss_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:192: warning: redundant redeclaration of 'nfscl_attrcache_load_done_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:79: warning: previous declaration of 'nfscl_attrcache_load_done_id' was here *** Error code 1 Stop. bmake[4]: stopped in /src/sys/modules/dtrace/dtnfscl *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/dtrace *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/GENERIC *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-26 06:32:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-26 06:32:23 - ERROR: failed to build GENERIC kernel TB --- 2013-11-26 06:32:23 - 9482.23 user 1225.03 system 11207.27 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 07:17:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B764F2C; Tue, 26 Nov 2013 07:17:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D88B8272A; Tue, 26 Nov 2013 07:17:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAQ7H2xx022735; Tue, 26 Nov 2013 02:17:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAQ7H2g2022734; Tue, 26 Nov 2013 07:17:02 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 26 Nov 2013 07:17:02 GMT Message-Id: <201311260717.rAQ7H2g2022734@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 07:17:04 -0000 TB --- 2013-11-26 04:03:51 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-26 04:03:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-26 04:03:51 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-11-26 04:03:51 - cleaning the object tree TB --- 2013-11-26 04:05:22 - /usr/local/bin/svn stat /src TB --- 2013-11-26 04:05:27 - At svn revision 258581 TB --- 2013-11-26 04:05:28 - building world TB --- 2013-11-26 04:05:28 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 04:05:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 04:05:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 04:05:28 - SRCCONF=/dev/null TB --- 2013-11-26 04:05:28 - TARGET=powerpc TB --- 2013-11-26 04:05:28 - TARGET_ARCH=powerpc64 TB --- 2013-11-26 04:05:28 - TZ=UTC TB --- 2013-11-26 04:05:28 - __MAKE_CONF=/dev/null TB --- 2013-11-26 04:05:28 - cd /src TB --- 2013-11-26 04:05:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 26 04:05:35 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Nov 26 07:07:21 UTC 2013 TB --- 2013-11-26 07:07:21 - generating LINT kernel config TB --- 2013-11-26 07:07:21 - cd /src/sys/powerpc/conf TB --- 2013-11-26 07:07:21 - /usr/bin/make -B LINT TB --- 2013-11-26 07:07:21 - cd /src/sys/powerpc/conf TB --- 2013-11-26 07:07:21 - /usr/sbin/config -m LINT TB --- 2013-11-26 07:07:21 - skipping LINT kernel TB --- 2013-11-26 07:07:21 - cd /src/sys/powerpc/conf TB --- 2013-11-26 07:07:21 - /usr/sbin/config -m GENERIC TB --- 2013-11-26 07:07:21 - skipping GENERIC kernel TB --- 2013-11-26 07:07:21 - cd /src/sys/powerpc/conf TB --- 2013-11-26 07:07:21 - /usr/sbin/config -m GENERIC64 TB --- 2013-11-26 07:07:21 - building GENERIC64 kernel TB --- 2013-11-26 07:07:21 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 07:07:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 07:07:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 07:07:21 - SRCCONF=/dev/null TB --- 2013-11-26 07:07:21 - TARGET=powerpc TB --- 2013-11-26 07:07:21 - TARGET_ARCH=powerpc64 TB --- 2013-11-26 07:07:21 - TZ=UTC TB --- 2013-11-26 07:07:21 - __MAKE_CONF=/dev/null TB --- 2013-11-26 07:07:21 - cd /src TB --- 2013-11-26 07:07:21 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Tue Nov 26 07:07:21 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:189: warning: redundant redeclaration of 'nfscl_attrcache_flush_done_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:76: warning: previous declaration of 'nfscl_attrcache_flush_done_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:190: warning: redundant redeclaration of 'nfscl_attrcache_get_hit_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:77: warning: previous declaration of 'nfscl_attrcache_get_hit_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:191: warning: redundant redeclaration of 'nfscl_attrcache_get_miss_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:78: warning: previous declaration of 'nfscl_attrcache_get_miss_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:192: warning: redundant redeclaration of 'nfscl_attrcache_load_done_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:79: warning: previous declaration of 'nfscl_attrcache_load_done_id' was here *** Error code 1 Stop. bmake[4]: stopped in /src/sys/modules/dtrace/dtnfscl *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/dtrace *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc64/src/sys/GENERIC64 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-26 07:17:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-26 07:17:02 - ERROR: failed to build GENERIC64 kernel TB --- 2013-11-26 07:17:02 - 10092.02 user 1298.48 system 11591.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 08:10:04 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D82672E3; Tue, 26 Nov 2013 08:10:04 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7037E29C4; Tue, 26 Nov 2013 08:10:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAQ89rKX010956; Tue, 26 Nov 2013 10:09:53 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAQ89rKX010956 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAQ89rcv010955; Tue, 26 Nov 2013 10:09:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 26 Nov 2013 10:09:53 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: gdb has outdated knowledge of signal trampolines Message-ID: <20131126080953.GS59496@kib.kiev.ua> References: <529322E1.1060105@FreeBSD.org> <20131125173527.GP59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cYIzBPdBhuBoQ5I4" Content-Disposition: inline In-Reply-To: <20131125173527.GP59496@kib.kiev.ua> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current , Luca Pizzamiglio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 08:10:05 -0000 --cYIzBPdBhuBoQ5I4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2013 at 07:35:27PM +0200, Konstantin Belousov wrote: > Could you update your gdb patch to use the KERN_PROC_SIGTRAMP from > the patch below ? If this works out, I will add initialization of > sv_szsigcode for ABIs which do not use shared page. Below is the complete patch. With it applied, I get (gdb) bt #0 sighandler (signo=3D1, info=3D0x7fffffffd2b0, context=3DUnhandled dwarf= expression opcode 0xf3 ) at siginfo.c:34 #1 #2 0x000000080088849a in sigsuspend () from /lib/libc.so.7 #3 0x000000000040093a in main (argc=3DUnhandled dwarf expression opcode 0x= f3 ) at siginfo.c:54 diff --git a/contrib/gdb/gdb/amd64fbsd-nat.c b/contrib/gdb/gdb/amd64fbsd-na= t.c index f083734..dacd4a3 100644 --- a/contrib/gdb/gdb/amd64fbsd-nat.c +++ b/contrib/gdb/gdb/amd64fbsd-nat.c @@ -29,6 +29,7 @@ #include #include #include +#include #include =20 #ifdef HAVE_SYS_PROCFS_H @@ -212,24 +213,23 @@ Please report this to .", =20 SC_RBP_OFFSET =3D offset; =20 - /* FreeBSD provides a kern.ps_strings sysctl that we can use to + /* FreeBSD provides a kern.proc.sigtramp sysctl that we can use to locate the sigtramp. That way we can still recognize a sigtramp - if its location is changed in a new kernel. Of course this is - still based on the assumption that the sigtramp is placed - directly under the location where the program arguments and - environment can be found. */ + if its location is changed in a new kernel. */ { - int mib[2]; - long ps_strings; + int mib[4]; + struct kinfo_sigtramp kst; size_t len; =20 mib[0] =3D CTL_KERN; - mib[1] =3D KERN_PS_STRINGS; - len =3D sizeof (ps_strings); - if (sysctl (mib, 2, &ps_strings, &len, NULL, 0) =3D=3D 0) + mib[1] =3D KERN_PROC; + mib[2] =3D KERN_PROC_SIGTRAMP; + mib[3] =3D getpid(); + len =3D sizeof (kst); + if (sysctl (mib, sizeof(mib) / sizeof(mib[0]), &kst, &len, NULL, 0) = =3D=3D 0) { - amd64fbsd_sigtramp_start_addr =3D ps_strings - 32; - amd64fbsd_sigtramp_end_addr =3D ps_strings; + amd64fbsd_sigtramp_start_addr =3D kst.ksigtramp_start; + amd64fbsd_sigtramp_end_addr =3D kst.ksigtramp_end; } } } diff --git a/sys/amd64/include/pcb.h b/sys/amd64/include/pcb.h index c106edc..80aff86 100644 --- a/sys/amd64/include/pcb.h +++ b/sys/amd64/include/pcb.h @@ -43,6 +43,7 @@ #include #include =20 +#ifdef __amd64__ struct pcb { register_t pcb_r15; register_t pcb_r14; @@ -105,6 +106,7 @@ struct pcb { =20 uint64_t pcb_pad[3]; }; +#endif =20 #ifdef _KERNEL struct trapframe; diff --git a/sys/amd64/include/segments.h b/sys/amd64/include/segments.h index d9f4280..6bcadc7 100644 --- a/sys/amd64/include/segments.h +++ b/sys/amd64/include/segments.h @@ -82,8 +82,8 @@ struct soft_segment_descriptor { * region descriptors, used to load gdt/idt tables before segments yet exi= st. */ struct region_descriptor { - unsigned long rd_limit:16; /* segment extent */ - unsigned long rd_base:64 __packed; /* base address */ + uint64_t rd_limit:16; /* segment extent */ + uint64_t rd_base:64 __packed; /* base address */ } __packed; =20 #ifdef _KERNEL diff --git a/sys/compat/freebsd32/freebsd32.h b/sys/compat/freebsd32/freebs= d32.h index 8376e95..94f886e 100644 --- a/sys/compat/freebsd32/freebsd32.h +++ b/sys/compat/freebsd32/freebsd32.h @@ -362,6 +362,12 @@ struct kinfo_proc32 { int ki_tdflags; }; =20 +struct kinfo_sigtramp32 { + uint32_t ksigtramp_start; + uint32_t ksigtramp_end; + uint32_t ksigtramp_spare[4]; +}; + struct kld32_file_stat_1 { int version; /* set to sizeof(struct kld_file_stat_1) */ char name[MAXPATHLEN]; diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c index 9968e76..2e6bc32 100644 --- a/sys/kern/kern_proc.c +++ b/sys/kern/kern_proc.c @@ -2632,6 +2632,60 @@ errout: return (error); } =20 +static int +sysctl_kern_proc_sigtramp(SYSCTL_HANDLER_ARGS) +{ + int *name =3D (int *)arg1; + u_int namelen =3D arg2; + struct proc *p; + struct kinfo_sigtramp kst; + const struct sysentvec *sv; + int error; +#ifdef COMPAT_FREEBSD32 + struct kinfo_sigtramp32 kst32; +#endif + + if (namelen !=3D 1) + return (EINVAL); + + error =3D pget((pid_t)name[0], PGET_CANDEBUG, &p); + if (error !=3D 0) + return (error); + sv =3D p->p_sysent; +#ifdef COMPAT_FREEBSD32 + if ((req->flags & SCTL_MASK32) !=3D 0) { + bzero(&kst32, sizeof(kst32)); + if (SV_PROC_FLAG(p, SV_ILP32)) { + if (sv->sv_sigcode_base !=3D 0) { + kst32.ksigtramp_start =3D sv->sv_sigcode_base; + kst32.ksigtramp_end =3D sv->sv_sigcode_base + + *sv->sv_szsigcode; + } else { + kst32.ksigtramp_start =3D sv->sv_psstrings - + *sv->sv_szsigcode; + kst32.ksigtramp_end =3D sv->sv_psstrings; + } + } + PROC_UNLOCK(p); + error =3D SYSCTL_OUT(req, &kst32, sizeof(kst32)); + return (error); + } +#endif + bzero(&kst, sizeof(kst)); + if (sv->sv_sigcode_base !=3D 0) { + kst.ksigtramp_start =3D (char *)sv->sv_sigcode_base; + kst.ksigtramp_end =3D (char *)sv->sv_sigcode_base + + *sv->sv_szsigcode; + } else { + kst.ksigtramp_start =3D (char *)sv->sv_psstrings - + *sv->sv_szsigcode; + kst.ksigtramp_end =3D (char *)sv->sv_psstrings; + } + PROC_UNLOCK(p); + error =3D SYSCTL_OUT(req, &kst, sizeof(kst)); + return (error); +} + SYSCTL_NODE(_kern, KERN_PROC, proc, CTLFLAG_RD, 0, "Process table"); =20 SYSCTL_PROC(_kern_proc, KERN_PROC_ALL, all, CTLFLAG_RD|CTLTYPE_STRUCT| @@ -2740,3 +2794,7 @@ static SYSCTL_NODE(_kern_proc, KERN_PROC_UMASK, umask= , CTLFLAG_RD | static SYSCTL_NODE(_kern_proc, KERN_PROC_OSREL, osrel, CTLFLAG_RW | CTLFLAG_ANYBODY | CTLFLAG_MPSAFE, sysctl_kern_proc_osrel, "Process binary osreldate"); + +static SYSCTL_NODE(_kern_proc, KERN_PROC_SIGTRAMP, sigtramp, CTLFLAG_RD | + CTLFLAG_MPSAFE, sysctl_kern_proc_sigtramp, + "Process signal trampoline location"); diff --git a/sys/sys/sysctl.h b/sys/sys/sysctl.h index 64292ba..8e70a12 100644 --- a/sys/sys/sysctl.h +++ b/sys/sys/sysctl.h @@ -530,6 +530,7 @@ SYSCTL_ALLOWED_TYPES(UINT64, uint64_t *a; unsigned long= long *b; ); #define KERN_PROC_PS_STRINGS 38 /* get ps_strings location */ #define KERN_PROC_UMASK 39 /* process umask */ #define KERN_PROC_OSREL 40 /* osreldate for process binary */ +#define KERN_PROC_SIGTRAMP 41 /* signal trampoline location */ =20 /* * KERN_IPC identifiers diff --git a/sys/sys/user.h b/sys/sys/user.h index d2e2b6e..e926fe8 100644 --- a/sys/sys/user.h +++ b/sys/sys/user.h @@ -498,6 +498,12 @@ struct kinfo_kstack { int _kkst_ispare[16]; /* Space for more stuff. */ }; =20 +struct kinfo_sigtramp { + void *ksigtramp_start; + void *ksigtramp_end; + void *ksigtramp_spare[4]; +}; + #ifdef _KERNEL /* Flags for kern_proc_out function. */ #define KERN_PROC_NOTHREADS 0x1 --cYIzBPdBhuBoQ5I4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlFdQAAoJEJDCuSvBvK1BPr8QAIf8qsyGYHcZkubOChm6j0ZR EXGKnb3/mM+RE6g0lo0NSux2Buffo7kG/Rt61l06Lyy15NZY0yi1AJ4rWJixhcA2 b3ecizPRZiNN3BZ7k8nk/bS7zlvrQkhzqNy0GJ9Hzmx/Ex/3I2mdmOlUwjGyzzV1 qMpMIj/H3/UDu34iwTyqOqQ3Pol0vVMpZR5Ye0H9NywpAZJH/7yecAD7SL+UQ0Lg exwTWVZ81XjUNKDyFq4xaQEV/hm78OsHVgGLHMkbDKlF1W/sDdTQEJik8OOydQM8 gVbE86eAsTHKHDDwHIIPETlwlNdTkPUxqu3JN2xwyoBwcqAztHJV4JNDIfO7qk0d eI/dl2w2i2JhQPAvcNVTW0oQW39POCrwiCp/o1/6faN3aepZCTG+UoZs+pjdZe6l YvJtiBEV/L5vp19XovGY7i5LAEKm7K7LIP1RkaKJ/nSNwhLbJJ26t4nkl93Tm7ra weTmpAg6MNcA5VIWnLb5Wk2/5RBkrMsW9IB5dPlBysWSqGpABgn85ZnUioz2Oaqu f009cI9SkjeSguFaqXzt9+x6oPgwumFg8riR3zAFVk5mQATv7BAaYW257T93gVi/ Vxh81gp7ovh4epfBVxI1hy1/5+C/f4CXD/q7inweE/J/L1W99SkkPDbgPLNhoyme Gz5KXABTn50IMs7hjNC1 =dPPG -----END PGP SIGNATURE----- --cYIzBPdBhuBoQ5I4-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 12:26:22 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06B8735F; Tue, 26 Nov 2013 12:26:22 +0000 (UTC) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0083.outbound.protection.outlook.com [213.199.154.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 93490298D; Tue, 26 Nov 2013 12:26:21 +0000 (UTC) Received: from ul9n (199.102.77.238) by DB3PR06MB172.eurprd06.prod.outlook.com (10.141.1.151) with Microsoft SMTP Server (TLS) id 15.0.800.7; Tue, 26 Nov 2013 12:11:02 +0000 Date: Tue, 26 Nov 2013 12:10:51 +0000 From: Anthony Perkins To: Mark Robert Vaughan Murray Subject: Re: Patch: Add option to fmt to ignore email reply lines Message-ID: <20131126121050.GC73645@ul9n> References: <20131125125430.GC67451@ul9n> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Originating-IP: [199.102.77.238] X-ClientProxiedBy: BL2PR08CA005.namprd08.prod.outlook.com (10.255.226.15) To DB3PR06MB172.eurprd06.prod.outlook.com (10.141.1.151) X-Forefront-PRVS: 00429279BA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(66654002)(24454002)(51704005)(189002)(199002)(65816001)(47976001)(49866001)(50986001)(81542001)(47736001)(4396001)(85306002)(74706001)(51856001)(46102001)(66066001)(50466002)(53806001)(80022001)(74876001)(54356001)(42186004)(59766001)(46406003)(87976001)(83072001)(77982001)(83322001)(76482001)(54316002)(56776001)(81686001)(47446002)(74662001)(31966008)(74502001)(47776003)(76796001)(81342001)(83506001)(76786001)(81816001)(63696002)(69226001)(74366001)(77096001)(56816003)(23726002)(80976001)(79102001)(87266001)(33716001)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR06MB172; H:ul9n; CLIP:199.102.77.238; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: acperkins.com Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 12:26:22 -0000 On Mon, Nov 25, 2013 at 09:58:12PM +0000, Mark Robert Vaughan Murray wrote: > > You may want to extend your idea a bit and do what par (ports/textproc/par) > does. This is a paragraph reformatter that takes the quoting into account, > replacing it after the paragraph wrapping. I did consider doing this but decided against it on the basis that the incoming mail from the previous sender was unpredictable. If it included, for example, a list of a few short sentences or bullet points these would all be combined into one long paragraph in the reply. If others also feel this would be desirable I will look at implementing it with an updated patch. Many thanks, Anthony From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 17:47:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87F547D5 for ; Tue, 26 Nov 2013 17:47:28 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 153E12059 for ; Tue, 26 Nov 2013 17:47:27 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id q8so4807455lbi.30 for ; Tue, 26 Nov 2013 09:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=q57hRNQ+Pxeu4IpKaIr/IIKiU3f2IvGqs1GL/Cg2PJ8=; b=zIJx1KEYIrrAgY3qVcTjdGMZHLkMSjh1atVbBIByNYAzQnVuHA1vMfAUZonDlwG/8W UHZ8apd1ppLduBtOIeNE3lcqiEdeqPuydnbPARk7O3zJlP/kYGlZH0K+U/IiwoOSivqO 9ClXTvJjOFJqtQC8L0I7pj4l9nGdeJi6dSsXA8r9W7TpGaYDeRh5nR4fsW+UGAblH03P qtJJqm5dxSV3MZSxJ2Wqh89narsS6aF3YJscVQYx10VR6034ExGx0lnFag+0ckqQ6M6P McyKycx89a3CkmMFd323jiAmJK7ToGNe5I+YWIumuXiB1bwwgmHJfzshjtiZWgYcHBLc pXjw== X-Received: by 10.112.133.104 with SMTP id pb8mr25975242lbb.22.1385488046137; Tue, 26 Nov 2013 09:47:26 -0800 (PST) Received: from scorpion.kiev.ua ([78.111.187.138]) by mx.google.com with ESMTPSA id go4sm42626995lbc.3.2013.11.26.09.47.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 09:47:25 -0800 (PST) Message-ID: <5294DEAA.5070308@gmail.com> Date: Tue, 26 Nov 2013 19:47:22 +0200 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: lang/gcc not build Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 17:47:28 -0000 #portmaster lang/gcc [...] cd /usr/ports/lang/gcc/work/gcc-4.6.4 ; contrib/gcc_update --touch configure: loading site script /usr/ports/Templates/config.site checking build system type... x86_64-portbld-freebsd10.0 checking host system type... x86_64-portbld-freebsd10.0 checking target system type... x86_64-portbld-freebsd10.0 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... (cached) /usr/bin/sed checking for gawk... (cached) /usr/bin/awk checking for gcc... gcc46 checking for C compiler default output file name... configure: error: in `/usr/ports/lang/gcc/work/build': configure: error: C compiler cannot create executables See `config.log' for more details. ===> Script "../gcc-4.6.4/configure" failed unexpectedly. Please report the problem to gerald@FreeBSD.org [maintainer] and attach the "/usr/ports/lang/gcc/work/build/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 ############################################# /etc/make.conf .if ${.CURDIR:N*/ports/lang/gcc*} == "" CFLAGS= -O2 -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Wformat CPPFLAGS+= -D_FORTIFY_SOURCE=2 USE_GCC=4.6 .endif #pkg info -ix gcc gcc-4.6.3 gcc-ecj-4.5 gccmakedep-1.0.2_1 -- Alexander From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 18:44:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DDD3AAD; Tue, 26 Nov 2013 18:44:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D7B2523FB; Tue, 26 Nov 2013 18:44:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAQIiaQv061843; Tue, 26 Nov 2013 13:44:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAQIiapf061839; Tue, 26 Nov 2013 18:44:36 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 26 Nov 2013 18:44:36 GMT Message-Id: <201311261844.rAQIiapf061839@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 18:44:44 -0000 TB --- 2013-11-26 15:37:19 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-26 15:37:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-26 15:37:19 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-26 15:37:19 - cleaning the object tree TB --- 2013-11-26 15:39:04 - /usr/local/bin/svn stat /src TB --- 2013-11-26 15:39:10 - At svn revision 258615 TB --- 2013-11-26 15:39:11 - building world TB --- 2013-11-26 15:39:11 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 15:39:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 15:39:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 15:39:11 - SRCCONF=/dev/null TB --- 2013-11-26 15:39:11 - TARGET=powerpc TB --- 2013-11-26 15:39:11 - TARGET_ARCH=powerpc TB --- 2013-11-26 15:39:11 - TZ=UTC TB --- 2013-11-26 15:39:11 - __MAKE_CONF=/dev/null TB --- 2013-11-26 15:39:11 - cd /src TB --- 2013-11-26 15:39:11 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 26 15:39:19 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Nov 26 18:16:52 UTC 2013 TB --- 2013-11-26 18:16:52 - generating LINT kernel config TB --- 2013-11-26 18:16:52 - cd /src/sys/powerpc/conf TB --- 2013-11-26 18:16:52 - /usr/bin/make -B LINT TB --- 2013-11-26 18:16:52 - cd /src/sys/powerpc/conf TB --- 2013-11-26 18:16:52 - /usr/sbin/config -m LINT TB --- 2013-11-26 18:16:52 - building LINT kernel TB --- 2013-11-26 18:16:52 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 18:16:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 18:16:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 18:16:52 - SRCCONF=/dev/null TB --- 2013-11-26 18:16:52 - TARGET=powerpc TB --- 2013-11-26 18:16:52 - TARGET_ARCH=powerpc TB --- 2013-11-26 18:16:52 - TZ=UTC TB --- 2013-11-26 18:16:52 - __MAKE_CONF=/dev/null TB --- 2013-11-26 18:16:52 - cd /src TB --- 2013-11-26 18:16:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 26 18:16:52 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Nov 26 18:36:02 UTC 2013 TB --- 2013-11-26 18:36:02 - cd /src/sys/powerpc/conf TB --- 2013-11-26 18:36:02 - /usr/sbin/config -m GENERIC TB --- 2013-11-26 18:36:02 - building GENERIC kernel TB --- 2013-11-26 18:36:02 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 18:36:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 18:36:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 18:36:02 - SRCCONF=/dev/null TB --- 2013-11-26 18:36:02 - TARGET=powerpc TB --- 2013-11-26 18:36:02 - TARGET_ARCH=powerpc TB --- 2013-11-26 18:36:02 - TZ=UTC TB --- 2013-11-26 18:36:02 - __MAKE_CONF=/dev/null TB --- 2013-11-26 18:36:02 - cd /src TB --- 2013-11-26 18:36:02 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Nov 26 18:36:02 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:189: warning: redundant redeclaration of 'nfscl_attrcache_flush_done_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:76: warning: previous declaration of 'nfscl_attrcache_flush_done_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:190: warning: redundant redeclaration of 'nfscl_attrcache_get_hit_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:77: warning: previous declaration of 'nfscl_attrcache_get_hit_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:191: warning: redundant redeclaration of 'nfscl_attrcache_get_miss_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:78: warning: previous declaration of 'nfscl_attrcache_get_miss_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:192: warning: redundant redeclaration of 'nfscl_attrcache_load_done_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:79: warning: previous declaration of 'nfscl_attrcache_load_done_id' was here *** Error code 1 Stop. bmake[4]: stopped in /src/sys/modules/dtrace/dtnfscl *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/dtrace *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/GENERIC *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-26 18:44:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-26 18:44:36 - ERROR: failed to build GENERIC kernel TB --- 2013-11-26 18:44:36 - 9491.14 user 1223.68 system 11237.29 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 19:30:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6FB1430; Tue, 26 Nov 2013 19:30:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AFC9E2732; Tue, 26 Nov 2013 19:30:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAQJU6hP053605; Tue, 26 Nov 2013 14:30:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAQJU6mD053604; Tue, 26 Nov 2013 19:30:06 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 26 Nov 2013 19:30:06 GMT Message-Id: <201311261930.rAQJU6mD053604@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 19:30:08 -0000 TB --- 2013-11-26 16:16:43 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-26 16:16:43 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-26 16:16:43 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-11-26 16:16:43 - cleaning the object tree TB --- 2013-11-26 16:18:48 - /usr/local/bin/svn stat /src TB --- 2013-11-26 16:18:53 - At svn revision 258615 TB --- 2013-11-26 16:18:54 - building world TB --- 2013-11-26 16:18:54 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 16:18:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 16:18:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 16:18:54 - SRCCONF=/dev/null TB --- 2013-11-26 16:18:54 - TARGET=powerpc TB --- 2013-11-26 16:18:54 - TARGET_ARCH=powerpc64 TB --- 2013-11-26 16:18:54 - TZ=UTC TB --- 2013-11-26 16:18:54 - __MAKE_CONF=/dev/null TB --- 2013-11-26 16:18:54 - cd /src TB --- 2013-11-26 16:18:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 26 16:19:01 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Nov 26 19:20:25 UTC 2013 TB --- 2013-11-26 19:20:25 - generating LINT kernel config TB --- 2013-11-26 19:20:25 - cd /src/sys/powerpc/conf TB --- 2013-11-26 19:20:25 - /usr/bin/make -B LINT TB --- 2013-11-26 19:20:25 - cd /src/sys/powerpc/conf TB --- 2013-11-26 19:20:25 - /usr/sbin/config -m LINT TB --- 2013-11-26 19:20:25 - skipping LINT kernel TB --- 2013-11-26 19:20:25 - cd /src/sys/powerpc/conf TB --- 2013-11-26 19:20:25 - /usr/sbin/config -m GENERIC TB --- 2013-11-26 19:20:25 - skipping GENERIC kernel TB --- 2013-11-26 19:20:25 - cd /src/sys/powerpc/conf TB --- 2013-11-26 19:20:25 - /usr/sbin/config -m GENERIC64 TB --- 2013-11-26 19:20:25 - building GENERIC64 kernel TB --- 2013-11-26 19:20:25 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 19:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 19:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 19:20:25 - SRCCONF=/dev/null TB --- 2013-11-26 19:20:25 - TARGET=powerpc TB --- 2013-11-26 19:20:25 - TARGET_ARCH=powerpc64 TB --- 2013-11-26 19:20:25 - TZ=UTC TB --- 2013-11-26 19:20:25 - __MAKE_CONF=/dev/null TB --- 2013-11-26 19:20:25 - cd /src TB --- 2013-11-26 19:20:25 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Tue Nov 26 19:20:25 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:189: warning: redundant redeclaration of 'nfscl_attrcache_flush_done_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:76: warning: previous declaration of 'nfscl_attrcache_flush_done_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:190: warning: redundant redeclaration of 'nfscl_attrcache_get_hit_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:77: warning: previous declaration of 'nfscl_attrcache_get_hit_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:191: warning: redundant redeclaration of 'nfscl_attrcache_get_miss_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:78: warning: previous declaration of 'nfscl_attrcache_get_miss_id' was here /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:192: warning: redundant redeclaration of 'nfscl_attrcache_load_done_id' [-Wredundant-decls] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_kdtrace.h:79: warning: previous declaration of 'nfscl_attrcache_load_done_id' was here *** Error code 1 Stop. bmake[4]: stopped in /src/sys/modules/dtrace/dtnfscl *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/dtrace *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc64/src/sys/GENERIC64 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-26 19:30:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-26 19:30:06 - ERROR: failed to build GENERIC64 kernel TB --- 2013-11-26 19:30:06 - 10088.59 user 1288.37 system 11603.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 20:07:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CBAC1EF for ; Tue, 26 Nov 2013 20:07:22 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7149A2940 for ; Tue, 26 Nov 2013 20:07:22 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VlOuh-0007dO-Aa for freebsd-current@freebsd.org; Tue, 26 Nov 2013 12:07:15 -0800 Date: Tue, 26 Nov 2013 12:07:14 -0800 (PST) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1385496434634-5864187.post@n5.nabble.com> Subject: ZFS: sharenfs and "zdb no such file" errors MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 20:07:22 -0000 I had a previously discussed zpool related error on my susytem: (http://freebsd.1045724.n5.nabble.com/zpool-requires-re-import-on-reboot-td5861930.html#a5862468). This may be related. Now a different but equally odd error: On one of the pools with the import problem (poolname=da), I had: zfs set sharenfs="-network=192.168.2.0/24" da/data/amd64 When I start nfsd + mountd, TTY0 shows this error: bad exports list line: /mnt/data/amd64 bad exports list line: /mnt/amd64 I can only assume that I had the da zpool mounted as altroot=/mnt at some point in its history. After I zfs set sharenfs=off da/data/amd64 for debugging, the error persisted for some time then was gone when I first tried; now it persists even after a pool scrub. ZDB shows nothing odd with the "-Cl /dev/ada1p2" flag, but, zdb -d da/data/amd64 zdb: can't open 'da/data/amd64': No such file or directory I have same error for all pool-type commands. "# zdb -C da" for example. Regards ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/ZFS-sharenfs-and-zdb-no-such-file-errors-tp5864187.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 20:10:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F11A46B for ; Tue, 26 Nov 2013 20:10:37 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 6B0AF2978 for ; Tue, 26 Nov 2013 20:10:37 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 5357238CAD for ; Tue, 26 Nov 2013 20:10:30 +0000 (UTC) Message-ID: <52950031.2010108@allanjude.com> Date: Tue, 26 Nov 2013 15:10:25 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ZFS: sharenfs and "zdb no such file" errors References: <1385496434634-5864187.post@n5.nabble.com> In-Reply-To: <1385496434634-5864187.post@n5.nabble.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fnMcLCjUHOXPb9coK8Sx9bAUVr5bGXfG1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 20:10:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fnMcLCjUHOXPb9coK8Sx9bAUVr5bGXfG1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-26 15:07, Beeblebrox wrote: > I had a previously discussed zpool related error on my susytem: > (http://freebsd.1045724.n5.nabble.com/zpool-requires-re-import-on-reboo= t-td5861930.html#a5862468). > This may be related. > > Now a different but equally odd error: On one of the pools with the imp= ort > problem (poolname=3Dda), I had: > zfs set sharenfs=3D"-network=3D192.168.2.0/24" da/data/amd64 > When I start nfsd + mountd, TTY0 shows this error: > bad exports list line: /mnt/data/amd64 > bad exports list line: /mnt/amd64 > > I can only assume that I had the da zpool mounted as altroot=3D/mnt at = some > point in its history. After I=20 > zfs set sharenfs=3Doff da/data/amd64=20 > for debugging, the error persisted for some time then was gone when I f= irst > tried; now it persists even after a pool scrub. ZDB shows nothing odd w= ith > the "-Cl /dev/ada1p2" flag, but, > zdb -d da/data/amd64 > zdb: can't open 'da/data/amd64': No such file or directory > I have same error for all pool-type commands. "# zdb -C da" for example= =2E > > Regards > > > > > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/ZFS-= sharenfs-and-zdb-no-such-file-errors-tp5864187.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" NFS related config for ZFS is stored in /etc/zfs/exports and mountd just reads that in addition to the usual /etc/exports you might want to check there --=20 Allan Jude --fnMcLCjUHOXPb9coK8Sx9bAUVr5bGXfG1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSlQA0AAoJEJrBFpNRJZKf89QP/RFaz1RV9YOweoo4HM54VR2O EY4U1fVlAatR6njHF5085WZ3ok9jpat8tlWkFsWXYDunnf+1dNoBxR5GsMsv2P8p STAdHTZn2hdBYpds+HAsR0ZUkOXQgh02m1UvddRMB0H9JTcxi4PTfCTNwBEzoIu7 Efie2EifHRQ3EVCxBiIZRiQJb7l5cHGzbJjlbAYcI1IVJQsHmWiBuUltNUANGqFz fptcLD9vDZvpKqrI7MDMewrD+84cthM9+qEo7dDPmpjcNwvwge2GY3f4LKNKhZGn 9Ib/6mq1Gdq7Tdt62ADtYvvupLObT3btYX+7RviaJz32l/HBLyTolR7sYuzZIUDX Uji9hqoLP3WOoU66fMv5ZcjkUam3ZrZUtG70003b/2TJoQ8EnSjvjpEgMPSPDcsE t0+oCBe8Xzloa2UEGOFcfD3L9emN21rN7i6rsGQjhNLbn96TxE6RNsxifGYIdRQr E48NueRdWxrvcKg2XwoSqFry5jg0GKeTm1ZuTVYoJ0UdpKJYFWPOXMh+UO2ZG3ok M5LrSN1l+HG3QE6qtLy0iPqT1rQcmUeyqvTxhAAfrB/XjH/oMwhUeTwoomOJ4rNN Jm7vjKE9zRPn6uzQ9uMgMdCPeQSdeNXqrXnM8+Aljp4cPXTfzzd/FYnIE6ZR/31p frSUSkBPZI4kNWDHPVQI =0suX -----END PGP SIGNATURE----- --fnMcLCjUHOXPb9coK8Sx9bAUVr5bGXfG1-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 20:17:40 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81F05721; Tue, 26 Nov 2013 20:17:40 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 49DA22A06; Tue, 26 Nov 2013 20:17:40 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VlP4h-0009JQ-7U; Tue, 26 Nov 2013 20:17:38 +0000 Subject: Re: Patch: Add option to fmt to ignore email reply lines Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CF5860DF-0A89-48FE-98FA-E4BDAD87EBC1"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark Robert Vaughan Murray In-Reply-To: <20131126121050.GC73645@ul9n> Date: Tue, 26 Nov 2013 20:17:28 +0000 Message-Id: References: <20131125125430.GC67451@ul9n> <20131126121050.GC73645@ul9n> To: Anthony Perkins X-Mailer: Apple Mail (2.1822) X-SA-Score: -1.0 Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 20:17:40 -0000 --Apple-Mail=_CF5860DF-0A89-48FE-98FA-E4BDAD87EBC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Nov 2013, at 12:10, Anthony Perkins wrote: > On Mon, Nov 25, 2013 at 09:58:12PM +0000, Mark Robert Vaughan Murray > wrote: >>=20 >> You may want to extend your idea a bit and do what par = (ports/textproc/par) >> does. This is a paragraph reformatter that takes the quoting into = account, >> replacing it after the paragraph wrapping. >=20 > I did consider doing this but decided against it on the basis that > the incoming mail from the previous sender was unpredictable. If > it included, for example, a list of a few short sentences or bullet > points these would all be combined into one long paragraph in the > reply. Not true. In fact par is rather good at preserving changing indent = levels. Its not perfect, but its darn good. > If others also feel this would be desirable I will look at = implementing > it with an updated patch. Yes please! M --=20 Mark R V Murray --Apple-Mail=_CF5860DF-0A89-48FE-98FA-E4BDAD87EBC1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUpUB3d58vKOKE6LNAQrpQAP/SejxDnuYx6hYSFPC+nQXo2CX8vU/Xq5I Q97QNdgAYncnItjXLaHF8L5Lcij9dl1Kyt/8o/TSpG6W/sIYgcY0hadqQgHd4pDV MXJyHJSX4J3XdbbnCysh1vHbMlxHUYF18V48UuvNpqJpFhQmpWso7+zP5msk/GqR ZDAzXAN/Aek= =jLeQ -----END PGP SIGNATURE----- --Apple-Mail=_CF5860DF-0A89-48FE-98FA-E4BDAD87EBC1-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 26 20:34:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64216F5E for ; Tue, 26 Nov 2013 20:34:24 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 48AD92B69 for ; Tue, 26 Nov 2013 20:34:24 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VlPKx-0000cC-Hm for freebsd-current@freebsd.org; Tue, 26 Nov 2013 12:34:23 -0800 Date: Tue, 26 Nov 2013 12:34:23 -0800 (PST) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1385498063500-5864193.post@n5.nabble.com> In-Reply-To: <52950031.2010108@allanjude.com> References: <1385496434634-5864187.post@n5.nabble.com> <52950031.2010108@allanjude.com> Subject: Re: ZFS: sharenfs and "zdb no such file" errors MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 20:34:24 -0000 >> NFS related config for ZFS is stored in /etc/zfs/exports >> and mountd just reads that in addition to the usual /etc/exports >> you might want to check there Awesome, pal!! Editing that file cleared it all up. Thanks. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/ZFS-sharenfs-and-zdb-no-such-file-errors-tp5864187p5864193.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 01:22:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A01A97A4; Wed, 27 Nov 2013 01:22:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 697DC2C8B; Wed, 27 Nov 2013 01:22:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAR1MAl7038076; Tue, 26 Nov 2013 20:22:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAR1MASv038070; Wed, 27 Nov 2013 01:22:10 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Nov 2013 01:22:10 GMT Message-Id: <201311270122.rAR1MASv038070@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 01:22:11 -0000 TB --- 2013-11-26 19:40:22 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-26 19:40:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-26 19:40:22 - starting HEAD tinderbox run for i386/i386 TB --- 2013-11-26 19:40:22 - cleaning the object tree TB --- 2013-11-26 19:40:22 - /usr/local/bin/svn stat /src TB --- 2013-11-26 19:40:27 - At svn revision 258660 TB --- 2013-11-26 19:40:28 - building world TB --- 2013-11-26 19:40:28 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 19:40:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 19:40:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 19:40:28 - SRCCONF=/dev/null TB --- 2013-11-26 19:40:28 - TARGET=i386 TB --- 2013-11-26 19:40:28 - TARGET_ARCH=i386 TB --- 2013-11-26 19:40:28 - TZ=UTC TB --- 2013-11-26 19:40:28 - __MAKE_CONF=/dev/null TB --- 2013-11-26 19:40:28 - cd /src TB --- 2013-11-26 19:40:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 26 19:40:37 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Nov 26 22:53:27 UTC 2013 TB --- 2013-11-26 22:53:27 - generating LINT kernel config TB --- 2013-11-26 22:53:27 - cd /src/sys/i386/conf TB --- 2013-11-26 22:53:27 - /usr/bin/make -B LINT TB --- 2013-11-26 22:53:27 - cd /src/sys/i386/conf TB --- 2013-11-26 22:53:27 - /usr/sbin/config -m LINT TB --- 2013-11-26 22:53:27 - building LINT kernel TB --- 2013-11-26 22:53:27 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 22:53:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 22:53:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 22:53:27 - SRCCONF=/dev/null TB --- 2013-11-26 22:53:27 - TARGET=i386 TB --- 2013-11-26 22:53:27 - TARGET_ARCH=i386 TB --- 2013-11-26 22:53:27 - TZ=UTC TB --- 2013-11-26 22:53:27 - __MAKE_CONF=/dev/null TB --- 2013-11-26 22:53:27 - cd /src TB --- 2013-11-26 22:53:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 26 22:53:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Nov 26 23:31:17 UTC 2013 TB --- 2013-11-26 23:31:17 - cd /src/sys/i386/conf TB --- 2013-11-26 23:31:17 - /usr/sbin/config -m LINT-NOINET TB --- 2013-11-26 23:31:17 - building LINT-NOINET kernel TB --- 2013-11-26 23:31:17 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 23:31:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 23:31:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 23:31:17 - SRCCONF=/dev/null TB --- 2013-11-26 23:31:17 - TARGET=i386 TB --- 2013-11-26 23:31:17 - TARGET_ARCH=i386 TB --- 2013-11-26 23:31:17 - TZ=UTC TB --- 2013-11-26 23:31:17 - __MAKE_CONF=/dev/null TB --- 2013-11-26 23:31:17 - cd /src TB --- 2013-11-26 23:31:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Nov 26 23:31:17 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Wed Nov 27 00:03:53 UTC 2013 TB --- 2013-11-27 00:03:53 - cd /src/sys/i386/conf TB --- 2013-11-27 00:03:53 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-11-27 00:03:53 - building LINT-NOINET6 kernel TB --- 2013-11-27 00:03:53 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 00:03:53 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 00:03:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 00:03:53 - SRCCONF=/dev/null TB --- 2013-11-27 00:03:53 - TARGET=i386 TB --- 2013-11-27 00:03:53 - TARGET_ARCH=i386 TB --- 2013-11-27 00:03:53 - TZ=UTC TB --- 2013-11-27 00:03:53 - __MAKE_CONF=/dev/null TB --- 2013-11-27 00:03:53 - cd /src TB --- 2013-11-27 00:03:53 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Wed Nov 27 00:03:53 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Wed Nov 27 00:37:14 UTC 2013 TB --- 2013-11-27 00:37:14 - cd /src/sys/i386/conf TB --- 2013-11-27 00:37:14 - /usr/sbin/config -m LINT-NOIP TB --- 2013-11-27 00:37:14 - building LINT-NOIP kernel TB --- 2013-11-27 00:37:14 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 00:37:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 00:37:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 00:37:14 - SRCCONF=/dev/null TB --- 2013-11-27 00:37:14 - TARGET=i386 TB --- 2013-11-27 00:37:14 - TARGET_ARCH=i386 TB --- 2013-11-27 00:37:14 - TZ=UTC TB --- 2013-11-27 00:37:14 - __MAKE_CONF=/dev/null TB --- 2013-11-27 00:37:14 - cd /src TB --- 2013-11-27 00:37:14 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Wed Nov 27 00:37:14 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Wed Nov 27 01:07:26 UTC 2013 TB --- 2013-11-27 01:07:26 - cd /src/sys/i386/conf TB --- 2013-11-27 01:07:26 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-11-27 01:07:26 - building LINT-VIMAGE kernel TB --- 2013-11-27 01:07:26 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 01:07:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 01:07:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 01:07:26 - SRCCONF=/dev/null TB --- 2013-11-27 01:07:26 - TARGET=i386 TB --- 2013-11-27 01:07:26 - TARGET_ARCH=i386 TB --- 2013-11-27 01:07:26 - TZ=UTC TB --- 2013-11-27 01:07:26 - __MAKE_CONF=/dev/null TB --- 2013-11-27 01:07:26 - cd /src TB --- 2013-11-27 01:07:26 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Wed Nov 27 01:07:26 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ /src/sys/sys/sdt.h:153:19: note: expanded from macro 'SDT_PROBE_DEFINE' struct sdt_probe sdt_##prov##_##mod##_##func##_##name[1] = { \ ^ :55:1: note: expanded from here sdt_vnet_functions_vnet_destroy_entry ^ 4 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT-VIMAGE *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-27 01:22:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-27 01:22:10 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-11-27 01:22:10 - 16002.27 user 3181.51 system 20507.19 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 01:52:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E479BA5; Wed, 27 Nov 2013 01:52:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 26EA22E0B; Wed, 27 Nov 2013 01:52:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAR1qkuK023557; Tue, 26 Nov 2013 20:52:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAR1qkQH023553; Wed, 27 Nov 2013 01:52:46 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Nov 2013 01:52:46 GMT Message-Id: <201311270152.rAR1qkQH023553@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 01:52:47 -0000 TB --- 2013-11-26 19:40:22 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-26 19:40:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-26 19:40:22 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-11-26 19:40:22 - cleaning the object tree TB --- 2013-11-26 19:40:22 - /usr/local/bin/svn stat /src TB --- 2013-11-26 19:40:27 - At svn revision 258660 TB --- 2013-11-26 19:40:28 - building world TB --- 2013-11-26 19:40:28 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 19:40:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 19:40:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 19:40:28 - SRCCONF=/dev/null TB --- 2013-11-26 19:40:28 - TARGET=amd64 TB --- 2013-11-26 19:40:28 - TARGET_ARCH=amd64 TB --- 2013-11-26 19:40:28 - TZ=UTC TB --- 2013-11-26 19:40:28 - __MAKE_CONF=/dev/null TB --- 2013-11-26 19:40:28 - cd /src TB --- 2013-11-26 19:40:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 26 19:40:37 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Nov 26 23:29:43 UTC 2013 TB --- 2013-11-26 23:29:43 - generating LINT kernel config TB --- 2013-11-26 23:29:43 - cd /src/sys/amd64/conf TB --- 2013-11-26 23:29:43 - /usr/bin/make -B LINT TB --- 2013-11-26 23:29:43 - cd /src/sys/amd64/conf TB --- 2013-11-26 23:29:43 - /usr/sbin/config -m LINT TB --- 2013-11-26 23:29:43 - building LINT kernel TB --- 2013-11-26 23:29:43 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 23:29:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 23:29:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 23:29:43 - SRCCONF=/dev/null TB --- 2013-11-26 23:29:43 - TARGET=amd64 TB --- 2013-11-26 23:29:43 - TARGET_ARCH=amd64 TB --- 2013-11-26 23:29:43 - TZ=UTC TB --- 2013-11-26 23:29:43 - __MAKE_CONF=/dev/null TB --- 2013-11-26 23:29:43 - cd /src TB --- 2013-11-26 23:29:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 26 23:29:43 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Wed Nov 27 00:04:14 UTC 2013 TB --- 2013-11-27 00:04:14 - cd /src/sys/amd64/conf TB --- 2013-11-27 00:04:14 - /usr/sbin/config -m LINT-NOINET TB --- 2013-11-27 00:04:14 - building LINT-NOINET kernel TB --- 2013-11-27 00:04:14 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 00:04:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 00:04:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 00:04:14 - SRCCONF=/dev/null TB --- 2013-11-27 00:04:14 - TARGET=amd64 TB --- 2013-11-27 00:04:14 - TARGET_ARCH=amd64 TB --- 2013-11-27 00:04:14 - TZ=UTC TB --- 2013-11-27 00:04:14 - __MAKE_CONF=/dev/null TB --- 2013-11-27 00:04:14 - cd /src TB --- 2013-11-27 00:04:14 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Nov 27 00:04:14 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Wed Nov 27 00:36:37 UTC 2013 TB --- 2013-11-27 00:36:37 - cd /src/sys/amd64/conf TB --- 2013-11-27 00:36:37 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-11-27 00:36:37 - building LINT-NOINET6 kernel TB --- 2013-11-27 00:36:37 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 00:36:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 00:36:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 00:36:37 - SRCCONF=/dev/null TB --- 2013-11-27 00:36:37 - TARGET=amd64 TB --- 2013-11-27 00:36:37 - TARGET_ARCH=amd64 TB --- 2013-11-27 00:36:37 - TZ=UTC TB --- 2013-11-27 00:36:37 - __MAKE_CONF=/dev/null TB --- 2013-11-27 00:36:37 - cd /src TB --- 2013-11-27 00:36:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Wed Nov 27 00:36:37 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Wed Nov 27 01:08:42 UTC 2013 TB --- 2013-11-27 01:08:42 - cd /src/sys/amd64/conf TB --- 2013-11-27 01:08:42 - /usr/sbin/config -m LINT-NOIP TB --- 2013-11-27 01:08:42 - building LINT-NOIP kernel TB --- 2013-11-27 01:08:42 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 01:08:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 01:08:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 01:08:42 - SRCCONF=/dev/null TB --- 2013-11-27 01:08:42 - TARGET=amd64 TB --- 2013-11-27 01:08:42 - TARGET_ARCH=amd64 TB --- 2013-11-27 01:08:42 - TZ=UTC TB --- 2013-11-27 01:08:42 - __MAKE_CONF=/dev/null TB --- 2013-11-27 01:08:42 - cd /src TB --- 2013-11-27 01:08:42 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Wed Nov 27 01:08:42 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Wed Nov 27 01:38:00 UTC 2013 TB --- 2013-11-27 01:38:00 - cd /src/sys/amd64/conf TB --- 2013-11-27 01:38:00 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-11-27 01:38:00 - building LINT-VIMAGE kernel TB --- 2013-11-27 01:38:00 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 01:38:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 01:38:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 01:38:00 - SRCCONF=/dev/null TB --- 2013-11-27 01:38:00 - TARGET=amd64 TB --- 2013-11-27 01:38:00 - TARGET_ARCH=amd64 TB --- 2013-11-27 01:38:00 - TZ=UTC TB --- 2013-11-27 01:38:00 - __MAKE_CONF=/dev/null TB --- 2013-11-27 01:38:00 - cd /src TB --- 2013-11-27 01:38:00 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Wed Nov 27 01:38:00 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ /src/sys/sys/sdt.h:153:19: note: expanded from macro 'SDT_PROBE_DEFINE' struct sdt_probe sdt_##prov##_##mod##_##func##_##name[1] = { \ ^ :51:1: note: expanded from here sdt_vnet_functions_vnet_destroy_entry ^ 4 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT-VIMAGE *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-27 01:52:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-27 01:52:46 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-11-27 01:52:46 - 17285.21 user 3441.84 system 22343.33 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 04:29:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 978182BA; Wed, 27 Nov 2013 04:29:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C2822558; Wed, 27 Nov 2013 04:29:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAR4TCok087305; Tue, 26 Nov 2013 23:29:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAR4TCmW087295; Wed, 27 Nov 2013 04:29:12 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Nov 2013 04:29:12 GMT Message-Id: <201311270429.rAR4TCmW087295@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 04:29:14 -0000 TB --- 2013-11-27 00:47:54 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-27 00:47:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-27 00:47:54 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-11-27 00:47:54 - cleaning the object tree TB --- 2013-11-27 00:47:54 - /usr/local/bin/svn stat /src TB --- 2013-11-27 00:48:19 - At svn revision 258660 TB --- 2013-11-27 00:48:20 - building world TB --- 2013-11-27 00:48:20 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 00:48:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 00:48:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 00:48:20 - SRCCONF=/dev/null TB --- 2013-11-27 00:48:20 - TARGET=pc98 TB --- 2013-11-27 00:48:20 - TARGET_ARCH=i386 TB --- 2013-11-27 00:48:20 - TZ=UTC TB --- 2013-11-27 00:48:20 - __MAKE_CONF=/dev/null TB --- 2013-11-27 00:48:20 - cd /src TB --- 2013-11-27 00:48:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Nov 27 00:48:28 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 27 04:09:56 UTC 2013 TB --- 2013-11-27 04:09:56 - generating LINT kernel config TB --- 2013-11-27 04:09:56 - cd /src/sys/pc98/conf TB --- 2013-11-27 04:09:56 - /usr/bin/make -B LINT TB --- 2013-11-27 04:09:56 - cd /src/sys/pc98/conf TB --- 2013-11-27 04:09:56 - /usr/sbin/config -m LINT TB --- 2013-11-27 04:09:56 - building LINT kernel TB --- 2013-11-27 04:09:56 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 04:09:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 04:09:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 04:09:56 - SRCCONF=/dev/null TB --- 2013-11-27 04:09:56 - TARGET=pc98 TB --- 2013-11-27 04:09:56 - TARGET_ARCH=i386 TB --- 2013-11-27 04:09:56 - TZ=UTC TB --- 2013-11-27 04:09:56 - __MAKE_CONF=/dev/null TB --- 2013-11-27 04:09:56 - cd /src TB --- 2013-11-27 04:09:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 27 04:09:56 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:483:17: error: use of undeclared identifier 'nfscl_accesscache_get_hit_id' else if (id == nfscl_accesscache_get_hit_id) ^ /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:485:17: error: use of undeclared identifier 'nfscl_accesscache_get_miss_id' else if (id == nfscl_accesscache_get_miss_id) ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** Error code 1 Stop. bmake[4]: stopped in /src/sys/modules/dtrace/dtnfscl *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/dtrace *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/pc98.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-27 04:29:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-27 04:29:12 - ERROR: failed to build LINT kernel TB --- 2013-11-27 04:29:12 - 10621.30 user 1455.07 system 13277.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 06:26:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1315C5B; Wed, 27 Nov 2013 06:26:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ABB3A2A34; Wed, 27 Nov 2013 06:26:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rAR6Q2eP064490; Wed, 27 Nov 2013 01:26:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rAR6Q2EN064489; Wed, 27 Nov 2013 06:26:02 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Nov 2013 06:26:02 GMT Message-Id: <201311270626.rAR6Q2EN064489@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 06:26:04 -0000 TB --- 2013-11-27 03:37:00 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-27 03:37:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-27 03:37:00 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-27 03:37:00 - cleaning the object tree TB --- 2013-11-27 03:39:36 - /usr/local/bin/svn stat /src TB --- 2013-11-27 03:40:37 - At svn revision 258660 TB --- 2013-11-27 03:40:38 - building world TB --- 2013-11-27 03:40:38 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 03:40:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 03:40:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 03:40:38 - SRCCONF=/dev/null TB --- 2013-11-27 03:40:38 - TARGET=powerpc TB --- 2013-11-27 03:40:38 - TARGET_ARCH=powerpc TB --- 2013-11-27 03:40:38 - TZ=UTC TB --- 2013-11-27 03:40:38 - __MAKE_CONF=/dev/null TB --- 2013-11-27 03:40:38 - cd /src TB --- 2013-11-27 03:40:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Nov 27 03:40:45 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 27 06:13:50 UTC 2013 TB --- 2013-11-27 06:13:50 - generating LINT kernel config TB --- 2013-11-27 06:13:50 - cd /src/sys/powerpc/conf TB --- 2013-11-27 06:13:50 - /usr/bin/make -B LINT TB --- 2013-11-27 06:13:50 - cd /src/sys/powerpc/conf TB --- 2013-11-27 06:13:50 - /usr/sbin/config -m LINT TB --- 2013-11-27 06:13:50 - building LINT kernel TB --- 2013-11-27 06:13:50 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 06:13:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 06:13:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 06:13:50 - SRCCONF=/dev/null TB --- 2013-11-27 06:13:50 - TARGET=powerpc TB --- 2013-11-27 06:13:50 - TARGET_ARCH=powerpc TB --- 2013-11-27 06:13:50 - TZ=UTC TB --- 2013-11-27 06:13:50 - __MAKE_CONF=/dev/null TB --- 2013-11-27 06:13:50 - cd /src TB --- 2013-11-27 06:13:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 27 06:13:50 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:506: error: 'nfscl_accesscache_flush_done_id' undeclared (first use in this function) /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:508: error: 'nfscl_accesscache_get_hit_id' undeclared (first use in this function) /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:510: error: 'nfscl_accesscache_get_miss_id' undeclared (first use in this function) /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:512: error: 'nfscl_accesscache_load_done_id' undeclared (first use in this function) /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:514: error: 'nfscl_attrcache_flush_done_id' undeclared (first use in this function) /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:516: error: 'nfscl_attrcache_get_hit_id' undeclared (first use in this function) /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:518: error: 'nfscl_attrcache_get_miss_id' undeclared (first use in this function) /src/sys/modules/dtrace/dtnfscl/../../../fs/nfsclient/nfs_clkdtrace.c:520: error: 'nfscl_attrcache_load_done_id' undeclared (first use in this function) *** Error code 1 Stop. bmake[4]: stopped in /src/sys/modules/dtrace/dtnfscl *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/dtrace *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-27 06:26:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-27 06:26:02 - ERROR: failed to build LINT kernel TB --- 2013-11-27 06:26:02 - 8571.16 user 1078.95 system 10141.68 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 08:22:41 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D72B4930 for ; Wed, 27 Nov 2013 08:22:41 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DE0B2F83 for ; Wed, 27 Nov 2013 08:22:41 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAR8MRnk039213; Wed, 27 Nov 2013 00:22:31 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311270822.rAR8MRnk039213@gw.catspoiler.org> Date: Wed, 27 Nov 2013 00:22:27 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131125081047.GN59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 08:22:41 -0000 On 25 Nov, Konstantin Belousov wrote: > On Sat, Nov 23, 2013 at 11:43:30PM -0800, Don Lewis wrote: >> I upgraded my 11.0-CURRENT machine to r258504 to get past the uma panic >> that I stumbled across earlier. Now I got this when I started upgrading >> ports: >> >> Unread portion of the kernel message buffer: >> >> Fatal double fault: >> eip = 0xc0b158e0 >> esp = 0xe4f62000 >> ebp = 0xe4f62010 >> cpuid = 0; apic id = 00 >> panic: double fault >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper(c113340c,2,10000000,c15a0cf0,c15a0ce8,...) at db_trace_self_wrapper+0x2d/frame 0xc15a0cb0 >> kdb_backtrace(c12f143f,0,c12f2aea,c15a0d6c,0,...) at kdb_backtrace+0x30/frame 0xc15a0d18 >> vpanic(c15a0d6c,c15a0d84,c0fc14fb,c12f2aea,0,...) at vpanic+0x11f/frame 0xc15a0d54 >> panic(c12f2aea,0,0,0,e4f62010,...) at panic+0x12/frame 0xc15a0d60 >> dblfault_handler() at dblfault_handler+0xab/frame 0xc15a0d60 >> --- trap 0x17, eip = 0xc0b158e0, esp = 0xe4f62000, ebp = 0xe4f62010 --- >> vprintf(c12f2900,c,fffffe7f,fffffeff,bfff75ed,...) at vprintf/frame 0xe4f62010 >> trap(e4f62164) at trap+0x18a/frame 0xe4f62158 >> calltrap() at calltrap+0x6/frame 0xe4f62158 >> --- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f621a4, ebp = 0xe4f62270 --- >> kvprintf(c12f2900,c0b15210,e4f62290,a,e4f6235c,...) at kvprintf+0x1cd/frame 0xe4f62270 >> vprintf(c12f2900,e4f6235c,e4f6235c) at vprintf+0x7f/frame 0xe4f6233c >> printf(c12f2900,c,ffefdfff,ebefefff,dfdffedf,...) at printf+0x1b/frame 0xe4f62350 >> trap(e4f624a4) at trap+0x18a/frame 0xe4f62498 >> calltrap() at calltrap+0x6/frame 0xe4f62498 >> --- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f624e4, ebp = 0xe4f625b0 --- >> kvprintf(c12f2900,c0b15210,e4f625d0,a,e4f6269c,...) at kvprintf+0x1cd/frame 0xe4f625b0 >> vprintf(c12f2900,e4f6269c,e4f6269c) at vprintf+0x7f/frame 0xe4f6267c >> printf(c12f2900,c,5fd7ff5f,ba77f7fb,bfffb7ff,...) at printf+0x1b/frame 0xe4f62690 >> trap(e4f627e4) at trap+0x18a/frame 0xe4f627d8 >> calltrap() at calltrap+0x6/frame 0xe4f627d8 >> --- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f62824, ebp = 0xe4f628f0 --- >> kvprintf(c12f2900,c0b15210,e4f62910,a,e4f629dc,...) at kvprintf+0x1cd/frame 0xe4f628f0 >> vprintf(c12f2900,e4f629dc,e4f629dc) at vprintf+0x7f/frame 0xe4f629bc >> printf(c12f2900,c,0,80000000,c0,...) at printf+0x1b/frame 0xe4f629d0 >> trap(e4f62b20) at trap+0x18a/frame 0xe4f62b14 >> calltrap() at calltrap+0x6/frame 0xe4f62b14 >> --- trap 0xc, eip = 0xc0afe270, esp = 0xe4f62b60, ebp = 0xe4f62b78 --- >> tdq_choose(c141e090,4,c113144d,917,c2425c80,...) at tdq_choose+0x60/frame 0xe4f62b78 >> sched_choose(e4f62c00,c0afc511,c141e090,14,c113144d,...) at sched_choose+0x4c/frame 0xe4f62ba4 >> choosethread(c141e090,14,c113144d,78b,c141e116,...) at choosethread+0x1f/frame 0xe4f62bac >> sched_switch(c8f04000,0,608,1b7,ef2,...) at sched_switch+0x361/frame 0xe4f62c00 >> mi_switch(608,0,c112f4e4,d3,c,...) at mi_switch+0x1c9/frame 0xe4f62c34 >> critical_exit(0,2,c113144d,411,c141e108,...) at critical_exit+0xa4/frame 0xe4f62c50 >> sched_idletd(0,e4f62d08,c1128634,3db,0,...) at sched_idletd+0x1d6/frame 0xe4f62ccc >> fork_exit(c0afeb00,0,e4f62d08) at fork_exit+0x7f/frame 0xe4f62cf4 >> fork_trampoline() at fork_trampoline+0x8/frame 0xe4f62cf4 >> --- trap 0, eip = 0, esp = 0xe4f62d40, ebp = 0 --- >> KDB: enter: panic >> >> (kgdb) list *tdq_choose+0x60 >> 0xc0afe270 is in tdq_choose (/usr/src/sys/kern/sched_ule.c:1334). >> 1329 td = runq_choose(&tdq->tdq_realtime); >> 1330 if (td != NULL) >> 1331 return (td); >> 1332 td = runq_choose_from(&tdq->tdq_timeshare, tdq->tdq_ridx); >> 1333 if (td != NULL) { >> 1334 KASSERT(td->td_priority >= PRI_MIN_BATCH, >> 1335 ("tdq_choose: Invalid priority on timeshare queue %d", >> 1336 td->td_priority)); >> 1337 return (td); >> 1338 } >> >> (kgdb) bt >> #0 doadump (textdump=-1051128300) at pcpu.h:233 >> #1 0xc052766d in db_fncall (dummy1=-1051051648, dummy2=0, dummy3=-1051063684, >> dummy4=0xc15a0a54 "") at /usr/src/sys/ddb/db_command.c:578 >> #2 0xc0527357 in db_command (cmd_table=) >> at /usr/src/sys/ddb/db_command.c:449 >> #3 0xc0527090 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 >> #4 0xc0529922 in db_trap (type=, code=0) >> at /usr/src/sys/ddb/db_main.c:231 >> #5 0xc0b0ff38 in kdb_trap (type=, >> code=, tf=) >> at /usr/src/sys/kern/subr_kdb.c:656 >> #6 0xc0fc0c07 in trap (frame=) >> at /usr/src/sys/i386/i386/trap.c:712 >> #7 0xc0faa0ec in calltrap () at /usr/src/sys/i386/i386/exception.s:170 >> #8 0xc0b0f7bd in kdb_enter (why=0xc112ee39 "panic", msg=) >> at cpufunc.h:71 >> #9 0xc0ad6a93 in vpanic (fmt=, ap=) >> at /usr/src/sys/kern/kern_shutdown.c:747 >> #10 0xc0ad6ad2 in panic (fmt=0xc12f2aea "double fault") >> at /usr/src/sys/kern/kern_shutdown.c:683 >> #11 0xc0fc14fb in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:1072 >> #12 0x00000000 in ?? () > > It seems to be a corruption of the td and probably curthread. > > Is it repeatable easily ? If yes, you could try to manually inspect first > elements in the (idle) runq queue of the tdq_cpu[paniced cpu]. It took a while, but I just got another double fault, though this one is somewhat different. This time it trapped in cpu_switch(), which resulted in calls to trap()->printf()->...->putchar()->msgbuf_addstr()->_mtx_lock_spin_flags() where it trapped again. Sitting at DDB prompt ... From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 08:48:10 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A94CFEA; Wed, 27 Nov 2013 08:48:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9C4120E3; Wed, 27 Nov 2013 08:48:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAR8m04U026443; Wed, 27 Nov 2013 10:48:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAR8m04U026443 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAR8m0r9026442; Wed, 27 Nov 2013 10:48:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Nov 2013 10:48:00 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131127084800.GV59496@kib.kiev.ua> References: <20131125081047.GN59496@kib.kiev.ua> <201311270822.rAR8MRnk039213@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9SDGQ4N0om8vOODx" Content-Disposition: inline In-Reply-To: <201311270822.rAR8MRnk039213@gw.catspoiler.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 08:48:10 -0000 --9SDGQ4N0om8vOODx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 12:22:27AM -0800, Don Lewis wrote: > It took a while, but I just got another double fault, though this one is > somewhat different. This time it trapped in cpu_switch(), which > resulted in calls to > trap()->printf()->...->putchar()->msgbuf_addstr()->_mtx_lock_spin_flags() > where it trapped again. >=20 > Sitting at DDB prompt ... Does 'show allpcpu' work ? --9SDGQ4N0om8vOODx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlbG/AAoJEJDCuSvBvK1BSbEP/2D0W0HgjFYzgi3vCXo35gRo LGZ7YhK2AWU/eMxlJ9eH2XkOpFzHuReUFiCIF2sX1WTp32SJlMNuLRCY1xdDN46p EaRx92FJft/P5YbGrf8JvXKRU9XsFeP0Waock7v5+3Yj1F/8ppqqs7/Hs/gZ5UIT kU8FNBFPOf3L+Z446e31u1mCs5aNF70syYoB9CmOb8CWAJcoHu2vCsVstFPLzLE+ No0GSUSKbRfU6p0SRfpsmRKahCc+UTfSknNO+SC03FdMQ/00k18osDyrxeMejJWN WO90Wt3yoSbioF/ZFYbc2bKOR4VgN3QHCRW7Yo3vnRsYDx6hYBZxXzQXXbZZMKtx v8HAp7ZYiFVxIPi3xtqkpsjY2XoJwf8zGCkutjXITtLcfBOQSHVXWgq1AoUKmhtr 1nYoidjqMzwrg/pC99itT1LAWrQVniFvVt5AupK1Q193eu53QMjVBt0KQm+EoDXC VOXv48xLjEJOVSRh/+SLtpTFOFQfHjYPFL3mqb6hDe8J2+/RP8MZPHptl0bfmi3y D1ztnh6Ddb7Ypko/cxIEkPwRzSY0FJBdXZjrR+EOH+IJBOytJcrt4dI2uDC9LkJA PIKmti4uJHFMJUuUyulVj4qlCQAQjdIOuZGzcmxxaJwGisqU3dnZFySeh85Z3bW7 e3lSWcuoMAsD96xWmvnf =OmCb -----END PGP SIGNATURE----- --9SDGQ4N0om8vOODx-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 09:13:49 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D16A5EE for ; Wed, 27 Nov 2013 09:13:49 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3AB4F2261 for ; Wed, 27 Nov 2013 09:13:49 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAR9DfeL039290; Wed, 27 Nov 2013 01:13:45 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311270913.rAR9DfeL039290@gw.catspoiler.org> Date: Wed, 27 Nov 2013 01:13:41 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131127084800.GV59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 09:13:49 -0000 On 27 Nov, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 12:22:27AM -0800, Don Lewis wrote: >> It took a while, but I just got another double fault, though this one is >> somewhat different. This time it trapped in cpu_switch(), which >> resulted in calls to >> trap()->printf()->...->putchar()->msgbuf_addstr()->_mtx_lock_spin_flags() >> where it trapped again. >> >> Sitting at DDB prompt ... > > Does 'show allpcpu' work ? Yup. For both CPUs, curthread == idlethread, both CPUs have the same curpcb. What is "dynamic pcpu"? The values differ considerably between the two CPUs. From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 09:22:56 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDF428FE; Wed, 27 Nov 2013 09:22:56 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E91892303; Wed, 27 Nov 2013 09:22:55 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA00248; Wed, 27 Nov 2013 11:22:54 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VlbKg-0005HJ-3x; Wed, 27 Nov 2013 11:22:54 +0200 Message-ID: <5295B9B6.1070400@FreeBSD.org> Date: Wed, 27 Nov 2013 11:21:58 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-ports@FreeBSD.org, FreeBSD Current Subject: (bsd)patch vs ports X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 09:22:56 -0000 When building ports on head I sometimes see messages like the following during a patch phase: ===> Applying FreeBSD patches for firefox-25.0_1,1 No such line 262 in input file, ignoring ===> Applying NSS patches No such line 194 in input file, ignoring No such line 658 in input file, ignoring No such line 52 in input file, ignoring No such line 45 in input file, ignoring Is this a cause for concern? Do those messages mean that potentially important patches are not actually applied? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 10:05:49 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB97155C; Wed, 27 Nov 2013 10:05:49 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FA40253A; Wed, 27 Nov 2013 10:05:49 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 988E3DBD0; Wed, 27 Nov 2013 10:05:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 988E3DBD0 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Wed, 27 Nov 2013 05:05:45 -0500 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-snapshots@FreeBSD.org Subject: FreeBSD 10.0-BETA3 snapshots (pre -BETA4) now available Message-ID: <20131127100545.GI1710@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zqjkMoGlbUJ91oFe" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 10:05:49 -0000 --zqjkMoGlbUJ91oFe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline FreeBSD 10.0-BETA3 snapshots are now available. These images are generated from r258657 of stable/10, and are intended as pre -BETA4 snapshots for public testing, until 10.0-BETA4 is rolled (which should be within the next few days). Please note, freebsd-update(8) upgrades are not available for this set of builds. As these builds are considered "snapshot-only", the change list is not included, in case something needs to be reverted for the 10.0-BETA4 builds. If you notice problems you can report them through the normal GNATS PR system or here on the -current mailing list. The images may be downloaded from the 'snapshots' directory on FTP: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ In addition, pre-built virtual machine images are also available: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Checksums for the installation ISOs and the VM disk images follow at the end of this email. == ISO CHECKSUMS == - 10.0-BETA3 amd64: SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-bootonly.iso) = bbaf40b51278e7f0f31ca056459539acd4eeca07eb3db77468e70f68dadfbc93 SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-disc1.iso) = e3f35a786af16bf8ea7f8ba8a1ce1a4ca0aaeb4388bd1af0f5d948072768472a SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-dvd1.iso) = 61c8031ad3c7daafe619e686485d04ee219dc6cdec5636ac171f3e6317c37004 SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-memstick.img) = 7f8bb8e0815772a9277d8465f7b43c22b07b7dd6251ddc0809ae9309c379d743 MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-bootonly.iso) = 573f679c2eacfbf46dd8452975c5a807 MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-disc1.iso) = 6ca7358887c622b7d9290da0acc4373c MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-dvd1.iso) = 833e47010f72aaed8e4ef5df8ef2f65d MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-memstick.img) = 576c2fc5c63aa3b3e46da38f7c40dec4 - 10.0-BETA3 i386: SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-bootonly.iso) = d08bf30619af86c5c8013a64be3fe3496c6b45b522a431660617011039a966a5 SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-disc1.iso) = 59e98e4f91bee70d9101b04f315ea2b5e2d3650f1f203ed9bba0a9e3bea09159 SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-dvd1.iso) = 0680818b9bf51513a5fbf311720873207f528c6201f9b05dbe322843a83ca9de SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-memstick.img) = 7c333fd25bb9e16c9b52027b3991e96b89f5cf44bb9e6d4e5ffb2162cb5f8654 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-bootonly.iso) = 3e950d40c7f807d0a4b8eef2d85da4c5 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-disc1.iso) = 95c5deb510b2d7d89d39435210c93e90 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-dvd1.iso) = 961394ea39d97ed706b8f840566aa7cd MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-memstick.img) = 12366e49affc33a9104861172adab6f4 - 10.0-BETA3 ia64: SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-bootonly.iso) = 843d2f6c7c2c57063e0de773f98c3d6327deded9fbe7488fdd90f5d3b091399d SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-disc1.iso) = 2f2b51ec6f9a32cd12db58bcb9e577f39689c250da666e7d3ceecbc54883377c SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-memstick.img) = 08902cfd3447df4edac150ff96bbf1235bab4ac461e4238c1125eea83cba15b1 MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-bootonly.iso) = 876d0a31510cf6a1251324738be82177 MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-disc1.iso) = 0acf4517db5df9407e97857d7811277b MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-memstick.img) = 55025d6ac489769ebb251ac137fe89e7 - 10.0-BETA3 powerpc: SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-bootonly.iso) = fff26c419a1a7380af4fdf8cee86aabd97584d03c6da71b2dff7e3f277f17711 SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-disc1.iso) = 2cdad79753ca5dc45907f14587fcfd06eed1b8449ed367f225045372762119b9 SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-memstick.img) = 16f2f54a9b7943b4eff89a8d52e96724caefecb39683125543a507a20df49953 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-bootonly.iso) = 9fb3857c394473d1e6fa7bd0753a6201 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-disc1.iso) = 4e9304f55d8a63310e4eda6c5bd8e4c7 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-memstick.img) = 11fc39cb92d9ef2d643c56368221443e - 10.0-BETA3 powerpc64: SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-bootonly.iso) = 7eb672f81d4c3cb32399f4285bb049e8576d1fabe46350210ca37bb01ea2e523 SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-disc1.iso) = 3ee0949bcab657b461fa5ca9eeef82ec8cd561750e098fbfd899330178bf2337 SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-memstick.img) = df21073b158b9be8bedd8d7ed55bd385a02844234c0ecb61701a3b42b6e035bb MD5 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-bootonly.iso) = 342212e97db9c2ea53c16c3aad2dea98 MD5 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-disc1.iso) = b5789471b9f4428468b906e140da5ea7 MD5 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-memstick.img) = 8f6ef84f4f9ba3fd46e57166434ec4e3 - 10.0-BETA3 sparc64: SHA256 (FreeBSD-10.0-BETA3-sparc64-20131126-r258657-bootonly.iso) = 7e9217cd7ba5dce8704288c9fe05a10e91bcefc134fbbe45fa951c00ad8e3e54 SHA256 (FreeBSD-10.0-BETA3-sparc64-20131126-r258657-disc1.iso) = 36401ec2425a8cb2417dc389ad664262d618bf69d39142960c94d6622581b42b MD5 (FreeBSD-10.0-BETA3-sparc64-20131126-r258657-bootonly.iso) = 27c5c1c6e7b5ad113f66f4a2c59a3bce MD5 (FreeBSD-10.0-BETA3-sparc64-20131126-r258657-disc1.iso) = fd9c5289fceaa3a3d650e15ad4c0c682 == VM IMAGE CHECKSUMS == - 10.0-BETA3 amd64: SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.qcow2.xz) = dfa8b295a247e760209df361dbe7d62425645360f3ab03f2bbb052ffa1d27f1a SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.vhd.xz) = d3306bdb526b6afe44a09cad6583b4c8ad747d202c970bfe234ae540688d526b SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.vmdk.xz) = 6982f66914a9f63f3e2301609aa2aff09b10a737cc3b07eb1b7972ac4e1e0fa1 MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.qcow2.xz) = 55e56a789b3b5b3c989df6bc27831b2f MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.vhd.xz) = 51a5cae2c6bb54c245a2c0a3388024dc MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.vmdk.xz) = 232455466d35471efea92e20e533b435 - 10.0-BETA3 i386: SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657.qcow2.xz) = 49ba5bbb5f33986f3b451f278063718e453b81a92a8b33cdd6d4f8af0fd236e8 SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657.vhd.xz) = baadc51e47e21f18f8394dec36342f387f0c4875e8c819b449e317f2a674924d SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657.vmdk.xz) = cce2a2eb73576231488fb46fa6869130db119cf10f1c5aadc371a6f3723fcbd2 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657.qcow2.xz) = f2f90e6b00c1f1bfa3e865f2a524f543 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657.vhd.xz) = b6d1dff90067336083c3b56e48d6d15f MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657.vmdk.xz) = 1bca9e2f6c70df490984cf810480e7f2 Glen --zqjkMoGlbUJ91oFe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSlcP5AAoJELls3eqvi17QtKUP/05cP2iMYx2ESMzJM3Avwh6C 8lSbeHznczfcxiuGkalr7c/J5iu/G9PuN3Wy7fVIP9uOzc3bKTMZu4qCVV947ye2 RghecmsNUkEgNfypKawx9EZHd8U8EZYhpNbvCx1SenfB7vcNLJxbzEsL3eEdsV6O pzPl7bbm6XeAVbwdcsC6Sof/XGIEKR/awDYt5MzhaMSmlXXbze0LHQEWXnJ3Oji3 j6jHKClIZv4o4Yl5xLaGQVS2lup3X8hWB+ZjEcRI8kjkqCfzQacy4meYmFuMJK9S GcLuV+m8g0uP48u3p/EOyrXwLS6w4oQdvaArkqNOXRb23olNyDc5cYUEL8QHxg1t aZvWwSMDwylactuWoX1zevirZ9MLswOkRhahM4vL2i30ETAFTzCyhsRJ5ARMkCvM F98e6x6aL30SW4K5bQ04bV8KuVdQUIe7CmSnqkhTIphk1SG8lmRPmvCqO2JbX6LN CWe678gQo7oJcpHUhYDcVAJGESGPwijqQpump8PTW+uKH9HvycXp0xyaZ97dT8T5 hMuSLxptlVdN3yvLBlXVXSJ189RpdrSrbpeMmc/M1uO+5i5T8R237I9kMXtUx+Sl MYv5uQZ3izVrGal2gLYErCzs1eaZFhHOKPoYYqRvfNnthcx8nOu+aefvc8970+Ec uGAinpbZDMZh/a1IKa1d =aNMc -----END PGP SIGNATURE----- --zqjkMoGlbUJ91oFe-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 10:24:59 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 288BC137; Wed, 27 Nov 2013 10:24:59 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE41226A2; Wed, 27 Nov 2013 10:24:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rARAOm0l046532; Wed, 27 Nov 2013 12:24:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rARAOm0l046532 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rARAOmbB046531; Wed, 27 Nov 2013 12:24:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Nov 2013 12:24:48 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131127102448.GX59496@kib.kiev.ua> References: <20131127084800.GV59496@kib.kiev.ua> <201311270913.rAR9DfeL039290@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7xM+HP/38VnOPdrP" Content-Disposition: inline In-Reply-To: <201311270913.rAR9DfeL039290@gw.catspoiler.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 10:24:59 -0000 --7xM+HP/38VnOPdrP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 01:13:41AM -0800, Don Lewis wrote: > On 27 Nov, Konstantin Belousov wrote: > > On Wed, Nov 27, 2013 at 12:22:27AM -0800, Don Lewis wrote: > >> It took a while, but I just got another double fault, though this one = is > >> somewhat different. This time it trapped in cpu_switch(), which > >> resulted in calls to > >> trap()->printf()->...->putchar()->msgbuf_addstr()->_mtx_lock_spin_flag= s() > >> where it trapped again. > >>=20 > >> Sitting at DDB prompt ... > >=20 > > Does 'show allpcpu' work ? >=20 > Yup. For both CPUs, curthread =3D=3D idlethread, both CPUs have the same > curpcb. What is "dynamic pcpu"? The values differ considerably between > the two CPUs. Are you sure about curpcb being the same for two CPUs ? This is rather broken. The best would be to show the actual ddb output. Dynamic pcpu is in fact 'static' pcpu which is allocated for modules. It must be per-cpu, so different values are correct. --7xM+HP/38VnOPdrP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlchvAAoJEJDCuSvBvK1BviQP/1Kcp03cEQ4SpER3ybN4R9v7 BuEWbebzNPk/dF9BGqNiVN+fjDxRaVe8Yc+HkFKqC9f0ZA2WlcRksW6fRVnoW/Y/ NexLtn97tZQJF+u+zGDfWE2T0mvyasxdbUBgm4Q+Is/P96Qa5s4MVCiUMqpbpqw8 B6/8Hsvujc0ZBbsflP/gT6TgT0SP7klnThKVf4OrFgxUWvZUz5Xt10PwOeDfmsp4 8re68v0K+SrpNhcGzT9ZfGZKv4yF6rCIaYGeG6x5VbTKcVCi99xU68N+OzJqJ+Cp 7eNJeo9INUNxTkKfYIQF1tr9yU7bDcXD+7G2x5UbhL3EgCcqiuYzwRfLqlQdD/D1 Z/D4aA3MsxzxK+0szgxv/6yhqV7fUa8WRhlNUdpUXlJYKNbejWgtvdL0WBH+eIgf IkPj2LUYYZCMe+BrchX1WSdKhbPfWX484tJSI2XzDS0AW2p/dT5XA88C1wg2/AOn yftxKpUinvDkwDtjBeCKdQcVlXn+KInTtdFSzYF4XXS33TsHz8hMT+HGe9oIJKHF mQWsntpc5zpmy8q9ugZwF3LxvK9Aduz71au+Ow/q4l99c4/WQwZxSEKR2u1LxYcF LCI+DrJGsuHR4TPXEu4hoyjWrASnXthtk1uI7zYjpglxQ5mbzKOk5VbbwJBkgH/w UgVAuncXLPYXl1b0dHGi =+ngu -----END PGP SIGNATURE----- --7xM+HP/38VnOPdrP-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 10:41:38 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDE1245D for ; Wed, 27 Nov 2013 10:41:38 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A35BE2781 for ; Wed, 27 Nov 2013 10:41:38 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rARAfUP2040781; Wed, 27 Nov 2013 02:41:34 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311271041.rARAfUP2040781@gw.catspoiler.org> Date: Wed, 27 Nov 2013 02:41:30 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131127102448.GX59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 10:41:38 -0000 On 27 Nov, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 01:13:41AM -0800, Don Lewis wrote: >> On 27 Nov, Konstantin Belousov wrote: >> > On Wed, Nov 27, 2013 at 12:22:27AM -0800, Don Lewis wrote: >> >> It took a while, but I just got another double fault, though this one is >> >> somewhat different. This time it trapped in cpu_switch(), which >> >> resulted in calls to >> >> trap()->printf()->...->putchar()->msgbuf_addstr()->_mtx_lock_spin_flags() >> >> where it trapped again. >> >> >> >> Sitting at DDB prompt ... >> > >> > Does 'show allpcpu' work ? >> >> Yup. For both CPUs, curthread == idlethread, both CPUs have the same >> curpcb. What is "dynamic pcpu"? The values differ considerably between >> the two CPUs. > > Are you sure about curpcb being the same for two CPUs ? This is rather > broken. The best would be to show the actual ddb output. It turns out that they are different: 0xe4f62d60 0xe4f65d60 Screenshot here: > Dynamic pcpu is in fact 'static' pcpu which is allocated for modules. > It must be per-cpu, so different values are correct. From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 10:49:20 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B54775EB for ; Wed, 27 Nov 2013 10:49:20 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99B0127BC for ; Wed, 27 Nov 2013 10:49:20 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rARAnCum040847; Wed, 27 Nov 2013 02:49:16 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311271049.rARAnCum040847@gw.catspoiler.org> Date: Wed, 27 Nov 2013 02:49:12 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <201311271041.rARAfUP2040781@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 10:49:20 -0000 On 27 Nov, I wrote: > On 27 Nov, Konstantin Belousov wrote: >> On Wed, Nov 27, 2013 at 01:13:41AM -0800, Don Lewis wrote: >>> On 27 Nov, Konstantin Belousov wrote: >>> > On Wed, Nov 27, 2013 at 12:22:27AM -0800, Don Lewis wrote: >>> >> It took a while, but I just got another double fault, though this one is >>> >> somewhat different. This time it trapped in cpu_switch(), which >>> >> resulted in calls to >>> >> trap()->printf()->...->putchar()->msgbuf_addstr()->_mtx_lock_spin_flags() >>> >> where it trapped again. >>> >> >>> >> Sitting at DDB prompt ... >>> > >>> > Does 'show allpcpu' work ? >>> >>> Yup. For both CPUs, curthread == idlethread, both CPUs have the same >>> curpcb. What is "dynamic pcpu"? The values differ considerably between >>> the two CPUs. >> >> Are you sure about curpcb being the same for two CPUs ? This is rather >> broken. The best would be to show the actual ddb output. > > It turns out that they are different: > 0xe4f62d60 > 0xe4f65d60 > > Screenshot here: And screenshot of the stack trace here: From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 12:03:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CEE33B5 for ; Wed, 27 Nov 2013 12:03:59 +0000 (UTC) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 27BDA2B70 for ; Wed, 27 Nov 2013 12:03:58 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id rARC3vBq001242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Nov 2013 13:03:57 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5295DFAD.5070402@omnilan.de> Date: Wed, 27 Nov 2013 13:03:57 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Feature request: sticky bit inheritance X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA4D34D963C2C152CACD8C144" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 12:03:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA4D34D963C2C152CACD8C144 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, ever since I took a FreeBSD machine into production, acting as any kind of file server, I have to work arround the problem, that write access to a directory implies unlinking (deleting) directory contents. Never heard any sensible explanation why anybody would ever want that behaviour, but it's been like that for decades and everybody seems to be fine with that!?! Maybe because there's the stick bit, which is a usable workarroun= d. Unfortunately, there's no =E2=80=9Csticky=E2=80=9D equivalent in nfs4acls= =2E More unfortunate, newly created directories don't inherit the sticky bit =E2=80=93 unlike the group settings. And most unfortunate, I'm not able to implement sticky bit inheritance myself :-( Since there's already a kind of inheritance when calling mkdir(1), I guess extendig the inheritance to respect the sticky bit shouldn't be too complex, is it? I'd love to see a sysctl which controls the behaviour, so there's no unexpected behaviour, but the possibillity to make FreeBSDs filsystem-permission-control more real-world-usable. But if a sysctl is noticable more effort than just a kern-conf (compile time) option, I'd also highly appreciate that option! Is there anybody who might want to look into that? Thanks, -Harry --------------enigA4D34D963C2C152CACD8C144 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlKV360ACgkQLDqVQ9VXb8jGtwCgxicLIh96i3vn105gXObeflFF SwIAoKSFdu2Fc739hxpOW4kJxEmF1AJK =R1Iz -----END PGP SIGNATURE----- --------------enigA4D34D963C2C152CACD8C144-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 12:17:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4ACF68E0 for ; Wed, 27 Nov 2013 12:17:40 +0000 (UTC) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12AE92C24 for ; Wed, 27 Nov 2013 12:17:40 +0000 (UTC) Received: by mail-yh0-f52.google.com with SMTP id i72so4914544yha.39 for ; Wed, 27 Nov 2013 04:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:content-type; bh=nX1B+A1m/6YE5hYwalyLefo7OROV0vSEsvlgl5CYfV8=; b=YF4YqzJ+l3uG+FumGjMnhletPRiSxTKagXVnosCmvm7K/GcTM4CxC8uztyNeNtBeTz Uc98Lz2nGuaAxDtKe7VC3JJpCEtnWYSYRpWQFugdmK9gI5iLvYBteo4Aof80eVy1C4TT YCQJdju76WQk/W1nfJiePOJa1SF/0T9+yh8FcqIZaYtfzkoS5oq5JLlbx0GOGFkz5+nR l/0frUIXaqb+08s175lBpPrkRr4DNvqdziRwoUtWWyyvPGzbT+ll0LGE2bjSqy8ZKzKz FN9PORetJzKHBsJRkSMu0WPe5dOT4nPuyxytCI2IkaiKAy0ZGxefm13BLZoB3H8rWRoh FwHQ== X-Received: by 10.236.17.133 with SMTP id j5mr1666905yhj.77.1385554658961; Wed, 27 Nov 2013 04:17:38 -0800 (PST) Received: from blackbeast.local (75-120-65-175.dyn.centurytel.net. [75.120.65.175]) by mx.google.com with ESMTPSA id q9sm89306584yhk.16.2013.11.27.04.17.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Nov 2013 04:17:36 -0800 (PST) From: Chuck Burns To: freebsd-current@freebsd.org Subject: Re: (bsd)patch vs ports Date: Wed, 27 Nov 2013 06:17:34 -0600 Message-ID: <2069317.7t5sA85o8W@blackbeast.local> User-Agent: KMail/4.10.5 (FreeBSD/10.0-BETA3; KDE/4.10.5; amd64; ; ) In-Reply-To: <5295B9B6.1070400@FreeBSD.org> References: <5295B9B6.1070400@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 12:17:40 -0000 On Wednesday, November 27, 2013 11:21:58 AM Andriy Gapon wrote: > When building ports on head I sometimes see messages like the following > during a patch phase: > > ===> Applying FreeBSD patches for firefox-25.0_1,1 > No such line 262 in input file, ignoring > ===> Applying NSS patches > No such line 194 in input file, ignoring > No such line 658 in input file, ignoring > No such line 52 in input file, ignoring > No such line 45 in input file, ignoring > > Is this a cause for concern? > Do those messages mean that potentially important patches are not actually > applied? Well.. If it compiles, then no, those patches were probably not important. Security fixes are usually done upstream by the vendor. Honestly, it appears that someone left old patch files, and those patches may no longer be needed for firefox to compile on FreeBSD. break19 From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 13:07:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB99597E; Wed, 27 Nov 2013 13:07:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 93A802EC9; Wed, 27 Nov 2013 13:07:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rARD750g053246; Wed, 27 Nov 2013 08:07:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rARD75uU053242; Wed, 27 Nov 2013 13:07:05 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Nov 2013 13:07:05 GMT Message-Id: <201311271307.rARD75uU053242@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 13:07:06 -0000 TB --- 2013-11-27 07:20:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-27 07:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-27 07:20:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-11-27 07:20:17 - cleaning the object tree TB --- 2013-11-27 07:28:48 - /usr/local/bin/svn stat /src TB --- 2013-11-27 07:28:52 - At svn revision 258674 TB --- 2013-11-27 07:28:53 - building world TB --- 2013-11-27 07:28:53 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 07:28:53 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 07:28:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 07:28:53 - SRCCONF=/dev/null TB --- 2013-11-27 07:28:53 - TARGET=amd64 TB --- 2013-11-27 07:28:53 - TARGET_ARCH=amd64 TB --- 2013-11-27 07:28:53 - TZ=UTC TB --- 2013-11-27 07:28:53 - __MAKE_CONF=/dev/null TB --- 2013-11-27 07:28:53 - cd /src TB --- 2013-11-27 07:28:53 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Nov 27 07:28:59 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 27 10:41:58 UTC 2013 TB --- 2013-11-27 10:41:58 - generating LINT kernel config TB --- 2013-11-27 10:41:58 - cd /src/sys/amd64/conf TB --- 2013-11-27 10:41:58 - /usr/bin/make -B LINT TB --- 2013-11-27 10:41:58 - cd /src/sys/amd64/conf TB --- 2013-11-27 10:41:58 - /usr/sbin/config -m LINT TB --- 2013-11-27 10:41:58 - building LINT kernel TB --- 2013-11-27 10:41:58 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 10:41:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 10:41:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 10:41:58 - SRCCONF=/dev/null TB --- 2013-11-27 10:41:58 - TARGET=amd64 TB --- 2013-11-27 10:41:58 - TARGET_ARCH=amd64 TB --- 2013-11-27 10:41:58 - TZ=UTC TB --- 2013-11-27 10:41:58 - __MAKE_CONF=/dev/null TB --- 2013-11-27 10:41:58 - cd /src TB --- 2013-11-27 10:41:58 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 27 10:41:58 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Wed Nov 27 11:18:27 UTC 2013 TB --- 2013-11-27 11:18:27 - cd /src/sys/amd64/conf TB --- 2013-11-27 11:18:27 - /usr/sbin/config -m LINT-NOINET TB --- 2013-11-27 11:18:27 - building LINT-NOINET kernel TB --- 2013-11-27 11:18:27 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 11:18:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 11:18:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 11:18:27 - SRCCONF=/dev/null TB --- 2013-11-27 11:18:27 - TARGET=amd64 TB --- 2013-11-27 11:18:27 - TARGET_ARCH=amd64 TB --- 2013-11-27 11:18:27 - TZ=UTC TB --- 2013-11-27 11:18:27 - __MAKE_CONF=/dev/null TB --- 2013-11-27 11:18:27 - cd /src TB --- 2013-11-27 11:18:27 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Nov 27 11:18:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Wed Nov 27 11:50:46 UTC 2013 TB --- 2013-11-27 11:50:46 - cd /src/sys/amd64/conf TB --- 2013-11-27 11:50:46 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-11-27 11:50:46 - building LINT-NOINET6 kernel TB --- 2013-11-27 11:50:46 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 11:50:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 11:50:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 11:50:46 - SRCCONF=/dev/null TB --- 2013-11-27 11:50:46 - TARGET=amd64 TB --- 2013-11-27 11:50:46 - TARGET_ARCH=amd64 TB --- 2013-11-27 11:50:46 - TZ=UTC TB --- 2013-11-27 11:50:46 - __MAKE_CONF=/dev/null TB --- 2013-11-27 11:50:46 - cd /src TB --- 2013-11-27 11:50:46 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Wed Nov 27 11:50:46 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Wed Nov 27 12:23:15 UTC 2013 TB --- 2013-11-27 12:23:15 - cd /src/sys/amd64/conf TB --- 2013-11-27 12:23:15 - /usr/sbin/config -m LINT-NOIP TB --- 2013-11-27 12:23:15 - building LINT-NOIP kernel TB --- 2013-11-27 12:23:15 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 12:23:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 12:23:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 12:23:15 - SRCCONF=/dev/null TB --- 2013-11-27 12:23:15 - TARGET=amd64 TB --- 2013-11-27 12:23:15 - TARGET_ARCH=amd64 TB --- 2013-11-27 12:23:15 - TZ=UTC TB --- 2013-11-27 12:23:15 - __MAKE_CONF=/dev/null TB --- 2013-11-27 12:23:15 - cd /src TB --- 2013-11-27 12:23:15 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Wed Nov 27 12:23:15 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Wed Nov 27 12:52:38 UTC 2013 TB --- 2013-11-27 12:52:38 - cd /src/sys/amd64/conf TB --- 2013-11-27 12:52:38 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-11-27 12:52:38 - building LINT-VIMAGE kernel TB --- 2013-11-27 12:52:38 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 12:52:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 12:52:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 12:52:38 - SRCCONF=/dev/null TB --- 2013-11-27 12:52:38 - TARGET=amd64 TB --- 2013-11-27 12:52:38 - TARGET_ARCH=amd64 TB --- 2013-11-27 12:52:38 - TZ=UTC TB --- 2013-11-27 12:52:38 - __MAKE_CONF=/dev/null TB --- 2013-11-27 12:52:38 - cd /src TB --- 2013-11-27 12:52:38 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Wed Nov 27 12:52:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ /src/sys/sys/sdt.h:153:19: note: expanded from macro 'SDT_PROBE_DEFINE' struct sdt_probe sdt_##prov##_##mod##_##func##_##name[1] = { \ ^ :51:1: note: expanded from here sdt_vnet_functions_vnet_destroy_entry ^ 4 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT-VIMAGE *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-27 13:07:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-27 13:07:05 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-11-27 13:07:05 - 15909.88 user 3061.45 system 20807.46 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 13:09:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59723BBF; Wed, 27 Nov 2013 13:09:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 20FAC2F09; Wed, 27 Nov 2013 13:09:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rARD9WOw072907; Wed, 27 Nov 2013 08:09:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rARD9WoV072892; Wed, 27 Nov 2013 13:09:32 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Nov 2013 13:09:32 GMT Message-Id: <201311271309.rARD9WoV072892@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 13:09:33 -0000 TB --- 2013-11-27 07:20:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-27 07:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-27 07:20:17 - starting HEAD tinderbox run for i386/i386 TB --- 2013-11-27 07:20:17 - cleaning the object tree TB --- 2013-11-27 07:28:28 - /usr/local/bin/svn stat /src TB --- 2013-11-27 07:28:32 - At svn revision 258674 TB --- 2013-11-27 07:28:33 - building world TB --- 2013-11-27 07:28:33 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 07:28:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 07:28:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 07:28:33 - SRCCONF=/dev/null TB --- 2013-11-27 07:28:33 - TARGET=i386 TB --- 2013-11-27 07:28:33 - TARGET_ARCH=i386 TB --- 2013-11-27 07:28:33 - TZ=UTC TB --- 2013-11-27 07:28:33 - __MAKE_CONF=/dev/null TB --- 2013-11-27 07:28:33 - cd /src TB --- 2013-11-27 07:28:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Nov 27 07:28:40 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 27 10:41:58 UTC 2013 TB --- 2013-11-27 10:41:58 - generating LINT kernel config TB --- 2013-11-27 10:41:58 - cd /src/sys/i386/conf TB --- 2013-11-27 10:41:58 - /usr/bin/make -B LINT TB --- 2013-11-27 10:41:58 - cd /src/sys/i386/conf TB --- 2013-11-27 10:41:58 - /usr/sbin/config -m LINT TB --- 2013-11-27 10:41:58 - building LINT kernel TB --- 2013-11-27 10:41:58 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 10:41:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 10:41:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 10:41:58 - SRCCONF=/dev/null TB --- 2013-11-27 10:41:58 - TARGET=i386 TB --- 2013-11-27 10:41:58 - TARGET_ARCH=i386 TB --- 2013-11-27 10:41:58 - TZ=UTC TB --- 2013-11-27 10:41:58 - __MAKE_CONF=/dev/null TB --- 2013-11-27 10:41:58 - cd /src TB --- 2013-11-27 10:41:58 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 27 10:41:58 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Wed Nov 27 11:18:44 UTC 2013 TB --- 2013-11-27 11:18:44 - cd /src/sys/i386/conf TB --- 2013-11-27 11:18:44 - /usr/sbin/config -m LINT-NOINET TB --- 2013-11-27 11:18:44 - building LINT-NOINET kernel TB --- 2013-11-27 11:18:44 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 11:18:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 11:18:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 11:18:44 - SRCCONF=/dev/null TB --- 2013-11-27 11:18:44 - TARGET=i386 TB --- 2013-11-27 11:18:44 - TARGET_ARCH=i386 TB --- 2013-11-27 11:18:44 - TZ=UTC TB --- 2013-11-27 11:18:44 - __MAKE_CONF=/dev/null TB --- 2013-11-27 11:18:44 - cd /src TB --- 2013-11-27 11:18:44 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Nov 27 11:18:44 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Wed Nov 27 11:51:46 UTC 2013 TB --- 2013-11-27 11:51:46 - cd /src/sys/i386/conf TB --- 2013-11-27 11:51:46 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-11-27 11:51:46 - building LINT-NOINET6 kernel TB --- 2013-11-27 11:51:46 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 11:51:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 11:51:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 11:51:46 - SRCCONF=/dev/null TB --- 2013-11-27 11:51:46 - TARGET=i386 TB --- 2013-11-27 11:51:46 - TARGET_ARCH=i386 TB --- 2013-11-27 11:51:46 - TZ=UTC TB --- 2013-11-27 11:51:46 - __MAKE_CONF=/dev/null TB --- 2013-11-27 11:51:46 - cd /src TB --- 2013-11-27 11:51:46 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Wed Nov 27 11:51:46 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Wed Nov 27 12:24:28 UTC 2013 TB --- 2013-11-27 12:24:28 - cd /src/sys/i386/conf TB --- 2013-11-27 12:24:28 - /usr/sbin/config -m LINT-NOIP TB --- 2013-11-27 12:24:28 - building LINT-NOIP kernel TB --- 2013-11-27 12:24:28 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 12:24:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 12:24:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 12:24:28 - SRCCONF=/dev/null TB --- 2013-11-27 12:24:28 - TARGET=i386 TB --- 2013-11-27 12:24:28 - TARGET_ARCH=i386 TB --- 2013-11-27 12:24:28 - TZ=UTC TB --- 2013-11-27 12:24:28 - __MAKE_CONF=/dev/null TB --- 2013-11-27 12:24:28 - cd /src TB --- 2013-11-27 12:24:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Wed Nov 27 12:24:28 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Wed Nov 27 12:54:54 UTC 2013 TB --- 2013-11-27 12:54:54 - cd /src/sys/i386/conf TB --- 2013-11-27 12:54:54 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-11-27 12:54:54 - building LINT-VIMAGE kernel TB --- 2013-11-27 12:54:54 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 12:54:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 12:54:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 12:54:54 - SRCCONF=/dev/null TB --- 2013-11-27 12:54:54 - TARGET=i386 TB --- 2013-11-27 12:54:54 - TARGET_ARCH=i386 TB --- 2013-11-27 12:54:54 - TZ=UTC TB --- 2013-11-27 12:54:54 - __MAKE_CONF=/dev/null TB --- 2013-11-27 12:54:54 - cd /src TB --- 2013-11-27 12:54:54 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Wed Nov 27 12:54:54 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ /src/sys/sys/sdt.h:153:19: note: expanded from macro 'SDT_PROBE_DEFINE' struct sdt_probe sdt_##prov##_##mod##_##func##_##name[1] = { \ ^ :55:1: note: expanded from here sdt_vnet_functions_vnet_destroy_entry ^ 4 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT-VIMAGE *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-27 13:09:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-27 13:09:32 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-11-27 13:09:32 - 15998.63 user 3122.92 system 20954.22 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 13:59:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A917ADD; Wed, 27 Nov 2013 13:59:57 +0000 (UTC) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBADD21C7; Wed, 27 Nov 2013 13:59:56 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id ia6so4881830vcb.18 for ; Wed, 27 Nov 2013 05:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4flONFiiyjFtAtWqWzFSt59tN/nr6iQRyEewsrhzvRQ=; b=XvmojIt3YN+sKgw6T2pVq+ABN19zlVkQmnLjJB3IrW8WUtyu2FC7lLgEVEN1E6GF7v A0/uS+S4mXxoe4T2uWvbE1WGKbSzLTPTc7NKtAnmJT5uCNgWDrlZHFavTf0nN0VV0GoL GHWvdsqpjIZhOIHbgcyUQFEq39zqzmgr3SyIedb3f0dSwoqGTUWOyXTXhHfmupIN3o8Z YYB9BuWwSU0rhTEEm1NYtHPLWS2M59ZYm5ltTCsLdOUiPoso2TrntYTZS5wicQjU/KXb w97M3xecsaq7af8h04I59cA+/DSruXUtkr+w8K1fBNrcd+SP1HaPkJvd+4xChiEHCY14 svaw== MIME-Version: 1.0 X-Received: by 10.58.161.231 with SMTP id xv7mr34499445veb.2.1385560795883; Wed, 27 Nov 2013 05:59:55 -0800 (PST) Received: by 10.58.37.135 with HTTP; Wed, 27 Nov 2013 05:59:55 -0800 (PST) In-Reply-To: <201311271307.rARD75uU053242@freebsd-current.sentex.ca> References: <201311271307.rARD75uU053242@freebsd-current.sentex.ca> Date: Wed, 27 Nov 2013 08:59:55 -0500 Message-ID: Subject: Re: [head tinderbox] failure on amd64/amd64 From: Shawn Webb To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: amd64@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 13:59:57 -0000 On Wed, Nov 27, 2013 at 8:07 AM, FreeBSD Tinderbox wrote: > > >>> stage 3.2: building everything > [...] > ^ > /src/sys/sys/sdt.h:153:19: note: expanded from macro 'SDT_PROBE_DEFINE' > struct sdt_probe sdt_##prov##_##mod##_##func##_##name[1] = { > \ > ^ > :51:1: note: expanded from here > sdt_vnet_functions_vnet_destroy_entry > ^ > 4 errors generated. > *** Error code 1 > > Stop. > bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT-VIMAGE > *** Error code 1 > > Stop. > bmake: stopped in /src > *** Error code 1 > > Stop in /src. > TB --- 2013-11-27 13:07:05 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2013-11-27 13:07:05 - ERROR: failed to build LINT-VIMAGE kernel > TB --- 2013-11-27 13:07:05 - 15909.88 user 3061.45 system 20807.46 real > > > http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full > Seems like this was a typo or copy/paste error. This patch fixes it: diff --git a/sys/net/vnet.c b/sys/net/vnet.c index 977bf59..bceb2ef 100644 --- a/sys/net/vnet.c +++ b/sys/net/vnet.c @@ -216,7 +216,7 @@ SDT_PROBE_DEFINE2(vnet, functions, vnet_alloc, return, "int", "struct vnet *"); SDT_PROBE_DEFINE2(vnet, functions, vnet_destroy, entry, "int", "struct vnet *"); -SDT_PROBE_DEFINE1(vnet, functions, vnet_destroy, entry, +SDT_PROBE_DEFINE1(vnet, functions, vnet_destroy, return, "int"); #ifdef DDB From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 14:08:00 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96F15EB0; Wed, 27 Nov 2013 14:08:00 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1187F2244; Wed, 27 Nov 2013 14:07:59 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq4so6941029wib.5 for ; Wed, 27 Nov 2013 06:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5rq+W/X1O3FLpE8t/PrAUoxLEwblebttXwTfsDVvCGQ=; b=dErRQBGALLsS19tF3coW2UTULd7zPpSx1XXKWhiJhMdXXIE3WGWb8iA7uIRCbDTxuP mux0sPCKVWRDt44AkmbzLvUEMQUvliKT8f7FDZE8d8WaMbztVzMwNqE6B7+TQDi2pOHA fgeJp76oYGvpRis0dde2uO4WXAlJwUzEm4TUWKbVOB5CgT7Ii2MJH/8ueHS7o4MlD1Th TlOnPWvSDFU7x3RRZ+K5QXY3J6QJO1WdFNv4gg1ZfSFa/ZEgeTMjfz3/NPXmLnjQ6FFz cjWAaOVC5f34LhjA2oHIEv1D1UemRo/ucUNW8iu7ocDDLEPlKLcaJhq5BvuX/dGN63ag F8fA== MIME-Version: 1.0 X-Received: by 10.194.216.38 with SMTP id on6mr32243195wjc.14.1385561278502; Wed, 27 Nov 2013 06:07:58 -0800 (PST) Received: by 10.217.0.143 with HTTP; Wed, 27 Nov 2013 06:07:58 -0800 (PST) In-Reply-To: References: <201311271307.rARD75uU053242@freebsd-current.sentex.ca> Date: Wed, 27 Nov 2013 18:07:58 +0400 Message-ID: Subject: Re: [head tinderbox] failure on amd64/amd64 From: Sergey Kandaurov To: Shawn Webb Content-Type: text/plain; charset=ISO-8859-1 Cc: amd64@freebsd.org, current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 14:08:00 -0000 On 27 November 2013 17:59, Shawn Webb wrote: > On Wed, Nov 27, 2013 at 8:07 AM, FreeBSD Tinderbox wrote: >> >> >>> stage 3.2: building everything >> [...] >> ^ >> /src/sys/sys/sdt.h:153:19: note: expanded from macro 'SDT_PROBE_DEFINE' >> struct sdt_probe sdt_##prov##_##mod##_##func##_##name[1] = { >> \ >> ^ >> :51:1: note: expanded from here >> sdt_vnet_functions_vnet_destroy_entry >> ^ >> 4 errors generated. >> *** Error code 1 >> >> Stop. >> bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT-VIMAGE >> *** Error code 1 >> >> Stop. >> bmake: stopped in /src >> *** Error code 1 >> >> Stop in /src. >> TB --- 2013-11-27 13:07:05 - WARNING: /usr/bin/make returned exit code 1 >> TB --- 2013-11-27 13:07:05 - ERROR: failed to build LINT-VIMAGE kernel >> TB --- 2013-11-27 13:07:05 - 15909.88 user 3061.45 system 20807.46 real >> >> >> http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full >> > > Seems like this was a typo or copy/paste error. This patch fixes it: > This should be fixed in r258675. Tinderbox is lagging behind. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 15:20:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC06C28E for ; Wed, 27 Nov 2013 15:20:33 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 787282655 for ; Wed, 27 Nov 2013 15:20:32 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rARFKRHM031446 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Nov 2013 07:20:30 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52960DB5.3090209@freebsd.org> Date: Wed, 27 Nov 2013 23:20:21 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Harald Schmalzbauer , freebsd-current@freebsd.org Subject: Re: Feature request: sticky bit inheritance References: <5295DFAD.5070402@omnilan.de> In-Reply-To: <5295DFAD.5070402@omnilan.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 15:20:33 -0000 On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote: > Hello, > > ever since I took a FreeBSD machine into production, acting as any kind > of file server, I have to work arround the problem, that write access to > a directory implies unlinking (deleting) directory contents. not sure I fully understand what you mean by that.. Do you mean write access implies delete access? yes.. This can be modified with the nounlink flag. (man 2 chflags) From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 15:29:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40F2F7B1 for ; Wed, 27 Nov 2013 15:29:15 +0000 (UTC) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 064A126B1 for ; Wed, 27 Nov 2013 15:29:14 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id c14so5421690vea.28 for ; Wed, 27 Nov 2013 07:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Fk7HJ1rroncxKyp9TdG3paZ13Ls1KYgOWy7xzE25RUI=; b=c3bIQ7oZC8AqoMcdL3JZHSxEsoISAPFm5p0aEuG+TVCsqXLGbqHmWQvOI63RvflEeP jntrJOLf6SGZnrzPyU1881hO9MdfidJATl60t2qCUmkehMx6uBwP2HfrjgDieCBkIbBs ZgOhb1T37+CzXhmQ+vfiXNNJG917QBcqFknHWzcWYQHRCTkGreKwIBE3kDFQB90VlSc5 LEbqnFFwgOhAeshGMkBZB9lb5OMxeKibhgVIkpWuhISCajYfLMvxA32QVtIRz2G+tSPu gpNosH+Udwm1ejmvgPUUFQTSrDts3pxsRub6NJX31XJPSovMPOmNgGXTcifk9FhixzGp 4XmA== MIME-Version: 1.0 X-Received: by 10.58.11.73 with SMTP id o9mr34749416veb.8.1385566154099; Wed, 27 Nov 2013 07:29:14 -0800 (PST) Received: by 10.221.63.6 with HTTP; Wed, 27 Nov 2013 07:29:14 -0800 (PST) Date: Wed, 27 Nov 2013 16:29:14 +0100 Message-ID: Subject: [request] ntp upgrade From: Cristiano Deana To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 15:29:15 -0000 Hi, is it possible to include in base system of the upcoming 10.0 the new version of ntp (4.2.7 instead of 4.2.4)? There is a bug in older versions (< 4.2.7) who allows attacker use an ntp server to DDoS. This has been corrected in new version: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks This attack seems to be increasing in the last few weeks. net/ntp-devel is Ok. Thank you, sorry for my basic english. -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 16:06:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D28A7375 for ; Wed, 27 Nov 2013 16:06:20 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6227F28A4 for ; Wed, 27 Nov 2013 16:06:20 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id ec20so5452222lab.1 for ; Wed, 27 Nov 2013 08:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=24zKNc/THLK7n8+9lVsxivIfNrtdZVZT7j4zt5plEnA=; b=CldyDR8gqFg0H8WTvaRNFgm5KUlcaeW1Z9IAj5CN+csecOr7SQ/maQc9ViLY2DTj6b O3cXXNj5+SU/r/ge9/8ihwXCBryeh8CIbXVqULY6LxlJrqa55e1K3N0nvP9JR1g+2dRd xOcQfAtTf5fre99ilo6/mARKE7QyyP2WWgrn1HxclUlMMDKPbhc0Ba2Z1p9DhfkddrFy VnpC0kLMpcSLpnqvKgU266GjnM6UKdGokCjyeWv6GwoeZIzchaLSSKT+U5N7YethKPbw mzAtAcz3fAZ+RHEd4J5UlEu8sINxT+QVHm1oTnQ7FB73GxbicvqX5QZnhzcGdKD1tIyF fbtA== MIME-Version: 1.0 X-Received: by 10.152.44.225 with SMTP id h1mr13759347lam.22.1385568378369; Wed, 27 Nov 2013 08:06:18 -0800 (PST) Received: by 10.112.133.69 with HTTP; Wed, 27 Nov 2013 08:06:18 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Nov 2013 16:06:18 +0000 Message-ID: Subject: Re: [request] ntp upgrade From: Tom Evans To: Cristiano Deana Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 16:06:20 -0000 On Wed, Nov 27, 2013 at 3:29 PM, Cristiano Deana wrote: > Hi, > > is it possible to include in base system of the upcoming 10.0 the new > version of ntp (4.2.7 instead of 4.2.4)? > > There is a bug in older versions (< 4.2.7) who allows attacker use an ntp > server to DDoS. This has been corrected in new version: > https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks > > This attack seems to be increasing in the last few weeks. > > net/ntp-devel is Ok. > > Thank you, sorry for my basic english. > ntp 4.2.4p8 isn't vulnerable. http://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html The reflection attack is the first in the list, 4.2.4p7 and below are affected. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 16:10:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25FAA94F for ; Wed, 27 Nov 2013 16:10:39 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D1F128FF for ; Wed, 27 Nov 2013 16:10:38 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ey16so2291879wid.0 for ; Wed, 27 Nov 2013 08:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6zuziLkGTHaLjAgavE7TpMn6fduT74zK7CQHgvGkf94=; b=CwexzBLwTJVqXfUkGiw61uOtIL0Hw/pAVLmz4L0N14WXm7tX6stgTBw0bR2TfHxX+h iJp5J7f6AMGh97ndm09CTRF2fTOt2NU6wG26dox97fX+IAYvlY+8tdfYdqqG1zwgf6zu re2s5W+97VcRfxqw/cXeHaFBW6YCJ1r8ZvDl7IH6Ry/FFqOA4CLh3epv1/0V/CCE+RWF T4vW1gqMHupnBByQhsDBN7TnU4a9PAnBPQQrXxIzTUeTAwTHscsyY25MfBVZgqNboC2D ak5UPFYg8vE0G/QoXxlMqkztuNJjYPCB+me6+r5+2waBqOZxvpSMMjCs7QKwlk930bws eecQ== MIME-Version: 1.0 X-Received: by 10.180.221.38 with SMTP id qb6mr23115408wic.8.1385568637068; Wed, 27 Nov 2013 08:10:37 -0800 (PST) Received: by 10.194.152.99 with HTTP; Wed, 27 Nov 2013 08:10:37 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Nov 2013 17:10:37 +0100 Message-ID: Subject: Re: [request] ntp upgrade From: Cristiano Deana To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 16:10:39 -0000 On Wed, Nov 27, 2013 at 5:06 PM, Tom Evans wrote: > > There is a bug in older versions (< 4.2.7) who allows attacker use an ntp > > server to DDoS. This has been corrected in new version: > > https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks > > > > This attack seems to be increasing in the last few weeks. > > > > net/ntp-devel is Ok. > > > ntp 4.2.4p8 isn't vulnerable. > > http://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html > > The reflection attack is the first in the list, 4.2.4p7 and below are > affected. Thank you, Tom for your quick reply. That is not the same bug. I had two ntpd with 4.2.4p8 used the last days to DDoS. I found the link below, used net/ntp-devel and the abuse was gone. -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 16:17:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B93BACC; Wed, 27 Nov 2013 16:17:45 +0000 (UTC) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C0FEC2961; Wed, 27 Nov 2013 16:17:44 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id rARGHf7O005612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Nov 2013 17:17:41 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <52961B25.3020109@omnilan.de> Date: Wed, 27 Nov 2013 17:17:41 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Julian Elischer Subject: Re: Feature request: sticky bit inheritance References: <5295DFAD.5070402@omnilan.de> <52960DB5.3090209@freebsd.org> In-Reply-To: <52960DB5.3090209@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7BB3F8551529996BE7A1F7A5" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 16:17:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7BB3F8551529996BE7A1F7A5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Julian Elischer's Nachricht vom 27.11.2013 16:20 (localti= me): > On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote: >> Hello, >> >> ever since I took a FreeBSD machine into production, acting as any kin= d >> of file server, I have to work arround the problem, that write access = to >> a directory implies unlinking (deleting) directory contents. > not sure I fully understand what you mean by that.. > Do you mean write access implies delete access? yes.. > > This can be modified with the nounlink flag. The uunlink flags also prohibits the owner to delete his files as far as I know. I want to prohibt users from deleting =E2=80=9Cforeign=E2=80=9D f= iles, even if the user has write access to the parent directory (and I wanted to explain that I don't understand why anybody would want that a user with write access to a directory can delete files on which the user doesn't have write access). The sticky bit exactly does what I need (and should be the default behaviour in my opinion). But my problem is that the stick bit must be added to each single directory after creation, it's not inherited. I'd need every child directory of directories, who have the sticky bit set, also to have the sticky bit. The same behaviour as with the gid =E2=80= =93 it's the same as the parent has for new directories. Thanks, -Harry --------------enig7BB3F8551529996BE7A1F7A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlKWGyUACgkQLDqVQ9VXb8gm0ACgwEfrzXq2Os1DleK4thBC7ZWN +FUAoMscC2xD4BW/LXXH9+a0+wD7hxIM =5ZTM -----END PGP SIGNATURE----- --------------enig7BB3F8551529996BE7A1F7A5-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 16:18:57 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0301CB8; Wed, 27 Nov 2013 16:18:56 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1382971; Wed, 27 Nov 2013 16:18:55 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA08413; Wed, 27 Nov 2013 18:18:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Vlhp8-0005kS-T4; Wed, 27 Nov 2013 18:18:46 +0200 Message-ID: <52961B2E.1080602@FreeBSD.org> Date: Wed, 27 Nov 2013 18:17:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org, FreeBSD Current , freebsd-fs@FreeBSD.org Subject: [HEADSUP!!!] do not upgrade to or past r258632 if you use ZFS + TRIM References: <201311260957.rAQ9vF6d004168@svn.freebsd.org> In-Reply-To: <201311260957.rAQ9vF6d004168@svn.freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 16:18:57 -0000 on 26/11/2013 11:57 Andriy Gapon said the following: > Author: avg > Date: Tue Nov 26 09:57:14 2013 > New Revision: 258632 > URL: http://svnweb.freebsd.org/changeset/base/258632 > > Log: > MFV r255255: 4045 zfs write throttle & i/o scheduler performance work > > illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e > > Please note the following changes: > - zio_ioctl has lost its priority parameter and now TRIM is executed > with 'now' priority > - some knobs are gone and some new knobs are added; not all of them are > exposed as tunables / sysctls yet > > MFC after: 10 days > Sponsored by: HybridCluster [merge] I think that I've introduced a very serious bug when merging this change. Please do not upgrade to this revision if you use ZFS with SSDs and have TRIM support enabled. If you have already upgraded, please disable TRIM support ASAP and roll back to a previous version of kernel and then check integrity of your pools. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 16:55:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C843D8F1 for ; Wed, 27 Nov 2013 16:55:07 +0000 (UTC) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 912E52B3A for ; Wed, 27 Nov 2013 16:55:07 +0000 (UTC) Received: by mail-yh0-f41.google.com with SMTP id f11so5242616yha.0 for ; Wed, 27 Nov 2013 08:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=++yLhZ6bwoft92BWdO12Lqll6Y793pSN1lJnR7q/ghc=; b=NVy0qEFAVUeHje6p97q/9WtLhy+szQBz5BU/zxGpl1IgVXtqkFZAnBfplWDSRsdgSJ QYrw7AWfXyH7eNQy6e3e7BfZPpilNJ33vocoWzKIyxdwrcL7N/oy/qvlLjsjh7ZTpuID QpiC/lgY/nORqohHLi8Ul8HFXqDie/cKCUox+kgeAkKPvVMQGi4LHInOKuZEmYj6sMAK ntl8Lc8ID8ghADdL9M5dpd5XBzPz8xGIY6q3oF4Nm0exf9DgpNwoARBrjlEY+Grq2U0M AUR2yVB0spWhBgjnPHysJvwOzhDI9I2GhCHhC6bUFt8VapeaRmN0Qngwx+HOwRbDtk8n y/rQ== X-Received: by 10.236.113.237 with SMTP id a73mr838835yhh.147.1385571306781; Wed, 27 Nov 2013 08:55:06 -0800 (PST) Received: from lumiwa.farms.net (d-ptld-bng1-71-161-118-183.ngn.east.myfairpoint.net. [71.161.118.183]) by mx.google.com with ESMTPSA id h66sm33485268yhb.7.2013.11.27.08.55.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Nov 2013 08:55:05 -0800 (PST) From: Ajtim To: freebsd-current@freebsd.org Subject: warning Date: Wed, 27 Nov 2013 11:55:01 -0500 Message-ID: <3949129.efd2ojFSgk@lumiwa.farms.net> User-Agent: KMail/4.11.3 (FreeBSD/10.0-BETA3; KDE/4.11.3; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 16:55:07 -0000 OS: FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 When I boot a computer I got one warning: /etc/rc: WARNING: $tcsd_enable is not set properly I don't now on which setting is this warning related. My rc.conf looks like: hostname="blabla" ifconfig_bge0="DHCP" ntpd_enable="YES" powerd_enable="YES" dumpdev="NO" pf_enable="YES" pflog_enable="YES" update_motd="NO" dbus_enable="YES" hald_enable="YES" saver="green" blanktime="600" webcamd_enable="YES" linux_enable="YES" cupsd_enable="YES" Thanks in advance. -- Mitja ------- http://www.redbubble.com/people.lumiwa From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 16:57:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89D60A1F for ; Wed, 27 Nov 2013 16:57:06 +0000 (UTC) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 525B32B52 for ; Wed, 27 Nov 2013 16:57:06 +0000 (UTC) Received: by mail-yh0-f51.google.com with SMTP id c41so3664399yho.10 for ; Wed, 27 Nov 2013 08:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=7S8xkwbT6l/2x0NzxVsk7JdL4amBnZlsoyNbsJZmb6o=; b=nqvqf8On2WBHdCCOmR3NEHoBkgTt83M7eBqUa+vx4v8vo300O79whHZJXTfUx4cUJL 7y0xVfEIoyN32PKcAdHKBf/h9Q4xsWcigGxJzReXG70lPF5d3gG+iyqfxTDdFBN7BhnM /tCyPc9794sWbbc7D4g5FiCeRJOqQ6KfjunOrphbqUuYHay+NAOWAyR+eYwZpTZ57nxe f588JFu4hBtp+UAhdrXWb/2O54pbfUnf6Z9VmSHPprqnQ/6Ryfkpk34mDLvl2TpZDl23 09rVtLwILqBAJ4I0oWUMaKvdWdqWLfq4aXYQbZ5ynZQny6e3yMdTQ5nhvzG44up/JNk9 IVlA== X-Received: by 10.236.85.237 with SMTP id u73mr2930194yhe.67.1385571425544; Wed, 27 Nov 2013 08:57:05 -0800 (PST) Received: from lumiwa.farms.net (d-ptld-bng1-71-161-118-183.ngn.east.myfairpoint.net. [71.161.118.183]) by mx.google.com with ESMTPSA id m29sm89397436yho.14.2013.11.27.08.57.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Nov 2013 08:57:04 -0800 (PST) From: Ajtim To: freebsd-current@freebsd.org Subject: python 2.7 Date: Wed, 27 Nov 2013 11:57:02 -0500 Message-ID: <2273061.X8BR8QFKds@lumiwa.farms.net> User-Agent: KMail/4.11.3 (FreeBSD/10.0-BETA3; KDE/4.11.3; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 16:57:06 -0000 OS: FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 I have all the time python related warnings: WARNING pid 1615 (python2.7): ioctl sign-extension ioctl ffffffff80087467 WARNING pid 1617 (python2.7): ioctl sign-extension ioctl ffffffff80087467 Thank you. -- Mitja ------- http://www.redbubble.com/people.lumiwa From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 17:18:34 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E021123D; Wed, 27 Nov 2013 17:18:34 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 25BC62C4D; Wed, 27 Nov 2013 17:18:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rARHISmh033932; Wed, 27 Nov 2013 19:18:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rARHISmh033932 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rARHISdQ033931; Wed, 27 Nov 2013 19:18:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Nov 2013 19:18:28 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131127171828.GZ59496@kib.kiev.ua> References: <201311271041.rARAfUP2040781@gw.catspoiler.org> <201311271049.rARAnCum040847@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kfZazuDJ3NZxT/6u" Content-Disposition: inline In-Reply-To: <201311271049.rARAnCum040847@gw.catspoiler.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 17:18:34 -0000 --kfZazuDJ3NZxT/6u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: > What is the instruction at cpu_switch+0x9b ? --kfZazuDJ3NZxT/6u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSliljAAoJEJDCuSvBvK1BGBIQAIpdiNEK8itFXfVXLANoWjy8 mVhKrxd8XPaWaExJKMUUwQ2527zba4n6gvtw0EfBXzffhO42qTp7WGdsO3eOi9z3 KgOEKefCPAlcAJ+CLYw0+I3FdD6UrOtF8Ad9H+pu116webm+BnpZNJ8MIP6slryO vNnvYIAncOh8JgPn+LzAtYGR2+zgx6lmAE69t5URTwGi/hCLqoS9KPNjHEQe+BWU Z2dK9XLX1vVXQOb7/Y1PNwvg0LLjPJyNb/sGYHEGQZdE1ydV6V1fL4Em7VldaS3L qMSJLgp2sTHMQsrliW0Bjq0HFcUJOT3ExolXivtN/mUjdVK+80AVcWTlq9VeP1an bi9cEsHg3RdXABS4J3gI7GNaTeMQnpFXAC8xweZWxgSO1QgVBXrQ3ByCUQXvhcj0 acxYSWOzdKLaTsxTHiXybGKYGNZHUXE97xXDukCVOiVn+JuAN/Drxb7U636coarx CUAXWgfnnPIHSKU88PyCb6tDlqqceX3U9hzCfiOWRUc0uhMWoEIiK/L2UFZePk6S YJgjyhx2H2yqnOZqNgBU17saU4yV/YYxRywpvthbmh4qNtuwBRylK8JSvydb4+kP Ni+j/rbGdbc4X0E7k6m6mJgulkDjyf0XX4PLxq9kVWqVKcmYGoo6Yr0kMm4dO2PB IYliCMxBgESBgikVkF+z =GU2A -----END PGP SIGNATURE----- --kfZazuDJ3NZxT/6u-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 17:21:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7707944C for ; Wed, 27 Nov 2013 17:21:08 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 070CC2C95 for ; Wed, 27 Nov 2013 17:21:07 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id eo20so5548532lab.28 for ; Wed, 27 Nov 2013 09:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HrLqsS9T/sfNDBloP4WiS4FpGxRiLhjVsVj69g7dmEM=; b=qnLIF6P9D42IZ9rEJ+Vrl6pAVRPwYFR1MgaViFtDimENGfN02P/HPSzzZ7dfWNKxVX UFDAjHqG5L4R0Od1nCxh60klAJlBRRr500VwaKu9kb1SCTBz0p79KJ5Mhk+xq/vAFIQ6 P5mdLnyA/5ql4opTkMeoYVUIj796ULQ/ewu+fyg48LikMxxdV8rbaKSW3ah61aKgzG2o RCFAL2HgYJspAvuDs0ZK+hWVEjatuBfnIrs3mmDqVgS9tScMNT9HLEcUMELhO2KHwJNB NBKBql2wCh0Aersq1A63KBqw4RdYDs7e9uarMn2d2Ou37mub5G3KJ4pA435xUgu2MNc/ SsSQ== MIME-Version: 1.0 X-Received: by 10.112.135.67 with SMTP id pq3mr18200lbb.65.1385572865825; Wed, 27 Nov 2013 09:21:05 -0800 (PST) Received: by 10.112.133.69 with HTTP; Wed, 27 Nov 2013 09:21:05 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Nov 2013 17:21:05 +0000 Message-ID: Subject: Re: [request] ntp upgrade From: Tom Evans To: Cristiano Deana Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 17:21:08 -0000 On Wed, Nov 27, 2013 at 4:10 PM, Cristiano Deana wrote: > On Wed, Nov 27, 2013 at 5:06 PM, Tom Evans wrote: > >> >> > There is a bug in older versions (< 4.2.7) who allows attacker use an >> > ntp >> > server to DDoS. This has been corrected in new version: >> > https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks >> > >> > This attack seems to be increasing in the last few weeks. >> > >> > net/ntp-devel is Ok. >> >> >> ntp 4.2.4p8 isn't vulnerable. >> >> http://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html >> >> The reflection attack is the first in the list, 4.2.4p7 and below are >> affected. > > > > Thank you, Tom for your quick reply. > > That is not the same bug. I had two ntpd with 4.2.4p8 used the last days to > DDoS. I found the link below, used net/ntp-devel and the abuse was gone. > Does it have a CVE? The article is low on content :( Cheers Tom From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 17:41:45 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33AC1749 for ; Wed, 27 Nov 2013 17:41:45 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0200C2D8E for ; Wed, 27 Nov 2013 17:41:44 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rARHfa66042131; Wed, 27 Nov 2013 09:41:40 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311271741.rARHfa66042131@gw.catspoiler.org> Date: Wed, 27 Nov 2013 09:41:36 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131127171828.GZ59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 17:41:45 -0000 On 27 Nov, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: >> > > What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax This machine is running in i386 mode. From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 17:57:53 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBE0AB0E; Wed, 27 Nov 2013 17:57:53 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 173982E22; Wed, 27 Nov 2013 17:57:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rARHvhQI042401; Wed, 27 Nov 2013 19:57:43 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rARHvhQI042401 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rARHvhCb042400; Wed, 27 Nov 2013 19:57:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Nov 2013 19:57:43 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131127175743.GA59496@kib.kiev.ua> References: <20131127171828.GZ59496@kib.kiev.ua> <201311271741.rARHfa66042131@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ur//+kVWxE8O2xb8" Content-Disposition: inline In-Reply-To: <201311271741.rARHfa66042131@gw.catspoiler.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 17:57:53 -0000 --Ur//+kVWxE8O2xb8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: > On 27 Nov, Konstantin Belousov wrote: > > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: > >> > >=20 > > What is the instruction at cpu_switch+0x9b ? >=20 > movl 0x8(%edx),%eax So it is line 176 in swtch.s. Is machine still in ddb, or did you obtained the core ? If yes, please print out the content of words at 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at address (*) + 8. > This machine is running in i386 mode. Yes, this is clear from the backtraces. --Ur//+kVWxE8O2xb8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSljKWAAoJEJDCuSvBvK1BXFQP/1kZ96z5/KJjS92VKNDB+VgE M9uXAhh+zkesE3vdou23FPTvEHjJlhdjLk128FFHFEpmRL4/X3/jIyFQGDFNpSBc ZCQRykTmEMPs+bF9KJVYtbDSyo74Xcc8qPkEcDqQfkvvmJKvYckM90V7POxnqxag 4PVBPc8DvJugSpvtepUlizU514fZkm3va49vxpgWMgJs+zr9ESqflu1i2iqOPwYA 47FRAiWMAuebchVbufIKxPaptwvC+4MD8bGmx+Cn3nEIVJciwQfx3we+GLkC1QL1 4cpZIPfxbFqVci6NASyZ2DGc6tozqiPpvtlU4USCGqh861f8QRUkA+Cbofu0QhyB ZSO8+ZJC/4E5PzXEBEnKOxd6CetMkjJo9uIvRv5AGlborY75RzhMmgQ5nqHn5NY2 QhyU4bat/hEHHH70RKGW/Z+xsrbgUu6oL/zIyB3NeyY2thpj/HX14sW24DpHe/LQ h3cONxLifAVU9MW7qtYeqkDLwHHSwmKdauASxNT5DUz42UmT90I2Q5XsF3OiIKD/ aVq+4Kx4sjIlLfKt/LcMpq+65Uj29n8euOyRaOzIbsTxqkjrpWyCS4ZOaSjZThpq E1Ul4iikMfBYceAqWclXcqaCCluv5UKNMMagahrt+xgNGTI2oP01XvtXqg/FM6f0 D0Ay4Ij1kRkxzUatyM4u =12Zs -----END PGP SIGNATURE----- --Ur//+kVWxE8O2xb8-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 18:33:38 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E61C594 for ; Wed, 27 Nov 2013 18:33:38 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6BE0A204A for ; Wed, 27 Nov 2013 18:33:38 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rARIXU8S042240; Wed, 27 Nov 2013 10:33:34 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311271833.rARIXU8S042240@gw.catspoiler.org> Date: Wed, 27 Nov 2013 10:33:30 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131127175743.GA59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 18:33:38 -0000 On 27 Nov, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: >> On 27 Nov, Konstantin Belousov wrote: >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: >> >> >> > >> > What is the instruction at cpu_switch+0x9b ? >> >> movl 0x8(%edx),%eax > So it is line 176 in swtch.s. Is machine still in ddb, or did you > obtained the core ? If yes, please print out the content of words at > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at > address (*) + 8. It is still in ddb. , though not in the above order. From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 18:43:13 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95B4C73C; Wed, 27 Nov 2013 18:43:13 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57D1E20C6; Wed, 27 Nov 2013 18:43:13 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rARIh2V4015040; Wed, 27 Nov 2013 10:43:02 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rARIh2LX015039; Wed, 27 Nov 2013 10:43:02 -0800 (PST) (envelope-from sgk) Date: Wed, 27 Nov 2013 10:43:02 -0800 From: Steve Kargl To: Jan Henrik Sylvester Subject: Re: Re: libc++ vs. libstdc++ usage in the ports tree Message-ID: <20131127184302.GA15006@troutmask.apl.washington.edu> References: <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> <20131114144555.GA22093@troutmask.apl.washington.edu> <52963A90.4000201@janh.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52963A90.4000201@janh.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dimitry Andric , David Chisnall , Andriy Gapon , Maho Nakata , FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 18:43:13 -0000 On Wed, Nov 27, 2013 at 07:31:44PM +0100, Jan Henrik Sylvester wrote: > On 11/14/2013 15:45, Steve Kargl wrote: > > > > And in practice, it is broken. > > > > http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html > > > > QED > > Trying to migrate to 10, I would like to keep octave. Have you found > anything new? Having build the port and all dependencies with standard > options, octave is segfaulting for me, too. Anyhow, I can run octave with: > > env LD_PRELOAD=/usr/lib/libc++.so.1 octave > Unfortunately, you need to add "USE_GCC=any" to math/octave/Makefile, and rebuild it. You theni need to run "ldd -a | more" and search for shared libraries that are linked against both libc++ and libstdc++. Then, add "USE_GCC=any" to those ports' Makefile and recompile. I recall at least 4 that needed to be rebuilt, but only remember fltk and libgraphite2. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 18:31:54 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EE2049A; Wed, 27 Nov 2013 18:31:54 +0000 (UTC) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9AD72039; Wed, 27 Nov 2013 18:31:52 +0000 (UTC) Received: from pc1111.math.uni-hamburg.de (pc1111.math.uni-hamburg.de [134.100.220.119]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MYaEY-1W7CfU0GDC-00VQK1; Wed, 27 Nov 2013 19:31:50 +0100 Message-ID: <52963A90.4000201@janh.de> Date: Wed, 27 Nov 2013 19:31:44 +0100 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Steve Kargl Subject: Re: Re: libc++ vs. libstdc++ usage in the ports tree References: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> <20131114144555.GA22093@troutmask.apl.washington.edu> In-Reply-To: <20131114144555.GA22093@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:JdZ5Eu3sfmoxrw3NNX8uc0gyPbZwIFb3cZVxGYwtmt+ t3PI8a3ti5nM6bVpSFfxyrTXzOOUw2FV76iuZ7DKun6N1X3nPd g2FT26Z7NiVzXv7kAAB08zlfOC0lcxnX+re14Kipx/4qsUHwuQ JPLTWrNMY5Ulq4xlfBfGcZ+eYYYq4BvMGMiWZu56Uxg+MuEOw1 7kjBf+XSDmh/vQ9EzgHZsXyC3ml1mJvifH748O514IvqYfR4R3 BYJGzP52BGKJWCOYq4qhtpCZoXpQjpVtd/CHJTj/pS8T2bssqu NQCzL2S97JAw++Qwq/MsiAv8qOc3/SbcCrP8Ioh1Q/Mn3dDlOA 7m5mK5kg+JW3eU1niknw= X-Mailman-Approved-At: Wed, 27 Nov 2013 18:49:06 +0000 Cc: Dimitry Andric , David Chisnall , Andriy Gapon , Maho Nakata , FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 18:31:54 -0000 On 11/14/2013 15:45, Steve Kargl wrote: > On Thu, Nov 14, 2013 at 09:54:52AM +0000, David Chisnall wrote: >> On 13 Nov 2013, at 19:40, Dimitry Andric wrote: >> >>> On the other hand, different C++ standard libraries simply cannot be >>> mixed. The internal implementations are usually completely different. >>> This is not really news at all, certainly not to the ports people. :-) >> >> That said, it should still be possible to mix them in different >> libraries. The constraint from the wiki still applies: if you >> don't use STL types at library boundaries, then it should still >> work. If you do, then the libc++ and libstdc++ symbols will be >> mangled differently and so you will get link-time errors. >> >> In theory, if it links it should run... >> > > And in practice, it is broken. > > http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html > > QED Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. Cheers, Jan Henrik From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 18:50:30 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B5CFB3A; Wed, 27 Nov 2013 18:50:30 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 94296211F; Wed, 27 Nov 2013 18:50:28 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rARIoH8V053231; Wed, 27 Nov 2013 20:50:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rARIoH8V053231 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rARIoHDv053229; Wed, 27 Nov 2013 20:50:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Nov 2013 20:50:17 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131127185017.GC59496@kib.kiev.ua> References: <20131127175743.GA59496@kib.kiev.ua> <201311271833.rARIXU8S042240@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PFevkc5XKN5n4o6D" Content-Disposition: inline In-Reply-To: <201311271833.rARIXU8S042240@gw.catspoiler.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 18:50:30 -0000 --PFevkc5XKN5n4o6D Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: > On 27 Nov, Konstantin Belousov wrote: > > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: > >> On 27 Nov, Konstantin Belousov wrote: > >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: > >> >> > >> >=20 > >> > What is the instruction at cpu_switch+0x9b ? > >>=20 > >> movl 0x8(%edx),%eax > > So it is line 176 in swtch.s. Is machine still in ddb, or did you > > obtained the core ? If yes, please print out the content of words at > > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at > > address (*) + 8. >=20 > It is still in ddb. >=20 > , though not in > the above order. Uhm, sorry, I mistyped the last part of the instructions. The new thread pointer is 0xd2f4e000, there is nothing incriminating. Please print the word at 0xd2f4e000+0x254 =3D=3D 0xd2f4e254, which would be the address of the new thread pcb. It is load from the pcb + 8 which faults. --PFevkc5XKN5n4o6D Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlj7oAAoJEJDCuSvBvK1BCkAP/AjbBoO9DPS/MIy5guLp1pKk xypBN2YzI5qil79ZZBG8FRG+IKgYPub/SjhYDJ6WUaRQ1gKeLeU2NqmDwZja2Lq1 Jkd3EHTvxddyWOWLxg0OEUDwxiQ7x9viXg1DZJ9ulsl2QG99yUWCy+FPTcqrhd8P LJVJhe0p1pVaHv7WpVdJrpApt74VmT3SQsmFaeNOPDyf1L0LcACWAmks51V29vJQ TEvqo6Xz35h9UnyscDSpb1+MQaXkQS4iweWpE1tJaHVFzHEwfvJom/qJ2etQ6bRH phKxRsbUNId9LIdqpDgSgPCXV2ZG5KNfn/4QfCathA9beLmCyIKmmtTQmfq9QZJ2 LvLtO+QxH7gGDI4Pu+zU3xmXnPfw3SizFUr48fFK2b2X7ghSbQSJ5taj0CgIG2eT xERdmwVoCgSEYPYG5OemPAjIVWSoEDJsGn+ckVc6qnabGVJyy89fJ7rePFFJl6A0 g9puDwRy7ybUkf3ux8T9P6OZfVIMJuBKsKjQ2pm/F7J0ZSr9HtVoRUPO5tz1j+iU bADxTs+Rh1I2Tze58qAZ449TRxBVYQRrlggKxMHMTv1au2qgjytDV+daV2UexudE nh8BMnNGJxYQNn3w3cRw58Jdet8ZS5bqxGD6fUFUS5HWPht9/wN943/NhI9z56ZX 7FJAhTB8NFVG6yq2JiWl =nw7y -----END PGP SIGNATURE----- --PFevkc5XKN5n4o6D-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 19:03:06 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17861EFC for ; Wed, 27 Nov 2013 19:03:06 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0B0321F0 for ; Wed, 27 Nov 2013 19:03:05 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rARJ2v6u042303; Wed, 27 Nov 2013 11:03:01 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311271903.rARJ2v6u042303@gw.catspoiler.org> Date: Wed, 27 Nov 2013 11:02:57 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131127185017.GC59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 19:03:06 -0000 On 27 Nov, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: >> On 27 Nov, Konstantin Belousov wrote: >> > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: >> >> On 27 Nov, Konstantin Belousov wrote: >> >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: >> >> >> >> >> > >> >> > What is the instruction at cpu_switch+0x9b ? >> >> >> >> movl 0x8(%edx),%eax >> > So it is line 176 in swtch.s. Is machine still in ddb, or did you >> > obtained the core ? If yes, please print out the content of words at >> > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at >> > address (*) + 8. >> >> It is still in ddb. >> >> , though not in >> the above order. > Uhm, sorry, I mistyped the last part of the instructions. > > The new thread pointer is 0xd2f4e000, there is nothing incriminating. > Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be > the address of the new thread pcb. It is load from the pcb + 8 which > faults. 0xf3d44d60 From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 19:03:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ABCD6A for ; Wed, 27 Nov 2013 19:03:13 +0000 (UTC) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6119921F5 for ; Wed, 27 Nov 2013 19:03:13 +0000 (UTC) Received: by mail-yh0-f50.google.com with SMTP id b6so5474179yha.9 for ; Wed, 27 Nov 2013 11:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:content-type; bh=Qcb6456Lrv7fvJqVRUwQZkPrPnyPqT5gTavCghgHtCY=; b=ycrabq1WHfn8m0kkEH8y7fqRTwHSEn8EYW5x7oOV1Igm8YKC7mNHYu1AkiiAkjHRxy sU15gyF4kVkWt5TwugkMwjkAaSr2XX79mIc58fBDigVdkgIjLloYX4qoS72GzZWnhZgv VtLGgXNxrde2EbRm7HGQ+8f1SZ2DBDa//U+Ua02Eky1FDb5ZZ7CEjlKtSTMqAOb6Xea1 fGNF3R6c1gxRROtwS8QBJ8E2ExdDlN376uiFjS21rM9CJEudG7k5hz4yDXsgeicNR1dI wLb5oN9bM51JOmS1vns7fznJkwd1VH5wVE6G7fMEMktbWmmkOBgpoIYjeVqUMT/1NGw2 9RFw== X-Received: by 10.236.84.81 with SMTP id r57mr1692460yhe.88.1385578992655; Wed, 27 Nov 2013 11:03:12 -0800 (PST) Received: from lumiwa.farms.net (d-ptld-bng1-71-161-118-183.ngn.east.myfairpoint.net. [71.161.118.183]) by mx.google.com with ESMTPSA id 48sm91839934yhq.11.2013.11.27.11.03.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Nov 2013 11:03:11 -0800 (PST) From: Ajtim To: Tom Evans , freebsd-current@freebsd.org Subject: Re: warning Date: Wed, 27 Nov 2013 14:03:08 -0500 Message-ID: <1507353.1DSceoke9z@lumiwa.farms.net> User-Agent: KMail/4.11.3 (FreeBSD/10.0-BETA3; KDE/4.11.3; amd64; ; ) In-Reply-To: <6259878.dCVq30d36H@lumiwa.farms.net> References: <3949129.efd2ojFSgk@lumiwa.farms.net> <6259878.dCVq30d36H@lumiwa.farms.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 19:03:13 -0000 On Wednesday 27 November 2013 12:59:10 Ajtim wrote: > On Wednesday 27 November 2013 17:07:40 you wrote: > > On Wed, Nov 27, 2013 at 4:55 PM, Ajtim wrote: > > > OS: FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > > > > > When I boot a computer I got one warning: > > > > > > /etc/rc: WARNING: $tcsd_enable is not set properly > > > > > > This is part of a port, security/trousers. Reinstall it? > > > > Cheers > > > > Tom > > Thank you. I didn't reinstall yet. > > I did and warning exist. If I put tcsd_enable="YES" in /etc/rc.conf than I gor that cannot start tcsd. Thank you. -- Mitja ------- http://www.redbubble.com/people.lumiwa From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 19:20:18 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D54AD55F; Wed, 27 Nov 2013 19:20:18 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 709D222BC; Wed, 27 Nov 2013 19:20:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rARJK8Oh059514; Wed, 27 Nov 2013 21:20:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rARJK8Oh059514 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rARJK8OV059506; Wed, 27 Nov 2013 21:20:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Nov 2013 21:20:08 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131127192008.GD59496@kib.kiev.ua> References: <20131127185017.GC59496@kib.kiev.ua> <201311271903.rARJ2v6u042303@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H8NM9WPt3ooVzFd/" Content-Disposition: inline In-Reply-To: <201311271903.rARJ2v6u042303@gw.catspoiler.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 19:20:19 -0000 --H8NM9WPt3ooVzFd/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: > On 27 Nov, Konstantin Belousov wrote: > > On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: > >> On 27 Nov, Konstantin Belousov wrote: > >> > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: > >> >> On 27 Nov, Konstantin Belousov wrote: > >> >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: > >> >> >> > >> >> >=20 > >> >> > What is the instruction at cpu_switch+0x9b ? > >> >>=20 > >> >> movl 0x8(%edx),%eax > >> > So it is line 176 in swtch.s. Is machine still in ddb, or did you > >> > obtained the core ? If yes, please print out the content of words at > >> > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at > >> > address (*) + 8. > >>=20 > >> It is still in ddb. > >>=20 > >> , though not in > >> the above order. > > Uhm, sorry, I mistyped the last part of the instructions. > >=20 > > The new thread pointer is 0xd2f4e000, there is nothing incriminating. > > Please print the word at 0xd2f4e000+0x254 =3D=3D 0xd2f4e254, which woul= d be > > the address of the new thread pcb. It is load from the pcb + 8 which > > faults. >=20 > 0xf3d44d60 Again, the pointer looks fine, and its tail is 0xd60, which is correct for the pcb offset in the last page of the thread stack. Please do 'show thread 0xd2f4e000' before trying below instructions. What happens if you try to read word at 0xf3d44d68 ? --H8NM9WPt3ooVzFd/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlkXnAAoJEJDCuSvBvK1B260P/A+cLEvlSTnzVNlFWoEsbVph XtWBX8Pq3fRIvopJbG5IkzvRTh/gjuD4MXhxlgPwW03u+OX//KSJESp/hnJ2E4g2 7tRsE6ssH3oZUWNp5ctL1aFOVRrp0QbY+mNQ/wEOpOcpUxs0UYczmSfn4fxW8NVk R1LMS3rJasA/RTL+BPJIPwa8pbl3G9SV70aRFXixq1wJp8C3tTBW9h2Sn4Yyk3z/ jrnhVXfh+rNt+Fu++Mg7jJpgT1QMJA169hQxR7BClqY2VCPGrnUWHH7g8C+edFaM +e7RQsi6EZyHQkRwrtTrWhLbgZK1Z+KD/jRpBsE1T45le0ShY0N+DmlupJNYtYTQ 5YZDqT1h/kCoZXabMV73PEcBU23PEzxFj5CVL7BhjRjxq7mlUXIejN0kRrZUzGxX e/bdtO6Wn2VgyEDTq8/sVBsYugokuXRU0qgWiQRIRegRM+YbmGnpBLg4F3NP/kiu n7Hn4+V/GmCvuP1Lr8ATDApxelHAQ4h6k7D7zR9NYUEqaIPawUGixPRTrYiPXlB8 fVmmcVeAbZ8vyAKfBRwGxZUNPwLlARnS97QIoFvqMQLwkbM38jWLW4DyMzq47XIo OqmqY9ft0VmFfnijcUCKipTMD78XNuU6s6rntq+/GY1DIxkyNG/v+i21vR+INgzP oxrzxzy328uzVLH0DL+t =wSPj -----END PGP SIGNATURE----- --H8NM9WPt3ooVzFd/-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 19:36:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F54F99C; Wed, 27 Nov 2013 19:36:45 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 027252389; Wed, 27 Nov 2013 19:36:44 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id j5so9805744qaq.5 for ; Wed, 27 Nov 2013 11:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=4mEUWUSVnJ6zXwOvo4JC2LM0sxNvIoGqmgMEzV5PGUM=; b=je7uj2nxnRnw1xu5DXw+0WMz30Du7AUGiTp3kCdxN/WbEutGQ2jyXP/fvvD8a2WnAW btd67S7Ra3rPD9hFRqFKELt0ThaugnMOR0L4MnHI5zwFxJSIHuOKqL5godAgyu9PfAtv VO9nJABabSzH4RFOwiFvIzqj8vbyOnRA9+eprI49edE9Yrxqoe/OZQOWPplyYhVxJwWn HCipZQRvMlLKriK2OcV2KETsoeyUWFtmUrY2BACt9sSqYglLu6OF185uJPLq3LbLFL+O aTQBIfTTvy+eJ58qWXNBRZsxgcJxhoeEKEYSFaO5b0kpRtekYLr9iboLV1Gwhsls9UbZ D2RQ== MIME-Version: 1.0 X-Received: by 10.229.56.200 with SMTP id z8mr69229405qcg.1.1385581004120; Wed, 27 Nov 2013 11:36:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Wed, 27 Nov 2013 11:36:44 -0800 (PST) Date: Wed, 27 Nov 2013 11:36:44 -0800 X-Google-Sender-Auth: EHAFstJ03Ts9iXCGhgrkajCtdL4 Message-ID: Subject: [review] sendfile / sendfile_sync refactoring From: Adrian Chadd To: "freebsd-arch@freebsd.org" , freebsd-current , Konstantin Belousov , Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 19:36:45 -0000 Hi, Here's part #2 in my sendfile refactoring. This is a little more intrusive than the first patch. http://people.freebsd.org/~adrian/netflix/20131126-sendfile-sync-refactor-2.diff My aim here is to move the sendfile_sync stuff out of uipc_syscalls.c and out of sendfile-only code and into something that can be reused elsewhere or replaced later on. I've created methods for all the sendfile_sync stuff, I've moved it out of the do_sendfile() loop so do_sendfile() doesn't specifically implement the completion behaviour. Initially, I'm going to implement a sendfile knote representing the completion of this particular mbuf transaction. I also have a vague, handwav-y idea to use this kind of mbuf transaction representation for later work with aio_write() (and maybe an aio_writev()) when writing to a socket - wire in the userland memory, create a chain of mbufs to represent those, wrap them up in a sendfile_sync (or whatever it mutates into) and then use that for the kqueue completion notification. It needs the same kind of mbuf transaction and kqueue notification mechanism so I'd like to eventually make the sendfile_sync stuff generic, or use the memory buffer representation from jhb, to implement this in a variety of places. I'm not entirely happy where the sendfile_sync stuff is living but this is all meant to be transition-y and enable further hacking on sendfile / variations thereof without having to duplicate too much code. Thanks, -adrian From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 19:46:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5B57F55; Wed, 27 Nov 2013 19:46:02 +0000 (UTC) Received: from mailrelay011.isp.belgacom.be (mailrelay011.isp.belgacom.be [195.238.6.178]) by mx1.freebsd.org (Postfix) with ESMTP id 7EBB02412; Wed, 27 Nov 2013 19:46:00 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAGADlLllJR8Y7x/2dsb2JhbABZgwc4uRWBHhd0giUBAQVWIxALGAklDyoeBhMJh3wBCMAMF48CB4QzA5Axh2KBMYsthTaDKjs Received: from 241.142-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.142.241]) by relay.skynet.be with ESMTP; 27 Nov 2013 20:45:59 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id rARJjvJw053553; Wed, 27 Nov 2013 20:45:58 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Wed, 27 Nov 2013 20:45:56 +0100 From: Tijl Coosemans To: Jan Henrik Sylvester Subject: Re: libc++ vs. libstdc++ usage in the ports tree Message-ID: <20131127204556.2974a3f5@kalimero.tijl.coosemans.org> In-Reply-To: <52963A90.4000201@janh.de> References: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> <20131114144555.GA22093@troutmask.apl.washington.edu> <52963A90.4000201@janh.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/CY5PFh_I1i.Xl_rs9n64aaV" Cc: Maho Nakata , FreeBSD Current , stephen@FreeBSD.org, Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 19:46:02 -0000 --MP_/CY5PFh_I1i.Xl_rs9n64aaV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: > Trying to migrate to 10, I would like to keep octave. Have you found > anything new? Having build the port and all dependencies with standard > options, octave is segfaulting for me, too. Anyhow, I can run octave with: > > env LD_PRELOAD=/usr/lib/libc++.so.1 octave > > Some very light testing indicates that it is working. Of course, this is > not ideal. > > Maybe this gives a clue how to fix the octave port properly. I have a preliminary patch for math/octave that I wanted to test on redports first, but it is down at the moment so here it is. --MP_/CY5PFh_I1i.Xl_rs9n64aaV Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=octave-fortran.patch Index: math/octave/Makefile =================================================================== --- math/octave/Makefile (revision 335025) +++ math/octave/Makefile (working copy) @@ -32,7 +32,7 @@ LIB_DEPENDS= GraphicsMagick:${PORTSDIR}/ umfpack.1:${PORTSDIR}/math/suitesparse \ glpk:${PORTSDIR}/math/glpk -USES= charsetfix gmake perl5 pkgconfig +USES= charsetfix fortran gmake perl5 pkgconfig USE_BZIP2= yes USE_PERL5= build USE_TEX= dvipsk:build @@ -74,8 +74,6 @@ BLAS= -lptf77blas LAPACK= -lalapack -lptcblas .endif -USE_FORTRAN= yes - OCTAVE_VERSION= ${PORTVERSION} GNU_HOST= ${ARCH}-portbld-freebsd${OSREL} PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} GNU_HOST=${GNU_HOST} @@ -140,7 +138,8 @@ post-install: ${ECHO_CMD} @dirrm share/octave >> ${WRKDIR}/PLIST cd ${WRKDIR} ; ${SED} -i -e "/PLIST/ r PLIST" ${TMPPLIST} -check: +check: regression-test +regression-test: build (cd ${WRKSRC}; ${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_ARGS} check) .include Index: math/octave/files/patch-configure =================================================================== --- math/octave/files/patch-configure (revision 0) +++ math/octave/files/patch-configure (working copy) @@ -0,0 +1,11 @@ +--- configure.orig 2013-02-21 21:21:49.000000000 +0100 ++++ configure 2013-11-22 20:34:49.000000000 +0100 +@@ -58248,7 +58248,7 @@ + main () + { + +- std::unordered_map m; ++ std::unordered_map m; + + ; + return 0; Property changes on: math/octave/files/patch-configure ___________________________________________________________________ Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: math/octave/files/patch-libgnu-math.in.h =================================================================== --- math/octave/files/patch-libgnu-math.in.h (revision 0) +++ math/octave/files/patch-libgnu-math.in.h (working copy) @@ -0,0 +1,11 @@ +--- libgnu/math.in.h.orig 2013-02-21 21:21:17.000000000 +0100 ++++ libgnu/math.in.h 2013-11-22 12:35:47.000000000 +0100 +@@ -17,7 +17,7 @@ + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +-#ifndef _@GUARD_PREFIX@_MATH_H ++#if 1 + + #if __GNUC__ >= 3 + @PRAGMA_SYSTEM_HEADER@ Property changes on: math/octave/files/patch-libgnu-math.in.h ___________________________________________________________________ Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: math/octave/files/patch-liboctave-eigs-base.cc =================================================================== --- math/octave/files/patch-liboctave-eigs-base.cc (revision 0) +++ math/octave/files/patch-liboctave-eigs-base.cc (working copy) @@ -0,0 +1,11 @@ +--- liboctave/eigs-base.cc.orig 2013-02-21 21:19:24.000000000 +0100 ++++ liboctave/eigs-base.cc 2013-11-22 20:19:19.000000000 +0100 +@@ -3832,7 +3832,7 @@ + bool cholB = 0, int disp = 0, int maxit = 300); + #endif + +-#ifndef _MSC_VER ++#if !defined(_MSC_VER) && !defined(__clang__) + template static octave_idx_type + lusolve (const SparseMatrix&, const SparseMatrix&, Matrix&); + Property changes on: math/octave/files/patch-liboctave-eigs-base.cc ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: Mk/Uses/fortran.mk =================================================================== --- Mk/Uses/fortran.mk (revision 0) +++ Mk/Uses/fortran.mk (working copy) @@ -0,0 +1,32 @@ +# $FreeBSD$ +# +# Establish Fortran-capable compiler as a build dependency +# +# MAINTAINER: ports@FreeBSD.org +# +# Feature: fortran +# Usage: USES=fortran +# Valid ARGS: does not require args + +.if !defined(_INCLUDE_USES_FORTRAN_MK) +_INCLUDE_USES_FORTRAN_MK= yes + +.if defined(fortran_ARGS) +IGNORE= USES=fortran does not require args +.endif + +.if !defined(FC) +BUILD_DEPENDS+= gfortran46:${PORTSDIR}/lang/gcc +RUN_DEPENDS+= gfortran46:${PORTSDIR}/lang/gcc + +USE_BINUTILS= yes + +FC= gfortran46 +FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc46 +LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc46 +.endif + +CONFIGURE_ENV+= F77="${FC}" FC="${FC}" FFLAGS="${FFLAGS}" +MAKE_ENV+= F77="${FC}" FC="${FC}" FFLAGS="${FFLAGS}" + +.endif Property changes on: Mk/Uses/fortran.mk ___________________________________________________________________ Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property --MP_/CY5PFh_I1i.Xl_rs9n64aaV-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 20:01:05 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DB22ACB for ; Wed, 27 Nov 2013 20:01:05 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04BE924F9 for ; Wed, 27 Nov 2013 20:01:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rARK0oM1069526; Wed, 27 Nov 2013 22:00:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rARK0oM1069526 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rARK0o4w069525; Wed, 27 Nov 2013 22:00:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Nov 2013 22:00:50 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131127200050.GE59496@kib.kiev.ua> References: <20131127192008.GD59496@kib.kiev.ua> <201311271935.rARJZJfC042361@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3JTsiWhzN5QveqyW" Content-Disposition: inline In-Reply-To: <201311271935.rARJZJfC042361@gw.catspoiler.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 20:01:05 -0000 --3JTsiWhzN5QveqyW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote: > On 27 Nov, Konstantin Belousov wrote: > > On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: > >> On 27 Nov, Konstantin Belousov wrote: > >> > On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: > >> >> On 27 Nov, Konstantin Belousov wrote: > >> >> > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: > >> >> >> On 27 Nov, Konstantin Belousov wrote: > >> >> >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: > >> >> >> >> > >> >> >> >=20 > >> >> >> > What is the instruction at cpu_switch+0x9b ? > >> >> >>=20 > >> >> >> movl 0x8(%edx),%eax > >> >> > So it is line 176 in swtch.s. Is machine still in ddb, or did you > >> >> > obtained the core ? If yes, please print out the content of words= at > >> >> > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word= at > >> >> > address (*) + 8. > >> >>=20 > >> >> It is still in ddb. > >> >>=20 > >> >> , though not = in > >> >> the above order. > >> > Uhm, sorry, I mistyped the last part of the instructions. > >> >=20 > >> > The new thread pointer is 0xd2f4e000, there is nothing incriminating. > >> > Please print the word at 0xd2f4e000+0x254 =3D=3D 0xd2f4e254, which w= ould be > >> > the address of the new thread pcb. It is load from the pcb + 8 which > >> > faults. > >>=20 > >> 0xf3d44d60 > > Again, the pointer looks fine, and its tail is 0xd60, which is correct = for > > the pcb offset in the last page of the thread stack. > >=20 > > Please do 'show thread 0xd2f4e000' before trying below instructions. >=20 > Ok, see below: > =20 > > What happens if you try to read word at 0xf3d44d68 ? >=20 > Nothing bad ... >=20 > >=20 So the thread structure looks sane, the stack region is in place where it is supposed to be, all the gathered data looks self-consistent. And, the access to the faulted address from ddb does not fault. Thread stacks can only be invalidated when the process is swapped out and kernel stack is written to swap. Your thread flags indicate that it is in memory, and TDF_CANSWAP is not set. I do not believe that our swapout code would invalidate stack mapping in such situation, otherwise we would have too many complaints already. Just in case, do you use swap on this box ? And, as the last resort, I do understand that this sounds as giving up, do you monitor the temperature of the CPUs ? BTW, which CPUs are that, please show the cpu identification lines from the boot dmesg. --3JTsiWhzN5QveqyW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlk9xAAoJEJDCuSvBvK1BfhgP/1k4JttQJs1jTAj9+8k19NLN e7XwQ/YFYu6dMXdvHfYQwL17OO8Kfw9yGskoX6Va+QbvRguIFyFYlGrKM0z159kV SwhzuY/qVFmqr2mBCOROYRnXdZRaLnPsj/BY81g3FucXl/0HyxbxgVEjX30U5ehC NF9d9kjA8tj3FZgWX42GfrC3y4UQ8XuQ7cdTKDh/KTVOrCKMl/mA6neHC6lcrQFb 3TPxIMzynBKCUkW1v5wl4PYuCTgCwSEh6TAde3AgdGZ/0h4iYKbqJiUvl3vUwmnA mWvhfKH34CZDHwrBlOa5GW/vbs5zP3IPMbJ0C2o3SPV7b6oJgwBHd/Y/wx8LWRCK 8CoBc2EPGNEX8ELi0eKc4AWvGzBghKJr21uW+Vova2gVXqADC+ABChZXKvGcGrZ5 wsQnTaZRU82I2hy00H+gS7jyMpBmnlCYNy+nBnEBPe8mECC6c4CtbOmM0IbQCWSh 7EaLrmQLfRi/dEB0XsZe9DffUmoaY5egOLbTPQ4yUbOKN6mVvppKb5ZGAV0iCYMs fnmHDHogh5DU1YCR9WMHIac6VD/nYUdnevXjgh16U0I9xOhvXIJIycavQiNbk6+M rfDJGlgjD+tzaDZRFn11l4SolZdv1hExfHG+vh6pKKD6d0PcjkqMaK/JBfZpwlz+ XxFHY8XbZMpaqNuTU327 =8PJh -----END PGP SIGNATURE----- --3JTsiWhzN5QveqyW-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 20:03:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25424BFB for ; Wed, 27 Nov 2013 20:03:55 +0000 (UTC) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC91A2515 for ; Wed, 27 Nov 2013 20:03:54 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id p6so5418842vbe.27 for ; Wed, 27 Nov 2013 12:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ElQhjLivxOSvdRr3tiFyhml/diYmBKSq/x9LoOyoTvo=; b=oThluprT0172jtAFHyR+6TPRjXyu9c8Y/MCM97AuZ/gV5a0r4oE9eIfeu2Ag42CHxr dtpRaxFXnVCEf3eUinyeyJnOXOrmGJeuwH3ohMb6nXwjQDqhua/XyI9V56SMV7J9Xzqw ORxWi6yHqd0dP6f2KrAv+gm3ZZy5Z8DnDRZQ3a26OPDeHLUKTqLCboAwPoprL7EeQ/j1 uIKMdwbpg2rcuYCxHy34dLSoNurdtzMVw3LxYYLJMpGmud/naPNZ2AzFmVQJULGn/X8q vvp1cB4HOpEvQgE+41+OtaowOGkREKnokNcnYrJLW33yBfphFQtnF77EarciRtGOeKy9 nOrA== X-Received: by 10.52.0.81 with SMTP id 17mr816523vdc.50.1385582633958; Wed, 27 Nov 2013 12:03:53 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.123.5 with HTTP; Wed, 27 Nov 2013 12:03:32 -0800 (PST) In-Reply-To: References: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 27 Nov 2013 21:03:32 +0100 X-Google-Sender-Auth: SzY9wBUXKEnBKvdcBc2yjHGZ8zs Message-ID: Subject: Re: [request] ntp upgrade To: Cristiano Deana Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 20:03:55 -0000 On Wed, Nov 27, 2013 at 4:29 PM, Cristiano Deana wrote: > Hi, > > is it possible to include in base system of the upcoming 10.0 the new > version of ntp (4.2.7 instead of 4.2.4)? > > There is a bug in older versions (< 4.2.7) who allows attacker use an ntp > server to DDoS. This has been corrected in new version: > https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks Thanks for this URL, I've meet this problem on my FreeBSD 9.2 few weeks ago (public NTP registered in the pool.ntp.org). There is a thread on the ntp.org ML about this too: http://lists.ntp.org/pipermail/pool/2013-November/thread.html Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 19:35:27 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1569A98D for ; Wed, 27 Nov 2013 19:35:27 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC87B2382 for ; Wed, 27 Nov 2013 19:35:26 +0000 (UTC) Received: from catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rARJZJfC042361; Wed, 27 Nov 2013 11:35:23 -0800 (PST) (envelope-from spamvictim@catspoiler.org) Message-Id: <201311271935.rARJZJfC042361@gw.catspoiler.org> Date: Wed, 27 Nov 2013 11:35:19 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131127192008.GD59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 27 Nov 2013 20:24:47 +0000 Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 19:35:27 -0000 On 27 Nov, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: >> On 27 Nov, Konstantin Belousov wrote: >> > On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: >> >> On 27 Nov, Konstantin Belousov wrote: >> >> > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: >> >> >> On 27 Nov, Konstantin Belousov wrote: >> >> >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: >> >> >> >> >> >> >> > >> >> >> > What is the instruction at cpu_switch+0x9b ? >> >> >> >> >> >> movl 0x8(%edx),%eax >> >> > So it is line 176 in swtch.s. Is machine still in ddb, or did you >> >> > obtained the core ? If yes, please print out the content of words at >> >> > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at >> >> > address (*) + 8. >> >> >> >> It is still in ddb. >> >> >> >> , though not in >> >> the above order. >> > Uhm, sorry, I mistyped the last part of the instructions. >> > >> > The new thread pointer is 0xd2f4e000, there is nothing incriminating. >> > Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be >> > the address of the new thread pcb. It is load from the pcb + 8 which >> > faults. >> >> 0xf3d44d60 > Again, the pointer looks fine, and its tail is 0xd60, which is correct for > the pcb offset in the last page of the thread stack. > > Please do 'show thread 0xd2f4e000' before trying below instructions. Ok, see below: > What happens if you try to read word at 0xf3d44d68 ? Nothing bad ... From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 21:11:46 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9BCB3F0 for ; Wed, 27 Nov 2013 21:11:46 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 66235294E for ; Wed, 27 Nov 2013 21:11:45 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rARLBZk9042868; Wed, 27 Nov 2013 13:11:39 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311272111.rARLBZk9042868@gw.catspoiler.org> Date: Wed, 27 Nov 2013 13:11:35 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131127200050.GE59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 21:11:47 -0000 On 27 Nov, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote: >> On 27 Nov, Konstantin Belousov wrote: >> > On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: >> >> On 27 Nov, Konstantin Belousov wrote: >> >> > On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: >> >> >> On 27 Nov, Konstantin Belousov wrote: >> >> >> > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: >> >> >> >> On 27 Nov, Konstantin Belousov wrote: >> >> >> >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: >> >> >> >> >> >> >> >> >> > >> >> >> >> > What is the instruction at cpu_switch+0x9b ? >> >> >> >> >> >> >> >> movl 0x8(%edx),%eax >> >> >> > So it is line 176 in swtch.s. Is machine still in ddb, or did you >> >> >> > obtained the core ? If yes, please print out the content of words at >> >> >> > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at >> >> >> > address (*) + 8. >> >> >> >> >> >> It is still in ddb. >> >> >> >> >> >> , though not in >> >> >> the above order. >> >> > Uhm, sorry, I mistyped the last part of the instructions. >> >> > >> >> > The new thread pointer is 0xd2f4e000, there is nothing incriminating. >> >> > Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be >> >> > the address of the new thread pcb. It is load from the pcb + 8 which >> >> > faults. >> >> >> >> 0xf3d44d60 >> > Again, the pointer looks fine, and its tail is 0xd60, which is correct for >> > the pcb offset in the last page of the thread stack. >> > >> > Please do 'show thread 0xd2f4e000' before trying below instructions. >> >> Ok, see below: >> >> > What happens if you try to read word at 0xf3d44d68 ? >> >> Nothing bad ... >> >> >> > So the thread structure looks sane, the stack region is in place where > it is supposed to be, all the gathered data looks self-consistent. And, > the access to the faulted address from ddb does not fault. > > Thread stacks can only be invalidated when the process is swapped out and > kernel stack is written to swap. Your thread flags indicate that it is > in memory, and TDF_CANSWAP is not set. I do not believe that our swapout > code would invalidate stack mapping in such situation, otherwise we would > have too many complaints already. > > Just in case, do you use swap on this box ? I do. > And, as the last resort, I do understand that this sounds as giving up, > do you monitor the temperature of the CPUs ? BTW, which CPUs are that, > please show the cpu identification lines from the boot dmesg. I don't monitor the temperature, but I do hear the CPU fan speed ramping up and down when I'm building ports like this. Even though I'm pretty much keeping one core busy the whole time, the temperature must drop enough at times to let the fan speed drop. I can run math/mprime on this machine for a while to see if anything shows up. I also have a very similar machine (same motherboard but different CPU) that I can move the drive over to and test. Here's the full dmesg.boot: Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #63 r258614M: Tue Nov 26 00:29:01 PST 2013 dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2500.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb1 Family = 0xf Model = 0x6b Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f real memory = 4294967296 (4096 MB) avail memory = 3589320704 (3423 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130823/tbfadt-630) ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dbdf0000 (3) failed cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfeff0000-0xfeff03ff irq 0,8 on acpi0 device_attach: hpet0 attach returned 12 atrtc0: port 0x70-0x73 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: Length mismatch for 4 range: 81 vs 7f pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 usbus0 on ohci0 ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 23 at device 4.0 on pci0 usbus2 on ohci1 ehci1: mem 0xfe02c000-0xfe02c0ff irq 20 at device 4.1 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci1 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 hdac0: mem 0xfe020000-0xfe023fff irq 21 at device 7.0 on pci0 pcib1: at device 8.0 on pci0 pci1: on pcib1 pci1: at device 7.0 (no driver attached) ahc0: port 0xcc00-0xccff mem 0xfd0fe000-0xfd0fefff irq 17 at device 9.0 on pci1 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahci0: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xdc00-0xdc0f mem 0xfe026000-0xfe027fff irq 22 at device 9.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported ahci0: quirks=0x200 ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 nfe0: port 0xd800-0xd807 mem 0xfe02b000-0xfe02bfff,0xfe02a000-0xfe02a0ff,0xfe029000-0xfe02900f irq 23 at device 10.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow nfe0: Ethernet address: 00:50:8d:9f:6d:e3 pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 ahci1: port 0xac00-0xac07,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9c00-0x9c1f mem 0xfdcff000-0xfdcff1ff irq 16 at device 0.0 on pci3 ahci1: AHCI v1.20 with 2 6Gbps ports, Port Multiplier supported ahcich4: at channel 0 on ahci1 ahcich5: at channel 1 on ahci1 pcib4: at device 13.0 on pci0 pci4: on pcib4 pcib5: at device 14.0 on pci0 pci5: on pcib5 pcib6: at device 15.0 on pci0 pci6: on pcib6 pcib7: at device 16.0 on pci0 pci7: on pcib7 pcib8: at device 17.0 on pci0 pci8: on pcib8 vgapci0: mem 0xfb000000-0xfbffffff,0xe0000000-0xefffffff,0xfc000000-0xfcffffff irq 20 at device 18.0 on pci0 NVRM: The NVIDIA GeForce 7050 PV / nForce 630a GPU installed in this system is NVRM: supported through the NVIDIA 304.xx Legacy drivers. Please NVRM: visit http://www.nvidia.com/object/unix.html for more NVRM: information. The 319.32 NVIDIA driver will ignore NVRM: this GPU. Continuing probe... acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model MouseMan+, device ID 0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. powernow0: on cpu0 powernow1: on cpu1 Timecounters tick every 1.000 msec xpt_config: xpt_create_path() failed for debug target 9:0:0, debugging disabled hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20,22,21,23,27 and 24,26,28,25 on hdaa0 pcm1: at nid 30 on hdaa0 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 5 on hdaa1 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen3.1: at usbus3 uhub1: on usbus3 ugen2.1: at usbus2 uhub2: on usbus2 ugen1.1: at usbus1 uhub3: on usbus1 uhub0: 6 ports with 6 removable, self powered uhub2: 6 ports with 6 removable, self powered uhub1: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ada0 at ahcich1 bus 0 scbus4 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 401411CQC11039 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad6 da0 at ahc0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number 3FD13QC700002243GFXL da0: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da0: Command Queueing enabled da0: 35003MB (71687370 512 byte sectors: 255H 63S/T 4462C) SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/da0s1a [rw]... lock order reversal: 1st 0xe4d836e8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3081 2nd 0xc9628400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper(c11334ac,323a632e,a3438,ee33f790,c0b660ba,...) at db_trace_self_wrapper+0x2d/frame 0xee33f760 kdb_backtrace(c1136ff9,c9628400,c116a0dd,c8da3b58,c1169d15,...) at kdb_backtrace+0x30/frame 0xee33f7c8 witness_checkorder(c9628400,9,c1169d15,11c,0,...) at witness_checkorder+0xc8a/frame 0xee33f818 _sx_xlock(c9628400,0,c1169d15,11c,c973d1d0,...) at _sx_xlock+0x77/frame 0xee33f848 ufsdirhash_add(c973d1d0,ee33f940,6f38,ee33f8c8,ee33f8cc,...) at ufsdirhash_add+0x4a/frame 0xee33f878 ufs_direnter(c9b3d6a8,c9b3d58c,ee33f940,ee33fb64,e4d83a80,...) at ufs_direnter+0x63b/frame 0xee33f8f8 ufs_mkdir(ee33fc00,c12f9e87,c11630ce,c9b3d6a8,ee33fbfc,...) at ufs_mkdir+0x884/frame 0xee33fa98 VOP_MKDIR_APV(c13bf1a0,ee33fc00,ee33fb64,ee33fb90,88803020,...) at VOP_MKDIR_APV+0x124/frame 0xee33fac8 kern_mkdirat(c96e6c40,ffffff9c,88803020,0,1c0) at kern_mkdirat+0x236/frame 0xee33fc24 sys_mkdir(c96e6c40,ee33fcc8,14,c11314ed,7ba,...) at sys_mkdir+0x31/frame 0xee33fc40 syscall(ee33fd08) at syscall+0x2de/frame 0xee33fcfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xee33fcfc --- syscall (136, FreeBSD ELF32, sys_mkdir), eip = 0x88176097, esp = 0xbfbfd92c, ebp = 0xbfbfddcc --- lock order reversal: 1st 0xc9b3d6dc ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101 2nd 0xe4d836e8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xc9b3d5c0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101 KDB: stack backtrace: db_trace_self_wrapper(c11334ac,3236323a,ee33000a,c0a24bae,c9668390,...) at db_trace_self_wrapper+0x2d/frame 0xee33f2f8 kdb_backtrace(c1137012,c9b3d5c0,c111d2f2,c8da3af0,c11406f1,...) at kdb_backtrace+0x30/frame 0xee33f360 witness_checkorder(c9b3d5c0,9,c11406f1,835,c9b3d5e0,...) at witness_checkorder+0xc8a/frame 0xee33f3b0 __lockmgr_args(c9b3d5c0,80100,c9b3d5e0,0,0,...) at __lockmgr_args+0x842/frame 0xee33f484 ffs_lock(ee33f508,c8d8f1e0,c8d95360,c8d8f1e0,c8d95360,...) at ffs_lock+0x9a/frame 0xee33f4c4 VOP_LOCK1_APV(c13bf1a0,ee33f508,ee33f544,c0b65518,c13d40b0,...) at VOP_LOCK1_APV+0x104/frame 0xee33f4f0 _vn_lock(c9b3d58c,80100,c11406f1,835,c113f929,...) at _vn_lock+0xca/frame 0xee33f530 vget(c9b3d58c,80100,c96e6c40,57,0,...) at vget+0x74/frame 0xee33f568 vfs_hash_get(c96a5d20,27e405,80000,c96e6c40,ee33f658,...) at vfs_hash_get+0xfc/frame 0xee33f594 ffs_vgetf(c96a5d20,27e405,80000,ee33f658,1,...) at ffs_vgetf+0x47/frame 0xee33f5f0 softdep_sync_buf(c9b3d6a8,e4d83690,1,0,0,...) at softdep_sync_buf+0x2cc/frame 0xee33f668 ffs_syncvnode(c9b3d6a8,1,0,246,0,...) at ffs_syncvnode+0x287/frame 0xee33f6c0 ffs_truncate(c9b3d6a8,7800,0,880,c9681080,...) at ffs_truncate+0x6db/frame 0xee33f878 ufs_direnter(c9b3d6a8,c9b3d58c,ee33f940,ee33fb64,e4d83a80,...) at ufs_direnter+0x7ed/frame 0xee33f8f8 ufs_mkdir(ee33fc00,c12f9e87,c11630ce,c9b3d6a8,ee33fbfc,...) at ufs_mkdir+0x884/frame 0xee33fa98 VOP_MKDIR_APV(c13bf1a0,ee33fc00,ee33fb64,ee33fb90,88803020,...) at VOP_MKDIR_APV+0x124/frame 0xee33fac8 kern_mkdirat(c96e6c40,ffffff9c,88803020,0,1c0) at kern_mkdirat+0x236/frame 0xee33fc24 sys_mkdir(c96e6c40,ee33fcc8,14,c11314ed,7ba,...) at sys_mkdir+0x31/frame 0xee33fc40 syscall(ee33fd08) at syscall+0x2de/frame 0xee33fcfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xee33fcfc --- syscall (136, FreeBSD ELF32, sys_mkdir), eip = 0x88176097, esp = 0xbfbfd92c, ebp = 0xbfbfddcc --- KLD linux_adobe.ko: depends on kernel - not available or version mismatch lock order reversal: 1st 0xc9665c28 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1203 2nd 0xc9d75a30 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4350 KDB: stack backtrace: db_trace_self_wrapper(c11334ac,6b2f7379,2f6e7265,6e72656b,7365645f,...) at db_trace_self_wrapper+0x2d/frame 0xf3cfc8f8 kdb_backtrace(c1136ff9,c9d75a30,c111d2f2,c8da3af0,c11406f1,...) at kdb_backtrace+0x30/frame 0xf3cfc960 witness_checkorder(c9d75a30,9,c11406f1,10fe,0,...) at witness_checkorder+0xc8a/frame 0xf3cfc9b0 __lockmgr_args(c9d75a30,80400,c9d75a50,0,0,...) at __lockmgr_args+0x842/frame 0xf3cfca84 ffs_lock(f3cfcb08,f3cfcadc,c0b71c45,c9d75a30,f3cfcb08,...) at ffs_lock+0x9a/frame 0xf3cfcac4 VOP_LOCK1_APV(c13bf1a0,f3cfcb08,c9d58d00,0,c13d40b0,...) at VOP_LOCK1_APV+0x104/frame 0xf3cfcaf0 _vn_lock(c9d759fc,80400,c11406f1,10fe) at _vn_lock+0xca/frame 0xf3cfcb30 vfs_knllock(c9d759fc,0,c1127f22,778,c9d759fc,...) at vfs_knllock+0x29/frame 0xf3cfcb48 knlist_remove_kq(0,0) at knlist_remove_kq+0x87/frame 0xf3cfcb6c knlist_remove(c9d58d00,c9b0b6c0,0,11,11,...) at knlist_remove+0x1f/frame 0xf3cfcb7c filt_vfsdetach(c9b0b6c0,0,c1127f22,882,4,...) at filt_vfsdetach+0x2f/frame 0xf3cfcb9c knote_fdclose(c9d6d000,11,c1127661,46a,0,...) at knote_fdclose+0xde/frame 0xf3cfcbd8 closefp(c9707888,c9d6d000,1,b1,c9665c00,...) at closefp+0x6b/frame 0xf3cfcc04 kern_close(c9d6d000,11) at kern_close+0xfb/frame 0xf3cfcc30 sys_close(c9d6d000,f3cfccc8,0,0,0,...) at sys_close+0x1a/frame 0xf3cfcc40 syscall(f3cfcd08) at syscall+0x2de/frame 0xf3cfccfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xf3cfccfc --- syscall (6, FreeBSD ELF32, sys_close), eip = 0x8843f017, esp = 0xbf7fbf00, ebp = 0xbf7fbf18 --- pid 66586 (iconvcap), uid 0: exited on signal 11 (core dumped) Fatal double fault: eip = 0xc0b14491 esp = 0xe4f61f54 ebp = 0xe4f62020 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c11334ac,2,10000000,c15a1cf0,c15a1ce8,...) at db_trace_self_wrapper+0x2d/frame 0xc15a1cb0 kdb_backtrace(c12f14df,0,c12f2b8a,c15a1d6c,0,...) at kdb_backtrace+0x30/frame 0xc15a1d18 vpanic(c15a1d6c,c15a1d84,c0fc159b,c12f2b8a,0,...) at vpanic+0x11f/frame 0xc15a1d54 panic(c12f2b8a,0,0,0,e4f62020,...) at panic+0x12/frame 0xc15a1d60 dblfault_handler() at dblfault_handler+0xab/frame 0xc15a1d60 --- trap 0x17, eip = 0xc0b14491, esp = 0xe4f61f54, ebp = 0xe4f62020 --- kvprintf(c12f29a0,c0b15270,e4f62040,a,e4f6210c,...) at kvprintf+0x21/frame 0xe4f62020 vprintf(c12f29a0,e4f6210c,e4f6210c) at vprintf+0x7f/frame 0xe4f620ec printf(c12f29a0,c,0,1050500,0,...) at printf+0x1b/frame 0xe4f62100 trap(e4f62254) at trap+0x18a/frame 0xe4f62248 calltrap() at calltrap+0x6/frame 0xe4f62248 --- trap 0xc, eip = 0xc0ac1887, esp = 0xe4f62294, ebp = 0xe4f622bc --- __mtx_lock_spin_flags(c2490ffc,0,c11338b5,c7,c2426cac,...) at __mtx_lock_spin_flags+0x27/frame 0xe4f622bc msgbuf_addstr(c2490fc8,ffffffff,e4f624f0,1,0,...) at msgbuf_addstr+0x5c/frame 0xe4f6236c putchar(a,e4f624d0,a,0,7ffd3914,...) at putchar+0xd6/frame 0xe4f623dc kvprintf(c12f29a0,c0b15270,e4f624d0,a,e4f6259c,...) at kvprintf+0xcb/frame 0xe4f624b0 vprintf(c12f29a0,e4f6259c,e4f6259c) at vprintf+0x7f/frame 0xe4f6257c printf(c12f29a0,c,2,1,c13cc2ac,...) at printf+0x1b/frame 0xe4f62590 trap(e4f626e4) at trap+0x18a/frame 0xe4f626d8 calltrap() at calltrap+0x6/frame 0xe4f626d8 --- trap 0xc, eip = 0xc0ac1887, esp = 0xe4f62724, ebp = 0xe4f6274c --- __mtx_lock_spin_flags(c2490ffc,0,c11338b5,c7,c0fe3ac7,...) at __mtx_lock_spin_flags+0x27/frame 0xe4f6274c msgbuf_addstr(c2490fc8,ffffffff,e4f62980,1,1,...) at msgbuf_addstr+0x5c/frame 0xe4f627fc putchar(a,e4f62960,a,0,c0afbcda,...) at putchar+0xd6/frame 0xe4f6286c kvprintf(c12f29a0,c0b15270,e4f62960,a,e4f62a2c,...) at kvprintf+0xcb/frame 0xe4f62940 vprintf(c12f29a0,e4f62a2c,e4f62a2c) at vprintf+0x7f/frame 0xe4f62a0c printf(c12f29a0,c,c11314ed,92c,e4f62a70,...) at printf+0x1b/frame 0xe4f62a20 trap(e4f62b70) at trap+0x18a/frame 0xe4f62b64 calltrap() at calltrap+0x6/frame 0xe4f62b64 --- trap 0xc, eip = 0xc0fbef73, esp = 0xe4f62bb0, ebp = 0xe4f62c00 --- cpu_switch(c8f04000,0,608,1b6,136af,...) at cpu_switch+0x9b/frame 0xe4f62c00 mi_switch(608,0,c112f584,d3,9,...) at mi_switch+0x1c9/frame 0xe4f62c34 critical_exit(0,2,c11314ed,410,c141f108,...) at critical_exit+0xa4/frame 0xe4f62c50 sched_idletd(0,e4f62d08,c11286d4,3da,0,...) at sched_idletd+0x1d6/frame 0xe4f62ccc fork_exit(c0afeb60,0,e4f62d08) at fork_exit+0x7f/frame 0xe4f62cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xe4f62cf4 --- trap 0, eip = 0, esp = 0xe4f62d40, ebp = 0 --- KDB: enter: panic Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #63 r258614M: Tue Nov 26 00:29:01 PST 2013 dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2500.05-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb1 Family = 0xf Model = 0x6b Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f real memory = 4294967296 (4096 MB) avail memory = 3589320704 (3423 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130823/tbfadt-630) ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dbdf0000 (3) failed cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfeff0000-0xfeff03ff irq 0,8 on acpi0 device_attach: hpet0 attach returned 12 atrtc0: port 0x70-0x73 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: Length mismatch for 4 range: 81 vs 7f pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 usbus0 on ohci0 ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 23 at device 4.0 on pci0 usbus2 on ohci1 ehci1: mem 0xfe02c000-0xfe02c0ff irq 20 at device 4.1 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci1 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 hdac0: mem 0xfe020000-0xfe023fff irq 21 at device 7.0 on pci0 pcib1: at device 8.0 on pci0 pci1: on pcib1 pci1: at device 7.0 (no driver attached) ahc0: port 0xcc00-0xccff mem 0xfd0fe000-0xfd0fefff irq 17 at device 9.0 on pci1 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahci0: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xdc00-0xdc0f mem 0xfe026000-0xfe027fff irq 22 at device 9.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported ahci0: quirks=0x200 ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 nfe0: port 0xd800-0xd807 mem 0xfe02b000-0xfe02bfff,0xfe02a000-0xfe02a0ff,0xfe029000-0xfe02900f irq 23 at device 10.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow nfe0: Ethernet address: 00:50:8d:9f:6d:e3 pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 ahci1: port 0xac00-0xac07,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9c00-0x9c1f mem 0xfdcff000-0xfdcff1ff irq 16 at device 0.0 on pci3 ahci1: AHCI v1.20 with 2 6Gbps ports, Port Multiplier supported ahcich4: at channel 0 on ahci1 ahcich5: at channel 1 on ahci1 pcib4: at device 13.0 on pci0 pci4: on pcib4 pcib5: at device 14.0 on pci0 pci5: on pcib5 pcib6: at device 15.0 on pci0 pci6: on pcib6 pcib7: at device 16.0 on pci0 pci7: on pcib7 pcib8: at device 17.0 on pci0 pci8: on pcib8 vgapci0: mem 0xfb000000-0xfbffffff,0xe0000000-0xefffffff,0xfc000000-0xfcffffff irq 20 at device 18.0 on pci0 NVRM: The NVIDIA GeForce 7050 PV / nForce 630a GPU installed in this system is NVRM: supported through the NVIDIA 304.xx Legacy drivers. Please NVRM: visit http://www.nvidia.com/object/unix.html for more NVRM: information. The 319.32 NVIDIA driver will ignore NVRM: this GPU. Continuing probe... acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model MouseMan+, device ID 0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. powernow0: on cpu0 powernow1: on cpu1 Timecounters tick every 1.000 msec xpt_config: xpt_create_path() failed for debug target 9:0:0, debugging disabled hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20,22,21,23,27 and 24,26,28,25 on hdaa0 pcm1: at nid 30 on hdaa0 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 5 on hdaa1 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen3.1: at usbus3 uhub3: on usbus3 uhub0: 6 ports with 6 removable, self powered uhub1: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub2: 6 ports with 6 removable, self powered ada0 at ahcich1 bus 0 scbus4 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 401411CQC11039 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad6 da0 at ahc0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number 3FD13QC700002243GFXL da0: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da0: Command Queueing enabled da0: 35003MB (71687370 512 byte sectors: 255H 63S/T 4462C) SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/da0s1a [rw]... WARNING: / was not properly dismounted lock order reversal: 1st 0xe4d5d738 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3081 2nd 0xc9684200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper(c11334ac,323a632e,a3438,ee33f790,c0b660ba,...) at db_trace_self_wrapper+0x2d/frame 0xee33f760 kdb_backtrace(c1136ff9,c9684200,c116a0dd,c8da3b58,c1169d15,...) at kdb_backtrace+0x30/frame 0xee33f7c8 witness_checkorder(c9684200,9,c1169d15,11c,0,...) at witness_checkorder+0xc8a/frame 0xee33f818 _sx_xlock(c9684200,0,c1169d15,11c,c973d414,...) at _sx_xlock+0x77/frame 0xee33f848 ufsdirhash_add(c973d414,ee33f940,71e4,ee33f8c8,ee33f8cc,...) at ufsdirhash_add+0x4a/frame 0xee33f878 ufs_direnter(c9b5911c,c9b59000,ee33f940,ee33fb64,e4d5c9c0,...) at ufs_direnter+0x63b/frame 0xee33f8f8 ufs_mkdir(ee33fc00,c12f9e87,c11630ce,c9b5911c,ee33fbfc,...) at ufs_mkdir+0x884/frame 0xee33fa98 VOP_MKDIR_APV(c13bf1a0,ee33fc00,ee33fb64,ee33fb90,88803020,...) at VOP_MKDIR_APV+0x124/frame 0xee33fac8 kern_mkdirat(c96e7c40,ffffff9c,88803020,0,1c0) at kern_mkdirat+0x236/frame 0xee33fc24 sys_mkdir(c96e7c40,ee33fcc8,14,c11314ed,7ba,...) at sys_mkdir+0x31/frame 0xee33fc40 syscall(ee33fd08) at syscall+0x2de/frame 0xee33fcfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xee33fcfc --- syscall (136, FreeBSD ELF32, sys_mkdir), eip = 0x88176097, esp = 0xbfbfd92c, ebp = 0xbfbfddcc --- From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 21:17:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3925E671 for ; Wed, 27 Nov 2013 21:17:05 +0000 (UTC) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE7BD2A0E for ; Wed, 27 Nov 2013 21:17:04 +0000 (UTC) Received: by mail-vb0-f44.google.com with SMTP id w20so5279795vbb.17 for ; Wed, 27 Nov 2013 13:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PaO5ENFiPtrEzTEWL0tgWWfjKWAybsKvrhPSXnNwPwk=; b=yWwDWahjs7K1udBu0a8JxaGKUq5cgBuyi6pzh4kaV2gSZy8SM/UmJnVn4VK/dMa+7O CwSnfEGmogd+9W9ABx78K1uOwjj44/y89FU9wYEqcjZeW2Cg0TCiTcjdxKBT6edvLrbG areWpgCfaM5MTW6iP4xWKrq9Sc4nfiRiv/ZoGE5jIWLlduJP7Gqv/rfJWOhFveLW6xwY NO+97lsL9P++3fkCV3TKjUxcEnnRbCmnXwdPvwZLUx4YBzwYW/0SyCrCeOYnN9RHbCsU IZWpiYRVsWZcYo6+76PRmndA7d0yHkuvn4OYjYnzvgD4zji6XtHoR08hSDaxT2iFTXbU 8uLQ== MIME-Version: 1.0 X-Received: by 10.220.169.203 with SMTP id a11mr10479090vcz.26.1385587024016; Wed, 27 Nov 2013 13:17:04 -0800 (PST) Received: by 10.221.63.6 with HTTP; Wed, 27 Nov 2013 13:17:03 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Nov 2013 22:17:03 +0100 Message-ID: Subject: Re: [request] ntp upgrade From: Cristiano Deana To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 21:17:05 -0000 On Wed, Nov 27, 2013 at 6:21 PM, Tom Evans wrote: > Does it have a CVE? The article is low on content > > I don't think so. I think there were lot of ideas about the DDoS, that's the only article suggesting a right solution (in my experience). I think they are still investigating. Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 21:20:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1777388C for ; Wed, 27 Nov 2013 21:20:54 +0000 (UTC) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBF2E2AAC for ; Wed, 27 Nov 2013 21:20:53 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id c14so5716844vea.0 for ; Wed, 27 Nov 2013 13:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ilDUaOzOB6uYFD2GQg/t7uN+Wbp/7q3jwEzxWesbO4w=; b=RwsIEE5bBpItb9okiii+GkE7gM3xnhOFa3Q17KJEk9F41Lj7MPWS+9/uqOtQxnZAcz C6/1CNk1SG5JJid49JN0/LYhF5sGIvmCAjLFjFl60y36J8K7jeM2ssJ9WAvuRik7Qb2g i4KSrpGAbZwg9vuHwegGT2ATrDKDty/y0tkvIw7q5XnEXOcuwZH27Zp5jp743OdvbxdP /GKJ0Gi2GCY+niSwp86puiH0QL+d2ara5ZchsKtGEGHObCSWQZZ6BQH4jAxn6/IdPfIF 9uIEwccf06bqxfK48G5y5xqGog+S+TOP3JQz1F5qMGTGVT271ZNFoBgdnJHPcL7QT9+g y0Qg== MIME-Version: 1.0 X-Received: by 10.52.164.203 with SMTP id ys11mr1424116vdb.37.1385587240249; Wed, 27 Nov 2013 13:20:40 -0800 (PST) Received: by 10.221.63.6 with HTTP; Wed, 27 Nov 2013 13:20:40 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Nov 2013 22:20:40 +0100 Message-ID: Subject: Re: [request] ntp upgrade From: Cristiano Deana To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 21:20:54 -0000 On Wed, Nov 27, 2013 at 9:03 PM, Olivier Cochard-Labb=E9 wrote: Hi Thanks for this URL, I've meet this problem on my FreeBSD 9.2 few > weeks ago (public NTP registered in the pool.ntp.org). > Same for me. > > There is a thread on the ntp.org ML about this too: > http://lists.ntp.org/pipermail/pool/2013-November/thread.html > > i tried those suggestion too (with "discard" parameter) but it didn't work. When I switched to ntp-devel everything went fine. Just: # service ntpd stop # cd /usr/ports/net/ntp-devel && make -DBATCH install # echo 'ntpd_program=3D"/usr/local/sbin/ntpd"' >> /etc/rc.conf # service ntpd start it will use same /etc/ntp.conf conf file. --=20 Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 27 21:24:58 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C629AC1 for ; Wed, 27 Nov 2013 21:24:58 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0866B2B62 for ; Wed, 27 Nov 2013 21:24:45 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rARLOV4S042894; Wed, 27 Nov 2013 13:24:35 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311272124.rARLOV4S042894@gw.catspoiler.org> Date: Wed, 27 Nov 2013 13:24:31 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131127200050.GE59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 21:24:58 -0000 On 27 Nov, Konstantin Belousov wrote: > And, as the last resort, I do understand that this sounds as giving up, > do you monitor the temperature of the CPUs ? BTW, which CPUs are that, > please show the cpu identification lines from the boot dmesg. Idle temps: hw.acpi.thermal.tz0.temperature: 38.0C dev.cpu.0.temperature: 40.2C dev.cpu.1.temperature: 44.2C dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb3 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 40.5C dev.amdtemp.0.core0.sensor1: 36.2C dev.amdtemp.0.core1.sensor0: 44.5C dev.amdtemp.0.core1.sensor1: 28.7C Running two copies of mprime: hw.acpi.thermal.tz0.temperature: 60.0C dev.cpu.0.temperature: 52.5C dev.cpu.1.temperature: 55.0C dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb3 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 51.7C dev.amdtemp.0.core0.sensor1: 52.2C dev.amdtemp.0.core1.sensor0: 55.0C dev.amdtemp.0.core1.sensor1: 44.0C From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 00:06:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D835748 for ; Thu, 28 Nov 2013 00:06:02 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 245DA7C6 for ; Thu, 28 Nov 2013 00:06:01 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rAS05u90032756 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Nov 2013 16:05:59 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <529688DF.2010600@freebsd.org> Date: Thu, 28 Nov 2013 08:05:51 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Harald Schmalzbauer Subject: Re: Feature request: sticky bit inheritance References: <5295DFAD.5070402@omnilan.de> <52960DB5.3090209@freebsd.org> <52961B25.3020109@omnilan.de> In-Reply-To: <52961B25.3020109@omnilan.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 00:06:02 -0000 On 11/28/13, 12:17 AM, Harald Schmalzbauer wrote: > Bezüglich Julian Elischer's Nachricht vom 27.11.2013 16:20 (localtime): >> On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote: >>> Hello, >>> >>> ever since I took a FreeBSD machine into production, acting as any kind >>> of file server, I have to work arround the problem, that write access to >>> a directory implies unlinking (deleting) directory contents. >> not sure I fully understand what you mean by that.. >> Do you mean write access implies delete access? yes.. >> >> This can be modified with the nounlink flag. > The uunlink flags also prohibits the owner to delete his files as far as > I know. I want to prohibt users from deleting “foreign†files, even if > the user has write access to the parent directory (and I wanted to > explain that I don't understand why anybody would want that a user with > write access to a directory can delete files on which the user doesn't > have write access). You can always unlink a file that is not yours if you own the directory. because the ability to unlink is purely dependent on the directory. You don't change the file, and it may in fact have other links The 'nounlink' flags change this. > The sticky bit exactly does what I need (and should be the default > behaviour in my opinion). > But my problem is that the stick bit must be added to each single > directory after creation, it's not inherited. correct. > I'd need every child directory of directories, who have the sticky bit > set, also to have the sticky bit. The same behaviour as with the gid – > it's the same as the parent has for new directories. "patches accepted" :-) I don't think that you are going to have much chance in changing default unix behaviour, but a patch (that can be disabled) would have a chance if there was a really good reason for it. > > Thanks, > > -Harry > From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 04:25:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AC71FA4; Thu, 28 Nov 2013 04:25:46 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F13341254; Thu, 28 Nov 2013 04:25:45 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id y13so11325546pdi.33 for ; Wed, 27 Nov 2013 20:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=92MOSzoj4eNje/xD66yogAjhv/86Od9MVRFnvgvri5c=; b=tHNDhg+tDp+0ReHTWP32gIiJUVCp4tzn8vC8KiVQZMdcXtg7570EIpvWqY9esHqCSa Ee9NG4NNgjg06pB0brzjAW05h+lFAWzDTwaq//IncOUYtiBo5I+JhA1pJPD+np/5C/Qs e49e0ZGH2Jg5kSnB9hYwDRxmYJ+rmVA0lgA7PTBKRHFn3lDgtH/mteNgFLYhk+niP/7C dJwb1k8Jzlg4jEhz4yItAAszYyxJsOsnRYKllr93xNr5o2dsRQOnOESkgPu2WCfDyRBG KaBOtwKFXfhSMHyXfcwYTZS0znf4A29Vu8xslMn81RI0JWu2gKnygv+A6HAsx3oXvuCZ ma2g== X-Received: by 10.68.233.135 with SMTP id tw7mr8722491pbc.112.1385612745566; Wed, 27 Nov 2013 20:25:45 -0800 (PST) Received: from localhost (rikad42.riken.jp. [134.160.214.42]) by mx.google.com with ESMTPSA id ka3sm91793318pbc.32.2013.11.27.20.25.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 20:25:44 -0800 (PST) Date: Thu, 28 Nov 2013 13:25:40 +0900 (JST) Message-Id: <20131128.132540.2082341321179147888.maho.nakata@gmail.com> To: sgk@troutmask.apl.washington.edu Subject: Re: libc++ vs. libstdc++ usage in the ports tree From: Nakata Maho In-Reply-To: <20131127184302.GA15006@troutmask.apl.washington.edu> References: <20131114144555.GA22093@troutmask.apl.washington.edu> <52963A90.4000201@janh.de> <20131127184302.GA15006@troutmask.apl.washington.edu> X-Mailer: Mew version 6.3 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Nov 2013 05:34:54 +0000 Cc: me@janh.de, dim@FreeBSD.org, theraven@FreeBSD.org, avg@FreeBSD.org, freebsd-current@FreeBSD.org, rysto32@gmail.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 04:25:46 -0000 Hmm thanks for discussion. I'll install and test FBSD 10 in this weekend. thanks Nakata Maho From: Steve Kargl Subject: Re: Re: libc++ vs. libstdc++ usage in the ports tree Date: Wed, 27 Nov 2013 10:43:02 -0800 > On Wed, Nov 27, 2013 at 07:31:44PM +0100, Jan Henrik Sylvester wrote: >> On 11/14/2013 15:45, Steve Kargl wrote: >> > >> > And in practice, it is broken. >> > >> > http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html >> > >> > QED >> >> Trying to migrate to 10, I would like to keep octave. Have you found >> anything new? Having build the port and all dependencies with standard >> options, octave is segfaulting for me, too. Anyhow, I can run octave with: >> >> env LD_PRELOAD=/usr/lib/libc++.so.1 octave >> > > Unfortunately, you need to add "USE_GCC=any" to math/octave/Makefile, > and rebuild it. You theni need to run "ldd -a | more" and search for > shared libraries that are linked against both libc++ and libstdc++. > Then, add "USE_GCC=any" to those ports' Makefile and recompile. > I recall at least 4 that needed to be rebuilt, but only remember > fltk and libgraphite2. > > -- > Steve > From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 07:56:18 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 759127D; Thu, 28 Nov 2013 07:56:18 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB6E91BC8; Thu, 28 Nov 2013 07:56:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAS7uAR0020732; Thu, 28 Nov 2013 09:56:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAS7uAR0020732 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAS7uAZe020731; Thu, 28 Nov 2013 09:56:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Nov 2013 09:56:10 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131128075610.GJ59496@kib.kiev.ua> References: <20131127200050.GE59496@kib.kiev.ua> <201311272111.rARLBZk9042868@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TjICR3deYYRuqXKh" Content-Disposition: inline In-Reply-To: <201311272111.rARLBZk9042868@gw.catspoiler.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: pho@freebsd.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 07:56:18 -0000 --TjICR3deYYRuqXKh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 01:11:35PM -0800, Don Lewis wrote: > On 27 Nov, Konstantin Belousov wrote: > > On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote: > >> On 27 Nov, Konstantin Belousov wrote: > >> > On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: > >> >> On 27 Nov, Konstantin Belousov wrote: > >> >> > On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: > >> >> >> On 27 Nov, Konstantin Belousov wrote: > >> >> >> > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: > >> >> >> >> On 27 Nov, Konstantin Belousov wrote: > >> >> >> >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: > >> >> >> >> >> > >> >> >> >> >=20 > >> >> >> >> > What is the instruction at cpu_switch+0x9b ? > >> >> >> >>=20 > >> >> >> >> movl 0x8(%edx),%eax > >> >> >> > So it is line 176 in swtch.s. Is machine still in ddb, or did = you > >> >> >> > obtained the core ? If yes, please print out the content of wo= rds at > >> >> >> > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the w= ord at > >> >> >> > address (*) + 8. > >> >> >>=20 > >> >> >> It is still in ddb. > >> >> >>=20 > >> >> >> , though n= ot in > >> >> >> the above order. > >> >> > Uhm, sorry, I mistyped the last part of the instructions. > >> >> >=20 > >> >> > The new thread pointer is 0xd2f4e000, there is nothing incriminat= ing. > >> >> > Please print the word at 0xd2f4e000+0x254 =3D=3D 0xd2f4e254, whic= h would be > >> >> > the address of the new thread pcb. It is load from the pcb + 8 wh= ich > >> >> > faults. > >> >>=20 > >> >> 0xf3d44d60 > >> > Again, the pointer looks fine, and its tail is 0xd60, which is corre= ct for > >> > the pcb offset in the last page of the thread stack. > >> >=20 > >> > Please do 'show thread 0xd2f4e000' before trying below instructions. > >>=20 > >> Ok, see below: > >> =20 > >> > What happens if you try to read word at 0xf3d44d68 ? > >>=20 > >> Nothing bad ... > >>=20 > >> > >>=20 > > So the thread structure looks sane, the stack region is in place where > > it is supposed to be, all the gathered data looks self-consistent. And, > > the access to the faulted address from ddb does not fault. > >=20 > > Thread stacks can only be invalidated when the process is swapped out a= nd > > kernel stack is written to swap. Your thread flags indicate that it is > > in memory, and TDF_CANSWAP is not set. I do not believe that our swapo= ut > > code would invalidate stack mapping in such situation, otherwise we wou= ld > > have too many complaints already. > >=20 > > Just in case, do you use swap on this box ? >=20 > I do. >=20 > > And, as the last resort, I do understand that this sounds as giving up, > > do you monitor the temperature of the CPUs ? BTW, which CPUs are that, > > please show the cpu identification lines from the boot dmesg. >=20 > I don't monitor the temperature, but I do hear the CPU fan speed ramping > up and down when I'm building ports like this. Even though I'm pretty > much keeping one core busy the whole time, the temperature must drop > enough at times to let the fan speed drop. >=20 > I can run math/mprime on this machine for a while to see if anything > shows up. I also have a very similar machine (same motherboard but > different CPU) that I can move the drive over to and test. >=20 > Here's the full dmesg.boot: >=20 > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #63 r258614M: Tue Nov 26 00:29:01 PST 2013 > dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB i386 > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2500.06-MHz 686-clas= s CPU) > Origin =3D "AuthenticAMD" Id =3D 0x60fb1 Family =3D 0xf Model =3D 0x= 6b Stepping =3D 1 > Features=3D0x178bfbff > Features2=3D0x2001 > AMD Features=3D0xea500800 > AMD Features2=3D0x11f The errata list for the Athlon 64 X2 is quite long. Do you have latest BIOS ? I am not sure if AMD provides standalone firmware update blocks for their CPUs. If any Linux distribution ships updates for AMD CPUs, it might be useful to load the update with cpucontrol(8). Even if we do not hit a CPU bug, it would provide me with more certainity that we are not chasing ghost. Another things to try, in vain, is to compile kernel with gcc or disable SMP. Peter, could you, please, try to reproduce the issue ? It does not look like a random hardware failure, since in all cases, it is curthread access which is faulting. The issue is only reported by Don, and so far only for i386 SMP. --TjICR3deYYRuqXKh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlvcZAAoJEJDCuSvBvK1BRnoP/1lf1AOF5GA266g/P5yaHzjC pvdKVCY32MuAmhi44JVumIsEoCMPEiioYnOzpmMwWBL068zDoYcLA2WMrU8B4ra/ UCdbtzAh6qaDre/hGSycZ7hzds7KL4V17N01Js8d/p0AF5J/MitR7kbCrt3v/w4U cEfQEC6lQSTw4IMGt5HeP3qLNQ9JpSqbxU/5eXtduze+xa9PBiTUSmQ7+twTQEEt omslHubAiRrVwD2jbV9bxcb/08jpUyfLSREj9Fdyss20EGytfBkJrK9rhFdIb7HZ ZVAPIuH+xIpOnCPNQ0IcSTgO16TPr41P+AnRihq11kJRz9jlfzUW8SeQMasSQ5I7 antuwk2nIPxz32IBphOCuVCVcso7u4kVj6J6k6Aj9TxTLE9jubz3fkSkWQBV58uk YtgKG696mo0K6acLS4xbnoO2181vNiqXFZdWb39af/q00DCLWuMpPSH4WEyN36Mz my/XmZblVN4XOkHpAib0XliMfDb2Xt9lcCXx3seBJ3AtslXzYMP6EpV6JLoNtIKM zb+kZMnX1ayLF4Dd0gQZHZDL1hhEP8XCKuMxfZp7vcySJzTqWbQWO3fpdO2Ms3mP X3o8KfmKiEjLX66V0Ohof3ZE0VuLn1ZQM1GO/yotBrlSjLu6RBXkoJyHyng7EZVi Jffw/d2dQnzc1JxJF8E3 =e1jl -----END PGP SIGNATURE----- --TjICR3deYYRuqXKh-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 08:20:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C41C486; Thu, 28 Nov 2013 08:20:06 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C3E71CCF; Thu, 28 Nov 2013 08:20:05 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAS8K0Lw025018; Thu, 28 Nov 2013 10:20:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAS8K0Lw025018 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAS8K0kJ025017; Thu, 28 Nov 2013 10:20:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Nov 2013 10:20:00 +0200 From: Konstantin Belousov To: Adrian Chadd Subject: Re: [review] sendfile / sendfile_sync refactoring Message-ID: <20131128082000.GK59496@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H55dy74Id38Dzf32" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current , Gleb Smirnoff , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 08:20:06 -0000 --H55dy74Id38Dzf32 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 11:36:44AM -0800, Adrian Chadd wrote: > Hi, >=20 > Here's part #2 in my sendfile refactoring. This is a little more > intrusive than the first patch. >=20 > http://people.freebsd.org/~adrian/netflix/20131126-sendfile-sync-refactor= -2.diff >=20 sf_buf.h is for sf buffers, and not for sendfile stuff. Please do not pollute this header. The changes you have to make to if_ti.c illustrate my point. The sys/event.h change of adding new kevent type is useless now and=20 has no relation to the rest of the patch. Patch has too many XXX notes for its triviality, some of which are baseless, e.g. the comment for struct sendfile_sync forward declaration in sys/file.h. You extracted all sfs accesses from the sendfile implementation, except the one in sf_buf_mext(). This is weird, please move the code from sf_buf_mext() into static function and put it near sf_sync_ref(). While moving the code into sf_sync_syscall_wait(), please use the opportunity and replace the if (sfs->count !=3D 0) with the while () cv_wait(); loop, to avoid spurious wakeups. I do not see any use for sfs->flags. Also, I do not see any use for passing the flags masked with SF_SYNC, which is always set, to sf_sync_alloc(). If the flags are going to be useful later, it should be added when needed later. The sf_sync_* stuff in the compat32 code just duplicates the main syscall. It should be done in the common code. > My aim here is to move the sendfile_sync stuff out of uipc_syscalls.c > and out of sendfile-only code and into something that can be reused > elsewhere or replaced later on. I've created methods for all the > sendfile_sync stuff, I've moved it out of the do_sendfile() loop so > do_sendfile() doesn't specifically implement the completion behaviour. As is, the patch is sincere nop. Modulo the comments above, I do not object against it. --H55dy74Id38Dzf32 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlvywAAoJEJDCuSvBvK1Bs9gP/iv7zcSWRf51kPbynKkWlM42 XZx4Tg6OnMkykU/G/M5091AyBgtM6NdJcalmtn5suFST5xa42gP0XXhWx7PhRdTQ m+tCqEqs19QNhElDCQ9a/BtemTuEN1ZIg4vYyXpG1qH4mWK+hJr+zJrQNcEMUXDo P3n4t7H5p4z9+20ETIQUGMqyuP0xHlAafvljGTuDzgDfk+y/3LN8Y8bM6VTGDm9B NzCbkP4cvMzuoeGiHOzpv13xd7jiLPJxaDbzUJQNQblWR1j9cWZe/z4AnAeZpm3z n5Pon2SeDxIi3i8p357J3H4UouDEwN52yt7DaXCUTSaRjI1T1ElDmMOnZAkl3YxX f8ZWP+YtJCaS+ZOW3OzV6pIqDVNkLpXuuNrsj2AISNNyz7SxwL7WEB3aRGaksj1f IVEBGs0CDboG0DYO49AFcEJCih1c6FvSvKyzkI6dvyX6L+1di3BnrpIIe7SKxUfb bxl6vxuGuFHSQhGKcb6eT9D6RaDIrQBhHzyvMWaWGFqdITOSH/7uHqk5twYfFBN8 8hd4NVEG8Q3zv6UHjWX+wYf3Vs/NcZ9ayEWjimdSsUqykuerDBUfTWm5t6uuupNp QxiHGI85nEGx2xxiQW22vLn1ESeaP0oY7qWXd3i9GcUP3h0p5uVnpB+ZYPbP+1s9 v991+RluwIIic34q+5I8 =MPo5 -----END PGP SIGNATURE----- --H55dy74Id38Dzf32-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 08:27:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B5746E7; Thu, 28 Nov 2013 08:27:17 +0000 (UTC) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD72B1D32; Thu, 28 Nov 2013 08:27:16 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id rAS8RCYe026792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Nov 2013 09:27:12 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5296FE5B.6050208@omnilan.de> Date: Thu, 28 Nov 2013 09:27:07 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Julian Elischer Subject: Re: Feature request: sticky bit inheritance References: <5295DFAD.5070402@omnilan.de> <52960DB5.3090209@freebsd.org> <52961B25.3020109@omnilan.de> <529688DF.2010600@freebsd.org> In-Reply-To: <529688DF.2010600@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2E4C172526AE87581B107F4F" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 08:27:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2E4C172526AE87581B107F4F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Julian Elischer's Nachricht vom 28.11.2013 01:05 (localti= me): > On 11/28/13, 12:17 AM, Harald Schmalzbauer wrote: >> Bez=C3=BCglich Julian Elischer's Nachricht vom 27.11.2013 16:20 >> (localtime): >>> On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote: >>>> Hello, >>>> >>>> ever since I took a FreeBSD machine into production, acting as any >>>> kind >>>> of file server, I have to work arround the problem, that write >>>> access to >>>> a directory implies unlinking (deleting) directory contents. >>> not sure I fully understand what you mean by that.. >>> Do you mean write access implies delete access? yes.. >>> >>> This can be modified with the nounlink flag. >> The uunlink flags also prohibits the owner to delete his files as far = as >> I know. I want to prohibt users from deleting =E2=80=9Cforeign=E2=80=9D= files, even if >> the user has write access to the parent directory (and I wanted to >> explain that I don't understand why anybody would want that a user wit= h >> write access to a directory can delete files on which the user doesn't= >> have write access). > > You can always unlink a file that is not yours if you own the directory= =2E > because the ability to unlink is purely dependent on the directory. > You don't change the file, and it may in fact have other links I have an idea why this kind of permission ist default: It's more expensive to extra check the file permission copmpared to only check the directory permission, the only part which will be altered any way. I guess having the sticky bit set by default would cause extra I/O+check, which might have been too expensive in the past=E2=80=A6 So the default w= as to do as less work as needed?!? =2E.. >> I'd need every child directory of directories, who have the sticky bit= >> set, also to have the sticky bit. The same behaviour as with the gid =E2= =80=93 >> it's the same as the parent has for new directories. > "patches accepted" :-) Besides horrible C skills, I have no idea where and how to start :-( I hoped somebody else with deeper knowledge is also suffering badly and someone could at least estimate the effort (in hours) needed to implement a inhert-stickybit kernconf option, or even better, a sysctl. Maybe I can pay for it. Thanks, -Harry --------------enig2E4C172526AE87581B107F4F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlKW/mAACgkQLDqVQ9VXb8hzKwCeLmlUvMcvXzRsqBtWlcxqEH4g /bIAoJEnSE6HObbV4d341S/0iQvPp8l5 =QHPy -----END PGP SIGNATURE----- --------------enig2E4C172526AE87581B107F4F-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 08:33:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB40E886; Thu, 28 Nov 2013 08:33:09 +0000 (UTC) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 661CF1D8A; Thu, 28 Nov 2013 08:33:09 +0000 (UTC) Received: by mail-qe0-f41.google.com with SMTP id gh4so6251511qeb.0 for ; Thu, 28 Nov 2013 00:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CZB3Yt/dOFXcZK5gTD2hVMe4YLuhFVyzTBRbQlOZMhU=; b=Jx5aAIdGBlW0WlDahoK60Jps8ESnOqZcvqmkxxwFF/ZgSFipgSz58iOpv4JHUgG/3F eZtIdDPqw7W0cH63EOyhqaEFg+OfILDcbZT9JkT2QhOabftHbJVoOi4WOFGSrLYEpUhB X2v04n1NKX9MA+aXzoGQxloTyyNTBWi9XIjk6h9zEr+HVn5sOWd3gC17vl0g67QubKpX dn8w75pUdWDgnA1M0FKc6mUKpshuEOvusMnZ0VAYF4spGC8Rh05snWqGKmNy9DN/1CRE HfDbGSeBtyinWKFNiaOIaOsTQ0H+cfCv9CGOlCc8VI4p50w3MZb2AdOZkEX8/2iMMhVv SVLQ== MIME-Version: 1.0 X-Received: by 10.224.111.197 with SMTP id t5mr74848653qap.49.1385627587884; Thu, 28 Nov 2013 00:33:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Thu, 28 Nov 2013 00:33:07 -0800 (PST) In-Reply-To: <20131128082000.GK59496@kib.kiev.ua> References: <20131128082000.GK59496@kib.kiev.ua> Date: Thu, 28 Nov 2013 00:33:07 -0800 X-Google-Sender-Auth: R-KhTJ2Tg2a8hK0JPoWnR4Q9HCA Message-ID: Subject: Re: [review] sendfile / sendfile_sync refactoring From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , Gleb Smirnoff , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 08:33:10 -0000 Hi, It's definitely a work in progress, as you've observed. On 28 November 2013 00:20, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 11:36:44AM -0800, Adrian Chadd wrote: >> Hi, >> >> Here's part #2 in my sendfile refactoring. This is a little more >> intrusive than the first patch. >> >> http://people.freebsd.org/~adrian/netflix/20131126-sendfile-sync-refactor-2.diff >> > sf_buf.h is for sf buffers, and not for sendfile stuff. Please do not > pollute this header. The changes you have to make to if_ti.c illustrate > my point. Yup. I don't like having it in here either. I may create a new header file specifically for this. > The sys/event.h change of adding new kevent type is useless now and > has no relation to the rest of the patch. Yeah, ignore that bit. I'm working on adding code for that. > > Patch has too many XXX notes for its triviality, some of which are > baseless, e.g. the comment for struct sendfile_sync forward declaration > in sys/file.h. > > You extracted all sfs accesses from the sendfile implementation, except > the one in sf_buf_mext(). This is weird, please move the code from > sf_buf_mext() into static function and put it near sf_sync_ref(). I plan on doing that soon. > While moving the code into sf_sync_syscall_wait(), please use the > opportunity and replace the if (sfs->count != 0) with the while () > cv_wait(); loop, to avoid spurious wakeups. > > I do not see any use for sfs->flags. Also, I do not see any use > for passing the flags masked with SF_SYNC, which is always set, to > sf_sync_alloc(). If the flags are going to be useful later, it should > be added when needed later. It's just precursor work to add support for other SF_* flags - specifically, a new kqueue notification flag for completion. > The sf_sync_* stuff in the compat32 code just duplicates the main > syscall. It should be done in the common code. The main motivation for moving the sendfile_sync setup and teardown out of do_sendfile() is so do_sendfile() can keep a very little/light idea of the behaviour of sendfile_sync. I don't mind keeping the code in there. Thanks for your feedback. I'll post an updated diff when I've fleshed out some more of this. -a From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 08:53:10 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B0EAD71; Thu, 28 Nov 2013 08:53:10 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 96B851E81; Thu, 28 Nov 2013 08:53:08 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA19929; Thu, 28 Nov 2013 10:53:06 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VlxLN-0009d1-Ql; Thu, 28 Nov 2013 10:53:05 +0200 Message-ID: <52970439.3070406@FreeBSD.org> Date: Thu, 28 Nov 2013 10:52:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org, FreeBSD Current , freebsd-fs@FreeBSD.org Subject: Re: [HEADSUP!!!] do not upgrade to or past r258632 if you use ZFS + TRIM References: <201311260957.rAQ9vF6d004168@svn.freebsd.org> <52961B2E.1080602@FreeBSD.org> In-Reply-To: <52961B2E.1080602@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 08:53:10 -0000 on 27/11/2013 18:17 Andriy Gapon said the following: > on 26/11/2013 11:57 Andriy Gapon said the following: >> Author: avg >> Date: Tue Nov 26 09:57:14 2013 >> New Revision: 258632 >> URL: http://svnweb.freebsd.org/changeset/base/258632 >> >> Log: >> MFV r255255: 4045 zfs write throttle & i/o scheduler performance work >> >> illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e >> >> Please note the following changes: >> - zio_ioctl has lost its priority parameter and now TRIM is executed >> with 'now' priority >> - some knobs are gone and some new knobs are added; not all of them are >> exposed as tunables / sysctls yet >> >> MFC after: 10 days >> Sponsored by: HybridCluster [merge] > > I think that I've introduced a very serious bug when merging this change. > Please do not upgrade to this revision if you use ZFS with SSDs and have TRIM > support enabled. > > If you have already upgraded, please disable TRIM support ASAP and roll back to > a previous version of kernel and then check integrity of your pools. The issue should be fixed in r258704. Yes, the bug was that simple and that serious. My apologies to all who were affected. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 08:56:52 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B35A8248; Thu, 28 Nov 2013 08:56:52 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 852EA1EB7; Thu, 28 Nov 2013 08:56:52 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAS8ubLR044563; Thu, 28 Nov 2013 00:56:41 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311280856.rAS8ubLR044563@gw.catspoiler.org> Date: Thu, 28 Nov 2013 00:56:37 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131128075610.GJ59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: pho@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 08:56:52 -0000 On 28 Nov, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 01:11:35PM -0800, Don Lewis wrote: >> On 27 Nov, Konstantin Belousov wrote: >> > On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote: >> >> On 27 Nov, Konstantin Belousov wrote: >> >> > On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: >> >> >> On 27 Nov, Konstantin Belousov wrote: >> >> >> > On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: >> >> >> >> On 27 Nov, Konstantin Belousov wrote: >> >> >> >> > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: >> >> >> >> >> On 27 Nov, Konstantin Belousov wrote: >> >> >> >> >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > What is the instruction at cpu_switch+0x9b ? >> >> >> >> >> >> >> >> >> >> movl 0x8(%edx),%eax >> >> >> >> > So it is line 176 in swtch.s. Is machine still in ddb, or did you >> >> >> >> > obtained the core ? If yes, please print out the content of words at >> >> >> >> > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at >> >> >> >> > address (*) + 8. >> >> >> >> >> >> >> >> It is still in ddb. >> >> >> >> >> >> >> >> , though not in >> >> >> >> the above order. >> >> >> > Uhm, sorry, I mistyped the last part of the instructions. >> >> >> > >> >> >> > The new thread pointer is 0xd2f4e000, there is nothing incriminating. >> >> >> > Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be >> >> >> > the address of the new thread pcb. It is load from the pcb + 8 which >> >> >> > faults. >> >> >> >> >> >> 0xf3d44d60 >> >> > Again, the pointer looks fine, and its tail is 0xd60, which is correct for >> >> > the pcb offset in the last page of the thread stack. >> >> > >> >> > Please do 'show thread 0xd2f4e000' before trying below instructions. >> >> >> >> Ok, see below: >> >> >> >> > What happens if you try to read word at 0xf3d44d68 ? >> >> >> >> Nothing bad ... >> >> >> >> >> >> >> > So the thread structure looks sane, the stack region is in place where >> > it is supposed to be, all the gathered data looks self-consistent. And, >> > the access to the faulted address from ddb does not fault. >> > >> > Thread stacks can only be invalidated when the process is swapped out and >> > kernel stack is written to swap. Your thread flags indicate that it is >> > in memory, and TDF_CANSWAP is not set. I do not believe that our swapout >> > code would invalidate stack mapping in such situation, otherwise we would >> > have too many complaints already. >> > >> > Just in case, do you use swap on this box ? >> >> I do. >> >> > And, as the last resort, I do understand that this sounds as giving up, >> > do you monitor the temperature of the CPUs ? BTW, which CPUs are that, >> > please show the cpu identification lines from the boot dmesg. >> >> I don't monitor the temperature, but I do hear the CPU fan speed ramping >> up and down when I'm building ports like this. Even though I'm pretty >> much keeping one core busy the whole time, the temperature must drop >> enough at times to let the fan speed drop. >> >> I can run math/mprime on this machine for a while to see if anything >> shows up. I also have a very similar machine (same motherboard but >> different CPU) that I can move the drive over to and test. >> >> Here's the full dmesg.boot: >> >> Copyright (c) 1992-2013 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 11.0-CURRENT #63 r258614M: Tue Nov 26 00:29:01 PST 2013 >> dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB i386 >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> WARNING: WITNESS option enabled, expect reduced performance. >> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2500.06-MHz 686-class CPU) >> Origin = "AuthenticAMD" Id = 0x60fb1 Family = 0xf Model = 0x6b Stepping = 1 >> Features=0x178bfbff >> Features2=0x2001 >> AMD Features=0xea500800 >> AMD Features2=0x11f > > The errata list for the Athlon 64 X2 is quite long. Do you have latest > BIOS ? I am not sure if AMD provides standalone firmware update blocks > for their CPUs. If any Linux distribution ships updates for AMD CPUs, > it might be useful to load the update with cpucontrol(8). Even if we > do not hit a CPU bug, it would provide me with more certainity that we > are not chasing ghost. I haven't figured out how to find the currently installed BIOS version. The motherboard is Abit, which is no more, but I found an archive of all of their downloads. I'll also check into updates from the Linux world. > Another things to try, in vain, is to compile kernel with gcc or disable > SMP. It has survived 10 hours running two copies of mprime. I just moved the boot drive over to another machine with the the same type of motherboard, but a different model AMD X2 CPU. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2200.05-MHz 686-class CPU ) Origin = "AuthenticAMD" Id = 0x40fb2 Family = 0xf Model = 0x4b Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 2147483648 (2048 MB) avail memory = 1940611072 (1850 MB) I also have a fairly new quad core AMD box I can test on, as well as an old dual P III machine. This machine gets updated every month or so and I've never had stability problems with it until just recently. It's definitely been using clang for quite a while without any problems other than the ports mess. > Peter, could you, please, try to reproduce the issue ? It does not look > like a random hardware failure, since in all cases, it is curthread access > which is faulting. The issue is only reported by Don, and so far only > for i386 SMP. The workload that is triggering this is portupgrade -fr lang/perl5.16 I've got 1000+ ports installed and this causes 400+ to be rebuilt. That seems to cause it to panic about half the time. The last time it made it through 268 ports before it croaked. From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 09:23:43 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 994C9888; Thu, 28 Nov 2013 09:23:43 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1FE981039; Thu, 28 Nov 2013 09:23:42 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAS9NbOL043854; Thu, 28 Nov 2013 11:23:37 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAS9NbOL043854 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAS9Nb9P043853; Thu, 28 Nov 2013 11:23:37 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Nov 2013 11:23:37 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131128092337.GL59496@kib.kiev.ua> References: <20131128075610.GJ59496@kib.kiev.ua> <201311280856.rAS8ubLR044563@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ClNGE9wjI6a/CVmZ" Content-Disposition: inline In-Reply-To: <201311280856.rAS8ubLR044563@gw.catspoiler.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: pho@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 09:23:43 -0000 --ClNGE9wjI6a/CVmZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 28, 2013 at 12:56:37AM -0800, Don Lewis wrote: > I haven't figured out how to find the currently installed BIOS version. > The motherboard is Abit, which is no more, but I found an archive of all > of their downloads. I'll also check into updates from the Linux world. I reviewed the 0xF family revision guide, and stumbled upon errata 122, "TLB Flush Filter May Cause Coherency Problem in Multicore Systems". You could try the patch at the end of message. > This machine gets updated every month or so and I've never had stability > problems with it until just recently. It's definitely been using clang > for quite a while without any problems other than the ports mess. Is it possible to bisect ? diff --git a/sys/amd64/amd64/initcpu.c b/sys/amd64/amd64/initcpu.c index 34a362d..87e3f69 100644 --- a/sys/amd64/amd64/initcpu.c +++ b/sys/amd64/amd64/initcpu.c @@ -88,6 +88,11 @@ static void init_amd(void) { =20 + if (CPUID_TO_FAMILY(cpu_id) =3D=3D 0x9) { + if ((cpu_feature2 & CPUID2_HV) =3D=3D 0) + wrmsr(MSR_HWCR, rdmsr(MSR_HWCR) | (1 << 6)); + } + /* * Work around Erratum 721 for Family 10h and 12h processors. * These processors may incorrectly update the stack pointer diff --git a/sys/i386/i386/initcpu.c b/sys/i386/i386/initcpu.c index 71c57b2..662ea8e 100644 --- a/sys/i386/i386/initcpu.c +++ b/sys/i386/i386/initcpu.c @@ -651,6 +651,32 @@ init_transmeta(void) } #endif =20 +static void +init_amd(void) +{ + +#ifdef CPU_ATHLON_SSE_HACK + /* + * Sometimes the BIOS doesn't enable SSE instructions. + * According to AMD document 20734, the mobile Duron, the + * (mobile) Athlon 4 and the Athlon MP support SSE. These + * correspond to cpu_id 0x66X or 0x67X. + */ + if ((cpu_feature & CPUID_XMM) =3D=3D 0 && ((cpu_id & ~0xf) =3D=3D 0x660 || + (cpu_id & ~0xf) =3D=3D 0x670 || (cpu_id & ~0xf) =3D=3D 0x680)) { + u_int regs[4]; + + wrmsr(MSR_HWCR, rdmsr(MSR_HWCR) & ~0x08000); + do_cpuid(1, regs); + cpu_feature =3D regs[3]; + } +#endif + if (CPUID_TO_FAMILY(cpu_id) =3D=3D 0x9) { + if ((cpu_feature2 & CPUID2_HV) =3D=3D 0) + wrmsr(MSR_HWCR, rdmsr(MSR_HWCR) | (1 << 6)); + } +} + /* * Initialize CR4 (Control register 4) to enable SSE instructions. */ @@ -725,26 +751,9 @@ initializecpu(void) break; } break; -#ifdef CPU_ATHLON_SSE_HACK case CPU_VENDOR_AMD: - /* - * Sometimes the BIOS doesn't enable SSE instructions. - * According to AMD document 20734, the mobile - * Duron, the (mobile) Athlon 4 and the Athlon MP - * support SSE. These correspond to cpu_id 0x66X - * or 0x67X. - */ - if ((cpu_feature & CPUID_XMM) =3D=3D 0 && - ((cpu_id & ~0xf) =3D=3D 0x660 || - (cpu_id & ~0xf) =3D=3D 0x670 || - (cpu_id & ~0xf) =3D=3D 0x680)) { - u_int regs[4]; - wrmsr(MSR_HWCR, rdmsr(MSR_HWCR) & ~0x08000); - do_cpuid(1, regs); - cpu_feature =3D regs[3]; - } + init_amd(); break; -#endif case CPU_VENDOR_CENTAUR: init_via(); break; --ClNGE9wjI6a/CVmZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlwuZAAoJEJDCuSvBvK1BHF4P/AhxoGwDlkQZDUhP7TbL4SjQ ZbZdz64oCWCBADG38WfuIvGxpz59UMcFkYQbCGjFlnq/NjFtwh67q7vHhhUfO5Xu PBeTXytfyNbsN+b37eSFTnFtr8ENYj5qrmtX3pMCiil/zYB3nfkhw3RYE6k4rGPo vx2rVAGIpvtkSL5CxV9A2S+eJe4N3Kr/eTwlYBq4tHVhtvajU00ncXFoRFfsDsiu WKFhq1g759kRuKGshr7vP9cidHN9ycBZU1PruoZU+Bg5sF4q2EpYhL5iyETAGqhn LTJHprIYiFk2yx2afNyV8mrteyERnBnyFoiYjvEESC9GIGMi7Agtc3CvY3TMMSRN UDyt/AY9IZeXl6FMP3jN0qH+zvMSjupflVuwAK98QCpzr6oO/ONk1PDpmXhURhrY To+0Efzo8LQr52Q94w2jS2ZlyC82l7fDtSbPvh+b1AR4W+G6MQ0vai/H/PO8nF/f 9bWwYNdBCBkc9ZCBSi5XRF09YZVz8GMk0SgdeNfYCpy1Rbl+qUlDckTo7yzbmZYe 4drSAqbTf9aIXHB+Hbr4gvjK/Fi4noStLSlS/heFrzInS3VWK2f8F/i7UTH5XEL1 mmtqwRaa4mg55lbykZ+fDfCECEOT5Htl0LgHfwe52JU3UZHVRrGbGYFCC/8z3gqq fN943y5C1+RSdwvn017Y =dLwf -----END PGP SIGNATURE----- --ClNGE9wjI6a/CVmZ-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 09:33:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0B41D3B for ; Thu, 28 Nov 2013 09:33:08 +0000 (UTC) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 9628710DA for ; Thu, 28 Nov 2013 09:33:08 +0000 (UTC) Received: (qmail 3689 invoked from network); 28 Nov 2013 09:33:01 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay03.pair.com with SMTP; 28 Nov 2013 09:33:01 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id rAS9X0ji066542; Thu, 28 Nov 2013 10:33:00 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id rAS9X0RJ066541; Thu, 28 Nov 2013 10:33:00 +0100 (CET) (envelope-from pho) Date: Thu, 28 Nov 2013 10:33:00 +0100 From: Peter Holm To: Konstantin Belousov Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131128093300.GB66346@x2.osted.lan> References: <20131127200050.GE59496@kib.kiev.ua> <201311272111.rARLBZk9042868@gw.catspoiler.org> <20131128075610.GJ59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131128075610.GJ59496@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Don Lewis , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 09:33:08 -0000 On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 01:11:35PM -0800, Don Lewis wrote: > > On 27 Nov, Konstantin Belousov wrote: > > > On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote: > > >> On 27 Nov, Konstantin Belousov wrote: > > >> > On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: > > >> >> On 27 Nov, Konstantin Belousov wrote: > > >> >> > On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: > > >> >> >> On 27 Nov, Konstantin Belousov wrote: > > >> >> >> > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: > > >> >> >> >> On 27 Nov, Konstantin Belousov wrote: > > >> >> >> >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: > > >> >> >> >> >> > > >> >> >> >> > > > >> >> >> >> > What is the instruction at cpu_switch+0x9b ? > > >> >> >> >> > > >> >> >> >> movl 0x8(%edx),%eax > > >> >> >> > So it is line 176 in swtch.s. Is machine still in ddb, or did you > > >> >> >> > obtained the core ? If yes, please print out the content of words at > > >> >> >> > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at > > >> >> >> > address (*) + 8. > > >> >> >> > > >> >> >> It is still in ddb. > > >> >> >> > > >> >> >> , though not in > > >> >> >> the above order. > > >> >> > Uhm, sorry, I mistyped the last part of the instructions. > > >> >> > > > >> >> > The new thread pointer is 0xd2f4e000, there is nothing incriminating. > > >> >> > Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be > > >> >> > the address of the new thread pcb. It is load from the pcb + 8 which > > >> >> > faults. > > >> >> > > >> >> 0xf3d44d60 > > >> > Again, the pointer looks fine, and its tail is 0xd60, which is correct for > > >> > the pcb offset in the last page of the thread stack. > > >> > > > >> > Please do 'show thread 0xd2f4e000' before trying below instructions. > > >> > > >> Ok, see below: > > >> > > >> > What happens if you try to read word at 0xf3d44d68 ? > > >> > > >> Nothing bad ... > > >> > > >> > > >> > > > So the thread structure looks sane, the stack region is in place where > > > it is supposed to be, all the gathered data looks self-consistent. And, > > > the access to the faulted address from ddb does not fault. > > > > > > Thread stacks can only be invalidated when the process is swapped out and > > > kernel stack is written to swap. Your thread flags indicate that it is > > > in memory, and TDF_CANSWAP is not set. I do not believe that our swapout > > > code would invalidate stack mapping in such situation, otherwise we would > > > have too many complaints already. > > > > > > Just in case, do you use swap on this box ? > > > > I do. > > > > > And, as the last resort, I do understand that this sounds as giving up, > > > do you monitor the temperature of the CPUs ? BTW, which CPUs are that, > > > please show the cpu identification lines from the boot dmesg. > > > > I don't monitor the temperature, but I do hear the CPU fan speed ramping > > up and down when I'm building ports like this. Even though I'm pretty > > much keeping one core busy the whole time, the temperature must drop > > enough at times to let the fan speed drop. > > > > I can run math/mprime on this machine for a while to see if anything > > shows up. I also have a very similar machine (same motherboard but > > different CPU) that I can move the drive over to and test. > > > > Here's the full dmesg.boot: > > > > Copyright (c) 1992-2013 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 11.0-CURRENT #63 r258614M: Tue Nov 26 00:29:01 PST 2013 > > dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB i386 > > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > > WARNING: WITNESS option enabled, expect reduced performance. > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2500.06-MHz 686-class CPU) > > Origin = "AuthenticAMD" Id = 0x60fb1 Family = 0xf Model = 0x6b Stepping = 1 > > Features=0x178bfbff > > Features2=0x2001 > > AMD Features=0xea500800 > > AMD Features2=0x11f > > The errata list for the Athlon 64 X2 is quite long. Do you have latest > BIOS ? I am not sure if AMD provides standalone firmware update blocks > for their CPUs. If any Linux distribution ships updates for AMD CPUs, > it might be useful to load the update with cpucontrol(8). Even if we > do not hit a CPU bug, it would provide me with more certainity that we > are not chasing ghost. > > Another things to try, in vain, is to compile kernel with gcc or disable > SMP. > > Peter, could you, please, try to reproduce the issue ? It does not look > like a random hardware failure, since in all cases, it is curthread access > which is faulting. The issue is only reported by Don, and so far only > for i386 SMP. I'm running tests right now. - Peter From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 09:49:24 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD94C1BB; Thu, 28 Nov 2013 09:49:24 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BFB1011DC; Thu, 28 Nov 2013 09:49:24 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAS9nFdU044639; Thu, 28 Nov 2013 01:49:19 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311280949.rAS9nFdU044639@gw.catspoiler.org> Date: Thu, 28 Nov 2013 01:49:15 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131128092337.GL59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: pho@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 09:49:24 -0000 On 28 Nov, Konstantin Belousov wrote: > On Thu, Nov 28, 2013 at 12:56:37AM -0800, Don Lewis wrote: >> I haven't figured out how to find the currently installed BIOS version. >> The motherboard is Abit, which is no more, but I found an archive of all >> of their downloads. I'll also check into updates from the Linux world. > I reviewed the 0xF family revision guide, and stumbled upon errata 122, > "TLB Flush Filter May Cause Coherency Problem in Multicore Systems". > You could try the patch at the end of message. I'll give it a try after my current test run, but it will probably be a few days before I have results. >> This machine gets updated every month or so and I've never had stability >> problems with it until just recently. It's definitely been using clang >> for quite a while without any problems other than the ports mess. > Is it possible to bisect ? Yes, though that could take quite a while since each iteration will take about two days. From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 11:17:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B5AD857 for ; Thu, 28 Nov 2013 11:17:59 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 26457175A for ; Thu, 28 Nov 2013 11:17:58 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id q8so6009195lbi.40 for ; Thu, 28 Nov 2013 03:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=SifdWtsMTFaSY1s4ytk9V8Z7r1diUauXug+cJoD8ExM=; b=gar26gckzSZG4bXGWgXJWSQWsX4KD9sPPXf9fa+dLEhanOJYepgYU7YdVvE4HGkgrG h9d+cR9hAGLcnETTtzfHE4Q8dvhg0FXeVLgWRPFUsp7kLrk8dyGeXxHtuoMEbfblB+uV uhgwXTyLgi/m1jttgs12RP0dhcvkPoDziJSTqHEnWubiKEo4JQ/yMkl6jLiyZjGxFbHm CL0auUB0iKuz+6XFnBpkAVp9N53iyfGArtAyFfgCUiaLBlR2uBA3cY+G6NcDy7IzIB0g TbPybxUrjyiCA8ujo5aWDghvFWoy/UpbDRca2KhgWFXbIpqtTostHl3xsE4dbyQk5QBR Qacw== MIME-Version: 1.0 X-Received: by 10.112.141.166 with SMTP id rp6mr4236668lbb.39.1385637477048; Thu, 28 Nov 2013 03:17:57 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Thu, 28 Nov 2013 03:17:56 -0800 (PST) Date: Thu, 28 Nov 2013 03:17:56 -0800 X-Google-Sender-Auth: LodEDk-nEqPYNMR49_7IMfW2_58 Message-ID: Subject: [RFC] how to get the size of a malloc(9) block ? From: Luigi Rizzo To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 11:17:59 -0000 in porting some linux kernel code to FreeBSD we stumbled upon ksize(), which returns the actual size of a kmalloc() block. We could easily implement it as the first part of realloc(9) -- see kern/kern_malloc.c Would it make sense to add this to the malloc(9) API ? The userspace equivalent seems to be malloc_usable_size(3) which according to the manpage appeared in FreeBSD 7.0 cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 13:34:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B37481DF for ; Thu, 28 Nov 2013 13:34:15 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6FDE41E39 for ; Thu, 28 Nov 2013 13:34:15 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vm1jF-0007w6-LX for freebsd-current@freebsd.org; Thu, 28 Nov 2013 14:34:03 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Nov 2013 14:34:01 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Nov 2013 14:34:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Thu, 28 Nov 2013 13:33:41 +0000 (UTC) Lines: 50 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 13:34:15 -0000 Luigi Rizzo iet.unipi.it> writes: > > in porting some linux kernel code to FreeBSD we > stumbled upon ksize(), which returns the > actual size of a kmalloc() block. > > We could easily implement it as the first part > of realloc(9) -- see kern/kern_malloc.c > > Would it make sense to add this to the malloc(9) API ? > The userspace equivalent seems to be > malloc_usable_size(3) which according to the > manpage appeared in FreeBSD 7.0 Hi, The implementation of ksize() depends on (has non-standard behavior across) architectures, memory allocators, page sizes, C libs, etc. It means, ksize() exports its implementation details to the caller, and this disqualifies it, regardless whether in kernel or user spaces. This leads to dangerous and conflicting assertions: malloc_usable_size(3) on Linux: NOTES The value returned by malloc_usable_size() may be greater than the requested size of the allocation because of alignment and minimum size constraints. Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice: the number of excess bytes in an allocation depends on the underlying implementation. The main use of this function is for debugging and introspection. Other sources: ... The caller may use this additional memory, even though a smaller amount of memory was initially specified with the kmalloc call. ... This is hair-raising: http://lwn.net/Articles/319686/ Result ? The same code works here, but may not elsewhere. It follows, you should remove malloc_usable_size() from user space instead. jb From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 14:10:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34D5187C for ; Thu, 28 Nov 2013 14:10:55 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id EB54D101B for ; Thu, 28 Nov 2013 14:10:53 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 4DFB37300B; Thu, 28 Nov 2013 15:06:37 +0100 (CET) Date: Thu, 28 Nov 2013 15:06:37 +0100 From: Luigi Rizzo To: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <20131128140637.GA62346@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 14:10:55 -0000 On Thu, Nov 28, 2013 at 01:33:41PM +0000, jb wrote: > Luigi Rizzo iet.unipi.it> writes: > > > > > in porting some linux kernel code to FreeBSD we > > stumbled upon ksize(), which returns the > > actual size of a kmalloc() block. > > > > We could easily implement it as the first part > > of realloc(9) -- see kern/kern_malloc.c > > > > Would it make sense to add this to the malloc(9) API ? > > The userspace equivalent seems to be > > malloc_usable_size(3) which according to the > > manpage appeared in FreeBSD 7.0 > > Hi, > > The implementation of ksize() depends on (has non-standard behavior across) > architectures, memory allocators, page sizes, C libs, etc. > > It means, ksize() exports its implementation details to the caller, and this > disqualifies it, regardless whether in kernel or user spaces. > > This leads to dangerous and conflicting assertions: > > malloc_usable_size(3) on Linux: > NOTES > The value returned by malloc_usable_size() may be greater than the > requested size of the allocation because of alignment and minimum size > constraints. Although the excess bytes can be overwritten by the > application without ill effects, this is not good programming practice: > the number of excess bytes in an allocation depends on the underlying > implementation. > > The main use of this function is for debugging and introspection. This is the same exact text we have in the FreeBSD manpage, and exactly the behaviour of ksize() in the linux kernel (and exactly the semantics that our realloc(9) relies upon). While I personally prefer that applications call realloc() directly, there might be cases where the decision is best left to the application (or kernel code): e.g. say you would like to get some extra space, but would rather do without it than risk a malloc() failure or having to sleep for the allocation. And there is also a (minor) issue of portability of code. But I don't understand why you find ksize()/malloc_usable_size() dangerous. Of course the result depends on the underlying implementation, but this happens in a ton of places including compiler behaviour and system calls. The danger is when the programmer makes assumptions that do not match reality, but the purpose of this call seems to be exactly the opposite: avoid making assumptions. cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 15:14:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2741E21 for ; Thu, 28 Nov 2013 15:14:20 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D72D1375 for ; Thu, 28 Nov 2013 15:14:20 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vm3IE-0002X9-1k for freebsd-current@freebsd.org; Thu, 28 Nov 2013 16:14:18 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Nov 2013 16:14:14 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Nov 2013 16:14:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Thu, 28 Nov 2013 15:13:53 +0000 (UTC) Lines: 24 Message-ID: References: <20131128140637.GA62346@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 15:14:20 -0000 Luigi Rizzo iet.unipi.it> writes: > ... > But I don't understand why you find ksize()/malloc_usable_size() dangerous. > ... The original crime is commited when *usable size* (an implementation detail) is exported (leaked) to the caller. To be blunt, when a caller requests memory of certain size, and its request is satisfied, then it is not its business to learn details beyond that (and they should not be offered as well). The API should be sanitized, in kernel and user space. Otherwise, all kind of charlatans will try to play hair-raising games with it. If the caller wants to track the *requested size* programmatically, it is its business to do it and it can be done very easily. Some of these guys got it perfectly right: http://stackoverflow.com/questions/5813078/is-it-possible-to-find-the-memory-allocated-to-the-pointer-without-searching-fo jb From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 17:13:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D786A8B1 for ; Thu, 28 Nov 2013 17:13:30 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F40419B7 for ; Thu, 28 Nov 2013 17:13:30 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id w61so2798457wes.28 for ; Thu, 28 Nov 2013 09:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kqSXZk86GEKqlHwMIHFlAvwKTUZFJVDJ4jHIufcLkLw=; b=LGNBXHdDBjNkqHQjIxiGyOaG2CadXOTSaH1KpI+2389W5GZFH1L96U5h69bwXKYTtB /jduZyPTinbhIKalspWVjjNOXWEuyIYY9A3p5+iM8IAOwH8gvqcQpGHORjQedzUvH8RT bPXDaElzekBV/PNG/pf5BrBFN3GiLR7cJ/RO3WVdFRnZVLAJNeMD4wODo2J/9t71i1Qc Ut7AT4NYaw8JIMBOZjtg4DuqFzk9o1TXUM2u6zuBuVXh3ldBOAepCBr++IrVTVGKqtqw AeQ4RRWfcDsbOd8pG6EcSjNesGaCjwTAxQWUNDpr79WIZv8UF/qErGmleopirOPE5Pn0 Cvaw== X-Received: by 10.194.62.8 with SMTP id u8mr3115566wjr.68.1385658808943; Thu, 28 Nov 2013 09:13:28 -0800 (PST) Received: from [192.168.1.129] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id y20sm83547287wib.0.2013.11.28.09.13.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 09:13:28 -0800 (PST) Message-ID: <529779B2.2090108@gmail.com> Date: Thu, 28 Nov 2013 19:13:22 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Alexander Panyushkin , freebsd-current@freebsd.org Subject: Re: lang/gcc not build References: <5294DEAA.5070308@gmail.com> In-Reply-To: <5294DEAA.5070308@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 17:13:31 -0000 26.11.2013 19:47, Alexander Panyushkin wrote: > #portmaster lang/gcc > [...] > cd /usr/ports/lang/gcc/work/gcc-4.6.4 ; contrib/gcc_update --touch > configure: loading site script /usr/ports/Templates/config.site > checking build system type... x86_64-portbld-freebsd10.0 > checking host system type... x86_64-portbld-freebsd10.0 > checking target system type... x86_64-portbld-freebsd10.0 > checking for a BSD-compatible install... /usr/bin/install -c -o root -g > wheel > checking whether ln works... yes > checking whether ln -s works... yes > checking for a sed that does not truncate output... (cached) /usr/bin/sed > checking for gawk... (cached) /usr/bin/awk > checking for gcc... gcc46 > checking for C compiler default output file name... > configure: error: in `/usr/ports/lang/gcc/work/build': > configure: error: C compiler cannot create executables > See `config.log' for more details. > ===> Script "../gcc-4.6.4/configure" failed unexpectedly. > Please report the problem to gerald@FreeBSD.org [maintainer] and attach the > "/usr/ports/lang/gcc/work/build/config.log" including the output of the > failure > of your make command. Also, it might be a good idea to provide an overview > of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static > info -g -Ea). > *** Error code 1 > > ############################################# > /etc/make.conf > > ..if ${.CURDIR:N*/ports/lang/gcc*} == "" > CFLAGS= -O2 -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Wformat > CPPFLAGS+= -D_FORTIFY_SOURCE=2 > USE_GCC=4.6 > ..endif Added this to my make.conf and tested - WFM. The problem is not there. Can you post a sample of /usr/ports/lang/gcc/work/build/config.log as log suggests? PS: CFLAGS= is a bit rough thing to have, CFLAGS+= would be much better. PPS: clang is mature enough and works correctly with CPUTYPE?=native so -march and -mtune can be substituted for that one. -- Sphinx of black quartz, judge my vow. From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 02:05:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FCECC0D for ; Fri, 29 Nov 2013 02:05:24 +0000 (UTC) Received: from server.i805.com.br (mailhost.i805.com.br [72.52.97.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE63D1451 for ; Fri, 29 Nov 2013 02:05:23 +0000 (UTC) Received: from i805.com.br (localhost [127.0.0.1]) by server.i805.com.br (8.14.6/8.14.5) with ESMTP id rAT25LiO068179 for ; Fri, 29 Nov 2013 00:05:21 -0200 (BRST) (envelope-from rizzo@i805.com.br) From: "Nilton Jose Rizzo" To: current@freebsd.org Subject: problems with pkg2ng Date: Thu, 28 Nov 2013 23:05:21 -0300 Message-Id: <20131129020453.M84728@i805.com.br> In-Reply-To: <20131129015446.M75652@i805.com.br> X-Mailer: OpenWebMail 3.00_beta4 20121104 671 X-OriginatingIP: 186.221.6.231 (rizzo) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on server.i805.com.br X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 02:05:24 -0000 Hi all, in the near past, when I update ports repository via svn, I always use pkg2ng to upgrade (or update?) the database, but today I can not do it. The command pkg2ng show this error message: root@valfenda:/home2/rizzo # pkg2ng pkg: PACKAGESITE in pkg.conf is deprecated. Please create a repository configuration file Converting packages from /var/db/pkg pkg: PACKAGESITE in pkg.conf is deprecated. Please create a repository configuration file pkg: fstat() failed for(/usr/local/etc/cups/cupsd.conf.N): No such file or directory but when I search in /usr/ports/UPDATING I can not found anything about this and no man pages about pkg2ng root@valfenda:/home2/rizzo # man pkg2ng No manual entry for pkg2ng root@valfenda:/home2/rizzo # Can Someone help me? MyBox: root@valfenda:/home2/rizzo # pkg -v 1.2_1 root@valfenda:/home2/rizzo # svn info /usr/src Caminho: /usr/src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Raiz do Repositório: svn://svn.freebsd.org/base UUID do repositório: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revisão: 258666 Tipo de Nó: diretório Agendado: normal Autor da Última Mudança: glebius Revisão da Última Mudança: 258666 Data da Última Mudança: 2013-11-26 18:27:57 -0200 (Ter, 26 Nov 2013) root@valfenda:/home2/rizzo # svn info /usr/ports Caminho: /usr/ports Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head Relative URL: ^/head Raiz do Repositório: svn://svn.freebsd.org/ports UUID do repositório: 35697150-7ecd-e111-bb59-0022644237b5 Revisão: 334975 Tipo de Nó: diretório Agendado: normal Autor da Última Mudança: kwm Revisão da Última Mudança: 334975 Data da Última Mudança: 2013-11-26 19:15:14 -0200 (Ter, 26 Nov 2013) root@valfenda:/home2/rizzo # uname -a FreeBSD valfenda 11.0-CURRENT FreeBSD 11.0-CURRENT #9 r258666: Wed Nov 27 00:06:27 BRST 2013 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64 TIA, Rizzo From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 02:12:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E318D99 for ; Fri, 29 Nov 2013 02:12:52 +0000 (UTC) Received: from server.i805.com.br (mailhost.i805.com.br [72.52.97.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6913814D9 for ; Fri, 29 Nov 2013 02:12:52 +0000 (UTC) Received: from i805.com.br (localhost [127.0.0.1]) by server.i805.com.br (8.14.6/8.14.5) with ESMTP id rAT22HmK068147 for ; Fri, 29 Nov 2013 00:02:17 -0200 (BRST) (envelope-from rizzo@i805.com.br) From: "Nilton Jose Rizzo" To: freebsd-current@freebsd.org Subject: problems with pkg2ng Date: Thu, 28 Nov 2013 23:02:17 -0300 Message-Id: <20131129015446.M75652@i805.com.br> X-Mailer: OpenWebMail 3.00_beta4 20121104 671 X-OriginatingIP: 186.221.6.231 (rizzo) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on server.i805.com.br X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 02:12:52 -0000 Hi all, in the near past, when I update ports repository via svn, I always use pkg2ng to upgrade (or update?) the database, but today I can not do it. The command pkg2ng show this error message: root@valfenda:/home2/rizzo # pkg2ng pkg: PACKAGESITE in pkg.conf is deprecated. Please create a repository configuration file Converting packages from /var/db/pkg pkg: PACKAGESITE in pkg.conf is deprecated. Please create a repository configuration file pkg: fstat() failed for(/usr/local/etc/cups/cupsd.conf.N): No such file or directory but when I search in /usr/ports/UPDATING I can not found anything about this and no man pages about pkg2ng root@valfenda:/home2/rizzo # man pkg2ng No manual entry for pkg2ng root@valfenda:/home2/rizzo # Can Someone help me? MyBox: root@valfenda:/home2/rizzo # pkg -v 1.2_1 root@valfenda:/home2/rizzo # svn info /usr/src Caminho: /usr/src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Raiz do Repositório: svn://svn.freebsd.org/base UUID do repositório: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revisão: 258666 Tipo de Nó: diretório Agendado: normal Autor da Última Mudança: glebius Revisão da Última Mudança: 258666 Data da Última Mudança: 2013-11-26 18:27:57 -0200 (Ter, 26 Nov 2013) root@valfenda:/home2/rizzo # svn info /usr/ports Caminho: /usr/ports Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head Relative URL: ^/head Raiz do Repositório: svn://svn.freebsd.org/ports UUID do repositório: 35697150-7ecd-e111-bb59-0022644237b5 Revisão: 334975 Tipo de Nó: diretório Agendado: normal Autor da Última Mudança: kwm Revisão da Última Mudança: 334975 Data da Última Mudança: 2013-11-26 19:15:14 -0200 (Ter, 26 Nov 2013) root@valfenda:/home2/rizzo # uname -a FreeBSD valfenda 11.0-CURRENT FreeBSD 11.0-CURRENT #9 r258666: Wed Nov 27 00:06:27 BRST 2013 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64 TIA, Rizzo From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 02:54:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F185789D; Fri, 29 Nov 2013 02:54:57 +0000 (UTC) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A290916BF; Fri, 29 Nov 2013 02:54:57 +0000 (UTC) Received: by mail-qe0-f43.google.com with SMTP id 2so9762554qeb.16 for ; Thu, 28 Nov 2013 18:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=JO2ITc4+VXQ/IxNtTLXHbHFHzBLASxs/CHaKaOdV6cQ=; b=qfIGfQES2XmKNMHme4thtFvZ1nYIC0ohMfZ+4mevPB3qyFl7QyTxIzQj7eyU8aQ2Rk q+Dc1pEy9Q6cbKTPh3vmIqZN0F1ZDG0DVs6okXUkYlrJxd/K11J+DMU9H12od01j1/Wz UM9gu4F1Ux3ZZx1jAbzJ5oB1ddesvE3uJktNQchT3YIezhxFKWIj5iNFeimL4dEfXsmI yk+m68l87TWVuj0NZhPd8SHDkD7csZSc60RaLkzGmvZhknghu2TCmSeqVGxSbvqBv6fd Cni8URgA+WlQeeh7I3TA8WhdM8AdjVyYk+Vuvmo3JGXo7BPWL52t2N3b7uapt7YVxYKD Aeaw== MIME-Version: 1.0 X-Received: by 10.49.24.211 with SMTP id w19mr10082005qef.9.1385693696838; Thu, 28 Nov 2013 18:54:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Thu, 28 Nov 2013 18:54:56 -0800 (PST) Date: Thu, 28 Nov 2013 18:54:56 -0800 X-Google-Sender-Auth: 1uOdpudWhk9fNy3RoRDbeF8mr7I Message-ID: Subject: request for help: MFC net80211 fixes from -HEAD to -10 From: Adrian Chadd To: freebsd-current , "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 02:54:58 -0000 hi all, I'd like a developer or two to organise the MFC of anything that's in net80211 on -HEAD back to -10 before 10.0-REL. There's a few critical fixes that need to go in but I just don't have the time to do it myself. :( Thanks! -adrian From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 03:04:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06A1DDD8; Fri, 29 Nov 2013 03:04:23 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA86117C3; Fri, 29 Nov 2013 03:04:22 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id A0CF11819F; Fri, 29 Nov 2013 03:04:20 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us A0CF11819F Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 28 Nov 2013 22:04:18 -0500 From: Glen Barber To: Adrian Chadd Subject: Re: request for help: MFC net80211 fixes from -HEAD to -10 Message-ID: <20131129030418.GB1717@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current , FreeBSD Release Engineering Team , "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 03:04:23 -0000 --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 28, 2013 at 06:54:56PM -0800, Adrian Chadd wrote: > I'd like a developer or two to organise the MFC of anything that's in > net80211 on -HEAD back to -10 before 10.0-REL. >=20 > There's a few critical fixes that need to go in but I just don't have > the time to do it myself. :( Depending on what the fixes are, you're likely too late at this point. What are the fixes, specifically? Glen --rJwd6BRFiFCcLxzm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSmAQyAAoJELls3eqvi17QzkMP/1qiAcQTZUxDu99E1O/AjK9N 1TBVEwB29BOteKfPzA1xO6eb2IFAXIHbrfWbayCbK+rBv+IZJA+Hin8LJvgZjFPv pMGZ9YSJ8Wg/Im+MZZhuM3mAif5lTOl34eB0pxXUbmDlBMo+ooqSuwjo2pgTDrl8 ioXaqOpN8nWs6vztI8Xq0NZMW7r39C4idumvfOwyYQEQECLB82zYZrLZZbpg6NmC ZDBvTWx9FS2rdBHvojFLf5yCeQq93JHyUEey2U3hdTo1bTJq3Axh2PZ7SW73byPW ou9cHyYosDfPPnZ5RxIDgunz1EmSvpL1lT+aM4PbrsD8TKxLGUpVc+t2UO9PKD9U ETSEZ2a2G3VNgxoGrX0sw/sKAH9X6vpvvnh2AjFks6yZc8Ei03/yuhS4n0JbpH8m 9f44Sh7KG+mKCbYFF/cgAATXvw6AaUYtv+w25hxADVUBJDojC4wkOuKC5g2uTEaH Oxyom073WjpthOi697G0Y5J4XzsC++cg3nFbR1jmCaUwQRhpzqwke3AsdJdbfpaa M+ouG10W5Tuf1O791AwzekGzRaeECCthZNY5ghru/YgsNQNNCDRk4LIWCQShxtae OkzWUIhCvzzhXSEY8vydnPzeAemQDY7lxLGbkZOMoc5OO95ttVXAU4c6hw/5gA2z R8lVq/6HNlaF8hbVGYil =nn/F -----END PGP SIGNATURE----- --rJwd6BRFiFCcLxzm-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 03:05:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2446F30; Fri, 29 Nov 2013 03:05:42 +0000 (UTC) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 51F6417E3; Fri, 29 Nov 2013 03:05:42 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id a11so9965080qen.33 for ; Thu, 28 Nov 2013 19:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Shfjb2hLBx7RwLlfkqGPojhWSEJkN+UyiiKedeqyHag=; b=SxPl0bODAKzQBFgtfTU+A7bd8lfJOnxUd83RrlE3aXA+l8xtyozVJQRyQbEoM0h+bI QDMlvJxH+DwyUGN8DlCtjzp71+kwlVaJ3WjeVs5tmjD7E2N2mDUYMh0YYMIq7Zw7xvzb tI1XTNwTto5s22iDFPu8vkrFx9Hhj+bZUVIGFedopG/bDruz8EyedyHt4I4UisEcQZOb iXf38PubMd3qOBeS+RC1UJnCOXRJ55ttmlgaUrrBweoC3bsbz6raXR0Z8HAxvExkJIJu oqW3dsTQSKyrL20Eu1JXn4GKFAfsjo62Ax7c7H/M5V2h0cG8GzUGpWitb9tYcuN2YNUK 1Lng== MIME-Version: 1.0 X-Received: by 10.224.10.197 with SMTP id q5mr61848050qaq.76.1385694341571; Thu, 28 Nov 2013 19:05:41 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Thu, 28 Nov 2013 19:05:41 -0800 (PST) In-Reply-To: <20131129030418.GB1717@glenbarber.us> References: <20131129030418.GB1717@glenbarber.us> Date: Thu, 28 Nov 2013 19:05:41 -0800 X-Google-Sender-Auth: tytP34X4IkTwj_1n5dCkvi902B4 Message-ID: Subject: Re: request for help: MFC net80211 fixes from -HEAD to -10 From: Adrian Chadd To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , FreeBSD Release Engineering Team , "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 03:05:42 -0000 On 28 November 2013 19:04, Glen Barber wrote: > On Thu, Nov 28, 2013 at 06:54:56PM -0800, Adrian Chadd wrote: >> I'd like a developer or two to organise the MFC of anything that's in >> net80211 on -HEAD back to -10 before 10.0-REL. >> >> There's a few critical fixes that need to go in but I just don't have >> the time to do it myself. :( > > Depending on what the fixes are, you're likely too late at this point. > > What are the fixes, specifically? I forget the details off-hand. There's a specific fix for incorrectly handling return values when queuing frames during power save or scan that results in traffic drops/errors. But there's been a few. -a From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 07:32:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 118F2EC4 for ; Fri, 29 Nov 2013 07:32:28 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A4711369 for ; Fri, 29 Nov 2013 07:32:27 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id q58so8941897wes.16 for ; Thu, 28 Nov 2013 23:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=NDwyPm433xFKTiJ/7HGHW4xFKN26aCMUzDw+O7N9pMA=; b=BiujWv4gwnlF3gQLGmQupB7+0Eg8EsFZFz+sQhDJA30oWE7eTx2t+A7k+jJ66lXYNr v5Dqllv2FGIlRoh9hOR17ao7FwdOhr1oIT8iRHrxTlsCKn1wZbO2Yhj52D0CJA/9xN5e uCXP4hcl1bseUvsCcjuUW/ePayOoyaSfxwu0P+rXYa5CgGxz1n17kviaqPw4O/q6XRku Li4tqlR7HfkDQsQuLqz8T2VAydTxMZtRTli80vAEyG5r2LW0JQHwt44w3lBsDTO7DVGl ydoXBATlwDVuvt0OMJmhVSV58UGYwQom+DwUS/kyc7k+FzegApAW6YrbpJ6uiIaq0wvp EYcg== X-Received: by 10.180.107.193 with SMTP id he1mr5601150wib.50.1385710346053; Thu, 28 Nov 2013 23:32:26 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id e10sm67418677wiy.7.2013.11.28.23.32.24 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 28 Nov 2013 23:32:24 -0800 (PST) Sender: Baptiste Daroussin Date: Fri, 29 Nov 2013 08:32:22 +0100 From: Baptiste Daroussin To: Nilton Jose Rizzo Subject: Re: problems with pkg2ng Message-ID: <20131129073222.GA48960@ithaqua.etoilebsd.net> References: <20131129015446.M75652@i805.com.br> <20131129020453.M84728@i805.com.br> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <20131129020453.M84728@i805.com.br> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 07:32:28 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 28, 2013 at 11:05:21PM -0300, Nilton Jose Rizzo wrote: >=20 >=20 > Hi all, >=20 > in the near past, when I update ports repository via svn, I always u= se > pkg2ng to upgrade (or update?) the database, but today I can not do it. >=20 > The command pkg2ng show this error message: >=20 > root@valfenda:/home2/rizzo # pkg2ng > pkg: PACKAGESITE in pkg.conf is deprecated. Please create a repository > configuration file > Converting packages from /var/db/pkg > pkg: PACKAGESITE in pkg.conf is deprecated. Please create a repository > configuration file > pkg: fstat() failed for(/usr/local/etc/cups/cupsd.conf.N): No such file or > directory >=20 > but when I search in /usr/ports/UPDATING I can not found anything about t= his > and no man pages about pkg2ng >=20 > root@valfenda:/home2/rizzo # man pkg2ng > No manual entry for pkg2ng > root@valfenda:/home2/rizzo # >=20 > Can Someone help me? >=20 Those are "just" warnings, nothing to worry about I'll add an UPDATING entry about those as soon as I can. regards, Bapt --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlKYQwYACgkQ8kTtMUmk6EywXQCfQ/VRsf1mTTrwD/EZsR1d3DDi yM4An33MhPN8rzQXKbyeDaFhR+4UIZkS =vIbg -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 07:45:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C05262CE for ; Fri, 29 Nov 2013 07:45:44 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 436411433 for ; Fri, 29 Nov 2013 07:45:44 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id rAT7jbB8017256 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 29 Nov 2013 07:45:37 GMT (envelope-from m.seaman@infracaninophile.co.uk) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk rAT7jbB8017256 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1385711137; bh=oC+tgxiS6v/AoO85cD44HzI6xkNEomVy89DPnsV687M=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Fri,=2029=20Nov=202013=2007:45:29=20+0000|From:=20Matthew =20Seaman=20|To:=20freebsd-curren t@freebsd.org|Subject:=20Re:=20problems=20with=20pkg2ng|References :=20<20131129015446.M75652@i805.com.br>|In-Reply-To:=20<2013112901 5446.M75652@i805.com.br>; b=gwl6gVitePABNDT66lO8tNu7haJZQ5WuQT6rEEMW8ucczvCCAJn6Bb0fzP8I0eq0b NFx9CdI63H3ArwgmrgHDeEwp/nUf/9vvh6JzxdrdZPZAe0UwlVHI3TN94g3QzEVzI9 9KUADPOVfCKdIlfo+Kyh2UyFbU/9kvXIO8/OACxw= Message-ID: <52984619.6080302@infracaninophile.co.uk> Date: Fri, 29 Nov 2013 07:45:29 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: problems with pkg2ng References: <20131129015446.M75652@i805.com.br> In-Reply-To: <20131129015446.M75652@i805.com.br> X-Enigmail-Version: 1.6 OpenPGP: id=E7F39EBF Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xiukXLIGScAVdXoeSjeg8qWqI0dKJ9d18" X-Virus-Scanned: clamav-milter 0.98 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 07:45:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xiukXLIGScAVdXoeSjeg8qWqI0dKJ9d18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29/11/2013 02:02, Nilton Jose Rizzo wrote: > in the near past, when I update ports repository via svn, I always= use > pkg2ng to upgrade (or update?) the database, but today I can not do it= =2E Uh? pkg2ng is a one time thing. Its only use is when converting a system that had previously used pkg_tools to pkg(8). That happens once, and after that, you never need it again. > The command pkg2ng show this error message: >=20 > root@valfenda:/home2/rizzo # pkg2ng > pkg: PACKAGESITE in pkg.conf is deprecated. Please create a repository > configuration file > Converting packages from /var/db/pkg > pkg: PACKAGESITE in pkg.conf is deprecated. Please create a repository > configuration file > pkg: fstat() failed for(/usr/local/etc/cups/cupsd.conf.N): No such file= or > directory This is not pkg2ng specific, but comes from the underlying calls to various pkg(8) actions. As it says, the format of pkg.conf has changed with this update, and it is instructing you on how to modify your pkg.conf so it conforms to the new norms. See pkg.conf(5) for details on creating a repository configuration file. The fstat() message is a different thing again -- looks like one of the files owned by the cups port has been deleted. You can fix that by forcing a reinstall of that package, but it's pretty innocuous really. > but when I search in /usr/ports/UPDATING I can not found anything about= this > and no man pages about pkg2ng=20 A lot of people seem confused and/or alarmed by this update. Yes, there have been a number of problems reported, which are being dealt with. Whether this warrants an entry in UPDATING I don't know, but the general tenor of any such entry would be "modify your configuration files as shown in the output of pkg(8)." No, there isn't a man page for pkg2ng. It was never thought necessary. However, if anyone wants to contribute a page for pkg2ng I'm sure it would be gratefully received. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matthew@infracaninophile.co.uk --xiukXLIGScAVdXoeSjeg8qWqI0dKJ9d18 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJSmEYgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATKPUP/R1DccACHc9WthNveeJG/cg2 r6VoLDuPnUSMxScuCtGdM6IaRXQ4kFy1WpLF2thZ5Bj74YyvFOfp5WHu1nfPk1Wg 8ESPx6WPscP8Li+deG7x/9N3A1mCsgW8GdCGYYVmAPezGL8+IlcrCpNZPvMt+vVg GiioGSApDIl+HEctZ6NgzAvjZkyI/jmVbQwI4cJ+TbJBf3113PwGnglXWMy7dm91 LCCxEPu+LAUrpPuEGeLmqpzudcmjDi6sMWnxnOJO4tLHto2HljJdERFbPUPyGcHf utH006skgfc8IMXSiEz4vF7TjFSXpvWBMoXXffZGIIschpvA6Vu7o2JwkYzSi7bj FzN4on9y4U7QvMZNpidm0JAAUMP7YHLCxYivQ+0pfn0drk/ycYXMzHC+Cuyg8bbb j/TqoKsdcDfjXM2aZLVo1rt3wXw/uLtxPBhJcybFodpRJpNS0XKTA+5E+zlPZHEf p60EakYtybQzLq4EeRWB0n8+sqVG3XgqvB2bsD+Ljeav4hCYZhSTSkIlyjQxOSXD F4Zx1Oskj77FhDwFBnGHQQsGoLoKWojkd0aajGcmZLpG/nvaJbAWYPQnTnSHNriS 6xRCH2+rHcd0HxqprtZgj8X2RFYIXD61HoVX2oEf64Xw5eZ0IwScSPQFrto5wBCE swzV+Xc1+A3CLaeZBOUq =ukE+ -----END PGP SIGNATURE----- --xiukXLIGScAVdXoeSjeg8qWqI0dKJ9d18-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 11:00:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF851DEB for ; Fri, 29 Nov 2013 11:00:04 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 46F7B1E35 for ; Fri, 29 Nov 2013 11:00:02 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rATAxxqS037214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Nov 2013 14:59:59 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rATAxxKD037213; Fri, 29 Nov 2013 14:59:59 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 29 Nov 2013 14:59:59 +0400 From: Gleb Smirnoff To: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <20131129105959.GF90895@FreeBSD.org> References: <20131128140637.GA62346@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 11:00:04 -0000 On Thu, Nov 28, 2013 at 03:13:53PM +0000, jb wrote: j> > But I don't understand why you find ksize()/malloc_usable_size() dangerous. j> > ... j> j> The original crime is commited when *usable size* (an implementation detail) j> is exported (leaked) to the caller. j> To be blunt, when a caller requests memory of certain size, and its request is j> satisfied, then it is not its business to learn details beyond that (and they j> should not be offered as well). j> The API should be sanitized, in kernel and user space. j> Otherwise, all kind of charlatans will try to play hair-raising games with it. j> If the caller wants to track the *requested size* programmatically, it is its j> business to do it and it can be done very easily. +1 This is kind of APIs that just shouldn't exist. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 11:16:21 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8053717A for ; Fri, 29 Nov 2013 11:16:21 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7A01F21 for ; Fri, 29 Nov 2013 11:16:20 +0000 (UTC) Received: from dhcp-172-17-159-175.eduroam.lapwing.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id rATBGBNf008785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Nov 2013 11:16:13 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: David Chisnall In-Reply-To: Date: Fri, 29 Nov 2013 11:16:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <933AFE5F-295B-41E0-9D43-14926CC6480D@FreeBSD.org> References: <20131128140637.GA62346@onelab2.iet.unipi.it> To: jb X-Mailer: Apple Mail (2.1822) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 11:16:21 -0000 On 28 Nov 2013, at 15:13, jb wrote: > Luigi Rizzo iet.unipi.it> writes: >=20 >> ...=20 >> But I don't understand why you find ksize()/malloc_usable_size() = dangerous. >> ... >=20 > The original crime is commited when *usable size* (an implementation = detail) > is exported (leaked) to the caller. > To be blunt, when a caller requests memory of certain size, and its = request is > satisfied, then it is not its business to learn details beyond that = (and they > should not be offered as well). > The API should be sanitized, in kernel and user space. > Otherwise, all kind of charlatans will try to play hair-raising games = with it. > If the caller wants to track the *requested size* programmatically, it = is its > business to do it and it can be done very easily. >=20 > Some of these guys got it perfectly right: > = http://stackoverflow.com/questions/5813078/is-it-possible-to-find-the-memo= ry-allocated-to-the-pointer-without-searching-fo I disagree. I've encountered several occasions where either locality = doesn't matter so much or I know the pointer is aliased, and I'd like = increase the size of a relatively large allocation. I have two choices: - Call realloc(), potentially copying a lot of data - Call malloc(), and chain two (or more) allocations together. What I'd like to do is call realloc() if it's effectively free, or call = malloc() in other cases. The malloc_useable_size() API is wrong though. In the kernel, realloc() = already takes a flag and a M_DONTALLOCATE would make more sense, = enlarging the allocation if it can be done without doing the = allocate-copy-free dance, but returning NULL and leaving the allocation = unmodified if not. David From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 11:26:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5221F335; Fri, 29 Nov 2013 11:26:20 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FFFC1FA2; Fri, 29 Nov 2013 11:26:19 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id u14so6829496lbd.4 for ; Fri, 29 Nov 2013 03:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oTeDx72VQI2mUBRN2chxMdIMJIK4pPs0oW0Tp7/bS58=; b=02PDLz7wm5C38UDd+yzokfxRju03sLFVmwDpmfkY4ZQCZ6ioT00urbyoH02gTJb58y 2RwfjdhpuWYIah2tavLtCanhC1Kf9rYL2Q2LH54Or/4naimDgjxIfivSVhnYz4Bkq97W WP48J4yWl2XVFkHziXHftzA6//cvM/nEX0h2zl9XlABWBdpOpG9LXwAVOR6mXHkpl0RW fn/jLReFVCwK5LADsMgDLS2AhqsY7lirKtseQOZrOiH4V9fyoiXiL75Gxq+iMnZlLHoq ylkQhjpnVwvR0ngVlipsQ5FN7/uC0MCMtZRbbUoz7K8DWC5AZQePVsTJYx6ySpvtRaLC 20Rg== MIME-Version: 1.0 X-Received: by 10.152.21.229 with SMTP id y5mr22254lae.87.1385724377600; Fri, 29 Nov 2013 03:26:17 -0800 (PST) Received: by 10.112.140.132 with HTTP; Fri, 29 Nov 2013 03:26:17 -0800 (PST) In-Reply-To: <20131129105959.GF90895@FreeBSD.org> References: <20131128140637.GA62346@onelab2.iet.unipi.it> <20131129105959.GF90895@FreeBSD.org> Date: Fri, 29 Nov 2013 12:26:17 +0100 Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Daniel Nebdal To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: Current , jb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 11:26:20 -0000 On Fri, Nov 29, 2013 at 11:59 AM, Gleb Smirnoff wrote: > On Thu, Nov 28, 2013 at 03:13:53PM +0000, jb wrote: > j> > But I don't understand why you find ksize()/malloc_usable_size() > dangerous. > j> > ... > j> > j> The original crime is commited when *usable size* (an implementation > detail) > j> is exported (leaked) to the caller. > j> To be blunt, when a caller requests memory of certain size, and its > request is > j> satisfied, then it is not its business to learn details beyond that > (and they > j> should not be offered as well). > j> The API should be sanitized, in kernel and user space. > j> Otherwise, all kind of charlatans will try to play hair-raising games > with it. > j> If the caller wants to track the *requested size* programmatically, it > is its > j> business to do it and it can be done very easily. > > +1 > > This is kind of APIs that just shouldn't exist. > > -- > Totus tuus, Glebius. > Then again: Using the "overflow" memory is only going to bite them if the API lies : If the return value is exactly "the size of the block you got allocated and can safely use until you free it", using it will per definition be safe. If the allocator later changes to, say, always allocate exact byte ranges, or to allocating blocks but having the option to fragment them later - then the return value would have to shrink to match, and any program using it would still DTRT. I'm completely ambivalent about adding it, though - it's not something I need, it's more stuff that needs to be handled if you change/rewrite the allocator, and it's not my decision. -- Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 11:49:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE0DBB49; Fri, 29 Nov 2013 11:49:23 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9083910E2; Fri, 29 Nov 2013 11:49:23 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rATBnBKr039184 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 03:49:15 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52987F32.1010500@freebsd.org> Date: Fri, 29 Nov 2013 19:49:06 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Daniel Nebdal , Gleb Smirnoff Subject: Re: [RFC] how to get the size of a malloc(9) block ? References: <20131128140637.GA62346@onelab2.iet.unipi.it> <20131129105959.GF90895@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Current , jb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 11:49:23 -0000 On 11/29/13, 7:26 PM, Daniel Nebdal wrote: > On Fri, Nov 29, 2013 at 11:59 AM, Gleb Smirnoff wrote: > >> On Thu, Nov 28, 2013 at 03:13:53PM +0000, jb wrote: >> j> > But I don't understand why you find ksize()/malloc_usable_size() >> dangerous. >> j> > ... >> j> >> j> The original crime is commited when *usable size* (an implementation >> detail) >> j> is exported (leaked) to the caller. >> j> To be blunt, when a caller requests memory of certain size, and its >> request is >> j> satisfied, then it is not its business to learn details beyond that >> (and they >> j> should not be offered as well). >> j> The API should be sanitized, in kernel and user space. >> j> Otherwise, all kind of charlatans will try to play hair-raising games >> with it. >> j> If the caller wants to track the *requested size* programmatically, it >> is its >> j> business to do it and it can be done very easily. >> >> +1 >> >> This is kind of APIs that just shouldn't exist. >> >> -- >> Totus tuus, Glebius. >> > > Then again: Using the "overflow" memory is only going to bite them if the > API lies : If the return value is exactly "the size of the block you got > allocated and can safely use until you free it", using it will per > definition be safe. If the allocator later changes to, say, always > allocate exact byte ranges, or to allocating blocks but having the option > to fragment them later - then the return value would have to shrink to > match, and any program using it would still DTRT. > > I'm completely ambivalent about adding it, though - it's not something I > need, it's more stuff that needs to be handled if you change/rewrite the > allocator, and it's not my decision. I think that if you want to play games with expanding buffers etc, then you should write your own allocator. You asked for X bytes. you should expect that you get X bytes and nothing more... either that or you should have asked for more in the first place. > > -- > Daniel Nebdal > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 12:04:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB95B2A0; Fri, 29 Nov 2013 12:04:17 +0000 (UTC) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E20A11E8; Fri, 29 Nov 2013 12:04:17 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id ma3so14259713pbc.26 for ; Fri, 29 Nov 2013 04:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=CPiWwDJfXaT9X6k4gc9+XeP9XZ7FCUEwK9RI9ulEeHo=; b=f+i94GeALnOCU/24hHWiuYggijU6nnh0+rpYqWzykfeCqmYpS1sIhFko/48vlznuuh 8joAmvFqn9jRKg3vFnFI49JETnwEEl4mwguHJ/f6jiAMo2Vh2JeCcEw0EhM9AFponIKy SxcGGg12+tjpz1qu+oLgjk+HptPeCNq+Z+hQO0HvAhfO4dJGUMgBi5HZWl56m9dm8d8+ A8izEiFIOTi06/xeD0MaPx9l6mb29S9tJ35qunskP+msBPVzKj2NL/uBFOYgilJWfVII uJFEjLefMMg2+aOOuCRBGuCbxdUsS1FpWPOcTizAD5BfU1Sqi27cRgKwBLo2VrXdZjLx /DNg== MIME-Version: 1.0 X-Received: by 10.66.235.106 with SMTP id ul10mr51271947pac.19.1385726648578; Fri, 29 Nov 2013 04:04:08 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Fri, 29 Nov 2013 04:04:08 -0800 (PST) Date: Fri, 29 Nov 2013 13:04:08 +0100 X-Google-Sender-Auth: G_-4mzBOTmt4WcmGtCWd4q2Li_I Message-ID: Subject: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: freebsd-net , "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 12:04:17 -0000 Hello, since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to share the same port and possibly listening ip, you would expect if you bind two daemon with such options to same port to see the same traffic on both! This is not the case today. Only multicast sockets seem to have the behaviour of broadcasting the data to all sockets sharing the same properties through these options! The patch at [1] implements/corrects the behaviour for UDP sockets. Is there anything to be corrected in that patch? Why it has not been provided there before? Can it be committed to the tree? Any extra security checks for jails needed there? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/udp_SO_REUSEADDR%2BPORT.diff -- Ermal From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 12:19:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94C4269E; Fri, 29 Nov 2013 12:19:50 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF41C12A9; Fri, 29 Nov 2013 12:19:49 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id ec20so6846952lab.10 for ; Fri, 29 Nov 2013 04:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=77XKm/7UVD72Kg0lAy4x0DO+xI0mfk3HqREjClEYdCY=; b=SCAeg4K92n6prQh4mlVZdUoGNPrYUC6mn33AfaG6YwiYLoaUKHUPm/uI3P7BDAsxS6 WkQxbo49Xfn02D94BdBsna39NNeDFcYb+SP2PkR9zVZ1XCu16pFj+/45ykE30C6Gqdjn WktD5SJ/VCnu/gt3nFPiAwdG8ZoygE5FTpk+zVobNu0XVi9EAI+tUXO2hZr/39YP7pM6 EmL5Wg5o4o0StNzGBtLmUjSll+iBBWe8ADSe+iDgKxPpS39O0A5UUazC2wNKe00ICCuA VO9bquHet+nqrLc9RkLYuUipG/ZSxSNqSU55itBEZqlMIhhTMexF571YS9anMar20Awk ZM6Q== MIME-Version: 1.0 X-Received: by 10.112.52.33 with SMTP id q1mr1463243lbo.30.1385727587656; Fri, 29 Nov 2013 04:19:47 -0800 (PST) Received: by 10.112.140.132 with HTTP; Fri, 29 Nov 2013 04:19:47 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 13:19:47 +0100 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Daniel Nebdal To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 12:19:50 -0000 On Fri, Nov 29, 2013 at 1:04 PM, Ermal Lu=E7i wrote: > Hello, > > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to > share the same port and possibly listening ip, you would expect if you bi= nd > two daemon with such options to same port to see the same traffic on both= ! > > This is not the case today. > Only multicast sockets seem to have the behaviour of broadcasting the dat= a > to all sockets sharing the same properties through these options! > > The patch at [1] implements/corrects the behaviour for UDP sockets. > Is there anything to be corrected in that patch? > Why it has not been provided there before? > Can it be committed to the tree? > Any extra security checks for jails needed there? > > > [1] > > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/= udp_SO_REUSEADDR%2BPORT.diff > > -- > Ermal I understood it as working sort of like for TCP, where packages from a given remote host+port all end up at exactly one of the local sockets? If the idea is to split the workload over multiple threads holding their own sockets listening to the same interface+port, wouldn't sending all packets to all sockets all the time be kind of counterproductive? Of course, I haven't actually used it much; I might be wrong. --=20 Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 16:15:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 922E8A3F; Fri, 29 Nov 2013 16:15:10 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6144D1F4D; Fri, 29 Nov 2013 16:15:10 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rATGF6LR039929 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 08:15:08 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5298BD83.2090601@freebsd.org> Date: Sat, 30 Nov 2013 00:14:59 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , "freebsd-current@freebsd.org" Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 16:15:10 -0000 On 11/29/13, 8:04 PM, Ermal Luçi wrote: > Hello, > > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to > share the same port and possibly listening ip, you would expect if you bind > two daemon with such options to same port to see the same traffic on both! this is not how I interpret it.. I presume it is is to allow two OUTGOING sessions from the same source. > > This is not the case today. > Only multicast sockets seem to have the behaviour of broadcasting the data > to all sockets sharing the same properties through these options! > > The patch at [1] implements/corrects the behaviour for UDP sockets. > Is there anything to be corrected in that patch? > Why it has not been provided there before? > Can it be committed to the tree? > Any extra security checks for jails needed there? > > > [1] > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/udp_SO_REUSEADDR%2BPORT.diff > From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 18:07:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A82E6E6C for ; Fri, 29 Nov 2013 18:07:54 +0000 (UTC) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 781B515AF for ; Fri, 29 Nov 2013 18:07:54 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id g10so14302975pdj.1 for ; Fri, 29 Nov 2013 10:07:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=pKqVVysBn4l+j9NkqDgRFfJPrlhXdFJquzctqtecpDA=; b=RSy+bMPiKvjbAHZZYajAr6YPemOUm9gaKpWj/P+KU1JEgHxchNECtR+T7IdZGMQ1It 7VW5CncaQyy4qRm6bNoCmFGcC8PI8Ff0ErVTE/Qif6JNau5nPiM6ApgCCIWGBUYiq1gd 8ivhuOIa5wDNkV1nX4HykBWE/9ef4TYEroEIUTvHkVbEscmg4JCazsJKbPFoxRFCI4O/ xdbNenb0qj5/v8akyXv8RGs2ZMbF4w1GowNZOjnNfAVzsMP+L8qyOAfpzmYrWnv+MXSU QVqJHnh1gzkdxGl16hjRPsF6GlFLsNy4b5vQYpj3IoM3zEKKG4ylEQwW6UX5jN2nu1XV LQpg== X-Gm-Message-State: ALoCoQnwiYMtMb/6vRKraUA3bhL9ygb6tR5D2ob+SmizQ9JeogsvY+UQSKi3ApikRkSz5a0WOyXl X-Received: by 10.68.191.3 with SMTP id gu3mr17101147pbc.142.1385747992101; Fri, 29 Nov 2013 09:59:52 -0800 (PST) Received: from [192.168.2.123] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPSA id pu5sm117393195pac.21.2013.11.29.09.59.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 09:59:51 -0800 (PST) Sender: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Tim Kientzle In-Reply-To: Date: Fri, 29 Nov 2013 09:59:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> References: To: =?windows-1252?Q?Ermal_Lu=E7i?= X-Mailer: Apple Mail (2.1822) Cc: freebsd-net , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 18:07:54 -0000 On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: > Hello, >=20 > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons = to > share the same port and possibly listening ip =85 These flags are used with TCP-based servers. I=92ve used them to make software upgrades go more smoothly. Without them, the following often happens: * Old server stops. In the process, all of its TCP connections are = closed. * Connections to old server remain in the TCP connection table until the = remote end can acknowledge. * New server starts. * New server tries to open port but fails because that port is =93still = in use=94 by connections in the TCP connection table. With these flags, the new server can open the port even though it is =93still in use=94 by existing connections. > This is not the case today. > Only multicast sockets seem to have the behaviour of broadcasting the = data > to all sockets sharing the same properties through these options! That is what multicast is for. If you want the same data sent to all listeners, then that is multicast behavior and you should be using a multicast socket. > The patch at [1] implements/corrects the behaviour for UDP sockets. You=92re trying to turn all UDP sockets with those options into multicast sockets. If you want a multicast socket, you should ask for one. Tim From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 18:42:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C351A1F; Fri, 29 Nov 2013 18:42:33 +0000 (UTC) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3212F188F; Fri, 29 Nov 2013 18:42:33 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id un15so14942157pbc.13 for ; Fri, 29 Nov 2013 10:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=E7rVOHXlcDEbgJykq07xE2JRIgEjpGh4AMC0W1PB8pc=; b=qTeId4+c5RgZhnyQC5UN6ut6WIE94WDdXJF7VcZkp6K548xeEWCmgTfTh27h0waDpp RJiiSFWK7uSg+vJ1l42OXviSxtue5A6bOP4+1tdvWBAT0zTZFcC94Bv7I7FTl6MM97Xm 5h0nh9MqPqYpPRvLpoCBL5KG5R6/TyQHLlOqZJsnvgLQVOiSdnmasWujPO2tu2MVM2+3 VuIOQKZAYuZ0UHymoWHiQmfivCyzyveMrG0Z4oUEAPWRgPuTNi9AZg08wu4woUx2tEOv sTGb7FxlY6Nmqu9H87LQ36iJ/xPvFUC0Q6iRDHjOqr+NPXzWJWHpxz1eunq8mIUSiBY8 NuCQ== MIME-Version: 1.0 X-Received: by 10.68.143.231 with SMTP id sh7mr7745610pbb.7.1385750552031; Fri, 29 Nov 2013 10:42:32 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Fri, 29 Nov 2013 10:42:31 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 19:42:31 +0100 X-Google-Sender-Auth: mE1J7-6v6SDPyXbAcvu5LrCfWoY Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Oleg Moskalenko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 18:42:33 -0000 Well seems Dragonfly has some version of it already from commit [1]. In FreeBSD there is the framework for this with by defining PCBGROUP. Also the explanation of it at [2] and [3]. It can achieve approximately the same features of SO_RESUSEPORT of linux. The only thing missing is the marketing behind it and i think and better RSS support. By looking at dates the support is there before linux so all you guys looking for it can experiment with it. What i was trying to accomplish was something else from performance improvement and maybe put a sysctl behind it to make it more acceptable.. [1] http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9c02= 1abb8197718d7a2d441c9 [2] http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpts#L51 [3] http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko wrote= : > Tim, you are wrong. Read what is "multicast" definition, and read how UDP > and TCP sockets work in Linux 3.9+ kernels. > > Oleg . > > > On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wrote= : > >> >> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: >> >> > Hello, >> > >> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons = to >> > share the same port and possibly listening ip =85 >> >> These flags are used with TCP-based servers. >> >> I=92ve used them to make software upgrades go more smoothly. >> Without them, the following often happens: >> >> * Old server stops. In the process, all of its TCP connections are >> closed. >> >> * Connections to old server remain in the TCP connection table until the >> remote end can acknowledge. >> >> * New server starts. >> >> * New server tries to open port but fails because that port is =93still = in >> use=94 by connections in the TCP connection table. >> >> With these flags, the new server can open the port even though >> it is =93still in use=94 by existing connections. >> >> >> > This is not the case today. >> > Only multicast sockets seem to have the behaviour of broadcasting the >> data >> > to all sockets sharing the same properties through these options! >> >> That is what multicast is for. >> >> If you want the same data sent to all listeners, then >> that is multicast behavior and you should be using >> a multicast socket. >> >> > The patch at [1] implements/corrects the behaviour for UDP sockets. >> >> You=92re trying to turn all UDP sockets with those options >> into multicast sockets. >> >> If you want a multicast socket, you should ask for one. >> >> Tim >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > --=20 Ermal From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 18:46:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6536CBF0; Fri, 29 Nov 2013 18:46:01 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2CFF218B3; Fri, 29 Nov 2013 18:46:01 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id p10so14223167pdj.4 for ; Fri, 29 Nov 2013 10:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=x3/7S+1KdZ4OGCpWIWM1/e7YTV63go6/l/1MGZ+63sk=; b=B/B2pq9DaUPU5dshnxkFLxYgRVlUJ+JXxd+JSLfwjy2hO48Dn/Fyhln5u3std+6kzT LcWzqmpzuoLVtoW6rMqfyrXugu0GdIlsfraZGXqeSKsKll3mGvIUW2Q9eMftcNwpWf1P GNUgXDOKEyvTBoXPvqov2v15rAxgKj8E0aDXGMnDJBsBj4v0HH0YLvy5APILCu9gldAF /D5hEYU5G4uvQinJoryJmH/AW+tTZNpgU3JlLFKDhsNzLV/LuXn0szb8Ty5wleABCjP3 bMPg8O8DFITeN809ZGz+UCirlSkugEJZ7jDIfVPJgfvXnHEfx8xCBeb8Ge0nGAuqroCD c0tQ== MIME-Version: 1.0 X-Received: by 10.66.149.135 with SMTP id ua7mr34022802pab.124.1385750760544; Fri, 29 Nov 2013 10:46:00 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Fri, 29 Nov 2013 10:46:00 -0800 (PST) In-Reply-To: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 19:46:00 +0100 X-Google-Sender-Auth: siq9dmpzJT8OkeHeH0-FBkIlW1w Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 18:46:01 -0000 On Fri, Nov 29, 2013 at 6:59 PM, Tim Kientzle wrote: > > On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: > > > Hello, > > > > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons t= o > > share the same port and possibly listening ip =85 > > These flags are used with TCP-based servers. > Every one has its own use-case! > > I=92ve used them to make software upgrades go more smoothly. > Without them, the following often happens: > > * Old server stops. In the process, all of its TCP connections are close= d. > > * Connections to old server remain in the TCP connection table until the > remote end can acknowledge. > > * New server starts. > > * New server tries to open port but fails because that port is =93still i= n > use=94 by connections in the TCP connection table. > > With these flags, the new server can open the port even though > it is =93still in use=94 by existing connections. > > > > This is not the case today. > > Only multicast sockets seem to have the behaviour of broadcasting the > data > > to all sockets sharing the same properties through these options! > > That is what multicast is for. > > Multicast has its defined scope and its applications though i think its interpreting the same socket options and respecting the options for what they should do and how they should behave. > If you want the same data sent to all listeners, then > that is multicast behavior and you should be using > a multicast socket. > > > The patch at [1] implements/corrects the behaviour for UDP sockets. > > You=92re trying to turn all UDP sockets with those options > into multicast sockets. > Not really the idea is how you do support the use case of having two daemons using the same port numbers but speaking different protocols. The best would be to merge these daemons but in the case you cannot there should be some support on it. At the very end there are only 65k ports :). Probably a sysctl for the feature might be a further compromise on it? > > If you want a multicast socket, you should ask for one. > > Tim > > --=20 Ermal From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 18:55:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 022D824F; Fri, 29 Nov 2013 18:55:33 +0000 (UTC) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BADCF193F; Fri, 29 Nov 2013 18:55:32 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id un15so14957353pbc.13 for ; Fri, 29 Nov 2013 10:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HnYU9wbKF43dOnvnPzXcTN3/pwiKZrFFJ7h3JNRL/RM=; b=UY+ppfIe0zsLCwwBaMw19qzGHm7f++ox64n2mleygKZunNjuDmLPFLG02GdsXjh2rD S6e3GykseQNPDtG4co3ox3ZffpmFVwdsS9+4jGVcjDf/IklZcAzLPL9r9HtqDG0XheBw fdsQkbK6kKHgvvFOkv2YyoXuNqE6Q9yonhRlOqV7DLemlNpKT0qp9nrwk013Cwayq74f 3Sndk+XvJd8QWM3AXA2PYZCeYGAF/zmOcU50dK+TE56wtBEjBElyE0u5km9+tmYJ2ZcW 4SwLtBsAV66O/souwna0yzRr6OOxeWrtimCZpSK8W2Bp2ZX4T38dDWVvVkOrgwm09jKW 11Yw== MIME-Version: 1.0 X-Received: by 10.68.143.231 with SMTP id sh7mr7787198pbb.7.1385751332368; Fri, 29 Nov 2013 10:55:32 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Fri, 29 Nov 2013 10:55:32 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 19:55:32 +0100 X-Google-Sender-Auth: t-IdTvNBjHGHoGdxnJt1Fb1cqFc Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Oleg Moskalenko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 18:55:33 -0000 Also some discussions and improvements to it. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html On Fri, Nov 29, 2013 at 7:42 PM, Ermal Lu=E7i wrote: > Well seems Dragonfly has some version of it already from commit [1]. > > In FreeBSD there is the framework for this with by defining PCBGROUP. > Also the explanation of it at [2] and [3]. > It can achieve approximately the same features of SO_RESUSEPORT of linux. > The only thing missing is the marketing behind it and i think and better > RSS support. > By looking at dates the support is there before linux so all you guys > looking for it can experiment with it. > > What i was trying to accomplish was something else from performance > improvement and > maybe put a sysctl behind it to make it more acceptable.. > > [1] > http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9c= 021abb8197718d7a2d441c9 > [2] > http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpts#L= 51 > [3] http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html > > > On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko wro= te: > >> Tim, you are wrong. Read what is "multicast" definition, and read how UD= P >> and TCP sockets work in Linux 3.9+ kernels. >> >> Oleg . >> >> >> On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wrot= e: >> >>> >>> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: >>> >>> > Hello, >>> > >>> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons >>> to >>> > share the same port and possibly listening ip =85 >>> >>> These flags are used with TCP-based servers. >>> >>> I=92ve used them to make software upgrades go more smoothly. >>> Without them, the following often happens: >>> >>> * Old server stops. In the process, all of its TCP connections are >>> closed. >>> >>> * Connections to old server remain in the TCP connection table until th= e >>> remote end can acknowledge. >>> >>> * New server starts. >>> >>> * New server tries to open port but fails because that port is =93still= in >>> use=94 by connections in the TCP connection table. >>> >>> With these flags, the new server can open the port even though >>> it is =93still in use=94 by existing connections. >>> >>> >>> > This is not the case today. >>> > Only multicast sockets seem to have the behaviour of broadcasting the >>> data >>> > to all sockets sharing the same properties through these options! >>> >>> That is what multicast is for. >>> >>> If you want the same data sent to all listeners, then >>> that is multicast behavior and you should be using >>> a multicast socket. >>> >>> > The patch at [1] implements/corrects the behaviour for UDP sockets. >>> >>> You=92re trying to turn all UDP sockets with those options >>> into multicast sockets. >>> >>> If you want a multicast socket, you should ask for one. >>> >>> Tim >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> > > > -- > Ermal > --=20 Ermal From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 19:01:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFCD94B7; Fri, 29 Nov 2013 19:01:26 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B30CD19A2; Fri, 29 Nov 2013 19:01:26 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id v10so14188062pde.41 for ; Fri, 29 Nov 2013 11:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7lSjamTqTzVkbRyBYKtnHFq3O97J7a2RyelXxvTR7oA=; b=z+wNaEYrA1hFgrLC+vAQetLZI69F9zgPo1SNXauK9y+NJfEhS3NFTgNDF96PLAHDKt +nIKRCV1nxWAi3kHKkhSp8NYBhwAzLXWprl14jPq9H5jpnd+s8ngVKaBMH6zWEqJgHey 2S9uwT/NFzQpWKbfmqK/L+MNn4t35chH22UZ2oDrToBfsNlFUShngr1TL2ob6DAEG0OC 9woYGE/cz3Pglu99oJW1jdpRrD/qE9QzG6q0J1wZ2XlvuVBqeP26BT+zsxZhQERXgECG jGLBcxLoszHqoMNWRF+KVMpHIt88fUdXSwWLBBQTLi1WpFU15Re0GMTVhCDpnWkQIxou cSKQ== MIME-Version: 1.0 X-Received: by 10.68.190.33 with SMTP id gn1mr17867037pbc.48.1385751686074; Fri, 29 Nov 2013 11:01:26 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Fri, 29 Nov 2013 11:01:26 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 20:01:26 +0100 X-Google-Sender-Auth: 9rUket6Ub6P9xoSV_z1KA3KcIp8 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Oleg Moskalenko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 19:01:27 -0000 And some better marketing from Dragonfly about it http://forum.nginx.org/read.php?29,241283,241283 :) On Fri, Nov 29, 2013 at 7:55 PM, Ermal Lu=E7i wrote: > Also some discussions and improvements to it. > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html > > > On Fri, Nov 29, 2013 at 7:42 PM, Ermal Lu=E7i wrote: > >> Well seems Dragonfly has some version of it already from commit [1]. >> >> In FreeBSD there is the framework for this with by defining PCBGROUP. >> Also the explanation of it at [2] and [3]. >> It can achieve approximately the same features of SO_RESUSEPORT of linux= . >> The only thing missing is the marketing behind it and i think and better >> RSS support. >> By looking at dates the support is there before linux so all you guys >> looking for it can experiment with it. >> >> What i was trying to accomplish was something else from performance >> improvement and >> maybe put a sysctl behind it to make it more acceptable.. >> >> [1] >> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9= c021abb8197718d7a2d441c9 >> [2] >> http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpts#= L51 >> [3] http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.htm= l >> >> >> On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko wr= ote: >> >>> Tim, you are wrong. Read what is "multicast" definition, and read how >>> UDP and TCP sockets work in Linux 3.9+ kernels. >>> >>> Oleg . >>> >>> >>> On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wro= te: >>> >>>> >>>> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: >>>> >>>> > Hello, >>>> > >>>> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemon= s >>>> to >>>> > share the same port and possibly listening ip =85 >>>> >>>> These flags are used with TCP-based servers. >>>> >>>> I=92ve used them to make software upgrades go more smoothly. >>>> Without them, the following often happens: >>>> >>>> * Old server stops. In the process, all of its TCP connections are >>>> closed. >>>> >>>> * Connections to old server remain in the TCP connection table until >>>> the remote end can acknowledge. >>>> >>>> * New server starts. >>>> >>>> * New server tries to open port but fails because that port is =93stil= l >>>> in use=94 by connections in the TCP connection table. >>>> >>>> With these flags, the new server can open the port even though >>>> it is =93still in use=94 by existing connections. >>>> >>>> >>>> > This is not the case today. >>>> > Only multicast sockets seem to have the behaviour of broadcasting th= e >>>> data >>>> > to all sockets sharing the same properties through these options! >>>> >>>> That is what multicast is for. >>>> >>>> If you want the same data sent to all listeners, then >>>> that is multicast behavior and you should be using >>>> a multicast socket. >>>> >>>> > The patch at [1] implements/corrects the behaviour for UDP sockets. >>>> >>>> You=92re trying to turn all UDP sockets with those options >>>> into multicast sockets. >>>> >>>> If you want a multicast socket, you should ask for one. >>>> >>>> Tim >>>> >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>> >>> >> >> >> -- >> Ermal >> > > > > -- > Ermal > --=20 Ermal From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 19:17:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B209AE4 for ; Fri, 29 Nov 2013 19:17:04 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 113031A56 for ; Fri, 29 Nov 2013 19:17:03 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id z5so7211401lbh.17 for ; Fri, 29 Nov 2013 11:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=DSpN88Js5jO6SUJDV5EUkv31bQIso8r2SBJmTwTJKzI=; b=ytrc6A1QVe/RF4xjJLiNIDTCCU79ud1xgN2SPHouxAiWcWp9bszIGpaQkT5e2rFAPs PhB+xs+pqucOLmLhPiJD+3WTc9R2cUhcxFduy96+M3GpkOTHSkyZWFP1EWkn5AvDIngC 8/AdA0pRcwX7FU05A+iGNgy9EFQefDfwdoI1QllCuPXYPqVkrLlfC/nfoG/UnF3CIi6R 206ons5s7Y7hwXyEWcqSRjO3n2hRTE05hjVCH1vk1RQNwqnuZdOcnW2816YOIScFh6nb C51fMhi1zzvk+IgCUlaerGyXgnfJkjxrdPMEhMurbf7KaGMqU2nZ660y81vPDOAL3Ene RRLA== MIME-Version: 1.0 X-Received: by 10.112.219.99 with SMTP id pn3mr18810138lbc.24.1385752621717; Fri, 29 Nov 2013 11:17:01 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Fri, 29 Nov 2013 11:17:01 -0800 (PST) Date: Fri, 29 Nov 2013 11:17:01 -0800 X-Google-Sender-Auth: o_YVzGJDZ5Ms8BkLj8gfB6jOcWE Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Luigi Rizzo To: jb Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 19:17:04 -0000 On Thu, Nov 28, 2013 at 7:13 AM, jb wrote: > Luigi Rizzo iet.unipi.it> writes: > > > ... > > But I don't understand why you find ksize()/malloc_usable_size() > dangerous. > > ... > > The original crime is commited when *usable size* (an implementation > detail) > is exported (leaked) to the caller. > To be blunt, when a caller requests memory of certain size, and its > request is > satisfied, then it is not its business to learn details beyond that (and > they > should not be offered as well). > The API should be sanitized, in kernel and user space. > Otherwise, all kind of charlatans will try to play hair-raising games with > it. > If the caller wants to track the *requested size* programmatically, it is > its > business to do it and it can be done very easily. > There is a difference between applications peeking into implementation details that should be hidden, and providing instead limited and specific information through a well defined API. In general (not in the specific code I am handling and not something I personally need), what the caller might want to do is optimize its requests according to how system behaves, and it cannot do that without some help from the below. I have seen the following types of comments in this thread: - "you should get it right the first time and never realloc" Maybe, but then the offending api is realloc() not ksize() - "build your own allocator" Yes i do it when it makes sense, but sometimes it is either overkill or a bad idea (as it loses opportunities for global optimizations, duplicates code, takes memory in subsystem-specific freelists...) - "what if ksize()/malloc_usable_size() lies ?" Well, that would be a bug in the allocator: if it says the memory is usable, it must be usable, period. - "rather than ksize() i'll give you a fix for one use case" (the NO_REALLOC flag to realloc()). This i think would be a mistake -- it acknowledges the need for exposing some information but then only provides a specific fix for one use case. I'll just restate that there are multiple situations where an application might use some information on actual allocation sizes: - when it needs to extend memory and has a choice between a cheap realloc() (if extra space is available), chaining blocks (when the memcpy would be too expensive), give up and live with whatever space is available. - when it has freedom in picking the block size and so it wants to optimize its requests basing on what the underlying allocator does. As an example, long ago FreeBSD was really suboptimal when you allocated blocks whose size was a power of 2, because the metadata was inline. These days, there is a different issue: powers of 2 are ok but blocks 2049 bytes and above seem to be padded to a multiple of 2048, leading to a huge overhead in some cases. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 19:30:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B751134; Fri, 29 Nov 2013 19:30:03 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D275B1AFB; Fri, 29 Nov 2013 19:30:02 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id k4so2174433qaq.15 for ; Fri, 29 Nov 2013 11:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5EVsvFt8BXDMy6fHbQ+UGB+UcTX1Lgack40jddvYHjQ=; b=ZaQin9mepc8SYXmle4KOR2sGE4doXhOz8xxIk8jJu626r7eHTnm+PdY5OlmNPwI/d9 1n5k7pW4Yvmzcc7JouYee5Owu5xx5flR0T4TcVo6ztyuNvrLC5x4aY8ndby60OdtJwob 0SjUxBBcDcezHrRycvZLA3YSPBBiOitb9h/w2yfNZh9UhWfva3r84FDWEdY3XsOty4WY xBNgOAIoK7XpLL1gZj/10ao+Y8v6TN7obPES60RN4e1OhbXmUuALvLXO7iRwdZ/rnctE /znmGTbyjbp+g2b0jIlKlz9pdKXvYJj2EmXG24PO3v3n2J3ifY3gijbRFGf487riJLXe r2/g== MIME-Version: 1.0 X-Received: by 10.49.35.144 with SMTP id h16mr89637851qej.35.1385753402048; Fri, 29 Nov 2013 11:30:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Fri, 29 Nov 2013 11:30:01 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 11:30:01 -0800 X-Google-Sender-Auth: bw5zAjZQER44f0HmpPx0l8u5Gjk Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Adrian Chadd To: Oleg Moskalenko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 19:30:03 -0000 Sure, is there a TCP version of this patch floating around? How's it doing load balancing to multiple listeners? -a On 29 November 2013 11:28, Oleg Moskalenko wrote: > It would be nice to have this feature compiled and supported in FreeBSD > kernel by default. > > Thanks > Oleg > > > On Fri, Nov 29, 2013 at 11:01 AM, Ermal Lu=E7i wrote: > >> And some better marketing from Dragonfly about it >> http://forum.nginx.org/read.php?29,241283,241283 :) >> >> >> On Fri, Nov 29, 2013 at 7:55 PM, Ermal Lu=E7i wrote: >> >>> Also some discussions and improvements to it. >>> >>> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.ht= ml >>> >>> >>> On Fri, Nov 29, 2013 at 7:42 PM, Ermal Lu=E7i wrote: >>> >>>> Well seems Dragonfly has some version of it already from commit [1]. >>>> >>>> In FreeBSD there is the framework for this with by defining PCBGROUP. >>>> Also the explanation of it at [2] and [3]. >>>> It can achieve approximately the same features of SO_RESUSEPORT of lin= ux. >>>> The only thing missing is the marketing behind it and i think and bett= er >>>> RSS support. >>>> By looking at dates the support is there before linux so all you guys >>>> looking for it can experiment with it. >>>> >>>> What i was trying to accomplish was something else from performance >>>> improvement and >>>> maybe put a sysctl behind it to make it more acceptable.. >>>> >>>> [1] >>>> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9= c9c021abb8197718d7a2d441c9 >>>> [2] >>>> http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpt= s#L51 >>>> [3] >>>> http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html >>>> >>>> >>>> On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko = wrote: >>>> >>>>> Tim, you are wrong. Read what is "multicast" definition, and read how >>>>> UDP and TCP sockets work in Linux 3.9+ kernels. >>>>> >>>>> Oleg . >>>>> >>>>> >>>>> On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle w= rote: >>>>> >>>>>> >>>>>> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: >>>>>> >>>>>> > Hello, >>>>>> > >>>>>> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two >>>>>> daemons to >>>>>> > share the same port and possibly listening ip =85 >>>>>> >>>>>> These flags are used with TCP-based servers. >>>>>> >>>>>> I=92ve used them to make software upgrades go more smoothly. >>>>>> Without them, the following often happens: >>>>>> >>>>>> * Old server stops. In the process, all of its TCP connections are >>>>>> closed. >>>>>> >>>>>> * Connections to old server remain in the TCP connection table until >>>>>> the remote end can acknowledge. >>>>>> >>>>>> * New server starts. >>>>>> >>>>>> * New server tries to open port but fails because that port is =93st= ill >>>>>> in use=94 by connections in the TCP connection table. >>>>>> >>>>>> With these flags, the new server can open the port even though >>>>>> it is =93still in use=94 by existing connections. >>>>>> >>>>>> >>>>>> > This is not the case today. >>>>>> > Only multicast sockets seem to have the behaviour of broadcasting >>>>>> the data >>>>>> > to all sockets sharing the same properties through these options! >>>>>> >>>>>> That is what multicast is for. >>>>>> >>>>>> If you want the same data sent to all listeners, then >>>>>> that is multicast behavior and you should be using >>>>>> a multicast socket. >>>>>> >>>>>> > The patch at [1] implements/corrects the behaviour for UDP sockets= . >>>>>> >>>>>> You=92re trying to turn all UDP sockets with those options >>>>>> into multicast sockets. >>>>>> >>>>>> If you want a multicast socket, you should ask for one. >>>>>> >>>>>> Tim >>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-net@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or= g" >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ermal >>>> >>> >>> >>> >>> -- >>> Ermal >>> >> >> >> >> -- >> Ermal >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 23:44:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58BAF6A for ; Fri, 29 Nov 2013 23:44:53 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1486E16BF for ; Fri, 29 Nov 2013 23:44:52 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VmXjj-0007WC-Jc for freebsd-current@freebsd.org; Sat, 30 Nov 2013 00:44:43 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Nov 2013 00:44:39 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Nov 2013 00:44:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Fri, 29 Nov 2013 23:44:18 +0000 (UTC) Lines: 35 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 23:44:53 -0000 Luigi Rizzo iet.unipi.it> writes: > ... > There is a difference between applications peeking into > implementation details that should be hidden, and providing > instead limited and specific information through a well defined API. > ... Right. If you want to improve memory management, that is, have the system (kernel or user space) handle memory reallocation intelligently and transparently to the user, then aim at a well defined API: - reallocate "with no copy", which means new space appended (taking into account *usable size*, a hidden-to-user implementation detail), if possible - otherwise fail, and let the user decide about reallocation "with copy" or allocation of a new space The malloc_usable_size() is a hack. The extra space allocated or not due to fragmentation, alignment, etc, is an internal by-product, irrelevant to original memory alloc request, and it should not be leaked, also because its details may change in future API implementations. So, these memory allocation functions leaking implementation details, and the two derived functions, ksize() and malloc_usable_size() (and other derivatives like malloc_size() in Mac OS X), are a violations of a clean, safe, and maintainable API. Note that malloc_usable_size() is a GNU C Library extension, not part of Single UNIX Specification. jb From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 00:03:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7CA85EF for ; Sat, 30 Nov 2013 00:03:51 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C80417BA for ; Sat, 30 Nov 2013 00:03:50 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id w7so7285652lbi.36 for ; Fri, 29 Nov 2013 16:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vo5U0WBIs91kKtnJFl3cbORTAVo4VzjlpBiL8yj52/c=; b=p2V0fYILdbcn+yATkgDwnokzpZu/LhDfAvW9VWSZYP3YKkSOuKvQj1AVtPHmoacrWF bongEBg0dRrvFKCe5iBpnJlOPLoFmBDN7U9LEIxPj9MtxpoO3WY28boCdbNYoIDRWyoC eyDhNR60WCEY2REmxZVbclm/pBCfvAZgzxanwV6eVOB5tEqfqkKZiRhppgiB2J9KL6ZQ Za8CzlvAd+m9sD84gEKWudEIzM1QhIrvwZk1OQt4Bksqcw6PFdOdA/hObYXa5DPvRb64 +L0smRBhx4yS1A14rVBK5/FCrnwGUHArXKUGz1p0thjBDqjViPGyk05Kg6C1ypC2ChMV PmqQ== MIME-Version: 1.0 X-Received: by 10.152.140.193 with SMTP id ri1mr37626273lab.18.1385769828792; Fri, 29 Nov 2013 16:03:48 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Fri, 29 Nov 2013 16:03:48 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 16:03:48 -0800 X-Google-Sender-Auth: Ztbh7sc0ej3fThu3SiDXHC9ch2s Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Luigi Rizzo To: jb Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 00:03:51 -0000 On Fri, Nov 29, 2013 at 3:44 PM, jb wrote: > Luigi Rizzo iet.unipi.it> writes: > > > ... > > There is a difference between applications peeking into > > implementation details that should be hidden, and providing > > instead limited and specific information through a well defined API. > > ... > > Right. > > If you want to improve memory management, that is, have the system (kernel > or user space) handle memory reallocation intelligently and transparently > to the user, then aim at a well defined API: > - reallocate "with no copy", which means new space appended (taking into > account *usable size*, a hidden-to-user implementation detail), if > possible > - otherwise fail, and let the user decide about reallocation "with copy" > or allocation of a new space > i respectfully disagree :) but am not pushing to add ksize. Just note that both mine and your "well defined API" leak details: yours is (A) "I may be overallocating but won't tell you how much"; mine is (B) "I may be overallocating and here is exactly how much". Now if I may make a comparison with going shopping, I'd rather hear the final price from the seller (case B), than having to guess by repeated trial and error, which is what case A leads to if i really want to figure out. > The malloc_usable_size() is a hack. > The extra space allocated or not due to fragmentation, alignment, etc, is > an internal by-product, irrelevant to original memory alloc request, and it > should not be leaked, also because its details may change in future API > implementations. > So, these memory allocation functions leaking implementation details, and > the two derived functions, ksize() and malloc_usable_size() (and other > derivatives like malloc_size() in Mac OS X), are a violations of a clean, > safe, and maintainable API. > > Note that malloc_usable_size() is a GNU C Library extension, not part of > Single UNIX Specification. > Honestly i did not even know they existed until a few days ago; but the fact that many different systems have come out with similar extensions at least make me wonder whether the SUS missed it. cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 00:49:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E82B5C5 for ; Sat, 30 Nov 2013 00:49:52 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C64E19B9 for ; Sat, 30 Nov 2013 00:49:52 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id w5so2392681qac.6 for ; Fri, 29 Nov 2013 16:49:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4x9AC/nAbPzDJiI99gjtaQRj1S52NRAffKwHtKcIQmI=; b=DVu0BbgL5USZsGBLe734ug7t2tTff6FY+z4jVQvYt8psxG7YcuSQksbuvus9lUTunI gYJLgMA0/9V+obcl9rkworJ6YtvTVf9XUXnKStwgxA5CoNjZ7IUz0SoQTDPEE+lK9K+L CLPgj4cR/n0UWZHXtbt3P5PAzIIgy2Tzw3WMI6xfqT0YmsjSnecCpfcrMCXM//vcmgGY PL6QhT1IoEzgUW4kaDLhZmIGn2nRsSODyIYIZiFoQ/mY/Nb2QfUGMUW+hwZyqMjFSUbG PaO7KHy9QtoBuKRwXjB0u61BSUytaTJJjVrvZnEc1ebqOuBXUNNZqv0yhA184/iqAbJF s0RA== MIME-Version: 1.0 X-Received: by 10.49.15.104 with SMTP id w8mr13170161qec.49.1385772591434; Fri, 29 Nov 2013 16:49:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Fri, 29 Nov 2013 16:49:51 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 16:49:51 -0800 X-Google-Sender-Auth: swdzfrGASHXbdWDoQhJSmpPZoTQ Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , jb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 00:49:52 -0000 The reason I wouldn't implement this is to avoid having code that _relies_ on this behaviour in order to function or perform well. Heck, it may not even be portable to other operating systems. Except, Linux, I guess. -adrian From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 01:02:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E06EFB45 for ; Sat, 30 Nov 2013 01:02:35 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 991B41A82 for ; Sat, 30 Nov 2013 01:02:35 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VmYx6-0004t5-6z for freebsd-current@freebsd.org; Sat, 30 Nov 2013 02:02:32 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Nov 2013 02:02:32 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Nov 2013 02:02:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Sat, 30 Nov 2013 01:02:11 +0000 (UTC) Lines: 48 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 01:02:35 -0000 Luigi Rizzo iet.unipi.it> writes: > ... > > If you want to improve memory management, that is, have the system (kernel > > or user space) handle memory reallocation intelligently and transparently > > to the user, then aim at a well defined API: > > - reallocate "with no copy", which means new space appended (taking into > > account *usable size*, a hidden-to-user implementation detail), if > > possible > > - otherwise fail, and let the user decide about reallocation "with copy" > > or allocation of a new space > > > > i respectfully disagree :) but am not pushing to add ksize. > Just note that both mine and your "well defined API" leak details: > > yours is (A) "I may be overallocating but won't tell you how much"; > mine is (B) "I may be overallocating and here is exactly how much". > > Now if I may make a comparison with going shopping, > I'd rather hear the final price from the seller (case B), > than having to guess by repeated trial and error, > which is what case A leads to if i really want to figure out. > ... This is not necessarily true - I omitted the details of reallocation implementation on purpose. >From the caller's point of view, if it requested allocation of memory size, then that's what it wanted in the first place. If it got it, then there is no other info needed. Next, if the caller came to the conclusion that more would be needed, then it should ask for memory reallocation, trusting that the system will do it in the most efficient way. If the caller wants to influence that process, then proper option(s) are needed in reallocation API, e.g.: - with no copy - with copy That means one call with options, with a specific (wanted by user) result. Of course, thinking thru the options (default, mutual exclusion, etc) is an important process and subject to RFC. A user-empowering API. No magic, no hacks. So, how about Request-for-Enhancement to GNU C lib, and the ugly hacks will disappear quickly. jb From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 01:11:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35E16FAA; Sat, 30 Nov 2013 01:11:53 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83A251B12; Sat, 30 Nov 2013 01:11:52 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id x18so7264324lbi.21 for ; Fri, 29 Nov 2013 17:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=idjeLnOWnX6+ivoH80Cyd/9Hf7Y0l7vYZffxw6EAK94=; b=ktW+Rr3bS3axRu+EPjmU48cuLQyme2RWM5JXuIv7GacZ6tK6bj0z/qWPmZXwc2k10t OogCl9it4YsU+3nQS6vh+kGfq0vPty9SMETkRCqYvfpo8vpDC0ZdSp+2n01yt02ZnkuV RWryHUoNO+NIykiUyFSJoQIUZrnYEJbyxsEafqWuY20MZEX6QsAxGVGstDK08c3T59uv vnOoecQhwaLeYlyQsp4pK+CakNpVmJavMHH20ytDknAGh/8WeA5DwjhJWQvP/3NE0xMV TeeXwENobdE3HKy6RSe3Mv7cRP67QFg9x0ztpTHklHZrlczFRGd5/cYpWXH7acn24Vi1 zr6w== MIME-Version: 1.0 X-Received: by 10.112.63.40 with SMTP id d8mr11706lbs.35.1385773909710; Fri, 29 Nov 2013 17:11:49 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Fri, 29 Nov 2013 17:11:49 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 17:11:49 -0800 X-Google-Sender-Auth: ivVDAljsiQOAEkug_MZyILnVr3I Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current , jb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 01:11:53 -0000 On Fri, Nov 29, 2013 at 4:49 PM, Adrian Chadd wrote: > The reason I wouldn't implement this is to avoid having code that > _relies_ on this behaviour in order to function or perform well. > nobody ever said (or could reasonably expect to do) that. Applications don't know if the allocator overallocates, so they have no hope unless they work even without the feature. This is only about giving them an option to improve performance in those (rare ?) cases where, as i showed, knowing the underlying allocation size may lead to better usage of memory. > > Heck, it may not even be portable to other operating systems. Except, > Linux, I guess. > > in userspace, as jb commented, all major OSes have it (malloc_usable_size() on FreeBSD and Linux, _msize() on Windows, malloc_size() on OSX). In the kernel, I have no idea, but porting kernel code across systems is a nightmare anyways... cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 01:21:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EAF7467 for ; Sat, 30 Nov 2013 01:21:35 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 776F41BCB for ; Sat, 30 Nov 2013 01:21:34 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id er20so7110938lab.36 for ; Fri, 29 Nov 2013 17:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BufjPVSFRVHv8S1mZe5eJruyvsgsUb0YyRWt7UWAOuU=; b=zl67t0dnivxzeeoTFhR9hih7NBRl+kSUI9ox5FRMguUgO9G/slvbfLQhK8oYyoWF2V zQgaX0lohchG2A90Kpa47cdZxTskakjqoeyMk5g+YWXqzKzqo07yS/8fKmzZTua9d+Mv aTvH8zdJ4cajtxiFinusZZYuG99zcpzaASm252nbSzyNVGlAdUBuCPGbQldUXmQKDVAv dFReKnwKj0paFcq7BWiFX1WU4mS8P8aY+uH4iCbx1tQA3LhfX8bzrWTcdL7Pzrdi89v+ +GU9rW+IwHAGospDsgcZpnBFqq/RDGvrAxL80rzgSzbMA7NzjqZIQCysgsum1eMxEIKA WLMQ== MIME-Version: 1.0 X-Received: by 10.152.140.193 with SMTP id ri1mr37841646lab.18.1385774492449; Fri, 29 Nov 2013 17:21:32 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Fri, 29 Nov 2013 17:21:32 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 17:21:32 -0800 X-Google-Sender-Auth: uHrxfkgvCLwMj6jBW2zV1WSu7Iw Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Luigi Rizzo To: jb Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 01:21:35 -0000 On Fri, Nov 29, 2013 at 5:02 PM, jb wrote: > Luigi Rizzo iet.unipi.it> writes: > > > ... > > > If you want to improve memory management, that is, have the system > (kernel > > > or user space) handle memory reallocation intelligently and > transparently > > > to the user, then aim at a well defined API: > > > - reallocate "with no copy", which means new space appended (taking > into > > > account *usable size*, a hidden-to-user implementation detail), if > > > possible > > > - otherwise fail, and let the user decide about reallocation "with > copy" > > > or allocation of a new space > > > > > > > i respectfully disagree :) but am not pushing to add ksize. > > Just note that both mine and your "well defined API" leak details: > > > > yours is (A) "I may be overallocating but won't tell you how much"; > > mine is (B) "I may be overallocating and here is exactly how much". > > > > Now if I may make a comparison with going shopping, > > I'd rather hear the final price from the seller (case B), > > than having to guess by repeated trial and error, > > which is what case A leads to if i really want to figure out. > > ... > > This is not necessarily true - I omitted the details of reallocation > implementation on purpose. > From the caller's point of view, if it requested allocation of memory > size, then that's what it wanted in the first place. If it got it, then > there is no other info needed. > This is not what we are discussing. We are discussing the case where the caller, _before_ requesting extra memory, would like to know how much space is available to make different decisions such as 1. realloc unconditionally 2. give up 3. allocate a separate block and chain to it 4. reduce its requirements and live with what extra space is available (if any). Your suggested flags support #1 and #2 directly, #3 can be simulated with realloc(NO_ALLOC) + malloc(), but prevent #4. cheers luigi Next, if the caller came to the conclusion that more would be needed, then > it should ask for memory reallocation, trusting that the system will do it > in the most efficient way. > If the caller wants to influence that process, then proper option(s) are > needed in reallocation API, e.g.: > - with no copy > - with copy > That means one call with options, with a specific (wanted by user) result. > Of course, thinking thru the options (default, mutual exclusion, etc) is > an important process and subject to RFC. > A user-empowering API. No magic, no hacks. > > So, how about Request-for-Enhancement to GNU C lib, and the ugly hacks > will disappear quickly. > > jb > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 03:13:01 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8C04EFA; Sat, 30 Nov 2013 03:13:01 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACEF9130A; Sat, 30 Nov 2013 03:13:01 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 61E27186EB; Sat, 30 Nov 2013 03:12:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 61E27186EB Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 29 Nov 2013 22:12:55 -0500 From: Glen Barber To: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Subject: 10.0-RELEASE status update Message-ID: <20131130031255.GG31807@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v2/QI0iRXglpx0hK" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 03:13:01 -0000 --v2/QI0iRXglpx0hK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Quick 10.0-RELEASE status update: - iconv(3) changes have been made in head/, and merged to stable/10 today. - Two MFCs are undergoing review, one of which I will commit right before updating the stable/10 branch name to reflect '-BETA4'.[1] - Builds for 10.0-BETA4 will begin tomorrow. The schedule page on the website will be updated to reflect the start of the -BETA4 builds, as well as updating the remainder of the schedule to reflect the adjustments after the delay. [1] - Important note to those tracking stable/10: An update will be committed tomorrow that will disable automatic creation of pkg.conf(5). Those installing new systems from 10.0-BETA4 should experience no trouble, as the update pkg(8) version (pkg-1.2.1) should be available around the same time 10.0-BETA4 is announced. This affects the pkg(8) bootstrap functionality *only*. Those with bootstrapped pkg(8) will not be affected. For those doing source-based upgrades from stable/10 *and* do not have pkg(8) already bootstrapped, there will be a brief (about 1 day, "brief" being relative) window of time where pkg(8) (versions less than 1.2) will not have a pre-configured pkg.conf(5). This will also be noted in the 10.0-BETA4 announcement mail.[2] [2] - I believe this is a non-issue, since usr.sbin/pkg/config.c has pkg.FreeBSD.org set as the packagesite, but I am sure I am overlooking something obvious that will prove me wrong. So, that is why the "important note" is longer than the actual status update. :-) Thank you for your patience. Glen On behalf of: re@ --v2/QI0iRXglpx0hK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSmVe3AAoJELls3eqvi17Qyd8QAIjFXgxYx+I7uXGvycYuMH0N lgoZBfonPmu5JBYDEjIQtzBpnQg0B+NWHshgIErPArMYC9nhNXhRhNdgoqrW+IEm 0YIv8Nrp05z27paGR4m7PMN1KhD1tv/NtosAhUB/LIFnswLxEPR5nHmLWs1HNGkh iZNGzGc9fxcMMPwpetJjhdxkUmyoPa5QAaMpc/Z1dfBIm88OTXdD3BhlIKAmnPIm l5qpY1mShh018zDerh28STlja8MUwAt957ei8TsalrA9F3z+FUB7K18C1Vmu+mEn l2pFtprkAsE6vZ4a2Pu+skB8CqN78a7qF4+3RhiPw/HMSaK3bzOsOcyFlPgV3qPB MtE3gZA33dgqNO8pQyA4sWRtchyVnZXbmf+ZBF08RSMtxd1NXcZub5y4su81WL21 Wor6uy3X3CiV1BifvEss2oXBwmEWHkk4EpVlAz6GzmwJvhqoM6Zg7H05347EZBLW tjyAFr7lMXyDTYksIULomS8SI/yOS16pjP4ubjXhQdi0lJD0qiBrgA6bvz3F5Uga CYLSzWbPKdhGN0G7kKJP1kNFsslJEAfHOGHYoiWsW84exx7wlxoJY7ZSLve0DIXS zQZWQLiqrzYXvEEt4bSgEiXMAdsoSSZU/YKXAJ+eORaatP03NxTmnbmXhf8AT7J2 EfcOZl2QzZVE1uyg2ZGG =y+5d -----END PGP SIGNATURE----- --v2/QI0iRXglpx0hK-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 03:32:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 664CF928 for ; Sat, 30 Nov 2013 03:32:14 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 11A2814CC for ; Sat, 30 Nov 2013 03:32:14 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M3AzH-1VWRe50EEh-00svCL for ; Sat, 30 Nov 2013 04:32:06 +0100 Message-ID: <52995C15.7010903@gmx.com> Date: Sat, 30 Nov 2013 04:31:33 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: freebsd-current Subject: Re: [RFC] how to get the size of a malloc(9) block ? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:p5e27GhuMuInFvgH7p7HnEfySF57/kQj3iW2yjoRwxHWbxnH+cg dYwxLQCbQi1CcCNn7amFz1YbWIRAGCfvNd1oCF6NQgDtc9Qv6hwVnUZkhaxT7vnQsM6QnXc PKNPU8Co0nIKtDAjRm91PEDLUmsD4XH8LN3vX+f+qEOCJ7hd5vUdwctwBnvr1CiHa3xZxkl +d5Dm5btpTNuusKPWZdmg== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 03:32:14 -0000 What is the supposed definition of malloc_usable_size(p) in a hypothetical, upcoming C standard? With the rest of the C standard remaining the same, one could try: Definition: The value of malloc_usable_size(p) is the amount of space allocated for object p, plus the amount of space after object p that can currently be written without messing up other objects or memory-management areas. This definition is practically useless, because data written to the slack space after the object could be claimed by calls to alloc()ish function -- perhaps by other threads. Another attempt at the defining something useful: Definition: The value of malloc_usable_size(p) is the amount of space allocated for object p, plus the amount of space after object p that can be written without messing up other objects or memory-management areas, while alloc()ish functions are not called on p. With this, one asks the question: How much is usually overallocated? In some implementations, usually just a few bytes (say, when the minimal allocation unit is 8 bytes); where not, it can be said that the memory manager is quite space-leaky. It appears that it's not possible to make a proper API with malloc_usable_size() included, at least when multi-threading is involved (ie., in the modern world). However, it is still useful to create an API that supports the following cases: - A program knows how to adapt to memory fragmentation without moving an ever-growing, but chainable array of data. - A program would become faster, if it knew when moving is required; then, the program could update various pointer-based (as opposed to arrayindex-based) references to the object being moved. (Just like when memory is defragmentated in a garbage-collected programming language.) - A program requires more memory in real-time, which means to either receive more memory immediately and do something, or to signal a real-time failure. So new flags could be [1]: - realloc_flags(p, s, REALLOCF_NO_MOVE): Resize object p, without moving it, to size s. With this restriction, when requesting more memory, and the specified amount isn't available, don't do anything (when requesting less memory, always succeed). - realloc_flags(p, s, REALLOCF_NO_MOVE | REALLOCF_ELASTIC): Resize object p, without moving it, to size s. With this restriction, when requesting more memory, and the specified amount isn't available, reserve as much as possible (when requesting less memory, always succeed). On the other hand, be advised of a hypothetical scenario, in which realloc() would like to jump at the opportunity to move the object to a different space, say, for the purpose of condensing slack space, when statistics show that allocated areas have plenty of holes. This means that the design of the new API can have more goals: - The allocator implementation should be able to shape the workings of a program at quick-realloc points, for example, by coaxing it to call realloc() when memory is very scattered. - The program should always be able to take advantage of a quick-realloc functionality, for example, to support certain real-time requirements of applications, to the extent reasonably possible within the implementation. For this, there could be a REALLOCF_FORCE flag, to be used in real-time scenarios. Without the flag, the call can be expected to be rejected on the basis of some implementation-specific preference, such as anti-fragmentation. Is there any insufficiency in this API, in anyone's mind? [1] When such a distinction makes sense and is supported (not stubbed) in the current architecture, environment, implementation, etc. From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 04:38:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F20FF267 for ; Sat, 30 Nov 2013 04:38:01 +0000 (UTC) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C23ED1983 for ; Sat, 30 Nov 2013 04:38:01 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id md12so15523081pbc.19 for ; Fri, 29 Nov 2013 20:37:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=x7XNsJC3q2yW2dnRMJc1WHinMktemKBjBIGF/pODZOs=; b=Iw9qzFbO+PjyWfags0ZwzqkX4SD27V/57gM7Vf7C1Kr6wZsqzJEzwAS/U8ayyj9uqW xwka++RyV2AP4w/xrSoNm5pMjv/LAt5eK+CABO9QqD8qWiuqwpdoXBvMSJaLbqoothbc d34MHdLsZJgdoiqHsMfdAMBshPAi7k7QxtdW/wp4qZYvuF8qZYLZSjiH7ZWr+QprWZMr EZoX8gwEse7hf0Jp3mN8NKLdbZnB9ERLHiFbZqhem8heNDd5YXxugE+lJcdp5snfXByV uu/0OXwZnDj78BLuF6Y37KI+kf49+LqT7NcuYIZwR8e4egMsXxOA9JAszz4KBClM4OuC wCaQ== X-Gm-Message-State: ALoCoQnUjIdXuIv5tM19GXX/8hNGXqdzr1MCV+M/CYzj7AXDyUNWuHFY7aFME8YC0oqK9YvfeIom X-Received: by 10.68.254.164 with SMTP id aj4mr115199pbd.161.1385786274856; Fri, 29 Nov 2013 20:37:54 -0800 (PST) Received: from [192.168.2.123] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPSA id de1sm105859312pbc.7.2013.11.29.20.37.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 20:37:54 -0800 (PST) Sender: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Tim Kientzle In-Reply-To: Date: Fri, 29 Nov 2013 20:37:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8BCD215D-55D8-452F-AAFC-8BC07AEDB76C@freebsd.org> References: To: jb X-Mailer: Apple Mail (2.1822) Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 04:38:02 -0000 On Nov 29, 2013, at 3:44 PM, jb wrote: > Luigi Rizzo iet.unipi.it> writes: >=20 >> ...=20 >> There is a difference between applications peeking into >> implementation details that should be hidden, and providing >> instead limited and specific information through a well defined API. >> ... >=20 > Right. >=20 > If you want to improve memory management, that is, have the system = (kernel > or user space) handle memory reallocation intelligently and = transparently > to the user, then aim at a well defined API: Don=92t forget: * Request a block of =93at least N bytes=94 and have the allocator tell you what it *really* allocated. This allows applications to use memory more efficiently by taking advantage of over-allocation when it happens. Tim From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 09:34:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB88D1AB for ; Sat, 30 Nov 2013 09:34:41 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7368015C9 for ; Sat, 30 Nov 2013 09:34:41 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vmgwb-0000wi-Qa for freebsd-current@freebsd.org; Sat, 30 Nov 2013 10:34:37 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Nov 2013 10:34:33 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Nov 2013 10:34:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Sat, 30 Nov 2013 09:34:13 +0000 (UTC) Lines: 24 Message-ID: References: <52995C15.7010903@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 09:34:41 -0000 gmx.com> writes: > ... > It appears that it's not possible to make a proper API with > malloc_usable_size() included, at least when > multi-threading is involved (ie., in the modern world). > > However, it is still useful to create an API that supports the following cases: > ... Well, this is a step forward toward achieving a well defined API for memory reallocation. But can we arrive at this goal without consideration for leaked implementation details via malloc_usable_size() & co ? We want to get rid of that leak and associated hacks. We want to induce reallocation function to do "the right thing" thru one API call with clear and smart options. If it does 90% of what we would ideally want, then the job is done. jb From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 12:03:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C92D2C16 for ; Sat, 30 Nov 2013 12:03:18 +0000 (UTC) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 6C3181E78 for ; Sat, 30 Nov 2013 12:02:24 +0000 (UTC) Received: (qmail 52550 invoked from network); 30 Nov 2013 12:02:17 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay03.pair.com with SMTP; 30 Nov 2013 12:02:17 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id rAUC2GGw048865; Sat, 30 Nov 2013 13:02:16 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id rAUC2GUP048864; Sat, 30 Nov 2013 13:02:16 +0100 (CET) (envelope-from pho) Date: Sat, 30 Nov 2013 13:02:16 +0100 From: Peter Holm To: Konstantin Belousov Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131130120216.GA48738@x2.osted.lan> References: <20131127200050.GE59496@kib.kiev.ua> <201311272111.rARLBZk9042868@gw.catspoiler.org> <20131128075610.GJ59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131128075610.GJ59496@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Don Lewis , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 12:03:18 -0000 On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote: > On Wed, Nov 27, 2013 at 01:11:35PM -0800, Don Lewis wrote: > > On 27 Nov, Konstantin Belousov wrote: > > > On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote: > > >> On 27 Nov, Konstantin Belousov wrote: > > >> > On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: > > >> >> On 27 Nov, Konstantin Belousov wrote: > > >> >> > On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: > > >> >> >> On 27 Nov, Konstantin Belousov wrote: > > >> >> >> > On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: > > >> >> >> >> On 27 Nov, Konstantin Belousov wrote: > > >> >> >> >> > On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: > > >> >> >> >> >> > > >> >> >> >> > > > >> >> >> >> > What is the instruction at cpu_switch+0x9b ? > > >> >> >> >> > > >> >> >> >> movl 0x8(%edx),%eax > > >> >> >> > So it is line 176 in swtch.s. Is machine still in ddb, or did you > > >> >> >> > obtained the core ? If yes, please print out the content of words at > > >> >> >> > 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at > > >> >> >> > address (*) + 8. > > >> >> >> > > >> >> >> It is still in ddb. > > >> >> >> > > >> >> >> , though not in > > >> >> >> the above order. > > >> >> > Uhm, sorry, I mistyped the last part of the instructions. > > >> >> > > > >> >> > The new thread pointer is 0xd2f4e000, there is nothing incriminating. > > >> >> > Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be > > >> >> > the address of the new thread pcb. It is load from the pcb + 8 which > > >> >> > faults. > > >> >> > > >> >> 0xf3d44d60 > > >> > Again, the pointer looks fine, and its tail is 0xd60, which is correct for > > >> > the pcb offset in the last page of the thread stack. > > >> > > > >> > Please do 'show thread 0xd2f4e000' before trying below instructions. > > >> > > >> Ok, see below: > > >> > > >> > What happens if you try to read word at 0xf3d44d68 ? > > >> > > >> Nothing bad ... > > >> > > >> > > >> > > > So the thread structure looks sane, the stack region is in place where > > > it is supposed to be, all the gathered data looks self-consistent. And, > > > the access to the faulted address from ddb does not fault. > > > > > > Thread stacks can only be invalidated when the process is swapped out and > > > kernel stack is written to swap. Your thread flags indicate that it is > > > in memory, and TDF_CANSWAP is not set. I do not believe that our swapout > > > code would invalidate stack mapping in such situation, otherwise we would > > > have too many complaints already. > > > > > > Just in case, do you use swap on this box ? > > > > I do. > > > > > And, as the last resort, I do understand that this sounds as giving up, > > > do you monitor the temperature of the CPUs ? BTW, which CPUs are that, > > > please show the cpu identification lines from the boot dmesg. > > > > I don't monitor the temperature, but I do hear the CPU fan speed ramping > > up and down when I'm building ports like this. Even though I'm pretty > > much keeping one core busy the whole time, the temperature must drop > > enough at times to let the fan speed drop. > > > > I can run math/mprime on this machine for a while to see if anything > > shows up. I also have a very similar machine (same motherboard but > > different CPU) that I can move the drive over to and test. > > > > Here's the full dmesg.boot: > > > > Copyright (c) 1992-2013 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 11.0-CURRENT #63 r258614M: Tue Nov 26 00:29:01 PST 2013 > > dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB i386 > > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > > WARNING: WITNESS option enabled, expect reduced performance. > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2500.06-MHz 686-class CPU) > > Origin = "AuthenticAMD" Id = 0x60fb1 Family = 0xf Model = 0x6b Stepping = 1 > > Features=0x178bfbff > > Features2=0x2001 > > AMD Features=0xea500800 > > AMD Features2=0x11f > > The errata list for the Athlon 64 X2 is quite long. Do you have latest > BIOS ? I am not sure if AMD provides standalone firmware update blocks > for their CPUs. If any Linux distribution ships updates for AMD CPUs, > it might be useful to load the update with cpucontrol(8). Even if we > do not hit a CPU bug, it would provide me with more certainity that we > are not chasing ghost. > > Another things to try, in vain, is to compile kernel with gcc or disable > SMP. > > Peter, could you, please, try to reproduce the issue ? It does not look > like a random hardware failure, since in all cases, it is curthread access > which is faulting. The issue is only reported by Don, and so far only > for i386 SMP. I'm not seeing this issue on my AMD Phenom(tm) 9150e Quad-Core Processor with i386/r258703. - Peter From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 13:22:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C09E6AEE; Sat, 30 Nov 2013 13:22:54 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2ACB9124B; Sat, 30 Nov 2013 13:10:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAUDARY4015671; Sat, 30 Nov 2013 15:10:27 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAUDARY4015671 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAUDAR6M015667; Sat, 30 Nov 2013 15:10:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Nov 2013 15:10:27 +0200 From: Konstantin Belousov To: Peter Holm Subject: Re: panic: double fault with 11.0-CURRENT r258504 Message-ID: <20131130131027.GX59496@kib.kiev.ua> References: <20131127200050.GE59496@kib.kiev.ua> <201311272111.rARLBZk9042868@gw.catspoiler.org> <20131128075610.GJ59496@kib.kiev.ua> <20131130120216.GA48738@x2.osted.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="idrYQvSmvc5WAT7Q" Content-Disposition: inline In-Reply-To: <20131130120216.GA48738@x2.osted.lan> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Don Lewis , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 13:22:54 -0000 --idrYQvSmvc5WAT7Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 30, 2013 at 01:02:16PM +0100, Peter Holm wrote: > On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote: > > Peter, could you, please, try to reproduce the issue ? It does not look > > like a random hardware failure, since in all cases, it is curthread acc= ess > > which is faulting. The issue is only reported by Don, and so far only > > for i386 SMP. >=20 > I'm not seeing this issue on my AMD Phenom(tm) 9150e Quad-Core > Processor with i386/r258703. Thank you. 9150 is family 0x10, which my indeed point out to some errata for family 0xf. Lets wait for Don. --idrYQvSmvc5WAT7Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSmePCAAoJEJDCuSvBvK1B1fEP+wa3JWnJBT2FikLIXaykTLi4 zkAVtZvLYy0vEqa5k8Ydk8V8Aji3L/46aRJ2STJnDF+PEhaJOhwp/Mtwu1lKC1oU lQ/XiaAS9Z55rlzgfXfrzQYPv0jV8RVxGW9fREQ7NVP/oGn93f7kBrFeNwOQnbic mNLMqRL9srS/9U8pW/41fbGrLd6n6DuhJIjAoeOhQBKR72slPioN15OcNt6JCYmT aSgnRDh0QJEwoKoszodIPkSBEib8qe8YfyyFsgW3OiQZa6N7upSq6M2FMsfnCTvi bFb1utxuml9jqOeMAhkf0etHJZ8J2rQCnTHt9Pwi8ByFMvul8XdA10gm/JrswKFE aoxbbF68cMXwkm8ozyz1oNk1KBUFm6xRxtO7SLyHMOjrYglEW6mzjBL9lRDtXdsp ozT1VJGcjeojBF5wRBpm8xhjPQZgtICY4fZAHZeBRx2jDcoU31ClkapDPlnG6bEz HLFhIVZe1wdApnoe6/bwGcJZxSROR1j3PGhIZ1C7ov8RsAIcZUDFd6m5unV7lmNL IxQ9Ix/B/NQ/LaUymTPLq58QhKuMMp4P6+Pk9mGvQ1B/7dc9XI78NxP4mUWP0myy rhYv1Lyl2zByyrf/GDA0FMalGdauK4+oifJCsGwLBvW1KOvp8uApLep5S4IIyE02 +LU7IMN0aE6f6xTO1LcV =E6X+ -----END PGP SIGNATURE----- --idrYQvSmvc5WAT7Q-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 13:56:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D3A3284 for ; Sat, 30 Nov 2013 13:56:52 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0FC7C15C4 for ; Sat, 30 Nov 2013 13:56:51 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAUDuG75025929 for ; Sat, 30 Nov 2013 15:56:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAUDuG75025929 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAUDuGDk025928 for current@freebsd.org; Sat, 30 Nov 2013 15:56:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Nov 2013 15:56:16 +0200 From: Konstantin Belousov To: current@freebsd.org Subject: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds Message-ID: <20131130135616.GA59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tC0181x+qd2nK2ch" Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 13:56:52 -0000 --tC0181x+qd2nK2ch Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I propose to unconditionally add the switch -fno-strict-overflow to the kernel compilation. See the patch at the end of message for exact change proposed. What does it do. It disallows useless and counter-intuitive behaviour of the compiler(s) for the signed overflow. Basically, the issue is that the C standard left signed overflow as undefined to allow for different hardware implementation of signess to be used for signed arithmetic. De-facto, all architectures where FreeBSD works or have a chance to be ported, use two-complement signed integer representation, and developers intuition is right about it. The compiler authors take the undefined part there as a blanket to perform optimizations which are assuming that signed overflow cannot happen. The problem with that approach is that typical checks for bounds are exactly the place where the overflow can happen. Instead of making some artificial example, I would just point to my own r258088 and r258397. What makes the things much worse is that the behaviour is highly depended on the optimization level of the exact version of compiler. What other projects did in this regard. They turned the same knob unconditionally. I can point at least to Linux kernel and Postgresql. Python uses -fwrapv, which is equivalent to the -fno-strict-overflow on the two-complement machines. Linux used -fwrapv before switched to -fno-strict-overflow. diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk index 2939a59..6e6ba92 100644 --- a/sys/conf/kern.mk +++ b/sys/conf/kern.mk @@ -148,6 +148,12 @@ INLINE_LIMIT?=3D 8000 CFLAGS+=3D -ffreestanding =20 # +# Do not allow a compiler to optimize out overflow checks for signed +# types. +# +CFLAGS+=3D -fno-strict-overflow + +# # GCC SSP support # .if ${MK_SSP} !=3D "no" && ${MACHINE_CPUARCH} !=3D "ia64" && \ --tC0181x+qd2nK2ch Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIbBAEBAgAGBQJSme5/AAoJEJDCuSvBvK1BQRMP+LRs2cW2QZ1iuQC7GLRdlCqc rKkJmSJLy1qkmB7vnZKUtYcAGsapxPZE0FDqnU1sPjAf1eiRsp3XgXQth8sinT6H HUQKjsM6H5kC2MMdYRVv0UlUT5Dg5mRXgrKIq0v/l3Rc2n6Efh6WiqU+pCn/Hq5h JVCp0g7E69VxUm731tFDZWxYQILbqMldCly6+3RO4G9Q2+u1hPswFl/riesSvjPd YTlgJgLzFye6Ehgk7Y1sZV4Dl425BbU6sHBCyLU7R71a8Dmo8twFSDSv76TfEBda 0Mpxc3E2M+vyCiVip/ubYvmeoaK/ErZfOFUFGt2nN3jiJuURXojE7ImcCEH6bO2o WOANjmxZ0/i8mHrEk8D8GYhSdKwni0yDgaXeIwJr+dFlR2MHXE32JJbF+RbyQpny 91T4hI3bsRN0RqjMzk4ukDszRh0ETKbpWk7cWbtI2ExVgIxMZIuji49aBZkfZgs4 GCHxRq1IDLh8SdaFJe4ldjRl6iE1DDT1rrsTOsk8c5aqc+ESLUPnZ4czQhGvmr8C VfVpX38JrCO3Eu6/Sr3EgRnUQzbWBmEjXNwU2lzFF2sJ+sPrG95lK5eHQ5CkLyQI /kDQ1YGfZQLO3Bv9tJpXS4j7Ro7o0YVhj6FpAkkg6NldaFeWmISL1JI9O9rIvVS4 2NYgf/R+krTpK3cAPOg= =9ZMN -----END PGP SIGNATURE----- --tC0181x+qd2nK2ch-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 14:06:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1372F470 for ; Sat, 30 Nov 2013 14:06:56 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A95251659 for ; Sat, 30 Nov 2013 14:06:55 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAUE6oRR028076 for ; Sat, 30 Nov 2013 16:06:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAUE6oRR028076 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAUE6oKE028075 for freebsd-current@freebsd.org; Sat, 30 Nov 2013 16:06:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Nov 2013 16:06:50 +0200 From: Konstantin Belousov To: FreeBSD current Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <20131130140650.GB59496@kib.kiev.ua> References: <8BCD215D-55D8-452F-AAFC-8BC07AEDB76C@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R6wYhkMFzQRgf+Dz" Content-Disposition: inline In-Reply-To: <8BCD215D-55D8-452F-AAFC-8BC07AEDB76C@freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 14:06:56 -0000 --R6wYhkMFzQRgf+Dz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 29, 2013 at 08:37:28PM -0800, Tim Kientzle wrote: >=20 > On Nov 29, 2013, at 3:44 PM, jb wrote: >=20 > > Luigi Rizzo iet.unipi.it> writes: > >=20 > >> ...=20 > >> There is a difference between applications peeking into > >> implementation details that should be hidden, and providing > >> instead limited and specific information through a well defined API. > >> ... > >=20 > > Right. > >=20 > > If you want to improve memory management, that is, have the system (ker= nel > > or user space) handle memory reallocation intelligently and transparent= ly > > to the user, then aim at a well defined API: >=20 > Don?t forget: >=20 > * Request a block of ?at least N bytes? and have the > allocator tell you what it *really* allocated. >=20 > This allows applications to use memory more efficiently > by taking advantage of over-allocation when it happens. Taking random message in the thread. IMO, more important point of this API is not to allow the code to micro-optimize. By the nature of malloc-like API, consumer code usually pass only the allocated pointed around, without attached notion of the size. Just note the signature of free(9) or free(3). As consequence, any interceptor-like functionality, e.g. performing accounting, leak detection, consistency analysis or anything else somebody could imagine, has to either track correspondence between allocation address and size on its own, or dive deep into the allocator implementation to obtain the size from address. When I am working with user-space and doing any trick with malloc, this functionality is in fact absolutely required. --R6wYhkMFzQRgf+Dz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSmfD6AAoJEJDCuSvBvK1BVkcP/3zJ/FwrHUUV0Ij2N0AJA0o4 fuD459lwGxB2E1x5NDk/ERV3ZhACAmTs6ED7pfk3oXZk6yWClU08XWjBbQyzP5B8 QtUQaZ5gAUQWH4itsEu4oAWUfZw6SumNx/kJcDb1es1tzVdnBqZd6OKDyFn4BTB7 etBCgiC/7FKD2BQ3rFpKQvf5DgP/2hwXbFavftf05hAWktEUi3ALYZ3uWgXNF6qb RORBWSz6rwGl+OkncpZ+Haiof5I9FY+W0monAeaD5ewY+ROMV1Iy6GnMFH5iXCKb 1hVIWNCHeaMMiYCAVjkQqs8S62MhDUn+ISwbjq4f0iN1NYgfncOOHc2IkqC9Yndd hvs8enROH8z3ZvSVfAKhSPWIQ8qiDyzCJfiN/Oxl/BKN6XOjFbx8iAeg4Vk/T2Zf KcwTHMvAZP7SIc33FuI56N8CwcUsMgDs3otljiKBUAxAj7NXqKZO4+gViXoZmIIm zuDzILEwxkfGFYAnnEwAQ1aNZ26sjWuRxCFNpBN4AZW7g0kXEMVVyctmDioBA9GT ocsPnTxJyFNgkr51TRMIUUxaIDeHvOQhc85d/WRXEtI0Eb3IkT8CoyczPu/nNztG USVf7LP4pkwsu+FxYHO7LkmOQN6B2GHiaMGfqmYj19NCDASW0NUkfdPDR1MPLkTT JPuLeRMZ9q45ax0q28Dd =tycF -----END PGP SIGNATURE----- --R6wYhkMFzQRgf+Dz-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 18:48:37 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DFA4A61 for ; Sat, 30 Nov 2013 18:48:37 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1DA881224 for ; Sat, 30 Nov 2013 18:48:36 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAUImMg1053041; Sat, 30 Nov 2013 10:48:26 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311301848.rAUImMg1053041@gw.catspoiler.org> Date: Sat, 30 Nov 2013 10:48:22 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <20131130131027.GX59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 18:48:37 -0000 On 30 Nov, Konstantin Belousov wrote: > On Sat, Nov 30, 2013 at 01:02:16PM +0100, Peter Holm wrote: >> On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote: >> > Peter, could you, please, try to reproduce the issue ? It does not look >> > like a random hardware failure, since in all cases, it is curthread access >> > which is faulting. The issue is only reported by Don, and so far only >> > for i386 SMP. >> >> I'm not seeing this issue on my AMD Phenom(tm) 9150e Quad-Core >> Processor with i386/r258703. > > Thank you. > > 9150 is family 0x10, which my indeed point out to some errata > for family 0xf. Lets wait for Don. It's really looking like a hardware problem at this point. I've seen no problems so far in about 2 1/2 passes through portupgrade -fr lang/perl5.16 on my other machine with the same motherboard model but a slightly different CPU. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2200.05-MHz 686-class CPU ) Origin = "AuthenticAMD" Id = 0x40fb2 Family = 0xf Model = 0x4b Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f It's also a family 0xF CPU, but strangely different. It only seems to have half as many on-die temperature sensors. dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 35.0C dev.amdtemp.0.core0.sensor1: -49.0C dev.amdtemp.0.core1.sensor0: 34.0C dev.amdtemp.0.core1.sensor1: -49.0C I've never noticed this before because this is the first time FreeBSD has been run on this hardware. I may have to dig out the fine manual to see if amdtemp can be tweaked to recognize this variation. After the current test run, which should finish late tonight, I'll go back to the original machine and try the patch. If I still see failures, then I'll start swapping parts to find the bad one. From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 18:53:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE239BD0 for ; Sat, 30 Nov 2013 18:53:08 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E5A71273 for ; Sat, 30 Nov 2013 18:53:08 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id o15so2940334qap.17 for ; Sat, 30 Nov 2013 10:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hUSfQCb/NySdiv9y/sxtJNwTd3de3dSpyf9ZsXcfCPU=; b=oZOgDnVbUKrx3VryTAFykA21tY4xPWZUYdRxWUWBgKhZ8ssMEcg6his7HVPdZnm0Lm AdyDIuUi9UMQrU9UPNkuZ94IsbuWrukMHB9qH9fmKnIdKDDZ7lCFhIK/yFfBb81dPzSX JGDyRVdphiesK+3yI+L3KYBMSmGAo0cfOt6JlKm+HC9Ub0NgyARFJ/Y1eGQB3FJyWrJZ qXSG1LxbpSNyiGNveCZmyIjiIBZVUhXdGwE96Q8pBU1MBqRGUUnDJ7ev6At97BRJs/WX DQBYcnLB94glwIO9yt1D1O6A7/qOv2b1ZQ/ZusdTUx9JAp/YGJmUv7LU+YxIZyx4jE7g +IQA== MIME-Version: 1.0 X-Received: by 10.224.46.8 with SMTP id h8mr777417qaf.49.1385837587648; Sat, 30 Nov 2013 10:53:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Sat, 30 Nov 2013 10:53:07 -0800 (PST) In-Reply-To: <20131130135616.GA59496@kib.kiev.ua> References: <20131130135616.GA59496@kib.kiev.ua> Date: Sat, 30 Nov 2013 10:53:07 -0800 X-Google-Sender-Auth: HFXMjo3tC-CKCSTQKfDJHwJD49Y Message-ID: Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 18:53:08 -0000 +1, this caught us out with sendfile testing very recently :( -a On 30 November 2013 05:56, Konstantin Belousov wrote: > I propose to unconditionally add the switch -fno-strict-overflow to the > kernel compilation. See the patch at the end of message for exact change > proposed. > > What does it do. It disallows useless and counter-intuitive behaviour of > the compiler(s) for the signed overflow. Basically, the issue is that > the C standard left signed overflow as undefined to allow for different > hardware implementation of signess to be used for signed arithmetic. > De-facto, all architectures where FreeBSD works or have a chance to be > ported, use two-complement signed integer representation, and developers > intuition is right about it. > > The compiler authors take the undefined part there as a blanket to perform > optimizations which are assuming that signed overflow cannot happen. The > problem with that approach is that typical checks for bounds are exactly > the place where the overflow can happen. Instead of making some artificial > example, I would just point to my own r258088 and r258397. > > What makes the things much worse is that the behaviour is highly depended > on the optimization level of the exact version of compiler. > > What other projects did in this regard. They turned the same knob > unconditionally. I can point at least to Linux kernel and Postgresql. > Python uses -fwrapv, which is equivalent to the -fno-strict-overflow > on the two-complement machines. Linux used -fwrapv before switched > to -fno-strict-overflow. > > diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk > index 2939a59..6e6ba92 100644 > --- a/sys/conf/kern.mk > +++ b/sys/conf/kern.mk > @@ -148,6 +148,12 @@ INLINE_LIMIT?= 8000 > CFLAGS+= -ffreestanding > > # > +# Do not allow a compiler to optimize out overflow checks for signed > +# types. > +# > +CFLAGS+= -fno-strict-overflow > + > +# > # GCC SSP support > # > .if ${MK_SSP} != "no" && ${MACHINE_CPUARCH} != "ia64" && \ From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 21:30:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1279482A; Sat, 30 Nov 2013 21:30:10 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3CB31AE0; Sat, 30 Nov 2013 21:30:09 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id rAULU65W070380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Nov 2013 13:30:07 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rAULU6jM070379; Sat, 30 Nov 2013 13:30:06 -0800 (PST) (envelope-from jmg) Date: Sat, 30 Nov 2013 13:30:06 -0800 From: John-Mark Gurney To: Venkata Duvvuru Subject: Re: sysctl add macros Message-ID: <20131130213006.GC55638@funkthat.com> Mail-Followup-To: Venkata Duvvuru , Matthew Fleming , "freebsd-current@freebsd.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 30 Nov 2013 13:30:07 -0800 (PST) Cc: Matthew Fleming , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 21:30:10 -0000 Venkata Duvvuru wrote this message on Mon, Nov 25, 2013 at 14:58 +0000: > The problem with using int or u_int for 1 or 2 byte values is that while printing these 1 or 2 byte values I observed that sysctl module is considering 4 bytes. Hence I see an undesired output. It is actually considering the next two bytes also as the value. If you _NEED_ to use a char or short, you need to write your own/clone it from the macros... Why can't you use an int for this variable? > From: mdf356@gmail.com [mailto:mdf356@gmail.com] On Behalf Of Matthew Fleming > Sent: Monday, November 25, 2013 8:18 PM > To: Venkata Duvvuru > Cc: freebsd-current@freebsd.org > Subject: Re: sysctl add macros > > On Mon, Nov 25, 2013 at 3:35 AM, Venkata Duvvuru > wrote: > Hi, > I'm unable to figure out how to add an unsigned short or an unsigned char values to a sysctl node. > SYSCTL_ADD_INT, SYSCTL_ADD_UINT, etc., are present but to add a char or a short values I couldn't find any macros. > > Could you please let me know how to add them? > > FreeBSD does not have any sysctl handlers for 1 or 2 byte values. FreeBSD code that wants to do this has used int or u_int instead of a smaller type. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 21:43:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 212BACE9 for ; Sat, 30 Nov 2013 21:43:18 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE8CF1BD4 for ; Sat, 30 Nov 2013 21:43:17 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VmsJj-0001uM-6z for freebsd-current@freebsd.org; Sat, 30 Nov 2013 22:43:15 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Nov 2013 22:43:11 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Nov 2013 22:43:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Sat, 30 Nov 2013 21:42:49 +0000 (UTC) Lines: 36 Message-ID: References: <52995C15.7010903@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 21:43:18 -0000 gmx.com> writes: > ... > So new flags could be [1]: > - realloc_flags(p, s, REALLOCF_NO_MOVE): Resize object p, without moving > it, to size s. With this restriction, when requesting more memory, and > the specified amount isn't available, don't do anything (when requesting > less memory, always succeed). > - realloc_flags(p, s, REALLOCF_NO_MOVE | REALLOCF_ELASTIC): Resize object > p, without moving it, to size s. With this restriction, when requesting > more memory, and the specified amount isn't available, reserve as much as > possible (when requesting less memory, always succeed). > ... The realloc_flags(), having different behavior from realloc(), should state what happens if: If the pointer is a null pointer, the function does not change anything. If the new size is zero, the function does not change anything. If the new size is the same as the old size, the function does not change anything. The return values have to be reviewed also. The function returns: - a pointer to the object specifid on entry - a null pointer if the object could not be modified - a null pointer if there was insufficient free memory available to extend the size of the object Reference to realloc(): http://www.cplusplus.com/reference/cstdlib/realloc/ jb From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 22:05:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80954667; Sat, 30 Nov 2013 22:05:15 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 456871CFC; Sat, 30 Nov 2013 22:05:15 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C14113EB42; Sat, 30 Nov 2013 21:57:26 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id rAULvQfH068553; Sat, 30 Nov 2013 21:57:26 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds In-reply-to: From: "Poul-Henning Kamp" References: <20131130135616.GA59496@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 30 Nov 2013 21:57:25 +0000 Message-ID: <68552.1385848645@critter.freebsd.dk> Cc: Konstantin Belousov , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 22:05:15 -0000 In message , Adrian Chadd writes: >> The compiler authors take the undefined part there as a blanket to perform >> optimizations which are assuming that signed overflow cannot happen. That's sufficient explanation for me to support your proposal. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 22:36:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FE52138; Sat, 30 Nov 2013 22:36:25 +0000 (UTC) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D47DB1E67; Sat, 30 Nov 2013 22:36:24 +0000 (UTC) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_ftISHxvL5H+AYDZeUZXaaA)" Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MX300K00LFUN700@smtpauth2.wiscmail.wisc.edu>; Sat, 30 Nov 2013 16:36:22 -0600 (CST) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.30.222715, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (adsl-76-208-69-44.dsl.mdsnwi.sbcglobal.net [76.208.69.44]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MX300AGBLGIEM00@smtpauth2.wiscmail.wisc.edu>; Sat, 30 Nov 2013 16:36:22 -0600 (CST) Date: Sat, 30 Nov 2013 16:36:18 -0600 From: Nathan Whitehorn Subject: Re: [CFT] bsdinstall and zfsboot enhancements In-reply-to: To: Devin Teske Message-id: <529A6862.7060308@freebsd.org> X-Enigmail-Version: 1.5.2 References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> <5281441E.7060806@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Cc: "freebsd-arch@freebsd.org" , Peter Grehan , "Teske, Devin" , Current Current , Michael Dexter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 22:36:25 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ftISHxvL5H+AYDZeUZXaaA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 11/11/13 14:57, Teske, Devin wrote: > On Nov 11, 2013, at 12:54 PM, Nathan Whitehorn wrote: > >> On 11/11/13 14:30, Nathan Whitehorn wrote: >>> On 11/11/13 14:18, Teske, Devin wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA512 >>>> >>>> >>>> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: >>>> >>>> >>>> Hello all, >>>> >>>> I have been experimenting with various BSD and GNU/Linux boot media >>>> under bhyve and noticed that we may want to accommodate the "LiveCD" >>>> mode of the installer, which in turn requires the correct console. >>>> >>>> Currently, one is prompted for VT100 for installation but this does not >>>> appear to work/stick for LiveCD mode. >>>> >>>> Can anyone verify this? >>>> >>>> >>>> While I developed this patch... >>>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%253A%253Absdinstall%253A%253Ascripts%253A%253Aconfig.patch?revision%3D1.10%26view%3Dmarkup&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=aZg%2BxwqLTX6Zcpf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0A&s=6d54d337ea5472f5713ddbe7788d3248c45feefd4b291eab0a976c39e9d40428 >>>> >>>> Reasons exist to search for a better solution, see here: >>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=aZg%2BxwqLTX6Zcpf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0A&s=5f8128901747346f937ffc4478eadb4bc39059504258dfb9b36f0fb9e7a61b79 >>>> (and messages that follow it) >>>> >>>> Is modifying init(8) still the way to go? What modification do we want to make? >>>> I'll do the work if we can come to consensus. >>>> >>>> Or should we touch up the patch in some way to address the original concerns? >>>> >>> I think modifying init is the way to go -- it keeps the install system from interfering with the installed one, as well as fixing this kind of issue with moved hard drives or PXE booting or what have you. If we can provide a guarantee that any system that displays text has a working console (unless explicitly configured not to), useability is improved. >>> >>> I would propose one of the following (and volunteer to write the code): >>> >>> Option A >>> ------------ >>> >>> 1. init checks if there is an entry in /etc/ttys for the terminal[s] corresponding to the value[s] in kern.console >>> 2. If an entry for each console terminal exists in /etc/ttys, enable it >>> 3. If not, invent one with a terminal type of "ansi" >>> >>> The one issue here is that someone may want to force a particular entry to off and still have it be the kernel console. This is tricky. We could invent a new "status" field that is not "on" or "off" ("auto", maybe, or "ifconsole"?). Which brings us to: >> One easy way to accomplish this is just to only implement (1) and (3), then comment out the ttyu0 entry in /etc/ttys on x86 instead of marking it "off". Then the behavior is just that a tty marked "off" stays off, one marked "on" stays on, and one not present spawns login with a terminal type corresponding to "console" (by default "unknown") if it happens to be the console. I will implement this over the next few days and then send patches unless anyone has an objection. > I love it. (smiles) > > Excellent idea and that's the winner I think. > > +1 This took much longer than I'd anticipated, but the patch to init is attached. I chose not to make the changes to init rather than getttyent() and friends in libc, which I am open to revisiting. The behavior changes are as follows: If the "console" device in /etc/ttys in marked "on", instead of opening /dev/console, init will loop through the active kernel console devices, and for each will: 1. If the kernel console device is in /etc/ttys and marked "on", it already has a terminal and will be ignored. 2. If marked "off", that is an explicit statement that a console is not wanted and so it will be ignored. 3. If not present in /etc/ttys, init will run getty with whatever parameters "console" has. (3) is the main behavioral change. No changes in behavior will occur if /etc/ttys is not modified. If we turn on "console" by default, it will usually have no effect instead of trying to run multiple gettys, which is new. If we then also comment out the ttyu0 line, instead of marking it "off", the result will be the conditional presence of a login prompt on the first serial port depending on whether it is an active console device for the kernel. I believe this is the behavior we are going for. Comments and test results would be appreciated. -Nathan --Boundary_(ID_ftISHxvL5H+AYDZeUZXaaA) Content-type: text/plain; CHARSET=US-ASCII; name=init-ttys.diff Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=init-ttys.diff Index: init.c =================================================================== --- init.c (revision 258756) +++ init.c (working copy) @@ -1102,22 +1102,84 @@ } /* + * Do something for all defined TTYs + */ +static void +do_allttys(void (*callback)(struct ttyent *, void *), void *cookie) +{ + struct ttyent *typ; + char *buf, *cons, *nextcons; + size_t len; + + /* Loop through /etc/ttys */ + while ((typ = getttyent()) != NULL) { + if (strcmp(typ->ty_name, "console") == 0) + continue; + + callback(typ, cookie); + } + + /* Mix in any active console devices not in /etc/ttys */ + buf = NULL; + if (sysctlbyname("kern.console", NULL, &len, NULL, 0) == -1) + goto done; + buf = malloc(len); + if (sysctlbyname("kern.console", buf, &len, NULL, 0) == -1) + goto done; + + if ((cons = strchr(buf, '/')) == NULL) + goto done; + *cons = '\0'; + nextcons = buf; + while ((cons = strsep(&nextcons, ",")) != NULL && strlen(cons) != 0) { + typ = getttynam(cons); + if (typ != NULL) /* Skip terminals with known configs */ + continue; + typ = getttynam("console"); + typ->ty_name = cons; + + callback(typ, cookie); + } + +done: + if (buf != NULL) + free(buf); + endttyent(); +} + +/* * Walk the list of ttys and create sessions for each active line. */ +struct read_ttys_args { + int session_index; + session_t *sp; +}; + +static void +read_ttys_callback(struct ttyent *typ, void *cookie) +{ + struct read_ttys_args *args = cookie; + session_t *snext; + + if ((snext = new_session(args->sp, ++args->session_index, typ)) != NULL) + args->sp = snext; +} + static state_func_t read_ttys(void) { - int session_index = 0; - session_t *sp, *snext; - struct ttyent *typ; + struct read_ttys_args args; + session_t *snext; + args.session_index = 0; + /* * Destroy any previous session state. * There shouldn't be any, but just in case... */ - for (sp = sessions; sp; sp = snext) { - snext = sp->se_next; - free_session(sp); + for (args.sp = sessions; args.sp; args.sp = snext) { + snext = args.sp->se_next; + free_session(args.sp); } sessions = 0; if (start_session_db()) @@ -1127,12 +1189,8 @@ * Allocate a session entry for each active port. * Note that sp starts at 0. */ - while ((typ = getttyent()) != NULL) - if ((snext = new_session(sp, ++session_index, typ)) != NULL) - sp = snext; + do_allttys(read_ttys_callback, &args); - endttyent(); - return (state_func_t) multi_user; } @@ -1375,85 +1433,93 @@ /* * This is an (n*2)+(n^2) algorithm. We hope it isn't run often... */ -static state_func_t -clean_ttys(void) +static void +clean_ttys_callback(struct ttyent *typ, void *cookie) { + int *session_index = cookie; session_t *sp, *sprev; - struct ttyent *typ; - int session_index = 0; int devlen; char *old_getty, *old_window, *old_type; - /* - * mark all sessions for death, (!SE_PRESENT) - * as we find or create new ones they'll be marked as keepers, - * we'll later nuke all the ones not found in /etc/ttys - */ - for (sp = sessions; sp != NULL; sp = sp->se_next) - sp->se_flags &= ~SE_PRESENT; - devlen = sizeof(_PATH_DEV) - 1; - while ((typ = getttyent()) != NULL) { - ++session_index; + ++(*session_index); - for (sprev = 0, sp = sessions; sp; sprev = sp, sp = sp->se_next) - if (strcmp(typ->ty_name, sp->se_device + devlen) == 0) - break; + for (sprev = 0, sp = sessions; sp; sprev = sp, sp = sp->se_next) + if (strcmp(typ->ty_name, sp->se_device + devlen) == 0) + break; - if (sp) { - /* we want this one to live */ - sp->se_flags |= SE_PRESENT; - if (sp->se_index != session_index) { - warning("port %s changed utmp index from %d to %d", - sp->se_device, sp->se_index, - session_index); - sp->se_index = session_index; - } - if ((typ->ty_status & TTY_ON) == 0 || - typ->ty_getty == 0) { - sp->se_flags |= SE_SHUTDOWN; - kill(sp->se_process, SIGHUP); - continue; - } - sp->se_flags &= ~SE_SHUTDOWN; - old_getty = sp->se_getty ? strdup(sp->se_getty) : 0; - old_window = sp->se_window ? strdup(sp->se_window) : 0; - old_type = sp->se_type ? strdup(sp->se_type) : 0; - if (setupargv(sp, typ) == 0) { - warning("can't parse getty for port %s", - sp->se_device); - sp->se_flags |= SE_SHUTDOWN; - kill(sp->se_process, SIGHUP); - } - else if ( !old_getty - || (!old_type && sp->se_type) - || (old_type && !sp->se_type) - || (!old_window && sp->se_window) - || (old_window && !sp->se_window) - || (strcmp(old_getty, sp->se_getty) != 0) - || (old_window && strcmp(old_window, sp->se_window) != 0) - || (old_type && strcmp(old_type, sp->se_type) != 0) - ) { + if (sp) { + /* we want this one to live */ + sp->se_flags |= SE_PRESENT; + if (sp->se_index != *session_index) { + warning("port %s changed utmp index from %d to %d", + sp->se_device, sp->se_index, + *session_index); + sp->se_index = *session_index; + } + if ((typ->ty_status & TTY_ON) == 0 || + typ->ty_getty == 0) { + sp->se_flags |= SE_SHUTDOWN; + kill(sp->se_process, SIGHUP); + return; + } + sp->se_flags &= ~SE_SHUTDOWN; + old_getty = sp->se_getty ? strdup(sp->se_getty) : 0; + old_window = sp->se_window ? strdup(sp->se_window) : 0; + old_type = sp->se_type ? strdup(sp->se_type) : 0; + if (setupargv(sp, typ) == 0) { + warning("can't parse getty for port %s", + sp->se_device); + sp->se_flags |= SE_SHUTDOWN; + kill(sp->se_process, SIGHUP); + } + else if ( !old_getty + || (!old_type && sp->se_type) + || (old_type && !sp->se_type) + || (!old_window && sp->se_window) + || (old_window && !sp->se_window) + || (strcmp(old_getty, sp->se_getty) != 0) + || (old_window && strcmp(old_window, sp->se_window) != 0) + || (old_type && strcmp(old_type, sp->se_type) != 0) + ) { /* Don't set SE_SHUTDOWN here */ sp->se_nspace = 0; sp->se_started = 0; kill(sp->se_process, SIGHUP); - } - if (old_getty) - free(old_getty); - if (old_window) - free(old_window); - if (old_type) - free(old_type); - continue; } - - new_session(sprev, session_index, typ); + if (old_getty) + free(old_getty); + if (old_window) + free(old_window); + if (old_type) + free(old_type); + return; } - endttyent(); + new_session(sprev, *session_index, typ); +} +static state_func_t +clean_ttys(void) +{ + session_t *sp; + int session_index = 0; + /* + * mark all sessions for death, (!SE_PRESENT) + * as we find or create new ones they'll be marked as keepers, + * we'll later nuke all the ones not found in /etc/ttys + */ + for (sp = sessions; sp != NULL; sp = sp->se_next) + sp->se_flags &= ~SE_PRESENT; + + /* + * Loop over all TTYs and sync state + */ + do_allttys(clean_ttys_callback, &session_index); + + + /* * sweep through and kill all deleted sessions * ones who's /etc/ttys line was deleted (SE_PRESENT unset) */ --Boundary_(ID_ftISHxvL5H+AYDZeUZXaaA)-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 23:25:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E80472B for ; Sat, 30 Nov 2013 23:25:47 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37D8110D1 for ; Sat, 30 Nov 2013 23:25:47 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::85ac:c2ca:692d:9ae] (unknown [IPv6:2001:7b8:3a7:0:85ac:c2ca:692d:9ae]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 83C285C43; Sun, 1 Dec 2013 00:25:39 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_58A31E6E-76CD-4ADB-81F8-9BDF34F6B0A8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds From: Dimitry Andric In-Reply-To: <20131130135616.GA59496@kib.kiev.ua> Date: Sun, 1 Dec 2013 00:25:21 +0100 Message-Id: References: <20131130135616.GA59496@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1822) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 23:25:47 -0000 --Apple-Mail=_58A31E6E-76CD-4ADB-81F8-9BDF34F6B0A8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 30 Nov 2013, at 14:56, Konstantin Belousov wrote: > I propose to unconditionally add the switch -fno-strict-overflow to the > kernel compilation. See the patch at the end of message for exact change > proposed. > > What does it do. It disallows useless and counter-intuitive behaviour of > the compiler(s) for the signed overflow. Basically, the issue is that > the C standard left signed overflow as undefined to allow for different > hardware implementation of signess to be used for signed arithmetic. > De-facto, all architectures where FreeBSD works or have a chance to be > ported, use two-complement signed integer representation, and developers > intuition is right about it. I think this is quite a misrepresentation. Any C compiler is free to do whatever it wants whenever it encounters undefined behavior. Some behavior is undefined in the C standards, so compilers can do a better job at optimization. If the optimized code fails to do what the programmer thinks it does, it is almost always the programmer's fault, excluding actual compiler bugs (which are unavoidable, as all software has bugs). Basically, if you rely on undefined behavior, you are inventing your own de facto language, which is *not* C. That is fine with me, but let's not pretend the FreeBSD kernel is written in C then. :-) > The compiler authors take the undefined part there as a blanket to perform > optimizations which are assuming that signed overflow cannot happen. The > problem with that approach is that typical checks for bounds are exactly > the place where the overflow can happen. Instead of making some artificial > example, I would just point to my own r258088 and r258397. > > What makes the things much worse is that the behaviour is highly depended > on the optimization level of the exact version of compiler. Of course it is: the behavior is undefined, so the compiler is free to randomly do anything. Garbage in, garbage out. > What other projects did in this regard. They turned the same knob > unconditionally. I can point at least to Linux kernel and Postgresql. > Python uses -fwrapv, which is equivalent to the -fno-strict-overflow > on the two-complement machines. Linux used -fwrapv before switched > to -fno-strict-overflow. If this makes the life of kernel developers easier, so be it. But I still feel this is a bit of a cop-out, and we could also just fix the bugs instead. -Dimitry --Apple-Mail=_58A31E6E-76CD-4ADB-81F8-9BDF34F6B0A8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKac+4ACgkQsF6jCi4glqPwcQCcC/uDUmEJZQquITSUxwSHu6U2 lNQAn2gArUEn9uDnIyYrSeBfpkIVOJt0 =6u3V -----END PGP SIGNATURE----- --Apple-Mail=_58A31E6E-76CD-4ADB-81F8-9BDF34F6B0A8--