From owner-freebsd-current@FreeBSD.ORG Sun Nov 25 00:37:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E344EC1 for ; Sun, 25 Nov 2012 00:37:35 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id EEFBA8FC12 for ; Sun, 25 Nov 2012 00:37:33 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0ME000L00PQFNE00@smtpauth2.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Sat, 24 Nov 2012 18:37:27 -0600 (CST) Received: from comporellon.tachypleus.net ([unknown] [76.210.69.142]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0ME000EA4PQEFN20@smtpauth2.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Sat, 24 Nov 2012 18:37:27 -0600 (CST) Date: Sat, 24 Nov 2012 18:37:26 -0600 From: Nathan Whitehorn Subject: Re: wifi + wpa_supplicant in 9.1-RC3 In-reply-to: Sender: whitehorn@wisc.edu To: freebsd-current@freebsd.org Message-id: <50B16846.5000805@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.69.142 X-Spam-PmxInfo: Server=avs-16, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.25.3017, SenderIP=76.210.69.142 References: User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121116 Thunderbird/16.0.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Nov 2012 00:37:35 -0000 On 11/20/12 07:52, CeDeROM wrote: > Hello :-) > > I have some problems with WiFi connectivity on my Dell Latitude E4310 > laptop with Intel card. Very often connection is broken, although > windows clients of the same network is working fine. I need to turn > radio off and on, sometimes this does not help, I need to kill > wpa_supplicant and start one by hand, so probably this is something > related with wpa_supplicant. Anyone observed similar issues? > > Btw if WiFi N supported? > > Best regards :-) > Tomek > This has been happening to be with iwn(4) for years. It will print something to the console about firmware watchdog timeouts and then the device needs to be restarted. It seems to happen only in radio-busy environments and also happens with clear-text networks. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Nov 25 04:58:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88C45FB2; Sun, 25 Nov 2012 04:58:54 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id E579A8FC08; Sun, 25 Nov 2012 04:58:53 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id a14so3075558eaa.13 for ; Sat, 24 Nov 2012 20:58:52 -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=8ssv+iuq/6NdrL3cX8SwmlVykoi9P7CkhjnhkjQ823M=; b=mX0E0CTr+Txqf4ZGEDkUMWY4TxglubVD6RNt77BBK/EEAalPQ6DwXilzsUxJKnVRYT EJUQBrKSkXnGK9p9dpYT7XTPKJRYW512/G6M0+IUjV73Pf7wiSNdbYlwBUzzFVhLTan3 KxLHXIYx/xA9XOulbTaRfqaLuAwa3kui5H2KnVJhBAvv5ZJED0HcWV1NXqSSArk6f5S1 rPscgzdFnn0/b+TQOa9KlCycGP5mYppXD0iQjT7BlpgSmYc/Ols9+oPuYhMgGbilBs+C zxwIIlJQR4z6JMA/xG4lTSPLlj4hTneRDKUyIJsBY9Gga5kSGQK23deMBkhYp20Q56Zw pfOw== MIME-Version: 1.0 Received: by 10.14.2.196 with SMTP id 44mr2349954eef.25.1353819532785; Sat, 24 Nov 2012 20:58:52 -0800 (PST) Received: by 10.223.71.199 with HTTP; Sat, 24 Nov 2012 20:58:52 -0800 (PST) In-Reply-To: <50B16846.5000805@freebsd.org> References: <50B16846.5000805@freebsd.org> Date: Sat, 24 Nov 2012 20:58:52 -0800 Message-ID: Subject: Re: wifi + wpa_supplicant in 9.1-RC3 From: Kevin Oberman To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Nov 2012 04:58:54 -0000 On Sat, Nov 24, 2012 at 4:37 PM, Nathan Whitehorn wrote: > On 11/20/12 07:52, CeDeROM wrote: >> >> Hello :-) >> >> I have some problems with WiFi connectivity on my Dell Latitude E4310 >> laptop with Intel card. Very often connection is broken, although >> windows clients of the same network is working fine. I need to turn >> radio off and on, sometimes this does not help, I need to kill >> wpa_supplicant and start one by hand, so probably this is something >> related with wpa_supplicant. Anyone observed similar issues? >> >> Btw if WiFi N supported? >> >> Best regards :-) >> Tomek >> > > This has been happening to be with iwn(4) for years. It will print something > to the console about firmware watchdog timeouts and then the device needs to > be restarted. It seems to happen only in radio-busy environments and also > happens with clear-text networks. Try turning off background scanning. 'ifconfig wlan0 -bgscan'. Note that this will have negative impact on roaming, but has never really caused me any real problems. I have found problems with several Wifi cards in "busy" locations, such as conferences and public places with multiple APs. iwn support N, but my experience has not been good. With a 'G' connection to my AP, I get about 20 Mbps, but when I turn on 'N', it drops to about 8 Mbps. I would not assume that 'N' is going to work better with the current software. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Nov 25 05:06:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C10B172; Sun, 25 Nov 2012 05:06:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id D30538FC08; Sun, 25 Nov 2012 05:06:24 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hm9so2118045wib.13 for ; Sat, 24 Nov 2012 21:06:23 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=e9dpPe6YEG78iWsNHoO+rb7aW+KrqYE+Yuoz3+GNsrI=; b=BvMTXWTRsAmbaw438kuWweDz9IzMN0PLumwEDOeJRn9FS/ox1Lx41mEkfat8mRG5x+ o2NYvfq0dALHLP+0GmF3TD49vU4fLd0ivzYrxuE7CPLDvnOzCNhFGzjKq9TucCWp6lA6 68MD4d5DCK+N5NJEsF1gGM29Ao0bQXVrA8lMzAbsv8RtYaHtH/lMQH7b7n3exKX4DIOb z2COqPybNrVmW6PfOfUt8ZgPQIdyk7RP42fFr64vD8ci2HUUy43ExecY7KQ0onB901Qh UJ/kATOVe6or0zoaQoN44x/xujybvS1ZIA0eLq4vKQhcGwySBEqhpDt0GgNPuMT0sdVh h1BA== MIME-Version: 1.0 Received: by 10.180.103.106 with SMTP id fv10mr12101489wib.19.1353819983497; Sat, 24 Nov 2012 21:06:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 24 Nov 2012 21:06:23 -0800 (PST) In-Reply-To: References: <50B16846.5000805@freebsd.org> Date: Sat, 24 Nov 2012 21:06:23 -0800 X-Google-Sender-Auth: GDk3whbq_ETHAAkoV_oo7EcrPhI Message-ID: Subject: Re: wifi + wpa_supplicant in 9.1-RC3 From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Nov 2012 05:06:25 -0000 On 24 November 2012 20:58, Kevin Oberman wrote: > iwn support N, but my experience has not been good. With a 'G' > connection to my AP, I get about 20 Mbps, but when I turn on 'N', it > drops to about 8 Mbps. I would not assume that 'N' is going to work > better with the current software. Have you filed a bug about this? Bernhard has done a pretty amazing job at getting iwn(4) 802.11n support working quite well. Adrian From owner-freebsd-current@FreeBSD.ORG Sun Nov 25 12:49:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AEBA47B; Sun, 25 Nov 2012 12:49:48 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 72F698FC08; Sun, 25 Nov 2012 12:49:47 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so9823353lah.13 for ; Sun, 25 Nov 2012 04:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ye3+vD0gXN4d4ZfjBlrPSS8t84n3qTqJn0KxZWwxcrA=; b=oWxHKG9JrWdcCiwuXqVfETUqzgxrRNH5A5l2GeWTirUOhl66P+POIAyWZkZPsie0yx iSfUZ6LvB0QO6euvDrhMRGS6WWEJiv9W4mFCEm8vzJ2qzNK7c/Dl70Zn33uNofzb/nDr RfrTYEoq72zNW9iJI9D/ImJZScVleEhZZnNb9/vwZkGitxnRRrfV5IVh5L84obb8IA7E GfINf3oCKHfUDZHdY4Cb7IqWDE7H8ctntyIzmbe5cBkVNCSjnIHcwkUYB8TDrQ1MyO1m bPI07AVbKQ0TKU02uXs/PDL+9rcoGrrQCX3BUaO43YslpjLf0u5j9Ux7ZcpqBPf6oDP7 sSMw== MIME-Version: 1.0 Received: by 10.112.26.67 with SMTP id j3mr3945437lbg.39.1353847784627; Sun, 25 Nov 2012 04:49:44 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sun, 25 Nov 2012 04:49:44 -0800 (PST) In-Reply-To: References: Date: Sun, 25 Nov 2012 12:49:44 +0000 X-Google-Sender-Auth: RkY4p3ghi-Wpi21JavQrwsPneNo Message-ID: Subject: Re: Spurious witness warning when destroying spin mtx From: Attilio Rao To: Ryan Stone , John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 12:49:48 -0000 On Sat, Nov 24, 2012 at 3:01 PM, Attilio Rao wrote: > On Sat, Nov 24, 2012 at 3:08 AM, Ryan Stone wrote: >> Today I saw a spurious witness warning for "acquiring duplicate lock of >> same type". The root cause is that when running mtx_destroy on a spinlock >> that is held by the current thread, mtx_destroy calls spinlock_exit() >> before calling WITNESS_UNLOCK, which opens up a window in which the CPU can >> be interrupted and attempt to acquire another spinlock of the same type as >> the one being destroyed. This patch should fix it: > > I seriously wonder why right now we don't assume the lock is unheld. > There are likely historically reasons for that, but I would like to > know which one are those and eventually fix them out. > FWIK, all the other locking primitives assume the lock is already > unheld when destroying and I think it would be good to have that for > mutexes as well. > > Can you please show which lock triggers the panic you saw? Ryan, however I'm sure this patch would introduce a major switch in our KPI/POLA and eventually it would be a bigger work. Your patch is certainly right and I think you should commit it for the time being. For the long-term, maybe you would like to work on such a patch, rather. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Nov 25 22:26:22 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A72DB4C for ; Sun, 25 Nov 2012 22:26:22 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 71AC28FC0C for ; Sun, 25 Nov 2012 22:26:21 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7F27340005 for ; Sun, 25 Nov 2012 23:26:19 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 713D640009; Sun, 25 Nov 2012 23:26:19 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 3090440005 for ; Sun, 25 Nov 2012 23:26:19 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y8m7Z5kYzz8hVn for ; Sun, 25 Nov 2012 23:26:18 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id ESQx6SRnuEL5 for ; Sun, 25 Nov 2012 23:26:16 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y8m7X5S91z8hVm for ; Sun, 25 Nov 2012 23:26:16 +0100 (CET) Received: from tifa.daemonic.se (tifa.daemonic.se [IPv6:2001:470:dca9:1::6]) by mail.daemonic.se (Postfix) with ESMTPSA id 3Y8m7X53j2z9Ctj for ; Sun, 25 Nov 2012 23:26:16 +0100 (CET) Received: from tifa.daemonic.se (localhost [IPv6:::1]) by tifa.daemonic.se (Postfix) with ESMTP id E874622AFA for ; Sun, 25 Nov 2012 23:26:15 +0100 (CET) Message-ID: <50B29B07.20808@daemonic.se> Date: Sun, 25 Nov 2012 23:26:15 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: current@freebsd.org Subject: panic: sbuf_trim makes no sense on sbuf 0xffffff82434d8898 with drain Content-Type: multipart/mixed; boundary="------------020505080100030203010700" X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Nov 2012 22:26:22 -0000 This is a multi-part message in MIME format. --------------020505080100030203010700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi! I consistently get this panic while trying to boot a kernel build from r243530. It happens when the entropy harvesting rc.d script starts. r243380 worked fine, I haven't tested any revisions in between. Attached is the backtrace from the kernel, as gotten by kgdb. The machine uses zfs as a root pool, and there have been churn in this area. To my untrained eyes, however, the issue seem related to hdaa.c. Please let me know if I can provide any more information. Regards! -- Niclas --------------020505080100030203010700 Content-Type: application/octet-stream; name="panic.out" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="panic.out" U2NyaXB0IHN0YXJ0ZWQgb24gU3VuIE5vdiAyNSAyMzoxNToyMiAyMDEyCnJvb3RAdml2aTpj cmFzaCMga2dkYiAvYm9vdC9rZXJuZWwva2VybmVsIHZtY29yZS4wIA0NCkdOVSBnZGIgNi4x LjEgW0ZyZWVCU0RdDQpDb3B5cmlnaHQgMjAwNCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24s IEluYy4NCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJh bCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBhcmUNCndlbGNvbWUgdG8gY2hhbmdlIGl0IGFu ZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBpdCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbnMu DQpUeXBlICJzaG93IGNvcHlpbmciIHRvIHNlZSB0aGUgY29uZGl0aW9ucy4NClRoZXJlIGlz IGFic29sdXRlbHkgbm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHki IGZvciBkZXRhaWxzLg0KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQgYXMgImFtZDY0LW1hcmNl bC1mcmVlYnNkIi4uLg0KDQpVbnJlYWQgcG9ydGlvbiBvZiB0aGUga2VybmVsIG1lc3NhZ2Ug YnVmZmVyOg0KMCwgYWRkciAxPiBvbiB1c2J1czANCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNi dXMxDQp1aHViMTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2J1czENCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMyDQp1 aHViMjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2J1czINCnVnZW4zLjE6IDxJbnRlbD4gYXQgdXNidXMzDQp1aHViMzog PEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAx PiBvbiB1c2J1czMNCnVnZW40LjE6IDxJbnRlbD4gYXQgdXNidXM0DQp1aHViNDogPEludGVs IFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2J1czQNCnVnZW41LjE6IDxJbnRlbD4gYXQgdXNidXM1DQp1aHViNTogPEludGVsIFVIQ0kg cm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czUN CnVnZW42LjE6IDxJbnRlbD4gYXQgdXNidXM2DQp1aHViNjogPEludGVsIFVIQ0kgcm9vdCBI VUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czYNCnVnZW43 LjE6IDxJbnRlbD4gYXQgdXNidXM3DQp1aHViNzogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNs YXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czcNCnVodWIwOiAyIHBv cnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjE6IDIgcG9ydHMgd2l0 aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVodWI0OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUs IHNlbGYgcG93ZXJlZA0KdWh1YjU6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkDQp1aHViNjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQN CnVodWIzOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1Yjc6 IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1Z2VuMi4yOiA8TG9n aXRlY2g+IGF0IHVzYnVzMg0KdW1zMDogPExvZ2l0ZWNoIFVTQi1QUzIgT3B0aWNhbCBNb3Vz ZSwgY2xhc3MgMC8wLCByZXYgMi4wMC8xOC4wMCwgYWRkciAyPiBvbiB1c2J1czINCnVtczA6 IDYgYnV0dG9ucyBhbmQgW1hZWl0gY29vcmRpbmF0ZXMgSUQ9MA0KdWdlbjIuMzogPExvZ2l0 ZWNoPiBhdCB1c2J1czINCnVrYmQwOiA8VVNCIEtleWJvYXJkPiBvbiB1c2J1czINCmtiZDAg YXQgdWtiZDANCnVoaWQwOiA8VVNCIEtleWJvYXJkPiBvbiB1c2J1czINCmFoY2ljaDM6IFRp bWVvdXQgb24gc2xvdCAwIHBvcnQgMA0KYWhjaWNoMzogaXMgMDAwMDAwMDAgY3MgMDAwMDAw MDAgc3MgMDAwMDAwMDAgcnMgMDAwMDAwMDEgdGZkIDUwIHNlcnIgMDAwMDAwMDAgY21kIDAw MDRjMDE3DQooYXByb2JlMDphaGNpY2gzOjA6MDowKTogU0VURkVBVFVSRVMgU0VUIFRSQU5T RkVSIE1PREUuIEFDQjogZWYgMDMgMDAgMDAgMDAgNDAgMDAgMDAgMDAgMDAgNDQgMDANCihh cHJvYmUwOmFoY2ljaDM6MDowOjApOiBDQU0gc3RhdHVzOiBDb21tYW5kIHRpbWVvdXQNCihh cHJvYmUwOmFoY2ljaDM6MDowOjApOiBFcnJvciA1LCBSZXRyeSB3YXMgYmxvY2tlZA0Kc2Vz MCBhdCBhaGNpZW0wIGJ1cyAwIHNjYnVzNiB0YXJnZXQgMCBsdW4gMA0Kc2VzMDogPEFIQ0kg U0dQSU8gRW5jbG9zdXJlIDEuMDAgMDAwMT4gU0VNQiBTLUUtUyAyLjAwIGRldmljZQ0Kc2Vz MDogU0VNQiBTRVMgRGV2aWNlDQphZGEwIGF0IGFoY2ljaDAgYnVzIDAgc2NidXMwIHRhcmdl dCAwIGx1biAwDQphZGEwOiA8U0FNU1VORyBIRDEwM1NKIDFBSjEwMDAxPiBBVEEtOCBTQVRB IDIueCBkZXZpY2UNCmFkYTA6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVE TUE2LCBQSU8gODE5MmJ5dGVzKQ0KYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkDQph ZGEwOiA5NTM4NjlNQiAoMTk1MzUyNTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1Qg MTYzODNDKQ0KYWRhMSBhdCBhaGNpY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4gMA0K YWRhMTogPFNBTVNVTkcgSEQxMDNTSiAxQUoxMDAwMT4gQVRBLTggU0FUQSAyLnggZGV2aWNl DQphZGExOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgx OTJieXRlcykNCmFkYTE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZA0KYWRhMTogOTUzODY5 TUIgKDE5NTM1MjUxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykNCmFk YTIgYXQgYWhjaWNoMiBidXMgMCBzY2J1czIgdGFyZ2V0IDAgbHVuIDANCmFkYTI6IDxTQU1T VU5HIEhEMTAzU0ogMUFKMTAwMDE+IEFUQS04IFNBVEEgMi54IGRldmljZQ0KYWRhMjogMzAw LjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpDQph ZGEyOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQNCmFkYTI6IDk1Mzg2OU1CICgxOTUzNTI1 MTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpDQpTTVA6IEFQIENQVSAj MyBMYXVuY2hlZCENClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQ0KU01QOiBBUCBDUFUgIzIg TGF1bmNoZWQhDQpUaW1lY291bnRlciAiVFNDLWxvdyIgZnJlcXVlbmN5IDEwNDE1Njk2IEh6 IHF1YWxpdHkgMTAwMA0KV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0 IHJlZHVjZWQgcGVyZm9ybWFuY2UuDQpjZDAgYXQgYWhjaWNoMyBidXMgMCBzY2J1czMgdGFy Z2V0IDAgbHVuIDANCmNkMDogPFBJT05FRVIgRFZELVJXICBEVlItMjE1IDEuMTk+IFJlbW92 YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSANCmNkMDogMTUwLjAwME1CL3MgdHJhbnNmZXJz IChTQVRBIDEueCwgVURNQTQsIEFUQVBJIDEyYnl0ZXMsIFBJTyA4MTkyYnl0ZXMpDQpjZDA6 IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1 bSBub3QgcHJlc2VudA0KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB6ZnM6enJvb3QgW10u Li4NCjwxMTg+U2V0dGluZyBob3N0dXVpZDogYmZiNjhmOGUtZWFiYi0xMWRjLTllODQtMDAx M2Q0ZDljOTQwLg0KPDExOD5TZXR0aW5nIGhvc3RpZDogMHgxN2FmYWFhOS4NCjwxMTg+U3Rh cnRpbmcgZGRiLg0KPDExOD5FbnRyb3B5IGhhcnZlc3Rpbmc6IGludGVycnVwdHMgZXRoZXJu ZXQNCnBhbmljOiBzYnVmX3RyaW0gbWFrZXMgbm8gc2Vuc2Ugb24gc2J1ZiAweGZmZmZmZjgy NDM0ZDg4OTggd2l0aCBkcmFpbg0KY3B1aWQgPSAzDQpLREI6IGVudGVyOiBwYW5pYw0KDQpS ZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvemZzLmtvLi4uUmVhZGluZyBzeW1i b2xzIGZyb20gL2Jvb3Qva2VybmVsL3pmcy5rby5zeW1ib2xzLi4uZG9uZS4NCmRvbmUuDQpM b2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL3pmcy5rbw0KUmVhZGluZyBzeW1ib2xz IGZyb20gL2Jvb3Qva2VybmVsL29wZW5zb2xhcmlzLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZy b20gL2Jvb3Qva2VybmVsL29wZW5zb2xhcmlzLmtvLnN5bWJvbHMuLi5kb25lLg0KZG9uZS4N CkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvb3BlbnNvbGFyaXMua28NCiMwICBk b2FkdW1wICh0ZXh0ZHVtcD0wKSBhdCBwY3B1Lmg6MjI5DQoyMjkJcGNwdS5oOiBObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5Lg0KCWluIHBjcHUuaA0KKGtnZGIpIGJ0DQojMCAgZG9hZHVt cCAodGV4dGR1bXA9MCkgYXQgcGNwdS5oOjIyOQ0KIzEgIDB4ZmZmZmZmZmY4MDJkMTUzMiBp biBkYl9mbmNhbGwgKGR1bW15MT08dmFsdWUgb3B0aW1pemVkIG91dD4sIA0KICAgIGR1bW15 Mj08dmFsdWUgb3B0aW1pemVkIG91dD4sIGR1bW15Mz08dmFsdWUgb3B0aW1pemVkIG91dD4s IA0KICAgIGR1bW15ND08dmFsdWUgb3B0aW1pemVkIG91dD4pIGF0IC91c3Ivc3JjL3N5cy9k ZGIvZGJfY29tbWFuZC5jOjU3OA0KIzIgIDB4ZmZmZmZmZmY4MDJkMTJkNCBpbiBkYl9jb21t YW5kIChsYXN0X2NtZHA9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCANCiAgICBjbWRfdGFibGU9 PHZhbHVlIG9wdGltaXplZCBvdXQ+LCBkb3BhZ2VyPTApDQogICAgYXQgL3Vzci9zcmMvc3lz L2RkYi9kYl9jb21tYW5kLmM6NDQ5DQojMyAgMHhmZmZmZmZmZjgwMmQ1M2VmIGluIGRiX3Nj cmlwdF9leGVjICgNCiAgICBzY3JpcHRuYW1lPTB4ZmZmZmZmODI0MzRkODNjMCAia2RiLmVu dGVyLnBhbmljIiwgDQogICAgd2Fybmlmbm90Zm91bmQ9PHZhbHVlIG9wdGltaXplZCBvdXQ+ KSBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX3NjcmlwdC5jOjMwMg0KIzQgIDB4ZmZmZmZmZmY4 MDJkNTIyNiBpbiBkYl9zY3JpcHRfa2RiZW50ZXIgKGV2ZW50bmFtZT0weDApDQogICAgYXQg L3Vzci9zcmMvc3lzL2RkYi9kYl9zY3JpcHQuYzozMjQNCiM1ICAweGZmZmZmZmZmODAyZDM4 ZWIgaW4gZGJfdHJhcCAodHlwZT08dmFsdWUgb3B0aW1pemVkIG91dD4sIGNvZGU9MCkNCiAg ICBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX21haW4uYzoyMzANCiM2ICAweGZmZmZmZmZmODA0 OTQzMGUgaW4ga2RiX3RyYXAgKHR5cGU9MywgY29kZT0wLCB0Zj08dmFsdWUgb3B0aW1pemVk IG91dD4pDQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9rZGIuYzo2NTQNCiM3ICAw eGZmZmZmZmZmODA2YTdiYWEgaW4gdHJhcCAoZnJhbWU9MHhmZmZmZmY4MjQzNGQ4NmYwKQ0K ICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6NTc5DQojOCAgMHhmZmZm ZmZmZjgwNjkxYTUyIGluIGNhbGx0cmFwICgpIGF0IC90bXAvZXhjZXB0aW9uLTlWWWVmci5z OjE3OQ0KIzkgIDB4ZmZmZmZmZmY4MDQ5M2IwZSBpbiBrZGJfZW50ZXIgKHdoeT0weGZmZmZm ZmZmODA3NDM3NDAgInBhbmljIiwgDQogICAgbXNnPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0Pikg YXQgY3B1ZnVuYy5oOjYzDQojMTAgMHhmZmZmZmZmZjgwNDYyMmU0IGluIHBhbmljIChmbXQ9 PHZhbHVlIG9wdGltaXplZCBvdXQ+KQ0KICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f c2h1dGRvd24uYzo2MTANCiMxMSAweGZmZmZmZmZmODA0OWNkY2YgaW4gc2J1Zl90cmltIChz PTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikNCi0tLVR5cGUgPHJldHVybj4gdG8gY29udGludWUs IG9yIHEgPHJldHVybj4gdG8gcXVpdC0tLQ0KICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3N1 YnJfc2J1Zi5jOjY1Mw0KIzEyIDB4ZmZmZmZmZmY4MDM1ODM0ZCBpbiBoZGFhX3N5c2N0bF9j YXBzIChvaWRwPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgDQogICAgYXJnMT0weDgwLCBhcmcy PS0yMTQyNjY0MTI4LCByZXE9PHZhbHVlIG9wdGltaXplZCBvdXQ+KQ0KICAgIGF0IC91c3Iv c3JjL3N5cy9kZXYvc291bmQvcGNpL2hkYS9oZGFhLmM6MTIyMg0KIzEzIDB4ZmZmZmZmZmY4 MDQ2Y2NmNyBpbiBzeXNjdGxfcm9vdCAoYXJnMT08dmFsdWUgb3B0aW1pemVkIG91dD4sIA0K ICAgIGFyZzI9PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBhdCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3N5c2N0bC5jOjE1MTMNCiMxNCAweGZmZmZmZmZmODA0NmQyZjIgaW4gdXNlcmxhbmRf c3lzY3RsICh0ZD08dmFsdWUgb3B0aW1pemVkIG91dD4sIA0KICAgIG5hbWU9MHhmZmZmZmY4 MjQzNGQ4YTcwLCBuYW1lbGVuPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgDQogICAgb2xkPTx2 YWx1ZSBvcHRpbWl6ZWQgb3V0Piwgb2xkbGVucD08dmFsdWUgb3B0aW1pemVkIG91dD4sIA0K ICAgIGlua2VybmVsPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgbmV3PTx2YWx1ZSBvcHRpbWl6 ZWQgb3V0PiwgDQogICAgbmV3bGVuPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgcmV0dmFsPTx2 YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgDQogICAgZmxhZ3M9MTEyOTE1NDk3NikgYXQgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl9zeXNjdGwuYzoxNjIzDQojMTUgMHhmZmZmZmZmZjgwNDZkMTI0 IGluIHN5c19fX3N5c2N0bCAodGQ9MHhmZmZmZmUwMDA4YzVhNDgwLCANCiAgICB1YXA9MHhm ZmZmZmY4MjQzNGQ4YjgwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3N5c2N0bC5jOjE1 NDkNCiMxNiAweGZmZmZmZmZmODA2YTg4MzUgaW4gYW1kNjRfc3lzY2FsbCAodGQ9MHhmZmZm ZmUwMDA4YzVhNDgwLCB0cmFjZWQ9MCkNCiAgICBhdCBzdWJyX3N5c2NhbGwuYzoxMzUNCiMx NyAweGZmZmZmZmZmODA2OTFkM2IgaW4gWGZhc3Rfc3lzY2FsbCAoKSBhdCAvdG1wL2V4Y2Vw dGlvbi05VlllZnIuczozMjkNCiMxOCAweDAwMDAwMDA4MDA5MjZmZWEgaW4gPz8gKCkNClBy ZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQ0KQ3Vy cmVudCBsYW5ndWFnZTogIGF1dG87IGN1cnJlbnRseSBtaW5pbWFsDQooa2dkYikgcXVpdA0K cm9vdEB2aXZpOmNyYXNoIyB1bmFtZSAtYQ0NCkZyZWVCU0Qgdml2aS5kYWVtb25pYy5zZSAx MC4wLUNVUlJFTlQgRnJlZUJTRCAxMC4wLUNVUlJFTlQgIzEgcjI0MzM4MDogVGh1IE5vdiAy MiAwMDo1NTowOCBDRVQgMjAxMiAgICAgcm9vdEB2aXZpLmRhZW1vbmljLnNlOi91c3Ivb2Jq L3Vzci9zcmMvc3lzL1ZJVkkgIGFtZDY0DQpyb290QHZpdmk6Y3Jhc2gjIF5ECAhleGl0DQoK U2NyaXB0IGRvbmUgb24gU3VuIE5vdiAyNSAyMzoxNjozOCAyMDEyCg== --------------020505080100030203010700-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 25 22:48:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F385E73; Sun, 25 Nov 2012 22:48:25 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 39B868FC08; Sun, 25 Nov 2012 22:48:25 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so1879215pad.13 for ; Sun, 25 Nov 2012 14:48:19 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sbCTjGY42Ks9QL87GriqoRfU0EXsrY9EnEglxjSJFVw=; b=oSZEF0D3ZcGOT6m5JKopnJJM2VnfvGt5wuTgv0HEsI+rN+wBBuTlh538AOWruQZF0H y8tx3a/oXMDY9qz0zpHXb8BKxGpZ0UnvtLaDyDeF2qunWImAOK9fNVq0bKjb5Tv0Cks2 C1COdSJjq6uXyPHasdKJv6j0aY1ooafMSC9z6Ve8DDO2tvLTIVz2w3KFZw/Yq7XKGPUG KpWPsdb7RYj93cjERQ5EODDVkg3wl7PvyDFoH6B09wfb79fVMxsatfil5jKrhPtPfM4A 9BqHXZtuEKMzBJh7V7xt/BrEIb90Hmbt6pNpGH6w6iltuEk/WYWjtd4AEfESn7tx6ToT b8jg== MIME-Version: 1.0 Received: by 10.68.233.196 with SMTP id ty4mr32575446pbc.23.1353883699489; Sun, 25 Nov 2012 14:48:19 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.132.136 with HTTP; Sun, 25 Nov 2012 14:48:19 -0800 (PST) In-Reply-To: <50B29B07.20808@daemonic.se> References: <50B29B07.20808@daemonic.se> Date: Sun, 25 Nov 2012 14:48:19 -0800 X-Google-Sender-Auth: zOKpkIe9mlqCzF7qYiRQ_IMWX5w Message-ID: Subject: Re: panic: sbuf_trim makes no sense on sbuf 0xffffff82434d8898 with drain From: mdf@FreeBSD.org To: Niclas Zeising Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Nov 2012 22:48:25 -0000 On Sun, Nov 25, 2012 at 2:26 PM, Niclas Zeising wrote: > Hi! > I consistently get this panic while trying to boot a kernel build from > r243530. It happens when the entropy harvesting rc.d script starts. r243380 > worked fine, I haven't tested any revisions in between. Attached is the > backtrace from the kernel, as gotten by kgdb. The machine uses zfs as a > root pool, and there have been churn in this area. To my untrained eyes, > however, the issue seem related to hdaa.c. Please let me know if I can > provide any more information. r243530 added the new sysctl that is causing panic. I'm not sure why there's an sbuf_trim() call; there shouldn't be more than a few \n at the end. IMO the sbuf_trim() can be eliminated. Alternately, the panic check can be removed and we could allow sbuf_trim() to remove any un-emitted whitespace for an sbuf with drain. CC'ing mav@ who introduced the code. (I introduced sbuf drains). Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Sun Nov 25 22:56:22 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3136B186; Sun, 25 Nov 2012 22:56:22 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 946108FC0C; Sun, 25 Nov 2012 22:56:21 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id D8E0340005; Sun, 25 Nov 2012 23:56:20 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id CE53A40009; Sun, 25 Nov 2012 23:56:20 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id B825540005; Sun, 25 Nov 2012 23:56:19 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y8mpC2fbnz8hVn; Sun, 25 Nov 2012 23:56:19 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id dYd1_9gErbvD; Sun, 25 Nov 2012 23:56:17 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y8mp91kHhz8hVm; Sun, 25 Nov 2012 23:56:17 +0100 (CET) Received: from tifa.daemonic.se (tifa.daemonic.se [10.32.0.6]) by mail.daemonic.se (Postfix) with ESMTPSA id 3Y8mp91KLSz9Ctj; Sun, 25 Nov 2012 23:56:17 +0100 (CET) Received: from tifa.daemonic.se (localhost [IPv6:::1]) by tifa.daemonic.se (Postfix) with ESMTP id 10A5C22AFA; Sun, 25 Nov 2012 23:56:17 +0100 (CET) Message-ID: <50B2A210.3020804@daemonic.se> Date: Sun, 25 Nov 2012 23:56:16 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: mdf@FreeBSD.org Subject: Re: panic: sbuf_trim makes no sense on sbuf 0xffffff82434d8898 with drain References: <50B29B07.20808@daemonic.se> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Alexander Motin , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Nov 2012 22:56:22 -0000 On 11/25/12 23:48, mdf@FreeBSD.org wrote: > On Sun, Nov 25, 2012 at 2:26 PM, Niclas Zeising > wrote: >> Hi! >> I consistently get this panic while trying to boot a kernel build from >> r243530. It happens when the entropy harvesting rc.d script starts. r243380 >> worked fine, I haven't tested any revisions in between. Attached is the >> backtrace from the kernel, as gotten by kgdb. The machine uses zfs as a >> root pool, and there have been churn in this area. To my untrained eyes, >> however, the issue seem related to hdaa.c. Please let me know if I can >> provide any more information. > > r243530 added the new sysctl that is causing panic. I'm not sure why > there's an sbuf_trim() call; there shouldn't be more than a few \n at > the end. IMO the sbuf_trim() can be eliminated. > > Alternately, the panic check can be removed and we could allow > sbuf_trim() to remove any un-emitted whitespace for an sbuf with > drain. > > CC'ing mav@ who introduced the code. (I introduced sbuf drains). > Thank you for the quick reply! Just to confirm, manually reverting r243530 makes the system boot without panicing. Regards! -- Niclas From owner-freebsd-current@FreeBSD.ORG Sun Nov 25 23:00:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5265E2CA for ; Sun, 25 Nov 2012 23:00:48 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C82A98FC16 for ; Sun, 25 Nov 2012 23:00:47 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so10071575lah.13 for ; Sun, 25 Nov 2012 15:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=lmNIH16X2uIMI2UBMKRR8iqwujzuMwF4ctHj0kt5rpU=; b=qvFsYDARMdC42O3lRsAkTvmO/Z+rSG6hC7ZvHhr2paPRb43rjEZsSLrfM1/td9GnmC 5AXkD6xrEx/b/C41hNAqAf/Sv3MYGxDdmOKrpGdrG9Ix+/v/68/IlYhI5fZgEuMZHYe2 8ldtAABrIDNwCM4UdaXeF29Wr/7EWy3d3fOyK3Uq9TtXzXwVNyELdY7+BrfS/PWgYfcE vceQSUyDAi5/kLQDeXd2wTByapuGv238oPz98TaQk2BEIV3nU9gpau7mOqH5v5N1mze8 Ofa/6clwXSMq2NAEtZVql36/MzXnqH8fDzF4FyfP3Q4sFcPr0myzKznPlEC22eukTCd/ p9GQ== MIME-Version: 1.0 Received: by 10.152.145.169 with SMTP id sv9mr9387719lab.2.1353884446341; Sun, 25 Nov 2012 15:00:46 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.12.226 with HTTP; Sun, 25 Nov 2012 15:00:46 -0800 (PST) Date: Mon, 26 Nov 2012 00:00:46 +0100 X-Google-Sender-Auth: B_ldnJLBgub6xWTVloVklh1Q21Y Message-ID: Subject: 9.1-RC3 magicnum/mount/cam issue From: CeDeROM To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Nov 2012 23:00:48 -0000 Hello :-) I have installed 9.1-RC3 on my desktop. After installation I wanted to mount Ext2 drive but provided bad device name, I got error that magic number was invalid, but then I had to wait some time until CAM returned error status to get back to the shell. Is that correct? The drive is functional. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 01:15:52 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B12C5551 for ; Mon, 26 Nov 2012 01:15:52 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 330788FC13 for ; Mon, 26 Nov 2012 01:15:51 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id qAQ0sGaT024158 for ; Mon, 26 Nov 2012 09:54:16 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili13) with ESMTP id qAQ0sG921543 for ; Mon, 26 Nov 2012 09:54:16 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi13) id qAQ0sGe7027781 for freebsd-current@FreeBSD.org; Mon, 26 Nov 2012 09:54:16 +0900 Received: from localhost by lomi13.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id qAQ0sGKJ027762 for ; Mon, 26 Nov 2012 09:54:16 +0900 Date: Mon, 26 Nov 2012 09:54:14 +0900 (JST) Message-Id: <20121126.095414.2127926346996476541.okuno.kohji@jp.panasonic.com> To: freebsd-current@FreeBSD.org Subject: About 802.1Q tag From: Kohji Okuno Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) 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.14 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, 26 Nov 2012 01:15:52 -0000 Hi, Would someone check the following code? If the hardware do not process an 802.1Q tag, the kernel repacks mbuf in line 578-580. But, `struct ether_header *eh' was assigned at line 484. And, in line 611-637, because of the kernel refers old eh pointer, the kernel will misjudges its ether packet. I think that `eh = mtod(m, struct ether_header *);' is needed after line 580. Thanks, Kohji Okuno sys/net/if_ethersubr.c: 448 static void 449 ether_input_internal(struct ifnet *ifp, struct mbuf *m) 450 { 451 struct ether_header *eh; 484 eh = mtod(m, struct ether_header *); 554 /* 555 * If the hardware did not process an 802.1Q tag, do this now, 556 * to allow 802.1P priority frames to be passed to the main input 557 * path correctly. 558 * TODO: Deal with Q-in-Q frames, but not arbitrary nesting levels. 559 */ 560 if ((m->m_flags & M_VLANTAG) == 0 && etype == ETHERTYPE_VLAN) { 578 bcopy((char *)evl, (char *)evl + ETHER_VLAN_ENCAP_LEN, 579 ETHER_HDR_LEN - ETHER_TYPE_LEN); 580 m_adj(m, ETHER_VLAN_ENCAP_LEN); 581 } 610 611 #if defined(INET) || defined(INET6) 612 /* 613 * Clear M_PROMISC on frame so that carp(4) will see it when the 614 * mbuf flows up to Layer 3. 615 * FreeBSD's implementation of carp(4) uses the inprotosw 616 * to dispatch IPPROTO_CARP. carp(4) also allocates its own 617 * Ethernet addresses of the form 00:00:5e:00:01:xx, which 618 * is outside the scope of the M_PROMISC test below. 619 * TODO: Maintain a hash table of ethernet addresses other than 620 * ether_dhost which may be active on this ifp. 621 */ 622 if (ifp->if_carp && (*carp_forus_p)(ifp, eh->ether_dhost)) { 623 m->m_flags &= ~M_PROMISC; 624 } else 625 #endif 626 { 627 /* 628 * If the frame received was not for our MAC address, set the 629 * M_PROMISC flag on the mbuf chain. The frame may need to 630 * be seen by the rest of the Ethernet input path in case of 631 * re-entry (e.g. bridge, vlan, netgraph) but should not be 632 * seen by upper protocol layers. 633 */ 634 if (!ETHER_IS_MULTICAST(eh->ether_dhost) && 635 bcmp(IF_LLADDR(ifp), eh->ether_dhost, ETHER_ADDR_LEN) != 0) 636 m->m_flags |= M_PROMISC; 637 } From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 01:54:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16988B6D; Mon, 26 Nov 2012 01:54:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9EFBA8FC12; Mon, 26 Nov 2012 01:54:24 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so2861483vba.13 for ; Sun, 25 Nov 2012 17:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EhjW/D1ueyGrA4wIkklHkbWMUOgdeIe30EQ5n1m0GzI=; b=kM7CCIQTYJanW1MXdM6WSe5MHIG2n6lo6zxomwA2JeiuNMC2QoFxdqQdo1jk6aVeMk oxYNK+vL/IVwTVxnCjquFPhTJkfLTTzTB1J2NEWHaTbtpt/8eqzHc78mGKmUBmPvsU7y z3Oj89T3+Yls7ytWC9Ul+w9273ZLh4mT/cJ8IURlPpptq1Y67I3jjpu/3vMpQtj5J7Up xkVe7VSNJdmXrItz3hzxdjTCh+3/RFawQYUpAkKOh+drD+lpMLMuA/lqcBrX9DmkldKH wXZUy6Mgc8WQDktEySvHrql7EpjqhCAKul4/oTnSU/nWZGcsoRZNoPU9LdqkV54UALMe esiA== Received: by 10.59.5.229 with SMTP id cp5mr17533943ved.32.1353894863726; Sun, 25 Nov 2012 17:54:23 -0800 (PST) Received: from mavbook.mavhome.dp.ua (cpe-67-244-107-195.nyc.res.rr.com. [67.244.107.195]) by mx.google.com with ESMTPS id cm9sm5162995vdb.3.2012.11.25.17.54.22 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Nov 2012 17:54:22 -0800 (PST) Sender: Alexander Motin Message-ID: <50B2CBCD.7090106@FreeBSD.org> Date: Mon, 26 Nov 2012 03:54:21 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: mdf@FreeBSD.org Subject: Re: panic: sbuf_trim makes no sense on sbuf 0xffffff82434d8898 with drain References: <50B29B07.20808@daemonic.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Niclas Zeising , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Nov 2012 01:54:25 -0000 On 26.11.2012 00:48, mdf@FreeBSD.org wrote: > On Sun, Nov 25, 2012 at 2:26 PM, Niclas Zeising > wrote: >> Hi! >> I consistently get this panic while trying to boot a kernel build from >> r243530. It happens when the entropy harvesting rc.d script starts. r243380 >> worked fine, I haven't tested any revisions in between. Attached is the >> backtrace from the kernel, as gotten by kgdb. The machine uses zfs as a >> root pool, and there have been churn in this area. To my untrained eyes, >> however, the issue seem related to hdaa.c. Please let me know if I can >> provide any more information. > > r243530 added the new sysctl that is causing panic. I'm not sure why > there's an sbuf_trim() call; there shouldn't be more than a few \n at > the end. IMO the sbuf_trim() can be eliminated. > > Alternately, the panic check can be removed and we could allow > sbuf_trim() to remove any un-emitted whitespace for an sbuf with > drain. > > CC'ing mav@ who introduced the code. (I introduced sbuf drains). Thanks. Removed. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 02:06:24 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F864105; Mon, 26 Nov 2012 02:06:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B97FE8FC12; Mon, 26 Nov 2012 02:06:23 +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 qAQ26GQu006552; Sun, 25 Nov 2012 21:06:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qAQ26GHX006543; Mon, 26 Nov 2012 02:06:16 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 26 Nov 2012 02:06:16 GMT Message-Id: <201211260206.qAQ26GHX006543@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 02:06:24 -0000 TB --- 2012-11-26 00:10:30 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-26 00:10:30 - 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 --- 2012-11-26 00:10:30 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-11-26 00:10:30 - cleaning the object tree TB --- 2012-11-26 00:10:30 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-26 00:10:30 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2012-11-26 00:10:30 - /usr/local/bin/svn cleanup /src TB --- 2012-11-26 00:11:33 - /usr/local/bin/svn update /src TB --- 2012-11-26 00:11:44 - At svn revision 243532 TB --- 2012-11-26 00:11:45 - building world TB --- 2012-11-26 00:11:45 - CROSS_BUILD_TESTING=YES TB --- 2012-11-26 00:11:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-26 00:11:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-26 00:11:45 - SRCCONF=/dev/null TB --- 2012-11-26 00:11:45 - TARGET=ia64 TB --- 2012-11-26 00:11:45 - TARGET_ARCH=ia64 TB --- 2012-11-26 00:11:45 - TZ=UTC TB --- 2012-11-26 00:11:45 - __MAKE_CONF=/dev/null TB --- 2012-11-26 00:11:45 - cd /src TB --- 2012-11-26 00:11:45 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 26 00:11:51 UTC 2012 >>> 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 26 01:54:25 UTC 2012 TB --- 2012-11-26 01:54:25 - generating LINT kernel config TB --- 2012-11-26 01:54:25 - cd /src/sys/ia64/conf TB --- 2012-11-26 01:54:25 - /usr/bin/make -B LINT TB --- 2012-11-26 01:54:25 - cd /src/sys/ia64/conf TB --- 2012-11-26 01:54:25 - /usr/sbin/config -m LINT TB --- 2012-11-26 01:54:25 - building LINT kernel TB --- 2012-11-26 01:54:25 - CROSS_BUILD_TESTING=YES TB --- 2012-11-26 01:54:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-26 01:54:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-26 01:54:25 - SRCCONF=/dev/null TB --- 2012-11-26 01:54:25 - TARGET=ia64 TB --- 2012-11-26 01:54:25 - TARGET_ARCH=ia64 TB --- 2012-11-26 01:54:25 - TZ=UTC TB --- 2012-11-26 01:54:25 - __MAKE_CONF=/dev/null TB --- 2012-11-26 01:54:25 - cd /src TB --- 2012-11-26 01:54:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 26 01:54:25 UTC 2012 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/sound/pci/t4dwave.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/sound/pci/via8233.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/sound/pci/via82c686.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/sound/pci/vibes.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/sound/pci/hda/hdaa.c cc1: warnings being treated as errors /src/sys/dev/sound/pci/hda/hdaa.c: In function 'hdaa_dump_ctls': /src/sys/dev/sound/pci/hda/hdaa.c:5556: warning: 'printed' may be used uninitialized in this function *** [hdaa.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-26 02:06:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-26 02:06:16 - ERROR: failed to build LINT kernel TB --- 2012-11-26 02:06:16 - 4883.79 user 1164.73 system 6946.21 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 08:10:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A21A5BD3 for ; Mon, 26 Nov 2012 08:10:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6DCD38FC1F for ; Mon, 26 Nov 2012 08:10:56 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so2150373pad.13 for ; Mon, 26 Nov 2012 00:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=7JLTCB9OoQGPrgG1CWvyaL8+SrVPUBfM5Rr+i5XPnJM=; b=wSKYY+/vJAcpHhSu1zpR8/Mu2xrzs1SQCFYydno8Axzszw5x7c6TiaeilIfcxOTwSL 8EAFsmteyF1QA1PzYElNdx+myJTdZ+JF5TLbL7tn6TbZ683sZBU7/7W6IffoHJEE1DIp 2FhDnzRY3CXFIsRrSrC12h1IGxjYzaOXnl1rvcVeo1DW43X0rJ5BCLxwqLgQ2dzgvQbN h9J97MnCCanltJ4c0rFH0vDHtFSIu1U4ElfBjrfVWx25G/R36vfNeQqJUe6iwr8k1Fba kgIi5UlcvUIyMpo5ijNwnR1lCkGksGGlCEu8+pdRi3s6ZZMNvFh86XjV2Wkc234oTDrc JjkA== Received: by 10.68.136.135 with SMTP id qa7mr35074936pbb.157.1353917455102; Mon, 26 Nov 2012 00:10:55 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id vs3sm8375285pbc.61.2012.11.26.00.10.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 00:10:53 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 26 Nov 2012 17:10:40 +0900 From: YongHyeon PYUN Date: Mon, 26 Nov 2012 17:10:40 +0900 To: Kohji Okuno Subject: Re: About 802.1Q tag Message-ID: <20121126081040.GA4076@michelle.cdnetworks.com> References: <20121126.095414.2127926346996476541.okuno.kohji@jp.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121126.095414.2127926346996476541.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 08:10:56 -0000 On Mon, Nov 26, 2012 at 09:54:14AM +0900, Kohji Okuno wrote: > Hi, > > Would someone check the following code? > > If the hardware do not process an 802.1Q tag, the kernel repacks mbuf > in line 578-580. But, `struct ether_header *eh' was assigned at line 484. > > And, in line 611-637, because of the kernel refers old eh pointer, the > kernel will misjudges its ether packet. > > I think that `eh = mtod(m, struct ether_header *);' is needed after > line 580. Yes, your analysis looks correct. > > Thanks, > Kohji Okuno > > sys/net/if_ethersubr.c: > 448 static void > 449 ether_input_internal(struct ifnet *ifp, struct mbuf *m) > 450 { > 451 struct ether_header *eh; > > 484 eh = mtod(m, struct ether_header *); > > 554 /* > 555 * If the hardware did not process an 802.1Q tag, do this now, > 556 * to allow 802.1P priority frames to be passed to the main input > 557 * path correctly. > 558 * TODO: Deal with Q-in-Q frames, but not arbitrary nesting levels. > 559 */ > 560 if ((m->m_flags & M_VLANTAG) == 0 && etype == ETHERTYPE_VLAN) { > > 578 bcopy((char *)evl, (char *)evl + ETHER_VLAN_ENCAP_LEN, > 579 ETHER_HDR_LEN - ETHER_TYPE_LEN); > 580 m_adj(m, ETHER_VLAN_ENCAP_LEN); > 581 } > > 610 > 611 #if defined(INET) || defined(INET6) > 612 /* > 613 * Clear M_PROMISC on frame so that carp(4) will see it when the > 614 * mbuf flows up to Layer 3. > 615 * FreeBSD's implementation of carp(4) uses the inprotosw > 616 * to dispatch IPPROTO_CARP. carp(4) also allocates its own > 617 * Ethernet addresses of the form 00:00:5e:00:01:xx, which > 618 * is outside the scope of the M_PROMISC test below. > 619 * TODO: Maintain a hash table of ethernet addresses other than > 620 * ether_dhost which may be active on this ifp. > 621 */ > 622 if (ifp->if_carp && (*carp_forus_p)(ifp, eh->ether_dhost)) { > 623 m->m_flags &= ~M_PROMISC; > 624 } else > 625 #endif > 626 { > 627 /* > 628 * If the frame received was not for our MAC address, set the > 629 * M_PROMISC flag on the mbuf chain. The frame may need to > 630 * be seen by the rest of the Ethernet input path in case of > 631 * re-entry (e.g. bridge, vlan, netgraph) but should not be > 632 * seen by upper protocol layers. > 633 */ > 634 if (!ETHER_IS_MULTICAST(eh->ether_dhost) && > 635 bcmp(IF_LLADDR(ifp), eh->ether_dhost, ETHER_ADDR_LEN) != 0) > 636 m->m_flags |= M_PROMISC; > 637 } From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 12:34:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BB9DDE2 for ; Mon, 26 Nov 2012 12:34:07 +0000 (UTC) (envelope-from lukasz.wojcik@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.103]) by mx1.freebsd.org (Postfix) with ESMTP id 3C74D8FC0C for ; Mon, 26 Nov 2012 12:34:06 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type; b=OX0X4uDhZ3mvH6iKF3cl7BOGfxa97wwyfGfkEciSS5if+Am5TCgXGiogJkxtSnmHVvcJQq5Zo//F EdFNWhSXppiQKaMoAqfsllcEjQkFTK8UupcZZ1qOn85wL4nDsy4O Received: from [192.168.100.175] (host-87-116-222-18.debica.mm.pl [87.116.222.18]) by mx.zohomail.com with SMTPS id 1353929969543569.0092420784406; Mon, 26 Nov 2012 03:39:29 -0800 (PST) Message-ID: <50B354F4.1070706@zoho.com> Date: Mon, 26 Nov 2012 12:39:32 +0100 From: Lukasz Wojcik User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20121028 Thunderbird/9.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: syscall cost freebsd vs linux ? References: <20121119193202.GA79496@onelab2.iet.unipi.it> In-Reply-To: <20121119193202.GA79496@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Nov 2012 12:34:07 -0000 On 11/19/12 20:32, Luigi Rizzo wrote: > today i was comparing the performance of some netmap-related code > on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that > our system calls are significantly slower. > On comparable hardware (i7-2600k vs E5-1650) the syscall > getppid() takes about 95ns on FreeBSD and 38ns on linux. > > (i make sure not to use gettimeofday(), which in linux is through vdso, > and getpid(), which is cached by glibc). > > Any idea on why there is this difference and whether/how > we can reduce it ? > I'm curious about how did you measure that ? Could you write some more about your methodology ? -LW > cheers > luigi > _______________________________________________ > 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 Mon Nov 26 14:31:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56CCFCCD for ; Mon, 26 Nov 2012 14:31:36 +0000 (UTC) (envelope-from sig6247@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1E41A8FC08 for ; Mon, 26 Nov 2012 14:31:35 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so8242513pbc.13 for ; Mon, 26 Nov 2012 06:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:subject:mime-version:content-type; bh=VmxkOoJQKoZirHza6LOpm3YgrnfCjGqwORtENAj4g1I=; b=aojmHFfzh70m1DYzGHQ0ZTW7Nc1BXTSyLbzw6PVHbROK3F03aZEkd0QoBIWm7+U0jV Tc1VJFiKn3xi+2VTEZZ6SYhARL2WuUmNcxqW7/3SlmTmkoLapG3EFUcYqL5wOowsmk+Y KXhgpDufuH0kBa7sPR+nyTWWlMtLo0gktZp/GCEczzNp+hFn7/vVI1YDLDGlpmKB6HoJ PFyaQaken1tydvhJlk+0A8zJnz5zrt7MFDMUDgEi7XzRXkznFub4OuzXO6yCnCqNsrq5 WblOikrso9xgYOodppOAYLLB+E0qi7seBUWRM9uyuvkBkV8pe+7j87D9gRnpzjD47wrP at7Q== Received: by 10.66.87.226 with SMTP id bb2mr33286323pab.57.1353940295613; Mon, 26 Nov 2012 06:31:35 -0800 (PST) Received: from localhost (manning2.torservers.net. [96.44.189.101]) by mx.google.com with ESMTPS id ou5sm8862198pbb.33.2012.11.26.06.31.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 06:31:34 -0800 (PST) Message-ID: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> Date: Mon, 26 Nov 2012 06:31:34 -0800 (PST) From: sig6247 To: freebsd-current@FreeBSD.org Subject: clang compiled kernel panic when mounting zfs root on i386 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Nov 2012 14:31:36 -0000 Hi, Just checked out r243529, this only happens when the kernel is compiled by clang, and only on i386, either recompiling the kernel with gcc or booting from a UFS root works fine. Is it a known problem? Thanks, ---------------------------------------------------------------------- WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot []... Fatal double fault: eip = 0xc0adc37d esp = 0xc86bffc8 ebp = 0xc86c003c cpuid = 1; apic id = 01 panic: double fault cpuid = 1 KDB: enter: panic [ thread pid 1 tid 100002 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> bt Tracing pid 1 tid 100002 td 0xc89efbc0 kdb_enter(c1064aa4,c1064aa4,c10b806f,c139e3b8,f5eacada,...) at kdb_enter+0x3d panic(c10b806f,1,1,1,c86c003c,...) at panic+0x14b dblfault_handler() at dblfault_handler+0xab --- trap 0x17, eip = 0xc0adc37d, esp = 0xc86bffc8, ebp = 0xc86c003c --- witness_checkorder(c1fd7508,9,c109df18,7fa,0,...) at witness_checkorder+0x37d __mtx_lock_flags(c1fd7518,0,c109df18,7fa,c135d918,...) at __mtx_lock_flags+0x87 uma_zalloc_arg(c1fd66c0,0,1,4d3,c86c0110,...) at uma_zalloc_arg+0x605 vm_map_insert(c1fd508c,c13dfc10,bb1f000,0,cba1e000,...) at vm_map_insert+0x499 kmem_back(c1fd508c,cba1e000,1000,3,c86c01d4,...) at kmem_back+0x76 kmem_malloc(c1fd508c,1000,3) at kmem_malloc+0x250 page_alloc(c1fd1d80,1000,c86c020b,3,c1fd1d80,...) at page_alloc+0x27 keg_alloc_slab(103,4,c109df18,870,cb99ef6c,...) at keg_alloc_slab+0xc3 keg_fetch_slab(103,c1fd1d80,cb99ef6c,c1fc8230,c86c02c0,...) at keg_fetch_slab+0xe2 zone_fetch_slab(c1fd1d80,c1fd0480,103,826,0,...) at zone_fetch_slab+0x43 uma_zalloc_arg(c1fd1d80,0,102,3,2,...) at uma_zalloc_arg+0x3f2 malloc(4c,c1686100,102,c86c0388,c173d09a,...) at malloc+0xe9 zfs_kmem_alloc(4c,102,cb618820,c89efbc0,cb618820,...) at zfs_kmem_alloc+0x20 vdev_mirror_io_start(cb8218a0,10,cb8218a0,1,0,...) at vdev_mirror_io_start+0x14a zio_vdev_io_start(cb8218a0,c89efbc0,0,cb8218a0,c86c0600,...) at zio_vdev_io_start+0x228 zio_execute(cb8218a0,cb618000,cba1b640,cb900000,400,...) at zio_execute+0x106 spa_load_verify_cb(cb618000,0,cba1b640,cb884b40,c86c0600,...) at spa_load_verify_cb+0x89 traverse_visitbp(cb884b40,cba1b640,c86c0600,c86c0ba0,0,...) at traverse_visitbp+0x29f traverse_dnode(cb884b40,0,0,8b,0,...) at traverse_dnode+0x92 traverse_visitbp(cb884bb8,cba07200,c86c0890,cb884bf4,c16ce7e0,...) at traverse_visitbp+0xe47 traverse_visitbp(cb884bf4,cb9bf840,c86c0968,c86c0ba0,0,...) at traverse_visitbp+0xf32 traverse_dnode(cb884bf4,0,0,0,0,...) at traverse_dnode+0x92 traverse_visitbp(0,cb618398,c86c0b50,2,cb9f1c78,...) at traverse_visitbp+0x96d traverse_impl(0,0,cb618398,3e1,0,...) at traverse_impl+0x268 traverse_pool(cb618000,3e1,0,d,c1727830,...) at traverse_pool+0x79 spa_load(0,1,c86c0ec4,1e,0,...) at spa_load+0x1dde spa_load(0,0,c13d8c94,1,3,...) at spa_load+0x11a5 spa_load_best(0,ffffffff,ffffffff,1,c0adc395,...) at spa_load_best+0x71 spa_open_common(c17e0e1e,0,0,c86c1190,c16f5a1c,...) at spa_open_common+0x11a spa_open(c86c1078,c86c1074,c17e0e1e,c135d918,c1fd7798,...) at spa_open+0x27 dsl_dir_open_spa(0,cb770030,c17e11b1,c86c11f8,c86c11f4,...) at dsl_dir_open_spa+0x6c dsl_dataset_hold(cb770030,cb613800,c86c1240,cb613800,cb613800,...) at dsl_dataset_hold+0x3a dsl_dataset_own(cb770030,0,cb613800,c86c1240,c1684e30,...) at dsl_dataset_own+0x21 dmu_objset_own(cb770030,2,1,cb613800,c86c1290,...) at dmu_objset_own+0x2a zfsvfs_create(cb770030,c86c13ac,c17ee05d,681,0,...) at zfsvfs_create+0x4c zfs_mount(cb78ed20,c17f411c,c9ff4600,c89cae80,0,...) at zfs_mount+0x42c vfs_donmount(c89efbc0,4000,0,c86c1790,cb6c0800,...) at vfs_donmount+0xc6d kernel_mount(cb7700b0,4000,0,0,1,...) at kernel_mount+0x6b parse_mount(cb7700e0,c1194498,0,1,0,...) at parse_mount+0x606 vfs_mountroot(c13d95b0,4,c105c042,2bb,0,...) at vfs_mountroot+0x6cf start_init(0,c86c1d08,c105e94c,3db,0,...) at start_init+0x6a fork_exit(c0a42090,0,c86c1d08) at fork_exit+0x7f fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc86c1d40, ebp = 0 --- db> From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 15:00:30 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FC894EA for ; Mon, 26 Nov 2012 15:00:30 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id CA92B8FC0C for ; Mon, 26 Nov 2012 15:00:29 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qAQF0SSH006570; Mon, 26 Nov 2012 19:00:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qAQF0S0S006569; Mon, 26 Nov 2012 19:00:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 26 Nov 2012 19:00:28 +0400 From: Gleb Smirnoff To: Paul Webster Subject: Re: Upgrading FreeBSD to use the NEW pf syntax. Message-ID: <20121126150028.GK84121@FreeBSD.org> References: <201211201543.17903.Mark.Martinec+freebsd@ijs.si> <20121121075642.GR67660@FreeBSD.org> <20121121145240.GE67660@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Nov 2012 15:00:30 -0000 Paul, On Sat, Nov 24, 2012 at 02:11:32PM -0000, Paul Webster wrote: P> I only really need one question answered in honesty; P> P> I personally think that by forking our own version of PF we have P> essentially made something totally different to what everyone wants to P> use. Which is fine, but because of that development of new features have P> dropped behind. P> P> If we had kept up with OpenBSD's version even if we trailed it by one P> MAJOR release; at least part of the development would have been done. P> P> So now we end up in a situation where we have these firewalls, P> IPFW2,ipf,pf(modded) and users wanting the newer features of OpenBSD's pf. P> So timewise the fork of pf may have actually cost more in time rather than P> less. P> P> I don't however think the 'solution' to the problem is just to say no to P> the userbase by not even trying to port across the newer pf. I think we P> should look at bringing it across, slowly and seeing what the uptake is P> like; in a few MAJOR releases we can start to look at which of the P> firewalls realistically are not used that much and should be deprecated. If you see a large userbase that eagers to see new pf, then you can port it to FreeBSD, maintain it, catch up with new versions from OpenBSD, and so on. No one forbids you doing that. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 17:17:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FEF8AC2; Mon, 26 Nov 2012 17:17:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id AD3548FC0C; Mon, 26 Nov 2012 17:17:10 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qAQHGwbN049728; Mon, 26 Nov 2012 19:16:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qAQHGwbN049728 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qAQHGwq6049727; Mon, 26 Nov 2012 19:16:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 26 Nov 2012 19:16:58 +0200 From: Konstantin Belousov To: sig6247 Subject: Re: clang compiled kernel panic when mounting zfs root on i386 Message-ID: <20121126171658.GD3013@kib.kiev.ua> References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="maH1Gajj2nflutpK" Content-Disposition: inline In-Reply-To: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, 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, fs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Nov 2012 17:17:11 -0000 --maH1Gajj2nflutpK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 26, 2012 at 06:31:34AM -0800, sig6247 wrote: >=20 > Hi, >=20 > Just checked out r243529, this only happens when the kernel is compiled > by clang, and only on i386, either recompiling the kernel with gcc or > booting from a UFS root works fine. Is it a known problem? It looks like that clang uses more stack than gcc, and zfs makes quite deep call chains. It would be a waste, generally, to increase the init process kernel stack size only to pacify zfs. And I suspect that it would not help in the similar situations when the same procedure initiated for non-root mounts. >=20 > Thanks, >=20 > ---------------------------------------------------------------------- > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from zfs:zroot []... >=20 > Fatal double fault: > eip =3D 0xc0adc37d > esp =3D 0xc86bffc8 > ebp =3D 0xc86c003c > cpuid =3D 1; apic id =3D 01 > panic: double fault > cpuid =3D 1 > KDB: enter: panic > [ thread pid 1 tid 100002 ] > Stopped at kdb_enter+0x3d: movl $0,kdb_why > db> bt > Tracing pid 1 tid 100002 td 0xc89efbc0 > kdb_enter(c1064aa4,c1064aa4,c10b806f,c139e3b8,f5eacada,...) at kdb_enter+= 0x3d > panic(c10b806f,1,1,1,c86c003c,...) at panic+0x14b > dblfault_handler() at dblfault_handler+0xab > --- trap 0x17, eip =3D 0xc0adc37d, esp =3D 0xc86bffc8, ebp =3D 0xc86c003c= --- > witness_checkorder(c1fd7508,9,c109df18,7fa,0,...) at witness_checkorder+0= x37d > __mtx_lock_flags(c1fd7518,0,c109df18,7fa,c135d918,...) at __mtx_lock_flag= s+0x87 > uma_zalloc_arg(c1fd66c0,0,1,4d3,c86c0110,...) at uma_zalloc_arg+0x605 > vm_map_insert(c1fd508c,c13dfc10,bb1f000,0,cba1e000,...) at vm_map_insert+= 0x499 > kmem_back(c1fd508c,cba1e000,1000,3,c86c01d4,...) at kmem_back+0x76 > kmem_malloc(c1fd508c,1000,3) at kmem_malloc+0x250 > page_alloc(c1fd1d80,1000,c86c020b,3,c1fd1d80,...) at page_alloc+0x27 > keg_alloc_slab(103,4,c109df18,870,cb99ef6c,...) at keg_alloc_slab+0xc3 > keg_fetch_slab(103,c1fd1d80,cb99ef6c,c1fc8230,c86c02c0,...) at keg_fetch_= slab+0xe2 > zone_fetch_slab(c1fd1d80,c1fd0480,103,826,0,...) at zone_fetch_slab+0x43 > uma_zalloc_arg(c1fd1d80,0,102,3,2,...) at uma_zalloc_arg+0x3f2 > malloc(4c,c1686100,102,c86c0388,c173d09a,...) at malloc+0xe9 > zfs_kmem_alloc(4c,102,cb618820,c89efbc0,cb618820,...) at zfs_kmem_alloc+0= x20 > vdev_mirror_io_start(cb8218a0,10,cb8218a0,1,0,...) at vdev_mirror_io_star= t+0x14a > zio_vdev_io_start(cb8218a0,c89efbc0,0,cb8218a0,c86c0600,...) at zio_vdev_= io_start+0x228 > zio_execute(cb8218a0,cb618000,cba1b640,cb900000,400,...) at zio_execute+0= x106 > spa_load_verify_cb(cb618000,0,cba1b640,cb884b40,c86c0600,...) at spa_load= _verify_cb+0x89 > traverse_visitbp(cb884b40,cba1b640,c86c0600,c86c0ba0,0,...) at traverse_v= isitbp+0x29f > traverse_dnode(cb884b40,0,0,8b,0,...) at traverse_dnode+0x92 > traverse_visitbp(cb884bb8,cba07200,c86c0890,cb884bf4,c16ce7e0,...) at tra= verse_visitbp+0xe47 > traverse_visitbp(cb884bf4,cb9bf840,c86c0968,c86c0ba0,0,...) at traverse_v= isitbp+0xf32 > traverse_dnode(cb884bf4,0,0,0,0,...) at traverse_dnode+0x92 > traverse_visitbp(0,cb618398,c86c0b50,2,cb9f1c78,...) at traverse_visitbp+= 0x96d > traverse_impl(0,0,cb618398,3e1,0,...) at traverse_impl+0x268 > traverse_pool(cb618000,3e1,0,d,c1727830,...) at traverse_pool+0x79 > spa_load(0,1,c86c0ec4,1e,0,...) at spa_load+0x1dde > spa_load(0,0,c13d8c94,1,3,...) at spa_load+0x11a5 > spa_load_best(0,ffffffff,ffffffff,1,c0adc395,...) at spa_load_best+0x71 > spa_open_common(c17e0e1e,0,0,c86c1190,c16f5a1c,...) at spa_open_common+0x= 11a > spa_open(c86c1078,c86c1074,c17e0e1e,c135d918,c1fd7798,...) at spa_open+0x= 27 > dsl_dir_open_spa(0,cb770030,c17e11b1,c86c11f8,c86c11f4,...) at dsl_dir_op= en_spa+0x6c > dsl_dataset_hold(cb770030,cb613800,c86c1240,cb613800,cb613800,...) at dsl= _dataset_hold+0x3a > dsl_dataset_own(cb770030,0,cb613800,c86c1240,c1684e30,...) at dsl_dataset= _own+0x21 > dmu_objset_own(cb770030,2,1,cb613800,c86c1290,...) at dmu_objset_own+0x2a > zfsvfs_create(cb770030,c86c13ac,c17ee05d,681,0,...) at zfsvfs_create+0x4c > zfs_mount(cb78ed20,c17f411c,c9ff4600,c89cae80,0,...) at zfs_mount+0x42c > vfs_donmount(c89efbc0,4000,0,c86c1790,cb6c0800,...) at vfs_donmount+0xc6d > kernel_mount(cb7700b0,4000,0,0,1,...) at kernel_mount+0x6b > parse_mount(cb7700e0,c1194498,0,1,0,...) at parse_mount+0x606 > vfs_mountroot(c13d95b0,4,c105c042,2bb,0,...) at vfs_mountroot+0x6cf > start_init(0,c86c1d08,c105e94c,3db,0,...) at start_init+0x6a > fork_exit(c0a42090,0,c86c1d08) at fork_exit+0x7f > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xc86c1d40, ebp =3D 0 --- > db>=20 > _______________________________________________ > 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" --maH1Gajj2nflutpK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCzpAoACgkQC3+MBN1Mb4j9FQCfX/BKJvG1317xh1X9RQQaCRmb FG0AoJTD3ObL+l6uWhI4ORT8GkSsGtIJ =/qn9 -----END PGP SIGNATURE----- --maH1Gajj2nflutpK-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 18:22:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5942B34F; Mon, 26 Nov 2012 18:22:26 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id AFC768FC15; Mon, 26 Nov 2012 18:22:25 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hm9so3155202wib.13 for ; Mon, 26 Nov 2012 10:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kCMgskCNE9+Z7AAuMsUypNaIqi9oQYgTFHyigan6Fa8=; b=V7/WzyGdP58lSxkaCUW+1NOHAA7Ml6+hwkh1M5HvBJV4VtOv+0zyrYU1He1u7868p7 A4pXqrm0m6FH0GHqAdOvPTSRgK42VotNMLafDsHDmEJ68z3kODtCYSaTlu71SagR4Nu4 67g7cG1Mww+i1UbLcuX6TCxA8pL404wE13fwDNzOiECaC9Jhem16OIj4ONau5EE6VKzw ULItccNqG1zu51znm0H80Xn3fhVinliPl35JmjM9wsSmyysV4iXHrDjEBQHOaYvo4PT7 1p9ni5D7g0QvozatS6KwXKiUsc0buJNPq8YzAzEe59pDEHQtMKADrlk4+03A3GR6zsGh u+Hw== Received: by 10.180.74.108 with SMTP id s12mr19218512wiv.12.1353954143931; Mon, 26 Nov 2012 10:22:23 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id bz12sm127354wib.5.2012.11.26.10.22.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 10:22:22 -0800 (PST) Date: Mon, 26 Nov 2012 19:22:14 +0100 From: Mateusz Guzik To: freebsd-rc@FreeBSD.org Subject: Re: after upgrade, can't restart apache via cron Message-ID: <20121126182214.GA17080@dft-labs.eu> References: <20121123031753.GA59632@bewilderbeast.blackhelicopters.org> <20121123.233754.1596631883684484110.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20121123.233754.1596631883684484110.hrs@allbsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@FreeBSD.org, mwlucas@michaelwlucas.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Nov 2012 18:22:26 -0000 On Fri, Nov 23, 2012 at 11:37:54PM +0900, Hiroki Sato wrote: > "Michael W. Lucas" wrote > in <20121123031753.GA59632@bewilderbeast.blackhelicopters.org>: > > mw> eval: setfib: not found > mw> /usr/local/etc/rc.d/apache22: WARNING: failed to start apache22 > mw> > mw> If I run /usr/local/etc/rc.d/apache22 restart from the command line, I > mw> can restart httpd without trouble. > mw> > mw> Any thoughts? > > This was due to $PATH in the cron job as already pointed out, but > this should not happen. I attached a patch to use full-path for > external commands in rc.subr. If there is no objection to this > change I will commit it. > service(8) tries to sanitize stuff before executing scripts. How about making this the default behaviour? Currently stuff like PATH "leak" to rc scripts and this can be harmful (for instance daemon was happily executing stuff from /usr/local/bin, yet after reboot it stopped working). Also I doubt anyone relies on current environment and what not to start a service, but we can provide another target tha would start the service without sanitizing in case this is needed. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 19:45:29 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1F88B04 for ; Mon, 26 Nov 2012 19:45:29 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3138FC12 for ; Mon, 26 Nov 2012 19:45:29 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qAQJjSu9007567; Mon, 26 Nov 2012 23:45:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qAQJjRqI007566; Mon, 26 Nov 2012 23:45:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 26 Nov 2012 23:45:27 +0400 From: Gleb Smirnoff To: Kohji Okuno Subject: Re: About 802.1Q tag Message-ID: <20121126194527.GN84121@FreeBSD.org> References: <20121126.095414.2127926346996476541.okuno.kohji@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20121126.095414.2127926346996476541.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Nov 2012 19:45:30 -0000 Kohji, On Mon, Nov 26, 2012 at 09:54:14AM +0900, Kohji Okuno wrote: K> Would someone check the following code? K> K> If the hardware do not process an 802.1Q tag, the kernel repacks mbuf K> in line 578-580. But, `struct ether_header *eh' was assigned at line 484. K> K> And, in line 611-637, because of the kernel refers old eh pointer, the K> kernel will misjudges its ether packet. K> K> I think that `eh = mtod(m, struct ether_header *);' is needed after K> line 580. Committed, thanks! -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 19:48:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD523C3C for ; Mon, 26 Nov 2012 19:48:06 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8247F8FC13 for ; Mon, 26 Nov 2012 19:48:06 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id g24so3883325qab.13 for ; Mon, 26 Nov 2012 11:48:04 -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 :content-type:content-transfer-encoding; bh=RGtgS/FjYlTc511EhXR30T3n+VHeOEtfT9Pf0JR6I2U=; b=o8KTf7i39u9Fi0JkS5uV9/S62dGUh90lkQwkjVTwbuLhPyk/F/5oU67yRCfc6Qydg4 3Kiatnc6PqB0vTfTrl2OWFIsRO54KPMOyeeBgVitHCrgy7RuX3G7PUDVbG82smyTCYes ssB+d+AwKM4LHHt0AS5Wo6rHd5ElwW3ihtT15/0wtseXawage0bP6jvgTzesZc5x/pia Q0T64vWe/N1PJnxXHkpdiOMe1s70UQBz2EnmbD2YebzgxY1tEVIx+2aF8a1WfBSpKvL/ mvTBVqH+2uXaHzCa7Jmx+Pwnes0h8PagD9vWPC+pwoSblq5XqtRtFqkf4aPN7r5QNTOs iFog== Received: by 10.224.60.18 with SMTP id n18mr13822375qah.36.1353959284245; Mon, 26 Nov 2012 11:48:04 -0800 (PST) Received: from bresson.poelloepaeae.de (jd-t430s.Princeton.EDU. [128.112.34.82]) by mx.google.com with ESMTPS id i9sm9242490qak.3.2012.11.26.11.48.03 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 11:48:03 -0800 (PST) Message-ID: <50B3C772.7040802@gmail.com> Date: Mon, 26 Nov 2012 14:48:02 -0500 From: Johannes Dieterich User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Samsung 830 and ZFS TRIM 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.14 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, 26 Nov 2012 19:48:06 -0000 Hello, (initially posted this to -questions@ a week ago, w/o reply) I installed CURRENT on a new Thinkpad equipped with a Samsung 830 SSD: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 as the setup is ZFS+GELI based (on ada0), I enabled ZFS TRIM support in loader.conf. Interestingly, I encounter an IMHO strange behavior with the stats on that: kstat.zfs.misc.zio_trim.zio_trim_bytes: 755712 kstat.zfs.misc.zio_trim.zio_trim_success: 97 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 7891 kstat.zfs.misc.zio_trim.zio_trim_failed: 0 It seems unintuitive to me why the unsupported counter first increases (seems to stay constant after that each boot) and then slowly the success counter increases as well. Probably there is a trivial explanation (GELI?) and/or fix for this that anyone is willing to share? If you need further information, let me know. Thanks a lot Johannes From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 21:21:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5472583; Mon, 26 Nov 2012 21:21:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 263408FC1C; Mon, 26 Nov 2012 21:21:14 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAQLL5T2008212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 08:21:06 +1100 Date: Tue, 27 Nov 2012 08:21:05 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: clang compiled kernel panic when mounting zfs root on i386 In-Reply-To: <20121126171658.GD3013@kib.kiev.ua> Message-ID: <20121127071243.D1255@besplex.bde.org> References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=TL4d0CZa c=1 sm=1 a=Dqyo4nusdH8A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=PZxpgLn_-10A:10 a=IMFgP6cxdJxPq-vExgcA:9 a=CjuIK1q_8ugA:10 a=yiplnose_AnHQ6Q_:21 a=7WiQoUoJrVuut8JH:21 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Mon, 26 Nov 2012 21:54:03 +0000 Cc: freebsd-current@freebsd.org, fs@freebsd.org, sig6247 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Nov 2012 21:21:15 -0000 On Mon, 26 Nov 2012, Konstantin Belousov wrote: > On Mon, Nov 26, 2012 at 06:31:34AM -0800, sig6247 wrote: >> >> Just checked out r243529, this only happens when the kernel is compiled >> by clang, and only on i386, either recompiling the kernel with gcc or >> booting from a UFS root works fine. Is it a known problem? > It looks like that clang uses more stack than gcc, and zfs makes quite > deep call chains. > > It would be a waste, generally, to increase the init process kernel > stack size only to pacify zfs. And I suspect that it would not help > in the similar situations when the same procedure initiated for non-root > mounts. Or to pacify clang... >> ---------------------------------------------------------------------- >> WARNING: WITNESS option enabled, expect reduced performance. >> Trying to mount root from zfs:zroot []... >> >> Fatal double fault: >> eip = 0xc0adc37d >> esp = 0xc86bffc8 >> ebp = 0xc86c003c >> cpuid = 1; apic id = 01 >> panic: double fault >> cpuid = 1 >> KDB: enter: panic >> [ thread pid 1 tid 100002 ] >> Stopped at kdb_enter+0x3d: movl $0,kdb_why >> db> bt >> Tracing pid 1 tid 100002 td 0xc89efbc0 >> kdb_enter(c1064aa4,c1064aa4,c10b806f,c139e3b8,f5eacada,...) at kdb_enter+0x3d >> panic(c10b806f,1,1,1,c86c003c,...) at panic+0x14b >> dblfault_handler() at dblfault_handler+0xab >> --- trap 0x17, eip = 0xc0adc37d, esp = 0xc86bffc8, ebp = 0xc86c003c --- >> witness_checkorder(c1fd7508,9,c109df18,7fa,0,...) at witness_checkorder+0x37d >> __mtx_lock_flags(c1fd7518,0,c109df18,7fa,c135d918,...) at __mtx_lock_flags+0x87 >> uma_zalloc_arg(c1fd66c0,0,1,4d3,c86c0110,...) at uma_zalloc_arg+0x605 >> vm_map_insert(c1fd508c,c13dfc10,bb1f000,0,cba1e000,...) at vm_map_insert+0x499 >> kmem_back(c1fd508c,cba1e000,1000,3,c86c01d4,...) at kmem_back+0x76 >> kmem_malloc(c1fd508c,1000,3) at kmem_malloc+0x250 >> page_alloc(c1fd1d80,1000,c86c020b,3,c1fd1d80,...) at page_alloc+0x27 >> keg_alloc_slab(103,4,c109df18,870,cb99ef6c,...) at keg_alloc_slab+0xc3 >> keg_fetch_slab(103,c1fd1d80,cb99ef6c,c1fc8230,c86c02c0,...) at keg_fetch_slab+0xe2 >> zone_fetch_slab(c1fd1d80,c1fd0480,103,826,0,...) at zone_fetch_slab+0x43 >> uma_zalloc_arg(c1fd1d80,0,102,3,2,...) at uma_zalloc_arg+0x3f2 >> malloc(4c,c1686100,102,c86c0388,c173d09a,...) at malloc+0xe9 >> zfs_kmem_alloc(4c,102,cb618820,c89efbc0,cb618820,...) at zfs_kmem_alloc+0x20 >> vdev_mirror_io_start(cb8218a0,10,cb8218a0,1,0,...) at vdev_mirror_io_start+0x14a >> zio_vdev_io_start(cb8218a0,c89efbc0,0,cb8218a0,c86c0600,...) at zio_vdev_io_start+0x228 >> zio_execute(cb8218a0,cb618000,cba1b640,cb900000,400,...) at zio_execute+0x106 >> spa_load_verify_cb(cb618000,0,cba1b640,cb884b40,c86c0600,...) at spa_load_verify_cb+0x89 >> traverse_visitbp(cb884b40,cba1b640,c86c0600,c86c0ba0,0,...) at traverse_visitbp+0x29f >> traverse_dnode(cb884b40,0,0,8b,0,...) at traverse_dnode+0x92 >> traverse_visitbp(cb884bb8,cba07200,c86c0890,cb884bf4,c16ce7e0,...) at traverse_visitbp+0xe47 >> traverse_visitbp(cb884bf4,cb9bf840,c86c0968,c86c0ba0,0,...) at traverse_visitbp+0xf32 >> traverse_dnode(cb884bf4,0,0,0,0,...) at traverse_dnode+0x92 >> traverse_visitbp(0,cb618398,c86c0b50,2,cb9f1c78,...) at traverse_visitbp+0x96d >> traverse_impl(0,0,cb618398,3e1,0,...) at traverse_impl+0x268 >> traverse_pool(cb618000,3e1,0,d,c1727830,...) at traverse_pool+0x79 >> spa_load(0,1,c86c0ec4,1e,0,...) at spa_load+0x1dde >> spa_load(0,0,c13d8c94,1,3,...) at spa_load+0x11a5 >> spa_load_best(0,ffffffff,ffffffff,1,c0adc395,...) at spa_load_best+0x71 >> spa_open_common(c17e0e1e,0,0,c86c1190,c16f5a1c,...) at spa_open_common+0x11a >> spa_open(c86c1078,c86c1074,c17e0e1e,c135d918,c1fd7798,...) at spa_open+0x27 >> dsl_dir_open_spa(0,cb770030,c17e11b1,c86c11f8,c86c11f4,...) at dsl_dir_open_spa+0x6c >> dsl_dataset_hold(cb770030,cb613800,c86c1240,cb613800,cb613800,...) at dsl_dataset_hold+0x3a >> dsl_dataset_own(cb770030,0,cb613800,c86c1240,c1684e30,...) at dsl_dataset_own+0x21 >> dmu_objset_own(cb770030,2,1,cb613800,c86c1290,...) at dmu_objset_own+0x2a >> zfsvfs_create(cb770030,c86c13ac,c17ee05d,681,0,...) at zfsvfs_create+0x4c >> zfs_mount(cb78ed20,c17f411c,c9ff4600,c89cae80,0,...) at zfs_mount+0x42c >> vfs_donmount(c89efbc0,4000,0,c86c1790,cb6c0800,...) at vfs_donmount+0xc6d >> kernel_mount(cb7700b0,4000,0,0,1,...) at kernel_mount+0x6b >> parse_mount(cb7700e0,c1194498,0,1,0,...) at parse_mount+0x606 >> vfs_mountroot(c13d95b0,4,c105c042,2bb,0,...) at vfs_mountroot+0x6cf >> start_init(0,c86c1d08,c105e94c,3db,0,...) at start_init+0x6a >> fork_exit(c0a42090,0,c86c1d08) at fork_exit+0x7f >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0, eip = 0, esp = 0xc86c1d40, ebp = 0 --- >> db> 43 deep (before the double fault) is disgusting, but even if clang has broken stack alignment due to a wrong default and no -mpreferred-stack-boundary to fix it, that's still only about 8*43 extra bytes (8 for the average extra stack to align to 16 bytes). Probably zfs is also putting large data structures on the stack. It would be useful if the stack trace printed the the stack pointer on every function call, so that you could see how much stack each function used. All those ', ...' printed after 5 args show further apparent clang lossage. vfs_mountroot takes no args at all, but the above shows ot taking 5 known args and further unknown args. ddb's stack tracer does limited parsing of the bytes in function's caller to guess the number of args. It usually guesses right for gcc. It apparently usually guesses wrong for clang. I can't test this for i386 since ref10-i386 is down, but for amd64 the parsing seems to be already too dificult for gcc and impossible for clang: for the function call in `void bar(void); void foo(void) { bar(); }', clang generates a tail call: % test: # @test % .cfi_startproc % # BB#0: # %entry % xorb %al, %al % jmp bar # TAILCALL % .Ltmp0: The bytes after the tail call are unparseable. The bytes before the tail call are difficult to parse, and AFAIR ddb doesn't look at them (the xorb says that there are no xmm args, but that is of no interest in the kernel). Gcc generates: % test: % .LFB2: % subq $8, %rsp % .LCFI0: % movl $0, %eax % call bar % addq $8, %rsp % ret The addq $8,%rsp after the call looks like it is popping 1 arg and is probably misguessed as such -- it is actually to clean up the stack alignment before return. Actually, this guess doesn't apply to amd64 -- the first few args are in registers where there number is almost impossible to guess even for gcc if there are none on stack; it is only when there are some on the stack that the number there can possibly be guessed and the total number = #number in registers + #on stack. With 1 arg: `void bar(int x); void foo(int) { bar(x); }', the generated code is identical for both compilers. So have any chance of guessing the number of args for bar(), bytes in bar()'s caller's callers would have to be checked, recursively. This is too hard for ddb. With tail calls, the checking is unbounded. Tail calls also break the stack trace, but save space so running out of kernel stack is less likely :-). It is arguable a bug to compile kernels with options that make stack tracing impossible. Even passing args in registers makes correct arg printing impossible -- ddb would have to assume that there are always at least 3 (?) args on amd64. The above shows 3 being printed for fork_exit(), which is correct, and 3 for kmem_malloc(), which is correct, and none for fork_trampoline(), which depends on ddb having special knowledge of this and a few other low-level/asm functions. All the others are broken. An very old bug in this area are that functions written in asm don't have normal frames (at least on amd64 and i386) unless profiling is configured. They are mostly leaf functions that shouldn't trap, so this is not very important for interactive use of ddb. But it makes the args of a function like memcpy() harder to find in interactive use, and breaks stack traces if an interrupt or trap occurs in the functions. Compilers may also omit frame pointers for leaf functions, but this is easy to prevent. The efficiency gains from not using frame pointers are small or negative, at least on modern x86 since the frame pointer management can run in parallel and is especially fast in leaf functions where it is not actually used (except for debugging), so frame pointers should never be omitted if there is any chance that the code needs to be debugged. The chance is almost 100% for kernels since they can be debugged if GDB or DDB or stack tracing is configured or if panic dumps are enabled and occur. A not so old bug in this area is that compiling with -O2 or just with with -march tends to break things. Even on old i386 kernels compiled with -O -march=i386, I mostly see 5 args (but no ', ...'). For a just a few functions, the calling sequence is "call foo; addl $4*N,%esp" and ddb correctly guesses that this means N args. Another sequence is "call foo; movl %eax,%esi; addl $8,%esp". ddb doesn't understand this at all, and misguesses that there are 5 args. Bruce From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 23:22:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55DE07F5 for ; Mon, 26 Nov 2012 23:22:05 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D676E8FC0C for ; Mon, 26 Nov 2012 23:22:04 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so8188889eek.13 for ; Mon, 26 Nov 2012 15:22:03 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=L4zfneul40VtkmXG5xhBZe5bq4SfB7DmZJj/KPud8ho=; b=jM8BNavVW9f5O7CTinvemg4XhFVu+UJMw0zwA/IQ0mOEK0t2jlSZGiLXV74U0amGEk A/03s62D7ScBod6XQW9s8oSzH3FM3v3yS3Set3WEi8NTn6uFSS4b24KuWBkFLUoUJet3 qNKZsdZM5O3QGlvrKg9QmbX1A6iD4adCwitPgnKIdbrJeO0JIxTCJtiXUYhsFhU73MiL dw2gmjCovRi3mPMLpNL1uFHpGPvHuhgPwN7gWcN7fJhdWcSYC6JqUeI1wL1aApUVWueH OLrTdQOvUsAMirgXcYn1EK+3uioj9J9CMM6trHiV74R7TXKVEYJ6VN5/zc6X6i8d7FRo 00Ng== MIME-Version: 1.0 Received: by 10.14.209.193 with SMTP id s41mr13461253eeo.9.1353972123719; Mon, 26 Nov 2012 15:22:03 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.14.94.80 with HTTP; Mon, 26 Nov 2012 15:22:03 -0800 (PST) In-Reply-To: <50B354F4.1070706@zoho.com> References: <20121119193202.GA79496@onelab2.iet.unipi.it> <50B354F4.1070706@zoho.com> Date: Mon, 26 Nov 2012 15:22:03 -0800 X-Google-Sender-Auth: SlnlbH02tN6Wpl6kX1fEdocjk8U Message-ID: Subject: Re: syscall cost freebsd vs linux ? From: Luigi Rizzo To: Lukasz Wojcik , will.froning@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Nov 2012 23:22:05 -0000 a quick and easy way is to run the syscall in a tight loop for a sufficient long time (1s or more) and use "time" to measure it. At 100ns per call you need about 10M cycles to do one second. cheers luigi On Mon, Nov 26, 2012 at 3:39 AM, Lukasz Wojcik wrote: > On 11/19/12 20:32, Luigi Rizzo wrote: > >> today i was comparing the performance of some netmap-related code >> on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that >> our system calls are significantly slower. >> On comparable hardware (i7-2600k vs E5-1650) the syscall >> getppid() takes about 95ns on FreeBSD and 38ns on linux. >> >> (i make sure not to use gettimeofday(), which in linux is through vdso, >> and getpid(), which is cached by glibc). >> >> Any idea on why there is this difference and whether/how >> we can reduce it ? >> >> > I'm curious about how did you measure that ? Could you write some more > about your methodology ? > > -LW > > cheers >> luigi >> ______________________________**_________________ >> 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 Tue Nov 27 00:02:46 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5091801 for ; Tue, 27 Nov 2012 00:02:46 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 664D58FC0C for ; Tue, 27 Nov 2012 00:02:46 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id t11so3805281qaa.13 for ; Mon, 26 Nov 2012 16:02:45 -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=RlONd/HKoVEVcGX/15wf1Ig2srAyxlrF1tufA1Xuu58=; b=cjxnq08ufJgEUTRdfpdrHAu5aT+0Jy0Mj8eNNYIgawdozmu+VLofVc01hPUu6k8P97 7B6ZgtIqUpe33pp81Pr5NzgbF88HdZZ8l1BY6KIny1WtNEEwpf3LQvhni82L1DIVL7E+ PLtLKgjYif7ges3xGPlEgZ1yELBhCXHvQf8QDdn2QGoBHdbsamxB+jW3wW6EoHIYLL9G 4lyxkaVdZRuC6Bh8VHhWP5X/ZASDb9rO82EVf4gqpak90IvyPQPfHhjomayOH22ODXof UQAKW7Y4DmeBvybS3E3qxOaFV08sh6pyfjy8L1UsmGlJ3SnDEVfGDh8vBZH6nF0Fsg9f u3Cg== MIME-Version: 1.0 Received: by 10.224.208.132 with SMTP id gc4mr14372184qab.67.1353974565454; Mon, 26 Nov 2012 16:02:45 -0800 (PST) Received: by 10.229.78.96 with HTTP; Mon, 26 Nov 2012 16:02:45 -0800 (PST) In-Reply-To: <50B354F4.1070706@zoho.com> References: <20121119193202.GA79496@onelab2.iet.unipi.it> <50B354F4.1070706@zoho.com> Date: Tue, 27 Nov 2012 03:02:45 +0300 Message-ID: Subject: Re: syscall cost freebsd vs linux ? From: Sergey Kandaurov To: Lukasz Wojcik Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 00:02:46 -0000 On 26 November 2012 15:39, Lukasz Wojcik wrote: > On 11/19/12 20:32, Luigi Rizzo wrote: >> >> today i was comparing the performance of some netmap-related code >> on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that >> our system calls are significantly slower. >> On comparable hardware (i7-2600k vs E5-1650) the syscall >> getppid() takes about 95ns on FreeBSD and 38ns on linux. >> >> (i make sure not to use gettimeofday(), which in linux is through vdso, >> and getpid(), which is cached by glibc). >> >> Any idea on why there is this difference and whether/how >> we can reduce it ? >> > > I'm curious about how did you measure that ? Could you write some more about > your methodology ? There is a nice tool at /usr/src/tools/tools/syscall_timing -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 05:46:06 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2B32CDC; Tue, 27 Nov 2012 05:46:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BC74B8FC0C; Tue, 27 Nov 2012 05:46: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 qAR5jwXP060076; Tue, 27 Nov 2012 00:45:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qAR5jwuq060074; Tue, 27 Nov 2012 05:45:58 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 27 Nov 2012 05:45:58 GMT Message-Id: <201211270545.qAR5jwuq060074@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 05:46:06 -0000 TB --- 2012-11-27 04:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-27 04:40: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 --- 2012-11-27 04:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-11-27 04:40:00 - cleaning the object tree TB --- 2012-11-27 04:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-27 04:40:00 - cd /tinderbox/HEAD/arm/arm TB --- 2012-11-27 04:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-27 04:43:57 - /usr/local/bin/svn update /src TB --- 2012-11-27 04:44:12 - At svn revision 243595 TB --- 2012-11-27 04:44:13 - building world TB --- 2012-11-27 04:44:13 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 04:44:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 04:44:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 04:44:13 - SRCCONF=/dev/null TB --- 2012-11-27 04:44:13 - TARGET=arm TB --- 2012-11-27 04:44:13 - TARGET_ARCH=arm TB --- 2012-11-27 04:44:13 - TZ=UTC TB --- 2012-11-27 04:44:13 - __MAKE_CONF=/dev/null TB --- 2012-11-27 04:44:13 - cd /src TB --- 2012-11-27 04:44:13 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 27 04:44:21 UTC 2012 >>> 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 27 05:42:07 UTC 2012 TB --- 2012-11-27 05:42:07 - generating LINT kernel config TB --- 2012-11-27 05:42:07 - cd /src/sys/arm/conf TB --- 2012-11-27 05:42:07 - /usr/bin/make -B LINT TB --- 2012-11-27 05:42:07 - cd /src/sys/arm/conf TB --- 2012-11-27 05:42:07 - /usr/sbin/config -m LINT TB --- 2012-11-27 05:42:07 - building LINT kernel TB --- 2012-11-27 05:42:07 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 05:42:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 05:42:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 05:42:07 - SRCCONF=/dev/null TB --- 2012-11-27 05:42:07 - TARGET=arm TB --- 2012-11-27 05:42:07 - TARGET_ARCH=arm TB --- 2012-11-27 05:42:07 - TZ=UTC TB --- 2012-11-27 05:42:07 - __MAKE_CONF=/dev/null TB --- 2012-11-27 05:42:07 - cd /src TB --- 2012-11-27 05:42:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 27 05:42:07 UTC 2012 >>> 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/dev/ath/if_ath_tdma.c:161: error: 'ATH_ALQ_TDMA_TIMER_SET' undeclared (first use in this function) /src/sys/dev/ath/if_ath_tdma.c:161: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath_tdma.c:161: error: for each function it appears in.) /src/sys/dev/ath/if_ath_tdma.c:162: error: storage size of 't' isn't known /src/sys/dev/ath/if_ath_tdma.c:171: warning: implicit declaration of function 'if_ath_alq_post' /src/sys/dev/ath/if_ath_tdma.c:171: warning: nested extern declaration of 'if_ath_alq_post' [-Wnested-externs] /src/sys/dev/ath/if_ath_tdma.c:171: error: 'struct ath_softc' has no member named 'sc_alq' /src/sys/dev/ath/if_ath_tdma.c:162: warning: unused variable 't' [-Wunused-variable] *** [if_ath_tdma.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-27 05:45:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-27 05:45:58 - ERROR: failed to build LINT kernel TB --- 2012-11-27 05:45:58 - 2703.08 user 586.17 system 3957.97 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 06:41:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A9C72F0 for ; Tue, 27 Nov 2012 06:41:54 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3028FC15 for ; Tue, 27 Nov 2012 06:41:53 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so8322379eek.13 for ; Mon, 26 Nov 2012 22:41:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=U336UTJBAaVRA0FUGnYoVMWL471DFzrqhzVs8KPjE/I=; b=NKhTDAlDxbAFciIL/qOPPkFIszwi8ITjZgqklbBLBlwqwfdgAxXq1RafM94tm6v6WX d+/eHXPxg+Sg4UgxM3qGkK53KsnCxyi3c09R3kWaOzNfVZCnVoF05ZUHJBDIuTuMyQcw YaaOYJW86ikm9xY305yu/QQBpVGnf9Q1f0Yt/wM0Zv8EgSxA8HyEVlB+eatj3I5usDkL XsVAfm1c7ataa48j3NXVk658TCGgC78ZbqVdLMICP1GPOjMB6S0gdgGN5EjBrkKcxpjL 29VV0idlcH1pn2p8bNv3a2KXLhmtefZNA2MBz1RlBbgJuc3Vt2V+WLCa8bNbInNDzwve NOJQ== Received: by 10.14.172.195 with SMTP id t43mr54839412eel.17.1353998512407; Mon, 26 Nov 2012 22:41:52 -0800 (PST) Received: from zont-osx.local (ppp95-165-156-193.pppoe.spdop.ru. [95.165.156.193]) by mx.google.com with ESMTPS id g47sm38820020eeo.6.2012.11.26.22.41.51 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 22:41:51 -0800 (PST) Sender: Andrey Zonov Message-ID: <50B460AA.10300@FreeBSD.org> Date: Tue, 27 Nov 2012 10:41:46 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: syscall cost freebsd vs linux ? References: <20121119193202.GA79496@onelab2.iet.unipi.it> In-Reply-To: <20121119193202.GA79496@onelab2.iet.unipi.it> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4B6FF0D266D2224B99A3B167" X-Gm-Message-State: ALoCoQmCQqC3rrUmHDZyZiWK6mClK+6ytIJuZN8+OfRtm+6rzS2zTvLa2R97Qa8CyZY5D0l7Me0F Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 06:41:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B6FF0D266D2224B99A3B167 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/19/12 11:32 PM, Luigi Rizzo wrote: > today i was comparing the performance of some netmap-related code > on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that > our system calls are significantly slower. > On comparable hardware (i7-2600k vs E5-1650) the syscall > getppid() takes about 95ns on FreeBSD and 38ns on linux. >=20 > (i make sure not to use gettimeofday(), which in linux is through vdso,= > and getpid(), which is cached by glibc). >=20 > Any idea on why there is this difference and whether/how > we can reduce it ? >=20 This is the cost of blocking mutexes. Linux uses RCU instead [1]. Here are the numbers on current: $ time ./getppid 100000000 real 0m22.926s user 0m2.252s sys 0m20.669s After locking removing (patch below): $ time ./getppid 100000000 real 0m15.224s user 0m2.355s sys 0m12.868s Unfortunately, RCU can be used only in GPL code, but we can use "passive serialization" for simple deref. And even more, it's already implemented in NetBSD. [1] https://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;= f=3Dkernel/timer.c;h=3D367d008584823a6fe01ed013cda8c3693fcfd761;hb=3DHEAD= #l1411 [2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/subr_pserialize.c?rev=3D= 1.5&content-type=3Dtext/x-cvsweb-markup diff --git a/sys/kern/kern_prot.c b/sys/kern/kern_prot.c index 7c46b2d..a13a17c 100644 --- a/sys/kern/kern_prot.c +++ b/sys/kern/kern_prot.c @@ -123,9 +123,7 @@ sys_getppid(struct thread *td, struct getppid_args *u= ap) { struct proc *p =3D td->td_proc; - PROC_LOCK(p); td->td_retval[0] =3D p->p_pptr->p_pid; - PROC_UNLOCK(p); return (0); } --=20 Andrey Zonov --------------enig4B6FF0D266D2224B99A3B167 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.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQtGCuAAoJEBWLemxX/CvTwLAIAI2aQieB000ZXPe49SjnkVGd B6RtaVHDkvOCCEzu2U4x3C0Q0FdUvYwh+5eTOPGU0PQO3lrnKfObv7HAlYw0I38I Euru8zNO/QmbipED3Z8Yb7ejMOv12nLdAG3XlaWVKH14aMy5XEiZcvbQVJ4jJNAk lIKr9QCOt8W2hFrVZKyPS2DMjlY56dCMT7s94umUq/xgiurn7veuKexgAOg2V2Bj lvnpGgKs8lpWWeMEbIqD5wQS8W9lFOkWS8JceGScV/k3G6YwgFhi00yRamVbQQH8 sNGtWSqZ9BcspQjLtiMalV7griWrf9VAB50UxkqYz8cuyUkt8LH2J2Vqw1Upz44= =pYpH -----END PGP SIGNATURE----- --------------enig4B6FF0D266D2224B99A3B167-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 07:30:46 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06A9CD86; Tue, 27 Nov 2012 07:30:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A53CA8FC12; Tue, 27 Nov 2012 07:30:45 +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 qAR7Ui2F052935; Tue, 27 Nov 2012 02:30:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qAR7UirK052923; Tue, 27 Nov 2012 07:30:44 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 27 Nov 2012 07:30:44 GMT Message-Id: <201211270730.qAR7UirK052923@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 07:30:46 -0000 TB --- 2012-11-27 05:45:58 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-27 05:45:58 - 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 --- 2012-11-27 05:45:58 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-11-27 05:45:58 - cleaning the object tree TB --- 2012-11-27 05:45:58 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-27 05:45:58 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2012-11-27 05:45:58 - /usr/local/bin/svn cleanup /src TB --- 2012-11-27 05:46:26 - /usr/local/bin/svn update /src TB --- 2012-11-27 05:46:32 - At svn revision 243595 TB --- 2012-11-27 05:46:33 - building world TB --- 2012-11-27 05:46:33 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 05:46:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 05:46:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 05:46:33 - SRCCONF=/dev/null TB --- 2012-11-27 05:46:33 - TARGET=ia64 TB --- 2012-11-27 05:46:33 - TARGET_ARCH=ia64 TB --- 2012-11-27 05:46:33 - TZ=UTC TB --- 2012-11-27 05:46:33 - __MAKE_CONF=/dev/null TB --- 2012-11-27 05:46:33 - cd /src TB --- 2012-11-27 05:46:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 27 05:46:38 UTC 2012 >>> 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 27 07:23:45 UTC 2012 TB --- 2012-11-27 07:23:45 - generating LINT kernel config TB --- 2012-11-27 07:23:45 - cd /src/sys/ia64/conf TB --- 2012-11-27 07:23:45 - /usr/bin/make -B LINT TB --- 2012-11-27 07:23:45 - cd /src/sys/ia64/conf TB --- 2012-11-27 07:23:45 - /usr/sbin/config -m LINT TB --- 2012-11-27 07:23:45 - building LINT kernel TB --- 2012-11-27 07:23:45 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 07:23:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 07:23:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 07:23:45 - SRCCONF=/dev/null TB --- 2012-11-27 07:23:45 - TARGET=ia64 TB --- 2012-11-27 07:23:45 - TARGET_ARCH=ia64 TB --- 2012-11-27 07:23:45 - TZ=UTC TB --- 2012-11-27 07:23:45 - __MAKE_CONF=/dev/null TB --- 2012-11-27 07:23:45 - cd /src TB --- 2012-11-27 07:23:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 27 07:23:45 UTC 2012 >>> 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/dev/ath/if_ath_tdma.c:161: error: 'ATH_ALQ_TDMA_TIMER_SET' undeclared (first use in this function) /src/sys/dev/ath/if_ath_tdma.c:161: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath_tdma.c:161: error: for each function it appears in.) /src/sys/dev/ath/if_ath_tdma.c:162: error: storage size of 't' isn't known /src/sys/dev/ath/if_ath_tdma.c:171: warning: implicit declaration of function 'if_ath_alq_post' /src/sys/dev/ath/if_ath_tdma.c:171: warning: nested extern declaration of 'if_ath_alq_post' [-Wnested-externs] /src/sys/dev/ath/if_ath_tdma.c:171: error: 'struct ath_softc' has no member named 'sc_alq' /src/sys/dev/ath/if_ath_tdma.c:162: warning: unused variable 't' [-Wunused-variable] *** [if_ath_tdma.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-27 07:30:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-27 07:30:44 - ERROR: failed to build LINT kernel TB --- 2012-11-27 07:30:44 - 4652.43 user 988.03 system 6285.40 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 07:54:35 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF09D419; Tue, 27 Nov 2012 07:54:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8FB438FC0C; Tue, 27 Nov 2012 07:54:35 +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 qAR7sYXq096600; Tue, 27 Nov 2012 02:54: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 qAR7sYRk096582; Tue, 27 Nov 2012 07:54:34 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 27 Nov 2012 07:54:34 GMT Message-Id: <201211270754.qAR7sYRk096582@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 07:54:36 -0000 TB --- 2012-11-27 04:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-27 04:40: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 --- 2012-11-27 04:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-11-27 04:40:00 - cleaning the object tree TB --- 2012-11-27 04:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-27 04:40:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-11-27 04:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-27 04:42:57 - /usr/local/bin/svn update /src TB --- 2012-11-27 04:43:28 - At svn revision 243595 TB --- 2012-11-27 04:43:29 - building world TB --- 2012-11-27 04:43:29 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 04:43:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 04:43:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 04:43:29 - SRCCONF=/dev/null TB --- 2012-11-27 04:43:29 - TARGET=i386 TB --- 2012-11-27 04:43:29 - TARGET_ARCH=i386 TB --- 2012-11-27 04:43:29 - TZ=UTC TB --- 2012-11-27 04:43:29 - __MAKE_CONF=/dev/null TB --- 2012-11-27 04:43:29 - cd /src TB --- 2012-11-27 04:43:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 27 04:43:36 UTC 2012 >>> 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 27 07:44:46 UTC 2012 TB --- 2012-11-27 07:44:46 - generating LINT kernel config TB --- 2012-11-27 07:44:46 - cd /src/sys/i386/conf TB --- 2012-11-27 07:44:46 - /usr/bin/make -B LINT TB --- 2012-11-27 07:44:46 - cd /src/sys/i386/conf TB --- 2012-11-27 07:44:46 - /usr/sbin/config -m LINT TB --- 2012-11-27 07:44:46 - building LINT kernel TB --- 2012-11-27 07:44:46 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 07:44:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 07:44:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 07:44:46 - SRCCONF=/dev/null TB --- 2012-11-27 07:44:46 - TARGET=i386 TB --- 2012-11-27 07:44:46 - TARGET_ARCH=i386 TB --- 2012-11-27 07:44:46 - TZ=UTC TB --- 2012-11-27 07:44:46 - __MAKE_CONF=/dev/null TB --- 2012-11-27 07:44:46 - cd /src TB --- 2012-11-27 07:44:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 27 07:44:46 UTC 2012 >>> 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/dev/ath/if_ath_tdma.c:171:3: error: implicit declaration of function 'if_ath_alq_post' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if_ath_alq_post(&sc->sc_alq, ATH_ALQ_TDMA_TIMER_SET, ^ /src/sys/dev/ath/if_ath_tdma.c:171:24: error: no member named 'sc_alq' in 'struct ath_softc' if_ath_alq_post(&sc->sc_alq, ATH_ALQ_TDMA_TIMER_SET, ~~ ^ 5 errors generated. *** [if_ath_tdma.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-27 07:54:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-27 07:54:34 - ERROR: failed to build LINT kernel TB --- 2012-11-27 07:54:34 - 8334.95 user 1482.90 system 11674.29 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 07:56:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAD26825; Tue, 27 Nov 2012 07:56:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B898B8FC12; Tue, 27 Nov 2012 07:56:41 +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 qAR7ufcO006400; Tue, 27 Nov 2012 02:56: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 qAR7ufMq006390; Tue, 27 Nov 2012 07:56:41 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 27 Nov 2012 07:56:41 GMT Message-Id: <201211270756.qAR7ufMq006390@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 07:56:42 -0000 TB --- 2012-11-27 04:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-27 04:40: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 --- 2012-11-27 04:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-11-27 04:40:00 - cleaning the object tree TB --- 2012-11-27 04:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-27 04:40:00 - cd /tinderbox/HEAD/i386/pc98 TB --- 2012-11-27 04:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-27 04:43:57 - /usr/local/bin/svn update /src TB --- 2012-11-27 04:44:12 - At svn revision 243595 TB --- 2012-11-27 04:44:13 - building world TB --- 2012-11-27 04:44:13 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 04:44:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 04:44:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 04:44:13 - SRCCONF=/dev/null TB --- 2012-11-27 04:44:13 - TARGET=pc98 TB --- 2012-11-27 04:44:13 - TARGET_ARCH=i386 TB --- 2012-11-27 04:44:13 - TZ=UTC TB --- 2012-11-27 04:44:13 - __MAKE_CONF=/dev/null TB --- 2012-11-27 04:44:13 - cd /src TB --- 2012-11-27 04:44:13 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 27 04:44:21 UTC 2012 >>> 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 27 07:49:06 UTC 2012 TB --- 2012-11-27 07:49:06 - generating LINT kernel config TB --- 2012-11-27 07:49:06 - cd /src/sys/pc98/conf TB --- 2012-11-27 07:49:06 - /usr/bin/make -B LINT TB --- 2012-11-27 07:49:06 - cd /src/sys/pc98/conf TB --- 2012-11-27 07:49:06 - /usr/sbin/config -m LINT TB --- 2012-11-27 07:49:06 - building LINT kernel TB --- 2012-11-27 07:49:06 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 07:49:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 07:49:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 07:49:06 - SRCCONF=/dev/null TB --- 2012-11-27 07:49:06 - TARGET=pc98 TB --- 2012-11-27 07:49:06 - TARGET_ARCH=i386 TB --- 2012-11-27 07:49:06 - TZ=UTC TB --- 2012-11-27 07:49:06 - __MAKE_CONF=/dev/null TB --- 2012-11-27 07:49:06 - cd /src TB --- 2012-11-27 07:49:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 27 07:49:07 UTC 2012 >>> 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/dev/ath/if_ath_tdma.c:171:3: error: implicit declaration of function 'if_ath_alq_post' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if_ath_alq_post(&sc->sc_alq, ATH_ALQ_TDMA_TIMER_SET, ^ /src/sys/dev/ath/if_ath_tdma.c:171:24: error: no member named 'sc_alq' in 'struct ath_softc' if_ath_alq_post(&sc->sc_alq, ATH_ALQ_TDMA_TIMER_SET, ~~ ^ 5 errors generated. *** [if_ath_tdma.o] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-27 07:56:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-27 07:56:41 - ERROR: failed to build LINT kernel TB --- 2012-11-27 07:56:41 - 8542.04 user 1483.94 system 11800.47 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 08:20:42 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F5DEBC8; Tue, 27 Nov 2012 08:20:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id B7D3A8FC12; Tue, 27 Nov 2012 08:20:41 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so3602117wib.1 for ; Tue, 27 Nov 2012 00:20:39 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fcjiPvyLNfrQ0tD7SsCtRhtY2CPvAfw9bQJEQuDrP4E=; b=G7D01CQ96K4gUweGLS/Pah+MZgSDBVmmJXQ8ldQCbY6MNg9TGrHKhIlj2Z/n1ACL3g 1LTPZ4jPrdpdfy0xrHEOq9Z2yIeJmX+RMV7mqlPGBX8uvq/FmQrVOHCCtdZ4c0oyRF8R 88qTBlfXHzK0nCqqC0lpCxuwCNSh9jODyslzrosMdu25ofBNClnmqAuRqkPjKj41vR09 R3AjVQIOyjsK0a8aWiA9sVvpnNYY/QbtQRyyDCEdj4jvPyTkBVjLoS7MZvjfkJgBlKN5 0v2G4r1WoQfqnkpK8LwmeqWLYPrF9No1QiofupVSLImz0Lbalt9KHmYqxzkO7p0eOPQb Ir4A== MIME-Version: 1.0 Received: by 10.180.24.4 with SMTP id q4mr25269828wif.19.1354004439578; Tue, 27 Nov 2012 00:20:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 27 Nov 2012 00:20:39 -0800 (PST) In-Reply-To: <201211270730.qAR7UirK052923@freebsd-current.sentex.ca> References: <201211270730.qAR7UirK052923@freebsd-current.sentex.ca> Date: Tue, 27 Nov 2012 00:20:39 -0800 X-Google-Sender-Auth: aI67RSki5yUNtUAF1rJCRviX7KI Message-ID: Subject: Re: [head tinderbox] failure on ia64/ia64 From: Adrian Chadd To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 08:20:42 -0000 ... fixed, btw. adrian On 26 November 2012 23:30, FreeBSD Tinderbox wrote: > TB --- 2012-11-27 05:45:58 - tinderbox 2.9 running on freebsd-current.sentex.ca > TB --- 2012-11-27 05:45:58 - 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 --- 2012-11-27 05:45:58 - starting HEAD tinderbox run for ia64/ia64 > TB --- 2012-11-27 05:45:58 - cleaning the object tree > TB --- 2012-11-27 05:45:58 - checking out /src from svn://svn.freebsd.org/base/head > TB --- 2012-11-27 05:45:58 - cd /tinderbox/HEAD/ia64/ia64 > TB --- 2012-11-27 05:45:58 - /usr/local/bin/svn cleanup /src > TB --- 2012-11-27 05:46:26 - /usr/local/bin/svn update /src > TB --- 2012-11-27 05:46:32 - At svn revision 243595 > TB --- 2012-11-27 05:46:33 - building world > TB --- 2012-11-27 05:46:33 - CROSS_BUILD_TESTING=YES > TB --- 2012-11-27 05:46:33 - MAKEOBJDIRPREFIX=/obj > TB --- 2012-11-27 05:46:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-11-27 05:46:33 - SRCCONF=/dev/null > TB --- 2012-11-27 05:46:33 - TARGET=ia64 > TB --- 2012-11-27 05:46:33 - TARGET_ARCH=ia64 > TB --- 2012-11-27 05:46:33 - TZ=UTC > TB --- 2012-11-27 05:46:33 - __MAKE_CONF=/dev/null > TB --- 2012-11-27 05:46:33 - cd /src > TB --- 2012-11-27 05:46:33 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Tue Nov 27 05:46:38 UTC 2012 >>>> 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 27 07:23:45 UTC 2012 > TB --- 2012-11-27 07:23:45 - generating LINT kernel config > TB --- 2012-11-27 07:23:45 - cd /src/sys/ia64/conf > TB --- 2012-11-27 07:23:45 - /usr/bin/make -B LINT > TB --- 2012-11-27 07:23:45 - cd /src/sys/ia64/conf > TB --- 2012-11-27 07:23:45 - /usr/sbin/config -m LINT > TB --- 2012-11-27 07:23:45 - building LINT kernel > TB --- 2012-11-27 07:23:45 - CROSS_BUILD_TESTING=YES > TB --- 2012-11-27 07:23:45 - MAKEOBJDIRPREFIX=/obj > TB --- 2012-11-27 07:23:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-11-27 07:23:45 - SRCCONF=/dev/null > TB --- 2012-11-27 07:23:45 - TARGET=ia64 > TB --- 2012-11-27 07:23:45 - TARGET_ARCH=ia64 > TB --- 2012-11-27 07:23:45 - TZ=UTC > TB --- 2012-11-27 07:23:45 - __MAKE_CONF=/dev/null > TB --- 2012-11-27 07:23:45 - cd /src > TB --- 2012-11-27 07:23:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>>> Kernel build for LINT started on Tue Nov 27 07:23:45 UTC 2012 >>>> 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/dev/ath/if_ath_tdma.c:161: error: 'ATH_ALQ_TDMA_TIMER_SET' undeclared (first use in this function) > /src/sys/dev/ath/if_ath_tdma.c:161: error: (Each undeclared identifier is reported only once > /src/sys/dev/ath/if_ath_tdma.c:161: error: for each function it appears in.) > /src/sys/dev/ath/if_ath_tdma.c:162: error: storage size of 't' isn't known > /src/sys/dev/ath/if_ath_tdma.c:171: warning: implicit declaration of function 'if_ath_alq_post' > /src/sys/dev/ath/if_ath_tdma.c:171: warning: nested extern declaration of 'if_ath_alq_post' [-Wnested-externs] > /src/sys/dev/ath/if_ath_tdma.c:171: error: 'struct ath_softc' has no member named 'sc_alq' > /src/sys/dev/ath/if_ath_tdma.c:162: warning: unused variable 't' [-Wunused-variable] > *** [if_ath_tdma.o] Error code 1 > > Stop in /obj/ia64.ia64/src/sys/LINT. > *** [buildkernel] Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2012-11-27 07:30:44 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2012-11-27 07:30:44 - ERROR: failed to build LINT kernel > TB --- 2012-11-27 07:30:44 - 4652.43 user 988.03 system 6285.40 real > > > http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full > _______________________________________________ > 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 Tue Nov 27 08:39:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 189BDA81; Tue, 27 Nov 2012 08:39:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DA2CE8FC13; Tue, 27 Nov 2012 08:39:16 +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 qAR8dFdF057783; Tue, 27 Nov 2012 03:39: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 qAR8dFue057774; Tue, 27 Nov 2012 08:39:15 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 27 Nov 2012 08:39:15 GMT Message-Id: <201211270839.qAR8dFue057774@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 08:39:17 -0000 TB --- 2012-11-27 04:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-27 04:40: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 --- 2012-11-27 04:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-11-27 04:40:00 - cleaning the object tree TB --- 2012-11-27 04:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-27 04:40:00 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-11-27 04:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-27 04:43:27 - /usr/local/bin/svn update /src TB --- 2012-11-27 04:43:43 - At svn revision 243595 TB --- 2012-11-27 04:43:44 - building world TB --- 2012-11-27 04:43:44 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 04:43:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 04:43:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 04:43:44 - SRCCONF=/dev/null TB --- 2012-11-27 04:43:44 - TARGET=amd64 TB --- 2012-11-27 04:43:44 - TARGET_ARCH=amd64 TB --- 2012-11-27 04:43:44 - TZ=UTC TB --- 2012-11-27 04:43:44 - __MAKE_CONF=/dev/null TB --- 2012-11-27 04:43:44 - cd /src TB --- 2012-11-27 04:43:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 27 04:43:53 UTC 2012 >>> 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 27 08:30:03 UTC 2012 TB --- 2012-11-27 08:30:03 - generating LINT kernel config TB --- 2012-11-27 08:30:03 - cd /src/sys/amd64/conf TB --- 2012-11-27 08:30:03 - /usr/bin/make -B LINT TB --- 2012-11-27 08:30:03 - cd /src/sys/amd64/conf TB --- 2012-11-27 08:30:03 - /usr/sbin/config -m LINT TB --- 2012-11-27 08:30:03 - building LINT kernel TB --- 2012-11-27 08:30:03 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 08:30:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 08:30:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 08:30:03 - SRCCONF=/dev/null TB --- 2012-11-27 08:30:03 - TARGET=amd64 TB --- 2012-11-27 08:30:03 - TARGET_ARCH=amd64 TB --- 2012-11-27 08:30:03 - TZ=UTC TB --- 2012-11-27 08:30:03 - __MAKE_CONF=/dev/null TB --- 2012-11-27 08:30:03 - cd /src TB --- 2012-11-27 08:30:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 27 08:30:04 UTC 2012 >>> 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/dev/ath/if_ath_tdma.c:171:3: error: implicit declaration of function 'if_ath_alq_post' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if_ath_alq_post(&sc->sc_alq, ATH_ALQ_TDMA_TIMER_SET, ^ /src/sys/dev/ath/if_ath_tdma.c:171:24: error: no member named 'sc_alq' in 'struct ath_softc' if_ath_alq_post(&sc->sc_alq, ATH_ALQ_TDMA_TIMER_SET, ~~ ^ 5 errors generated. *** [if_ath_tdma.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-27 08:39:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-27 08:39:15 - ERROR: failed to build LINT kernel TB --- 2012-11-27 08:39:15 - 9588.59 user 1848.32 system 14354.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 08:56:04 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64030397; Tue, 27 Nov 2012 08:56:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6A78FC15; Tue, 27 Nov 2012 08:56: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 qAR8u3gR045486; Tue, 27 Nov 2012 03:56:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qAR8u3W7045485; Tue, 27 Nov 2012 08:56:03 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 27 Nov 2012 08:56:03 GMT Message-Id: <201211270856.qAR8u3W7045485@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 08:56:04 -0000 TB --- 2012-11-27 07:30:44 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-27 07:30: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 --- 2012-11-27 07:30:44 - starting HEAD tinderbox run for mips/mips TB --- 2012-11-27 07:30:44 - cleaning the object tree TB --- 2012-11-27 07:30:44 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-27 07:30:44 - cd /tinderbox/HEAD/mips/mips TB --- 2012-11-27 07:30:44 - /usr/local/bin/svn cleanup /src TB --- 2012-11-27 07:31:50 - /usr/local/bin/svn update /src TB --- 2012-11-27 07:31:57 - At svn revision 243604 TB --- 2012-11-27 07:31:58 - building world TB --- 2012-11-27 07:31:58 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 07:31:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 07:31:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 07:31:58 - SRCCONF=/dev/null TB --- 2012-11-27 07:31:58 - TARGET=mips TB --- 2012-11-27 07:31:58 - TARGET_ARCH=mips TB --- 2012-11-27 07:31:58 - TZ=UTC TB --- 2012-11-27 07:31:58 - __MAKE_CONF=/dev/null TB --- 2012-11-27 07:31:58 - cd /src TB --- 2012-11-27 07:31:58 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 27 07:32:05 UTC 2012 >>> 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 27 08:52:43 UTC 2012 TB --- 2012-11-27 08:52:43 - cd /src/sys/mips/conf TB --- 2012-11-27 08:52:43 - /usr/sbin/config -m ADM5120 TB --- 2012-11-27 08:52:43 - skipping ADM5120 kernel TB --- 2012-11-27 08:52:43 - cd /src/sys/mips/conf TB --- 2012-11-27 08:52:43 - /usr/sbin/config -m ALCHEMY TB --- 2012-11-27 08:52:43 - skipping ALCHEMY kernel TB --- 2012-11-27 08:52:43 - cd /src/sys/mips/conf TB --- 2012-11-27 08:52:43 - /usr/sbin/config -m AP91 TB --- 2012-11-27 08:52:43 - building AP91 kernel TB --- 2012-11-27 08:52:43 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 08:52:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 08:52:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 08:52:43 - SRCCONF=/dev/null TB --- 2012-11-27 08:52:43 - TARGET=mips TB --- 2012-11-27 08:52:43 - TARGET_ARCH=mips TB --- 2012-11-27 08:52:43 - TZ=UTC TB --- 2012-11-27 08:52:43 - __MAKE_CONF=/dev/null TB --- 2012-11-27 08:52:43 - cd /src TB --- 2012-11-27 08:52:43 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Tue Nov 27 08:52:43 UTC 2012 >>> 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 [...] cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx_ht.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_led.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_rx.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c: In function 'ath_tdma_update': /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c:532: error: 'tsf_1' undeclared (first use in this function) /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c:532: error: (Each undeclared identifier is reported only once /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c:532: error: for each function it appears in.) *** [if_ath_tdma.o] Error code 1 Stop in /src/sys/modules/ath. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/mips.mips/src/sys/AP91. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-27 08:56:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-27 08:56:03 - ERROR: failed to build AP91 kernel TB --- 2012-11-27 08:56:03 - 2793.81 user 783.27 system 5118.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 09:08:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5456D744; Tue, 27 Nov 2012 09:08:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AF6008FC19; Tue, 27 Nov 2012 09:08:35 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id 12so608298wgh.31 for ; Tue, 27 Nov 2012 01:08:34 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3MNmoKRSeN9lEJntiRuFziNo5zzbTgf7OdTqXyErKqA=; b=ZWAZ1NqGL5cTAv4ynIR5NFB0/VrFGgH2rF0zX6sLNVADW/XcrkmzDr6q0u9B3UJ2Gm fq+bROY5phxq7TtLohKRZeK7fdtHzurg3c5XjzltFPjvGUAcl6tt21ZSgxvw3ZQvcinl T0SYluGPYpyPEbabV1Lxa40lUyKXTlIH+C41Su1siD3uquLxrtJKzTnoncMj+cV9nvwT oBKbWGS2Kcjl8qCesYRuafy+GjrJ22baGoljIo38QYvRljYQsA9JconCI9gUP7qSXx0T Mujlt0OkWXEQL1JkV7VVbS0rjmVGy8nxsx6IsJwUrTI1IeRGArIhnIAfmgPnvF6AlcyJ nDXw== MIME-Version: 1.0 Received: by 10.180.102.102 with SMTP id fn6mr1529364wib.13.1354007314423; Tue, 27 Nov 2012 01:08:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 27 Nov 2012 01:08:34 -0800 (PST) In-Reply-To: <201211270856.qAR8u3W7045485@freebsd-current.sentex.ca> References: <201211270856.qAR8u3W7045485@freebsd-current.sentex.ca> Date: Tue, 27 Nov 2012 01:08:34 -0800 X-Google-Sender-Auth: waTaj_IpbUqokdA0uAfwW1qhhlc Message-ID: Subject: Re: [head tinderbox] failure on mips/mips From: Adrian Chadd To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 09:08:36 -0000 This has been fixed too. I actually fat fingered this commit - I committed from the WIP directory, rather than the full -HEAD checkout I had been working from and had actually done compile tests against. Sorry :( Adrian On 27 November 2012 00:56, FreeBSD Tinderbox wrote: > TB --- 2012-11-27 07:30:44 - tinderbox 2.9 running on freebsd-current.sen= tex.ca > TB --- 2012-11-27 07:30:44 - FreeBSD freebsd-current.sentex.ca 8.3-PREREL= EASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebs= d-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2012-11-27 07:30:44 - starting HEAD tinderbox run for mips/mips > TB --- 2012-11-27 07:30:44 - cleaning the object tree > TB --- 2012-11-27 07:30:44 - checking out /src from svn://svn.freebsd.org= /base/head > TB --- 2012-11-27 07:30:44 - cd /tinderbox/HEAD/mips/mips > TB --- 2012-11-27 07:30:44 - /usr/local/bin/svn cleanup /src > TB --- 2012-11-27 07:31:50 - /usr/local/bin/svn update /src > TB --- 2012-11-27 07:31:57 - At svn revision 243604 > TB --- 2012-11-27 07:31:58 - building world > TB --- 2012-11-27 07:31:58 - CROSS_BUILD_TESTING=3DYES > TB --- 2012-11-27 07:31:58 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2012-11-27 07:31:58 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-11-27 07:31:58 - SRCCONF=3D/dev/null > TB --- 2012-11-27 07:31:58 - TARGET=3Dmips > TB --- 2012-11-27 07:31:58 - TARGET_ARCH=3Dmips > TB --- 2012-11-27 07:31:58 - TZ=3DUTC > TB --- 2012-11-27 07:31:58 - __MAKE_CONF=3D/dev/null > TB --- 2012-11-27 07:31:58 - cd /src > TB --- 2012-11-27 07:31:58 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Tue Nov 27 07:32:05 UTC 2012 >>>> 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 27 08:52:43 UTC 2012 > TB --- 2012-11-27 08:52:43 - cd /src/sys/mips/conf > TB --- 2012-11-27 08:52:43 - /usr/sbin/config -m ADM5120 > TB --- 2012-11-27 08:52:43 - skipping ADM5120 kernel > TB --- 2012-11-27 08:52:43 - cd /src/sys/mips/conf > TB --- 2012-11-27 08:52:43 - /usr/sbin/config -m ALCHEMY > TB --- 2012-11-27 08:52:43 - skipping ALCHEMY kernel > TB --- 2012-11-27 08:52:43 - cd /src/sys/mips/conf > TB --- 2012-11-27 08:52:43 - /usr/sbin/config -m AP91 > TB --- 2012-11-27 08:52:43 - building AP91 kernel > TB --- 2012-11-27 08:52:43 - CROSS_BUILD_TESTING=3DYES > TB --- 2012-11-27 08:52:43 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2012-11-27 08:52:43 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-11-27 08:52:43 - SRCCONF=3D/dev/null > TB --- 2012-11-27 08:52:43 - TARGET=3Dmips > TB --- 2012-11-27 08:52:43 - TARGET_ARCH=3Dmips > TB --- 2012-11-27 08:52:43 - TZ=3DUTC > TB --- 2012-11-27 08:52:43 - __MAKE_CONF=3D/dev/null > TB --- 2012-11-27 08:52:43 - cd /src > TB --- 2012-11-27 08:52:43 - /usr/bin/make -B buildkernel KERNCONF=3DAP91 >>>> Kernel build for AP91 started on Tue Nov 27 08:52:43 UTC 2012 >>>> 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 > [...] > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/= modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHA= VE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h = -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mn= o-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffrees= tanding -std=3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstri= ct-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -= Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiag= nostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx_ht.c > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/= modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHA= VE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h = -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mn= o-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffrees= tanding -std=3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstri= ct-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -= Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiag= nostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_led.c > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/= modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHA= VE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h = -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mn= o-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffrees= tanding -std=3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstri= ct-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -= Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiag= nostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_rx.c > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/= modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHA= VE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h = -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mn= o-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffrees= tanding -std=3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstri= ct-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -= Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiag= nostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c > /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c: In function 'ath_tdma_u= pdate': > /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c:532: error: 'tsf_1' unde= clared (first use in this function) > /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c:532: error: (Each undecl= ared identifier is reported only once > /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c:532: error: for each fun= ction it appears in.) > *** [if_ath_tdma.o] Error code 1 > > Stop in /src/sys/modules/ath. > *** [all] Error code 1 > > Stop in /src/sys/modules. > *** [modules-all] Error code 1 > > Stop in /obj/mips.mips/src/sys/AP91. > *** [buildkernel] Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2012-11-27 08:56:03 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2012-11-27 08:56:03 - ERROR: failed to build AP91 kernel > TB --- 2012-11-27 08:56:03 - 2793.81 user 783.27 system 5118.66 real > > > http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full > _______________________________________________ > 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 Tue Nov 27 09:50:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7476F27 for ; Tue, 27 Nov 2012 09:50:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 47CA88FC13 for ; Tue, 27 Nov 2012 09:50:54 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id 12so633262wgh.31 for ; Tue, 27 Nov 2012 01:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=EiQoR/XRpIDFXlIumuLxDGmaVKkgUvGru34lfz4hyUY=; b=dE+lqKgUO11cXmJGX2hD4MemDC2b6swis9Q2XUAwobjG02txc1wzHp8QInwRdSWyic 0I6VqMEfFRFzcPt3TtfbvZge+Tw1Xvh0uOggxXJK3jOG5tghJFIj1E3dnBLoPoEvQxF1 2NIrD5A1NxDivdhVYkYYYMzvKCG9/42j13HfTv2jUPGJhtFS46ct09dXM91f/iuKt0wd C2JeRifJ8BtBgxyjgeg5ZBf+2oCFU9In3KmmkGPdiH2ktHG9LlaT9uy+g6k4f56oe1eD gN358bo89ylHUUwbBV4BHPvXT9cJeTfxeqhA1dWni7IghbxTfVK5I6hclauajN52pZKc Jxow== MIME-Version: 1.0 Received: by 10.216.74.85 with SMTP id w63mr5830673wed.212.1354009854276; Tue, 27 Nov 2012 01:50:54 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 27 Nov 2012 01:50:54 -0800 (PST) Date: Tue, 27 Nov 2012 01:50:54 -0800 X-Google-Sender-Auth: l6JElBYFuR5As-hfz_fmIYR-20Y Message-ID: Subject: Is cross-world building broken? From: Adrian Chadd To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 09:50:56 -0000 Hiya, I'm having trouble doing a cross-build with -HEAD. It's possible this has been like this for a while. It's dying really, really early on when doing a build of the make utility. It looks like it's trying to link the make utility against a library inside the DESTDIR root, rather than the system libc path. Before people say "but but tinderbox works!" I've taken a quick peek at the tinderbox output and it doesn't look like it sets DESTDIR. I definitely set DESTDIR here; I have a bunch of different installroots based on what platform I'm building for. LIBC is defined as: Global:LIBC = ${DESTDIR}${LIBDIR}/libc.a .. and that's likely being evaluated deep in the bowels of make somewhere. The build script in question: env CROSS_BUILD_TESTING=YES \ MAKEOBJDIRPREFIX=${X_MAKEOBJDIRPREFIX} \ make ${BUILD_FLAGS} \ TARGET=${TARGET} \ TARGET_ARCH=${TARGET_ARCH} \ ${X_TARGET_CPUTYPE} \ KERNCONF=${KERNCONF} DESTDIR=${X_DESTDIR} \ KODIR=/boot/kernel.${KERNCONF}/ \ KMODDIR=/boot/kernel.${KERNCONF}/ \ __MAKE_CONF=${X_DESTDIR}/../make.conf.${BUILDNAME} \ SRCCONF=${X_DESTDIR}/../src.conf.${BUILDNAME} \ LOCAL_DIRS="${LOCAL_DIRS}" \ ${X_LOCAL_TOOL_DIRS} \ $1 \ The snippet from make -dA: # # parents: all make : arch.o buf.o cond.o dir.o for.o hash.o hash_tables.o job.o lst.o main.o make.o parse.o proc.o shell.o str.o suff.o targ.o util.o var.o /home/adrian/work/freebsd/svn/src/../root/armeb/usr/lib/libc.a ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD} @[ -z "${CTFMERGE}" -o -n "${NO_CTF}" ] || (${ECHO} ${CTFMERGE} ${CTFFLAGS} -o ${.TARGET} ${OBJS} && ${CTFMERGE} ${CTFFLAGS} -o ${.TARGET} ${OBJS}) The output: lucy# ../../build/trunk/build/bin/build cambria buildworld buildkernel installworld installkernel *** Configuration file : cambria *** Platform : armeb *** Target : buildworld MAKEOBJDIRPREFIX: /home/adrian/work/freebsd/svn/src/../obj/armeb/ -------------------------------------------------------------- >>> Building an up-to-date make(1) -------------------------------------------------------------- cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/main.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/shell.c make: don't know how to make /home/adrian/work/freebsd/svn/src/../root/armeb/usr/lib/libc.a. Stop *** Error code 2 Stop in /usr/home/adrian/work/freebsd/svn/src. *** Error code 1 Stop in /usr/home/adrian/work/freebsd/svn/src. lucy# rm -rf ../root lucy# rm -rf ../obj lucy# ../../build/trunk/build/bin/build cambria buildworld *** Configuration file : cambria *** Platform : armeb *** Target : buildworld MAKEOBJDIRPREFIX: /home/adrian/work/freebsd/svn/src/../obj/armeb/ -------------------------------------------------------------- >>> Building an up-to-date make(1) -------------------------------------------------------------- /home/adrian/work/freebsd/svn/src/../obj/armeb//usr/home/adrian/work/freebsd/svn/src/make.i386/usr/home/adrian/work/freebsd/svn/src/usr.bin/make created for /usr/home/adrian/work/freebsd/svn/src/usr.bin/make rm -f .depend mkdep -f .depend -a -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/arch.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/buf.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/cond.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/dir.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/for.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/hash.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/hash_tables.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/job.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/lst.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/main.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/make.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/parse.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/proc.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/shell.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/str.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/suff.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/targ.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/util.c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/var.c echo make: /home/adrian/work/freebsd/svn/src/../root/armeb/usr/lib/libc.a >> .depend cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/arch.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/buf.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/cond.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/dir.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/for.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/hash.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/hash_tables.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/job.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/lst.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/main.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/make.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/parse.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/proc.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/shell.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/str.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/suff.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/targ.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/util.c cc -O2 -pipe -I/usr/home/adrian/work/freebsd/svn/src/usr.bin/make -DMAKE_VERSION=\"10201205300\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/home/adrian/work/freebsd/svn/src/usr.bin/make/var.c make: don't know how to make /home/adrian/work/freebsd/svn/src/../root/armeb/usr/lib/libc.a. Stop *** Error code 2 Stop in /usr/home/adrian/work/freebsd/svn/src. *** Error code 1 Stop in /usr/home/adrian/work/freebsd/svn/src. lucy# From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 11:07:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00080996; Tue, 27 Nov 2012 11:07:56 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 915BD8FC08; Tue, 27 Nov 2012 11:07:56 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so11076179qcs.13 for ; Tue, 27 Nov 2012 03:07:50 -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=ayJ7WV9dv3yx8T8euUnnu5gF13uF6oosYusF7R/vj9k=; b=H19CAvEqxnPr3oXOfCFaYeAxbYTr3VcKh7zr4fuWjJqNwKF5Oih8CzZDLRpHpLckwg RWtc3cXv42UvfBb61ryQtEsWZb2vtAooiVbbz8enCSfCJkPtXgcs1IEleO+2OJG/xwui JVJMvG9Qd2uuDi2g5OS9yxY0bvE9iaEmL01iRvZPskGEk4G2tArV0UejMSsLgryDcgGN GtFxoC+MYXztJI1Z9MNheSVoTLCjuKvMfKMMaoj4Iz4dIT66/FYyes9eOUqCwx7kDQ0D mITfC+oJSwvZIZXjjioaYSLHO+LnxDRPdCmuHEDieWV0qwZK0q8DMD54sY1Fqa0z4rYr K8dg== MIME-Version: 1.0 Received: by 10.49.82.98 with SMTP id h2mr17418638qey.14.1354014470177; Tue, 27 Nov 2012 03:07:50 -0800 (PST) Received: by 10.49.121.163 with HTTP; Tue, 27 Nov 2012 03:07:50 -0800 (PST) Date: Tue, 27 Nov 2012 12:07:50 +0100 Message-ID: Subject: Re-sizable UFS project From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 11:07:57 -0000 Hello, some time ago the FreeBSD Foundation published/approved a project for live resizing of UFS filesystems. Does any know if the project was successful and any outcome from it? -- Ermal From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 11:13:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4835BE72 for ; Tue, 27 Nov 2012 11:13:33 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id 5D1AD8FC12 for ; Tue, 27 Nov 2012 11:13:28 +0000 (UTC) Received: (qmail 22793 invoked from network); 27 Nov 2012 11:13:04 -0000 Received: from unknown (HELO alex.andxor.it) (192.168.2.30) by andxor.it with SMTP; 27 Nov 2012 11:13:04 -0000 Message-ID: <50B4A040.6060001@FreeBSD.org> Date: Tue, 27 Nov 2012 12:13:04 +0100 From: Alex Dupre User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Subject: Re: Re-sizable UFS project References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 11:13:33 -0000 Ermal Luçi ha scritto: > some time ago the FreeBSD Foundation published/approved a project for live > resizing of UFS filesystems. > Does any know if the project was successful and any outcome from it? http://lists.freebsd.org/pipermail/svn-src-head/2012-November/042539.html -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 11:25:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E767C19C for ; Tue, 27 Nov 2012 11:25:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 574868FC13 for ; Tue, 27 Nov 2012 11:25:15 +0000 (UTC) Received: (qmail 33676 invoked from network); 27 Nov 2012 12:56:54 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Nov 2012 12:56:54 -0000 Message-ID: <50B4A374.5040705@freebsd.org> Date: Tue, 27 Nov 2012 12:26:44 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious 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.14 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, 27 Nov 2012 11:25:16 -0000 FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Fri Nov 23 17:00:40 CET 2012 aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 #0 doadump (textdump=-2014022336) at pcpu.h:229 #1 0xffffffff8033e2d2 in db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/head/sys/ddb/db_command.c:578 #2 0xffffffff8033e074 in db_command (last_cmdp=, cmd_table=, dopager=1) at /usr/src/head/sys/ddb/db_command.c:449 #3 0xffffffff8033dd62 in db_command_loop () at /usr/src/head/sys/ddb/db_command.c:502 #4 0xffffffff80340690 in db_trap (type=, code=0) at /usr/src/head/sys/ddb/db_main.c:231 #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=) at /usr/src/head/sys/kern/subr_kdb.c:654 #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) at /usr/src/head/sys/amd64/amd64/trap.c:579 #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", msg=) at cpufunc.h:63 #9 0xffffffff8088086f in panic (fmt=) at /usr/src/head/sys/kern/kern_shutdown.c:628 #10 0xffffffff80adea4a in vm_object_madvise (object=, pindex=, end=8952, advise=) at /usr/src/head/sys/vm/vm_object.c:1101 #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, start=, end=, behav=5) at /usr/src/head/sys/vm/vm_map.c:2140 #12 0xffffffff80adbd8d in sys_madvise (td=, uap=) at /usr/src/head/sys/vm/vm_mmap.c:752 #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, traced=0) at subr_syscall.c:135 #14 0xffffffff80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329 #15 0x00000000016f3bfa in ?? () From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 13:41:02 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90F26862; Tue, 27 Nov 2012 13:41:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 553B28FC12; Tue, 27 Nov 2012 13:41:02 +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 qARDf1er093351; Tue, 27 Nov 2012 08:41: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 qARDf1fI093340; Tue, 27 Nov 2012 13:41:01 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 27 Nov 2012 13:41:01 GMT Message-Id: <201211271341.qARDf1fI093340@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 13:41:02 -0000 TB --- 2012-11-27 12:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-27 12: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 --- 2012-11-27 12:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-11-27 12:20:01 - cleaning the object tree TB --- 2012-11-27 12:25:38 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-27 12:25:38 - cd /tinderbox/HEAD/arm/arm TB --- 2012-11-27 12:25:38 - /usr/local/bin/svn cleanup /src TB --- 2012-11-27 12:27:28 - /usr/local/bin/svn update /src TB --- 2012-11-27 12:27:39 - At svn revision 243615 TB --- 2012-11-27 12:27:40 - building world TB --- 2012-11-27 12:27:40 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 12:27:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 12:27:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 12:27:40 - SRCCONF=/dev/null TB --- 2012-11-27 12:27:40 - TARGET=arm TB --- 2012-11-27 12:27:40 - TARGET_ARCH=arm TB --- 2012-11-27 12:27:40 - TZ=UTC TB --- 2012-11-27 12:27:40 - __MAKE_CONF=/dev/null TB --- 2012-11-27 12:27:40 - cd /src TB --- 2012-11-27 12:27:40 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 27 12:27:46 UTC 2012 >>> 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 27 13:27:38 UTC 2012 TB --- 2012-11-27 13:27:38 - generating LINT kernel config TB --- 2012-11-27 13:27:38 - cd /src/sys/arm/conf TB --- 2012-11-27 13:27:38 - /usr/bin/make -B LINT TB --- 2012-11-27 13:27:38 - cd /src/sys/arm/conf TB --- 2012-11-27 13:27:38 - /usr/sbin/config -m LINT TB --- 2012-11-27 13:27:38 - building LINT kernel TB --- 2012-11-27 13:27:38 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 13:27:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 13:27:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 13:27:38 - SRCCONF=/dev/null TB --- 2012-11-27 13:27:38 - TARGET=arm TB --- 2012-11-27 13:27:38 - TARGET_ARCH=arm TB --- 2012-11-27 13:27:38 - TZ=UTC TB --- 2012-11-27 13:27:38 - __MAKE_CONF=/dev/null TB --- 2012-11-27 13:27:38 - cd /src TB --- 2012-11-27 13:27:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 27 13:27:39 UTC 2012 >>> 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 [...] uart_bus_fdt.o:uart_bus_fdt.c:(.text+0x0): first defined here uart_cpu_pxa.o: In function `uart_cpu_getdev': uart_cpu_pxa.c:(.text+0x18): multiple definition of `uart_cpu_getdev' uart_bus_fdt.o:uart_bus_fdt.c:(.text+0x264): first defined here uart_cpu_pxa.o:(.bss+0x4): multiple definition of `uart_bus_space_mem' uart_bus_fdt.o:(.bss+0x4): first defined here uart_cpu_pxa.o:(.bss+0x0): multiple definition of `uart_bus_space_io' uart_bus_fdt.o:(.bss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-27 13:41:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-27 13:41:01 - ERROR: failed to build LINT kernel TB --- 2012-11-27 13:41:01 - 3210.74 user 634.22 system 4860.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 13:50:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA1E8A89; Tue, 27 Nov 2012 13:50:41 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 21AD68FC13; Tue, 27 Nov 2012 13:50:40 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so11219457qcs.13 for ; Tue, 27 Nov 2012 05:50: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=VNyaE/Q92yZk54cu1mnOrGVWANmOqFPdMZKUGXK5L0k=; b=TPRure96C4F41MSv985wQ13DcK+bfoUDDacLtYmZLduGRSzO8XlQQ802HWFhnGJuiW vRNjnBN74zsmAWW9XZUGkd1KU7Zx43KNS4PIRgdLfIiHmAlVzzJqSjfz/OhlnThl3cEG HclEpwkOvjJCZqg0u3yo8honvZEnRyPy16H0mZKzKFLDEeiQxoU4BcZD8qCR+6nnCfbm CzhYBALlTOIicw6dEZlreBsffSsoISF1TtKqeKKKuirQ36i6RmleUi6FNMNk0qmBUZsx 4vXsszqtnQJavbgNCYd6en4ZtQEPkNLc7S5CbUrkqKsL1iRRyMaCgk8Y0BVW3UnDX8lf Pt9Q== MIME-Version: 1.0 Received: by 10.49.48.111 with SMTP id k15mr17956216qen.28.1354024240315; Tue, 27 Nov 2012 05:50:40 -0800 (PST) Received: by 10.49.121.163 with HTTP; Tue, 27 Nov 2012 05:50:40 -0800 (PST) In-Reply-To: <50B4A040.6060001@FreeBSD.org> References: <50B4A040.6060001@FreeBSD.org> Date: Tue, 27 Nov 2012 14:50:40 +0100 Message-ID: Subject: Re: Re-sizable UFS project From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Alex Dupre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 13:50:41 -0000 On Tue, Nov 27, 2012 at 12:13 PM, Alex Dupre wrote: > Ermal Lu=E7i ha scritto: > > some time ago the FreeBSD Foundation published/approved a project for > live > > resizing of UFS filesystems. > > Does any know if the project was successful and any outcome from it? > > http://lists.freebsd.org/pipermail/svn-src-head/2012-November/042539.html > > -- > Alex Dupre > Thank you, somehow my search terms must have been wrong. --=20 Ermal From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 14:02:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B22BD1F6; Tue, 27 Nov 2012 14:02:12 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id CB4E08FC0C; Tue, 27 Nov 2012 14:02:11 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so9297609lbb.13 for ; Tue, 27 Nov 2012 06:02:10 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MYK4Ewm35cLl769wwbOJ3rCl9StZfMEAerkfsvSBOzY=; b=xWCYb3xh2PA/36uDwKx1FhaUDb6fK0hPwWYg52gZf6HrM+vJEqfI7YbRgBlTBsB4lf SM1XjRRL4NQuQiIW/9V8a2L28NivgIKcpJlNMwYAClr9FJnFKWmhAaRu2L66tWILmm4q KRCvj1Z+6dUPD/a658fgIq3a2Yibo4HDKH0VlUo8FnhKYvcPLjwG40D99WUJS78nU1Zh jxk7u6EBEAeSpNvjbCTSomB9UX2Db2eurHNuMngzApTzBuuZsZi+OvFbyLyMsvWzfYIJ Lp0EaKPdNnjZGMMnxE+wJdNXzhw4ZVNJrqNIX3iMjrpQYZbAL1pF5dz3C1AjdRRmx5CE BiyA== MIME-Version: 1.0 Received: by 10.112.87.40 with SMTP id u8mr6632581lbz.50.1354024930146; Tue, 27 Nov 2012 06:02:10 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.12.226 with HTTP; Tue, 27 Nov 2012 06:02:09 -0800 (PST) In-Reply-To: References: <50B4A040.6060001@FreeBSD.org> Date: Tue, 27 Nov 2012 15:02:09 +0100 X-Google-Sender-Auth: phXZSAJ5H1ymzDeW1O3aNy-o9Vs Message-ID: Subject: Re: Re-sizable UFS project From: CeDeROM To: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Alex Dupre X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 14:02:12 -0000 Btw. are there any projects to make UFS natively available (something like fs-driver for ExtFS) on platforms such as Windows, Linux, MacOS? It would be nice to have native UFS instead Ext2 as universal filesystem among these operating systems... :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 15:05:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0D28494; Tue, 27 Nov 2012 15:05:36 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 08EAD8FC13; Tue, 27 Nov 2012 15:05:35 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so9376123lbb.13 for ; Tue, 27 Nov 2012 07:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZBZqBuUb3EyQ+3qsoLqWFrhvhDI7R/sljlhfZbtogbo=; b=Fc8s1aCpbdOvC8POd2EYgXS6HD7OM3K+JcsrXaa+OFkGqJftFhZPRC1drUJhdeIAbp Az2qN/FSS4M5LNmkU9s6QnUtb64cdUDnfaT5ReVVK4+I1HlYXSQmLhT9WF3BWtpyq2hX RuHiHeLZIwItwSKoj9HviGlJAyq/7DnzQ/Fpi38q7XYW9AEg1If0VaSEXvoLlvvt3Cmw Ls1Q1WyX1Pwa1Np41qRFmsd6zJJc0DYMW2z0wfQEjS8NwWAqoA8dtR9MUyK7VEAMmQ/T GG9nXv7yN4KSsEYLVWmlwzShZY6Hu+P9PcE6ixd0ni4cSAgL5pNR18jctM6Tq8hIBQcl mXhA== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr15229784lab.9.1354028734749; Tue, 27 Nov 2012 07:05:34 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Tue, 27 Nov 2012 07:05:34 -0800 (PST) In-Reply-To: <50B4A374.5040705@freebsd.org> References: <50B4A374.5040705@freebsd.org> Date: Tue, 27 Nov 2012 15:05:34 +0000 X-Google-Sender-Auth: KNGU8R5NgO5v5rn_J9_JrgsHqDw Message-ID: Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious From: Attilio Rao To: Andre Oppermann Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:05:36 -0000 On Tue, Nov 27, 2012 at 11:26 AM, Andre Oppermann wrote: > FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: > Fri Nov 23 17:00:40 CET 2012 > aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 > > #0 doadump (textdump=-2014022336) at pcpu.h:229 > #1 0xffffffff8033e2d2 in db_fncall (dummy1=, > dummy2=, > dummy3=, dummy4=) > at /usr/src/head/sys/ddb/db_command.c:578 > #2 0xffffffff8033e074 in db_command (last_cmdp=, > cmd_table=, dopager=1) at > /usr/src/head/sys/ddb/db_command.c:449 > #3 0xffffffff8033dd62 in db_command_loop () at > /usr/src/head/sys/ddb/db_command.c:502 > #4 0xffffffff80340690 in db_trap (type=, code=0) > at /usr/src/head/sys/ddb/db_main.c:231 > #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf= out>) > at /usr/src/head/sys/kern/subr_kdb.c:654 > #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) > at /usr/src/head/sys/amd64/amd64/trap.c:579 > #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 > #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", > msg=) > at cpufunc.h:63 > #9 0xffffffff8088086f in panic (fmt=) > at /usr/src/head/sys/kern/kern_shutdown.c:628 > #10 0xffffffff80adea4a in vm_object_madvise (object=, > pindex=, end=8952, advise=) > at /usr/src/head/sys/vm/vm_object.c:1101 Can you do: "frame 10" and then "info locals" and finally "p *m"? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 15:06:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C6335C7; Tue, 27 Nov 2012 15:06:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 84C7E8FC08; Tue, 27 Nov 2012 15:06:36 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qARF6PTB077134; Tue, 27 Nov 2012 17:06:25 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qARF6PTB077134 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qARF6P73077133; Tue, 27 Nov 2012 17:06:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Nov 2012 17:06:25 +0200 From: Konstantin Belousov To: Andre Oppermann Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious Message-ID: <20121127150625.GJ3013@kib.kiev.ua> References: <50B4A374.5040705@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBYU9MM4gf8jKg2V" Content-Disposition: inline In-Reply-To: <50B4A374.5040705@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, 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: alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 15:06:37 -0000 --gBYU9MM4gf8jKg2V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: > FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: > Fri Nov 23 17:00:40 CET 2012 > aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >=20 > #0 doadump (textdump=3D-2014022336) at pcpu.h:229 > #1 0xffffffff8033e2d2 in db_fncall (dummy1=3D,=20 > dummy2=3D, > dummy3=3D, dummy4=3D) > at /usr/src/head/sys/ddb/db_command.c:578 > #2 0xffffffff8033e074 in db_command (last_cmdp=3D, > cmd_table=3D, dopager=3D1) at=20 > /usr/src/head/sys/ddb/db_command.c:449 > #3 0xffffffff8033dd62 in db_command_loop () at=20 > /usr/src/head/sys/ddb/db_command.c:502 > #4 0xffffffff80340690 in db_trap (type=3D, code=3D0) > at /usr/src/head/sys/ddb/db_main.c:231 > #5 0xffffffff808b375e in kdb_trap (type=3D3, code=3D0, tf=3D out>) > at /usr/src/head/sys/kern/subr_kdb.c:654 > #6 0xffffffff80bfc71a in trap (frame=3D0xffffff8487f478a0) > at /usr/src/head/sys/amd64/amd64/trap.c:579 > #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 > #8 0xffffffff808b2f5e in kdb_enter (why=3D0xffffffff80e5e23b "panic",=20 > msg=3D) > at cpufunc.h:63 > #9 0xffffffff8088086f in panic (fmt=3D) > at /usr/src/head/sys/kern/kern_shutdown.c:628 > #10 0xffffffff80adea4a in vm_object_madvise (object=3D, > pindex=3D, end=3D8952, advise=3D) > at /usr/src/head/sys/vm/vm_object.c:1101 > #11 0xffffffff80ad759a in vm_map_madvise (map=3D0xfffffe0018260188,=20 > start=3D, > end=3D, behav=3D5) at=20 > /usr/src/head/sys/vm/vm_map.c:2140 > #12 0xffffffff80adbd8d in sys_madvise (td=3D,=20 > uap=3D) > at /usr/src/head/sys/vm/vm_mmap.c:752 > #13 0xffffffff80bfd3a5 in amd64_syscall (td=3D0xfffffe0018230000,=20 > traced=3D0) at subr_syscall.c:135 > #14 0xffffffff80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329 > #15 0x00000000016f3bfa in ?? () I think this is an omission in the check for the object types. BTW, this pattern already repeats in several places, I thought about adding either new pager method, like boolean_t vm_pager_is_pageable(), or just a flag fields to the struct vm_pager to classify the vm objects. I am curious, what was the process which caused the panic ? diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index e19750c..5b8ed23 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -1060,7 +1060,10 @@ shadowlookup: (tobject->flags & OBJ_ONEMAPPING) =3D=3D 0) { goto unlock_tobject; } - } else if (tobject->type =3D=3D OBJT_PHYS) + } else if (tobject->type =3D=3D OBJT_PHYS || + tobject->type =3D=3D OBJT_SG || + tobject->type =3D=3D OBJT_MGTDEVICE || + tobject->type =3D=3D OBJT_DEVICE) goto unlock_tobject; m =3D vm_page_lookup(tobject, tpindex); if (m =3D=3D NULL && advise =3D=3D MADV_WILLNEED) { --gBYU9MM4gf8jKg2V Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC01vEACgkQC3+MBN1Mb4j9cgCeO9vu/sGtdDSGBCzqytogsdEw WvwAn3FkmqtYO5m94Ged1eOhqRJqSR59 =fXn/ -----END PGP SIGNATURE----- --gBYU9MM4gf8jKg2V-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 15:09:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94A1F864 for ; Tue, 27 Nov 2012 15:09:02 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id F29F78FC14 for ; Tue, 27 Nov 2012 15:09:01 +0000 (UTC) Received: (qmail 35404 invoked from network); 27 Nov 2012 16:40:33 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Nov 2012 16:40:33 -0000 Message-ID: <50B4D7E1.60004@freebsd.org> Date: Tue, 27 Nov 2012 16:10:25 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 15:09:02 -0000 On 27.11.2012 16:05, Attilio Rao wrote: > On Tue, Nov 27, 2012 at 11:26 AM, Andre Oppermann wrote: >> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: >> Fri Nov 23 17:00:40 CET 2012 >> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >> >> #0 doadump (textdump=-2014022336) at pcpu.h:229 >> #1 0xffffffff8033e2d2 in db_fncall (dummy1=, >> dummy2=, >> dummy3=, dummy4=) >> at /usr/src/head/sys/ddb/db_command.c:578 >> #2 0xffffffff8033e074 in db_command (last_cmdp=, >> cmd_table=, dopager=1) at >> /usr/src/head/sys/ddb/db_command.c:449 >> #3 0xffffffff8033dd62 in db_command_loop () at >> /usr/src/head/sys/ddb/db_command.c:502 >> #4 0xffffffff80340690 in db_trap (type=, code=0) >> at /usr/src/head/sys/ddb/db_main.c:231 >> #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=> out>) >> at /usr/src/head/sys/kern/subr_kdb.c:654 >> #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) >> at /usr/src/head/sys/amd64/amd64/trap.c:579 >> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 >> #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", >> msg=) >> at cpufunc.h:63 >> #9 0xffffffff8088086f in panic (fmt=) >> at /usr/src/head/sys/kern/kern_shutdown.c:628 >> #10 0xffffffff80adea4a in vm_object_madvise (object=, >> pindex=, end=8952, advise=) >> at /usr/src/head/sys/vm/vm_object.c:1101 > > Can you do: "frame 10" and then "info locals" and finally "p *m"? (kgdb) frame 10 #10 0xffffffff80adea4a in vm_object_madvise (object=, pindex=, end=8952, advise=) at /usr/src/head/sys/vm/vm_object.c:1101 1101 KASSERT((m->flags & PG_FICTITIOUS) == 0, Current language: auto; currently minimal (kgdb) info locals m = backing_object = tpindex = (kgdb) p *m Cannot access memory at address 0xa00000038 (kgdb) -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 15:36:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0366779B for ; Tue, 27 Nov 2012 15:36:43 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8A88FC0C for ; Tue, 27 Nov 2012 15:36:42 +0000 (UTC) Received: (qmail 35499 invoked from network); 27 Nov 2012 17:08:20 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Nov 2012 17:08:20 -0000 Message-ID: <50B4DE64.5090809@freebsd.org> Date: Tue, 27 Nov 2012 16:38:12 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> In-Reply-To: <20121127150625.GJ3013@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 15:36:44 -0000 On 27.11.2012 16:06, Konstantin Belousov wrote: > On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: >> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: >> Fri Nov 23 17:00:40 CET 2012 >> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >> >> #0 doadump (textdump=-2014022336) at pcpu.h:229 >> #1 0xffffffff8033e2d2 in db_fncall (dummy1=, >> dummy2=, >> dummy3=, dummy4=) >> at /usr/src/head/sys/ddb/db_command.c:578 >> #2 0xffffffff8033e074 in db_command (last_cmdp=, >> cmd_table=, dopager=1) at >> /usr/src/head/sys/ddb/db_command.c:449 >> #3 0xffffffff8033dd62 in db_command_loop () at >> /usr/src/head/sys/ddb/db_command.c:502 >> #4 0xffffffff80340690 in db_trap (type=, code=0) >> at /usr/src/head/sys/ddb/db_main.c:231 >> #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=> out>) >> at /usr/src/head/sys/kern/subr_kdb.c:654 >> #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) >> at /usr/src/head/sys/amd64/amd64/trap.c:579 >> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 >> #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", >> msg=) >> at cpufunc.h:63 >> #9 0xffffffff8088086f in panic (fmt=) >> at /usr/src/head/sys/kern/kern_shutdown.c:628 >> #10 0xffffffff80adea4a in vm_object_madvise (object=, >> pindex=, end=8952, advise=) >> at /usr/src/head/sys/vm/vm_object.c:1101 >> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >> start=, >> end=, behav=5) at >> /usr/src/head/sys/vm/vm_map.c:2140 >> #12 0xffffffff80adbd8d in sys_madvise (td=, >> uap=) >> at /usr/src/head/sys/vm/vm_mmap.c:752 >> #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, >> traced=0) at subr_syscall.c:135 >> #14 0xffffffff80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329 >> #15 0x00000000016f3bfa in ?? () > > I think this is an omission in the check for the object types. BTW, this > pattern already repeats in several places, I thought about adding either > new pager method, like boolean_t vm_pager_is_pageable(), or just a flag > fields to the struct vm_pager to classify the vm objects. > > I am curious, what was the process which caused the panic ? Clang doing a manual kernel build of my work tree with "make -j8 kernel". -- Andre > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index e19750c..5b8ed23 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -1060,7 +1060,10 @@ shadowlookup: > (tobject->flags & OBJ_ONEMAPPING) == 0) { > goto unlock_tobject; > } > - } else if (tobject->type == OBJT_PHYS) > + } else if (tobject->type == OBJT_PHYS || > + tobject->type == OBJT_SG || > + tobject->type == OBJT_MGTDEVICE || > + tobject->type == OBJT_DEVICE) > goto unlock_tobject; > m = vm_page_lookup(tobject, tpindex); > if (m == NULL && advise == MADV_WILLNEED) { > From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 15:41:02 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 479329DF; Tue, 27 Nov 2012 15:41:02 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7738FC13; Tue, 27 Nov 2012 15:41:00 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA14465; Tue, 27 Nov 2012 17:40:58 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50B4DF0A.6030106@FreeBSD.org> Date: Tue, 27 Nov 2012 17:40:58 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> <50B4DE64.5090809@freebsd.org> In-Reply-To: <50B4DE64.5090809@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , alc@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 15:41:02 -0000 on 27/11/2012 17:38 Andre Oppermann said the following: > Clang doing a manual kernel build of my work tree with "make -j8 kernel". This sounds like a "process" that may have triggered the problem. But is it the process that made the syscall in the backtrace? You can check by e.g. going to frame 13 and examining *td and *td->td_proc. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 15:51:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D02A512A; Tue, 27 Nov 2012 15:51:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 278518FC14; Tue, 27 Nov 2012 15:51:38 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qARFpWXL081616; Tue, 27 Nov 2012 17:51:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qARFpWXL081616 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qARFpWb1081615; Tue, 27 Nov 2012 17:51:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Nov 2012 17:51:32 +0200 From: Konstantin Belousov To: Andre Oppermann Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious Message-ID: <20121127155132.GM3013@kib.kiev.ua> References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> <50B4DE64.5090809@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TN8pJM9vJMHHFgJc" Content-Disposition: inline In-Reply-To: <50B4DE64.5090809@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, 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: alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 15:51:39 -0000 --TN8pJM9vJMHHFgJc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2012 at 04:38:12PM +0100, Andre Oppermann wrote: > On 27.11.2012 16:06, Konstantin Belousov wrote: > > On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: > >> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: > >> Fri Nov 23 17:00:40 CET 2012 > >> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 > >> > >> #0 doadump (textdump=3D-2014022336) at pcpu.h:229 > >> #1 0xffffffff8033e2d2 in db_fncall (dummy1=3D, > >> dummy2=3D, > >> dummy3=3D, dummy4=3D) > >> at /usr/src/head/sys/ddb/db_command.c:578 > >> #2 0xffffffff8033e074 in db_command (last_cmdp=3D, > >> cmd_table=3D, dopager=3D1) at > >> /usr/src/head/sys/ddb/db_command.c:449 > >> #3 0xffffffff8033dd62 in db_command_loop () at > >> /usr/src/head/sys/ddb/db_command.c:502 > >> #4 0xffffffff80340690 in db_trap (type=3D, code= =3D0) > >> at /usr/src/head/sys/ddb/db_main.c:231 > >> #5 0xffffffff808b375e in kdb_trap (type=3D3, code=3D0, tf=3D >> out>) > >> at /usr/src/head/sys/kern/subr_kdb.c:654 > >> #6 0xffffffff80bfc71a in trap (frame=3D0xffffff8487f478a0) > >> at /usr/src/head/sys/amd64/amd64/trap.c:579 > >> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 > >> #8 0xffffffff808b2f5e in kdb_enter (why=3D0xffffffff80e5e23b "panic", > >> msg=3D) > >> at cpufunc.h:63 > >> #9 0xffffffff8088086f in panic (fmt=3D) > >> at /usr/src/head/sys/kern/kern_shutdown.c:628 > >> #10 0xffffffff80adea4a in vm_object_madvise (object=3D, > >> pindex=3D, end=3D8952, advise=3D) > >> at /usr/src/head/sys/vm/vm_object.c:1101 > >> #11 0xffffffff80ad759a in vm_map_madvise (map=3D0xfffffe0018260188, > >> start=3D, > >> end=3D, behav=3D5) at > >> /usr/src/head/sys/vm/vm_map.c:2140 > >> #12 0xffffffff80adbd8d in sys_madvise (td=3D, > >> uap=3D) > >> at /usr/src/head/sys/vm/vm_mmap.c:752 > >> #13 0xffffffff80bfd3a5 in amd64_syscall (td=3D0xfffffe0018230000, > >> traced=3D0) at subr_syscall.c:135 > >> #14 0xffffffff80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:= 329 > >> #15 0x00000000016f3bfa in ?? () > > > > I think this is an omission in the check for the object types. BTW, this > > pattern already repeats in several places, I thought about adding either > > new pager method, like boolean_t vm_pager_is_pageable(), or just a flag > > fields to the struct vm_pager to classify the vm objects. > > > > I am curious, what was the process which caused the panic ? >=20 > Clang doing a manual kernel build of my work tree with "make -j8 kernel". You did not answered my question, what was the process that caused the panic ? As in, could it be X server ? >=20 > --=20 > Andre >=20 > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > > index e19750c..5b8ed23 100644 > > --- a/sys/vm/vm_object.c > > +++ b/sys/vm/vm_object.c > > @@ -1060,7 +1060,10 @@ shadowlookup: > > (tobject->flags & OBJ_ONEMAPPING) =3D=3D 0) { > > goto unlock_tobject; > > } > > - } else if (tobject->type =3D=3D OBJT_PHYS) > > + } else if (tobject->type =3D=3D OBJT_PHYS || > > + tobject->type =3D=3D OBJT_SG || > > + tobject->type =3D=3D OBJT_MGTDEVICE || > > + tobject->type =3D=3D OBJT_DEVICE) > > goto unlock_tobject; > > m =3D vm_page_lookup(tobject, tpindex); > > if (m =3D=3D NULL && advise =3D=3D MADV_WILLNEED) { > > --TN8pJM9vJMHHFgJc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC04YQACgkQC3+MBN1Mb4hcUwCg6u0MJhVWTPhVtM12xv3EZIw3 08QAni9vFYfIMfIXbaU4Z7kH6nmAGb2e =lOXC -----END PGP SIGNATURE----- --TN8pJM9vJMHHFgJc-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 16:03:27 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 693AACB8 for ; Tue, 27 Nov 2012 16:03:27 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 914298FC1D for ; Tue, 27 Nov 2012 16:03:26 +0000 (UTC) Received: (qmail 35617 invoked from network); 27 Nov 2012 17:35:03 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Nov 2012 17:35:03 -0000 Message-ID: <50B4E4A7.9080705@freebsd.org> Date: Tue, 27 Nov 2012 17:04:55 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> <50B4DE64.5090809@freebsd.org> <50B4DF0A.6030106@FreeBSD.org> In-Reply-To: <50B4DF0A.6030106@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , alc@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 16:03:27 -0000 On 27.11.2012 16:40, Andriy Gapon wrote: > on 27/11/2012 17:38 Andre Oppermann said the following: >> Clang doing a manual kernel build of my work tree with "make -j8 kernel". > > This sounds like a "process" that may have triggered the problem. > But is it the process that made the syscall in the backtrace? > You can check by e.g. going to frame 13 and examining *td and *td->td_proc. > (kgdb) frame 13 #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, traced=0) at subr_syscall.c:135 135 error = (sa->callp->sy_call)(td, sa->args); Current language: auto; currently minimal (kgdb) p *td $1 = {td_lock = 0xffffffff812ac180, td_proc = 0xfffffe0256301950, td_plist = {tqe_next = 0x0, tqe_prev = 0xfffffe0256301960}, td_runq = {tqe_next = 0x0, tqe_prev = 0xffffffff812ac630}, td_slpq = {tqe_next = 0x0, tqe_prev = 0xfffffe00181c6a80}, td_lockq = {tqe_next = 0x0, tqe_prev = 0xffffff8487efc540}, td_hash = {le_next = 0x0, le_prev = 0xffffff80006ffe58}, td_cpuset = 0xfffffe0007376dc8, td_sel = 0x0, td_sleepqueue = 0xfffffe00181c6a80, td_turnstile = 0xfffffe0018378b40, td_rlqe = 0xfffffe0018215a00, td_umtxq = 0xfffffe0018170580, td_tid = 100299, td_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {tqh_first = 0x0, tqh_last = 0xfffffe00182300b8}, sq_proc = 0xfffffe0256301950, sq_flags = 1}, td_lend_user_pri = 255 'ÿ', td_flags = 4, td_inhibitors = 0, td_pflags = 0, td_dupfd = 0, td_sqqueue = 0, td_wchan = 0x0, td_wmesg = 0x0, td_lastcpu = 0 '\0', td_oncpu = 0 '\0', td_owepreempt = 0 '\0', td_tsqueue = 255 'ÿ', td_locks = 3, td_rw_rlocks = 0, td_lk_slocks = 0, td_stopsched = 1, td_blocked = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0}, td_sleeplocks = 0xffffffff81429ea0, td_intr_nesting_level = 0, td_pinned = 1, td_ucred = 0xfffffe0018244c00, td_estcpu = 0, td_slptick = 0, td_blktick = 0, td_swvoltick = 2312563, td_cow = 6, td_ru = {ru_utime = { tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 50728, ru_ixrss = 2858440, ru_idrss = 31280, ru_isrss = 26752, ru_minflt = 7722, ru_majflt = 11, ru_nswap = 0, ru_inblock = 8, ru_oublock = 4, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 35, ru_nivcsw = 98}, td_rux = {rux_runtime = 0, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, td_incruntime = 2792408043, td_runtime = 2792408043, td_pticks = 0, td_sticks = 7, td_iticks = 0, td_uticks = 108, td_intrval = 0, td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_generation = 133, td_sigstk = { ss_sp = 0x0, ss_size = 0, ss_flags = 4}, td_xsig = 0, td_profil_addr = 0, td_profil_ticks = 0, td_name = "cc", '\0' , td_fpop = 0x0, td_dbgflags = 0, td_dbgksi = { ksi_link = {tqe_next = 0x0, tqe_prev = 0x0}, ksi_info = {si_signo = 0, si_errno = 0, si_code = 0, si_pid = 0, si_uid = 0, si_status = 0, si_addr = 0x0, si_value = { sival_int = 0, sival_ptr = 0x0, sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = { _trapno = 0}, _timer = {_timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = { _band = 0}, __spare__ = {__spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0}}}}, ksi_flags = 0, ksi_sigq = 0x0}, td_ng_outbound = 0, td_osd = {osd_nslots = 0, osd_slots = 0x0, osd_next = {le_next = 0x0, le_prev = 0x0}}, td_map_def_user = 0x0, td_dbg_forked = 0, td_vp_reserv = 0, td_sigmask = {__bits = {0, 0, 0, 0}}, td_rqindex = 0 '\0', td_base_pri = 175 '¯', td_priority = 175 '¯', td_pri_class = 3 '\003', td_user_pri = 175 '¯', td_base_user_pri = 175 '¯', td_pcb = 0xffffff8487f47cc0, td_state = TDS_RUNNING, td_retval = {0, 5}, td_slpcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 16, c_cpu = 0}, td_frame = 0xffffff8487f47c00, td_kstack_obj = 0xfffffe0256092570, td_kstack = 18446743543414538240, td_kstack_pages = 4, td_critnest = 1, td_md = { md_spinlock_count = 1, md_saved_flags = 582, md_spurflt_addr = 34407014400}, td_sched = 0xfffffe0018230458, td_ar = 0x0, td_lprof = {{lh_first = 0x0}, {lh_first = 0x0}}, td_dtrace = 0xfffffe0248e8c000, td_errno = 0, td_vnet = 0x0, td_vnet_lpush = 0x0, td_intr_frame = 0x0, td_rfppwait_p = 0xfffffe0248f8a950, td_ma = 0x0, td_ma_cnt = 0} (kgdb) p *td->td_proc $2 = {p_list = {le_next = 0xfffffe0248f8a950, le_prev = 0xfffffe0248eb04a8}, p_threads = { tqh_first = 0xfffffe0018230000, tqh_last = 0xfffffe0018230010}, p_slock = {lock_object = { lo_name = 0xffffffff80e5c3a8 "process slock", lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, p_ucred = 0xfffffe0018244c00, p_fd = 0xfffffe0018560000, p_fdtol = 0x0, p_stats = 0xfffffe0018225a00, p_limit = 0xfffffe0018468900, p_limco = {c_links = { sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0xfffffe0256301a48, c_flags = 0, c_cpu = 0}, p_sigacts = 0xfffffe0256372000, p_flag = 268451842, p_state = PRS_NORMAL, p_pid = 5732, p_hash = {le_next = 0x0, le_prev = 0xffffff80006ed320}, p_pglist = { le_next = 0xfffffe0248d5f000, le_prev = 0xfffffe0248f8aa18}, p_pptr = 0xfffffe0248f8a950, p_sibling = {le_next = 0x0, le_prev = 0xfffffe0248f8aa40}, p_children = {lh_first = 0x0}, p_mtx = {lock_object = {lo_name = 0xffffffff80e5c39b "process lock", lo_flags = 21168128, lo_data = 0, lo_witness = 0xffffff80006c8400}, mtx_lock = 4}, p_ksi = 0xfffffe0016c82850, p_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {tqh_first = 0x0, tqh_last = 0xfffffe0256301a90}, sq_proc = 0xfffffe0256301950, sq_flags = 1}, p_oppid = 0, p_vmspace = 0xfffffe0018260188, p_swtick = 2311559, p_realtimer = { it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec = 0}}, p_ru = { ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 0, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, p_crux = {rux_runtime = 0, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, p_profthreads = 0, p_exitthreads = 0, p_traceflag = 0, p_tracevp = 0x0, p_tracecred = 0x0, p_textvp = 0xfffffe0248d4f5d0, p_lock = 0, p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_sig = 0, p_code = 0, p_stops = 0, p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo = 0x0, p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, p_boundary_count = 0, p_pendingcnt = 0, p_itimers = 0x0, p_procdesc = 0x0, p_magic = 3203398350, p_osrel = 1000025, p_comm = "cc", '\0' , p_pgrp = 0xfffffe00184e5900, p_sysent = 0xffffffff8123bf58, p_args = 0x0, p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_fibnum = 0, p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0xffffffff80849790 , kl_unlock = 0xffffffff808497b0 , kl_assert_locked = 0xffffffff808497d0 , kl_assert_unlocked = 0xffffffff808497f0 , kl_lockarg = 0xfffffe0256301a48}, p_numthreads = 1, p_md = {md_ldt = 0x0, md_ldt_sd = { sd_lolimit = 0, sd_lobase = 0, sd_type = 0, sd_dpl = 0, sd_p = 0, sd_hilimit = 0, sd_xx0 = 0, sd_gran = 0, sd_hibase = 0, sd_xx1 = 0, sd_mbz = 0, sd_xx2 = 0}}, p_itcallout = { c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 16, c_cpu = 0}, p_acflag = 0, p_peers = 0x0, p_leader = 0xfffffe0256301950, p_emuldata = 0x0, p_label = 0x0, p_sched = 0xfffffe0256301df8, p_ktr = {stqh_first = 0x0, stqh_last = 0xfffffe0256301d88}, p_mqnotifier = {lh_first = 0x0}, p_dtrace = 0xfffffe0256687a40, p_pwait = {cv_description = 0xffffffff80e5d034 "ppwait", cv_waiters = 0}, p_dbgwait = {cv_description = 0xffffffff80e5d03b "dbgwait", cv_waiters = 0}, p_prev_runtime = 0, p_racct = 0x0, p_throttled = 0 '\0', p_orphan = {le_next = 0x0, le_prev = 0x0}, p_orphans = {lh_first = 0x0}} -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 16:05:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B520DE7 for ; Tue, 27 Nov 2012 16:05:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6242A8FC1C for ; Tue, 27 Nov 2012 16:05:06 +0000 (UTC) Received: (qmail 35628 invoked from network); 27 Nov 2012 17:36:44 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Nov 2012 17:36:44 -0000 Message-ID: <50B4E50C.6010809@freebsd.org> Date: Tue, 27 Nov 2012 17:06:36 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> <50B4DE64.5090809@freebsd.org> <20121127155132.GM3013@kib.kiev.ua> In-Reply-To: <20121127155132.GM3013@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 16:05:08 -0000 On 27.11.2012 16:51, Konstantin Belousov wrote: > On Tue, Nov 27, 2012 at 04:38:12PM +0100, Andre Oppermann wrote: >> On 27.11.2012 16:06, Konstantin Belousov wrote: >>> On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: >>>> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: >>>> Fri Nov 23 17:00:40 CET 2012 >>>> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >>>> >>>> #0 doadump (textdump=-2014022336) at pcpu.h:229 >>>> #1 0xffffffff8033e2d2 in db_fncall (dummy1=, >>>> dummy2=, >>>> dummy3=, dummy4=) >>>> at /usr/src/head/sys/ddb/db_command.c:578 >>>> #2 0xffffffff8033e074 in db_command (last_cmdp=, >>>> cmd_table=, dopager=1) at >>>> /usr/src/head/sys/ddb/db_command.c:449 >>>> #3 0xffffffff8033dd62 in db_command_loop () at >>>> /usr/src/head/sys/ddb/db_command.c:502 >>>> #4 0xffffffff80340690 in db_trap (type=, code=0) >>>> at /usr/src/head/sys/ddb/db_main.c:231 >>>> #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=>>> out>) >>>> at /usr/src/head/sys/kern/subr_kdb.c:654 >>>> #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) >>>> at /usr/src/head/sys/amd64/amd64/trap.c:579 >>>> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 >>>> #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", >>>> msg=) >>>> at cpufunc.h:63 >>>> #9 0xffffffff8088086f in panic (fmt=) >>>> at /usr/src/head/sys/kern/kern_shutdown.c:628 >>>> #10 0xffffffff80adea4a in vm_object_madvise (object=, >>>> pindex=, end=8952, advise=) >>>> at /usr/src/head/sys/vm/vm_object.c:1101 >>>> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >>>> start=, >>>> end=, behav=5) at >>>> /usr/src/head/sys/vm/vm_map.c:2140 >>>> #12 0xffffffff80adbd8d in sys_madvise (td=, >>>> uap=) >>>> at /usr/src/head/sys/vm/vm_mmap.c:752 >>>> #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, >>>> traced=0) at subr_syscall.c:135 >>>> #14 0xffffffff80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329 >>>> #15 0x00000000016f3bfa in ?? () >>> >>> I think this is an omission in the check for the object types. BTW, this >>> pattern already repeats in several places, I thought about adding either >>> new pager method, like boolean_t vm_pager_is_pageable(), or just a flag >>> fields to the struct vm_pager to classify the vm objects. >>> >>> I am curious, what was the process which caused the panic ? >> >> Clang doing a manual kernel build of my work tree with "make -j8 kernel". > You did not answered my question, what was the process that caused the > panic ? As in, could it be X server ? No X on this machine. Pure ssh login. See my other reply for *td and *td->td_proc output. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 16:42:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F729F89; Tue, 27 Nov 2012 16:42:57 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx1.freebsd.org (Postfix) with ESMTP id 0C94D8FC13; Tue, 27 Nov 2012 16:42:56 +0000 (UTC) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 92A504C03B6; Tue, 27 Nov 2012 10:42:49 -0600 (CST) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 910024C02FE; Tue, 27 Nov 2012 10:42:49 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id YP-Ye_oXYpOj; Tue, 27 Nov 2012 10:42:49 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 8226F4C03A0; Tue, 27 Nov 2012 10:42:47 -0600 (CST) Message-ID: <50B4ED86.40308@rice.edu> Date: Tue, 27 Nov 2012 10:42:46 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> In-Reply-To: <20121127150625.GJ3013@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 16:42:57 -0000 On 11/27/2012 09:06, Konstantin Belousov wrote: > On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: >> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: >> Fri Nov 23 17:00:40 CET 2012 >> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >> >> #0 doadump (textdump=-2014022336) at pcpu.h:229 >> #1 0xffffffff8033e2d2 in db_fncall (dummy1=, >> dummy2=, >> dummy3=, dummy4=) >> at /usr/src/head/sys/ddb/db_command.c:578 >> #2 0xffffffff8033e074 in db_command (last_cmdp=, >> cmd_table=, dopager=1) at >> /usr/src/head/sys/ddb/db_command.c:449 >> #3 0xffffffff8033dd62 in db_command_loop () at >> /usr/src/head/sys/ddb/db_command.c:502 >> #4 0xffffffff80340690 in db_trap (type=, code=0) >> at /usr/src/head/sys/ddb/db_main.c:231 >> #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=> out>) >> at /usr/src/head/sys/kern/subr_kdb.c:654 >> #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) >> at /usr/src/head/sys/amd64/amd64/trap.c:579 >> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 >> #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", >> msg=) >> at cpufunc.h:63 >> #9 0xffffffff8088086f in panic (fmt=) >> at /usr/src/head/sys/kern/kern_shutdown.c:628 >> #10 0xffffffff80adea4a in vm_object_madvise (object=, >> pindex=, end=8952, advise=) >> at /usr/src/head/sys/vm/vm_object.c:1101 >> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >> start=, >> end=, behav=5) at >> /usr/src/head/sys/vm/vm_map.c:2140 >> #12 0xffffffff80adbd8d in sys_madvise (td=, >> uap=) >> at /usr/src/head/sys/vm/vm_mmap.c:752 >> #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, >> traced=0) at subr_syscall.c:135 >> #14 0xffffffff80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329 >> #15 0x00000000016f3bfa in ?? () > I think this is an omission in the check for the object types. BTW, this > pattern already repeats in several places, I thought about adding either > new pager method, like boolean_t vm_pager_is_pageable(), or just a flag > fields to the struct vm_pager to classify the vm objects. A fictitious page should always have a non-zero wire count. In fact, it should always be one and never change. (See vm_page_unwire().) In vm_object_madvise(), there is a check against the page's wire count that precedes the KASSERT(). This check should prevent the KASSERT() from being reached for the various device-backed object types. So, something else has gone wrong here, or rather something has gone wrong elsewhere that caused the KASSERT() failure here. Andre, can we see the contents of the offending struct vm_page and also the struct vm_object to which the offending page belongs to? Also, are you running a kernel with any experimental zero-copy send support? (Kostik, by the way, I would be happy to see attribute flags added to the vm object to take the place of the type checks.) > I am curious, what was the process which caused the panic ? > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index e19750c..5b8ed23 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -1060,7 +1060,10 @@ shadowlookup: > (tobject->flags & OBJ_ONEMAPPING) == 0) { > goto unlock_tobject; > } > - } else if (tobject->type == OBJT_PHYS) > + } else if (tobject->type == OBJT_PHYS || > + tobject->type == OBJT_SG || > + tobject->type == OBJT_MGTDEVICE || > + tobject->type == OBJT_DEVICE) > goto unlock_tobject; > m = vm_page_lookup(tobject, tpindex); > if (m == NULL && advise == MADV_WILLNEED) { From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 18:06:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 308143E1 for ; Tue, 27 Nov 2012 18:06:55 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0FE8FC12 for ; Tue, 27 Nov 2012 18:06:54 +0000 (UTC) Received: (qmail 36055 invoked from network); 27 Nov 2012 19:38:29 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Nov 2012 19:38:29 -0000 Message-ID: <50B50196.4080804@freebsd.org> Date: Tue, 27 Nov 2012 19:08:22 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Alan Cox Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> <50B4ED86.40308@rice.edu> In-Reply-To: <50B4ED86.40308@rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 18:06:55 -0000 On 27.11.2012 17:42, Alan Cox wrote: > On 11/27/2012 09:06, Konstantin Belousov wrote: >> On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: >>> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: >>> Fri Nov 23 17:00:40 CET 2012 >>> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >>> >>> #0 doadump (textdump=-2014022336) at pcpu.h:229 >>> #1 0xffffffff8033e2d2 in db_fncall (dummy1=, >>> dummy2=, >>> dummy3=, dummy4=) >>> at /usr/src/head/sys/ddb/db_command.c:578 >>> #2 0xffffffff8033e074 in db_command (last_cmdp=, >>> cmd_table=, dopager=1) at >>> /usr/src/head/sys/ddb/db_command.c:449 >>> #3 0xffffffff8033dd62 in db_command_loop () at >>> /usr/src/head/sys/ddb/db_command.c:502 >>> #4 0xffffffff80340690 in db_trap (type=, code=0) >>> at /usr/src/head/sys/ddb/db_main.c:231 >>> #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=>> out>) >>> at /usr/src/head/sys/kern/subr_kdb.c:654 >>> #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) >>> at /usr/src/head/sys/amd64/amd64/trap.c:579 >>> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 >>> #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", >>> msg=) >>> at cpufunc.h:63 >>> #9 0xffffffff8088086f in panic (fmt=) >>> at /usr/src/head/sys/kern/kern_shutdown.c:628 >>> #10 0xffffffff80adea4a in vm_object_madvise (object=, >>> pindex=, end=8952, advise=) >>> at /usr/src/head/sys/vm/vm_object.c:1101 >>> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >>> start=, >>> end=, behav=5) at >>> /usr/src/head/sys/vm/vm_map.c:2140 >>> #12 0xffffffff80adbd8d in sys_madvise (td=, >>> uap=) >>> at /usr/src/head/sys/vm/vm_mmap.c:752 >>> #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, >>> traced=0) at subr_syscall.c:135 >>> #14 0xffffffff80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329 >>> #15 0x00000000016f3bfa in ?? () >> I think this is an omission in the check for the object types. BTW, this >> pattern already repeats in several places, I thought about adding either >> new pager method, like boolean_t vm_pager_is_pageable(), or just a flag >> fields to the struct vm_pager to classify the vm objects. > > > A fictitious page should always have a non-zero wire count. In fact, it > should always be one and never change. (See vm_page_unwire().) In > vm_object_madvise(), there is a check against the page's wire count that > precedes the KASSERT(). This check should prevent the KASSERT() from > being reached for the various device-backed object types. So, something > else has gone wrong here, or rather something has gone wrong elsewhere > that caused the KASSERT() failure here. > > Andre, can we see the contents of the offending struct vm_page and also > the struct vm_object to which the offending page belongs to? Also, are > you running a kernel with any experimental zero-copy send support? No experimental zero-copy support, or anything else, just a stock GENERIC kernel. (kgdb) frame 11 #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, start=, end=, behav=5) at /usr/src/head/sys/vm/vm_map.c:2140 2140 vm_object_madvise(current->object.vm_object, pstart, (kgdb) p *map $1 = {header = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, left = 0x0, right = 0x0, start = 4096, end = 140737488355328, avail_ssize = 0, adj_free = 0, max_free = 0, object = { vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0, protection = 0 '\0', max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0 '\0', wired_count = 0, next_read = 0, cred = 0x0}, lock = {lock_object = { lo_name = 0xffffffff80e66905 "vm map (user)", lo_flags = 36896768, lo_data = 0, lo_witness = 0xffffff80006c9700}, sx_lock = 17}, system_mtx = {lock_object = { lo_name = 0xffffffff80e668d7 "vm map (system)", lo_flags = 21168128, lo_data = 0, lo_witness = 0xffffff80006c9500}, mtx_lock = 4}, nentries = 32, size = 64647168, timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags = 0 '\0', root = 0xfffffe02560a6258, pmap = 0xfffffe00182602b8, busy = 0} (kgdb) p* map->pmap $6 = {pm_mtx = {lock_object = {lo_name = 0xffffffff80e66934 "pmap", lo_flags = 21168128, lo_data = 0, lo_witness = 0xffffff80006c9900}, mtx_lock = 4}, pm_pml4 = 0xfffffe0256458000, pm_pvchunk = {tqh_first = 0xfffffe0256142000, tqh_last = 0xfffffe025644c008}, pm_active = { __bits = {1}}, pm_stats = {resident_count = 12683, wired_count = 0}, pm_root = 0xfffffe041289e040} (kgdb) p* map->root $7 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left = 0xfffffe0018ed0708, right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536, avail_ssize = 0, adj_free = 140703057047552, max_free = 140703057047552, object = { vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570}, offset = 1810432, eflags = 0, protection = 3 '\003', max_protection = 7 '\a', inheritance = 1 '\001', read_ahead = 15 '\017', wired_count = 0, next_read = 0, cred = 0x0} (kgdb) p *current $2 = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, left = 0x0, right = 0x0, start = 4096, end = 140737488355328, avail_ssize = 0, adj_free = 0, max_free = 0, object = {vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0, protection = 0 '\0', max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0 '\0', wired_count = 0, next_read = 0, cred = 0x0} (kgdb) p *entry $3 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left = 0xfffffe0018ed0708, right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536, avail_ssize = 0, adj_free = 140703057047552, max_free = 140703057047552, object = { vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570}, offset = 1810432, eflags = 0, protection = 3 '\003', max_protection = 7 '\a', inheritance = 1 '\001', read_ahead = 15 '\017', wired_count = 0, next_read = 0, cred = 0x0} (kgdb) p *entry->object.vm_object $4 = {mtx = {lock_object = {lo_name = 0xffffffff80e66913 "vm object", lo_flags = 21168128, lo_data = 0, lo_witness = 0xffffff80006cdd00}, mtx_lock = 18446741875091243008}, object_list = {tqe_next = 0xfffffe0248ffb910, tqe_prev = 0xfffffe025618e020}, shadow_head = { lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0x0}, memq = { tqh_first = 0xfffffe0413891880, tqh_last = 0xfffffe0413a3a570}, root = 0xfffffe0413c58630, size = 9658, generation = 1, ref_count = 1, shadow_count = 0, memattr = 6 '\006', type = 0 '\0', flags = 12288, pg_color = 7750, paging_in_progress = 0, resident_page_count = 7650, backing_object = 0x0, backing_object_offset = 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {lh_first = 0xfffffe0400ff07c0}, cache = 0x0, handle = 0x0, un_pager = { vnp = {vnp_size = 0, writemappings = 0}, devp = {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0}, sgp = {sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_bcount = 0}}, cred = 0xfffffe0018244c00, charge = 39559168} (kgdb) p *entry->object.sub_map $5 = {header = {prev = 0xffffffff80e66913, next = 0x1430000, left = 0xffffff80006cdd00, right = 0xfffffe0018230000, start = 18446741884500949264, end = 18446741884720701472, avail_ssize = 0, adj_free = 0, max_free = 0, object = {vm_object = 0xfffffe0413891880, sub_map = 0xfffffe0413891880}, offset = -2181513894544, eflags = 331712048, protection = 4 '\004', max_protection = 254 'þ', inheritance = -1 'ÿ', read_ahead = 255 'ÿ', wired_count = 9658, next_read = 4294967297, cred = 0x3000000600000000}, lock = {lock_object = { lo_name = 0x1e46
, lo_flags = 7650, lo_data = 0, lo_witness = 0x0}, sx_lock = 0}, system_mtx = {lock_object = {lo_name = 0x0, lo_flags = 0, lo_data = 0, lo_witness = 0xfffffe0400ff07c0}, mtx_lock = 0}, nentries = 0, size = 0, timestamp = 0, needs_wakeup = 0 '\0', system_map = 0 '\0', flags = 0 '\0', root = 0x0, pmap = 0xfffffe0018244c00, busy = 39559168} (kgdb) p *entry->object.sub_map->pmap $8 = {pm_mtx = {lock_object = {lo_name = 0x3e900000114
, lo_flags = 1001, lo_data = 1001, lo_witness = 0x3e900000003}, mtx_lock = 1001}, pm_pml4 = 0xfffffe0018e53c00, pm_pvchunk = {tqh_first = 0xfffffe0018e53c00, tqh_last = 0xffffffff811e74a0}, pm_active = {__bits = {-2198902153216}}, pm_stats = { resident_count = 0, wired_count = 0}, pm_root = 0x0} -- Andre > (Kostik, by the way, I would be happy to see attribute flags added to > the vm object to take the place of the type checks.) > > >> I am curious, what was the process which caused the panic ? >> >> diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c >> index e19750c..5b8ed23 100644 >> --- a/sys/vm/vm_object.c >> +++ b/sys/vm/vm_object.c >> @@ -1060,7 +1060,10 @@ shadowlookup: >> (tobject->flags & OBJ_ONEMAPPING) == 0) { >> goto unlock_tobject; >> } >> - } else if (tobject->type == OBJT_PHYS) >> + } else if (tobject->type == OBJT_PHYS || >> + tobject->type == OBJT_SG || >> + tobject->type == OBJT_MGTDEVICE || >> + tobject->type == OBJT_DEVICE) >> goto unlock_tobject; >> m = vm_page_lookup(tobject, tpindex); >> if (m == NULL && advise == MADV_WILLNEED) { > > _______________________________________________ > 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 Tue Nov 27 18:35:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 652F9E04; Tue, 27 Nov 2012 18:35:58 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id 318EE8FC12; Tue, 27 Nov 2012 18:35:57 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 5ECCB460160; Tue, 27 Nov 2012 12:27:44 -0600 (CST) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 5D3194600EF; Tue, 27 Nov 2012 12:27:44 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id g-ljMKzFMGdK; Tue, 27 Nov 2012 12:27:44 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 60AB446012F; Tue, 27 Nov 2012 12:27:43 -0600 (CST) Message-ID: <50B5061E.90805@rice.edu> Date: Tue, 27 Nov 2012 12:27:42 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> <50B4ED86.40308@rice.edu> <50B50196.4080804@freebsd.org> In-Reply-To: <50B50196.4080804@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 18:35:58 -0000 On 11/27/2012 12:08, Andre Oppermann wrote: > On 27.11.2012 17:42, Alan Cox wrote: >> On 11/27/2012 09:06, Konstantin Belousov wrote: >>> On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: >>>> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: >>>> Fri Nov 23 17:00:40 CET 2012 >>>> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >>>> >>>> #0 doadump (textdump=-2014022336) at pcpu.h:229 >>>> #1 0xffffffff8033e2d2 in db_fncall (dummy1=, >>>> dummy2=, >>>> dummy3=, dummy4=) >>>> at /usr/src/head/sys/ddb/db_command.c:578 >>>> #2 0xffffffff8033e074 in db_command (last_cmdp=, >>>> cmd_table=, dopager=1) at >>>> /usr/src/head/sys/ddb/db_command.c:449 >>>> #3 0xffffffff8033dd62 in db_command_loop () at >>>> /usr/src/head/sys/ddb/db_command.c:502 >>>> #4 0xffffffff80340690 in db_trap (type=, code=0) >>>> at /usr/src/head/sys/ddb/db_main.c:231 >>>> #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=>>> optimized >>>> out>) >>>> at /usr/src/head/sys/kern/subr_kdb.c:654 >>>> #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) >>>> at /usr/src/head/sys/amd64/amd64/trap.c:579 >>>> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 >>>> #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", >>>> msg=) >>>> at cpufunc.h:63 >>>> #9 0xffffffff8088086f in panic (fmt=) >>>> at /usr/src/head/sys/kern/kern_shutdown.c:628 >>>> #10 0xffffffff80adea4a in vm_object_madvise (object=>>> optimized out>, >>>> pindex=, end=8952, advise=>>> optimized out>) >>>> at /usr/src/head/sys/vm/vm_object.c:1101 >>>> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >>>> start=, >>>> end=, behav=5) at >>>> /usr/src/head/sys/vm/vm_map.c:2140 >>>> #12 0xffffffff80adbd8d in sys_madvise (td=, >>>> uap=) >>>> at /usr/src/head/sys/vm/vm_mmap.c:752 >>>> #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, >>>> traced=0) at subr_syscall.c:135 >>>> #14 0xffffffff80be689b in Xfast_syscall () at >>>> /tmp/exception-3nQ6Cf.s:329 >>>> #15 0x00000000016f3bfa in ?? () >>> I think this is an omission in the check for the object types. BTW, >>> this >>> pattern already repeats in several places, I thought about adding >>> either >>> new pager method, like boolean_t vm_pager_is_pageable(), or just a flag >>> fields to the struct vm_pager to classify the vm objects. >> >> >> A fictitious page should always have a non-zero wire count. In fact, it >> should always be one and never change. (See vm_page_unwire().) In >> vm_object_madvise(), there is a check against the page's wire count that >> precedes the KASSERT(). This check should prevent the KASSERT() from >> being reached for the various device-backed object types. So, something >> else has gone wrong here, or rather something has gone wrong elsewhere >> that caused the KASSERT() failure here. >> >> Andre, can we see the contents of the offending struct vm_page and also >> the struct vm_object to which the offending page belongs to? Also, are >> you running a kernel with any experimental zero-copy send support? > > No experimental zero-copy support, or anything else, just a stock > GENERIC kernel. > > (kgdb) frame 11 > #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, > start=, > end=, behav=5) at > /usr/src/head/sys/vm/vm_map.c:2140 > 2140 > vm_object_madvise(current->object.vm_object, pstart, > (kgdb) p *map > $1 = {header = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, > left = 0x0, right = 0x0, > start = 4096, end = 140737488355328, avail_ssize = 0, adj_free = > 0, max_free = 0, object = { > vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0, > protection = 0 '\0', > max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0 > '\0', wired_count = 0, > next_read = 0, cred = 0x0}, lock = {lock_object = { > lo_name = 0xffffffff80e66905 "vm map (user)", lo_flags = > 36896768, lo_data = 0, > lo_witness = 0xffffff80006c9700}, sx_lock = 17}, system_mtx = > {lock_object = { > lo_name = 0xffffffff80e668d7 "vm map (system)", lo_flags = > 21168128, lo_data = 0, > lo_witness = 0xffffff80006c9500}, mtx_lock = 4}, nentries = 32, > size = 64647168, > timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags = > 0 '\0', > root = 0xfffffe02560a6258, pmap = 0xfffffe00182602b8, busy = 0} > (kgdb) p* map->pmap > $6 = {pm_mtx = {lock_object = {lo_name = 0xffffffff80e66934 "pmap", > lo_flags = 21168128, > lo_data = 0, lo_witness = 0xffffff80006c9900}, mtx_lock = 4}, > pm_pml4 = 0xfffffe0256458000, > pm_pvchunk = {tqh_first = 0xfffffe0256142000, tqh_last = > 0xfffffe025644c008}, pm_active = { > __bits = {1}}, pm_stats = {resident_count = 12683, wired_count = 0}, > pm_root = 0xfffffe041289e040} > (kgdb) p* map->root > $7 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left = > 0xfffffe0018ed0708, > right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536, > avail_ssize = 0, > adj_free = 140703057047552, max_free = 140703057047552, object = { > vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570}, > offset = 1810432, eflags = 0, > protection = 3 '\003', max_protection = 7 '\a', inheritance = 1 > '\001', read_ahead = 15 '\017', > wired_count = 0, next_read = 0, cred = 0x0} > > (kgdb) p *current > $2 = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, left = > 0x0, right = 0x0, start = 4096, > end = 140737488355328, avail_ssize = 0, adj_free = 0, max_free = 0, > object = {vm_object = 0x0, > sub_map = 0x0}, offset = 0, eflags = 0, protection = 0 '\0', > max_protection = 0 '\0', > inheritance = 0 '\0', read_ahead = 0 '\0', wired_count = 0, > next_read = 0, cred = 0x0} > > (kgdb) p *entry > $3 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left = > 0xfffffe0018ed0708, > right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536, > avail_ssize = 0, > adj_free = 140703057047552, max_free = 140703057047552, object = { > vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570}, > offset = 1810432, eflags = 0, > protection = 3 '\003', max_protection = 7 '\a', inheritance = 1 > '\001', read_ahead = 15 '\017', > wired_count = 0, next_read = 0, cred = 0x0} The following tells us that this is an OBJT_DEFAULT (i.e., anonymous) memory object. Such objects should never contain fictitious pages. Can you please print the contents of the offending struct vm_page using the address from the panic message? > (kgdb) p *entry->object.vm_object > $4 = {mtx = {lock_object = {lo_name = 0xffffffff80e66913 "vm object", > lo_flags = 21168128, > lo_data = 0, lo_witness = 0xffffff80006cdd00}, mtx_lock = > 18446741875091243008}, > object_list = {tqe_next = 0xfffffe0248ffb910, tqe_prev = > 0xfffffe025618e020}, shadow_head = { > lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0x0}, > memq = { > tqh_first = 0xfffffe0413891880, tqh_last = 0xfffffe0413a3a570}, > root = 0xfffffe0413c58630, > size = 9658, generation = 1, ref_count = 1, shadow_count = 0, > memattr = 6 '\006', type = 0 '\0', > flags = 12288, pg_color = 7750, paging_in_progress = 0, > resident_page_count = 7650, > backing_object = 0x0, backing_object_offset = 0, pager_object_list = > {tqe_next = 0x0, > tqe_prev = 0x0}, rvq = {lh_first = 0xfffffe0400ff07c0}, cache = > 0x0, handle = 0x0, un_pager = { > vnp = {vnp_size = 0, writemappings = 0}, devp = {devp_pglist = > {tqh_first = 0x0, > tqh_last = 0x0}, ops = 0x0}, sgp = {sgp_pglist = {tqh_first = > 0x0, tqh_last = 0x0}}, > swp = {swp_bcount = 0}}, cred = 0xfffffe0018244c00, charge = > 39559168} > (kgdb) p *entry->object.sub_map > $5 = {header = {prev = 0xffffffff80e66913, next = 0x1430000, left = > 0xffffff80006cdd00, > right = 0xfffffe0018230000, start = 18446741884500949264, end = > 18446741884720701472, > avail_ssize = 0, adj_free = 0, max_free = 0, object = {vm_object = > 0xfffffe0413891880, > sub_map = 0xfffffe0413891880}, offset = -2181513894544, eflags = > 331712048, > protection = 4 '\004', max_protection = 254 'þ', inheritance = -1 > 'ÿ', read_ahead = 255 'ÿ', > wired_count = 9658, next_read = 4294967297, cred = > 0x3000000600000000}, lock = {lock_object = { > lo_name = 0x1e46
, lo_flags = > 7650, lo_data = 0, > lo_witness = 0x0}, sx_lock = 0}, system_mtx = {lock_object = > {lo_name = 0x0, lo_flags = 0, > lo_data = 0, lo_witness = 0xfffffe0400ff07c0}, mtx_lock = 0}, > nentries = 0, size = 0, > timestamp = 0, needs_wakeup = 0 '\0', system_map = 0 '\0', flags = 0 > '\0', root = 0x0, > pmap = 0xfffffe0018244c00, busy = 39559168} > (kgdb) p *entry->object.sub_map->pmap > $8 = {pm_mtx = {lock_object = {lo_name = 0x3e900000114
0x3e900000114 out of bounds>, > lo_flags = 1001, lo_data = 1001, lo_witness = 0x3e900000003}, > mtx_lock = 1001}, > pm_pml4 = 0xfffffe0018e53c00, pm_pvchunk = {tqh_first = > 0xfffffe0018e53c00, > tqh_last = 0xffffffff811e74a0}, pm_active = {__bits = > {-2198902153216}}, pm_stats = { > resident_count = 0, wired_count = 0}, pm_root = 0x0} > From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 18:41:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0422461 for ; Tue, 27 Nov 2012 18:41:56 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id F0E2F8FC13 for ; Tue, 27 Nov 2012 18:41:54 +0000 (UTC) Received: (qmail 36190 invoked from network); 27 Nov 2012 20:13:30 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Nov 2012 20:13:30 -0000 Message-ID: <50B509CC.5090508@freebsd.org> Date: Tue, 27 Nov 2012 19:43:24 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Alan Cox Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> <50B4ED86.40308@rice.edu> <50B50196.4080804@freebsd.org> <50B5061E.90805@rice.edu> In-Reply-To: <50B5061E.90805@rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 18:41:56 -0000 On 27.11.2012 19:27, Alan Cox wrote: > On 11/27/2012 12:08, Andre Oppermann wrote: >> On 27.11.2012 17:42, Alan Cox wrote: >>> On 11/27/2012 09:06, Konstantin Belousov wrote: >>>> On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: >>>>> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: >>>>> Fri Nov 23 17:00:40 CET 2012 >>>>> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >>>>> >>>>> #0 doadump (textdump=-2014022336) at pcpu.h:229 >>>>> #1 0xffffffff8033e2d2 in db_fncall (dummy1=, >>>>> dummy2=, >>>>> dummy3=, dummy4=) >>>>> at /usr/src/head/sys/ddb/db_command.c:578 >>>>> #2 0xffffffff8033e074 in db_command (last_cmdp=, >>>>> cmd_table=, dopager=1) at >>>>> /usr/src/head/sys/ddb/db_command.c:449 >>>>> #3 0xffffffff8033dd62 in db_command_loop () at >>>>> /usr/src/head/sys/ddb/db_command.c:502 >>>>> #4 0xffffffff80340690 in db_trap (type=, code=0) >>>>> at /usr/src/head/sys/ddb/db_main.c:231 >>>>> #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=>>>> optimized >>>>> out>) >>>>> at /usr/src/head/sys/kern/subr_kdb.c:654 >>>>> #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) >>>>> at /usr/src/head/sys/amd64/amd64/trap.c:579 >>>>> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 >>>>> #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", >>>>> msg=) >>>>> at cpufunc.h:63 >>>>> #9 0xffffffff8088086f in panic (fmt=) >>>>> at /usr/src/head/sys/kern/kern_shutdown.c:628 >>>>> #10 0xffffffff80adea4a in vm_object_madvise (object=>>>> optimized out>, >>>>> pindex=, end=8952, advise=>>>> optimized out>) >>>>> at /usr/src/head/sys/vm/vm_object.c:1101 >>>>> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >>>>> start=, >>>>> end=, behav=5) at >>>>> /usr/src/head/sys/vm/vm_map.c:2140 >>>>> #12 0xffffffff80adbd8d in sys_madvise (td=, >>>>> uap=) >>>>> at /usr/src/head/sys/vm/vm_mmap.c:752 >>>>> #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, >>>>> traced=0) at subr_syscall.c:135 >>>>> #14 0xffffffff80be689b in Xfast_syscall () at >>>>> /tmp/exception-3nQ6Cf.s:329 >>>>> #15 0x00000000016f3bfa in ?? () >>>> I think this is an omission in the check for the object types. BTW, >>>> this >>>> pattern already repeats in several places, I thought about adding >>>> either >>>> new pager method, like boolean_t vm_pager_is_pageable(), or just a flag >>>> fields to the struct vm_pager to classify the vm objects. >>> >>> >>> A fictitious page should always have a non-zero wire count. In fact, it >>> should always be one and never change. (See vm_page_unwire().) In >>> vm_object_madvise(), there is a check against the page's wire count that >>> precedes the KASSERT(). This check should prevent the KASSERT() from >>> being reached for the various device-backed object types. So, something >>> else has gone wrong here, or rather something has gone wrong elsewhere >>> that caused the KASSERT() failure here. >>> >>> Andre, can we see the contents of the offending struct vm_page and also >>> the struct vm_object to which the offending page belongs to? Also, are >>> you running a kernel with any experimental zero-copy send support? >> >> No experimental zero-copy support, or anything else, just a stock >> GENERIC kernel. >> >> (kgdb) frame 11 >> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >> start=, >> end=, behav=5) at >> /usr/src/head/sys/vm/vm_map.c:2140 >> 2140 >> vm_object_madvise(current->object.vm_object, pstart, >> (kgdb) p *map >> $1 = {header = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, >> left = 0x0, right = 0x0, >> start = 4096, end = 140737488355328, avail_ssize = 0, adj_free = >> 0, max_free = 0, object = { >> vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0, >> protection = 0 '\0', >> max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0 >> '\0', wired_count = 0, >> next_read = 0, cred = 0x0}, lock = {lock_object = { >> lo_name = 0xffffffff80e66905 "vm map (user)", lo_flags = >> 36896768, lo_data = 0, >> lo_witness = 0xffffff80006c9700}, sx_lock = 17}, system_mtx = >> {lock_object = { >> lo_name = 0xffffffff80e668d7 "vm map (system)", lo_flags = >> 21168128, lo_data = 0, >> lo_witness = 0xffffff80006c9500}, mtx_lock = 4}, nentries = 32, >> size = 64647168, >> timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags = >> 0 '\0', >> root = 0xfffffe02560a6258, pmap = 0xfffffe00182602b8, busy = 0} >> (kgdb) p* map->pmap >> $6 = {pm_mtx = {lock_object = {lo_name = 0xffffffff80e66934 "pmap", >> lo_flags = 21168128, >> lo_data = 0, lo_witness = 0xffffff80006c9900}, mtx_lock = 4}, >> pm_pml4 = 0xfffffe0256458000, >> pm_pvchunk = {tqh_first = 0xfffffe0256142000, tqh_last = >> 0xfffffe025644c008}, pm_active = { >> __bits = {1}}, pm_stats = {resident_count = 12683, wired_count = 0}, >> pm_root = 0xfffffe041289e040} >> (kgdb) p* map->root >> $7 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left = >> 0xfffffe0018ed0708, >> right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536, >> avail_ssize = 0, >> adj_free = 140703057047552, max_free = 140703057047552, object = { >> vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570}, >> offset = 1810432, eflags = 0, >> protection = 3 '\003', max_protection = 7 '\a', inheritance = 1 >> '\001', read_ahead = 15 '\017', >> wired_count = 0, next_read = 0, cred = 0x0} >> >> (kgdb) p *current >> $2 = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, left = >> 0x0, right = 0x0, start = 4096, >> end = 140737488355328, avail_ssize = 0, adj_free = 0, max_free = 0, >> object = {vm_object = 0x0, >> sub_map = 0x0}, offset = 0, eflags = 0, protection = 0 '\0', >> max_protection = 0 '\0', >> inheritance = 0 '\0', read_ahead = 0 '\0', wired_count = 0, >> next_read = 0, cred = 0x0} >> >> (kgdb) p *entry >> $3 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left = >> 0xfffffe0018ed0708, >> right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536, >> avail_ssize = 0, >> adj_free = 140703057047552, max_free = 140703057047552, object = { >> vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570}, >> offset = 1810432, eflags = 0, >> protection = 3 '\003', max_protection = 7 '\a', inheritance = 1 >> '\001', read_ahead = 15 '\017', >> wired_count = 0, next_read = 0, cred = 0x0} > > > The following tells us that this is an OBJT_DEFAULT (i.e., anonymous) > memory object. Such objects should never contain fictitious pages. Can > you please print the contents of the offending struct vm_page using the > address from the panic message? (kgdb) p (struct vm_page)*0xfffffe0413c58630 $12 = {pageq = {tqe_next = 0xfffffe04127fbcc8, tqe_prev = 0xfffffe0412658358}, listq = { tqe_next = 0xfffffe0413c586a8, tqe_prev = 0xfffffe0413c585c8}, left = 0xfffffe0413c585b8, right = 0xfffffe0413c586a8, object = 0xfffffe0256484570, pindex = 8868, phys_addr = 10744668160, md = {pv_list = {tqh_first = 0xfffffe025654d9a0, tqh_last = 0xfe025654d9a8}, pat_mode = 6}, queue = 1 '\001', segind = 4 '\004', hold_count = 0, order = 13 '\r', pool = 0 '\0', cow = 0, wire_count = 0, aflags = 1 '\001', oflags = 0 '\0', flags = 65535, act_count = 5 '\005', busy = 0 '\0', valid = 255 'ÿ', dirty = 0 '\0'} -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 19:16:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67828EA5; Tue, 27 Nov 2012 19:16:38 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id 31E038FC14; Tue, 27 Nov 2012 19:16:37 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 82D3C46014E; Tue, 27 Nov 2012 13:16:37 -0600 (CST) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 808A446012F; Tue, 27 Nov 2012 13:16:37 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 3TbgQ326k36w; Tue, 27 Nov 2012 13:16:37 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id DF0B546011D; Tue, 27 Nov 2012 13:16:36 -0600 (CST) Message-ID: <50B51194.2020209@rice.edu> Date: Tue, 27 Nov 2012 13:16:36 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> <50B4ED86.40308@rice.edu> <50B50196.4080804@freebsd.org> <50B5061E.90805@rice.edu> <50B509CC.5090508@freebsd.org> In-Reply-To: <50B509CC.5090508@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 19:16:38 -0000 On 11/27/2012 12:43, Andre Oppermann wrote: > On 27.11.2012 19:27, Alan Cox wrote: >> On 11/27/2012 12:08, Andre Oppermann wrote: >>> On 27.11.2012 17:42, Alan Cox wrote: >>>> On 11/27/2012 09:06, Konstantin Belousov wrote: >>>>> On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: >>>>>> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: >>>>>> Fri Nov 23 17:00:40 CET 2012 >>>>>> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >>>>>> >>>>>> #0 doadump (textdump=-2014022336) at pcpu.h:229 >>>>>> #1 0xffffffff8033e2d2 in db_fncall (dummy1=, >>>>>> dummy2=, >>>>>> dummy3=, dummy4=) >>>>>> at /usr/src/head/sys/ddb/db_command.c:578 >>>>>> #2 0xffffffff8033e074 in db_command (last_cmdp=>>>>> out>, >>>>>> cmd_table=, dopager=1) at >>>>>> /usr/src/head/sys/ddb/db_command.c:449 >>>>>> #3 0xffffffff8033dd62 in db_command_loop () at >>>>>> /usr/src/head/sys/ddb/db_command.c:502 >>>>>> #4 0xffffffff80340690 in db_trap (type=, >>>>>> code=0) >>>>>> at /usr/src/head/sys/ddb/db_main.c:231 >>>>>> #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=>>>>> optimized >>>>>> out>) >>>>>> at /usr/src/head/sys/kern/subr_kdb.c:654 >>>>>> #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) >>>>>> at /usr/src/head/sys/amd64/amd64/trap.c:579 >>>>>> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 >>>>>> #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", >>>>>> msg=) >>>>>> at cpufunc.h:63 >>>>>> #9 0xffffffff8088086f in panic (fmt=) >>>>>> at /usr/src/head/sys/kern/kern_shutdown.c:628 >>>>>> #10 0xffffffff80adea4a in vm_object_madvise (object=>>>>> optimized out>, >>>>>> pindex=, end=8952, advise=>>>>> optimized out>) >>>>>> at /usr/src/head/sys/vm/vm_object.c:1101 >>>>>> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >>>>>> start=, >>>>>> end=, behav=5) at >>>>>> /usr/src/head/sys/vm/vm_map.c:2140 >>>>>> #12 0xffffffff80adbd8d in sys_madvise (td=, >>>>>> uap=) >>>>>> at /usr/src/head/sys/vm/vm_mmap.c:752 >>>>>> #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, >>>>>> traced=0) at subr_syscall.c:135 >>>>>> #14 0xffffffff80be689b in Xfast_syscall () at >>>>>> /tmp/exception-3nQ6Cf.s:329 >>>>>> #15 0x00000000016f3bfa in ?? () >>>>> I think this is an omission in the check for the object types. BTW, >>>>> this >>>>> pattern already repeats in several places, I thought about adding >>>>> either >>>>> new pager method, like boolean_t vm_pager_is_pageable(), or just a >>>>> flag >>>>> fields to the struct vm_pager to classify the vm objects. >>>> >>>> >>>> A fictitious page should always have a non-zero wire count. In >>>> fact, it >>>> should always be one and never change. (See vm_page_unwire().) In >>>> vm_object_madvise(), there is a check against the page's wire count >>>> that >>>> precedes the KASSERT(). This check should prevent the KASSERT() from >>>> being reached for the various device-backed object types. So, >>>> something >>>> else has gone wrong here, or rather something has gone wrong elsewhere >>>> that caused the KASSERT() failure here. >>>> >>>> Andre, can we see the contents of the offending struct vm_page and >>>> also >>>> the struct vm_object to which the offending page belongs to? Also, >>>> are >>>> you running a kernel with any experimental zero-copy send support? >>> >>> No experimental zero-copy support, or anything else, just a stock >>> GENERIC kernel. >>> >>> (kgdb) frame 11 >>> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >>> start=, >>> end=, behav=5) at >>> /usr/src/head/sys/vm/vm_map.c:2140 >>> 2140 >>> vm_object_madvise(current->object.vm_object, pstart, >>> (kgdb) p *map >>> $1 = {header = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, >>> left = 0x0, right = 0x0, >>> start = 4096, end = 140737488355328, avail_ssize = 0, adj_free = >>> 0, max_free = 0, object = { >>> vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0, >>> protection = 0 '\0', >>> max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0 >>> '\0', wired_count = 0, >>> next_read = 0, cred = 0x0}, lock = {lock_object = { >>> lo_name = 0xffffffff80e66905 "vm map (user)", lo_flags = >>> 36896768, lo_data = 0, >>> lo_witness = 0xffffff80006c9700}, sx_lock = 17}, system_mtx = >>> {lock_object = { >>> lo_name = 0xffffffff80e668d7 "vm map (system)", lo_flags = >>> 21168128, lo_data = 0, >>> lo_witness = 0xffffff80006c9500}, mtx_lock = 4}, nentries = 32, >>> size = 64647168, >>> timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags = >>> 0 '\0', >>> root = 0xfffffe02560a6258, pmap = 0xfffffe00182602b8, busy = 0} >>> (kgdb) p* map->pmap >>> $6 = {pm_mtx = {lock_object = {lo_name = 0xffffffff80e66934 "pmap", >>> lo_flags = 21168128, >>> lo_data = 0, lo_witness = 0xffffff80006c9900}, mtx_lock = 4}, >>> pm_pml4 = 0xfffffe0256458000, >>> pm_pvchunk = {tqh_first = 0xfffffe0256142000, tqh_last = >>> 0xfffffe025644c008}, pm_active = { >>> __bits = {1}}, pm_stats = {resident_count = 12683, wired_count >>> = 0}, >>> pm_root = 0xfffffe041289e040} >>> (kgdb) p* map->root >>> $7 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left = >>> 0xfffffe0018ed0708, >>> right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536, >>> avail_ssize = 0, >>> adj_free = 140703057047552, max_free = 140703057047552, object = { >>> vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570}, >>> offset = 1810432, eflags = 0, >>> protection = 3 '\003', max_protection = 7 '\a', inheritance = 1 >>> '\001', read_ahead = 15 '\017', >>> wired_count = 0, next_read = 0, cred = 0x0} >>> >>> (kgdb) p *current >>> $2 = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, left = >>> 0x0, right = 0x0, start = 4096, >>> end = 140737488355328, avail_ssize = 0, adj_free = 0, max_free = 0, >>> object = {vm_object = 0x0, >>> sub_map = 0x0}, offset = 0, eflags = 0, protection = 0 '\0', >>> max_protection = 0 '\0', >>> inheritance = 0 '\0', read_ahead = 0 '\0', wired_count = 0, >>> next_read = 0, cred = 0x0} >>> >>> (kgdb) p *entry >>> $3 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left = >>> 0xfffffe0018ed0708, >>> right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536, >>> avail_ssize = 0, >>> adj_free = 140703057047552, max_free = 140703057047552, object = { >>> vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570}, >>> offset = 1810432, eflags = 0, >>> protection = 3 '\003', max_protection = 7 '\a', inheritance = 1 >>> '\001', read_ahead = 15 '\017', >>> wired_count = 0, next_read = 0, cred = 0x0} >> >> >> The following tells us that this is an OBJT_DEFAULT (i.e., anonymous) >> memory object. Such objects should never contain fictitious pages. Can >> you please print the contents of the offending struct vm_page using the >> address from the panic message? > > (kgdb) p (struct vm_page)*0xfffffe0413c58630 > $12 = {pageq = {tqe_next = 0xfffffe04127fbcc8, tqe_prev = > 0xfffffe0412658358}, listq = { > tqe_next = 0xfffffe0413c586a8, tqe_prev = 0xfffffe0413c585c8}, > left = 0xfffffe0413c585b8, > right = 0xfffffe0413c586a8, object = 0xfffffe0256484570, pindex = > 8868, phys_addr = 10744668160, > md = {pv_list = {tqh_first = 0xfffffe025654d9a0, tqh_last = > 0xfe025654d9a8}, pat_mode = 6}, > queue = 1 '\001', segind = 4 '\004', hold_count = 0, order = 13 > '\r', pool = 0 '\0', cow = 0, > wire_count = 0, aflags = 1 '\001', oflags = 0 '\0', flags = 65535, > act_count = 5 '\005', > busy = 0 '\0', valid = 255 'ÿ', dirty = 0 '\0'} > Except for the value of the "flags" field, this looks like a perfectly ordinary page of physical memory. In other words, this is not a fictitious page. Moreover, there is nothing inconsistent about the other fields. A "flags" field value of 65535 should be an impossibility. We only define flags for 9 of the 16 bits in the field. Is there any chance you're loading and using a kernel module that is older than your kernel? From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 19:35:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C0C6F5E for ; Tue, 27 Nov 2012 19:35:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B2CF88FC14 for ; Tue, 27 Nov 2012 19:35:15 +0000 (UTC) Received: (qmail 36445 invoked from network); 27 Nov 2012 21:06:50 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Nov 2012 21:06:50 -0000 Message-ID: <50B5164C.9040206@freebsd.org> Date: Tue, 27 Nov 2012 20:36:44 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Alan Cox Subject: Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious References: <50B4A374.5040705@freebsd.org> <20121127150625.GJ3013@kib.kiev.ua> <50B4ED86.40308@rice.edu> <50B50196.4080804@freebsd.org> <50B5061E.90805@rice.edu> <50B509CC.5090508@freebsd.org> <50B51194.2020209@rice.edu> In-Reply-To: <50B51194.2020209@rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Nov 2012 19:35:16 -0000 On 27.11.2012 20:16, Alan Cox wrote: > On 11/27/2012 12:43, Andre Oppermann wrote: >> On 27.11.2012 19:27, Alan Cox wrote: >>> On 11/27/2012 12:08, Andre Oppermann wrote: >>>> On 27.11.2012 17:42, Alan Cox wrote: >>>>> On 11/27/2012 09:06, Konstantin Belousov wrote: >>>>>> On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: >>>>>>> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0: >>>>>>> Fri Nov 23 17:00:40 CET 2012 >>>>>>> aaa@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64 >>>>>>> >>>>>>> #0 doadump (textdump=-2014022336) at pcpu.h:229 >>>>>>> #1 0xffffffff8033e2d2 in db_fncall (dummy1=, >>>>>>> dummy2=, >>>>>>> dummy3=, dummy4=) >>>>>>> at /usr/src/head/sys/ddb/db_command.c:578 >>>>>>> #2 0xffffffff8033e074 in db_command (last_cmdp=>>>>>> out>, >>>>>>> cmd_table=, dopager=1) at >>>>>>> /usr/src/head/sys/ddb/db_command.c:449 >>>>>>> #3 0xffffffff8033dd62 in db_command_loop () at >>>>>>> /usr/src/head/sys/ddb/db_command.c:502 >>>>>>> #4 0xffffffff80340690 in db_trap (type=, >>>>>>> code=0) >>>>>>> at /usr/src/head/sys/ddb/db_main.c:231 >>>>>>> #5 0xffffffff808b375e in kdb_trap (type=3, code=0, tf=>>>>>> optimized >>>>>>> out>) >>>>>>> at /usr/src/head/sys/kern/subr_kdb.c:654 >>>>>>> #6 0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0) >>>>>>> at /usr/src/head/sys/amd64/amd64/trap.c:579 >>>>>>> #7 0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179 >>>>>>> #8 0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic", >>>>>>> msg=) >>>>>>> at cpufunc.h:63 >>>>>>> #9 0xffffffff8088086f in panic (fmt=) >>>>>>> at /usr/src/head/sys/kern/kern_shutdown.c:628 >>>>>>> #10 0xffffffff80adea4a in vm_object_madvise (object=>>>>>> optimized out>, >>>>>>> pindex=, end=8952, advise=>>>>>> optimized out>) >>>>>>> at /usr/src/head/sys/vm/vm_object.c:1101 >>>>>>> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >>>>>>> start=, >>>>>>> end=, behav=5) at >>>>>>> /usr/src/head/sys/vm/vm_map.c:2140 >>>>>>> #12 0xffffffff80adbd8d in sys_madvise (td=, >>>>>>> uap=) >>>>>>> at /usr/src/head/sys/vm/vm_mmap.c:752 >>>>>>> #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000, >>>>>>> traced=0) at subr_syscall.c:135 >>>>>>> #14 0xffffffff80be689b in Xfast_syscall () at >>>>>>> /tmp/exception-3nQ6Cf.s:329 >>>>>>> #15 0x00000000016f3bfa in ?? () >>>>>> I think this is an omission in the check for the object types. BTW, >>>>>> this >>>>>> pattern already repeats in several places, I thought about adding >>>>>> either >>>>>> new pager method, like boolean_t vm_pager_is_pageable(), or just a >>>>>> flag >>>>>> fields to the struct vm_pager to classify the vm objects. >>>>> >>>>> >>>>> A fictitious page should always have a non-zero wire count. In >>>>> fact, it >>>>> should always be one and never change. (See vm_page_unwire().) In >>>>> vm_object_madvise(), there is a check against the page's wire count >>>>> that >>>>> precedes the KASSERT(). This check should prevent the KASSERT() from >>>>> being reached for the various device-backed object types. So, >>>>> something >>>>> else has gone wrong here, or rather something has gone wrong elsewhere >>>>> that caused the KASSERT() failure here. >>>>> >>>>> Andre, can we see the contents of the offending struct vm_page and >>>>> also >>>>> the struct vm_object to which the offending page belongs to? Also, >>>>> are >>>>> you running a kernel with any experimental zero-copy send support? >>>> >>>> No experimental zero-copy support, or anything else, just a stock >>>> GENERIC kernel. >>>> >>>> (kgdb) frame 11 >>>> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188, >>>> start=, >>>> end=, behav=5) at >>>> /usr/src/head/sys/vm/vm_map.c:2140 >>>> 2140 >>>> vm_object_madvise(current->object.vm_object, pstart, >>>> (kgdb) p *map >>>> $1 = {header = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, >>>> left = 0x0, right = 0x0, >>>> start = 4096, end = 140737488355328, avail_ssize = 0, adj_free = >>>> 0, max_free = 0, object = { >>>> vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0, >>>> protection = 0 '\0', >>>> max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0 >>>> '\0', wired_count = 0, >>>> next_read = 0, cred = 0x0}, lock = {lock_object = { >>>> lo_name = 0xffffffff80e66905 "vm map (user)", lo_flags = >>>> 36896768, lo_data = 0, >>>> lo_witness = 0xffffff80006c9700}, sx_lock = 17}, system_mtx = >>>> {lock_object = { >>>> lo_name = 0xffffffff80e668d7 "vm map (system)", lo_flags = >>>> 21168128, lo_data = 0, >>>> lo_witness = 0xffffff80006c9500}, mtx_lock = 4}, nentries = 32, >>>> size = 64647168, >>>> timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags = >>>> 0 '\0', >>>> root = 0xfffffe02560a6258, pmap = 0xfffffe00182602b8, busy = 0} >>>> (kgdb) p* map->pmap >>>> $6 = {pm_mtx = {lock_object = {lo_name = 0xffffffff80e66934 "pmap", >>>> lo_flags = 21168128, >>>> lo_data = 0, lo_witness = 0xffffff80006c9900}, mtx_lock = 4}, >>>> pm_pml4 = 0xfffffe0256458000, >>>> pm_pvchunk = {tqh_first = 0xfffffe0256142000, tqh_last = >>>> 0xfffffe025644c008}, pm_active = { >>>> __bits = {1}}, pm_stats = {resident_count = 12683, wired_count >>>> = 0}, >>>> pm_root = 0xfffffe041289e040} >>>> (kgdb) p* map->root >>>> $7 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left = >>>> 0xfffffe0018ed0708, >>>> right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536, >>>> avail_ssize = 0, >>>> adj_free = 140703057047552, max_free = 140703057047552, object = { >>>> vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570}, >>>> offset = 1810432, eflags = 0, >>>> protection = 3 '\003', max_protection = 7 '\a', inheritance = 1 >>>> '\001', read_ahead = 15 '\017', >>>> wired_count = 0, next_read = 0, cred = 0x0} >>>> >>>> (kgdb) p *current >>>> $2 = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, left = >>>> 0x0, right = 0x0, start = 4096, >>>> end = 140737488355328, avail_ssize = 0, adj_free = 0, max_free = 0, >>>> object = {vm_object = 0x0, >>>> sub_map = 0x0}, offset = 0, eflags = 0, protection = 0 '\0', >>>> max_protection = 0 '\0', >>>> inheritance = 0 '\0', read_ahead = 0 '\0', wired_count = 0, >>>> next_read = 0, cred = 0x0} >>>> >>>> (kgdb) p *entry >>>> $3 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left = >>>> 0xfffffe0018ed0708, >>>> right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536, >>>> avail_ssize = 0, >>>> adj_free = 140703057047552, max_free = 140703057047552, object = { >>>> vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570}, >>>> offset = 1810432, eflags = 0, >>>> protection = 3 '\003', max_protection = 7 '\a', inheritance = 1 >>>> '\001', read_ahead = 15 '\017', >>>> wired_count = 0, next_read = 0, cred = 0x0} >>> >>> >>> The following tells us that this is an OBJT_DEFAULT (i.e., anonymous) >>> memory object. Such objects should never contain fictitious pages. Can >>> you please print the contents of the offending struct vm_page using the >>> address from the panic message? >> >> (kgdb) p (struct vm_page)*0xfffffe0413c58630 >> $12 = {pageq = {tqe_next = 0xfffffe04127fbcc8, tqe_prev = >> 0xfffffe0412658358}, listq = { >> tqe_next = 0xfffffe0413c586a8, tqe_prev = 0xfffffe0413c585c8}, >> left = 0xfffffe0413c585b8, >> right = 0xfffffe0413c586a8, object = 0xfffffe0256484570, pindex = >> 8868, phys_addr = 10744668160, >> md = {pv_list = {tqh_first = 0xfffffe025654d9a0, tqh_last = >> 0xfe025654d9a8}, pat_mode = 6}, >> queue = 1 '\001', segind = 4 '\004', hold_count = 0, order = 13 >> '\r', pool = 0 '\0', cow = 0, >> wire_count = 0, aflags = 1 '\001', oflags = 0 '\0', flags = 65535, >> act_count = 5 '\005', >> busy = 0 '\0', valid = 255 'ÿ', dirty = 0 '\0'} >> > > Except for the value of the "flags" field, this looks like a perfectly > ordinary page of physical memory. In other words, this is not a > fictitious page. Moreover, there is nothing inconsistent about the > other fields. > > A "flags" field value of 65535 should be an impossibility. We only > define flags for 9 of the 16 bits in the field. > > Is there any chance you're loading and using a kernel module that is > older than your kernel? No kernel modules loaded at all. It's the first time ever I got this panic. Maybe it's just a Heisenbug. IIRC I don't have ECC in this machine. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 23:37:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45A5BDE8; Tue, 27 Nov 2012 23:37:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 09FF48FC0C; Tue, 27 Nov 2012 23:37: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 qARNb5Le074776; Tue, 27 Nov 2012 18:37: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 qARNb5VT074761; Tue, 27 Nov 2012 23:37:05 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 27 Nov 2012 23:37:05 GMT Message-Id: <201211272337.qARNb5VT074761@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 23:37:07 -0000 TB --- 2012-11-27 22:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-27 22: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 --- 2012-11-27 22:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-11-27 22:20:00 - cleaning the object tree TB --- 2012-11-27 22:24:37 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-27 22:24:37 - cd /tinderbox/HEAD/arm/arm TB --- 2012-11-27 22:24:37 - /usr/local/bin/svn cleanup /src TB --- 2012-11-27 22:25:20 - /usr/local/bin/svn update /src TB --- 2012-11-27 22:25:26 - At svn revision 243636 TB --- 2012-11-27 22:25:27 - building world TB --- 2012-11-27 22:25:27 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 22:25:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 22:25:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 22:25:27 - SRCCONF=/dev/null TB --- 2012-11-27 22:25:27 - TARGET=arm TB --- 2012-11-27 22:25:27 - TARGET_ARCH=arm TB --- 2012-11-27 22:25:27 - TZ=UTC TB --- 2012-11-27 22:25:27 - __MAKE_CONF=/dev/null TB --- 2012-11-27 22:25:27 - cd /src TB --- 2012-11-27 22:25:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 27 22:25:31 UTC 2012 >>> 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 27 23:23:27 UTC 2012 TB --- 2012-11-27 23:23:27 - generating LINT kernel config TB --- 2012-11-27 23:23:27 - cd /src/sys/arm/conf TB --- 2012-11-27 23:23:27 - /usr/bin/make -B LINT TB --- 2012-11-27 23:23:27 - cd /src/sys/arm/conf TB --- 2012-11-27 23:23:27 - /usr/sbin/config -m LINT TB --- 2012-11-27 23:23:27 - building LINT kernel TB --- 2012-11-27 23:23:27 - CROSS_BUILD_TESTING=YES TB --- 2012-11-27 23:23:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-27 23:23:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-27 23:23:27 - SRCCONF=/dev/null TB --- 2012-11-27 23:23:27 - TARGET=arm TB --- 2012-11-27 23:23:27 - TARGET_ARCH=arm TB --- 2012-11-27 23:23:27 - TZ=UTC TB --- 2012-11-27 23:23:27 - __MAKE_CONF=/dev/null TB --- 2012-11-27 23:23:27 - cd /src TB --- 2012-11-27 23:23:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 27 23:23:27 UTC 2012 >>> 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 [...] uart_bus_fdt.o:uart_bus_fdt.c:(.text+0x0): first defined here uart_cpu_pxa.o: In function `uart_cpu_getdev': uart_cpu_pxa.c:(.text+0x18): multiple definition of `uart_cpu_getdev' uart_bus_fdt.o:uart_bus_fdt.c:(.text+0x264): first defined here uart_cpu_pxa.o:(.bss+0x4): multiple definition of `uart_bus_space_mem' uart_bus_fdt.o:(.bss+0x4): first defined here uart_cpu_pxa.o:(.bss+0x0): multiple definition of `uart_bus_space_io' uart_bus_fdt.o:(.bss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-27 23:37:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-27 23:37:05 - ERROR: failed to build LINT kernel TB --- 2012-11-27 23:37:05 - 3201.64 user 655.94 system 4625.28 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 28 04:40:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AFB5E32 for ; Wed, 28 Nov 2012 04:40:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 8C38F8FC12 for ; Wed, 28 Nov 2012 04:40:29 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so4431955wib.1 for ; Tue, 27 Nov 2012 20:40:28 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=zjnkv1+I+yKOSbkmIptoXpT5lwPponteRK4FzKQpaMs=; b=kQNkfP7vPgeFaPCsG2zbgaA7ybfoRgl/c4g+GGo4gxzcJMsU8c4TR6hyBcnDjPadrG ye80XfTMI6BXrz15wsVIwLSzcXHGVXjjwAC2wOEoBJIMQt+SZYD3yEj/H3X+XfGrrSHv bTTf2I4C0afPavYZ6Nh/nK69dKnC7+A6iKuTngxTmvM3QPPa6ZOLe6VlrvauU5/zk9GX P7sisA45gIT1XP4Xh7ruxJ/JBHcKVk3eNItMBS6UM41lVfepeYCrLrnELbfLIV++x5Xe CUujJtqwL+yEbdVXoiWGwYMxOtRClLKhGF9iF0fYHneVRV3e0YGRtEWxdJl/ML4JEQDY z/sQ== MIME-Version: 1.0 Received: by 10.180.78.1 with SMTP id x1mr26334243wiw.17.1354077628154; Tue, 27 Nov 2012 20:40:28 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 27 Nov 2012 20:40:28 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 20:40:28 -0800 X-Google-Sender-Auth: WaZ4D8XwX_Wfz76dO3evyC85WVU Message-ID: Subject: Re: Is cross-world building broken? From: Adrian Chadd To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Nov 2012 04:40:30 -0000 .. so, Nathan Whitehorn discovered that DESTDIR should be specified in environment, not on the command line. He's also got a patch to address this: http://www.pastebin.ca/2257413 So - what's the correct place to put each of the build options? Is this documented somewhere? Adrian From owner-freebsd-current@FreeBSD.ORG Wed Nov 28 09:36:09 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E051E09; Wed, 28 Nov 2012 09:36:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CF5D38FC12; Wed, 28 Nov 2012 09:36:08 +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 qAS9a1kM035736; Wed, 28 Nov 2012 04:36: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 qAS9a1au035725; Wed, 28 Nov 2012 09:36:01 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 28 Nov 2012 09:36:01 GMT Message-Id: <201211280936.qAS9a1au035725@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 09:36:09 -0000 TB --- 2012-11-28 08:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-28 08: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 --- 2012-11-28 08:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-11-28 08:20:01 - cleaning the object tree TB --- 2012-11-28 08:23:29 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-28 08:23:29 - cd /tinderbox/HEAD/arm/arm TB --- 2012-11-28 08:23:29 - /usr/local/bin/svn cleanup /src TB --- 2012-11-28 08:23:59 - /usr/local/bin/svn update /src TB --- 2012-11-28 08:24:04 - At svn revision 243648 TB --- 2012-11-28 08:24:05 - building world TB --- 2012-11-28 08:24:05 - CROSS_BUILD_TESTING=YES TB --- 2012-11-28 08:24:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-28 08:24:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-28 08:24:05 - SRCCONF=/dev/null TB --- 2012-11-28 08:24:05 - TARGET=arm TB --- 2012-11-28 08:24:05 - TARGET_ARCH=arm TB --- 2012-11-28 08:24:05 - TZ=UTC TB --- 2012-11-28 08:24:05 - __MAKE_CONF=/dev/null TB --- 2012-11-28 08:24:05 - cd /src TB --- 2012-11-28 08:24:05 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Nov 28 08:24:10 UTC 2012 >>> 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 28 09:22:19 UTC 2012 TB --- 2012-11-28 09:22:19 - generating LINT kernel config TB --- 2012-11-28 09:22:19 - cd /src/sys/arm/conf TB --- 2012-11-28 09:22:19 - /usr/bin/make -B LINT TB --- 2012-11-28 09:22:19 - cd /src/sys/arm/conf TB --- 2012-11-28 09:22:19 - /usr/sbin/config -m LINT TB --- 2012-11-28 09:22:19 - building LINT kernel TB --- 2012-11-28 09:22:19 - CROSS_BUILD_TESTING=YES TB --- 2012-11-28 09:22:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-28 09:22:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-28 09:22:19 - SRCCONF=/dev/null TB --- 2012-11-28 09:22:19 - TARGET=arm TB --- 2012-11-28 09:22:19 - TARGET_ARCH=arm TB --- 2012-11-28 09:22:19 - TZ=UTC TB --- 2012-11-28 09:22:19 - __MAKE_CONF=/dev/null TB --- 2012-11-28 09:22:19 - cd /src TB --- 2012-11-28 09:22:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 28 09:22:19 UTC 2012 >>> 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 [...] uart_bus_fdt.o:uart_bus_fdt.c:(.text+0x0): first defined here uart_cpu_pxa.o: In function `uart_cpu_getdev': uart_cpu_pxa.c:(.text+0x18): multiple definition of `uart_cpu_getdev' uart_bus_fdt.o:uart_bus_fdt.c:(.text+0x264): first defined here uart_cpu_pxa.o:(.bss+0x4): multiple definition of `uart_bus_space_mem' uart_bus_fdt.o:(.bss+0x4): first defined here uart_cpu_pxa.o:(.bss+0x0): multiple definition of `uart_bus_space_io' uart_bus_fdt.o:(.bss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-28 09:36:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-28 09:36:01 - ERROR: failed to build LINT kernel TB --- 2012-11-28 09:36:01 - 3205.30 user 643.22 system 4560.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 28 13:29:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29DAEF00 for ; Wed, 28 Nov 2012 13:29:34 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C142C8FC0C for ; Wed, 28 Nov 2012 13:29:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Tdhhj-000SYu-QA>; Wed, 28 Nov 2012 14:29:31 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Tdhhj-000QdP-Nq>; Wed, 28 Nov 2012 14:29:31 +0100 Message-ID: <50B611B6.40903@zedat.fu-berlin.de> Date: Wed, 28 Nov 2012 14:29:26 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Current FreeBSD Subject: ZFS: ZIL with only one additional disk and how secure? X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCB2D0DE8D7C6F9A64D13F248" X-Originating-IP: 130.133.86.198 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Nov 2012 13:29:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCB2D0DE8D7C6F9A64D13F248 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I have a naive question. I read about speeding up NFSv4 shared ZFS array. I use a RAIDZ1 volume made up from 5 times 3TB harddrives, attached to a ICH10 SATA controller on a FreeBSD 10.0-CURRENT box. The maximum performance of that array never goes beyond 45 - 51 MB/s and levels out very often at 12 - 35 MB/s when used as a NFSv4 share and 1 GBit LAN. The local system harddisk, attached to the sixth SATA port of the same controller and containig a UFS2 filesystem, is capable of doing tasks with 60 - 80 MB/s (peak) when used as a NFSv4 share with another FreeBSD 10.0-CURRENT box. I used several reported tweaks on the RAIDZ1 ZFS volume exporting it as a NFSv4 volume, so I was capable of raising the throughput from sad 3 MB/s up to the 30 MB/s sustained. Also I was told that adding a dedicated ZIL drive could speed up things up to 90 MB/s with the mentioned construction of a RAIDZ1 over NFSv4. It is always suggested to add SSDs, a pair, for security reasons. My question in conrete is now: Do I need two (2) ZIL drives in a mirror? I guess this is considered due to security issues which lead to the next question: If it is possible to use only one ZIL drive and this drive gets corrupted, is the whole ZFS array corrupted, then? The minor question regards to the use of SSDs: Is it possible to gain speedup also from an ordinary disk dedicated to the ZFS array connected to a additional SATA controller? The SATA controller should be fast enough to serve a bandwith of 90 - 100 MB/s (theoretically) over 1 GBit lines when using the ZFS array as a NFSv4 export (the LAN is limiting, so, but 80 - 90 MB/s is possible on the specific box, the limiting factor at the moment is the bad performance of ZFS). The box is a quad core system at 3 GHz (Intel Q6600) with 8 GB of RAM running most recent FreeBSD 10.0-CURRENT/amd64. Thanks in advance, Oliver --------------enigCB2D0DE8D7C6F9A64D13F248 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.19 (FreeBSD) iQEcBAEBAgAGBQJQthG7AAoJEOgBcD7A/5N8+5UIAOLxog/7YYzr4FSfho3AWD52 O0K1kW5suRamMsksCiS4driQEhwS7bA/emKiR/b1JSg5j6+/Kx4d32tD8CKQh/ac 7gCboQu08Mb5QrHhjN1TQFpsW/1sBUsEezErtQTFYHftBuFwGSoZbcYoZgDroFIy Vnw0Xk28FgxFflD6ZLM7NECsdGueb2AseTw369ssqsb8CuAElGvWMq7Kog88ebjK D/YBzNF1nT9ERpZ/ZdPE73VjCM9tuTglQg3o2YkgCLPhFUmW2YSy7vvBqwk9B+3d beVFp/Fr9vhx2Rdg7W56ckhjD9GhM0BsgJu8MCuuZh6mhtNTAct5S4WeZgDz5gg= =ZQzS -----END PGP SIGNATURE----- --------------enigCB2D0DE8D7C6F9A64D13F248-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 28 13:38:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 546322E9 for ; Wed, 28 Nov 2012 13:38:50 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id F3A078FC08 for ; Wed, 28 Nov 2012 13:38:49 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo13so18409701vcb.13 for ; Wed, 28 Nov 2012 05:38:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=wSxAM0vXWqfQqk261HD/lCxe3DMEZPo4h8QpP/5R6v4=; b=cBTav2QgvqjbioL2GFMcZnsgRq0qKyw3wK742IQOljjZ8d5rQkdFnCZn5OTPFzgzM6 2OgNNva/ElIXOHudtAFrV0WvxQOHGJcVVbNCM2F4WxTZKc80VNlKuAk9cs/691KgiaNG f4cPZX8pZqGx6g+xt9yR5FZhmh1tcBlwyri6LiCIqCx06F0WbgO38xDGPaFeCczhC/g0 hPAMYChujYdD2nkdnGQrPP+pJqPwAxFVUuBIOQV8Zrgkx56P1k/+WzWfn0Nfz2H3XRqX KJ/NBrWKqiFLA6t99+WGQ7+VI64G/CzI3m4og0mkAOUwhYpu3cYmmZzmv1FJRghvreJg bTXA== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr28697661vca.14.1354109928872; Wed, 28 Nov 2012 05:38:48 -0800 (PST) Received: by 10.58.92.5 with HTTP; Wed, 28 Nov 2012 05:38:48 -0800 (PST) In-Reply-To: <50B611B6.40903@zedat.fu-berlin.de> References: <50B611B6.40903@zedat.fu-berlin.de> Date: Wed, 28 Nov 2012 14:38:48 +0100 Message-ID: Subject: Re: ZFS: ZIL with only one additional disk and how secure? From: Olivier Smedts To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm3u5QNucgKI9oWKxmRlzHDK2wkzeRsaV2nSlVjTYyeQlavpsntb5CgWY6uAdCZo/A3EmV5 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Nov 2012 13:38:50 -0000 Hi, 2012/11/28 O. Hartmann : > Hello, > I have a naive question. > I read about speeding up NFSv4 shared ZFS array. I use a RAIDZ1 volume > made up from 5 times 3TB harddrives, attached to a ICH10 SATA controller > on a FreeBSD 10.0-CURRENT box. The maximum performance of that array > never goes beyond 45 - 51 MB/s and levels out very often at 12 - 35 MB/s > when used as a NFSv4 share and 1 GBit LAN. The local system harddisk, > attached to the sixth SATA port of the same controller and containig a > UFS2 filesystem, is capable of doing tasks with 60 - 80 MB/s (peak) when > used as a NFSv4 share with another FreeBSD 10.0-CURRENT box. > > I used several reported tweaks on the RAIDZ1 ZFS volume exporting it as > a NFSv4 volume, so I was capable of raising the throughput from sad 3 > MB/s up to the 30 MB/s sustained. > > Also I was told that adding a dedicated ZIL drive could speed up things > up to 90 MB/s with the mentioned construction of a RAIDZ1 over NFSv4. It > is always suggested to add SSDs, a pair, for security reasons. > > My question in conrete is now: Do I need two (2) ZIL drives in a mirror? > I guess this is considered due to security issues which lead to the next > question: If it is possible to use only one ZIL drive and this drive > gets corrupted, is the whole ZFS array corrupted, then? You don't "need" two because if the ZIL is corrupted you'll only loose the data since the last TXG, but no metadata. Make sure you have an up-to-date pool. But you'll *need* a battery cache or supercaps on the SSD(s) so that they flush their caches in case of a power failure. > The minor question regards to the use of SSDs: Is it possible to gain > speedup also from an ordinary disk dedicated to the ZFS array connected > to a additional SATA controller? The SATA controller should be fast > enough to serve a bandwith of 90 - 100 MB/s (theoretically) over 1 GBit > lines when using the ZFS array as a NFSv4 export (the LAN is limiting, > so, but 80 - 90 MB/s is possible on the specific box, the limiting > factor at the moment is the bad performance of ZFS). I don't think so, or not much. What makes SSDs appealing for ZIL is that they have very good access times / latencies. > The box is a quad core system at 3 GHz (Intel Q6600) with 8 GB of RAM > running most recent FreeBSD 10.0-CURRENT/amd64. > > Thanks in advance, > > Oliver Cheers -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Wed Nov 28 14:07:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F03B3D57 for ; Wed, 28 Nov 2012 14:07:38 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9BE328FC12 for ; Wed, 28 Nov 2012 14:07:38 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TdiIb-000sHS-TP>; Wed, 28 Nov 2012 15:07:37 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TdiIb-000TX2-R5>; Wed, 28 Nov 2012 15:07:37 +0100 Message-ID: <50B61AA5.7030007@zedat.fu-berlin.de> Date: Wed, 28 Nov 2012 15:07:33 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Olivier Smedts Subject: Re: ZFS: ZIL with only one additional disk and how secure? References: <50B611B6.40903@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAB960E764C48C7DC68784060" X-Originating-IP: 130.133.86.198 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Nov 2012 14:07:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAB960E764C48C7DC68784060 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/28/12 14:38, Olivier Smedts wrote: > Hi, >=20 > 2012/11/28 O. Hartmann : >> Hello, >> I have a naive question. >> I read about speeding up NFSv4 shared ZFS array. I use a RAIDZ1 volume= >> made up from 5 times 3TB harddrives, attached to a ICH10 SATA controll= er >> on a FreeBSD 10.0-CURRENT box. The maximum performance of that array >> never goes beyond 45 - 51 MB/s and levels out very often at 12 - 35 MB= /s >> when used as a NFSv4 share and 1 GBit LAN. The local system harddisk, >> attached to the sixth SATA port of the same controller and containig a= >> UFS2 filesystem, is capable of doing tasks with 60 - 80 MB/s (peak) wh= en >> used as a NFSv4 share with another FreeBSD 10.0-CURRENT box. >> >> I used several reported tweaks on the RAIDZ1 ZFS volume exporting it a= s >> a NFSv4 volume, so I was capable of raising the throughput from sad 3 >> MB/s up to the 30 MB/s sustained. >> >> Also I was told that adding a dedicated ZIL drive could speed up thing= s >> up to 90 MB/s with the mentioned construction of a RAIDZ1 over NFSv4. = It >> is always suggested to add SSDs, a pair, for security reasons. >> >> My question in conrete is now: Do I need two (2) ZIL drives in a mirro= r? >> I guess this is considered due to security issues which lead to the ne= xt >> question: If it is possible to use only one ZIL drive and this drive >> gets corrupted, is the whole ZFS array corrupted, then? >=20 > You don't "need" two because if the ZIL is corrupted you'll only loose > the data since the last TXG, but no metadata. Make sure you have an > up-to-date pool. >=20 > But you'll *need* a battery cache or supercaps on the SSD(s) so that > they flush their caches in case of a power failure. >=20 >> The minor question regards to the use of SSDs: Is it possible to gain >> speedup also from an ordinary disk dedicated to the ZFS array connecte= d >> to a additional SATA controller? The SATA controller should be fast >> enough to serve a bandwith of 90 - 100 MB/s (theoretically) over 1 GBi= t >> lines when using the ZFS array as a NFSv4 export (the LAN is limiting,= >> so, but 80 - 90 MB/s is possible on the specific box, the limiting >> factor at the moment is the bad performance of ZFS). >=20 > I don't think so, or not much. What makes SSDs appealing for ZIL is > that they have very good access times / latencies. >=20 >> The box is a quad core system at 3 GHz (Intel Q6600) with 8 GB of RAM >> running most recent FreeBSD 10.0-CURRENT/amd64. >> >> Thanks in advance, >> >> Oliver >=20 > Cheers >=20 Good to hear. Thanks a lot, Greetings Oliver --------------enigAB960E764C48C7DC68784060 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.19 (FreeBSD) iQEcBAEBAgAGBQJQthqpAAoJEOgBcD7A/5N8uSQH/RgbZCkeB9LWb6elghfMhOyn yZ+drgWuuBBUi63Ov5WuA9IBNBCBoRqGctiO2TcqnmdyFtMUeqcB5LaoeN+60XIv GBp3+fZmIrJPZCYFiFFiJp3wqX1Mc9fXfmvoLy/FuPjJiAQ8VFbNFWsWlgLXHIIy 7ABvxClgF42fmC/N8cFlNnZ9Ms7gd55bQ/DUdEt5FDjAF5ylJF1y0dggsSQNDbYE cCV5/R1BLCSsaSjea44228vQu93VQyUED1lqiNrW9z6v1gns1maMlRtb3Nq7w6Gh GBmOnB3gP4GCXJFWE+62gAwna3TpMZfjVF+y+fVx1b2Eh4PNAPGouU2lsduealY= =ufi5 -----END PGP SIGNATURE----- --------------enigAB960E764C48C7DC68784060-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 28 18:35:58 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90D37C51; Wed, 28 Nov 2012 18:35:58 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B08368FC16; Wed, 28 Nov 2012 18:35:57 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA29309; Wed, 28 Nov 2012 20:35:56 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50B6598B.20200@FreeBSD.org> Date: Wed, 28 Nov 2012 20:35:55 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: FreeBSD current , FreeBSD Stable Subject: [HEADSUP] zfs root pool mounting X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Nov 2012 18:35:58 -0000 Recently some changes were made to how a root pool is opened for root filesystem mounting. Previously the root pool had to be present in zpool.cache. Now it is automatically discovered by probing available GEOM providers. The new scheme is believed to be more flexible. For example, it allows to prepare a new root pool at one system, then export it and then boot from it on a new system without doing any extra/magical steps with zpool.cache. It could also be convenient after zpool split and in some other situations. The change was introduced via multiple commits, the latest relevant revision in head is r243502. The changes are partially MFC-ed, the remaining parts are scheduled to be MFC-ed soon. I have received a report that the change caused a problem with booting on at least one system. The problem has been identified as an issue in local environment and has been fixed. Please read on to see if you might be affected when you upgrade, so that you can avoid any unnecessary surprises. You might be affected if you ever had a pool named the same as your current root pool. And you still have any disks connected to your system that belonged to that pool (in whole or via some partitions). And that pool was never properly destroyed using zpool destroy, but merely abandoned (its disks re-purposed/re-partitioned/reused). If all of the above are true, then I recommend that you run 'zdb -l ' for all suspect disks and their partitions (or just all disks and partitions). If this command reports at least one valid ZFS label for a disk or a partition that do not belong to any current pool, then the problem may affect you. The best course is to remove the offending labels. If you are affected, please follow up to this email. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 28 19:37:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46944E56; Wed, 28 Nov 2012 19:37:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1153E8FC08; Wed, 28 Nov 2012 19:37: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 qASJbOdX003912; Wed, 28 Nov 2012 14:37:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qASJbO2S003898; Wed, 28 Nov 2012 19:37:24 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 28 Nov 2012 19:37:24 GMT Message-Id: <201211281937.qASJbO2S003898@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 19:37:26 -0000 TB --- 2012-11-28 18:20:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-28 18:20:01 - 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 --- 2012-11-28 18:20:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-11-28 18:20:01 - cleaning the object tree TB --- 2012-11-28 18:24:33 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-28 18:24:33 - cd /tinderbox/HEAD/arm/arm TB --- 2012-11-28 18:24:33 - /usr/local/bin/svn cleanup /src TB --- 2012-11-28 18:25:14 - /usr/local/bin/svn update /src TB --- 2012-11-28 18:25:19 - At svn revision 243658 TB --- 2012-11-28 18:25:20 - building world TB --- 2012-11-28 18:25:20 - CROSS_BUILD_TESTING=YES TB --- 2012-11-28 18:25:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-28 18:25:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-28 18:25:20 - SRCCONF=/dev/null TB --- 2012-11-28 18:25:20 - TARGET=arm TB --- 2012-11-28 18:25:20 - TARGET_ARCH=arm TB --- 2012-11-28 18:25:20 - TZ=UTC TB --- 2012-11-28 18:25:20 - __MAKE_CONF=/dev/null TB --- 2012-11-28 18:25:20 - cd /src TB --- 2012-11-28 18:25:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Nov 28 18:25:24 UTC 2012 >>> 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 28 19:23:49 UTC 2012 TB --- 2012-11-28 19:23:49 - generating LINT kernel config TB --- 2012-11-28 19:23:49 - cd /src/sys/arm/conf TB --- 2012-11-28 19:23:49 - /usr/bin/make -B LINT TB --- 2012-11-28 19:23:49 - cd /src/sys/arm/conf TB --- 2012-11-28 19:23:49 - /usr/sbin/config -m LINT TB --- 2012-11-28 19:23:49 - building LINT kernel TB --- 2012-11-28 19:23:49 - CROSS_BUILD_TESTING=YES TB --- 2012-11-28 19:23:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-28 19:23:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-28 19:23:49 - SRCCONF=/dev/null TB --- 2012-11-28 19:23:49 - TARGET=arm TB --- 2012-11-28 19:23:49 - TARGET_ARCH=arm TB --- 2012-11-28 19:23:49 - TZ=UTC TB --- 2012-11-28 19:23:49 - __MAKE_CONF=/dev/null TB --- 2012-11-28 19:23:49 - cd /src TB --- 2012-11-28 19:23:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 28 19:23:50 UTC 2012 >>> 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 [...] uart_bus_fdt.o:uart_bus_fdt.c:(.text+0x0): first defined here uart_cpu_pxa.o: In function `uart_cpu_getdev': uart_cpu_pxa.c:(.text+0x18): multiple definition of `uart_cpu_getdev' uart_bus_fdt.o:uart_bus_fdt.c:(.text+0x264): first defined here uart_cpu_pxa.o:(.bss+0x4): multiple definition of `uart_bus_space_mem' uart_bus_fdt.o:(.bss+0x4): first defined here uart_cpu_pxa.o:(.bss+0x0): multiple definition of `uart_bus_space_io' uart_bus_fdt.o:(.bss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-28 19:37:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-28 19:37:24 - ERROR: failed to build LINT kernel TB --- 2012-11-28 19:37:24 - 3230.97 user 652.88 system 4643.53 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 28 19:54:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5D83417; Wed, 28 Nov 2012 19:54:33 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA518FC0C; Wed, 28 Nov 2012 19:54:32 +0000 (UTC) X-AuditID: 1209190c-b7f766d0000015cf-6c-50b66ac4c4f3 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 84.79.05583.4CA66B05; Wed, 28 Nov 2012 14:49:24 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id qASJnO2L011970; Wed, 28 Nov 2012 14:49:24 -0500 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id qASJnMdG007675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Nov 2012 14:49:23 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id qASJnLIp008236; Wed, 28 Nov 2012 14:49:22 -0500 (EST) Date: Wed, 28 Nov 2012 14:49:21 -0500 (EST) From: Benjamin Kaduk To: Adrian Chadd Subject: Re: Is cross-world building broken? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixG6nrnska1uAwcl+A4u9W7czWcx584HJ gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZs5rZC9YzVWy43MTcwPiBsYuRk0NCwERi3rFdrBC2 mMSFe+vZuhi5OIQE9jFKnNmxkQXC2cAoMffmMyYI5wSTxLwNB9khnAZGiYmrNrGD9LMIaEus XjedDcRmE1CRmPlmI5DNwSEioCrROd8ZJMwsIC/x/8plJhBbWEBHovfCRLAzOAUCJQ7dOssM YvMKOEicaX3LCjF/KqPEkXuNYEWiQA2r909hgSgSlDg58wkLxFBLiXN/rrNNYBSchSQ1C0lq ASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJNjKAA5ZTk2cH45qDSIUYBDkYl Ht4dDtsChFgTy4orcw8xSnIwKYnyfosHCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhvRUElONN SaysSi3Kh0lJc7AoifNeTrnpLySQnliSmp2aWpBaBJOV4eBQkuB9mgnUKFiUmp5akZaZU4KQ ZuLgBBnOAzT8JkgNb3FBYm5xZjpE/hSjopQ47x+QhABIIqM0D64XlkBeMYoDvSLM+xGkigeY fOC6XwENZgIaHHR2K8jgkkSElFQDoyZbqsO5krpvgnpzdjXdfxkZzinjklT6WnLLq/eiD/T3 1u3VY61dn3kjq8u9J9dWo+WXQtgDniU+DxZ+kI3KW/Bd/oFvzoyvJ3c2NGUc8Ph3kf1hatHJ jU9SZpTWCWfO8lyvtN/gv2RO5sLV55ONdgaorS2Kbpmy67d5r5afGvslV8X57BJMSizFGYmG WsxFxYkAaq4jjfsCAAA= Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Nov 2012 19:54:33 -0000 On Tue, 27 Nov 2012, Adrian Chadd wrote: > .. so, Nathan Whitehorn discovered that DESTDIR should be specified in > environment, not on the command line. Um, we have lots of things that document passing DESTDIR on the command line. Like, src/UPDATING. Something seems wrong, here... -Ben From owner-freebsd-current@FreeBSD.ORG Wed Nov 28 20:15:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4416E757 for ; Wed, 28 Nov 2012 20:15:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C5DA48FC08 for ; Wed, 28 Nov 2012 20:14:59 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so6156811wey.13 for ; Wed, 28 Nov 2012 12:14:58 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vl+M5yoXAPmQgbBU8ZRQXJTVTCptP3YpnnxhnIPCd7M=; b=QcPbvyJIRzepPEl1WUaXKGSbl8SC46bXH01vWWZ+wTFHv6bUvqJcBVe0FAQHjtsa5g KwCG2tT3FhDWteFSzc/v1ptS+QlqA1h09EUp2KThaXFQ8Ulkuy/Ic5964ba/7k0a+LaI X9WuR2M+SoWs7BPPjaThrHv+GjUzDMp36jL8h0aKSFi69zYR8aV7o8USctk6x8M6cs2J keuly2i4+oUuYdmgBWWXQ5XwMlqrUCHxxq1mDq38WiKVczSU1C0VlNXaKMiSpvGwrxlI O3YO3asZP9lv9RCmSv9RHWzLzfH6fFUgt7JPDJCYWo9oQHamunCMeBGrMh+3jBnKMrke vg6g== MIME-Version: 1.0 Received: by 10.216.200.160 with SMTP id z32mr7604762wen.53.1354133698816; Wed, 28 Nov 2012 12:14:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Wed, 28 Nov 2012 12:14:58 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Nov 2012 12:14:58 -0800 X-Google-Sender-Auth: jPaYHS6Nn5-MCOCWEKaRZBUXGRA Message-ID: Subject: Re: Is cross-world building broken? From: Adrian Chadd To: Benjamin Kaduk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Nov 2012 20:15:00 -0000 On 28 November 2012 11:49, Benjamin Kaduk wrote: > Um, we have lots of things that document passing DESTDIR on the command > line. Like, src/UPDATING. Something seems wrong, here... Right. Andrew thinks that the MMAKE variables for building the initial make aren't setting DESTDIR correctly. Well, aren't clearing it correctly. Adrian From owner-freebsd-current@FreeBSD.ORG Thu Nov 29 00:10:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03BBBAFD for ; Thu, 29 Nov 2012 00:10:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B17328FC12 for ; Thu, 29 Nov 2012 00:10:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAEGntlCDaFvO/2dsb2JhbABFhiq6DnOCHgEBAQMBAQEBICseAggDBRYYAgINGQIpAQkmBggHBAEcBIdpBgysJpJ3gSKLIgYQAYMSgRMDiF6KdoItgRyPKIMQgU41 X-IronPort-AV: E=Sophos;i="4.84,180,1355115600"; d="scan'208";a="2286110" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 28 Nov 2012 19:10:09 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9ED76B4052; Wed, 28 Nov 2012 19:10:09 -0500 (EST) Date: Wed, 28 Nov 2012 19:10:09 -0500 (EST) From: Rick Macklem To: Olivier Smedts Message-ID: <847367079.954826.1354147809641.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: ZFS: ZIL with only one additional disk and how secure? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: Current FreeBSD , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Nov 2012 00:10:18 -0000 Olivier Smedts wrote: > Hi, > > 2012/11/28 O. Hartmann : > > Hello, > > I have a naive question. > > I read about speeding up NFSv4 shared ZFS array. I use a RAIDZ1 > > volume > > made up from 5 times 3TB harddrives, attached to a ICH10 SATA > > controller > > on a FreeBSD 10.0-CURRENT box. The maximum performance of that array > > never goes beyond 45 - 51 MB/s and levels out very often at 12 - 35 > > MB/s > > when used as a NFSv4 share and 1 GBit LAN. The local system > > harddisk, > > attached to the sixth SATA port of the same controller and containig > > a > > UFS2 filesystem, is capable of doing tasks with 60 - 80 MB/s (peak) > > when > > used as a NFSv4 share with another FreeBSD 10.0-CURRENT box. > > > > I used several reported tweaks on the RAIDZ1 ZFS volume exporting it > > as > > a NFSv4 volume, so I was capable of raising the throughput from sad > > 3 > > MB/s up to the 30 MB/s sustained. > > > > Also I was told that adding a dedicated ZIL drive could speed up > > things > > up to 90 MB/s with the mentioned construction of a RAIDZ1 over > > NFSv4. It > > is always suggested to add SSDs, a pair, for security reasons. > > > > My question in conrete is now: Do I need two (2) ZIL drives in a > > mirror? > > I guess this is considered due to security issues which lead to the > > next > > question: If it is possible to use only one ZIL drive and this drive > > gets corrupted, is the whole ZFS array corrupted, then? > > You don't "need" two because if the ZIL is corrupted you'll only loose > the data since the last TXG, but no metadata. Make sure you have an > up-to-date pool. > Be careful here. When an NFS client does write, ..., commit and the NFS server replies OK, the client assumes the data is "safe" and will no longer cache it. Take the following simple example: - User on a client edits a file and then saves it. No errors are reported, and the client doesn't crash, so the user assumes the saved data is "safe". - NFS server crashes and loses the one ZIL, losing the data. The User/client will not know the data was lost (might have seen the "server not repsonding... server ok" message, but that's all.) - User discovers months later that the change to the file is somehow missing and is Not Happy. If a user sees the client crash, they will suspect the data was lost, but they won't expect that if the client keeps running and doesn't report errors. I'd want the ZIL mirrored if I was setting this up, but I can't say how serious the above failure might be for your environment. (Some are happy with "sync=disabled"). rick > But you'll *need* a battery cache or supercaps on the SSD(s) so that > they flush their caches in case of a power failure. > > > The minor question regards to the use of SSDs: Is it possible to > > gain > > speedup also from an ordinary disk dedicated to the ZFS array > > connected > > to a additional SATA controller? The SATA controller should be fast > > enough to serve a bandwith of 90 - 100 MB/s (theoretically) over 1 > > GBit > > lines when using the ZFS array as a NFSv4 export (the LAN is > > limiting, > > so, but 80 - 90 MB/s is possible on the specific box, the limiting > > factor at the moment is the bad performance of ZFS). > > I don't think so, or not much. What makes SSDs appealing for ZIL is > that they have very good access times / latencies. > > > The box is a quad core system at 3 GHz (Intel Q6600) with 8 GB of > > RAM > > running most recent FreeBSD 10.0-CURRENT/amd64. > > > > Thanks in advance, > > > > Oliver > > Cheers > > -- > Olivier Smedts _ > ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org - against HTML email & vCards X > www: http://www.gid0.org - against proprietary attachments / \ > > "Il y a seulement 10 sortes de gens dans le monde : > ceux qui comprennent le binaire, > et ceux qui ne le comprennent pas." > _______________________________________________ > 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 Thu Nov 29 00:19:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53FB4E5D; Thu, 29 Nov 2012 00:19:30 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE1968FC08; Thu, 29 Nov 2012 00:19:28 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so16148089obc.13 for ; Wed, 28 Nov 2012 16:19:28 -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=lezbWYp3rjEQKd6Ftj60k76Aj1lKXAyE6UjvumsGcCY=; b=Ms5EFDA0RUz/b3jX9fmFMy+MEj+UU5Ltt1Mu5hqnBJxUUBkqtt5mTmrhscRxBlGZpL NsgDrDyQTrjwhnnSaZ7C4SCFSTajqJxDj5yPL53AkltLsZ6Awj+5w2vjFa02Rnz4Tz98 VesIsgcjqyZSMBQPeXoRromBlHSvSw0uRVMd9C7XJZKsGVh57dUoc1k4YWy9HvCYmpe0 +ObtYTwhF5IIY3f8AroZs/CZPj9mCQ0mQo8YmPiuLfLSmec0eq3DO4HArcvz40vpw1xX x2IgcNu2kyD7Wgyclwc65HdNGp1Na6f5Br/T+CPd5TJEGbiJ3W7coUOzuX8i3PlCM9Zt 3tuQ== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr182452oeb.24.1354148368439; Wed, 28 Nov 2012 16:19:28 -0800 (PST) Received: by 10.76.143.33 with HTTP; Wed, 28 Nov 2012 16:19:28 -0800 (PST) In-Reply-To: References: <6961B0D9-F823-415C-A105-7DAC8339CB30@gmail.com> <3EB9F7EB-D9C8-40CB-BF28-21B7BE59C94C@gmail.com> <20121128071252.7AC1958094@chaos.jnpr.net> <20121128231538.8AB6758094@chaos.jnpr.net> <20121129000106.540ED58094@chaos.jnpr.net> Date: Wed, 28 Nov 2012 16:19:28 -0800 Message-ID: Subject: Re: Is cross-world building broken? From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Andrew Turner , FreeBSD Current , "Simon J. Gerraty" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Nov 2012 00:19:30 -0000 On Wed, Nov 28, 2012 at 4:07 PM, Adrian Chadd wrote: > top posting, out of laziness and busy-ness at work.. > > Ok. So: > > * make installworld/installkernel/distribution - set DESTDIR on the command line > * make buildworld/make buildkernel/make - > don't set DESTDIR? (re-CCing -current@) Correct. DESTDIR should only be used for install targets (install, installworld, installkernel, distribution, etc), and not for any of the other build-related targets on FreeBSD. [as the meme goes] "If you set DESTDIR when building, you're gonna have a bad time". HTH! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Nov 29 09:49:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17ECE4B8 for ; Thu, 29 Nov 2012 09:49:32 +0000 (UTC) (envelope-from prvs=1680ddcdf2=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 960138FC0C for ; Thu, 29 Nov 2012 09:49:30 +0000 (UTC) Received: from r2d2 ([82.12.17.66]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001203859.msg for ; Thu, 29 Nov 2012 09:49:12 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 29 Nov 2012 09:49:12 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDDNSBL-Result: mail1.multiplay.co.uk, Thu, 29 Nov 2012 09:49:12 +0000 zen.spamhaus.org returned result of 127.0.0.11 X-MDRemoteIP: 82.12.17.66 X-Return-Path: prvs=1680ddcdf2=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org Message-ID: From: "Steven Hartland" To: "Johannes Dieterich" , References: <50B3C772.7040802@gmail.com> Subject: Re: Samsung 830 and ZFS TRIM Date: Thu, 29 Nov 2012 09:40:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Nov 2012 09:49:32 -0000 Do you have any other disks in the machine if so its likely these are the source of the unsupported increments. Regards Steve ----- Original Message ----- From: "Johannes Dieterich" To: Sent: Monday, November 26, 2012 7:48 PM Subject: Samsung 830 and ZFS TRIM > Hello, > > (initially posted this to -questions@ a week ago, w/o reply) > > I installed CURRENT on a new Thinkpad equipped with a Samsung 830 SSD: > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-9 SATA 3.x device > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) > ada0: Previously was known as ad4 > > as the setup is ZFS+GELI based (on ada0), I enabled ZFS TRIM support in > loader.conf. > > Interestingly, I encounter an IMHO strange behavior with the stats on that: > > kstat.zfs.misc.zio_trim.zio_trim_bytes: 755712 > kstat.zfs.misc.zio_trim.zio_trim_success: 97 > kstat.zfs.misc.zio_trim.zio_trim_unsupported: 7891 > kstat.zfs.misc.zio_trim.zio_trim_failed: 0 > > It seems unintuitive to me why the unsupported counter first increases > (seems to stay constant after that each boot) and then slowly the > success counter increases as well. > > Probably there is a trivial explanation (GELI?) and/or fix for this that > anyone is willing to share? > > If you need further information, let me know. > > Thanks a lot > > Johannes > _______________________________________________ > 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" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Thu Nov 29 12:05:52 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0342E808; Thu, 29 Nov 2012 12:05:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E4FBE8FC13; Thu, 29 Nov 2012 12:05:50 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA10285; Thu, 29 Nov 2012 14:05:48 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50B74F9C.40106@FreeBSD.org> Date: Thu, 29 Nov 2012 14:05:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page References: <50A4E8C0.5030608@FreeBSD.org> <50A552C5.5060703@FreeBSD.org> <50A650C2.7060407@FreeBSD.org> In-Reply-To: <50A650C2.7060407@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Nov 2012 12:05:52 -0000 on 16/11/2012 16:42 Andriy Gapon said the following: > on 15/11/2012 23:44 Attilio Rao said the following: >> Do you think you can test this patch?: >> http://www.freebsd.org/~attilio/lockmgr_forcerec.patch > > I will use this patch in my tree, but I think that it is effectively already quite > well tested by using INVARIANTS+WITNESS. > I've been using this patch in both debug and non-debug environments and I have not run into any issues. Please commit when you get a chance. Thank you. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 29 14:10:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03FE23EC for ; Thu, 29 Nov 2012 14:10:30 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id A98698FC08 for ; Thu, 29 Nov 2012 14:10:29 +0000 (UTC) Received: by mail-gh0-f182.google.com with SMTP id z15so2855049ghb.13 for ; Thu, 29 Nov 2012 06:10:28 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=f6zonLgJZ6imyeguoZrjlj0HBmtmlbC0mJm5p8EYOp4=; b=pGo7Aa+QczaQm9aNrAz+c/lSEW9QNj2olJNQGFnGHi4ogWtYzr88ubvwRTLuWy6CX+ 62AUZMq+coREsQGK4ETRhXQOBFrC+s4uVaOQx33eUPZEtbify1w+Nitlt3IY1kgS95gv d/s/tDGk1U7/EGUMLqTFmCK1E5f1I45ouVFO0NcCjTDBrgWULmT+cTLeoogVtC/Dnp6+ M0XOiBl4wDkc7kE0acx3auCinGvkZwg7uinuK7T8Mxv/uAveBIL8T3YkNIbQZ+MmXyfZ te0t/zwHb5fLJee1os5x2UfglthzaU0u79kv5FBdzNSFBiZhm23Pkd60fhyQpyzhWBxD Kbag== Received: by 10.236.47.41 with SMTP id s29mr24355262yhb.20.1354198228853; Thu, 29 Nov 2012 06:10:28 -0800 (PST) Received: from bresson.poelloepaeae.de (pool-173-72-34-218.cmdnnj.fios.verizon.net. [173.72.34.218]) by mx.google.com with ESMTPS id t12sm1539287ane.6.2012.11.29.06.10.27 (version=SSLv3 cipher=OTHER); Thu, 29 Nov 2012 06:10:28 -0800 (PST) Message-ID: <50B76CD3.2050607@gmail.com> Date: Thu, 29 Nov 2012 09:10:27 -0500 From: Johannes Dieterich User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Steven Hartland Subject: Re: Samsung 830 and ZFS TRIM References: <50B3C772.7040802@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Nov 2012 14:10:30 -0000 On 11/29/12 04:40, Steven Hartland wrote: > Do you have any other disks in the machine if so its likely these are > the source of the unsupported increments. No, not yet. Best regards Johannes > ----- Original Message ----- From: "Johannes Dieterich" > > To: > Sent: Monday, November 26, 2012 7:48 PM > Subject: Samsung 830 and ZFS TRIM > > >> Hello, >> >> (initially posted this to -questions@ a week ago, w/o reply) >> >> I installed CURRENT on a new Thinkpad equipped with a Samsung 830 SSD: >> >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-9 SATA 3.x device >> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) >> ada0: Previously was known as ad4 >> >> as the setup is ZFS+GELI based (on ada0), I enabled ZFS TRIM support >> in loader.conf. >> >> Interestingly, I encounter an IMHO strange behavior with the stats on >> that: >> >> kstat.zfs.misc.zio_trim.zio_trim_bytes: 755712 >> kstat.zfs.misc.zio_trim.zio_trim_success: 97 >> kstat.zfs.misc.zio_trim.zio_trim_unsupported: 7891 >> kstat.zfs.misc.zio_trim.zio_trim_failed: 0 >> >> It seems unintuitive to me why the unsupported counter first increases >> (seems to stay constant after that each boot) and then slowly the >> success counter increases as well. >> >> Probably there is a trivial explanation (GELI?) and/or fix for this >> that anyone is willing to share? >> >> If you need further information, let me know. >> >> Thanks a lot >> >> Johannes >> _______________________________________________ >> 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" >> > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, printing > or otherwise disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > From owner-freebsd-current@FreeBSD.ORG Thu Nov 29 22:36:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DE10C43 for ; Thu, 29 Nov 2012 22:36:12 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C96978FC1A for ; Thu, 29 Nov 2012 22:36:11 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so14045425qcs.13 for ; Thu, 29 Nov 2012 14:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=yGLSsq5kG/7RYzZn0MuHIXwU8a7tyCqBsI7Zh5td9/M=; b=cslNLIXmn6EqfuGf5p38LR8arIKySVtNkNA0ut7OnqCKzFHMIh53BJvoZ1h4urnnb+ qO56AUBWA+JDDCpxD4ZXm+uLrXaH/8POtDoW+T2loRTSSDV0J9zlV4C1HRPCbEhyF3o5 VGvz9ym2SSSFfMtHQQ0gWLwww8tAYZ1NSqjZr7WHbQVZb2cclROEQJcU2DqY6HVmYmc7 3exPM95dmssG5kzTAtpwJMlOnmCLKcJY+q2TMkm30kQbMaesbB0ZYQOn4WDHLEpIQoZq 3aquOlwdpshl+B9j3D3oZ6HFf8aRXTHD3oZCK/BH07ZZs0DdbXyn760apfrJJanG7V+H kMNw== MIME-Version: 1.0 Received: by 10.224.31.20 with SMTP id w20mr103629qac.3.1354228570961; Thu, 29 Nov 2012 14:36:10 -0800 (PST) Sender: carpeddiem@gmail.com Received: by 10.49.127.50 with HTTP; Thu, 29 Nov 2012 14:36:08 -0800 (PST) Date: Thu, 29 Nov 2012 17:36:08 -0500 X-Google-Sender-Auth: PPavV4fkTQyL_sl3wqy15iRUI2s Message-ID: Subject: Panic on shutdown, r243674M From: Ed Maste To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Nov 2012 22:36:12 -0000 Rev 243674 with some minor local changes. #12 0xffffffff80bfd775 in trap_fatal (frame=0xffffff800025e870, eva=) at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:867 #13 0xffffffff80bfda3a in trap_pfault (frame=0x0, usermode=0) at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:698 #14 0xffffffff80bfd226 in trap (frame=0xffffff800025e870) at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:463 #15 0xffffffff80be71a2 in calltrap () at /tmp/exception-N6d6io.s:179 #16 0xffffffff808bb9c0 in rman_set_bustag () at /home/emaste/src/head-ro/sys/kern/subr_rman.c:941 #17 0xffffffff80356c9d in acpi_cpu_idle () at /home/emaste/src/head-ro/sys/dev/acpica/acpi_cpu.c:1020 #18 0xffffffff80beb268 in cpu_idle_acpi (busy=0) at /home/emaste/src/head-ro/sys/amd64/amd64/machdep.c:685 #19 0xffffffff80beb308 in cpu_idle (busy=0) at /home/emaste/src/head-ro/sys/amd64/amd64/machdep.c:839 #20 0xffffffff808a6058 in sched_idletd (dummy=) at /home/emaste/src/head-ro/sys/kern/sched_ule.c:2665 #21 0xffffffff808524d4 in fork_exit ( callout=0xffffffff808a5e20 , arg=0x0, frame=0xffffff800025eac0) at /home/emaste/src/head-ro/sys/kern/kern_fork.c:995 #22 0xffffffff80be76de in fork_trampoline () at /tmp/exception-N6d6io.s:501 #23 0x0000000000000000 in ?? () From owner-freebsd-current@FreeBSD.ORG Thu Nov 29 23:29:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 890AF71F; Thu, 29 Nov 2012 23:29:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id EA0CF8FC08; Thu, 29 Nov 2012 23:29:49 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qATNTiX6024876; Fri, 30 Nov 2012 01:29:44 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qATNTiX6024876 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qATNTior024875; Fri, 30 Nov 2012 01:29:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Nov 2012 01:29:44 +0200 From: Konstantin Belousov To: sig6247 Subject: Re: clang compiled kernel panic when mounting zfs root on i386 Message-ID: <20121129232944.GQ3013@kib.kiev.ua> References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KI6XeYrntNhU1GwB" Content-Disposition: inline In-Reply-To: <20121127071243.D1255@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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, fs@freebsd.org, Bruce Evans X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Nov 2012 23:29:50 -0000 --KI6XeYrntNhU1GwB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2012 at 08:21:05AM +1100, Bruce Evans wrote: > On Mon, 26 Nov 2012, Konstantin Belousov wrote: >=20 > > On Mon, Nov 26, 2012 at 06:31:34AM -0800, sig6247 wrote: > >> > >> Just checked out r243529, this only happens when the kernel is compiled > >> by clang, and only on i386, either recompiling the kernel with gcc or > >> booting from a UFS root works fine. Is it a known problem? > > It looks like that clang uses more stack than gcc, and zfs makes quite > > deep call chains. =2E.. > It would be useful if the stack trace printed the the stack pointer > on every function call, so that you could see how much stack each > function used. Please apply the patch below and obtain the backtrace of the double fault panic again. I will commit the patch later. diff --git a/sys/amd64/amd64/db_trace.c b/sys/amd64/amd64/db_trace.c index cba90f2..2c81f87 100644 --- a/sys/amd64/amd64/db_trace.c +++ b/sys/amd64/amd64/db_trace.c @@ -186,7 +186,8 @@ db_ss(struct db_variable *vp, db_expr_t *valuep, int op) =20 static void db_nextframe(struct amd64_frame **, db_addr_t *, struct thread= *); static int db_numargs(struct amd64_frame *); -static void db_print_stack_entry(const char *, int, char **, long *, db_ad= dr_t); +static void db_print_stack_entry(const char *, int, char **, long *, db_ad= dr_t, + void *); static void decode_syscall(int, struct thread *); =20 static const char * watchtype_str(int type); @@ -230,12 +231,13 @@ db_numargs(fp) } =20 static void -db_print_stack_entry(name, narg, argnp, argp, callpc) +db_print_stack_entry(name, narg, argnp, argp, callpc, frame) const char *name; int narg; char **argnp; long *argp; db_addr_t callpc; + void *frame; { db_printf("%s(", name); #if 0 @@ -250,6 +252,8 @@ db_print_stack_entry(name, narg, argnp, argp, callpc) #endif db_printf(") at "); db_printsym(callpc, DB_STGY_PROC); + if (frame !=3D NULL) + db_printf("/frame 0x%lx", (register_t)frame); db_printf("\n"); } =20 @@ -341,7 +345,7 @@ db_nextframe(struct amd64_frame **fp, db_addr_t *ip, st= ruct thread *td) return; } =20 - db_print_stack_entry(name, 0, 0, 0, rip); + db_print_stack_entry(name, 0, 0, 0, rip, &(*fp)->f_frame); =20 /* * Point to base of trapframe which is just above the @@ -437,7 +441,8 @@ db_backtrace(struct thread *td, struct trapframe *tf, * Don't try to walk back on a stack for a * process that hasn't actually been run yet. */ - db_print_stack_entry(name, 0, 0, 0, pc); + db_print_stack_entry(name, 0, 0, 0, pc, + actframe); break; } first =3D FALSE; @@ -451,7 +456,7 @@ db_backtrace(struct thread *td, struct trapframe *tf, narg =3D db_numargs(frame); } =20 - db_print_stack_entry(name, narg, argnp, argp, pc); + db_print_stack_entry(name, narg, argnp, argp, pc, actframe); =20 if (actframe !=3D frame) { /* `frame' belongs to caller. */ @@ -465,7 +470,7 @@ db_backtrace(struct thread *td, struct trapframe *tf, if (INKERNEL((long)pc) && !INKERNEL((long)frame)) { sym =3D db_search_symbol(pc, DB_STGY_ANY, &offset); db_symbol_values(sym, &name, NULL); - db_print_stack_entry(name, 0, 0, 0, pc); + db_print_stack_entry(name, 0, 0, 0, pc, frame); break; } if (!INKERNEL((long) frame)) { diff --git a/sys/i386/i386/db_trace.c b/sys/i386/i386/db_trace.c index 445d9c5..822cc56 100644 --- a/sys/i386/i386/db_trace.c +++ b/sys/i386/i386/db_trace.c @@ -176,7 +176,8 @@ db_ss(struct db_variable *vp, db_expr_t *valuep, int op) =20 static void db_nextframe(struct i386_frame **, db_addr_t *, struct thread = *); static int db_numargs(struct i386_frame *); -static void db_print_stack_entry(const char *, int, char **, int *, db_add= r_t); +static void db_print_stack_entry(const char *, int, char **, int *, db_add= r_t, + void *); static void decode_syscall(int, struct thread *); =20 static const char * watchtype_str(int type); @@ -220,12 +221,13 @@ retry: } =20 static void -db_print_stack_entry(name, narg, argnp, argp, callpc) +db_print_stack_entry(name, narg, argnp, argp, callpc, frame) const char *name; int narg; char **argnp; int *argp; db_addr_t callpc; + void *frame; { int n =3D narg >=3D 0 ? narg : 5; =20 @@ -242,6 +244,8 @@ db_print_stack_entry(name, narg, argnp, argp, callpc) db_printf(",..."); db_printf(") at "); db_printsym(callpc, DB_STGY_PROC); + if (frame !=3D NULL) + db_printf("/frame 0x%r", (register_t)frame); db_printf("\n"); } =20 @@ -326,7 +330,7 @@ db_nextframe(struct i386_frame **fp, db_addr_t *ip, str= uct thread *td) return; } =20 - db_print_stack_entry(name, 0, 0, 0, eip); + db_print_stack_entry(name, 0, 0, 0, eip, &(*fp)->f_frame); =20 /* * For a double fault, we have to snag the values from the @@ -467,7 +471,8 @@ db_backtrace(struct thread *td, struct trapframe *tf, s= truct i386_frame *frame, * Don't try to walk back on a stack for a * process that hasn't actually been run yet. */ - db_print_stack_entry(name, 0, 0, 0, pc); + db_print_stack_entry(name, 0, 0, 0, pc, + actframe); break; } first =3D FALSE; @@ -481,7 +486,7 @@ db_backtrace(struct thread *td, struct trapframe *tf, s= truct i386_frame *frame, narg =3D db_numargs(frame); } =20 - db_print_stack_entry(name, narg, argnp, argp, pc); + db_print_stack_entry(name, narg, argnp, argp, pc, actframe); =20 if (actframe !=3D frame) { /* `frame' belongs to caller. */ @@ -495,7 +500,7 @@ db_backtrace(struct thread *td, struct trapframe *tf, s= truct i386_frame *frame, if (INKERNEL((int)pc) && !INKERNEL((int) frame)) { sym =3D db_search_symbol(pc, DB_STGY_ANY, &offset); db_symbol_values(sym, &name, NULL); - db_print_stack_entry(name, 0, 0, 0, pc); + db_print_stack_entry(name, 0, 0, 0, pc, frame); break; } if (!INKERNEL((int) frame)) { --KI6XeYrntNhU1GwB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQt+/nAAoJEJDCuSvBvK1BXUIP/jOiC4stZJ9EEWRosY4ELMDI WJnPA/mukK/tGNY/WXYm3Ro+6tkfe8rbrUoolkIuo3D/dmtunA8JYXA0bkGW3Rbq GsJNfi6Rie4e7I+VkUI5cRzEZ0Atcz5Mw+Vy0ix6UQzGC9TvWvCQI0khfWBVbeyX v1hLx/McVn9iRBCftFtQj0JfGvQmVxLVCMdMQJ59Ds7IwHyPtWbPLtq5f0AEjSfz fCxksMI8sKfvzBHjZA5Cxux5k2Hf97gppXUTAsnHOau2M8oQFNyNNWf7SPnF6iKS Qw5JAhpNePHy6x1VjdiecUjziC4jBeMONWPGRVVwSdYyDNTuzd8kg8bkzPhYaywJ T7+1hjdzvV5fCTVIj53GFnMP60g0cnfyQoEt9nDXW7d6AZofeZWPVtusJUD4bmTz 42btYYzCzMWG/UViGzc3eoYX9kqmi8mut+/0UbaZErLtSlzTb86SXZfmnC/n2OE7 GrnyFXpia1To1YluGWsDV6BrNzhgWZhGmy9C+GyV60alO0MVF18mMRn5OSP1aBIe y2WJhMDTIdL+gnbWnKK0J+AV17BptApVzTfU/3KM2avH7Z83LVngLQDyfSyMtTN0 m3qS7bGMKQXf5oUh+jcGPjGimW4SJYjL75OuyvkWxmXn9IC+RWFhzDR3PyzMf+zc kRpA9qMuQM81N4BSbYjI =Jtls -----END PGP SIGNATURE----- --KI6XeYrntNhU1GwB-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 01:34:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 837FA1EB for ; Fri, 30 Nov 2012 01:34:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45B2B8FC0C for ; Fri, 30 Nov 2012 01:34:19 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id x2so14334438iad.13 for ; Thu, 29 Nov 2012 17:34:13 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=+GAxOWMmKRVeLVFZdpUMXE0W4zxTVDt14ctr7Ednay0=; b=ElaczYluzA/nkWGemrDReAfKuMdeHolO6uwKrxiKly3Ib3GwObPlLgl2cXk0tvP4B2 fJWhHH7UL6N1pKB0kCywKhocDpGmuLuCzzaF6b1IBaI2bcI2XZKfEwFb+heQiXet2IHn XIwh1+rmRvWAAOG4KJj3VIud0EYWDgUmpT9PElj/4ikUS93qBRXWTJTU+Zna+NGQzNP+ UcNu3Ebi1xHJ2oF22PfVDAVumm5LAw0Gl5FWX7mPeT3HXGt8ngvDysw6zWcmL00O0iTW CwohevJnI3T3w+gcgzy6Uh0b7yuqoAH4xBk9h8v6EWaAHlk4EvvWSSxgGMw9Ayvhxqcm Z67A== MIME-Version: 1.0 Received: by 10.50.184.232 with SMTP id ex8mr27098638igc.30.1354239253302; Thu, 29 Nov 2012 17:34:13 -0800 (PST) Sender: carpeddiem@gmail.com Received: by 10.50.151.135 with HTTP; Thu, 29 Nov 2012 17:34:13 -0800 (PST) In-Reply-To: References: Date: Thu, 29 Nov 2012 20:34:13 -0500 X-Google-Sender-Auth: tf4JYwfXKEuY0qPCYe6Z-3bp_ic Message-ID: Subject: Re: Panic on shutdown, r243674M From: Ed Maste To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 01:34:19 -0000 On 29 November 2012 17:36, Ed Maste wrote: > #14 0xffffffff80bfd226 in trap (frame=0xffffff800025e870) > at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:463 > #15 0xffffffff80be71a2 in calltrap () at /tmp/exception-N6d6io.s:179 > #16 0xffffffff808bb9c0 in rman_set_bustag () > at /home/emaste/src/head-ro/sys/kern/subr_rman.c:941 > #17 0xffffffff80356c9d in acpi_cpu_idle () > at /home/emaste/src/head-ro/sys/dev/acpica/acpi_cpu.c:1020 > #18 0xffffffff80beb268 in cpu_idle_acpi (busy=0) > at /home/emaste/src/head-ro/sys/amd64/amd64/machdep.c:685 FWIW I had a second instance of this panic. Previous kernel is from Nov. 14 (prior to the import of ACPICA 20121114) and it has been stable. From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 07:06:40 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 514C9FDE; Fri, 30 Nov 2012 07:06:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id EC7068FC0C; Fri, 30 Nov 2012 07:06:39 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TeKRw-00088u-Bd; Fri, 30 Nov 2012 08:51:48 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Andriy Gapon Subject: Re: [HEADSUP] zfs root pool mounting In-reply-to: <50B6598B.20200@FreeBSD.org> References: <50B6598B.20200@FreeBSD.org> Comments: In-reply-to Andriy Gapon message dated "Wed, 28 Nov 2012 20:35:55 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Nov 2012 08:51:48 +0200 From: Daniel Braniss Message-ID: Cc: FreeBSD current , FreeBSD Stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 07:06:40 -0000 > > Recently some changes were made to how a root pool is opened for root filesystem > mounting. Previously the root pool had to be present in zpool.cache. Now it is > automatically discovered by probing available GEOM providers. > The new scheme is believed to be more flexible. For example, it allows to prepare > a new root pool at one system, then export it and then boot from it on a new > system without doing any extra/magical steps with zpool.cache. It could also be > convenient after zpool split and in some other situations. > > The change was introduced via multiple commits, the latest relevant revision in > head is r243502. The changes are partially MFC-ed, the remaining parts are > scheduled to be MFC-ed soon. > > I have received a report that the change caused a problem with booting on at least > one system. The problem has been identified as an issue in local environment and > has been fixed. Please read on to see if you might be affected when you upgrade, > so that you can avoid any unnecessary surprises. > > You might be affected if you ever had a pool named the same as your current root > pool. And you still have any disks connected to your system that belonged to that > pool (in whole or via some partitions). And that pool was never properly > destroyed using zpool destroy, but merely abandoned (its disks > re-purposed/re-partitioned/reused). > > If all of the above are true, then I recommend that you run 'zdb -l ' for > all suspect disks and their partitions (or just all disks and partitions). If > this command reports at least one valid ZFS label for a disk or a partition that > do not belong to any current pool, then the problem may affect you. > > The best course is to remove the offending labels. > > If you are affected, please follow up to this email. GREATE!!!! in a diskless environment, /boot is read only, and the zpool.cache issue has been bothering me ever since, there was no way (and I tried) to re route it. thanks, danny From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 11:13:15 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72122E74; Fri, 30 Nov 2012 11:13:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8769D8FC13; Fri, 30 Nov 2012 11:13:13 +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 NAA19850; Fri, 30 Nov 2012 13:13:12 +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 1TeOWu-0002ce-8t; Fri, 30 Nov 2012 13:13:12 +0200 Message-ID: <50B894C5.5060102@FreeBSD.org> Date: Fri, 30 Nov 2012 13:13:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: Panic on shutdown, r243674M References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 11:13:15 -0000 on 30/11/2012 00:36 Ed Maste said the following: > Rev 243674 with some minor local changes. Please try this patch: http://people.freebsd.org/~avg/acpi_cpu_notify.2.diff I should have committed this earlier, but the fact that we were not getting much problems when updating resources in place lead me to believe that we would not get more problems when first deleting and then re-creating resources. If the patch works OK, I'll commit it tomorrow. > #12 0xffffffff80bfd775 in trap_fatal (frame=0xffffff800025e870, > eva=) > at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:867 > #13 0xffffffff80bfda3a in trap_pfault (frame=0x0, usermode=0) > at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:698 > #14 0xffffffff80bfd226 in trap (frame=0xffffff800025e870) > at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:463 > #15 0xffffffff80be71a2 in calltrap () at /tmp/exception-N6d6io.s:179 > #16 0xffffffff808bb9c0 in rman_set_bustag () > at /home/emaste/src/head-ro/sys/kern/subr_rman.c:941 > #17 0xffffffff80356c9d in acpi_cpu_idle () > at /home/emaste/src/head-ro/sys/dev/acpica/acpi_cpu.c:1020 > #18 0xffffffff80beb268 in cpu_idle_acpi (busy=0) > at /home/emaste/src/head-ro/sys/amd64/amd64/machdep.c:685 > #19 0xffffffff80beb308 in cpu_idle (busy=0) > at /home/emaste/src/head-ro/sys/amd64/amd64/machdep.c:839 > #20 0xffffffff808a6058 in sched_idletd (dummy=) > at /home/emaste/src/head-ro/sys/kern/sched_ule.c:2665 > #21 0xffffffff808524d4 in fork_exit ( > callout=0xffffffff808a5e20 , arg=0x0, > frame=0xffffff800025eac0) > at /home/emaste/src/head-ro/sys/kern/kern_fork.c:995 > #22 0xffffffff80be76de in fork_trampoline () at /tmp/exception-N6d6io.s:501 > #23 0x0000000000000000 in ?? () -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 12:48:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B967D3DB; Fri, 30 Nov 2012 12:48:32 +0000 (UTC) (envelope-from sig6247@gmail.com) Received: from mail-ye0-f182.google.com (mail-ye0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 550898FC14; Fri, 30 Nov 2012 12:48:32 +0000 (UTC) Received: by mail-ye0-f182.google.com with SMTP id q5so43083yen.13 for ; Fri, 30 Nov 2012 04:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:cc:subject:in-reply-to:references :mime-version:content-type; bh=qXp7rUZlhnsNhLRthaKsOZwbbwSEzH4phdoKUQXBtL0=; b=aAmIQ79HBueetspzT78j1DGGBwoalgk+ttC26wz6BmPawRfsirXLOT3TgxtvI9ZcPM 5ffGlwvuMuz48Jjp/6uJQMDdiUal6xDVPSrKQ7u6eRN2T7One3sZjcnyAb4eaRYv/C5A ewyo5W20L7VFYWAjiQZaRHNNisoy6d5k6XIgbfGTYqJNqN0gv8Y8syjFtJPP3/xJqkk3 99salmwbf7jPq/TLnGiweTwMPEgNC8OJS9TjcHp92UDKOn9OIyfz3uUt3HTZdX3C7DbP oHer/On4ipIG2CJbZAkRkq76uIDQAEs8CuCtOmKqJixO+5brY7pO97cvSEoNueXMcT/R NxjQ== Received: by 10.236.124.131 with SMTP id x3mr840252yhh.14.1354279366065; Fri, 30 Nov 2012 04:42:46 -0800 (PST) Received: from localhost ([165.254.32.192]) by mx.google.com with ESMTPS id d66sm4703080yhe.1.2012.11.30.04.42.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Nov 2012 04:42:45 -0800 (PST) Message-ID: <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> Date: Fri, 30 Nov 2012 04:42:45 -0800 (PST) From: sig6247 To: Konstantin Belousov Subject: Re: clang compiled kernel panic when mounting zfs root on i386 In-Reply-To: <20121129232944.GQ3013@kib.kiev.ua> (Konstantin Belousov's message of "Fri, 30 Nov 2012 01:29:44 +0200") References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, Bruce Evans , fs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 12:48:32 -0000 On Fri, 30 Nov 2012 01:29:44 +0200, Konstantin Belousov wrote: > Please apply the patch below and obtain the backtrace of the double fault > panic again. I will commit the patch later. Thanks for the patch. WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot []... Fatal double fault: eip = 0xc0e93e07 esp = 0xc86bffbc ebp = 0xc86c0032 cpuid = 1; apic id = 01 panic: double fault cpuid = 1 KDB: enter: panic [ thread pid 1 tid 100002 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> bt Tracing pid 1 tid 100002 td 0xc89efbc0 kdb_enter(c1065960,c1065960,c10b903b,c139f438,aef01785,...) at kdb_enter+0x3d/frame 0xc139f3f0 panic(c10b903b,1,1,1,c86c0032,...) at panic+0x14b/frame 0xc139f42c dblfault_handler() at dblfault_handler+0xab/frame 0xc139f42c --- trap 0x17, eip = 0xc0e93e07, esp = 0xc86bffbc, ebp = 0xc86c0032 --- __qdivrem(0,aba80000,c10d,98600000,68c119,...) at __qdivrem+0x197/frame 0xc86c0032 db> From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 13:45:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0704E2ED for ; Fri, 30 Nov 2012 13:45:57 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 55A7F8FC12 for ; Fri, 30 Nov 2012 13:45:56 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so596164lbb.13 for ; Fri, 30 Nov 2012 05:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=mzGlJJ3YVYdRiqRlxVebDB3jlXPgm+5vgs+nLWrZx28=; b=iSlHOjb/cl1JjVxrOi6WOw+FpXqNA9raF0sSIoHQIYwE20vwDMSdyy8S12q5js0qpS U5L3pwt2ri1XbGtjZkfv5RDXUGpuHuBF7/lZdJ0U5F/1lFXzPKXxMd5Ko8RlzO8ZXMHN 2aFU6HJNGcJF1FvkqUX10NldYBwI305YfeG945hR1vKqOwWf2MbbDpNApv7RrKKpvKK0 WspOyh1S5euIOx2gtBK0PVQURSpQbJiTfVIpy6nKWUy0rBpoE8QYg6BMW7sr1nPbfbIQ QJLajp0pVMWDDBAPzaheOJu5t+2dDPEmPlaW8XkV1CcB7g8dmxxiCGu7wR6xvyrlz7+K E8Dg== MIME-Version: 1.0 Received: by 10.112.100.195 with SMTP id fa3mr890556lbb.38.1354283155204; Fri, 30 Nov 2012 05:45:55 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.12.226 with HTTP; Fri, 30 Nov 2012 05:45:55 -0800 (PST) Date: Fri, 30 Nov 2012 14:45:55 +0100 X-Google-Sender-Auth: fOGYcmnd8A95udwiunVGIwm8vbY Message-ID: Subject: 9.1-RC3 default Linux ALSA configuration From: CeDeROM To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 13:45:57 -0000 Hello :-) I have installed and started Skype (2.1 and 2.2 devel) with success using Linux binaries provided in port tree. However there is an issue with default ALSA configuration and sound/calls does not work properly off out the box. I suggest to set /dev/dsp0 and /dev/mixer0 as default devices in the alsa configuration, so the sound works on the default audio device. Right now it does not work at all. # pcm-oss plugin configuration pcm.oss { type oss device /dev/dsp0 hint { description "Open Sound System" } } ctl.oss { type oss device /dev/mixer0 hint { description "Open Sound System" } } Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 15:10:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73B6AB79; Fri, 30 Nov 2012 15:10:00 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2659A8FC12; Fri, 30 Nov 2012 15:09:59 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so1009769iec.13 for ; Fri, 30 Nov 2012 07:09:59 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sn9Jiu83G33NegaLDz2j3QpgjmRaFIuyJFKIdJ3GG1w=; b=l6YkoxJuz8pP/77WqYv52emThGXiwaiqwr9mIJDN9+0Q+lw9wzzSx80HuhpTVS4bEf 5g0lUqohE3LvkrFlQjFtSfv/IwTCnH+lKEukn0RM1COCNCnkDv4t91uhT4DKQdOYevOK EK9XWg7FEkzAJ7xkmIoZJxc3ZeQIy4xQ3kri/uv3X/leheN9kSYlIbld/k2FbOvBYtDQ fFtXTFfYiGCotM7Vr4sKKtvqjttvr+lgVKQWiPnv7w4VPzwv9CLdiQnDyiT8CCmSnkzt RO6vtokAlcJ98gYRiaBq7aWPCcjJxF988eKYIXC15r5Csucg7OLmvTVEWhafCg0OSS3u b9mg== MIME-Version: 1.0 Received: by 10.50.56.195 with SMTP id c3mr1277345igq.30.1354288199568; Fri, 30 Nov 2012 07:09:59 -0800 (PST) Sender: carpeddiem@gmail.com Received: by 10.50.151.135 with HTTP; Fri, 30 Nov 2012 07:09:59 -0800 (PST) In-Reply-To: <50B894C5.5060102@FreeBSD.org> References: <50B894C5.5060102@FreeBSD.org> Date: Fri, 30 Nov 2012 10:09:59 -0500 X-Google-Sender-Auth: heQSTyGrR-FPgNQtSg1OIsbHsIM Message-ID: Subject: Re: Panic on shutdown, r243674M From: Ed Maste To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 15:10:00 -0000 > Please try this patch: > http://people.freebsd.org/~avg/acpi_cpu_notify.2.diff > > I should have committed this earlier, but the fact that we were not getting much > problems when updating resources in place lead me to believe that we would not > get more problems when first deleting and then re-creating resources. > > If the patch works OK, I'll commit it tomorrow. It works fine for me (of course I can't say with certainty that I've exercised the path that previously panicked). Please go ahead and commit. From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 15:15:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 296B3DDC; Fri, 30 Nov 2012 15:15:09 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2E18FC0C; Fri, 30 Nov 2012 15:15:08 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAUFF7d5046307; Fri, 30 Nov 2012 08:15:07 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAUFF3AZ042544; Fri, 30 Nov 2012 08:15:03 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Is cross-world building broken? From: Ian Lepore To: Garrett Cooper In-Reply-To: References: <6961B0D9-F823-415C-A105-7DAC8339CB30@gmail.com> <3EB9F7EB-D9C8-40CB-BF28-21B7BE59C94C@gmail.com> <20121128071252.7AC1958094@chaos.jnpr.net> <20121128231538.8AB6758094@chaos.jnpr.net> <20121129000106.540ED58094@chaos.jnpr.net> Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Nov 2012 08:15:03 -0700 Message-ID: <1354288503.69940.410.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Andrew Turner , Adrian Chadd , FreeBSD Current , "Simon J. Gerraty" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 15:15:09 -0000 On Wed, 2012-11-28 at 16:19 -0800, Garrett Cooper wrote: > On Wed, Nov 28, 2012 at 4:07 PM, Adrian Chadd wrote: > > top posting, out of laziness and busy-ness at work.. > > > > Ok. So: > > > > * make installworld/installkernel/distribution - set DESTDIR on the command line > > * make buildworld/make buildkernel/make - > > don't set DESTDIR? > > (re-CCing -current@) > Correct. DESTDIR should only be used for install targets (install, > installworld, installkernel, distribution, etc), and not for any of > the other build-related targets on FreeBSD. [as the meme goes] "If you > set DESTDIR when building, you're gonna have a bad time". > HTH! > -Garrett So when did this break, and why can't it be fixed? I've been using DESTDIR= on the command line for cross-builds as long as I've been doing cross-builds and have never had a problem; doing this is just built in to the scripts I use for cross-building. It's still working for me in some sandboxes that haven't been updated since r240278. Also, how about "make DESTDIR=foo buildkernel installkernel" which is something I've been doing for years, you're saying that now that won't work because DESTDIR will be there during the build part? This just seems all wrong. -- Ian From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 16:47:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1274A4E0; Fri, 30 Nov 2012 16:47:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9DEBB8FC08; Fri, 30 Nov 2012 16:47:23 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qAUGlGo8028201; Fri, 30 Nov 2012 18:47:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qAUGlGo8028201 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qAUGlFdd028200; Fri, 30 Nov 2012 18:47:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Nov 2012 18:47:15 +0200 From: Konstantin Belousov To: sig6247 Subject: Re: clang compiled kernel panic when mounting zfs root on i386 Message-ID: <20121130164715.GW3013@kib.kiev.ua> References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iwX7oKFvAj2SwWc7" Content-Disposition: inline In-Reply-To: <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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, Bruce Evans , fs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 16:47:24 -0000 --iwX7oKFvAj2SwWc7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 30, 2012 at 04:42:45AM -0800, sig6247 wrote: > On Fri, 30 Nov 2012 01:29:44 +0200, Konstantin Belousov wrote: >=20 > > Please apply the patch below and obtain the backtrace of the double fau= lt > > panic again. I will commit the patch later. >=20 > Thanks for the patch.=20 >=20 > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from zfs:zroot []... >=20 > Fatal double fault: > eip =3D 0xc0e93e07 > esp =3D 0xc86bffbc > ebp =3D 0xc86c0032 > cpuid =3D 1; apic id =3D 01 > panic: double fault > cpuid =3D 1 > KDB: enter: panic > [ thread pid 1 tid 100002 ] > Stopped at kdb_enter+0x3d: movl $0,kdb_why > db> bt > Tracing pid 1 tid 100002 td 0xc89efbc0 > kdb_enter(c1065960,c1065960,c10b903b,c139f438,aef01785,...) at kdb_enter+= 0x3d/frame 0xc139f3f0 > panic(c10b903b,1,1,1,c86c0032,...) at panic+0x14b/frame 0xc139f42c > dblfault_handler() at dblfault_handler+0xab/frame 0xc139f42c > --- trap 0x17, eip =3D 0xc0e93e07, esp =3D 0xc86bffbc, ebp =3D 0xc86c0032= --- > __qdivrem(0,aba80000,c10d,98600000,68c119,...) at __qdivrem+0x197/frame 0= xc86c0032 > db>=20 Hm, this is not very useful. Although the panic is again caused by the stack overflow, most likely (please also include the output of the "show thread" =66rom ddb), it is at different place, and probably at the leaf function. Can you try some more times, so that we could see 'big' backtrace ? --iwX7oKFvAj2SwWc7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQuOMTAAoJEJDCuSvBvK1Bfb4QAKfQlzWqbvLNxc0iMg7NQlJ8 ZlJanY91GWIuZbgtSYSwkLZ0mJ0xhHgCRGJLFnVncZGY56bPmIDnkV0h776RY7RU 2fH1BI2QLCEVqRH/y4n3uoJZRfdZ2xrqRuvw3qkWQ5xUbMgTFZamckv1Z0rTsp9w NKwzFcWBGvZeioJJALMDbKr4FtmPeFK1K61aQlAL2WzwbTn7xd3Iqs9CrMm8oUEi FMl3mHajW61g2dYY1LwxEpR4/GnMmJARFqMRugN68W0PyfXvYfX7QFJcL/TuZZHS 3pl3fvVIR00sCmEwT1xYyI4Q9oF/5Hs5ybFFFBkLX0CABXyVoAZbUo/Z+JldM6SQ VgjMF+qucbcacBCYerSXjTQv0Hv+3P4ALMepJBuwiE/DCwnWe4UO3LhpUx1rVR5X 8siL9sE4u0qkyxirti7TTlOQS30MEneyYtybNQaiY3cn5YCrCy5otovc047hd65w JIX6I5R0ZS84KoXQe/gfyOcWz87zfFInVfRWevz62x7rfQqF3srlIenpfE1d0ZP1 qRYKGZcRiR02RACoLerlTKukj6ZzXK0XXTt84GZaqzUZvb3tzYS6e22gAEKRd7T6 xcvNILDcPaUHRRLr8+OPGPJNj0ZpKkeGT9EtVWSXBz+Sy+v7jB+nF8Yw4Y85DvnO 4UPihvsOQq9VptkFTkn0 =rLF0 -----END PGP SIGNATURE----- --iwX7oKFvAj2SwWc7-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 17:30:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D23219E; Fri, 30 Nov 2012 17:30:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id D664B8FC0C; Fri, 30 Nov 2012 17:30:57 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so6250454wib.1 for ; Fri, 30 Nov 2012 09:30:56 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6DJgrKbeoHa4z6qN8TzEKP9GSSSwBfU7oneAt2JwgJ0=; b=diVahVeagqBR9Mj0WdLBLyclc9jHE+X9WdMGVEmksvl5VbtRRS2sXwoCRRRLn5DyjJ Ij9vZgaPvuCtx5+V5fxH2cvjcYnzojKmTsfKoW49CvbWmAUacRuURq4QObC5o9rm8nFD tvf4fT+q9sC1d0d7JtzPO+hi0A/JXlK2IvZlHb0QyCGLKCcldHCPnhfDQHT/lcEjhqoS s6BdNdZFOwpe9sL+4E4tD1umz2kD/tSZGs4Tyeb6btpSKMJvBYHXqHON38TYZiT6fQoG XlJS81TPZzBghgzENIXpgHGIQaVNTbRw6cjI2E0Tgzhid0aujccujT27f4mMlmz+kgYI Tnyg== MIME-Version: 1.0 Received: by 10.216.200.160 with SMTP id z32mr758518wen.53.1354296656878; Fri, 30 Nov 2012 09:30:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 30 Nov 2012 09:30:56 -0800 (PST) In-Reply-To: <1354288503.69940.410.camel@revolution.hippie.lan> References: <6961B0D9-F823-415C-A105-7DAC8339CB30@gmail.com> <3EB9F7EB-D9C8-40CB-BF28-21B7BE59C94C@gmail.com> <20121128071252.7AC1958094@chaos.jnpr.net> <20121128231538.8AB6758094@chaos.jnpr.net> <20121129000106.540ED58094@chaos.jnpr.net> <1354288503.69940.410.camel@revolution.hippie.lan> Date: Fri, 30 Nov 2012 09:30:56 -0800 X-Google-Sender-Auth: RZFRRjQ0Ph2thJ3Y65uCNJXKR-c Message-ID: Subject: Re: Is cross-world building broken? From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , Andrew Turner , FreeBSD Current , "Simon J. Gerraty" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 17:30:58 -0000 So, DESTDIR works fine if you use it for the install phases. If you use it for the build phases, it confuses things. I'm not sure why this has been working for the past 12 months or so. I've modified my build scripts to: * Add DESTDIR to installkernel, installworld, distribution * Not set DESTDIR for buildworld, buildkernel. And that seems to work. Thanks for the advice everyone. Adrian From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 17:43:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BC574FB for ; Fri, 30 Nov 2012 17:43:32 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 102678FC12 for ; Fri, 30 Nov 2012 17:43:31 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so600312pbc.13 for ; Fri, 30 Nov 2012 09:43:31 -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:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=9KCZmYSuT/vEpcBViaSJ3hqDeuBjuBtfCS4jlwYhKC8=; b=l2soM1aLym6azNDYU0fA+NcM4iE++e8cUlNuGsM/NivBng2EsHOqDLvuW1ga+5dMTt ooW0oC9s1Y/KSGucn1sHhs+EJIhB8DG0FhI5kdnZbxvIGVbrGpnol0qjbfEoGlYBmShW y1u12vIE8a//XMTjpNjftxNVaVs62MPDCw7CBV7E0glLUEby7myZTP76m0UuQNOg08ww JdK0CLKeM3Uq8syUiYRvJL+gtwAS7d8j3br3AreTbmmP7pNDs0aM6gWZFE+aZdivS80H yyhB+hy2/IHQVnyoyyeHY4IWyHfSXQtky8FF/WL+FbqbSIo6cscGq3nU9BLEnBIT+jtu 7tEQ== Received: by 10.66.80.194 with SMTP id t2mr4997810pax.43.1354297411511; Fri, 30 Nov 2012 09:43:31 -0800 (PST) Received: from bakeneko.local (108-213-216-134.lightspeed.sntcca.sbcglobal.net. [108.213.216.134]) by mx.google.com with ESMTPS id vn2sm3351288pbc.31.2012.11.30.09.43.28 (version=SSLv3 cipher=OTHER); Fri, 30 Nov 2012 09:43:30 -0800 (PST) Message-ID: <50B8F021.50301@gmail.com> Date: Fri, 30 Nov 2012 09:42:57 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121106 Thunderbird/10.0.10 MIME-Version: 1.0 To: Ryan Stone Subject: Re: pw keeps setting /etc/group to 0600 References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 17:43:32 -0000 On 11/17/12 07:24, Ryan Stone wrote: > /etc/group is supposed to be world-reable, right? Tools like groups or pw > groupshow certainly seem to think so: > > [rstone@rstone-server ~]groups > 1001 920 > [rstone@rstone-server ~]ls -l /etc/group > -rw------- 1 root 0 482 Nov 14 21:02 /etc/group > [rstone@rstone-server ~]sudo chmod a+r /etc/group > Password: > [rstone@rstone-server ~]groups > rstone vboxusers > [rstone@rstone-server ~]sudo pw groupadd foo > [rstone@rstone-server ~]ls -l /etc/group > -rw------- 1 root 0 494 Nov 17 10:19 /etc/group > [rstone@rstone-server ~] > > I'm not sure what caused the regression. I've been seeing the problem > since I first installed -CURRENT on the machine a couple of weeks ago. > _______________________________________________ > 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" Interesting, I noticed my pw segfaulted twice on 'pw groupdel' twice out of three groups deleted. Not sure if related. I'm at r243502. Matt From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 18:14:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4784DCF7; Fri, 30 Nov 2012 18:14:31 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id D67878FC15; Fri, 30 Nov 2012 18:14:30 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAUIETPo051218; Fri, 30 Nov 2012 11:14:30 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAUIERc3042639; Fri, 30 Nov 2012 11:14:27 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Is cross-world building broken? From: Ian Lepore To: "Simon J. Gerraty" In-Reply-To: <20121130173656.9A9BE58094@chaos.jnpr.net> References: <6961B0D9-F823-415C-A105-7DAC8339CB30@gmail.com> <3EB9F7EB-D9C8-40CB-BF28-21B7BE59C94C@gmail.com> <20121128071252.7AC1958094@chaos.jnpr.net> <20121128231538.8AB6758094@chaos.jnpr.net> <20121129000106.540ED58094@chaos.jnpr.net> <1354288503.69940.410.camel@revolution.hippie.lan> <20121130173656.9A9BE58094@chaos.jnpr.net> Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Nov 2012 11:14:27 -0700 Message-ID: <1354299267.69940.434.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Andrew Turner , Adrian Chadd , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 18:14:31 -0000 On Fri, 2012-11-30 at 09:36 -0800, Simon J. Gerraty wrote: > On Fri, 30 Nov 2012 08:15:03 -0700, Ian Lepore writes: > >So when did this break, and why can't it be fixed? I've been using > > Sorry I missed the begining of this thread, > is anything broken? > I haven't experienced anything myself, I assumed because I've been too busy to update any of my -current sandboxes for weeks. I was just going by the earlier messages in this thread, which were roughly "A cross-build breaks early in the process if DESTDIR is set" followed by "DESTDIR must only be set for installworld, buildworld, and distribute targets." If either of those statements is true, that strikes me as breakage, because it never used to be that way. Maybe I've misunderstood something about the earlier messages in the thread. -- Ian From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 17:47:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65384684; Fri, 30 Nov 2012 17:47:20 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id A90A28FC12; Fri, 30 Nov 2012 17:47:19 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKULjxIRpJMuuc0NF2DwDALEqHwx+iH0Sf@postini.com; Fri, 30 Nov 2012 09:47:19 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 30 Nov 2012 09:36:57 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qAUHau306838; Fri, 30 Nov 2012 09:36:56 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 9A9BE58094; Fri, 30 Nov 2012 09:36:56 -0800 (PST) To: Ian Lepore Subject: Re: Is cross-world building broken? In-Reply-To: <1354288503.69940.410.camel@revolution.hippie.lan> References: <6961B0D9-F823-415C-A105-7DAC8339CB30@gmail.com> <3EB9F7EB-D9C8-40CB-BF28-21B7BE59C94C@gmail.com> <20121128071252.7AC1958094@chaos.jnpr.net> <20121128231538.8AB6758094@chaos.jnpr.net> <20121129000106.540ED58094@chaos.jnpr.net> <1354288503.69940.410.camel@revolution.hippie.lan> Comments: In-reply-to: Ian Lepore message dated "Fri, 30 Nov 2012 08:15:03 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Fri, 30 Nov 2012 09:36:56 -0800 Message-ID: <20121130173656.9A9BE58094@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Fri, 30 Nov 2012 18:15:35 +0000 Cc: Garrett Cooper , Andrew Turner , Adrian Chadd , FreeBSD Current , sjg@juniper.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 17:47:20 -0000 On Fri, 30 Nov 2012 08:15:03 -0700, Ian Lepore writes: >So when did this break, and why can't it be fixed? I've been using Sorry I missed the begining of this thread, is anything broken? >Also, how about "make DESTDIR=foo buildkernel installkernel" which is >something I've been doing for years, you're saying that now that won't >work because DESTDIR will be there during the build part? It will be set - but that doesn't mean it would have any effect/impact. Oh and contrary to what I told Adrian earlier, buildworld's manipulation of DESTDIR would generally be unaffected, because the makefiles do not actually attempt to set it (vs simply passing a new value to a submake). An demo might help. In the following BINDIR is affected by a value set in either environment or on commandline LIBDIR is only affected by a value set on commandline The DESTDIR seen by install run by child is unaffected by anything, even though the values for LIBDIR and BINDIR are. --------------------8<-------------------- BINDIR?= /bin LIBDIR= /lib all: install child install: @echo DESTDIR=${DESTDIR} @echo install stuff to ${DESTDIR}${BINDIR} @echo install stuff to ${DESTDIR}${LIBDIR} child: ${MAKE} -f ${MAKEFILE} DESTDIR=/tmp/childest install demo: all envset cmdset envset: BINDIR=/sbin LIBDIR=/usr/lib DESTDIR=$@ ${MAKE} -f ${MAKEFILE} cmdset: ${MAKE} -f ${MAKEFILE} BINDIR=/sbin LIBDIR=/usr/lib DESTDIR=$@ --------------------8<-------------------- $ make -r -f /homes/sjg/make-tests/destdir demo DESTDIR= install stuff to /bin install stuff to /lib make -f /homes/sjg/make-tests/destdir DESTDIR=/tmp/childest install DESTDIR=/tmp/childest install stuff to /tmp/childest/bin install stuff to /tmp/childest/lib BINDIR=/sbin LIBDIR=/usr/lib DESTDIR=envset make -f /homes/sjg/make-tests/destdir DESTDIR=envset install stuff to envset/sbin install stuff to envset/lib make -f /homes/sjg/make-tests/destdir DESTDIR=/tmp/childest install DESTDIR=/tmp/childest install stuff to /tmp/childest/sbin install stuff to /tmp/childest/lib make -f /homes/sjg/make-tests/destdir BINDIR=/sbin LIBDIR=/usr/lib DESTDIR=cmdset DESTDIR=cmdset install stuff to cmdset/sbin install stuff to cmdset/usr/lib make -f /homes/sjg/make-tests/destdir DESTDIR=/tmp/childest install DESTDIR=/tmp/childest install stuff to /tmp/childest/sbin install stuff to /tmp/childest/lib $ From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 22:16:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 730E794E; Fri, 30 Nov 2012 22:16:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 25AD78FC0C; Fri, 30 Nov 2012 22:16:45 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so664369pad.13 for ; Fri, 30 Nov 2012 14:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=eH0fnyrZdtwOli4w/7pjcGWbyxO8DQADfixRui/jO/Q=; b=mDQk+e8QUgBqQeyBkcIC1SZ4MctGidz6UV0q9sJDzo/w4w0qdn0ExeR96mC/WwOdZf CBIYgnh9X/Hat0X3CQj1SAQGweBvLOQPhyuYR94ZxbEvXudqJ/Yn2qDrr8ap6sp1bNO8 09JECIIwpJp/L5/7JehGcDxDfEW0aGnn0KkLmoB3IYr9rhSlC1GVN7w2Ia7sBw2nvcjm SigjcMkimJBruchNV59EFU4bncK3XXzzPloSY88EFtQumjLJSQVR7OQo8PGza7ZXrUEe stAmC77g+oUE4+Aune8aLbkW+M+hlRgAed5TJoH+pXwF26NH8tYI/+MpeAtLQa3eQFkQ 6Iew== Received: by 10.68.253.66 with SMTP id zy2mr8025888pbc.131.1354313804839; Fri, 30 Nov 2012 14:16:44 -0800 (PST) Received: from [192.168.20.12] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id bt2sm3535319pab.15.2012.11.30.14.16.42 (version=SSLv3 cipher=OTHER); Fri, 30 Nov 2012 14:16:43 -0800 (PST) References: <6961B0D9-F823-415C-A105-7DAC8339CB30@gmail.com> <3EB9F7EB-D9C8-40CB-BF28-21B7BE59C94C@gmail.com> <20121128071252.7AC1958094@chaos.jnpr.net> <20121128231538.8AB6758094@chaos.jnpr.net> <20121129000106.540ED58094@chaos.jnpr.net> <1354288503.69940.410.camel@revolution.hippie.lan> <20121130173656.9A9BE58094@chaos.jnpr.net> <1354299267.69940.434.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <1354299267.69940.434.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4DB7FB56-359B-42DA-BB6F-0F4F33C772C5@gmail.com> X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: Is cross-world building broken? Date: Fri, 30 Nov 2012 14:16:40 -0800 To: Ian Lepore Cc: Andrew Turner , Adrian Chadd , FreeBSD Current , "Simon J. Gerraty" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Nov 2012 22:16:46 -0000 On Nov 30, 2012, at 10:14 AM, Ian Lepore wro= te: > On Fri, 2012-11-30 at 09:36 -0800, Simon J. Gerraty wrote: >> On Fri, 30 Nov 2012 08:15:03 -0700, Ian Lepore writes: >>> So when did this break, and why can't it be fixed? I've been using >>=20 >> Sorry I missed the begining of this thread, >> is anything broken? >=20 > I haven't experienced anything myself, I assumed because I've been too > busy to update any of my -current sandboxes for weeks. I was just going > by the earlier messages in this thread, which were roughly=20 >=20 > "A cross-build breaks early in the process if DESTDIR is set"=20 >=20 > followed by=20 >=20 > "DESTDIR must only be set for installworld, buildworld, and distribute > targets." s/buildworld/installkernel/ > If either of those statements is true, that strikes me as breakage, > because it never used to be that way. >=20 > Maybe I've misunderstood something about the earlier messages in the > thread. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 03:18:04 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3818AB5; Sat, 1 Dec 2012 03:18:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 96F148FC1A; Sat, 1 Dec 2012 03:18:04 +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 qB13HvpU059006; Fri, 30 Nov 2012 22:17:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qB13HvbL058987; Sat, 1 Dec 2012 03:17:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 03:17:57 GMT Message-Id: <201212010317.qB13HvbL058987@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 03:18:04 -0000 TB --- 2012-12-01 01:21:19 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 01:21: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 --- 2012-12-01 01:21:19 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-12-01 01:21:19 - cleaning the object tree TB --- 2012-12-01 01:21:19 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 01:21:19 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2012-12-01 01:21:19 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 01:22:05 - /usr/local/bin/svn update /src TB --- 2012-12-01 01:22:12 - At svn revision 243740 TB --- 2012-12-01 01:22:13 - building world TB --- 2012-12-01 01:22:13 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 01:22:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 01:22:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 01:22:13 - SRCCONF=/dev/null TB --- 2012-12-01 01:22:13 - TARGET=ia64 TB --- 2012-12-01 01:22:13 - TARGET_ARCH=ia64 TB --- 2012-12-01 01:22:13 - TZ=UTC TB --- 2012-12-01 01:22:13 - __MAKE_CONF=/dev/null TB --- 2012-12-01 01:22:13 - cd /src TB --- 2012-12-01 01:22:13 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 01:22:18 UTC 2012 >>> 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 Sat Dec 1 03:01:48 UTC 2012 TB --- 2012-12-01 03:01:48 - generating LINT kernel config TB --- 2012-12-01 03:01:48 - cd /src/sys/ia64/conf TB --- 2012-12-01 03:01:48 - /usr/bin/make -B LINT TB --- 2012-12-01 03:01:48 - cd /src/sys/ia64/conf TB --- 2012-12-01 03:01:48 - /usr/sbin/config -m LINT TB --- 2012-12-01 03:01:48 - building LINT kernel TB --- 2012-12-01 03:01:48 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 03:01:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 03:01:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 03:01:48 - SRCCONF=/dev/null TB --- 2012-12-01 03:01:48 - TARGET=ia64 TB --- 2012-12-01 03:01:48 - TARGET_ARCH=ia64 TB --- 2012-12-01 03:01:48 - TZ=UTC TB --- 2012-12-01 03:01:48 - __MAKE_CONF=/dev/null TB --- 2012-12-01 03:01:48 - cd /src TB --- 2012-12-01 03:01:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 1 03:01:49 UTC 2012 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/vfs_lookup.c /src/sys/kern/vfs_lookup.c:214:54: error: macro "AUDIT_ARG_UPATH1" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c: In function 'namei': /src/sys/kern/vfs_lookup.c:214: error: 'AUDIT_ARG_UPATH1' undeclared (first use in this function) /src/sys/kern/vfs_lookup.c:214: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_lookup.c:214: error: for each function it appears in.) /src/sys/kern/vfs_lookup.c:216:54: error: macro "AUDIT_ARG_UPATH2" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c:216: error: 'AUDIT_ARG_UPATH2' undeclared (first use in this function) *** [vfs_lookup.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 03:17:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 03:17:57 - ERROR: failed to build LINT kernel TB --- 2012-12-01 03:17:57 - 5135.34 user 1156.66 system 6998.49 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 03:42:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35765CBF; Sat, 1 Dec 2012 03:42:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E9ABB8FC0C; Sat, 1 Dec 2012 03:42: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 qB13gpEE006175; Fri, 30 Nov 2012 22:42:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qB13gpMv006152; Sat, 1 Dec 2012 03:42:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 03:42:51 GMT Message-Id: <201212010342.qB13gpMv006152@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 03:42:53 -0000 TB --- 2012-12-01 02:32:43 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 02:32: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 --- 2012-12-01 02:32:43 - starting HEAD tinderbox run for mips/mips TB --- 2012-12-01 02:32:43 - cleaning the object tree TB --- 2012-12-01 02:32:43 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 02:32:43 - cd /tinderbox/HEAD/mips/mips TB --- 2012-12-01 02:32:43 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 02:33:46 - /usr/local/bin/svn update /src TB --- 2012-12-01 02:33:53 - At svn revision 243742 TB --- 2012-12-01 02:33:54 - building world TB --- 2012-12-01 02:33:54 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 02:33:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 02:33:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 02:33:54 - SRCCONF=/dev/null TB --- 2012-12-01 02:33:54 - TARGET=mips TB --- 2012-12-01 02:33:54 - TARGET_ARCH=mips TB --- 2012-12-01 02:33:54 - TZ=UTC TB --- 2012-12-01 02:33:54 - __MAKE_CONF=/dev/null TB --- 2012-12-01 02:33:54 - cd /src TB --- 2012-12-01 02:33:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 02:34:00 UTC 2012 >>> 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 Sat Dec 1 03:40:47 UTC 2012 TB --- 2012-12-01 03:40:47 - cd /src/sys/mips/conf TB --- 2012-12-01 03:40:47 - /usr/sbin/config -m ADM5120 TB --- 2012-12-01 03:40:47 - skipping ADM5120 kernel TB --- 2012-12-01 03:40:47 - cd /src/sys/mips/conf TB --- 2012-12-01 03:40:47 - /usr/sbin/config -m ALCHEMY TB --- 2012-12-01 03:40:47 - skipping ALCHEMY kernel TB --- 2012-12-01 03:40:47 - cd /src/sys/mips/conf TB --- 2012-12-01 03:40:47 - /usr/sbin/config -m AP91 TB --- 2012-12-01 03:40:47 - building AP91 kernel TB --- 2012-12-01 03:40:47 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 03:40:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 03:40:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 03:40:47 - SRCCONF=/dev/null TB --- 2012-12-01 03:40:47 - TARGET=mips TB --- 2012-12-01 03:40:47 - TARGET_ARCH=mips TB --- 2012-12-01 03:40:47 - TZ=UTC TB --- 2012-12-01 03:40:47 - __MAKE_CONF=/dev/null TB --- 2012-12-01 03:40:47 - cd /src TB --- 2012-12-01 03:40:47 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Sat Dec 1 03:40:47 UTC 2012 >>> 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 [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=768 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_lookup.c /src/sys/kern/vfs_lookup.c:214:54: error: macro "AUDIT_ARG_UPATH1" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c: In function 'namei': /src/sys/kern/vfs_lookup.c:214: error: 'AUDIT_ARG_UPATH1' undeclared (first use in this function) /src/sys/kern/vfs_lookup.c:214: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_lookup.c:214: error: for each function it appears in.) /src/sys/kern/vfs_lookup.c:216:54: error: macro "AUDIT_ARG_UPATH2" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c:216: error: 'AUDIT_ARG_UPATH2' undeclared (first use in this function) *** [vfs_lookup.o] Error code 1 Stop in /obj/mips.mips/src/sys/AP91. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 03:42:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 03:42:51 - ERROR: failed to build AP91 kernel TB --- 2012-12-01 03:42:51 - 2718.64 user 735.23 system 4208.61 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 04:30:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1195273; Sat, 1 Dec 2012 04:30:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AB54F8FC08; Sat, 1 Dec 2012 04:30: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 qB14UOPB079754; Fri, 30 Nov 2012 23:30:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qB14UOqB079748; Sat, 1 Dec 2012 04:30:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 04:30:24 GMT Message-Id: <201212010430.qB14UOqB079748@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 04:30:29 -0000 TB --- 2012-12-01 03:17:58 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 03:17:58 - 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 --- 2012-12-01 03:17:58 - starting HEAD tinderbox run for mips64/mips TB --- 2012-12-01 03:17:58 - cleaning the object tree TB --- 2012-12-01 03:17:58 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 03:17:58 - cd /tinderbox/HEAD/mips64/mips TB --- 2012-12-01 03:17:58 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 03:19:34 - /usr/local/bin/svn update /src TB --- 2012-12-01 03:19:43 - At svn revision 243742 TB --- 2012-12-01 03:19:44 - building world TB --- 2012-12-01 03:19:44 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 03:19:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 03:19:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 03:19:44 - SRCCONF=/dev/null TB --- 2012-12-01 03:19:44 - TARGET=mips TB --- 2012-12-01 03:19:44 - TARGET_ARCH=mips64 TB --- 2012-12-01 03:19:44 - TZ=UTC TB --- 2012-12-01 03:19:44 - __MAKE_CONF=/dev/null TB --- 2012-12-01 03:19:44 - cd /src TB --- 2012-12-01 03:19:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 03:19:50 UTC 2012 >>> 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 Sat Dec 1 04:28:50 UTC 2012 TB --- 2012-12-01 04:28:50 - cd /src/sys/mips/conf TB --- 2012-12-01 04:28:50 - /usr/sbin/config -m ADM5120 TB --- 2012-12-01 04:28:50 - skipping ADM5120 kernel TB --- 2012-12-01 04:28:50 - cd /src/sys/mips/conf TB --- 2012-12-01 04:28:50 - /usr/sbin/config -m ALCHEMY TB --- 2012-12-01 04:28:50 - skipping ALCHEMY kernel TB --- 2012-12-01 04:28:50 - cd /src/sys/mips/conf TB --- 2012-12-01 04:28:50 - /usr/sbin/config -m AP91 TB --- 2012-12-01 04:28:50 - skipping AP91 kernel TB --- 2012-12-01 04:28:50 - cd /src/sys/mips/conf TB --- 2012-12-01 04:28:50 - /usr/sbin/config -m AP93 TB --- 2012-12-01 04:28:50 - skipping AP93 kernel TB --- 2012-12-01 04:28:50 - cd /src/sys/mips/conf TB --- 2012-12-01 04:28:50 - /usr/sbin/config -m AP94 TB --- 2012-12-01 04:28:50 - skipping AP94 kernel TB --- 2012-12-01 04:28:50 - cd /src/sys/mips/conf TB --- 2012-12-01 04:28:50 - /usr/sbin/config -m AP96 TB --- 2012-12-01 04:28:50 - skipping AP96 kernel TB --- 2012-12-01 04:28:50 - cd /src/sys/mips/conf TB --- 2012-12-01 04:28:50 - /usr/sbin/config -m AR71XX_BASE TB --- 2012-12-01 04:28:50 - skipping AR71XX_BASE kernel TB --- 2012-12-01 04:28:50 - cd /src/sys/mips/conf TB --- 2012-12-01 04:28:50 - /usr/sbin/config -m AR724X_BASE TB --- 2012-12-01 04:28:50 - skipping AR724X_BASE kernel TB --- 2012-12-01 04:28:50 - cd /src/sys/mips/conf TB --- 2012-12-01 04:28:50 - /usr/sbin/config -m AR91XX_BASE TB --- 2012-12-01 04:28:50 - skipping AR91XX_BASE kernel TB --- 2012-12-01 04:28:50 - cd /src/sys/mips/conf TB --- 2012-12-01 04:28:50 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2012-12-01 04:28:50 - building BERI_DE4_MDROOT kernel TB --- 2012-12-01 04:28:50 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 04:28:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 04:28:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 04:28:50 - SRCCONF=/dev/null TB --- 2012-12-01 04:28:50 - TARGET=mips TB --- 2012-12-01 04:28:50 - TARGET_ARCH=mips64 TB --- 2012-12-01 04:28:50 - TZ=UTC TB --- 2012-12-01 04:28:50 - __MAKE_CONF=/dev/null TB --- 2012-12-01 04:28:50 - cd /src TB --- 2012-12-01 04:28:50 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Sat Dec 1 04:28:51 UTC 2012 >>> 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 [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_lookup.c /src/sys/kern/vfs_lookup.c:214:54: error: macro "AUDIT_ARG_UPATH1" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c: In function 'namei': /src/sys/kern/vfs_lookup.c:214: error: 'AUDIT_ARG_UPATH1' undeclared (first use in this function) /src/sys/kern/vfs_lookup.c:214: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_lookup.c:214: error: for each function it appears in.) /src/sys/kern/vfs_lookup.c:216:54: error: macro "AUDIT_ARG_UPATH2" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c:216: error: 'AUDIT_ARG_UPATH2' undeclared (first use in this function) *** [vfs_lookup.o] Error code 1 Stop in /obj/mips.mips64/src/sys/BERI_DE4_MDROOT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 04:30:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 04:30:24 - ERROR: failed to build BERI_DE4_MDROOT kernel TB --- 2012-12-01 04:30:24 - 2722.07 user 647.11 system 4346.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 06:21:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84E6C2CB; Sat, 1 Dec 2012 06:21:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 51F268FC14; Sat, 1 Dec 2012 06:21:01 +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 qB16L0RR032168; Sat, 1 Dec 2012 01:21:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qB16L092032164; Sat, 1 Dec 2012 06:21:00 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 06:21:00 GMT Message-Id: <201212010621.qB16L092032164@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 06:21:01 -0000 TB --- 2012-12-01 03:42:52 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 03:42: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 --- 2012-12-01 03:42:52 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-12-01 03:42:52 - cleaning the object tree TB --- 2012-12-01 03:42:52 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 03:42:52 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2012-12-01 03:42:52 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 03:44:15 - /usr/local/bin/svn update /src TB --- 2012-12-01 03:44:23 - At svn revision 243742 TB --- 2012-12-01 03:44:24 - building world TB --- 2012-12-01 03:44:24 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 03:44:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 03:44:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 03:44:24 - SRCCONF=/dev/null TB --- 2012-12-01 03:44:24 - TARGET=powerpc TB --- 2012-12-01 03:44:24 - TARGET_ARCH=powerpc TB --- 2012-12-01 03:44:24 - TZ=UTC TB --- 2012-12-01 03:44:24 - __MAKE_CONF=/dev/null TB --- 2012-12-01 03:44:24 - cd /src TB --- 2012-12-01 03:44:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 03:44:29 UTC 2012 >>> 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 Sat Dec 1 06:11:49 UTC 2012 TB --- 2012-12-01 06:11:49 - generating LINT kernel config TB --- 2012-12-01 06:11:49 - cd /src/sys/powerpc/conf TB --- 2012-12-01 06:11:49 - /usr/bin/make -B LINT TB --- 2012-12-01 06:11:49 - cd /src/sys/powerpc/conf TB --- 2012-12-01 06:11:49 - /usr/sbin/config -m LINT TB --- 2012-12-01 06:11:49 - building LINT kernel TB --- 2012-12-01 06:11:49 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 06:11:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 06:11:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 06:11:49 - SRCCONF=/dev/null TB --- 2012-12-01 06:11:49 - TARGET=powerpc TB --- 2012-12-01 06:11:49 - TARGET_ARCH=powerpc TB --- 2012-12-01 06:11:49 - TZ=UTC TB --- 2012-12-01 06:11:49 - __MAKE_CONF=/dev/null TB --- 2012-12-01 06:11:49 - cd /src TB --- 2012-12-01 06:11:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 1 06:11:49 UTC 2012 >>> 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 [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/vfs_lookup.c /src/sys/kern/vfs_lookup.c:214:54: error: macro "AUDIT_ARG_UPATH1" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c: In function 'namei': /src/sys/kern/vfs_lookup.c:214: error: 'AUDIT_ARG_UPATH1' undeclared (first use in this function) /src/sys/kern/vfs_lookup.c:214: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_lookup.c:214: error: for each function it appears in.) /src/sys/kern/vfs_lookup.c:216:54: error: macro "AUDIT_ARG_UPATH2" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c:216: error: 'AUDIT_ARG_UPATH2' undeclared (first use in this function) *** [vfs_lookup.o] Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 06:21:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 06:21:00 - ERROR: failed to build LINT kernel TB --- 2012-12-01 06:21:00 - 7389.74 user 1012.55 system 9488.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 06:55:34 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 019AF607; Sat, 1 Dec 2012 06:55:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B8BAC8FC08; Sat, 1 Dec 2012 06:55: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 qB16tWrG035810; Sat, 1 Dec 2012 01:55: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 qB16tW2x035809; Sat, 1 Dec 2012 06:55:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 06:55:32 GMT Message-Id: <201212010655.qB16tW2x035809@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 06:55:34 -0000 TB --- 2012-12-01 05:42:02 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 05:42:02 - 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 --- 2012-12-01 05:42:02 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-12-01 05:42:03 - cleaning the object tree TB --- 2012-12-01 05:42:03 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 05:42:03 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2012-12-01 05:42:03 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 05:42:47 - /usr/local/bin/svn update /src TB --- 2012-12-01 05:42:53 - At svn revision 243744 TB --- 2012-12-01 05:42:54 - building world TB --- 2012-12-01 05:42:54 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 05:42:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 05:42:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 05:42:54 - SRCCONF=/dev/null TB --- 2012-12-01 05:42:54 - TARGET=sparc64 TB --- 2012-12-01 05:42:54 - TARGET_ARCH=sparc64 TB --- 2012-12-01 05:42:54 - TZ=UTC TB --- 2012-12-01 05:42:54 - __MAKE_CONF=/dev/null TB --- 2012-12-01 05:42:54 - cd /src TB --- 2012-12-01 05:42:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 05:42:59 UTC 2012 >>> 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 Sat Dec 1 06:45:10 UTC 2012 TB --- 2012-12-01 06:45:10 - generating LINT kernel config TB --- 2012-12-01 06:45:10 - cd /src/sys/sparc64/conf TB --- 2012-12-01 06:45:10 - /usr/bin/make -B LINT TB --- 2012-12-01 06:45:10 - cd /src/sys/sparc64/conf TB --- 2012-12-01 06:45:10 - /usr/sbin/config -m LINT TB --- 2012-12-01 06:45:10 - building LINT kernel TB --- 2012-12-01 06:45:10 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 06:45:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 06:45:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 06:45:10 - SRCCONF=/dev/null TB --- 2012-12-01 06:45:10 - TARGET=sparc64 TB --- 2012-12-01 06:45:10 - TARGET_ARCH=sparc64 TB --- 2012-12-01 06:45:10 - TZ=UTC TB --- 2012-12-01 06:45:10 - __MAKE_CONF=/dev/null TB --- 2012-12-01 06:45:10 - cd /src TB --- 2012-12-01 06:45:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 1 06:45:10 UTC 2012 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/vfs_lookup.c /src/sys/kern/vfs_lookup.c:214:54: error: macro "AUDIT_ARG_UPATH1" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c: In function 'namei': /src/sys/kern/vfs_lookup.c:214: error: 'AUDIT_ARG_UPATH1' undeclared (first use in this function) /src/sys/kern/vfs_lookup.c:214: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_lookup.c:214: error: for each function it appears in.) /src/sys/kern/vfs_lookup.c:216:54: error: macro "AUDIT_ARG_UPATH2" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c:216: error: 'AUDIT_ARG_UPATH2' undeclared (first use in this function) *** [vfs_lookup.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 06:55:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 06:55:32 - ERROR: failed to build LINT kernel TB --- 2012-12-01 06:55:32 - 3569.71 user 584.98 system 4409.94 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 07:28:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 100CE83D; Sat, 1 Dec 2012 07:28:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AD8918FC14; Sat, 1 Dec 2012 07:28: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 qB17SObW098722; Sat, 1 Dec 2012 02:28:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qB17SOV1098721; Sat, 1 Dec 2012 07:28:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 07:28:24 GMT Message-Id: <201212010728.qB17SOV1098721@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 07:28:26 -0000 TB --- 2012-12-01 04:30:24 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 04:30:24 - 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 --- 2012-12-01 04:30:24 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-12-01 04:30:25 - cleaning the object tree TB --- 2012-12-01 04:30:25 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 04:30:25 - cd /tinderbox/HEAD/powerpc64/powerpc TB --- 2012-12-01 04:30:25 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 04:31:21 - /usr/local/bin/svn update /src TB --- 2012-12-01 04:31:29 - At svn revision 243743 TB --- 2012-12-01 04:31:30 - building world TB --- 2012-12-01 04:31:30 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 04:31:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 04:31:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 04:31:30 - SRCCONF=/dev/null TB --- 2012-12-01 04:31:30 - TARGET=powerpc TB --- 2012-12-01 04:31:30 - TARGET_ARCH=powerpc64 TB --- 2012-12-01 04:31:30 - TZ=UTC TB --- 2012-12-01 04:31:30 - __MAKE_CONF=/dev/null TB --- 2012-12-01 04:31:30 - cd /src TB --- 2012-12-01 04:31:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 04:31:35 UTC 2012 >>> 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 Sat Dec 1 07:20:22 UTC 2012 TB --- 2012-12-01 07:20:22 - generating LINT kernel config TB --- 2012-12-01 07:20:22 - cd /src/sys/powerpc/conf TB --- 2012-12-01 07:20:22 - /usr/bin/make -B LINT TB --- 2012-12-01 07:20:22 - cd /src/sys/powerpc/conf TB --- 2012-12-01 07:20:22 - /usr/sbin/config -m LINT TB --- 2012-12-01 07:20:22 - building LINT kernel TB --- 2012-12-01 07:20:22 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 07:20:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 07:20:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 07:20:22 - SRCCONF=/dev/null TB --- 2012-12-01 07:20:22 - TARGET=powerpc TB --- 2012-12-01 07:20:22 - TARGET_ARCH=powerpc64 TB --- 2012-12-01 07:20:22 - TZ=UTC TB --- 2012-12-01 07:20:22 - __MAKE_CONF=/dev/null TB --- 2012-12-01 07:20:22 - cd /src TB --- 2012-12-01 07:20:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 1 07:20:22 UTC 2012 >>> 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 [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/vfs_lookup.c /src/sys/kern/vfs_lookup.c:214:54: error: macro "AUDIT_ARG_UPATH1" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c: In function 'namei': /src/sys/kern/vfs_lookup.c:214: error: 'AUDIT_ARG_UPATH1' undeclared (first use in this function) /src/sys/kern/vfs_lookup.c:214: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_lookup.c:214: error: for each function it appears in.) /src/sys/kern/vfs_lookup.c:216:54: error: macro "AUDIT_ARG_UPATH2" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c:216: error: 'AUDIT_ARG_UPATH2' undeclared (first use in this function) *** [vfs_lookup.o] Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 07:28:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 07:28:24 - ERROR: failed to build LINT kernel TB --- 2012-12-01 07:28:24 - 8961.70 user 1205.18 system 10679.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 08:50:34 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0DECD8E; Sat, 1 Dec 2012 08:50:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9D5628FC08; Sat, 1 Dec 2012 08:50: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 qB18oX0b041415; Sat, 1 Dec 2012 03:50:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qB18oX9f041409; Sat, 1 Dec 2012 08:50:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 08:50:33 GMT Message-Id: <201212010850.qB18oX9f041409@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 08:50:34 -0000 TB --- 2012-12-01 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 07:30: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 --- 2012-12-01 07:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-01 07:30:00 - cleaning the object tree TB --- 2012-12-01 07:30:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 07:30:00 - cd /tinderbox/HEAD/arm/arm TB --- 2012-12-01 07:30:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 07:34:14 - /usr/local/bin/svn update /src TB --- 2012-12-01 07:34:24 - At svn revision 243744 TB --- 2012-12-01 07:34:25 - building world TB --- 2012-12-01 07:34:25 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 07:34:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 07:34:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 07:34:25 - SRCCONF=/dev/null TB --- 2012-12-01 07:34:25 - TARGET=arm TB --- 2012-12-01 07:34:25 - TARGET_ARCH=arm TB --- 2012-12-01 07:34:25 - TZ=UTC TB --- 2012-12-01 07:34:25 - __MAKE_CONF=/dev/null TB --- 2012-12-01 07:34:25 - cd /src TB --- 2012-12-01 07:34:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 07:34:33 UTC 2012 >>> 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 Sat Dec 1 08:39:40 UTC 2012 TB --- 2012-12-01 08:39:40 - generating LINT kernel config TB --- 2012-12-01 08:39:40 - cd /src/sys/arm/conf TB --- 2012-12-01 08:39:40 - /usr/bin/make -B LINT TB --- 2012-12-01 08:39:40 - cd /src/sys/arm/conf TB --- 2012-12-01 08:39:40 - /usr/sbin/config -m LINT TB --- 2012-12-01 08:39:40 - building LINT kernel TB --- 2012-12-01 08:39:40 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 08:39:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 08:39:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 08:39:40 - SRCCONF=/dev/null TB --- 2012-12-01 08:39:40 - TARGET=arm TB --- 2012-12-01 08:39:40 - TARGET_ARCH=arm TB --- 2012-12-01 08:39:40 - TZ=UTC TB --- 2012-12-01 08:39:40 - __MAKE_CONF=/dev/null TB --- 2012-12-01 08:39:40 - cd /src TB --- 2012-12-01 08:39:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 1 08:39:41 UTC 2012 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/kern/vfs_lookup.c /src/sys/kern/vfs_lookup.c:214:54: error: macro "AUDIT_ARG_UPATH1" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c: In function 'namei': /src/sys/kern/vfs_lookup.c:214: error: 'AUDIT_ARG_UPATH1' undeclared (first use in this function) /src/sys/kern/vfs_lookup.c:214: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_lookup.c:214: error: for each function it appears in.) /src/sys/kern/vfs_lookup.c:216:54: error: macro "AUDIT_ARG_UPATH2" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c:216: error: 'AUDIT_ARG_UPATH2' undeclared (first use in this function) *** [vfs_lookup.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 08:50:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 08:50:33 - ERROR: failed to build LINT kernel TB --- 2012-12-01 08:50:33 - 3021.45 user 644.99 system 4832.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 09:34:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0351C43C; Sat, 1 Dec 2012 09:34:12 +0000 (UTC) (envelope-from sig6247@gmail.com) Received: from mail-ye0-f182.google.com (mail-ye0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9552E8FC08; Sat, 1 Dec 2012 09:34:11 +0000 (UTC) Received: by mail-ye0-f182.google.com with SMTP id q5so212125yen.13 for ; Sat, 01 Dec 2012 01:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:cc:subject:in-reply-to:references :mime-version:content-type; bh=B3xNG/8mTroDisWL43ugcBgjH5T1nGBrCW2MtPRo/nk=; b=hhGPMrlQ+NUsEN4o9YbpInEhaGhokk/GJ2x97NDDdY/PCZgolXXW6adNGSwzRZVitJ Aw8yOYUBzhiCgWtsPVPQnKAwME3aig6UFvUO0LvnGNOnjT/2PGxNymsParRdkBy6W+hu s3JDwqnzWknr84XtQaik0kPBO3JOEQaUhvBP/bzGrGkC4bpxOZRnoUTQ7uZCx0AkFkoJ GiPFu8Rbrfe8BLrJgCGSpvdHKjd+tsLQ7Ofix86AgCoH75FW/sYhkRFWeRdNIWMoXHbf ZlL3TB22nGqDYuXDdulORuPCtk4eHbKF80dzkr2wExg+AJZDEk+vyzMbaZggwu4N15vu FvBg== Received: by 10.101.128.5 with SMTP id f5mr1229916ann.6.1354354445120; Sat, 01 Dec 2012 01:34:05 -0800 (PST) Received: from localhost (bolobolo1.torservers.net. [96.47.226.20]) by mx.google.com with ESMTPS id u15sm6694664anq.14.2012.12.01.01.33.56 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2012 01:34:04 -0800 (PST) Message-ID: <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> Date: Sat, 01 Dec 2012 01:34:04 -0800 (PST) From: sig6247 To: Konstantin Belousov Subject: Re: clang compiled kernel panic when mounting zfs root on i386 In-Reply-To: <20121130164715.GW3013@kib.kiev.ua> (Konstantin Belousov's message of "Fri, 30 Nov 2012 18:47:15 +0200") References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 09:34:12 -0000 On Fri, 30 Nov 2012 18:47:15 +0200, Konstantin Belousov wrote: > Hm, this is not very useful. Although the panic is again caused by the stack > overflow, most likely (please also include the output of the "show thread" > from ddb), it is at different place, and probably at the leaf function. > > Can you try some more times, so that we could see 'big' backtrace ? Sure. Thanks. WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot []... Fatal double fault: eip = 0xc0add15d esp = 0xc86bffc8 ebp = 0xc86c003c cpuid = 1; apic id = 01 panic: double fault cpuid = 1 KDB: enter: panic [ thread pid 1 tid 100002 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> bt Tracing pid 1 tid 100002 td 0xc89efbc0 kdb_enter(c1065960,c1065960,c10b903b,c139f438,2243cdbd,...) at kdb_enter+0x3d/frame 0xc139f3f0 panic(c10b903b,1,1,1,c86c003c,...) at panic+0x14b/frame 0xc139f42c dblfault_handler() at dblfault_handler+0xab/frame 0xc139f42c --- trap 0x17, eip = 0xc0add15d, esp = 0xc86bffc8, ebp = 0xc86c003c --- witness_checkorder(c1fd7508,9,c109ee8c,7fa,0,...) at witness_checkorder+0x37d/frame 0xc86c003c __mtx_lock_flags(c1fd7518,0,c109ee8c,7fa,c135e998,...) at __mtx_lock_flags+0x87/frame 0xc86c007 0 uma_zalloc_arg(c1fd66c0,0,1,4d3,c86c0110,...) at uma_zalloc_arg+0x605/frame 0xc86c00c8 vm_map_insert(c1fd508c,c13e0ca0,bd3a000,0,cbc39000,...) at vm_map_insert+0x499/frame 0xc86c0130 kmem_back(c1fd508c,cbc39000,1000,3,c86c01d4,...) at kmem_back+0x76/frame 0xc86c018c kmem_malloc(c1fd508c,1000,3) at kmem_malloc+0x250/frame 0xc86c01c0 page_alloc(c1fd1d80,1000,c86c020b,3,c1fd1d80,...) at page_alloc+0x27/frame 0xc86c01d4 keg_alloc_slab(103,4,c109ee8c,870,cbb95f6c,...) at keg_alloc_slab+0xc3/frame 0xc86c0218 keg_fetch_slab(103,c1fd1d80,cbb95f6c,c1fc8230,c86c02c0,...) at keg_fetch_slab+0xe2/frame 0xc86c 0250 zone_fetch_slab(c1fd1d80,c1fd0480,103,826,0,...) at zone_fetch_slab+0x43/frame 0xc86c0268 uma_zalloc_arg(c1fd1d80,0,102,3,2,...) at uma_zalloc_arg+0x3f2/frame 0xc86c02c0 malloc(4c,c1826100,102,c86c0388,c173909a,...) at malloc+0xe9/frame 0xc86c02e8 zfs_kmem_alloc(4c,102,cb7d8820,c89efbc0,cb7d8820,...) at zfs_kmem_alloc+0x20/frame 0xc86c02fc vdev_mirror_io_start(cba232e0,10,cba232e0,1,0,...) at vdev_mirror_io_start+0x14a/frame 0xc86c03 88 zio_vdev_io_start(cba232e0,c89efbc0,0,cba232e0,c86c0600,...) at zio_vdev_io_start+0x228/frame 0 xc86c03e4 zio_execute(cba232e0,cb7d8000,cbbec640,cbbe2000,600,...) at zio_execute+0x106/frame 0xc86c0418 spa_load_verify_cb(cb7d8000,0,cbbec640,cba6bd20,c86c0600,...) at spa_load_verify_cb+0x89/frame 0xc86c0458 traverse_visitbp(cba6bd20,cbbec640,c86c0600,c86c0ba0,0,...) at traverse_visitbp+0x29f/frame 0xc 86c05e0 traverse_dnode(cba6bd20,0,0,23,0,...) at traverse_dnode+0x92/frame 0xc86c0638 traverse_visitbp(cba6bd98,cbbf0080,c86c0890,cba6bdd4,c16ca7e0,...) at traverse_visitbp+0xe47/fr ame 0xc86c07c0 traverse_visitbp(cba6bdd4,cbbe2840,c86c0968,c86c0ba0,0,...) at traverse_visitbp+0xf32/frame 0xc 86c0948 traverse_dnode(cba6bdd4,0,0,0,0,...) at traverse_dnode+0x92/frame 0xc86c09a0 traverse_visitbp(0,cb7d8398,c86c0b50,2,cbbdc214,...) at traverse_visitbp+0x96d/frame 0xc86c0b28 traverse_impl(0,0,cb7d8398,74,0,...) at traverse_impl+0x268/frame 0xc86c0be0 traverse_pool(cb7d8000,74,0,d,c1723830,...) at traverse_pool+0x79/frame 0xc86c0c88 spa_load(0,1,c86c0ec4,1e,0,...) at spa_load+0x1dde/frame 0xc86c0df0 spa_load(0,0,c13d9d14,1,3,...) at spa_load+0x11a5/frame 0xc86c0f58 spa_load_best(0,ffffffff,ffffffff,1,c0add175,...) at spa_load_best+0x71/frame 0xc86c0fb0 spa_open_common(c17dce4e,0,0,c86c1190,c16f1a1c,...) at spa_open_common+0x11a/frame 0xc86c100c spa_open(c86c1078,c86c1074,c17dce4e,c135e998,c1fd7798,...) at spa_open+0x27/frame 0xc86c1020 dsl_dir_open_spa(0,c89770b0,c17dd1e1,c86c11f8,c86c11f4,...) at dsl_dir_open_spa+0x6c/frame 0xc8 6c1190 dsl_dataset_hold(c89770b0,cb7d3800,c86c1240,cb7d3800,cb7d3800,...) at dsl_dataset_hold+0x3a/fra me 0xc86c120c dsl_dataset_own(c89770b0,0,cb7d3800,c86c1240,c1824e30,...) at dsl_dataset_own+0x21/frame 0xc86c 1228 dmu_objset_own(c89770b0,2,1,cb7d3800,c86c1290,...) at dmu_objset_own+0x2a/frame 0xc86c1250 zfsvfs_create(c89770b0,c86c13ac,c17ea09b,681,0,...) at zfsvfs_create+0x4c/frame 0xc86c12a8 zfs_mount(cb99b540,c17f0160,cb98b100,c89cae80,0,...) at zfs_mount+0x42c/frame 0xc86c14e0 vfs_donmount(c89efbc0,4000,0,c86c1790,cb98b180,...) at vfs_donmount+0xc6d/frame 0xc86c1778 kernel_mount(c8977490,4000,0,0,1,...) at kernel_mount+0x6b/frame 0xc86c17b8 parse_mount(cb96e0e0,c1195498,0,1,0,...) at parse_mount+0x606/frame 0xc86c19d8 vfs_mountroot(c13da634,4,c105ceba,2bb,0,...) at vfs_mountroot+0x6cf/frame 0xc86c1c60 start_init(0,c86c1d08,c105f7c4,3db,0,...) at start_init+0x6a/frame 0xc86c1ccc fork_exit(c0a429e0,0,c86c1d08) at fork_exit+0x7f/frame 0xc86c1cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xc86c1cf4 --- trap 0, eip = 0, esp = 0xc86c1d40, ebp = 0 --- db> show thread Thread 100002 at 0xc89efbc0: proc (pid 1): 0xc89edb40 name: kernel stack: 0xc86c0000-0xc86c1fff flags: 0x4 pflags: 0x10000 state: RUNNING (CPU 1) priority: 84 container lock: sched lock 1 (0xc1220000) db> From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 10:51:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3E7AD62; Sat, 1 Dec 2012 10:51:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 75EC18FC08; Sat, 1 Dec 2012 10:51:29 +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 qB1ApTaQ058633; Sat, 1 Dec 2012 05:51: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 qB1ApTqA058626; Sat, 1 Dec 2012 10:51:29 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 10:51:29 GMT Message-Id: <201212011051.qB1ApTqA058626@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 10:51:30 -0000 TB --- 2012-12-01 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 07:30: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 --- 2012-12-01 07:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-12-01 07:30:00 - cleaning the object tree TB --- 2012-12-01 07:30:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 07:30:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-12-01 07:30:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 07:33:25 - /usr/local/bin/svn update /src TB --- 2012-12-01 07:33:42 - At svn revision 243744 TB --- 2012-12-01 07:33:43 - building world TB --- 2012-12-01 07:33:43 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 07:33:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 07:33:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 07:33:43 - SRCCONF=/dev/null TB --- 2012-12-01 07:33:43 - TARGET=i386 TB --- 2012-12-01 07:33:43 - TARGET_ARCH=i386 TB --- 2012-12-01 07:33:43 - TZ=UTC TB --- 2012-12-01 07:33:43 - __MAKE_CONF=/dev/null TB --- 2012-12-01 07:33:43 - cd /src TB --- 2012-12-01 07:33:43 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 07:33:52 UTC 2012 >>> 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 Sat Dec 1 10:48:22 UTC 2012 TB --- 2012-12-01 10:48:22 - generating LINT kernel config TB --- 2012-12-01 10:48:22 - cd /src/sys/i386/conf TB --- 2012-12-01 10:48:22 - /usr/bin/make -B LINT TB --- 2012-12-01 10:48:22 - cd /src/sys/i386/conf TB --- 2012-12-01 10:48:22 - /usr/sbin/config -m LINT TB --- 2012-12-01 10:48:22 - building LINT kernel TB --- 2012-12-01 10:48:22 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 10:48:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 10:48:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 10:48:22 - SRCCONF=/dev/null TB --- 2012-12-01 10:48:22 - TARGET=i386 TB --- 2012-12-01 10:48:22 - TARGET_ARCH=i386 TB --- 2012-12-01 10:48:22 - TZ=UTC TB --- 2012-12-01 10:48:22 - __MAKE_CONF=/dev/null TB --- 2012-12-01 10:48:22 - cd /src TB --- 2012-12-01 10:48:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 1 10:48:22 UTC 2012 >>> 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 [...] /src/sys/kern/vfs_lookup.c:214:41: error: too many arguments provided to function-like macro invocation AUDIT_ARG_UPATH1(td, ndp->ni_dirfd, , cnp->cn_pnbuf); ^ /src/sys/kern/vfs_lookup.c:216:41: error: too many arguments provided to function-like macro invocation AUDIT_ARG_UPATH2(td, ndp->ni_dirfd, , cnp->cn_pnbuf); ^ 2 errors generated. mkdep: compile failed *** [.depend] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 10:51:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 10:51:29 - ERROR: failed to build LINT kernel TB --- 2012-12-01 10:51:29 - 8165.21 user 1362.53 system 12088.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 10:54:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72132D71; Sat, 1 Dec 2012 10:54:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE478FC12; Sat, 1 Dec 2012 10:54:39 +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 qB1Ascvp070589; Sat, 1 Dec 2012 05:54:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qB1Ascpp070567; Sat, 1 Dec 2012 10:54:38 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 10:54:38 GMT Message-Id: <201212011054.qB1Ascpp070567@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 10:54:39 -0000 TB --- 2012-12-01 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 07:30: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 --- 2012-12-01 07:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-12-01 07:30:00 - cleaning the object tree TB --- 2012-12-01 07:30:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 07:30:00 - cd /tinderbox/HEAD/i386/pc98 TB --- 2012-12-01 07:30:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 07:34:14 - /usr/local/bin/svn update /src TB --- 2012-12-01 07:34:24 - At svn revision 243744 TB --- 2012-12-01 07:34:25 - building world TB --- 2012-12-01 07:34:25 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 07:34:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 07:34:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 07:34:25 - SRCCONF=/dev/null TB --- 2012-12-01 07:34:25 - TARGET=pc98 TB --- 2012-12-01 07:34:25 - TARGET_ARCH=i386 TB --- 2012-12-01 07:34:25 - TZ=UTC TB --- 2012-12-01 07:34:25 - __MAKE_CONF=/dev/null TB --- 2012-12-01 07:34:25 - cd /src TB --- 2012-12-01 07:34:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 07:34:33 UTC 2012 >>> 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 Sat Dec 1 10:51:24 UTC 2012 TB --- 2012-12-01 10:51:24 - generating LINT kernel config TB --- 2012-12-01 10:51:24 - cd /src/sys/pc98/conf TB --- 2012-12-01 10:51:24 - /usr/bin/make -B LINT TB --- 2012-12-01 10:51:24 - cd /src/sys/pc98/conf TB --- 2012-12-01 10:51:24 - /usr/sbin/config -m LINT TB --- 2012-12-01 10:51:24 - building LINT kernel TB --- 2012-12-01 10:51:24 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 10:51:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 10:51:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 10:51:24 - SRCCONF=/dev/null TB --- 2012-12-01 10:51:24 - TARGET=pc98 TB --- 2012-12-01 10:51:24 - TARGET_ARCH=i386 TB --- 2012-12-01 10:51:24 - TZ=UTC TB --- 2012-12-01 10:51:24 - __MAKE_CONF=/dev/null TB --- 2012-12-01 10:51:24 - cd /src TB --- 2012-12-01 10:51:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 1 10:51:24 UTC 2012 >>> 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 [...] /src/sys/kern/vfs_lookup.c:214:41: error: too many arguments provided to function-like macro invocation AUDIT_ARG_UPATH1(td, ndp->ni_dirfd, , cnp->cn_pnbuf); ^ /src/sys/kern/vfs_lookup.c:216:41: error: too many arguments provided to function-like macro invocation AUDIT_ARG_UPATH2(td, ndp->ni_dirfd, , cnp->cn_pnbuf); ^ 2 errors generated. mkdep: compile failed *** [.depend] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 10:54:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 10:54:38 - ERROR: failed to build LINT kernel TB --- 2012-12-01 10:54:38 - 8410.19 user 1373.30 system 12277.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 10:55:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45BF6D7A; Sat, 1 Dec 2012 10:55:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 079588FC12; Sat, 1 Dec 2012 10:55:20 +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 qB1AtKOL071989; Sat, 1 Dec 2012 05:55:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qB1AtKKk071987; Sat, 1 Dec 2012 10:55:20 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 10:55:20 GMT Message-Id: <201212011055.qB1AtKKk071987@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 10:55:21 -0000 TB --- 2012-12-01 08:50:33 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 08:50: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 --- 2012-12-01 08:50:33 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-12-01 08:50:33 - cleaning the object tree TB --- 2012-12-01 08:51:51 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 08:51:51 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2012-12-01 08:51:51 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 08:52:57 - /usr/local/bin/svn update /src TB --- 2012-12-01 08:53:03 - At svn revision 243745 TB --- 2012-12-01 08:53:04 - building world TB --- 2012-12-01 08:53:04 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 08:53:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 08:53:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 08:53:04 - SRCCONF=/dev/null TB --- 2012-12-01 08:53:04 - TARGET=ia64 TB --- 2012-12-01 08:53:04 - TARGET_ARCH=ia64 TB --- 2012-12-01 08:53:04 - TZ=UTC TB --- 2012-12-01 08:53:04 - __MAKE_CONF=/dev/null TB --- 2012-12-01 08:53:04 - cd /src TB --- 2012-12-01 08:53:04 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 08:53:10 UTC 2012 >>> 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 Sat Dec 1 10:37:29 UTC 2012 TB --- 2012-12-01 10:37:29 - generating LINT kernel config TB --- 2012-12-01 10:37:29 - cd /src/sys/ia64/conf TB --- 2012-12-01 10:37:29 - /usr/bin/make -B LINT TB --- 2012-12-01 10:37:29 - cd /src/sys/ia64/conf TB --- 2012-12-01 10:37:29 - /usr/sbin/config -m LINT TB --- 2012-12-01 10:37:29 - building LINT kernel TB --- 2012-12-01 10:37:29 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 10:37:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 10:37:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 10:37:29 - SRCCONF=/dev/null TB --- 2012-12-01 10:37:29 - TARGET=ia64 TB --- 2012-12-01 10:37:29 - TARGET_ARCH=ia64 TB --- 2012-12-01 10:37:29 - TZ=UTC TB --- 2012-12-01 10:37:29 - __MAKE_CONF=/dev/null TB --- 2012-12-01 10:37:29 - cd /src TB --- 2012-12-01 10:37:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 1 10:37:30 UTC 2012 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/vfs_lookup.c /src/sys/kern/vfs_lookup.c:214:54: error: macro "AUDIT_ARG_UPATH1" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c: In function 'namei': /src/sys/kern/vfs_lookup.c:214: error: 'AUDIT_ARG_UPATH1' undeclared (first use in this function) /src/sys/kern/vfs_lookup.c:214: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_lookup.c:214: error: for each function it appears in.) /src/sys/kern/vfs_lookup.c:216:54: error: macro "AUDIT_ARG_UPATH2" passed 4 arguments, but takes just 3 /src/sys/kern/vfs_lookup.c:216: error: 'AUDIT_ARG_UPATH2' undeclared (first use in this function) *** [vfs_lookup.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 10:55:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 10:55:20 - ERROR: failed to build LINT kernel TB --- 2012-12-01 10:55:20 - 5132.70 user 1069.53 system 7486.54 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 10:59:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C6C9DA0; Sat, 1 Dec 2012 10:59:49 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0A77D8FC12; Sat, 1 Dec 2012 10:59:48 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so1737789oag.13 for ; Sat, 01 Dec 2012 02:59:48 -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:content-transfer-encoding; bh=d90B+Gh54rRY8BYC3JCRhU/uBY2o1vS72w3vI2kCrOs=; b=NJFC5bDZfSQPI/TF1pU1LgwMcR360tpSeS7dAhfNyr2WpY25LepF96chZfaClOv2zt 62ltbPcZvSVCTwtaUHnQJcYK01bR+aW6ksDijZ+FwLNh4+SM+qgtlphxP72MJpajxfhb XHmDizNFZaFrKl3y7v7jzghfsa+mdCQIs2tAC7U+ka9H2DYL1ulCPgUnfHTa/ioKuBsa ez0Y4MceM6zYfKaMozeSvohHNGRUJhGbsOKgjNb1EINkOOJQO8sNvkgYaGw9TkvYHUwT HAblWtnkTPGMqwQcXKj+6eUC0s/xx/bFRrM/JmM/ioN+i66cgKQfxmnuvTPnIz9V7Sp7 YljA== MIME-Version: 1.0 Received: by 10.60.170.114 with SMTP id al18mr3643209oec.56.1354359588575; Sat, 01 Dec 2012 02:59:48 -0800 (PST) Received: by 10.76.143.33 with HTTP; Sat, 1 Dec 2012 02:59:48 -0800 (PST) In-Reply-To: <20120703102142.6554b10e.taku@tackymt.homeip.net> References: <20120703102142.6554b10e.taku@tackymt.homeip.net> Date: Sat, 1 Dec 2012 02:59:48 -0800 Message-ID: Subject: Re: A suspicious warning in sys/boot/zfs/zfsimpl.c From: Garrett Cooper To: Taku YAMAMOTO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 10:59:49 -0000 On Mon, Jul 2, 2012 at 6:21 PM, Taku YAMAMOTO wro= te: > When I built the world as of r237813, clang reported a warning which > caught my attention. > > =3D=3D=3D> sys/boot/zfs (all) > clang -O2 -pipe -march=3Dpentium4 -DBOOTPROG=3D\"zfsloader\" -I/usr/src/= sys/boot/zfs/../common -I/usr/src/sys/boot/zfs/../.. -I. -I/usr/src/sys/boo= t/zfs/../../../lib/libstand -I/usr/src/sys/boot/zfs/../../cddl/boot/zfs -ff= reestanding -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mn= o-sse2 -mno-sse3 -msoft-float -Wformat -Wall -DNDEBUG -std=3Dgnu99 -Qunused= -arguments -c /usr/src/sys/boot/zfs/zfs.c -o zfs.o > In file included from /usr/src/sys/boot/zfs/zfs.c:48: > /usr/src/sys/boot/zfs/zfsimpl.c:2033:19: warning: array index 264 is past= the end of the array (which contains 192 elements) [-Warray-bounds] > memcpy(path, &dn.dn_bonus[sizeof(znode_ph= ys_t)], > ^ ~~~~~~~~~~~~~~~= ~~~~~ > /usr/src/sys/boot/zfs/../../cddl/boot/zfs/zfsimpl.h:788:2: note: array 'd= n_bonus' declared here > uint8_t dn_bonus[DN_MAX_BONUSLEN - sizeof (blkptr_t)]; > ^ > > I don't have a zfs-powered machine, so I'm not sure whether this > warning is false-positive or not. I'm seeing the same warnings trying to build HEAD r242903 with clang on amd64. Andriy CCed. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 11:05:51 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82ED2EE3 for ; Sat, 1 Dec 2012 11:05:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C7D0C8FC08 for ; Sat, 1 Dec 2012 11:05:48 +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 NAA28567; Sat, 01 Dec 2012 13:05:36 +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 1Tekt6-00056g-7c; Sat, 01 Dec 2012 13:05:36 +0200 Message-ID: <50B9E47F.6070005@FreeBSD.org> Date: Sat, 01 Dec 2012 13:05:35 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: A suspicious warning in sys/boot/zfs/zfsimpl.c References: <20120703102142.6554b10e.taku@tackymt.homeip.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Taku YAMAMOTO , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 11:05:51 -0000 on 01/12/2012 12:59 Garrett Cooper said the following: > On Mon, Jul 2, 2012 at 6:21 PM, Taku YAMAMOTO wrote: >> When I built the world as of r237813, clang reported a warning which >> caught my attention. >> >> ===> sys/boot/zfs (all) >> clang -O2 -pipe -march=pentium4 -DBOOTPROG=\"zfsloader\" -I/usr/src/sys/boot/zfs/../common -I/usr/src/sys/boot/zfs/../.. -I. -I/usr/src/sys/boot/zfs/../../../lib/libstand -I/usr/src/sys/boot/zfs/../../cddl/boot/zfs -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Wformat -Wall -DNDEBUG -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/zfs/zfs.c -o zfs.o >> In file included from /usr/src/sys/boot/zfs/zfs.c:48: >> /usr/src/sys/boot/zfs/zfsimpl.c:2033:19: warning: array index 264 is past the end of the array (which contains 192 elements) [-Warray-bounds] >> memcpy(path, &dn.dn_bonus[sizeof(znode_phys_t)], >> ^ ~~~~~~~~~~~~~~~~~~~~ >> /usr/src/sys/boot/zfs/../../cddl/boot/zfs/zfsimpl.h:788:2: note: array 'dn_bonus' declared here >> uint8_t dn_bonus[DN_MAX_BONUSLEN - sizeof (blkptr_t)]; >> ^ >> >> I don't have a zfs-powered machine, so I'm not sure whether this >> warning is false-positive or not. > > I'm seeing the same warnings trying to build HEAD r242903 with > clang on amd64. Andriy CCed. I believe that there is no actual problem there. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 11:32:02 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B37CC2D0; Sat, 1 Dec 2012 11:32:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 760608FC0C; Sat, 1 Dec 2012 11:32:02 +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 qB1BW1cg014682; Sat, 1 Dec 2012 06:32: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 qB1BW1RF014675; Sat, 1 Dec 2012 11:32:01 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Dec 2012 11:32:01 GMT Message-Id: <201212011132.qB1BW1RF014675@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.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 11:32:02 -0000 TB --- 2012-12-01 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-01 07:30: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 --- 2012-12-01 07:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-12-01 07:30:00 - cleaning the object tree TB --- 2012-12-01 07:30:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-01 07:30:00 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-12-01 07:30:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-01 07:33:31 - /usr/local/bin/svn update /src TB --- 2012-12-01 07:33:52 - At svn revision 243744 TB --- 2012-12-01 07:33:53 - building world TB --- 2012-12-01 07:33:53 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 07:33:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 07:33:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 07:33:53 - SRCCONF=/dev/null TB --- 2012-12-01 07:33:53 - TARGET=amd64 TB --- 2012-12-01 07:33:53 - TARGET_ARCH=amd64 TB --- 2012-12-01 07:33:53 - TZ=UTC TB --- 2012-12-01 07:33:53 - __MAKE_CONF=/dev/null TB --- 2012-12-01 07:33:53 - cd /src TB --- 2012-12-01 07:33:53 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 1 07:34:04 UTC 2012 >>> 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 Sat Dec 1 11:28:49 UTC 2012 TB --- 2012-12-01 11:28:49 - generating LINT kernel config TB --- 2012-12-01 11:28:49 - cd /src/sys/amd64/conf TB --- 2012-12-01 11:28:49 - /usr/bin/make -B LINT TB --- 2012-12-01 11:28:49 - cd /src/sys/amd64/conf TB --- 2012-12-01 11:28:49 - /usr/sbin/config -m LINT TB --- 2012-12-01 11:28:49 - building LINT kernel TB --- 2012-12-01 11:28:49 - CROSS_BUILD_TESTING=YES TB --- 2012-12-01 11:28:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-01 11:28:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-01 11:28:49 - SRCCONF=/dev/null TB --- 2012-12-01 11:28:49 - TARGET=amd64 TB --- 2012-12-01 11:28:49 - TARGET_ARCH=amd64 TB --- 2012-12-01 11:28:49 - TZ=UTC TB --- 2012-12-01 11:28:49 - __MAKE_CONF=/dev/null TB --- 2012-12-01 11:28:49 - cd /src TB --- 2012-12-01 11:28:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 1 11:28:50 UTC 2012 >>> 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 [...] /src/sys/kern/vfs_lookup.c:214:41: error: too many arguments provided to function-like macro invocation AUDIT_ARG_UPATH1(td, ndp->ni_dirfd, , cnp->cn_pnbuf); ^ /src/sys/kern/vfs_lookup.c:216:41: error: too many arguments provided to function-like macro invocation AUDIT_ARG_UPATH2(td, ndp->ni_dirfd, , cnp->cn_pnbuf); ^ 2 errors generated. mkdep: compile failed *** [.depend] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-01 11:32:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-01 11:32:01 - ERROR: failed to build LINT kernel TB --- 2012-12-01 11:32:01 - 9428.62 user 1737.44 system 14520.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 12:19:01 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77655AEE for ; Sat, 1 Dec 2012 12:19:01 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 17B9F8FC08 for ; Sat, 1 Dec 2012 12:19:00 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1Tem21-003jkl-Sv>; Sat, 01 Dec 2012 13:18:53 +0100 Received: from e178034076.adsl.alicedsl.de ([85.178.34.76] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1Tem21-000Bs2-P2>; Sat, 01 Dec 2012 13:18:53 +0100 Message-ID: <50B9F5AA.90906@zedat.fu-berlin.de> Date: Sat, 01 Dec 2012 13:18:50 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Current FreeBSD Subject: gcc46: .././../gcc-4.6-20121123/gcc/rtl.h:2105:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER', rtx x_initial_regno_reg_rtx[FIRST_PSEUDO_REGISTER]; X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBE22F9C279D79F8C363186A3" X-Originating-IP: 85.178.34.76 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 12:19:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBE22F9C279D79F8C363186A3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On exactly ONE FreeBSD 10.0-CURRENT box, out of a couple, all the same OS version (most recent sources/buildworld with CLANG and ports tree always up to date) I get this nasty error shown below. I can not reproduce this problem on other machines of the very same architecture (neither Core2Duo or even up to Ivy Bridge CPUs, if the -march=3Dnative option would cause the problem). I'm helpless. I replaced gcc46 by now with gcc47, but I can not update/repair the ports database, since many packages which do not compile with CLANG neede gcc46 as a dependency and pkgdb -F doesn't work with the unfinished PKGNG version we use by default now on FreeBSD 10. Since I'm now convinced, that the error is triggered by some shadowed problems of that specific box, can someone help and suggest where to llok after? As I said, I deleted the port lang/gcc46 and replaced it with lang/gcc47 (but didn't it properly with portupgrade -o). Maybe there are still remains of the gcc46 leftover. How to finde those and kill them - if? Tahnks in advance, Oliver [...] cc -c -O3 -pipe -fno-strict-aliasing -march=3Dnative -march=3Dnative -I/usr/local/include -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I.././../gcc-4.6-20121123/gcc -I.././../gcc-4.6-20121123/gcc/build -I.././../gcc-4.6-20121123/gcc/../include -I.././../gcc-4.6-20121123/gcc/../libcpp/include -I/usr/local/include -I.././../gcc-4.6-20121123/gcc/../libdecnumber -I.././../gcc-4.6-20121123/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include \ -o build/genflags.o .././../gcc-4.6-20121123/gcc/genflags.c In file included from .././../gcc-4.6-20121123/gcc/genflags.c:28: =2E././../gcc-4.6-20121123/gcc/rtl.h:1989:13: warning: ISO C forbids forward references to 'enum' types [-Wpedantic] extern enum reg_class reg_preferred_class (int); ^ =2E././../gcc-4.6-20121123/gcc/rtl.h:2105:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER' rtx x_initial_regno_reg_rtx[FIRST_PSEUDO_REGISTER]; ^ =2E././../gcc-4.6-20121123/gcc/rtl.h:2112:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER' rtx x_static_reg_base_value[FIRST_PSEUDO_REGISTER]; ^ 1 warning and 2 errors generated. gmake[2]: *** [build/genflags.o] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build/gcc' gmake[1]: *** [all-gcc] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc46. *** [build] Error code 1 Stop in /usr/ports/lang/gcc46. --------------enigBE22F9C279D79F8C363186A3 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.19 (FreeBSD) iQEcBAEBAgAGBQJQufWtAAoJEOgBcD7A/5N8yEQIALInoihOGzl8xmq1fDFerwjM wXuA7qvCYsevAdQcSI53AszJg1eMxXmqm2XDiu+0FfzIy0ya9jfrKp5JWRs8khu3 KlJUXyV+5MRAPv41V04epdE1uqzHRTGN6dGddkBbPhkCTcwemwTyxW27WlGSqZAX eE1PnT+9dKK/7qYeBYZyJKfDdIF2wTTGJ4vK/R+lQ7Nx2JtDMc1Whe71KTmXGlBc SPvEORMZStHJqLU0xTMYX1LhFk1AHkOxk1B+iDVhTONLzCj2vI6baypEymf1cLIw 4IwolJfwit8rV+ZJ7jg9SVdpd748p/03ZuFJkI6N3YmNmCMng//dImcAMj8xqDw= =ZXVH -----END PGP SIGNATURE----- --------------enigBE22F9C279D79F8C363186A3-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 13:30:04 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEFFF5ED; Sat, 1 Dec 2012 13:30:04 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id AD84F8FC08; Sat, 1 Dec 2012 13:30:04 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id D3F77EDB; Sat, 1 Dec 2012 14:28:04 +0100 (CET) Date: Sat, 1 Dec 2012 14:31:18 +0100 From: Pawel Jakub Dawidek To: FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on ia64/ia64 Message-ID: <20121201133118.GE1399@garage.freebsd.pl> References: <201212010317.qB13HvbL058987@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/2994txjAzEdQwm5" Content-Disposition: inline In-Reply-To: <201212010317.qB13HvbL058987@freebsd-current.sentex.ca> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 13:30:05 -0000 --/2994txjAzEdQwm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 01, 2012 at 03:17:57AM +0000, FreeBSD Tinderbox wrote: > cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -Wall -Wredundant-decls= -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmis= sing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/= src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KE= RNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D1500= 0 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fn= o-builtin -mconstant-gp -ffixed-r13 -mfixed-range=3Df32-f127 -fpic -ffreest= anding -Werror /src/sys/kern/vfs_lookup.c > /src/sys/kern/vfs_lookup.c:214:54: error: macro "AUDIT_ARG_UPATH1" passed= 4 arguments, but takes just 3 > /src/sys/kern/vfs_lookup.c: In function 'namei': > /src/sys/kern/vfs_lookup.c:214: error: 'AUDIT_ARG_UPATH1' undeclared (fir= st use in this function) > /src/sys/kern/vfs_lookup.c:214: error: (Each undeclared identifier is rep= orted only once > /src/sys/kern/vfs_lookup.c:214: error: for each function it appears in.) > /src/sys/kern/vfs_lookup.c:216:54: error: macro "AUDIT_ARG_UPATH2" passed= 4 arguments, but takes just 3 > /src/sys/kern/vfs_lookup.c:216: error: 'AUDIT_ARG_UPATH2' undeclared (fir= st use in this function) > *** [vfs_lookup.o] Error code 1 [...] My recent commits broke the build in two ways, both should be fixed now, I'm very sorry about that. The code did compile for me on my development box, but it turned out source code on my laptop didn't have latest changes. I tried to compile it on my laptop before the commit, but run into problems with my environment (my laptop is running HEAD from before the switch to clang and the compilation was failing very early for other reasons), it is late at night to figure out the fix (which was trivial: CC=3Dgcc), so I assumed that if the code builds on dev box it is fine. It wasn't. My mistake, I should've waited till moring. Once again, sorry about that! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --/2994txjAzEdQwm5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC6BqUACgkQForvXbEpPzRhxACcC9nNZFy92VAqFdTMznBv3fHk +oUAn0NUBTmvhIMGbkfmbzPhrpIJNDop =HpKT -----END PGP SIGNATURE----- --/2994txjAzEdQwm5-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 13:34:44 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 236E8618; Sat, 1 Dec 2012 13:34:44 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id A8ED28FC1C; Sat, 1 Dec 2012 13:34:43 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 32A60EDD; Sat, 1 Dec 2012 14:32:50 +0100 (CET) Date: Sat, 1 Dec 2012 14:36:03 +0100 From: Pawel Jakub Dawidek To: Daniel Braniss Subject: Re: [HEADSUP] zfs root pool mounting Message-ID: <20121201133603.GF1399@garage.freebsd.pl> References: <50B6598B.20200@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="juZjCTNxrMaZdGZC" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD current , FreeBSD Stable , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 13:34:44 -0000 --juZjCTNxrMaZdGZC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 30, 2012 at 08:51:48AM +0200, Daniel Braniss wrote: > >=20 > > Recently some changes were made to how a root pool is opened for root f= ilesystem > > mounting. Previously the root pool had to be present in zpool.cache. = Now it is > > automatically discovered by probing available GEOM providers. > > The new scheme is believed to be more flexible. For example, it allows= to prepare > > a new root pool at one system, then export it and then boot from it on = a new > > system without doing any extra/magical steps with zpool.cache. It coul= d also be > > convenient after zpool split and in some other situations. > >=20 > > The change was introduced via multiple commits, the latest relevant rev= ision in > > head is r243502. The changes are partially MFC-ed, the remaining parts= are > > scheduled to be MFC-ed soon. > >=20 > > I have received a report that the change caused a problem with booting = on at least > > one system. The problem has been identified as an issue in local envir= onment and > > has been fixed. Please read on to see if you might be affected when yo= u upgrade, > > so that you can avoid any unnecessary surprises. > >=20 > > You might be affected if you ever had a pool named the same as your cur= rent root > > pool. And you still have any disks connected to your system that belon= ged to that > > pool (in whole or via some partitions). And that pool was never proper= ly > > destroyed using zpool destroy, but merely abandoned (its disks > > re-purposed/re-partitioned/reused). > >=20 > > If all of the above are true, then I recommend that you run 'zdb -l ' for > > all suspect disks and their partitions (or just all disks and partition= s). If > > this command reports at least one valid ZFS label for a disk or a parti= tion that > > do not belong to any current pool, then the problem may affect you. > >=20 > > The best course is to remove the offending labels. > >=20 > > If you are affected, please follow up to this email. >=20 > GREATE!!!! > in a diskless environment, /boot is read only, and the zpool.cache issue > has been bothering me ever since, there was no way (and I tried) to re ro= ute it. I believe zpool.cache is not required only for root pool anymore and that you still need it if you want non-root pools to be automatically configured after reboot. Am I right, Andriy? Zpool.cache basically tells ZFS which pools should be automatically imported and file systems mounted. You can have disks in your system with ZFS pools that should not be auto-imported and zpool.cache is the way to tell the difference. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --juZjCTNxrMaZdGZC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC6B8IACgkQForvXbEpPzQmVQCgwL1RvyYB6HC+2/kcdWN3xLwa oHgAn2qWqOntsDsfJwjqkiBZtBLDGpVf =aPgG -----END PGP SIGNATURE----- --juZjCTNxrMaZdGZC-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 15:15:12 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DCF8992; Sat, 1 Dec 2012 15:15:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2E40E8FC12; Sat, 1 Dec 2012 15:15:12 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CF68A46B0D; Sat, 1 Dec 2012 10:15:11 -0500 (EST) Date: Sat, 1 Dec 2012 15:15:11 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Subject: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: security@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 15:15:12 -0000 Dear all: I've now committed the build glue required to install the recently merged Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and sponsored by the FreeBSD Foundation. This allows individual hosts generating audit trails to submit trails to a central audit server for review and safe keeping. Part of the goal is to ensure that a host submitting trail data can't later modify the trails. Pawel uses a variety of useful security- and resilience-related features such as TLS, Capsicum, etc, in auditdistd. As the recent security incident in the FreeBSD.org cluster illustrated, having reliable and detailed audit trails makes a big difference in forensic work, and hopefully this will allow the FreeBSD Project (and our users) to do that better in the future. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Sat, 1 Dec 2012 15:11:46 +0000 (UTC) From: Robert Watson To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd Author: rwatson Date: Sat Dec 1 15:11:46 2012 New Revision: 243752 URL: http://svnweb.freebsd.org/changeset/base/243752 Log: Merge a number of changes required to hook up OpenBSM 1.2-alpha2's auditdistd (distributed audit daemon) to the build: - Manual cross references - Makefile for auditdistd - rc.d script, rc.conf entrie - New group and user for auditdistd; associated aliases, etc. The audit trail distribution daemon provides reliable, cryptographically protected (and sandboxed) delivery of audit tails from live clients to audit server hosts in order to both allow centralised analysis, and improve resilience in the event of client compromises: clients are not permitted to change trail contents after submission. Submitted by: pjd Sponsored by: The FreeBSD Foundation (auditdistd) Added: head/etc/rc.d/auditdistd (contents, props changed) head/usr.sbin/auditdistd/ head/usr.sbin/auditdistd/Makefile (contents, props changed) Modified: head/etc/defaults/rc.conf head/etc/ftpusers head/etc/mail/aliases head/etc/master.passwd head/etc/mtree/BSD.var.dist head/etc/rc.d/Makefile head/share/man/man4/audit.4 head/usr.sbin/Makefile Modified: head/etc/defaults/rc.conf ============================================================================== --- head/etc/defaults/rc.conf Sat Dec 1 13:46:37 2012 (r243751) +++ head/etc/defaults/rc.conf Sat Dec 1 15:11:46 2012 (r243752) @@ -590,6 +590,9 @@ sendmail_rebuild_aliases="NO" # Run newa auditd_enable="NO" # Run the audit daemon. auditd_program="/usr/sbin/auditd" # Path to the audit daemon. auditd_flags="" # Which options to pass to the audit daemon. +auditdistd_enable="NO" # Run the audit daemon. +auditdistd_program="/usr/sbin/auditdistd" # Path to the auditdistd daemon. +auditdistd_flags="" # Which options to pass to the auditdistd daemon. cron_enable="YES" # Run the periodic job daemon. cron_program="/usr/sbin/cron" # Which cron executable to run (if enabled). cron_dst="YES" # Handle DST transitions intelligently (YES/NO) Modified: head/etc/ftpusers ============================================================================== --- head/etc/ftpusers Sat Dec 1 13:46:37 2012 (r243751) +++ head/etc/ftpusers Sat Dec 1 15:11:46 2012 (r243752) @@ -19,6 +19,7 @@ _pflogd _dhcp uucp pop +auditdistd www hast nobody Modified: head/etc/mail/aliases ============================================================================== --- head/etc/mail/aliases Sat Dec 1 13:46:37 2012 (r243751) +++ head/etc/mail/aliases Sat Dec 1 15:11:46 2012 (r243752) @@ -26,6 +26,7 @@ postmaster: root # General redirections for pseudo accounts _dhcp: root _pflogd: root +auditdistd: root bin: root bind: root daemon: root Modified: head/etc/master.passwd ============================================================================== --- head/etc/master.passwd Sat Dec 1 13:46:37 2012 (r243751) +++ head/etc/master.passwd Sat Dec 1 15:11:46 2012 (r243752) @@ -20,6 +20,7 @@ _pflogd:*:64:64::0:0:pflogd privsep user _dhcp:*:65:65::0:0:dhcp programs:/var/empty:/usr/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin +auditdistd:*:78:77::0:0:Auditdistd unprivileged user:/var/empty:/usr/sbin/nologin www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/usr/sbin/nologin hast:*:845:845::0:0:HAST unprivileged user:/var/empty:/usr/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin Modified: head/etc/mtree/BSD.var.dist ============================================================================== --- head/etc/mtree/BSD.var.dist Sat Dec 1 13:46:37 2012 (r243751) +++ head/etc/mtree/BSD.var.dist Sat Dec 1 15:11:46 2012 (r243752) @@ -19,6 +19,10 @@ /set gname=audit audit .. + dist uname=auditdistd gname=audit mode=0770 + .. + remote uname=auditdistd gname=wheel mode=0700 + .. /set gname=wheel backups .. Modified: head/etc/rc.d/Makefile ============================================================================== --- head/etc/rc.d/Makefile Sat Dec 1 13:46:37 2012 (r243751) +++ head/etc/rc.d/Makefile Sat Dec 1 15:11:46 2012 (r243752) @@ -19,6 +19,7 @@ FILES= DAEMON \ atm2 \ atm3 \ auditd \ + auditdistd \ bgfsck \ bluetooth \ bootparams \ Added: head/etc/rc.d/auditdistd ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/etc/rc.d/auditdistd Sat Dec 1 15:11:46 2012 (r243752) @@ -0,0 +1,21 @@ +#!/bin/sh +# +# $FreeBSD$ +# + +# PROVIDE: auditdistd +# REQUIRE: auditd +# BEFORE: DAEMON +# KEYWORD: nojail shutdown + +. /etc/rc.subr + +name="auditdistd" +rcvar="${name}_enable" +pidfile="/var/run/${name}.pid" +command="/usr/sbin/${name}" +required_files="/etc/${name}.conf" +extra_commands="reload" + +load_rc_config $name +run_rc_command "$1" Modified: head/share/man/man4/audit.4 ============================================================================== --- head/share/man/man4/audit.4 Sat Dec 1 13:46:37 2012 (r243751) +++ head/share/man/man4/audit.4 Sat Dec 1 15:11:46 2012 (r243752) @@ -96,7 +96,8 @@ to track users and events in a fine-grai .Xr audit_warn 5 , .Xr rc.conf 5 , .Xr audit 8 , -.Xr auditd 8 +.Xr auditd 8 , +.Xr auditdistd 8 .Sh HISTORY The .Tn OpenBSM Modified: head/usr.sbin/Makefile ============================================================================== --- head/usr.sbin/Makefile Sat Dec 1 13:46:37 2012 (r243751) +++ head/usr.sbin/Makefile Sat Dec 1 15:11:46 2012 (r243752) @@ -110,6 +110,9 @@ SUBDIR+= amd .if ${MK_AUDIT} != "no" SUBDIR+= audit SUBDIR+= auditd +.if ${MK_OPENSSL} != "no" +SUBDIR+= auditdistd +.endif SUBDIR+= auditreduce SUBDIR+= praudit .endif Added: head/usr.sbin/auditdistd/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/usr.sbin/auditdistd/Makefile Sat Dec 1 15:11:46 2012 (r243752) @@ -0,0 +1,32 @@ +# +# $FreeBSD$ +# + +OPENBSMDIR=${.CURDIR}/../../contrib/openbsm +.PATH: ${OPENBSMDIR}/bin/auditdistd + +# Addition of auditdistd because otherwise generated parse.c can't find +# auditdistd.h. This seems like a makefile non-feature. +CFLAGS+=-I${OPENBSMDIR} -I${OPENBSMDIR}/bin/auditdistd + +NO_WFORMAT= + +PROG= auditdistd +SRCS= auditdistd.c +SRCS+= parse.y pjdlog.c +SRCS+= proto.c proto_common.c proto_socketpair.c proto_tcp.c proto_tls.c +SRCS+= receiver.c +SRCS+= sandbox.c sender.c subr.c +SRCS+= token.l trail.c +MAN= auditdistd.8 auditdistd.conf.5 + +DPADD= ${LIBL} ${LIBPTHREAD} ${LIBUTIL} +LDADD= -ll -lpthread -lutil +DPADD+= ${LIBCRYPTO} ${LIBSSL} +LDADD+= -lcrypto -lssl + +YFLAGS+=-v + +CLEANFILES=parse.c parse.h parse.output + +.include From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 16:30:08 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F09A952E; Sat, 1 Dec 2012 16:30:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D1FDD8FC15; Sat, 1 Dec 2012 16:30:07 +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 SAA29896; Sat, 01 Dec 2012 18:30:00 +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 1Tepx2-0005RF-00; Sat, 01 Dec 2012 18:30:00 +0200 Message-ID: <50BA3087.5030904@FreeBSD.org> Date: Sat, 01 Dec 2012 18:29:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: [HEADSUP] zfs root pool mounting References: <50B6598B.20200@FreeBSD.org> <20121201133603.GF1399@garage.freebsd.pl> In-Reply-To: <20121201133603.GF1399@garage.freebsd.pl> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , FreeBSD Stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 16:30:09 -0000 on 01/12/2012 15:36 Pawel Jakub Dawidek said the following: > On Fri, Nov 30, 2012 at 08:51:48AM +0200, Daniel Braniss wrote: >> GREATE!!!! in a diskless environment, /boot is read only, and the >> zpool.cache issue has been bothering me ever since, there was no way (and >> I tried) to re route it. > > I believe zpool.cache is not required only for root pool anymore and that > you still need it if you want non-root pools to be automatically configured > after reboot. Am I right, Andriy? Yes, definitely. > Zpool.cache basically tells ZFS which pools should be automatically > imported and file systems mounted. You can have disks in your system with > ZFS pools that should not be auto-imported and zpool.cache is the way to > tell the difference. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 16:51:14 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C20A6DF for ; Sat, 1 Dec 2012 16:51:14 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 1FE328FC13 for ; Sat, 1 Dec 2012 16:51:12 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id qB1GoseO048751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 2 Dec 2012 01:51:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id qB1GoqP4046382 for ; Sun, 2 Dec 2012 01:50:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 02 Dec 2012 01:50:48 +0900 (JST) Message-Id: <20121202.015048.1122480556487090170.hrs@allbsd.org> To: current@FreeBSD.org Subject: RFC: sysctl -f filename From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Sun_Dec__2_01_50_48_2012_189)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sun, 02 Dec 2012 01:51:04 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,QENCPTR1,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 16:51:14 -0000 ----Security_Multipart0(Sun_Dec__2_01_50_48_2012_189)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Dec__2_01_50_48_2012_330)--" Content-Transfer-Encoding: 7bit ----Next_Part(Sun_Dec__2_01_50_48_2012_330)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I would like comments about the attached patch for sysctl(8) to add a new option "-f filename". It supports reading of a file with key=value lines. As you probably know, we already have /etc/sysctl.conf and it is processed by rc.d/sysctl shell script in a line-by-line basis. The problem I want to fix is a confusing syntax of /etc/sysctl.conf. The file supports a typical configuration file syntax but problematic in some cases. For example: kern.coredump=1 works well in /etc/sysctl.conf, but kern.coredump="1" does not work. Similarly, it is difficult to use whitespaces and "#" in the value: OK: kern.domainname=domain\ name\ with\ spaces NG: kern.domainname="domain name with spaces" NG: kern.domainname=domain\ name\ including\ #\ character NG: kern.domainname=domain\ name\ including\ \#\ character The attached patch solves them, and in addition it displays an error message with a line number if there is something wrong in the file like this: % cat -n /etc/sysctl.conf ... 10 kern.coredump=1 11 kern.coredump2=1 ... % /etc/rc.d/sysctl start sysctl: kern.coredump at line 10: Operation not permitted sysctl: unknown oid 'kern.coredump2' at line 11 # /etc/rc.d/sysctl start kern.coredump: 1 -> 1 sysctl: unknown oid 'kern.coredump2' at line 11 Any comments are welcome. -- Hiroki ----Next_Part(Sun_Dec__2_01_50_48_2012_330)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sysctl_20121201-1.diff" Index: sbin/sysctl/sysctl.8 =================================================================== --- sbin/sysctl/sysctl.8 (revision 243756) +++ sbin/sysctl/sysctl.8 (working copy) @@ -28,7 +28,7 @@ .\" From: @(#)sysctl.8 8.1 (Berkeley) 6/6/93 .\" $FreeBSD$ .\" -.Dd January 17, 2011 +.Dd November 22, 2012 .Dt SYSCTL 8 .Os .Sh NAME @@ -37,6 +37,7 @@ .Sh SYNOPSIS .Nm .Op Fl bdehiNnoqx +.Op Fl f Ar filename .Ar name Ns Op = Ns Ar value .Ar ... .Nm @@ -80,6 +81,11 @@ or .Fl n is specified, or a variable is being set. +.It Fl f Ar filename +Specify a file which contains a pair of name and value in each line. +.Nm +reads and processes the specified file first and then processes the name +and value pairs in the command line argument. .It Fl h Format output for human, rather than machine, readability. .It Fl i Index: sbin/sysctl/sysctl.c =================================================================== --- sbin/sysctl/sysctl.c (revision 243756) +++ sbin/sysctl/sysctl.c (working copy) @@ -56,13 +56,16 @@ #include #include #include +#include #include +static const char *conffile; static int aflag, bflag, dflag, eflag, hflag, iflag; -static int Nflag, nflag, oflag, qflag, xflag, warncount; +static int Nflag, nflag, oflag, qflag, xflag; static int oidfmt(int *, int, char *, u_int *); -static void parse(char *); +static int parsefile(const char *); +static int parse(char *, int); static int show_var(int *, int); static int sysctl_all(int *oid, int len); static int name2oid(char *, int *); @@ -74,7 +77,7 @@ { (void)fprintf(stderr, "%s\n%s\n", - "usage: sysctl [-bdehiNnoqx] name[=value] ...", + "usage: sysctl [-bdehiNnoqx] [-f filename] name[=value] ...", " sysctl [-bdehNnoqx] -a"); exit(1); } @@ -83,12 +86,13 @@ main(int argc, char **argv) { int ch; + int warncount = 0; setlocale(LC_NUMERIC, ""); setbuf(stdout,0); setbuf(stderr,0); - while ((ch = getopt(argc, argv, "AabdehiNnoqwxX")) != -1) { + while ((ch = getopt(argc, argv, "Aabdef:hiNnoqwxX")) != -1) { switch (ch) { case 'A': /* compatibility */ @@ -106,6 +110,9 @@ case 'e': eflag = 1; break; + case 'f': + conffile = strdup(optarg); + break; case 'h': hflag = 1; break; @@ -146,13 +153,15 @@ usage(); if (aflag && argc == 0) exit(sysctl_all(0, 0)); - if (argc == 0) + if (argc == 0 && conffile == NULL) usage(); - warncount = 0; + if (conffile != NULL) + warncount += parsefile(conffile); while (argc-- > 0) - parse(*argv++); - exit(warncount); + warncount += parse(*argv++, 0); + + return (warncount); } /* @@ -160,8 +169,8 @@ * Lookup and print out the MIB entry if it exists. * Set a new value if requested. */ -static void -parse(char *string) +static int +parse(char *string, int lineno) { int len, i, j; void *newval = 0; @@ -173,17 +182,30 @@ int64_t i64val; uint64_t u64val; int mib[CTL_MAXNAME]; - char *cp, *bufp, buf[BUFSIZ], *endptr, fmt[BUFSIZ]; + char *cp, *bufp, buf[BUFSIZ], *endptr, fmt[BUFSIZ], line[BUFSIZ]; u_int kind; + memset(line, 0, sizeof(line)); + if (lineno) + snprintf(line, sizeof(line), " at line %d", lineno); bufp = buf; - if (snprintf(buf, BUFSIZ, "%s", string) >= BUFSIZ) - errx(1, "oid too long: '%s'", string); + if (snprintf(buf, BUFSIZ, "%s", string) >= BUFSIZ) { + warn("oid too long: '%s'%s", string, line); + return (1); + } if ((cp = strchr(string, '=')) != NULL) { *strchr(buf, '=') = '\0'; *cp++ = '\0'; while (isspace(*cp)) cp++; + /* Strip a pair of " or ' if any. */ + switch (*cp) { + case '\"': + case '\'': + if (cp[strlen(cp) - 1] == *cp) + cp[strlen(cp) - 1] = '\0'; + cp++; + } newval = cp; newsize = strlen(cp); } @@ -191,15 +213,20 @@ if (len < 0) { if (iflag) - return; - if (qflag) + return (1); + if (qflag) exit(1); else - errx(1, "unknown oid '%s'", bufp); + errx(1, "unknown oid '%s'%s", bufp, line); } - if (oidfmt(mib, len, fmt, &kind)) - err(1, "couldn't find format of oid '%s'", bufp); + if (oidfmt(mib, len, fmt, &kind)) { + warn("couldn't find format of oid '%s'%s", bufp, line); + if (!iflag) + exit(1); + else + return (1); + } if (newval == NULL || dflag) { if ((kind & CTLTYPE) == CTLTYPE_NODE) { @@ -215,16 +242,20 @@ putchar('\n'); } } else { - if ((kind & CTLTYPE) == CTLTYPE_NODE) - errx(1, "oid '%s' isn't a leaf node", bufp); + if ((kind & CTLTYPE) == CTLTYPE_NODE) { + warn("oid '%s' isn't a leaf node%s", bufp, line); + return (1); + } if (!(kind & CTLFLAG_WR)) { if (kind & CTLFLAG_TUN) { - warnx("oid '%s' is a read only tunable", bufp); - errx(1, "Tunable values are set in /boot/loader.conf"); - } else { - errx(1, "oid '%s' is read only", bufp); - } + warnx("oid '%s' is a read only tunable%s", + bufp, line); + warn("Tunable values are set in /boot/loader.conf"); + } else + warn("oid '%s' is read only%s", bufp, line); + + return (1); } if ((kind & CTLTYPE) == CTLTYPE_INT || @@ -233,22 +264,28 @@ (kind & CTLTYPE) == CTLTYPE_ULONG || (kind & CTLTYPE) == CTLTYPE_S64 || (kind & CTLTYPE) == CTLTYPE_U64) { - if (strlen(newval) == 0) - errx(1, "empty numeric value"); + if (strlen(newval) == 0) { + warn("empty numeric value%s", line); + return (1); + } } switch (kind & CTLTYPE) { case CTLTYPE_INT: if (strcmp(fmt, "IK") == 0) { - if (!set_IK(newval, &intval)) - errx(1, "invalid value '%s'", - (char *)newval); + if (!set_IK(newval, &intval)) { + warn("invalid value '%s'%s", + (char *)newval, line); + return (1); + } } else { intval = (int)strtol(newval, &endptr, 0); - if (endptr == newval || *endptr != '\0') - errx(1, "invalid integer '%s'", - (char *)newval); + if (endptr == newval || *endptr != '\0') { + warn("invalid integer '%s'%s", + (char *)newval, line); + return (1); + } } newval = &intval; newsize = sizeof(intval); @@ -256,16 +293,16 @@ case CTLTYPE_UINT: uintval = (int) strtoul(newval, &endptr, 0); if (endptr == newval || *endptr != '\0') - errx(1, "invalid unsigned integer '%s'", - (char *)newval); + errx(1, "invalid unsigned integer " + "'%s'%s", (char *)newval, line); newval = &uintval; newsize = sizeof(uintval); break; case CTLTYPE_LONG: longval = strtol(newval, &endptr, 0); if (endptr == newval || *endptr != '\0') - errx(1, "invalid long integer '%s'", - (char *)newval); + errx(1, "invalid long integer '%s'%s", + (char *)newval, line); newval = &longval; newsize = sizeof(longval); break; @@ -273,7 +310,7 @@ ulongval = strtoul(newval, &endptr, 0); if (endptr == newval || *endptr != '\0') errx(1, "invalid unsigned long integer" - " '%s'", (char *)newval); + " '%s'%s", (char *)newval, line); newval = &ulongval; newsize = sizeof(ulongval); break; @@ -282,16 +319,16 @@ case CTLTYPE_S64: i64val = strtoimax(newval, &endptr, 0); if (endptr == newval || *endptr != '\0') - errx(1, "invalid int64_t '%s'", - (char *)newval); + errx(1, "invalid int64_t '%s'%s", + (char *)newval, line); newval = &i64val; newsize = sizeof(i64val); break; case CTLTYPE_U64: u64val = strtoumax(newval, &endptr, 0); if (endptr == newval || *endptr != '\0') - errx(1, "invalid uint64_t '%s'", - (char *)newval); + errx(1, "invalid uint64_t '%s'%s", + (char *)newval, line); newval = &u64val; newsize = sizeof(u64val); break; @@ -299,8 +336,8 @@ /* FALLTHROUGH */ default: errx(1, "oid '%s' is type %d," - " cannot set that", bufp, - kind & CTLTYPE); + " cannot set that%s", bufp, + kind & CTLTYPE, line); } i = show_var(mib, len); @@ -309,18 +346,20 @@ putchar('\n'); switch (errno) { case EOPNOTSUPP: - errx(1, "%s: value is not available", - string); + warn("%s: value is not available%s", string, + line); + return (1); case ENOTDIR: - errx(1, "%s: specification is incomplete", - string); + warn("%s: specification is incomplete%s", + string, line); + return (1); case ENOMEM: - errx(1, "%s: type is unknown to this program", - string); + warn("%s: type is unknown to this program%s", + string, line); + return (1); default: - warn("%s", string); - warncount++; - return; + warn("%s%s", string, line); + return (1); } } if (!bflag) @@ -332,8 +371,46 @@ putchar('\n'); nflag = i; } + + return (0); } +static int +parsefile(const char *filename) +{ + FILE *file; + char line[BUFSIZ], *p; + int warncount = 0, lineno = 0; + + file = fopen(filename, "r"); + if (file == NULL) + err(EX_NOINPUT, "%s", filename); + while (fgets(line, sizeof(line), file) != NULL) { + lineno++; + p = line; + /* Replace the first # with \0. */ + while((p = strchr(p, '#')) != NULL) { + if (p == line || *(p-1) != '\\') { + *p = '\0'; + break; + } + p++; + } + p = line; + while (isspace((int)p[strlen(p) - 1])) + p[strlen(p) - 1] = '\0'; + while (isspace((int)*p)) + p++; + if (*p == '\0') + continue; + else + warncount += parse(p, lineno); + } + fclose(file); + + return (warncount); +} + /* These functions will dump out various interesting structures. */ static int Index: etc/rc.d/sysctl =================================================================== --- etc/rc.d/sysctl (revision 243756) +++ etc/rc.d/sysctl (working copy) @@ -8,51 +8,27 @@ . /etc/rc.subr name="sysctl" +command=/sbin/sysctl stop_cmd=":" start_cmd="sysctl_start" reload_cmd="sysctl_start" lastload_cmd="sysctl_start last" extra_commands="reload lastload" -# -# Read in a file containing sysctl settings and set things accordingly. -# -parse_file() -{ - if [ -f $1 ]; then - while read var comments - do - case ${var} in - \#*|'') - ;; - *) - mib=${var%=*} - val=${var#*=} - - if current_value=`${SYSCTL} -n ${mib} 2>/dev/null`; then - case ${current_value} in - ${val}) - ;; - *) - if ! sysctl "${var}" >/dev/null 2>&1; then - warn "unable to set ${var}" - fi - ;; - esac - elif [ "$2" = "last" ]; then - warn "sysctl ${mib} does not exist." - fi - ;; - esac - done < $1 - fi -} - sysctl_start() { + case $1 in + last) + command_args="-i -f" + ;; + *) + command_args="-f" + ;; + esac - parse_file /etc/sysctl.conf $1 - parse_file /etc/sysctl.conf.local $1 + for _f in /etc/sysctl.conf /etc/sysctl.conf.local; do + [ -r $_f ] && $command $command_args $_f + done } load_rc_config $name ----Next_Part(Sun_Dec__2_01_50_48_2012_330)---- ----Security_Multipart0(Sun_Dec__2_01_50_48_2012_189)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlC6NWgACgkQTyzT2CeTzy0S9QCeMTjv42ScGn2UDpIkhacW38Xa byYAoNYcjnPOLWtoLwnt6TsGNo+RkRNa =19UY -----END PGP SIGNATURE----- ----Security_Multipart0(Sun_Dec__2_01_50_48_2012_189)---- From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 17:45:19 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18035BCE for ; Sat, 1 Dec 2012 17:45:19 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id B483D8FC13 for ; Sat, 1 Dec 2012 17:45:18 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1Ter7t-0008CD-HS>; Sat, 01 Dec 2012 18:45:17 +0100 Received: from e178034076.adsl.alicedsl.de ([85.178.34.76] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1Ter7s-000Sb1-3l>; Sat, 01 Dec 2012 18:45:17 +0100 Message-ID: <50BA4227.1040707@zedat.fu-berlin.de> Date: Sat, 01 Dec 2012 18:45:11 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "free >> Current FreeBSD" Subject: Revision: 243756: mtree: line 22: unknown user auditdistd X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2D1ACA9C8CF6FADB171F3B56" X-Originating-IP: 85.178.34.76 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 17:45:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2D1ACA9C8CF6FADB171F3B56 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Neither "make kernel" nor "mergemaster" works for me: make kernel" [...] Bc6K4/locale rm -rf /tmp/install.TagBc6K4 -------------------------------------------------------------- >>> Making hierarchy -------------------------------------------------------------- cd /usr/src; /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 LOCAL_MTREE=3D hierarchy cd /usr/src/etc; /usr/obj/usr/src/make.amd64/make distrib-dirs mtree -eU -f /usr/src/etc/mtree/BSD.root.dist -p / mtree -eU -f /usr/src/etc/mtree/BSD.var.dist -p /var mtree: line 22: unknown user auditdistd *** [distrib-dirs] Error code 1 Stop in /usr/src/etc. *** [hierarchy] Error code 1 Stop in /usr/src. *** [reinstall] Error code 1 Stop in /usr/src. *** [installworld] Error code 1 Stop in /usr/src. *** [installworld] Error code 1 Stop in /usr/src. mergemaster: *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot mtree: line 22: unknown user auditdistd *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to the temproot environment --------------enig2D1ACA9C8CF6FADB171F3B56 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.19 (FreeBSD) iQEcBAEBAgAGBQJQukIoAAoJEOgBcD7A/5N8UI0H/2eUpKyxmg0e+KNMgMaVVNkw dGczqOZznrojt7HrAKTCTA3VwlKCOjU6RTTaaPWljuFSXvJpY7Zk/zMkau0qNyij UOOTvyqvjPzFMCciEBr1x6GcpvDTiSE8bUupS2dUSs5QgRfJr+LDwxqpptHXdSAG C0LTnQ2Zoplc21JopIy6oVXWRHJsSvkGCW1hC8JadLA3gmWmEZtYQ9jBKs1zn3xe NH6Q0D8U2ulX/OEqtkTaMxu68JcAafA8pTAXOQR2DWM/7s+GFriL7sVvCaQq1Do8 SSvMePN4EB6AF7IowtH01zz/C78FRsyrrKXzR5OPf0aaSm4ZIdwC1nO9GaE4jtU= =c9qY -----END PGP SIGNATURE----- --------------enig2D1ACA9C8CF6FADB171F3B56-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 18:29:58 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F3D16B6 for ; Sat, 1 Dec 2012 18:29:58 +0000 (UTC) (envelope-from boris.t.ru@mail.ru) Received: from fallback5.mail.ru (fallback5.mail.ru [94.100.176.59]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7578FC13 for ; Sat, 1 Dec 2012 18:29:57 +0000 (UTC) Received: from smtp31.i.mail.ru (smtp31.i.mail.ru [94.100.177.91]) by fallback5.mail.ru (mPOP.Fallback_MX) with ESMTP id F21FDC48FF05 for ; Sat, 1 Dec 2012 22:29:48 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=AlMPwRfjCCwnZn05BXBiFxxMO7ajyYflcXBmDp8A8Eo=; b=LfxQ3vGTIU3BRmLpKOnaZqkBKOBBVZ/p0+N+BxpolG3q0hyTxUbQC7ExgRH6EbQEofM5XTKU6OFsRoUw6dvIzJivUWO5YMgSJh5vBcc8Tm4CzuC6daA3Uz6qBhtAzWOO; Received: from [212.119.243.183] (port=54234 helo=[192.168.229.10]) by smtp31.i.mail.ru with esmtpa (envelope-from ) id 1Teror-0005w0-Ry for current@freebsd.org; Sat, 01 Dec 2012 22:29:42 +0400 Message-ID: <50BA4C93.9050105@mail.ru> Date: Sun, 02 Dec 2012 00:29:39 +0600 From: Boris Talovikov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: current@freebsd.org Subject: gtpzfsboot: error 66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 18:29:58 -0000 please help I migrate from ufs to zfs I executed a script #!/bin/sh -v # $Id: zfs_install,v 1.3 2012/12/01 14:57:30 root Exp root $ GEOM=ada0 POOL=zroot POOL_CACHE=/tmp/zpool.cache MNT=/mnt BACKUP_FBSD=/media/hummingbird.tar.gz gpart backup $GEOM > /media/geom_backup_`date "+%s"` gpart destroy -F $GEOM gpart create -s gpt $GEOM gpart add -t freebsd-boot -a 4k -s 64k -l boot0 $GEOM gpart add -t freebsd-swap -a 4k -s 4G -l swap0 $GEOM gpart add -t freebsd-zfs -a 4k -l zroot0 $GEOM gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 $GEOM kldload opensolaris kldload zfs zpool create -f -o altroot=$MNT -o cachefile=$POOL_CACHE $POOL $GEOM\p3 zfs set checksum=fletcher4 $POOL zfs create -o compression=on -o exec=on -o setuid=off $POOL/tmp chmod 1777 $MNT/tmp zfs create $POOL/usr zfs create $POOL/usr/local zfs create $POOL/home zfs create -o compression=lzjb -o setuid=off $POOL/usr/ports zfs create -o compression=off -o exec=off -o setuid=off $POOL/usr/ports/distfiles zfs create -o compression=off -o exec=off -o setuid=off $POOL/usr/ports/package zfs create -o compression=lzjb -o exec=off -o setuid=off $POOL/usr/src zfs create $POOL/var zfs create -o compression=lzjb -o exec=off -o setuid=off $POOL/var/crash zfs create -o exec=off -o setuid=off $POOL/var/db zfs create -o compression=lzjb -o exec=on -o setuid=off $POOL/var/db/pkg zfs create -o exec=off -o setuid=off $POOL/var/empty zfs create -o compression=lzjb -o exec=off -o setuid=off $POOL/var/log zfs create -o compression=gzip -o exec=off -o setuid=off $POOL/var/mail zfs create -o exec=off -o setuid=off $POOL/var/run zfs create -o compression=lzjb -o exec=on -o setuid=off $POOL/var/tmp chmod 1777 /mnt/var/tmp tar -xzvf $BACKUP_FBSD -C / echo zfs_enable=\"YES\" >> $MNT/etc/rc.conf echo zfs_load=\"YES\" >> $MNT/boot/loader.conf echo vfs.root.mountfrom=\"zfs:$POOL\" >> $MNT/boot/loader.conf mv $MNT/etc/fstab $MNT/etc/fstab_backup echo /dev/$GEOM\p2 none swap sw 0 0 > $MNT/etc/fstab zfs unmount -af zpool export $POOL zpool import -o cachefile=$POOL_CACHE -o altroot=$MNT $POOL zfs set mountpoint=/ $POOL zpool set bootfs=$POOL $POOL cp $POOL_CACHE $MNT/boot/zfs/ zfs unmount -af zpool set cachefile='' $POOL zfs set mountpoint=legacy $POOL zfs set mountpoint=/tmp $POOL/tmp zfs set mountpoint=/usr $POOL/usr zfs set mountpoint=/var $POOL/var zfs set mountpoint=/home $POOL/home zfs set readonly=on $POOL/var/crash result: # gpart show => 34 488397101 ada0 GPT (232G) 34 6 - free - (3.0k) 40 128 1 freebsd-boot (64k) 168 8388608 2 freebsd-swap (4.0G) 8388776 480008352 3 freebsd-zfs (228G) 488397128 7 - free - (3.5k) => 63 62808001 da0 MBR (30G) 63 8001 - free - (3.9M) 8064 62800000 1 !12 (30G) => 0 15687680 da1 BSD (7.5G) 0 1065680 1 freebsd-ufs (520M) 1065680 14622000 - free - (7G) => 63 3911617 da2 MBR (1.9G) 63 66 - free - (33k) 129 3911551 1 !6 (1.9G) # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zroot 228G 24.9G 203G 10% 1.00x ONLINE - # zpool get all zroot NAME PROPERTY VALUE SOURCE zroot size 228G - zroot capacity 10% - zroot altroot - default zroot health ONLINE - zroot guid 16482364191304738607 default zroot version 28 default zroot bootfs zroot local zroot delegation on default zroot autoreplace off default zroot cachefile - default zroot failmode wait default zroot listsnapshots off default zroot autoexpand off default zroot dedupditto 0 default zroot dedupratio 1.00x - zroot free 203G - zroot allocated 24.9G - zroot readonly off - zroot comment - default zroot expandsize 0 - # zfs list NAME USED AVAIL REFER MOUNTPOINT zroot 24.9G 200G 1.09G legacy zroot/home 5.40G 200G 5.40G /home zroot/tmp 141M 200G 141M /tmp zroot/usr 17.6G 200G 7.85G /usr zroot/usr/local 5.55G 200G 5.55G /usr/local zroot/usr/ports 3.44G 200G 1.24G /usr/ports zroot/usr/ports/distfiles 2.21G 200G 2.21G /usr/ports/distfiles zroot/usr/ports/package 31K 200G 31K /usr/ports/package zroot/usr/src 784M 200G 784M /usr/src zroot/var 698M 200G 131M /var zroot/var/crash 402M 200G 402M /var/crash zroot/var/db 144M 200G 91.6M /var/db zroot/var/db/pkg 52.3M 200G 52.3M /var/db/pkg zroot/var/empty 31K 200G 31K /var/empty zroot/var/log 20.6M 200G 20.6M /var/log zroot/var/mail 34K 200G 34K /var/mail zroot/var/run 65.5K 200G 65.5K /var/run zroot/var/tmp 286K 200G 286K /var/tmp # zfs get all zroot NAME PROPERTY VALUE SOURCE zroot type filesystem - zroot creation Sat Dec 1 15:26 2012 - zroot used 24.9G - zroot available 200G - zroot referenced 1.09G - zroot compressratio 1.06x - zroot mounted no - zroot quota none default zroot reservation none default zroot recordsize 128K default zroot mountpoint legacy local zroot sharenfs off default zroot checksum fletcher4 local zroot compression off default zroot atime on default zroot devices on default zroot exec on default zroot setuid on default zroot readonly off default zroot jailed off default zroot snapdir hidden default zroot aclmode discard default zroot aclinherit restricted default zroot canmount on default zroot xattr on default zroot copies 1 default zroot version 5 - zroot utf8only off - zroot normalization none - zroot casesensitivity sensitive - zroot vscan off default zroot nbmand off default zroot sharesmb off default zroot refquota none default zroot refreservation none default zroot primarycache all default zroot secondarycache all default zroot usedbysnapshots 0 - zroot usedbydataset 1.09G - zroot usedbychildren 23.8G - zroot usedbyrefreservation 0 - zroot logbias latency default zroot dedup off default zroot mlslabel - zroot sync standard default zroot refcompressratio 1.00x - zroot written 1.09G - system does not boot gtpzfsboot: error 66 lba 48 gtpzfsboot: error 66 lba 1 gtpzfsboot: No ZFS pools located, can't boot please tell me what I'm doing wrong? freebsd 10-current From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 21:06:37 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02512347; Sat, 1 Dec 2012 21:06:37 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 79EAF8FC08; Sat, 1 Dec 2012 21:06:35 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id qB1L6WBH006056; Sat, 1 Dec 2012 22:06:33 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <50BA7158.1040302@fgznet.ch> Date: Sat, 01 Dec 2012 22:06:32 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Robert Watson Subject: Re: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: current@freebsd.org, security@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 21:06:37 -0000 On 01.12.12 16:15, Robert Watson wrote: > > Dear all: > > I've now committed the build glue required to install the recently merged > Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and > sponsored by the FreeBSD Foundation. This allows individual hosts generating > audit trails to submit trails to a central audit server for review and safe > keeping. Part of the goal is to ensure that a host submitting trail data > can't later modify the trails. Pawel uses a variety of useful security- and > resilience-related features such as TLS, Capsicum, etc, in auditdistd. As the > recent security incident in the FreeBSD.org cluster illustrated, having > reliable and detailed audit trails makes a big difference in forensic work, > and hopefully this will allow the FreeBSD Project (and our users) to do that > better in the future. Aehm, hope it is ok to 'complain' here. Happens when installing world. cd /export/devel/fbsd/head/src; /usr/obj/export/devel/fbsd/head/src/make.amd64/make -f Makefile.inc1 LOCAL_MTREE= hierarchy cd /export/devel/fbsd/head/src/etc; /usr/obj/export/devel/fbsd/head/src/make.amd64/make distrib-dirs mtree -eU -f /export/devel/fbsd/head/src/etc/mtree/BSD.root.dist -p / mtree -eU -f /export/devel/fbsd/head/src/etc/mtree/BSD.var.dist -p /var mtree: line 22: unknown user auditdistd *** [distrib-dirs] Error code 1 Andreas From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 21:52:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13AAC9E1 for ; Sat, 1 Dec 2012 21:52:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id BA0D68FC08 for ; Sat, 1 Dec 2012 21:52:52 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f19f:4a41:71ae:f9e6] (unknown [IPv6:2001:7b8:3a7:0:f19f:4a41:71ae:f9e6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 465C75C37; Sat, 1 Dec 2012 22:52:51 +0100 (CET) Message-ID: <50BA7C3A.70609@FreeBSD.org> Date: Sat, 01 Dec 2012 22:52:58 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: Revision: 243756: mtree: line 22: unknown user auditdistd References: <50BA4227.1040707@zedat.fu-berlin.de> In-Reply-To: <50BA4227.1040707@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 21:52:53 -0000 On 2012-12-01 18:45, O. Hartmann wrote: > Neither "make kernel" nor "mergemaster" works for me: ... > mtree: line 22: unknown user auditdistd Run mergemaster -p, as you should always do before installworld. From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 21:53:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4877AADE; Sat, 1 Dec 2012 21:53:29 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 672C08FC08; Sat, 1 Dec 2012 21:53:27 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so717670bkc.13 for ; Sat, 01 Dec 2012 13:53:27 -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=rTgbHlRXY7BL/aN4ZWhLNrMAPdi4MDwekr1ZnfRMGFE=; b=iIa82FzoqmAkZqfjzI3qVtJ3ptyFewEf2R3/55XOvlZGc8e5VTLdi72ga5xRjve8Dr 5Qak1ZjLZJY9D04v4rO9srjU1lMNlADCT6q3cxiQsW2YnuBBcfoH0xMXHsrlSEbNMA9a ACejHc2Tn+hCZ5KBYA/cmVf99s3q4ah2fzaJoNfAz7+19szCcnb99eOO6vxLUXrqKQXF K3F8IdExNC6bKBz46ondlya+dN90bCLyXeBRfpMPAstSLkawIKywYRGsgKxPHiqIA32L Q41ggX6tP287X0o2QogdoIdcZTa/ANRUMAKXXLFSpkz0/rhNqzr/H6b65xI4S+7QmrXO rUGA== MIME-Version: 1.0 Received: by 10.204.4.131 with SMTP id 3mr1567514bkr.25.1354398806976; Sat, 01 Dec 2012 13:53:26 -0800 (PST) Received: by 10.204.167.71 with HTTP; Sat, 1 Dec 2012 13:53:26 -0800 (PST) Received: by 10.204.167.71 with HTTP; Sat, 1 Dec 2012 13:53:26 -0800 (PST) In-Reply-To: <50BA7158.1040302@fgznet.ch> References: <50BA7158.1040302@fgznet.ch> Date: Sat, 1 Dec 2012 21:53:26 +0000 Message-ID: Subject: Re: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) From: Chris Rees To: Andreas Tobler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Robert Watson , current@freebsd.org, security@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 21:53:29 -0000 On 1 Dec 2012 21:51, "Andreas Tobler" wrote: > > On 01.12.12 16:15, Robert Watson wrote: > > > > Dear all: > > > > I've now committed the build glue required to install the recently merged > > Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and > > sponsored by the FreeBSD Foundation. This allows individual hosts generating > > audit trails to submit trails to a central audit server for review and safe > > keeping. Part of the goal is to ensure that a host submitting trail data > > can't later modify the trails. Pawel uses a variety of useful security- and > > resilience-related features such as TLS, Capsicum, etc, in auditdistd. As the > > recent security incident in the FreeBSD.org cluster illustrated, having > > reliable and detailed audit trails makes a big difference in forensic work, > > and hopefully this will allow the FreeBSD Project (and our users) to do that > > better in the future. > > Aehm, hope it is ok to 'complain' here. > > Happens when installing world. > > cd /export/devel/fbsd/head/src; > /usr/obj/export/devel/fbsd/head/src/make.amd64/make -f Makefile.inc1 > LOCAL_MTREE= hierarchy > cd /export/devel/fbsd/head/src/etc; > /usr/obj/export/devel/fbsd/head/src/make.amd64/make distrib-dirs > mtree -eU -f /export/devel/fbsd/head/src/etc/mtree/BSD.root.dist -p / > mtree -eU -f /export/devel/fbsd/head/src/etc/mtree/BSD.var.dist -p /var > mtree: line 22: unknown user auditdistd > *** [distrib-dirs] Error code 1 Does mergemaster -p help? Chris From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 22:09:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EDD7EAA; Sat, 1 Dec 2012 22:09:21 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id D9ADA8FC08; Sat, 1 Dec 2012 22:09:20 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id qB1M9B6Q087505; Sat, 1 Dec 2012 23:09:16 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <50BA8007.5030501@fgznet.ch> Date: Sat, 01 Dec 2012 23:09:11 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Chris Rees Subject: Re: Distributed audit daemon committed References: <50BA7158.1040302@fgznet.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Robert Watson , current@freebsd.org, security@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 22:09:21 -0000 On 01.12.12 22:53, Chris Rees wrote: > > On 1 Dec 2012 21:51, "Andreas Tobler" > wrote: >> >> On 01.12.12 16:15, Robert Watson wrote: >> > >> > Dear all: >> > >> > I've now committed the build glue required to install the recently > merged >> > Audit Distribution Daemon (auditdistd) contributed by the Pawel > Dawidek, and >> > sponsored by the FreeBSD Foundation. This allows individual hosts > generating >> > audit trails to submit trails to a central audit server for review > and safe >> > keeping. Part of the goal is to ensure that a host submitting trail > data >> > can't later modify the trails. Pawel uses a variety of useful > security- and >> > resilience-related features such as TLS, Capsicum, etc, in > auditdistd. As the >> > recent security incident in the FreeBSD.org cluster illustrated, having >> > reliable and detailed audit trails makes a big difference in > forensic work, >> > and hopefully this will allow the FreeBSD Project (and our users) to > do that >> > better in the future. >> >> Aehm, hope it is ok to 'complain' here. >> >> Happens when installing world. >> >> cd /export/devel/fbsd/head/src; >> /usr/obj/export/devel/fbsd/head/src/make.amd64/make -f Makefile.inc1 >> LOCAL_MTREE= hierarchy >> cd /export/devel/fbsd/head/src/etc; >> /usr/obj/export/devel/fbsd/head/src/make.amd64/make distrib-dirs >> mtree -eU -f /export/devel/fbsd/head/src/etc/mtree/BSD.root.dist -p / >> mtree -eU -f /export/devel/fbsd/head/src/etc/mtree/BSD.var.dist -p /var >> mtree: line 22: unknown user auditdistd >> *** [distrib-dirs] Error code 1 > > Does mergemaster -p help? Hey, thank you! I'm now able to installworld. Andreas From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 22:10:22 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3543ED0; Sat, 1 Dec 2012 22:10:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 961928FC0C; Sat, 1 Dec 2012 22:10:21 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2099963oag.13 for ; Sat, 01 Dec 2012 14:10:20 -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=JldwXiYEvlndzPi1Qr8krwwoP7ZCVpuMuxei7RmMbV8=; b=prVeIBoV96ffzPPgSxsw9FUNyud7KFH3HSOSg0pnXPUxk3RUUTRDbCdzkZqjLInU8A 646uRW/9RthmjX/aqGZ7RMXJs5+4OdmEIZCM0Oz2OK6VsVxj0oVbA4YQJKwPAMC7gZKh 6dCdcRbzXIskfkD/ojCIlCk5I9rPu+LtkvTTmPSu4tzTufCo7jEJqsgRUQmj12lJwIZg 7lp4/ggjIUg9ZbASygn8a8DjMq4OT0xxv2q+NwNLZrARdXOqR+upDcShOz0eQn9wHiCm o8tv5wVmSmYBDdhDXtbF7RbW5+GShlcty6lUM6/Cleb/v0aphv6R/NIv867+9DREbUfZ QVQg== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr4608090oeb.24.1354399820833; Sat, 01 Dec 2012 14:10:20 -0800 (PST) Received: by 10.76.143.33 with HTTP; Sat, 1 Dec 2012 14:10:20 -0800 (PST) In-Reply-To: <20121202.015048.1122480556487090170.hrs@allbsd.org> References: <20121202.015048.1122480556487090170.hrs@allbsd.org> Date: Sat, 1 Dec 2012 14:10:20 -0800 Message-ID: Subject: Re: RFC: sysctl -f filename From: Garrett Cooper To: Hiroki Sato Content-Type: text/plain; charset=ISO-8859-1 Cc: rc@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 22:10:22 -0000 On Sat, Dec 1, 2012 at 8:50 AM, Hiroki Sato wrote: > Hi, > > I would like comments about the attached patch for sysctl(8) to add a > new option "-f filename". It supports reading of a file with > key=value lines. > > As you probably know, we already have /etc/sysctl.conf and it is > processed by rc.d/sysctl shell script in a line-by-line basis. The > problem I want to fix is a confusing syntax of /etc/sysctl.conf. The > file supports a typical configuration file syntax but problematic in > some cases. For example: > > kern.coredump=1 > > works well in /etc/sysctl.conf, but > > kern.coredump="1" > > does not work. Similarly, it is difficult to use whitespaces and "#" > in the value: > > OK: kern.domainname=domain\ name\ with\ spaces > NG: kern.domainname="domain name with spaces" > NG: kern.domainname=domain\ name\ including\ #\ character > NG: kern.domainname=domain\ name\ including\ \#\ character > > The attached patch solves them, and in addition it displays an error > message with a line number if there is something wrong in the file > like this: > > % cat -n /etc/sysctl.conf > ... > 10 kern.coredump=1 > 11 kern.coredump2=1 > ... > > % /etc/rc.d/sysctl start > sysctl: kern.coredump at line 10: Operation not permitted > sysctl: unknown oid 'kern.coredump2' at line 11 > > # /etc/rc.d/sysctl start > kern.coredump: 1 -> 1 > sysctl: unknown oid 'kern.coredump2' at line 11 > > Any comments are welcome. Why change the tool when we can change the rc script to do the right thing? I have a patch I'm working on to resolve this (you hit an itch I've been meaning to scratch for a little while). Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 22:12:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AA1F2B6 for ; Sat, 1 Dec 2012 22:12:26 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id D74328FC18 for ; Sat, 1 Dec 2012 22:12:25 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1668262lah.13 for ; Sat, 01 Dec 2012 14:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UqAVa1Er64fTCIAytFddMjClI/oE/ZBJq2pAoDuupHs=; b=cfsEtshJbb6qOrjayq50qSMjcYOh4UaVRAQI0AUZRtONG9UPu2ZcRJ5u+mJTtnp8u1 af6TTtX/U8bH4zy9ZNcldUkybzgDR7g9XKiCj87gH60qizOV7fRM8XL3SsjY3IAqho4h mapA9qcFUX0RHVebsnREbgaxnyttBxwzcWTZ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=UqAVa1Er64fTCIAytFddMjClI/oE/ZBJq2pAoDuupHs=; b=EydXX4huS/zNMCy/mJbCajWmq6gEPpyNt8YlqSm8fMGklgUZIKKgcMcNy5+VB0omlU JqL4ehSXl6p+H29ftAS9B9Db8i9XeTqqEis1pjTCxdsTRzdNye4mS+iO50tRSWgUfY11 uhBRVzSOdhY9YLdO2E+af7TBDDPVBjqZVLiMXo9CgxEa1XJ6TTcDffJeTgiaKAT0XkE7 M/gcGkVbq/BGHWzJfJFwCgHue4/tCn5jFqeZyXoDCTSlzFsMqR8Ty0EUC/mUEdgX7zn/ W2xdHbkaHSSV+1wOPGM2C6LNmFcA8rm6FVaruMmSYCrRf8mWzMDA8c3jVUwZ/5ktyJ8V cr4A== MIME-Version: 1.0 Received: by 10.112.8.37 with SMTP id o5mr2507271lba.135.1354399944305; Sat, 01 Dec 2012 14:12:24 -0800 (PST) Sender: simon@qxnitro.org Received: by 10.112.134.196 with HTTP; Sat, 1 Dec 2012 14:12:24 -0800 (PST) X-Originating-IP: [89.100.2.68] In-Reply-To: <50BA7158.1040302@fgznet.ch> References: <50BA7158.1040302@fgznet.ch> Date: Sat, 1 Dec 2012 22:12:24 +0000 X-Google-Sender-Auth: m9ht55Q3-0ka9njDeKQuPIexB8U Message-ID: Subject: Re: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) From: "Simon L. B. Nielsen" To: Andreas Tobler Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmzwbO+MmfX4XcuQtXfpuFUFJgAiGNRMzsUv7+DKscJZ3I1V7Pz1Obyq/aYBaDvnsac5IDt Cc: Robert Watson , current@freebsd.org, security@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 22:12:26 -0000 On 1 December 2012 21:06, Andreas Tobler wrote: > On 01.12.12 16:15, Robert Watson wrote: >> >> Dear all: >> >> I've now committed the build glue required to install the recently merged >> Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and >> sponsored by the FreeBSD Foundation. This allows individual hosts generating >> audit trails to submit trails to a central audit server for review and safe >> keeping. Part of the goal is to ensure that a host submitting trail data >> can't later modify the trails. Pawel uses a variety of useful security- and >> resilience-related features such as TLS, Capsicum, etc, in auditdistd. As the >> recent security incident in the FreeBSD.org cluster illustrated, having >> reliable and detailed audit trails makes a big difference in forensic work, >> and hopefully this will allow the FreeBSD Project (and our users) to do that >> better in the future. > > Aehm, hope it is ok to 'complain' here. > > Happens when installing world. > > cd /export/devel/fbsd/head/src; > /usr/obj/export/devel/fbsd/head/src/make.amd64/make -f Makefile.inc1 > LOCAL_MTREE= hierarchy > cd /export/devel/fbsd/head/src/etc; > /usr/obj/export/devel/fbsd/head/src/make.amd64/make distrib-dirs > mtree -eU -f /export/devel/fbsd/head/src/etc/mtree/BSD.root.dist -p / > mtree -eU -f /export/devel/fbsd/head/src/etc/mtree/BSD.var.dist -p /var > mtree: line 22: unknown user auditdistd > *** [distrib-dirs] Error code 1 Did you remember mergemaster -p before installworld? -- Simon L. B. Nielsen From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 22:33:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C896968; Sat, 1 Dec 2012 22:33:44 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AC8328FC0C; Sat, 1 Dec 2012 22:33:43 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so1850083obc.13 for ; Sat, 01 Dec 2012 14:33:43 -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=BYhZlpAhqXB64AqTiS/QHgU9h5yeXPytc0OX8p5ZUqM=; b=NuBV2poVUXvaKPW9R35OHAHD0eNJjWF7miaafwuWKtld7wqbkS4vhl0F78EKXU3EY5 3VB4mQ4qLl8DJATGtOTzp0+iVZcg/BSH/O4MgH1cbDBi6ZVdb4BTfPhVVkunsvoHWBux RYZ3XdGGD7ozMJpJUEOBPqj4Byl4ytHWrdJ/k+F1y96S97G5zzqha+is94dLFnq8Wc9Z h7e40l+kr6zTNFR/wdvXG3qQAhnbTn8jEcx1qU3rxMViFFeB702/pWRRnfkNENoDk0v7 3GjjpV+vNigWFw3J6Vn/gCJu+/Un2RMfNYQjv4ueZ6Au2KX62X4MPxfEXYGWzwyPJKvz He/w== MIME-Version: 1.0 Received: by 10.182.172.74 with SMTP id ba10mr962946obc.83.1354401223193; Sat, 01 Dec 2012 14:33:43 -0800 (PST) Received: by 10.76.143.33 with HTTP; Sat, 1 Dec 2012 14:33:42 -0800 (PST) In-Reply-To: References: <20121202.015048.1122480556487090170.hrs@allbsd.org> Date: Sat, 1 Dec 2012 14:33:42 -0800 Message-ID: Subject: Re: RFC: sysctl -f filename From: Garrett Cooper To: Hiroki Sato Content-Type: multipart/mixed; boundary=e89a8f839f6fcab2b704cfd21bbb Cc: rc@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 22:33:44 -0000 --e89a8f839f6fcab2b704cfd21bbb Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 1, 2012 at 2:10 PM, Garrett Cooper wrote: > On Sat, Dec 1, 2012 at 8:50 AM, Hiroki Sato wrote: >> Hi, >> >> I would like comments about the attached patch for sysctl(8) to add a >> new option "-f filename". It supports reading of a file with >> key=value lines. >> >> As you probably know, we already have /etc/sysctl.conf and it is >> processed by rc.d/sysctl shell script in a line-by-line basis. The >> problem I want to fix is a confusing syntax of /etc/sysctl.conf. The >> file supports a typical configuration file syntax but problematic in >> some cases. For example: >> >> kern.coredump=1 >> >> works well in /etc/sysctl.conf, but >> >> kern.coredump="1" >> >> does not work. Similarly, it is difficult to use whitespaces and "#" >> in the value: >> >> OK: kern.domainname=domain\ name\ with\ spaces >> NG: kern.domainname="domain name with spaces" >> NG: kern.domainname=domain\ name\ including\ #\ character >> NG: kern.domainname=domain\ name\ including\ \#\ character >> >> The attached patch solves them, and in addition it displays an error >> message with a line number if there is something wrong in the file >> like this: >> >> % cat -n /etc/sysctl.conf >> ... >> 10 kern.coredump=1 >> 11 kern.coredump2=1 >> ... >> >> % /etc/rc.d/sysctl start >> sysctl: kern.coredump at line 10: Operation not permitted >> sysctl: unknown oid 'kern.coredump2' at line 11 >> >> # /etc/rc.d/sysctl start >> kern.coredump: 1 -> 1 >> sysctl: unknown oid 'kern.coredump2' at line 11 >> >> Any comments are welcome. > > Why change the tool when we can change the rc script to do the > right thing? I have a patch I'm working on to resolve this (you hit an > itch I've been meaning to scratch for a little while). This should work. I also refactored the script to get it down to 80 columns. I've attached the debug output and the diff for the debug version of the script. Cheers, -Garrett # diff -u etc/rc.d/sysctl etc/rc.d/sysctl.debug | sed -e 's,\.debug,,' --- etc/rc.d/sysctl 2012-12-01 14:29:31.948502097 -0800 +++ etc/rc.d/sysctl 2012-12-01 14:29:21.694501765 -0800 @@ -38,6 +38,10 @@ val="${val#\"*}" val="${val%%\"*}" + debug "line -> '$line'" + debug "mib -> '$mib'" + debug "val -> '$val'" + if current_value=`${SYSCTL} -n "${mib}" 2>/dev/null`; then if [ "${current_value}" = "${val}" ]; then continue ./etc/rc.d/sysctl: DEBUG: run_rc_command: doit: sysctl_start ./etc/rc.d/sysctl: DEBUG: line -> 'net.inet.tcp.recvspace=262144' ./etc/rc.d/sysctl: DEBUG: mib -> 'net.inet.tcp.recvspace' ./etc/rc.d/sysctl: DEBUG: val -> '262144' ./etc/rc.d/sysctl: DEBUG: line -> 'net.inet.tcp.sendspace="231072' ./etc/rc.d/sysctl: DEBUG: mib -> 'net.inet.tcp.sendspace' ./etc/rc.d/sysctl: DEBUG: val -> '231072' ./etc/rc.d/sysctl: DEBUG: line -> 'net.inet.tcp.sendspace="131074"' ./etc/rc.d/sysctl: DEBUG: mib -> 'net.inet.tcp.sendspace' ./etc/rc.d/sysctl: DEBUG: val -> '131074' ./etc/rc.d/sysctl: DEBUG: line -> 'net.inet.udp.recvspace=131072' ./etc/rc.d/sysctl: DEBUG: mib -> 'net.inet.udp.recvspace' ./etc/rc.d/sysctl: DEBUG: val -> '131072' ./etc/rc.d/sysctl: DEBUG: line -> 'kern.corefile=' ./etc/rc.d/sysctl: DEBUG: mib -> 'kern.corefile' ./etc/rc.d/sysctl: DEBUG: val -> '' ./etc/rc.d/sysctl: DEBUG: line -> 'kern.corefile="#' ./etc/rc.d/sysctl: DEBUG: mib -> 'kern.corefile' ./etc/rc.d/sysctl: DEBUG: val -> '#' ./etc/rc.d/sysctl: DEBUG: line -> 'kern.corefile="# abcd' ./etc/rc.d/sysctl: DEBUG: mib -> 'kern.corefile' ./etc/rc.d/sysctl: DEBUG: val -> '# abcd' ./etc/rc.d/sysctl: DEBUG: line -> 'kern.corefile="# abcd" #' ./etc/rc.d/sysctl: DEBUG: mib -> 'kern.corefile' ./etc/rc.d/sysctl: DEBUG: val -> '# abcd' ./etc/rc.d/sysctl: DEBUG: line -> 'kern.corefile="# abcd" #' ./etc/rc.d/sysctl: DEBUG: mib -> 'kern.corefile' ./etc/rc.d/sysctl: DEBUG: val -> '# abcd' ./etc/rc.d/sysctl: DEBUG: line -> 'kern.corefile="# abcd " #' ./etc/rc.d/sysctl: DEBUG: mib -> 'kern.corefile' ./etc/rc.d/sysctl: DEBUG: val -> '# abcd ' ./etc/rc.d/sysctl: DEBUG: line -> 'kern.corefile="# abcd " #' ./etc/rc.d/sysctl: DEBUG: mib -> 'kern.corefile' ./etc/rc.d/sysctl: DEBUG: val -> '# abcd ' ./etc/rc.d/sysctl: DEBUG: line -> 'kern.corefile="%N.core"' ./etc/rc.d/sysctl: DEBUG: mib -> 'kern.corefile' ./etc/rc.d/sysctl: DEBUG: val -> '%N.core' --e89a8f839f6fcab2b704cfd21bbb Content-Type: application/octet-stream; name="make-etc-rc.d-sysctl-quote-comment-and-space-aware.patch" Content-Disposition: attachment; filename="make-etc-rc.d-sysctl-quote-comment-and-space-aware.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ha7bej930 SW5kZXg6IGV0Yy9yYy5kL3N5c2N0bAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcmMuZC9zeXNjdGwJKHJl dmlzaW9uIDI0Mzc0NykKKysrIGV0Yy9yYy5kL3N5c2N0bAkod29ya2luZyBjb3B5KQpAQCAtMTks MzMgKzE5LDM2IEBACiAjCiBwYXJzZV9maWxlKCkKIHsKLQlpZiBbIC1mICQxIF07IHRoZW4KLQkJ d2hpbGUgcmVhZCB2YXIgY29tbWVudHMKLQkJZG8KLQkJCWNhc2UgJHt2YXJ9IGluCi0JCQlcIyp8 JycpCi0JCQkJOzsKLQkJCSopCi0JCQkJbWliPSR7dmFyJT0qfQotCQkJCXZhbD0ke3ZhciMqPX0K KwlpZiBbICEgLWYgIiQxIiBdOyB0aGVuCisJCXJldHVybiAwCisJZmkKKwlsb2NhbCBJRlM9Igor IgorCXdoaWxlIHJlYWQgbGluZQorCWRvCisJCWNhc2UgIiR7bGluZSVcIyp9IiBpbgorCQknJykK KwkJCWNvbnRpbnVlCisJCQk7OworCQllc2FjCisJCWxpbmU9IiR7bGluZSVcICp9IgogCi0JCQkJ aWYgY3VycmVudF92YWx1ZT1gJHtTWVNDVEx9IC1uICR7bWlifSAyPi9kZXYvbnVsbGA7IHRoZW4K LQkJCQkJY2FzZSAke2N1cnJlbnRfdmFsdWV9IGluCi0JCQkJCSR7dmFsfSkKLQkJCQkJCTs7Ci0J CQkJCSopCi0JCQkJCQlpZiAhIHN5c2N0bCAiJHt2YXJ9IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4K LQkJCQkJCQl3YXJuICJ1bmFibGUgdG8gc2V0ICR7dmFyfSIKLQkJCQkJCWZpCi0JCQkJCQk7Owot CQkJCQllc2FjCi0JCQkJZWxpZiBbICIkMiIgPSAibGFzdCIgXTsgdGhlbgotCQkJCQl3YXJuICJz eXNjdGwgJHttaWJ9IGRvZXMgbm90IGV4aXN0LiIKLQkJCQlmaQotCQkJCTs7Ci0JCQllc2FjCi0J CWRvbmUgPCAkMQotCWZpCisJCW1pYj0iJHtsaW5lJT0qfSIKKwkJdmFsPSIke2xpbmUjKj19Igor CQl2YWw9IiR7dmFsI1wiKn0iCisJCXZhbD0iJHt2YWwlJVwiKn0iCisKKwkJaWYgY3VycmVudF92 YWx1ZT1gJHtTWVNDVEx9IC1uICIke21pYn0iIDI+L2Rldi9udWxsYDsgdGhlbgorCQkJaWYgWyAi JHtjdXJyZW50X3ZhbHVlfSIgPSAiJHt2YWx9IiBdOyB0aGVuCisJCQkJY29udGludWUKKwkJCWZp CisJCQlpZiAhIHN5c2N0bCAiJHttaWJ9PSR7dmFsfSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJ CQkJd2FybiAidW5hYmxlIHRvIHNldCAke21pYn09JHt2YWx9IgorCQkJZmkKKwkJZWxpZiBbICIk MiIgPSAibGFzdCIgXTsgdGhlbgorCQkJd2FybiAic3lzY3RsICR7bWlifSBkb2VzIG5vdCBleGlz dC4iCisJCWZpCisJZG9uZSA8ICIkMSIKIH0KIAogc3lzY3RsX3N0YXJ0KCkK --e89a8f839f6fcab2b704cfd21bbb-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 23:32:31 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E610294; Sat, 1 Dec 2012 23:32:31 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id AB1F88FC12; Sat, 1 Dec 2012 23:32:27 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id qB1NWACj098678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Dec 2012 08:32:20 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id qB1NW8Vn050788; Sun, 2 Dec 2012 08:32:09 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 02 Dec 2012 08:21:50 +0900 (JST) Message-Id: <20121202.082150.896017277887885294.hrs@allbsd.org> To: yanegomi@gmail.com Subject: Re: RFC: sysctl -f filename From: Hiroki Sato In-Reply-To: References: <20121202.015048.1122480556487090170.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Dec__2_08_21_50_2012_024)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sun, 02 Dec 2012 08:32:20 +0900 (JST) X-Spam-Status: No, score=-98.1 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: rc@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 23:32:32 -0000 ----Security_Multipart(Sun_Dec__2_08_21_50_2012_024)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Garrett Cooper wrote in : ya> On Sat, Dec 1, 2012 at 2:10 PM, Garrett Cooper wrote: ya> > Why change the tool when we can change the rc script to do the ya> > right thing? I have a patch I'm working on to resolve this (you hit an ya> > itch I've been meaning to scratch for a little while). ya> ya> This should work. I also refactored the script to get it down to ya> 80 columns. I've attached the debug output and the diff for the debug ya> version of the script. You will find out the following test case does not work (this is one of the test strings I used): kern.domainname="c$EDITOR.\"\ hoge\ \"\#hoge2\\$ \# h$$\#oge"# The reason why I changed sysctl(8) was that the rc.d/sysctl script was too complex and slow even if it could support meta characters in shell script syntax. I created several prototypes as script but noticed that keeping consistency was quite difficult and maintainability was poor due to tricky handling of variables. Although my patch in the previous email does not support meta characters completely, I still think it is more reasonable to implement this functionality on the sysctl(8) side. -- Hiroki ----Security_Multipart(Sun_Dec__2_08_21_50_2012_024)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlC6kQ4ACgkQTyzT2CeTzy1sjQCguq+9gj8qNTMzQJbV1uVmyoCL RagAoNktNXOzlZuAk5aZC9Ax7MH0oyiN =ZWBX -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Dec__2_08_21_50_2012_024)---- From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 23:38:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C680290; Sat, 1 Dec 2012 23:38:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id BBB708FC08; Sat, 1 Dec 2012 23:37:59 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qB1NbuZp010540; Sun, 2 Dec 2012 01:37:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qB1NbuZp010540 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qB1NbutC010539; Sun, 2 Dec 2012 01:37:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 2 Dec 2012 01:37:56 +0200 From: Konstantin Belousov To: Hiroki Sato Subject: Re: RFC: sysctl -f filename Message-ID: <20121201233756.GS3013@kib.kiev.ua> References: <20121202.015048.1122480556487090170.hrs@allbsd.org> <20121202.082150.896017277887885294.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lfL9iWt62hyVv4Jn" Content-Disposition: inline In-Reply-To: <20121202.082150.896017277887885294.hrs@allbsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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: yanegomi@gmail.com, rc@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 23:38:00 -0000 --lfL9iWt62hyVv4Jn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 02, 2012 at 08:21:50AM +0900, Hiroki Sato wrote: > Garrett Cooper wrote > in : >=20 > ya> On Sat, Dec 1, 2012 at 2:10 PM, Garrett Cooper w= rote: > ya> > Why change the tool when we can change the rc script to do the > ya> > right thing? I have a patch I'm working on to resolve this (you hit= an > ya> > itch I've been meaning to scratch for a little while). > ya> > ya> This should work. I also refactored the script to get it down to > ya> 80 columns. I've attached the debug output and the diff for the debug > ya> version of the script. >=20 > You will find out the following test case does not work (this is one > of the test strings I used): >=20 > kern.domainname=3D"c$EDITOR.\"\ hoge\ \"\#hoge2\\$ \# h$$\#oge"# >=20 > The reason why I changed sysctl(8) was that the rc.d/sysctl script > was too complex and slow even if it could support meta characters in > shell script syntax. I created several prototypes as script but > noticed that keeping consistency was quite difficult and > maintainability was poor due to tricky handling of variables. >=20 > Although my patch in the previous email does not support meta > characters completely, I still think it is more reasonable to > implement this functionality on the sysctl(8) side. >=20 > -- Hiroki I fully agree with the proposal to add the -f switch to the sysctl(8). This is consistent with several other administrative tools. Putting the ability to parse and apply arbitrary sysctl.conf-like file into=20 the rc script is weird. --lfL9iWt62hyVv4Jn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQupTTAAoJEJDCuSvBvK1BSLEQAIKuOn4rfK6jKjfEL1dbQV5k Ioqan+cvl4GoDZVBfF+NL6U22qBQdbuRa0rV8V1SnG8UYc/hjqd65Xxl00G6CRAb zhuR1kccpxjp2IN4wyYdGecXi00iRqdJeWGinL03Z/NpCr0zrgMR9RA5zM9KcJrZ vofQbkY/28VqsxxS6S/i8avbV3060T81EeupzFW5olv8Gf97M3nDiRJbP0S4EwXV QXs3rIONv+Y8+Ny00sVDfyBxfQ66nRYbmvlJcs/5SNW7cfk6BGg+4g81hNhmGlCb L4SKBMoiW+1Ls1AxhFOFUSFCL4xVINP6px4LqL/TJYR0mTrIYe7YCPDih4KYkIL4 U8DTbCbZTwBegnExNyDNeDgBug/JyIMrjBfFJeoNhKc6Kqw2inL5eO5lY49bE0hB ypiy8FXNjU0cW0OwrC8TvANstJ4Gif98DKjc9OufoatK7LKCDLgxPJ0gtV6mL+V4 605dXtURT6sIWgrrmSbYWVukUlEF7IOgCU/S2OZzz3mrsFC1kTlpOKboH+TLvLd8 OWaDJMnNEj5IOyQUJJ5RSAAKD9K9Pyy2StOLQOtoMCa5FdFANtVLnY3IXfh+wP2+ dqb2Wxg6r9h1iseaETCKxsDtroIw5GDqnYx1qZIUozD26q0hoiF5POn26jZKIMZ9 R7ym6rVAvCTGZlxULVyk =2uEK -----END PGP SIGNATURE----- --lfL9iWt62hyVv4Jn-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 1 23:44:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4F153F0; Sat, 1 Dec 2012 23:44:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7235B8FC12; Sat, 1 Dec 2012 23:44:25 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qB1NiOXe000763; Sat, 1 Dec 2012 16:44:25 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qB1Ni2l6044024; Sat, 1 Dec 2012 16:44:02 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: RFC: sysctl -f filename From: Ian Lepore To: Hiroki Sato In-Reply-To: <20121202.015048.1122480556487090170.hrs@allbsd.org> References: <20121202.015048.1122480556487090170.hrs@allbsd.org> Content-Type: text/plain; charset="us-ascii" Date: Sat, 01 Dec 2012 16:44:02 -0700 Message-ID: <1354405442.69940.586.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Dec 2012 23:44:25 -0000 On Sun, 2012-12-02 at 01:50 +0900, Hiroki Sato wrote: > Hi, > > I would like comments about the attached patch for sysctl(8) to add a > new option "-f filename". It supports reading of a file with > key=value lines. > > As you probably know, we already have /etc/sysctl.conf and it is > processed by rc.d/sysctl shell script in a line-by-line basis. The > problem I want to fix is a confusing syntax of /etc/sysctl.conf. The > file supports a typical configuration file syntax but problematic in > some cases. For example: > > kern.coredump=1 > > works well in /etc/sysctl.conf, but > > kern.coredump="1" > > does not work. Similarly, it is difficult to use whitespaces and "#" > in the value: > > OK: kern.domainname=domain\ name\ with\ spaces > NG: kern.domainname="domain name with spaces" > NG: kern.domainname=domain\ name\ including\ #\ character > NG: kern.domainname=domain\ name\ including\ \#\ character > > The attached patch solves them, and in addition it displays an error > message with a line number if there is something wrong in the file > like this: > > % cat -n /etc/sysctl.conf > ... > 10 kern.coredump=1 > 11 kern.coredump2=1 > ... > > % /etc/rc.d/sysctl start > sysctl: kern.coredump at line 10: Operation not permitted > sysctl: unknown oid 'kern.coredump2' at line 11 > > # /etc/rc.d/sysctl start > kern.coredump: 1 -> 1 > sysctl: unknown oid 'kern.coredump2' at line 11 > > Any comments are welcome. > > -- Hiroki This is cool, thanks. Shouldn't there be an update to sysctl.conf(5) to mention the ability to handle quoting now? -- Ian