From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 02:26:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBC1ADD for ; Sun, 16 Nov 2014 02:26:23 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3D6D7E1 for ; Sun, 16 Nov 2014 02:26:23 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id lf10so19874707pab.19 for ; Sat, 15 Nov 2014 18:26: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=m7oYquO38ulUQ78TGtisS9YrYGZeHP481brF0pyPnEU=; b=FjF2XWiMol/0WKhQXG5x8UzEeU1D6yttfu5NEF3BQtqZbRIjC3k70fpd2/qWSsdi9q X/1z8ut+vmgs7j8ttflkwwIv/LgkfraGERhStwtxStA5shduT/1Qu71yOuaT/vhLU/MH 3KvDMu/JY0lqtGlaDXFFta+tMbQ5YS9fr7zo+P0Wgv/p2d4B/ORXtzIXW3V6BMAqP1Hn RlsReMLoLkKuqrBVe0QrQaMmWgdMIOW4CLWSpk9fKKE9myrZQFkAB5AxvWRMXpyHnM+/ 290aqmXsP+uu6fmVQljNy/ptr0zo2eimov7OY92hzetjM5a1RGE6rOaihRc7V1aHg6Lz EKKg== X-Received: by 10.70.138.104 with SMTP id qp8mr19719949pdb.99.1416104783171; Sat, 15 Nov 2014 18:26:23 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([97.84.68.201]) by mx.google.com with ESMTPSA id bf2sm31343638pbb.13.2014.11.15.18.26.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Nov 2014 18:26:22 -0800 (PST) Sender: Alexander Motin Message-ID: <54680B4C.9020207@FreeBSD.org> Date: Sun, 16 Nov 2014 04:26:20 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Garrett Cooper , "Ranjan1018 ." <214748mv@gmail.com> Subject: Re: [PATCH] gstat on SSD References: <1263A474-E3B8-4942-A0AA-6692F509138F@gmail.com> In-Reply-To: <1263A474-E3B8-4942-A0AA-6692F509138F@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 02:26:24 -0000 On 15.11.2014 23:35, Garrett Cooper wrote: > On Nov 15, 2014, at 8:04, Ranjan1018 . <214748mv@gmail.com> wrote: >> I am running a pair of servers with SSD. In gstat the default >> display of operation/ms is only one digit after the comma and >> there are a lot of R/W operation displayed with the 0.1 value. >> This simple patch displays the operation/ms with two decimal >> digit. >> >> What’s next ? After testing this patch for a day, recording the >> values in a log file, I have found that some write operation are >> only 0.02 ms short, on a OCZ Vertex SSD. Probably the next patch >> is to display micro seconds instead of milli seconds. >> >> Maurizio >> >> FreeBSD 11 gstat.c.patch > > LGTM, but I don’t have hardware capable of that precision so I > can’t verify the patch other than build test it and run it for what > existing cases I have. > > What do you think Alexander? SSD in my laptop can to 20K simple case IOPS in one stream, that means ~50us time. So I think this patch should not harm. From the other side these numbers are mostly informational, since any real performance investigation would require a histogram rather the a single average number. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 05:41:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61AD2F5F; Sun, 16 Nov 2014 05:41:44 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 23B74B2B; Sun, 16 Nov 2014 05:41:44 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAG5fggH033198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Nov 2014 21:41:42 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAG5ff60033197; Sat, 15 Nov 2014 21:41:41 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Nov 2014 21:41:41 -0800 From: Steve Kargl To: Hans Petter Selasky Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141116054141.GA33186@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141113212206.GA20802@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 05:41:44 -0000 On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: > On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: > > On 11/13/14 19:15, Steve Kargl wrote: > > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: > > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > > >>>> I have a kernel/world from r274273 sources, which is exhibiting a new > > >>>> issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > > >>>> work. I get to the end of shutdown and see for example > > >>>> > > >>>> All buffers synced > > >>>> Uptime: 4h23m15s > > >>>> > > >>>> and then the laptop just sits there. It does not power off with > > >>>> the -p option nor does it reboot with the -r. Has anyone else > > >>>> seen this behavior? > > >>>> > > >>> > > >>> The problem appears to be related to a recent change in the > > >>> USB stack. If I have the following drive plugged into a > > >>> usb port, the above behavior is observed on shutdown. > > >>> > > > > > > Adding > > > > > > hw.usb.no_shutdown_wait: 1 > > > > > > to /boot/loader.conf appears to work around the 'shutdown -p now' > > > and 'shutdown -r now' issue. Unfortunately, the bricking of the > > > laptop is not affected by this sysctl. Once a device is plugged > > > into a usb, it must remain plugged in. > > > > > > > Hi, > > > > Is using this sysctl/tunable a suitable solution for you? > > > > The sysctl is a suitable solution for the shutdown issues. > It is not suitable solution for the general use of using > a memory stick to for example quickly transfer files. Once > the memory stick is plugged into the usb port, it must > remain there unless one wants to reboot the system. > > I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. > I need to wade through a rather large /var/log/messages > to see if anything appears unusual. > Well, this has been a waste of a day. The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 05:44:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66571EF; Sun, 16 Nov 2014 05:44:20 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E83D4B51; Sun, 16 Nov 2014 05:44:19 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id n3so2699812wiv.2 for ; Sat, 15 Nov 2014 21:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OtwtPP4tQpFxBPBmHb8VN9zz8hYggqpus3GW8cqswnc=; b=DZYsQPAXSiIiwr3oSGOuJZ2199bOWc/nodGYEYVFL5vWPgnE1BfjFKj9xhWXa686AB WQDqQCoXUlTGJGT8+AXMLgsLA6us/BVc3wD0OrSzYJ2ccoCErU5HDcBHutR9OnfJR7eh A1GJ4D6efVyX+BcTKtBv9DNUZqcczfejsCQ0K2pEdz9QwKOWfuMKxFkoUrcC2NlAGRSv /TS8vfCtyh9PXS4NLOBDt8wJ6xc2jUfwXD5/h1Zlz/2tFiYYa1L0DF2+OPNO8+159IH0 VNeK1cCuvaxGFw4QlJOrt6tMK3+Li93MCj/VimBfpFmDngw/SyaNGlqnbeGI/V7TkvNv bF2g== MIME-Version: 1.0 X-Received: by 10.180.87.33 with SMTP id u1mr21066902wiz.20.1416116658151; Sat, 15 Nov 2014 21:44:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 15 Nov 2014 21:44:18 -0800 (PST) In-Reply-To: <20141116054141.GA33186@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> <20141116054141.GA33186@troutmask.apl.washington.edu> Date: Sat, 15 Nov 2014 21:44:18 -0800 X-Google-Sender-Auth: I8lLyq0RzT11tlvJ0c7XSvPQeA8 Message-ID: Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem From: Adrian Chadd To: Steve Kargl , Mark Murray , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 05:44:20 -0000 On 15 November 2014 21:41, Steve Kargl wrote: > On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: >> On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: >> > On 11/13/14 19:15, Steve Kargl wrote: >> > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: >> > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: >> > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: >> > >>>> I have a kernel/world from r274273 sources, which is exhibiting a new >> > >>>> issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' >> > >>>> work. I get to the end of shutdown and see for example >> > >>>> >> > >>>> All buffers synced >> > >>>> Uptime: 4h23m15s >> > >>>> >> > >>>> and then the laptop just sits there. It does not power off with >> > >>>> the -p option nor does it reboot with the -r. Has anyone else >> > >>>> seen this behavior? >> > >>>> >> > >>> >> > >>> The problem appears to be related to a recent change in the >> > >>> USB stack. If I have the following drive plugged into a >> > >>> usb port, the above behavior is observed on shutdown. >> > >>> >> > > >> > > Adding >> > > >> > > hw.usb.no_shutdown_wait: 1 >> > > >> > > to /boot/loader.conf appears to work around the 'shutdown -p now' >> > > and 'shutdown -r now' issue. Unfortunately, the bricking of the >> > > laptop is not affected by this sysctl. Once a device is plugged >> > > into a usb, it must remain plugged in. >> > > >> > >> > Hi, >> > >> > Is using this sysctl/tunable a suitable solution for you? >> > >> >> The sysctl is a suitable solution for the shutdown issues. >> It is not suitable solution for the general use of using >> a memory stick to for example quickly transfer files. Once >> the memory stick is plugged into the usb port, it must >> remain there unless one wants to reboot the system. >> >> I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. >> I need to wade through a rather large /var/log/messages >> to see if anything appears unusual. >> > > Well, this has been a waste of a day. The problem is caused > by r273872. This is the recent random device patch. I have no > idea why removing a usb device would cause the system to lock > up other than random is probably trying to harvest some entropy. + des / markm That's a good catch! It's not a waste of a day. Thankyou for digging into it and finding out what introduced the failure. Hopefully between Hans, des and markm a solution can be found. -adrian From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 06:01:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35A1049C; Sun, 16 Nov 2014 06:01:23 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C84FCBF; Sun, 16 Nov 2014 06:01:23 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAG61Ms0033296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Nov 2014 22:01:22 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAG61LPj033295; Sat, 15 Nov 2014 22:01:21 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Nov 2014 22:01:21 -0800 From: Steve Kargl To: Adrian Chadd Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141116060121.GA33248@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> <20141116054141.GA33186@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Hans Petter Selasky , freebsd-current , Dag-Erling Sm?rgrav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 06:01:23 -0000 On Sat, Nov 15, 2014 at 09:44:18PM -0800, Adrian Chadd wrote: > On 15 November 2014 21:41, Steve Kargl wrote: > > On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: > >> On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: > >> > On 11/13/14 19:15, Steve Kargl wrote: > >> > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: > >> > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > >> > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > >> > >>>> I have a kernel/world from r274273 sources, which is exhibiting a new > >> > >>>> issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > >> > >>>> work. I get to the end of shutdown and see for example > >> > >>>> > >> > >>>> All buffers synced > >> > >>>> Uptime: 4h23m15s > >> > >>>> > >> > >>>> and then the laptop just sits there. It does not power off with > >> > >>>> the -p option nor does it reboot with the -r. Has anyone else > >> > >>>> seen this behavior? > >> > >>>> > >> > >>> > >> > >>> The problem appears to be related to a recent change in the > >> > >>> USB stack. If I have the following drive plugged into a > >> > >>> usb port, the above behavior is observed on shutdown. > >> > >>> > >> > > > >> > > Adding > >> > > > >> > > hw.usb.no_shutdown_wait: 1 > >> > > > >> > > to /boot/loader.conf appears to work around the 'shutdown -p now' > >> > > and 'shutdown -r now' issue. Unfortunately, the bricking of the > >> > > laptop is not affected by this sysctl. Once a device is plugged > >> > > into a usb, it must remain plugged in. > >> > > > >> > > >> > Hi, > >> > > >> > Is using this sysctl/tunable a suitable solution for you? > >> > > >> > >> The sysctl is a suitable solution for the shutdown issues. > >> It is not suitable solution for the general use of using > >> a memory stick to for example quickly transfer files. Once > >> the memory stick is plugged into the usb port, it must > >> remain there unless one wants to reboot the system. > >> > >> I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. > >> I need to wade through a rather large /var/log/messages > >> to see if anything appears unusual. > >> > > > > Well, this has been a waste of a day. The problem is caused > > by r273872. This is the recent random device patch. I have no > > idea why removing a usb device would cause the system to lock > > up other than random is probably trying to harvest some entropy. > > + des / markm > > That's a good catch! It's not a waste of a day. Thankyou for digging > into it and finding out what introduced the failure. > > Hopefully between Hans, des and markm a solution can be found. > It is a waste in that I was going to spend the day working on powl(). My next window of time for powl() hacking is probably sometime in mid to late December. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 06:15:28 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F292F785; Sun, 16 Nov 2014 06:15:27 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C3E84D8D; Sun, 16 Nov 2014 06:15:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAG6FQde008545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2014 22:15:26 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAG6FPpp008544; Sat, 15 Nov 2014 22:15:25 -0800 (PST) (envelope-from jmg) Date: Sat, 15 Nov 2014 22:15:25 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141116061525.GG24601@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , freebsd-security@freebsd.org, current@freebsd.org References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> <546744B6.8040504@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546744B6.8040504@yandex.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 15 Nov 2014 22:15:26 -0800 (PST) Cc: freebsd-security@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 06:15:28 -0000 Andrey V. Elsukov wrote this message on Sat, Nov 15, 2014 at 15:19 +0300: > On 15.11.2014 05:42, John-Mark Gurney wrote: > > I just verified that this happens on a clean HEAD @ r274534: > > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > > jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 > > > > No modifications, nothing, and I got the same panic: > > panic: System call sendto returing with kernel FPU ctx leaked > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 > > vpanic() at vpanic+0x189/frame 0xfffffe001de7a930 > > kassert_panic() at kassert_panic+0x139/frame 0xfffffe001de7a9a0 > > amd64_syscall() at amd64_syscall+0x616/frame 0xfffffe001de7aab0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 > > --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffffffee588, rbp = 0x7ffffffee5c0 --- > > KDB: enter: panic > > > > So, it's clearly not my patch that is causing the issue... > > > > Andrey, can you verify that you do not receive the same panic w/o my > > patches? > > I tried 11.0-CURRENT r274549 with and without patches. > Without patches all works as expected. System encrypts and forwards > traffic with and without aesni module. > > With patches software rijndaelEncrypt also works. But when I load > aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors > counter starts grow. And I see messages about wrong source route > attempts from random addresses. Ok, I was able to reproduce the bug, and found that my optimization for single mbuf packets was broken... I've attached a new patch that has the fix... This patch also has added a lock around the aesni fpu context setting to deal w/ the issue that I had... Let me know how things are w/ this new patch. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 06:18:35 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7382A7B; Sun, 16 Nov 2014 06:18:35 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C1E3E02; Sun, 16 Nov 2014 06:18:35 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id z12so4247188wgg.1 for ; Sat, 15 Nov 2014 22:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=4EylnWg1bafbBrLbinzbxK5TwKJilSUa48ZcBYS5qFU=; b=fqvgQXhG2QoMckqV7bjNWahu3cVyBP5NLoaYHUD2CokVCVjsU2rZMukRFu/xdJPD6n VEwc+x8pB36y1GI9zwG+sM9OMQCtoaIDJR/LDMGDg2/1FexITMa3nxZ9QtJ5UStuTVyS +DtZu36Npnbn93LvN0iRgmb94JBtJsI8zMaL842dMgN0zrrLrvpWhyQ2sJu9vsXYmlvF uguW3OAQ8u/GZws+pLfoyczfTCOewcEUllFCpPmvU0rryj7K3fa47tTuoGTo0PZIlHXp fnkV5qgcJsqYLhz59brVe2+xjabPPhSb4Q3KgzpymGYCQxldLmZsmtNoFX9r7ETPZSqv 0s5Q== MIME-Version: 1.0 X-Received: by 10.180.83.98 with SMTP id p2mr21169288wiy.20.1416118713818; Sat, 15 Nov 2014 22:18:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 15 Nov 2014 22:18:32 -0800 (PST) In-Reply-To: <20141116061525.GG24601@funkthat.com> References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> <546744B6.8040504@yandex.ru> <20141116061525.GG24601@funkthat.com> Date: Sat, 15 Nov 2014 22:18:32 -0800 X-Google-Sender-Auth: 52YUPCelGkWABckxG2XJNLQqXuY Message-ID: Subject: Re: CFR: AES-GCM and OpenCrypto work review From: Adrian Chadd To: "Andrey V. Elsukov" , freebsd-security@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 06:18:35 -0000 ... no attachment? -adrian On 15 November 2014 22:15, John-Mark Gurney wrote: > Andrey V. Elsukov wrote this message on Sat, Nov 15, 2014 at 15:19 +0300: >> On 15.11.2014 05:42, John-Mark Gurney wrote: >> > I just verified that this happens on a clean HEAD @ r274534: >> > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 >> > jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 >> > >> > No modifications, nothing, and I got the same panic: >> > panic: System call sendto returing with kernel FPU ctx leaked >> > cpuid = 0 >> > KDB: stack backtrace: >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 >> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 >> > vpanic() at vpanic+0x189/frame 0xfffffe001de7a930 >> > kassert_panic() at kassert_panic+0x139/frame 0xfffffe001de7a9a0 >> > amd64_syscall() at amd64_syscall+0x616/frame 0xfffffe001de7aab0 >> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 >> > --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffffffee588, rbp = 0x7ffffffee5c0 --- >> > KDB: enter: panic >> > >> > So, it's clearly not my patch that is causing the issue... >> > >> > Andrey, can you verify that you do not receive the same panic w/o my >> > patches? >> >> I tried 11.0-CURRENT r274549 with and without patches. >> Without patches all works as expected. System encrypts and forwards >> traffic with and without aesni module. >> >> With patches software rijndaelEncrypt also works. But when I load >> aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors >> counter starts grow. And I see messages about wrong source route >> attempts from random addresses. > > Ok, I was able to reproduce the bug, and found that my optimization > for single mbuf packets was broken... I've attached a new patch > that has the fix... > > This patch also has added a lock around the aesni fpu context setting > to deal w/ the issue that I had... > > Let me know how things are w/ this new patch. > > Thanks. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 06:20:20 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ADA4B88; Sun, 16 Nov 2014 06:20:20 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 11BE4E0F; Sun, 16 Nov 2014 06:20:19 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAG6KJNZ008611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2014 22:20:19 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAG6KJHt008610; Sat, 15 Nov 2014 22:20:19 -0800 (PST) (envelope-from jmg) Date: Sat, 15 Nov 2014 22:20:18 -0800 From: John-Mark Gurney To: Adrian Chadd Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141116062018.GH24601@funkthat.com> Mail-Followup-To: Adrian Chadd , "Andrey V. Elsukov" , freebsd-security@freebsd.org, "current@freebsd.org" References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> <546744B6.8040504@yandex.ru> <20141116061525.GG24601@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 15 Nov 2014 22:20:19 -0800 (PST) Cc: freebsd-security@freebsd.org, "Andrey V. Elsukov" , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 06:20:20 -0000 Adrian Chadd wrote this message on Sat, Nov 15, 2014 at 22:18 -0800: > ... no attachment? Thanks, I put it on the website since I realized it was 155k and a bit large to attach... it's at: https://www.funkthat.com/~jmg/patches/aes.ipsec.6.patch > On 15 November 2014 22:15, John-Mark Gurney wrote: > > Andrey V. Elsukov wrote this message on Sat, Nov 15, 2014 at 15:19 +0300: > >> On 15.11.2014 05:42, John-Mark Gurney wrote: > >> > I just verified that this happens on a clean HEAD @ r274534: > >> > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > >> > jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 > >> > > >> > No modifications, nothing, and I got the same panic: > >> > panic: System call sendto returing with kernel FPU ctx leaked > >> > cpuid = 0 > >> > KDB: stack backtrace: > >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 > >> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 > >> > vpanic() at vpanic+0x189/frame 0xfffffe001de7a930 > >> > kassert_panic() at kassert_panic+0x139/frame 0xfffffe001de7a9a0 > >> > amd64_syscall() at amd64_syscall+0x616/frame 0xfffffe001de7aab0 > >> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 > >> > --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffffffee588, rbp = 0x7ffffffee5c0 --- > >> > KDB: enter: panic > >> > > >> > So, it's clearly not my patch that is causing the issue... > >> > > >> > Andrey, can you verify that you do not receive the same panic w/o my > >> > patches? > >> > >> I tried 11.0-CURRENT r274549 with and without patches. > >> Without patches all works as expected. System encrypts and forwards > >> traffic with and without aesni module. > >> > >> With patches software rijndaelEncrypt also works. But when I load > >> aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors > >> counter starts grow. And I see messages about wrong source route > >> attempts from random addresses. > > > > Ok, I was able to reproduce the bug, and found that my optimization > > for single mbuf packets was broken... I've attached a new patch > > that has the fix... > > > > This patch also has added a lock around the aesni fpu context setting > > to deal w/ the issue that I had... > > > > Let me know how things are w/ this new patch. > > > > Thanks. > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." > > _______________________________________________ > > 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" > _______________________________________________ > 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" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 12:50:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EEF14DF3 for ; Sun, 16 Nov 2014 12:50:03 +0000 (UTC) Received: from mail-yh0-f45.google.com (mail-yh0-f45.google.com [209.85.213.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B53192F1 for ; Sun, 16 Nov 2014 12:50:03 +0000 (UTC) Received: by mail-yh0-f45.google.com with SMTP id f10so3258345yha.18 for ; Sun, 16 Nov 2014 04:49:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9v0gvNoAk/NZjQeAEp6QBleSmhhybcGT5Jf/49GJEqo=; b=j2/VeA+/UVaUJOb/GYt0cX5zd5xRLVPCtqW5v1xe8y9j86JSgqMTzarRIo+mwGrG0H oOApEf+rLv79qawp1cpp/5DztNcci18fKFukshBsspOIAOy1n0m9jUOF+UHut7t2YW1m B9RCCVnQa0lg2IIg99r5JdrmQ4PqI1q7cw5lK9sdKiIuSvx/+RnNE6LSAi4BLJe3F5sX biNLJl/3MxQ/ZMaac0rVN1P8b3EfOGvQBq2vkVfWUmOOqmMht0qR4Ero+IJ3C/7yVo4n d7HSTfoA55qukEnyLsDSGyUR9zHT7isBD0Lo36J6+E9tJAgSqxICSeHScjTGfyfqqfjA 3qfg== X-Gm-Message-State: ALoCoQkxJjsFUOZ8xlrBe/ipwL8vG5hhDEjlAPk84grrkNmkP8sND7qw4YAD5RSTlHBVQqx0uE6P MIME-Version: 1.0 X-Received: by 10.236.32.168 with SMTP id o28mr526601yha.168.1416138839142; Sun, 16 Nov 2014 03:53:59 -0800 (PST) Received: by 10.170.46.203 with HTTP; Sun, 16 Nov 2014 03:53:59 -0800 (PST) X-Originating-IP: [62.165.255.179] In-Reply-To: <5467CEE2.908@banym.de> References: <5467CEE2.908@banym.de> Date: Sun, 16 Nov 2014 12:53:59 +0100 Message-ID: Subject: Re: Changing makeoptions UKBD_DFLT_KEYMAP leads to kernel build fail From: Oliver Pinter To: Dominik Zajac Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 12:50:04 -0000 On 11/15/14, Dominik Zajac wrote: > Hi, > > I am trying to change the default keymap for my keyboard therefore I > added the following options to my kernel configuration which leads to > the error bellow. > > Added options: > > options KBD_INSTALL_CDEV > > options UKBD_DFLT_KEYMAP > > makeoptions UKBD_DFLT_KEYMAP=de.iso > > > I tried it with this, too: > > makeoptions UKBD_DFLT_KEYMAP=german.iso > > > Both leads to the following problem: > > > /usr/src/sys/dev/usb/input/ukbd.c:1209:18: error: use of undeclared > identifier 'key_map' > > sc->sc_keymap = key_map; > > ^ > > /usr/src/sys/dev/usb/input/ukbd.c:1210:18: error: use of undeclared > identifier 'accent_map' > > sc->sc_accmap = accent_map; > > ^ > > 2 errors generated. > > *** Error code 1 Hi! See this ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 and the related bugs. > > Is there a dynamic way to change the keyboard layout at boot time to typ > the zfs passphrase on my default keyboardlayout? > > Regards, > > Dominik > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 17:51:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8926B967; Sun, 16 Nov 2014 17:51:04 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F7C0285; Sun, 16 Nov 2014 17:51:04 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAGHp38w035683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Nov 2014 09:51:03 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAGHp2k1035682; Sun, 16 Nov 2014 09:51:02 -0800 (PST) (envelope-from sgk) Date: Sun, 16 Nov 2014 09:51:02 -0800 From: Steve Kargl To: Adrian Chadd Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141116175102.GA35649@troutmask.apl.washington.edu> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> <20141116054141.GA33186@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Hans Petter Selasky , freebsd-current , Dag-Erling Sm?rgrav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 17:51:04 -0000 On Sat, Nov 15, 2014 at 09:44:18PM -0800, Adrian Chadd wrote: > On 15 November 2014 21:41, Steve Kargl wrote: > > On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: > >> On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: > >> > On 11/13/14 19:15, Steve Kargl wrote: > >> > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: > >> > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: > >> > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: > >> > >>>> I have a kernel/world from r274273 sources, which is exhibiting a new > >> > >>>> issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' > >> > >>>> work. I get to the end of shutdown and see for example > >> > >>>> > >> > >>>> All buffers synced > >> > >>>> Uptime: 4h23m15s > >> > >>>> > >> > >>>> and then the laptop just sits there. It does not power off with > >> > >>>> the -p option nor does it reboot with the -r. Has anyone else > >> > >>>> seen this behavior? > >> > >>>> > >> > >>> > >> > >>> The problem appears to be related to a recent change in the > >> > >>> USB stack. If I have the following drive plugged into a > >> > >>> usb port, the above behavior is observed on shutdown. > >> > >>> > >> > > > >> > > Adding > >> > > > >> > > hw.usb.no_shutdown_wait: 1 > >> > > > >> > > to /boot/loader.conf appears to work around the 'shutdown -p now' > >> > > and 'shutdown -r now' issue. Unfortunately, the bricking of the > >> > > laptop is not affected by this sysctl. Once a device is plugged > >> > > into a usb, it must remain plugged in. > >> > > > >> > > >> > Hi, > >> > > >> > Is using this sysctl/tunable a suitable solution for you? > >> > > >> > >> The sysctl is a suitable solution for the shutdown issues. > >> It is not suitable solution for the general use of using > >> a memory stick to for example quickly transfer files. Once > >> the memory stick is plugged into the usb port, it must > >> remain there unless one wants to reboot the system. > >> > >> I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. > >> I need to wade through a rather large /var/log/messages > >> to see if anything appears unusual. > >> > > > > Well, this has been a waste of a day. The problem is caused > > by r273872. This is the recent random device patch. I have no > > idea why removing a usb device would cause the system to lock > > up other than random is probably trying to harvest some entropy. > > + des / markm > > That's a good catch! It's not a waste of a day. Thankyou for digging > into it and finding out what introduced the failure. > > Hopefully between Hans, des and markm a solution can be found. > Shooting into the dark. I added 'options RANDOM_DEBUG' to my kernel. Plugging in a USB device shows kernel: ugen6.2: at usbus6 kernel: umass0: on usbus6 kernel: random: device_attach(): feeding 4 bit(s) of entropy from umass0 kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 kernel: da0: < 0.00> Removable Direct Access SCSI-2 device kernel: da0: Serial Number 08102201c42413 kernel: da0: 40.000MB/s transfers kernel: da0: 963MB (1974271 512 byte sectors: 64H 32S/T 963C) kernel: da0: quirks=0x2 in /var/log/messages. Now, when I immediately pull the device from the USB port, I get kernel: ugen6.2: at usbus6 (disconnected) kernel: umass0: at uhub6, port 1, addr 2 (disconnected) kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 kernel: da0: < 0.00> s/n 08102201c42413 detached followed by a bricked laptop, which requires a depression of the power button. Is there a 'random: device_detach():' missing between the 'umass0' and 'da0' messages in the last 4 lines. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 18:07:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD632CD1 for ; Sun, 16 Nov 2014 18:07:34 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DAD53B9 for ; Sun, 16 Nov 2014 18:07:34 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAGI7Y3P035851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 16 Nov 2014 10:07:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAGI7YLD035850 for freebsd-current@freebsd.org; Sun, 16 Nov 2014 10:07:34 -0800 (PST) (envelope-from sgk) Date: Sun, 16 Nov 2014 10:07:33 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: init(8) diagnostics? Message-ID: <20141116180733.GA35841@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 18:07:34 -0000 In init(8), one finds under DIAGNOSISTICS "some processes would not die; ps axl advised." So, just how is one to actually run 'ps axl advised' as the message appears as init(8) is killing off the system? -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 18:17:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F07D48D; Sun, 16 Nov 2014 18:17:29 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00EA06A7; Sun, 16 Nov 2014 18:17:29 +0000 (UTC) Received: from [2001:470:9174:1:c55a:8f0e:b91b:d061] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xq4O5-000DwK-MC; Sun, 16 Nov 2014 18:17:27 +0000 Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=us-ascii From: Mark R V Murray In-Reply-To: <20141116175102.GA35649@troutmask.apl.washington.edu> Date: Sun, 16 Nov 2014 18:17:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> <20141116054141.GA33186@troutmask.apl.washington.edu> <20141116175102.GA35649@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Dag-Erling Sm?rgrav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 18:17:29 -0000 > On 16 Nov 2014, at 17:51, Steve Kargl = wrote: >=20 > Is there a 'random: device_detach():' missing between the 'umass0' > and 'da0' messages in the last 4 lines. No. At attach time, the RNG grabs some probe entropy. At detach time it = does nothing. M --=20 Mark R V Murray From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 18:21:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42889629; Sun, 16 Nov 2014 18:21:15 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E50A7AB; Sun, 16 Nov 2014 18:21:14 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xq4Rl-000Plh-53; Sun, 16 Nov 2014 18:21:13 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAGILBpG001373; Sun, 16 Nov 2014 11:21:11 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+CIyZKbWwC4sQN5AubTJsJ X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem From: Ian Lepore To: Mark R V Murray In-Reply-To: References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> <20141116054141.GA33186@troutmask.apl.washington.edu> <20141116175102.GA35649@troutmask.apl.washington.edu> Content-Type: text/plain; charset="us-ascii" Date: Sun, 16 Nov 2014 11:21:10 -0700 Message-ID: <1416162070.4781.186.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Dag-Erling Sm?rgrav , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 18:21:15 -0000 On Sun, 2014-11-16 at 18:17 +0000, Mark R V Murray wrote: > > On 16 Nov 2014, at 17:51, Steve Kargl wrote: > > > > Is there a 'random: device_detach():' missing between the 'umass0' > > and 'da0' messages in the last 4 lines. > > No. At attach time, the RNG grabs some probe entropy. At detach time it does nothing. > > M And yet... Steve has gathered evidence that the system bricks when a device is detached with the new entropy-gathering code and doesn't do so prior to that code. What else is the new code doing around detach time? -- Ian From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 18:22:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D301B738 for ; Sun, 16 Nov 2014 18:22:31 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id ACA017C1 for ; Sun, 16 Nov 2014 18:22:31 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 8974C70C63 for ; Sun, 16 Nov 2014 18:22:30 +0000 (UTC) Message-ID: <5468EB84.2070309@freebsd.org> Date: Sun, 16 Nov 2014 13:23:00 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: init(8) diagnostics? References: <20141116180733.GA35841@troutmask.apl.washington.edu> In-Reply-To: <20141116180733.GA35841@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qmTxPiTfECBfpSJK2UbQImraARKIwnkFF" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 18:22:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qmTxPiTfECBfpSJK2UbQImraARKIwnkFF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-11-16 13:07, Steve Kargl wrote: > In init(8), one finds under DIAGNOSISTICS >=20 > "some processes would not die; ps axl advised." >=20 > So, just how is one to actually run 'ps axl advised' as > the message appears as init(8) is killing off the system? >=20 In this case 'advised' is not a literal part of the command, but rather, it is suggesting that running 'ps axl' will show which process(es) are still running, and those would be the ones that would not die. When this message comes up, how far through the shutdown are you? Does it stall there for a while? or continue quickly? --=20 Allan Jude --qmTxPiTfECBfpSJK2UbQImraARKIwnkFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUaOuEAAoJEJrBFpNRJZKfuD0P/imfhTLKmkK+Qn3jyM8Cc8ES 3LVtKZzsFHoAyBbTmbwYU9qVnnCfJhQFnYN6O84GntNPqEm4L7s6Fab6supvgpfF /gT8cKbFu4k7bQCYf14ckAvTSO014W42MxDJyy6l3wv5auKXhwefJ1eS0PCp/YZL tJ9QvXS+fD9qwzAQx+JyjBL20oOqLAiNgUxfLQj8dfzI7sNbU9DLj10s8b4EoSRi KY8sDQcoBgfU9w2aOBFv1PSxXqREPiJgkAJmNQGVr4NKUhPviDe+asDLLgb4KysM N8kjmVnU22hqxzgXmYeTJPpSNITWtIMO4v0NRrX8nlH2DihUUFu1kozdGdyDtYV+ SBwxANZnbYhlE8ipf431+Z2RAB3qnBOUojdHSwpCvNriXQygPCmQ8yXM0/A/1yF4 X6gJFx59dJC7Od0P8f3Gn4JChzRtv9XoJzdv26CZQUNjoCSloIaAHGLSbpVDzM23 Wuzl5HlmBQ5ebGZkR4KxvL32lbYL1qdmT3OaCIJ7a9Tk682rnNBWZZxoR4/Us5fy 7lYkuIClY13tdx73FUyFzoyYtCl6VW1hC/+5ipVCE5YE+5JgfGpvCJzPh3CkYql+ 190vxZuMwgwZgdXlfA8wuBj92Su65PsYXRHD+D8jvJY3z9/ZBLj/FpY/OgiwrWNl 1jbG947zX8GoyjIT1ybg =5zEI -----END PGP SIGNATURE----- --qmTxPiTfECBfpSJK2UbQImraARKIwnkFF-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 18:24:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB79684C; Sun, 16 Nov 2014 18:24:02 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C0A17CC; Sun, 16 Nov 2014 18:24:02 +0000 (UTC) Received: from [2001:470:9174:1:c55a:8f0e:b91b:d061] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xq4US-000Dx0-K6; Sun, 16 Nov 2014 18:24:01 +0000 Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <1416162070.4781.186.camel@revolution.hippie.lan> Date: Sun, 16 Nov 2014 18:23:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> <20141116054141.GA33186@troutmask.apl.washington.edu> <20141116175102.GA35649@troutmask.apl.washington.edu> <1416162070.4781.186.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Dag-Erling Sm?rgrav , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 18:24:02 -0000 > On 16 Nov 2014, at 18:21, Ian Lepore wrote: >=20 > On Sun, 2014-11-16 at 18:17 +0000, Mark R V Murray wrote: >>> On 16 Nov 2014, at 17:51, Steve Kargl = wrote: >>>=20 >>> Is there a 'random: device_detach():' missing between the 'umass0' >>> and 'da0' messages in the last 4 lines. >>=20 >> No. At attach time, the RNG grabs some probe entropy. At detach time = it does nothing. >>=20 >> M >=20 > And yet... Steve has gathered evidence that the system bricks when a > device is detached with the new entropy-gathering code and doesn't do = so > prior to that code. What else is the new code doing around detach = time? Nothing, except possibly harvesting interrupt entropy. I=E2=80=99ll = promise to be astonished if this is other-than-harmless. I=E2=80=99d be more suspicious of the harvester thread, but I still = can=E2=80=99t see how its hurting :-( M --=20 Mark R V Murray From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 18:32:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11A26DF7; Sun, 16 Nov 2014 18:32:01 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEAE588B; Sun, 16 Nov 2014 18:32:00 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xq4cB-0004WD-Cn; Sun, 16 Nov 2014 18:31:59 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAGIVwhN001401; Sun, 16 Nov 2014 11:31:58 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+9ndMg+1VaK20PX+H91Qch X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem From: Ian Lepore To: Mark R V Murray In-Reply-To: References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> <20141116054141.GA33186@troutmask.apl.washington.edu> <20141116175102.GA35649@troutmask.apl.washington.edu> <1416162070.4781.186.camel@revolution.hippie.lan> Content-Type: text/plain; charset="iso-8859-7" Date: Sun, 16 Nov 2014 11:31:58 -0700 Message-ID: <1416162718.4781.192.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sAGIVwhN001401 Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Steve Kargl , Dag-Erling Sm?rgrav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 18:32:01 -0000 On Sun, 2014-11-16 at 18:23 +0000, Mark R V Murray wrote: > > On 16 Nov 2014, at 18:21, Ian Lepore wrote: > >=20 > > On Sun, 2014-11-16 at 18:17 +0000, Mark R V Murray wrote: > >>> On 16 Nov 2014, at 17:51, Steve Kargl wrote: > >>>=20 > >>> Is there a 'random: device_detach():' missing between the 'umass0' > >>> and 'da0' messages in the last 4 lines. > >>=20 > >> No. At attach time, the RNG grabs some probe entropy. At detach time= it does nothing. > >>=20 > >> M > >=20 > > And yet... Steve has gathered evidence that the system bricks when a > > device is detached with the new entropy-gathering code and doesn't do= so > > prior to that code. What else is the new code doing around detach ti= me? >=20 > Nothing, except possibly harvesting interrupt entropy. I=A2ll promise t= o be > astonished if this is other-than-harmless. >=20 > I=A2d be more suspicious of the harvester thread, but I still can=A2t s= ee how > its hurting :-( >=20 > M The point I'm trying to make here is that you trimmed away the important part of the prior messages and replied only to the part where Steve's debugging efforts were somewhat speculating. The non-speculative part was where he bisected the failure to an exact commit: > > > The problem is caused > > > by r273872. This is the recent random device patch. I have no > > > idea why removing a usb device would cause the system to lock > > > up other than random is probably trying to harvest some entropy. -- Ian From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 18:34:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1565F4A; Sun, 16 Nov 2014 18:34:47 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 606C78A3; Sun, 16 Nov 2014 18:34:47 +0000 (UTC) Received: from [2001:470:9174:1:1854:2549:19e3:cc92] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xq4ep-000Dy9-7d; Sun, 16 Nov 2014 18:34:43 +0000 Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <1416162718.4781.192.camel@revolution.hippie.lan> Date: Sun, 16 Nov 2014 18:34:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> References: <20141112224212.GA14013@troutmask.apl.washington.edu> <20141113172533.GA18690@troutmask.apl.washington.edu> <20141113180332.GA18990@troutmask.apl.washington.edu> <20141113181515.GA19117@troutmask.apl.washington.edu> <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> <20141116054141.GA33186@troutmask.apl.washington.edu> <20141116175102.GA35649@troutmask.apl.washington.edu> <1416162070.4781.186.camel@revolution.hippie.lan> <1416162718.4781.192.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Steve Kargl , Dag-Erling Sm?rgrav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 18:34:47 -0000 > On 16 Nov 2014, at 18:31, Ian Lepore wrote: >=20 > The point I'm trying to make here is that you trimmed away the = important > part of the prior messages and replied only to the part where Steve's > debugging efforts were somewhat speculating. The non-speculative part > was where he bisected the failure to an exact commit: >=20 >>>> The problem is caused >>>> by r273872. This is the recent random device patch. I have no >>>> idea why removing a usb device would cause the system to lock >>>> up other than random is probably trying to harvest some entropy. I=E2=80=99m sorry my commit caused the problem. I=E2=80=99m also trying to find out why, but I don=E2=80=99t know enough = about USB or mass-storage devices to know why, so this may take me a while. In the meanwhile, I=E2=80=99ll try to help by pointing out things I do know. M --=20 Mark R V Murray From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 18:37:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54A6E29A; Sun, 16 Nov 2014 18:37:54 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 196CA8C5; Sun, 16 Nov 2014 18:37:54 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAGIbrFH036094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Nov 2014 10:37:53 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAGIbrwo036093; Sun, 16 Nov 2014 10:37:53 -0800 (PST) (envelope-from sgk) Date: Sun, 16 Nov 2014 10:37:53 -0800 From: Steve Kargl To: Allan Jude Subject: Re: init(8) diagnostics? Message-ID: <20141116183753.GA36021@troutmask.apl.washington.edu> References: <20141116180733.GA35841@troutmask.apl.washington.edu> <5468EB84.2070309@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5468EB84.2070309@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 18:37:54 -0000 On Sun, Nov 16, 2014 at 01:23:00PM -0500, Allan Jude wrote: > On 2014-11-16 13:07, Steve Kargl wrote: > > In init(8), one finds under DIAGNOSISTICS > > > > "some processes would not die; ps axl advised." > > > > So, just how is one to actually run 'ps axl advised' as > > the message appears as init(8) is killing off the system? > > > > In this case 'advised' is not a literal part of the command, but rather, > it is suggesting that running 'ps axl' will show which process(es) are > still running, and those would be the ones that would not die. > > When this message comes up, how far through the shutdown are you? Does > it stall there for a while? or continue quickly? > Yes, I know that the message means that one should run 'ps axl'. The system is well beyond any hope of interactive commands at the console. It appears right after init(8) stops syslogd and before the 'stopping vnlru ... done.' message. I was hoping that I could put the command in /etc/shutdown.rc, but reading that script did not provide the insight needed to automatically run the command. It is somewhat surprising that init(8) does not give the PID(s) of the offending process(es). -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 18:51:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E497B60; Sun, 16 Nov 2014 18:51:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5ACB3A35; Sun, 16 Nov 2014 18:51:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAGIpf2a036160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Nov 2014 10:51:41 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAGIpfZX036159; Sun, 16 Nov 2014 10:51:41 -0800 (PST) (envelope-from sgk) Date: Sun, 16 Nov 2014 10:51:41 -0800 From: Steve Kargl To: Mark R V Murray Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141116185141.GB36021@troutmask.apl.washington.edu> References: <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> <20141116054141.GA33186@troutmask.apl.washington.edu> <20141116175102.GA35649@troutmask.apl.washington.edu> <1416162070.4781.186.camel@revolution.hippie.lan> <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Dag-Erling Sm?rgrav , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 18:51:48 -0000 On Sun, Nov 16, 2014 at 06:34:42PM +0000, Mark R V Murray wrote: > > > On 16 Nov 2014, at 18:31, Ian Lepore wrote: > > > > The point I'm trying to make here is that you trimmed away the important > > part of the prior messages and replied only to the part where Steve's > > debugging efforts were somewhat speculating. The non-speculative part > > was where he bisected the failure to an exact commit: > > > >>>> The problem is caused > >>>> by r273872. This is the recent random device patch. I have no > >>>> idea why removing a usb device would cause the system to lock > >>>> up other than random is probably trying to harvest some entropy. > > I?m sorry my commit caused the problem. > Nothing to be sorry about. This is -current afterall. > I?m also trying to find out why, but I don?t know enough about USB or > mass-storage devices to know why, so this may take me a while. In the > meanwhile, I?ll try to help by pointing out things I do know. Yes, I did the bisection to find that r273872 exposes the problem. What I don't know is if this is hardware specific to a Dell Latitude D530 laptop, USB specific, or some weird interaction between the random and USB. What I also find odd is that I seem to be the only person seeing this behavior when it is trivial for me to reproduce: boot laptop, plug in usb device, wait usb recognizes the device, then unplug the device. If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 18:55:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21F7AD40; Sun, 16 Nov 2014 18:55:57 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D703FA69; Sun, 16 Nov 2014 18:55:56 +0000 (UTC) Received: from [2001:470:9174:1:1854:2549:19e3:cc92] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xq4zL-000Dzo-0L; Sun, 16 Nov 2014 18:55:55 +0000 Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <20141116185141.GB36021@troutmask.apl.washington.edu> Date: Sun, 16 Nov 2014 18:55:53 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> References: <546515BF.6030508@selasky.org> <20141113212206.GA20802@troutmask.apl.washington.edu> <20141116054141.GA33186@troutmask.apl.washington.edu> <20141116175102.GA35649@troutmask.apl.washington.edu> <1416162070.4781.186.camel@revolution.hippie.lan> <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Dag-Erling Sm?rgrav , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 18:55:57 -0000 > On 16 Nov 2014, at 18:51, Steve Kargl = wrote: >=20 >>=20 >> I?m sorry my commit caused the problem. >>=20 >=20 > Nothing to be sorry about. This is -current after all. Thanks :-) >> I?m also trying to find out why, but I don?t know enough about USB or >> mass-storage devices to know why, so this may take me a while. In the >> meanwhile, I?ll try to help by pointing out things I do know. >=20 > Yes, I did the bisection to find that r273872 exposes the problem. > What I don't know is if this is hardware specific to a Dell Latitude > D530 laptop, USB specific, or some weird interaction between the > random and USB. >=20 > What I also find odd is that I seem to be the only person seeing > this behavior when it is trivial for me to reproduce: boot laptop, > plug in usb device, wait usb recognizes the device, then unplug=20 > the device. Strange for me too. I=E2=80=99m not exactly being bombarded with bug = reports. > If you have not read the entire thread, once the laptop keyboard and > video output lock up, I can ssh into the laptop. If I run usbconfig, > it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* = devices > have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? M --=20 Mark R V Murray From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 19:03:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64EAB22D; Sun, 16 Nov 2014 19:03:45 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B096B25; Sun, 16 Nov 2014 19:03:45 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAGJ3iVi036234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Nov 2014 11:03:44 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAGJ3iJQ036233; Sun, 16 Nov 2014 11:03:44 -0800 (PST) (envelope-from sgk) Date: Sun, 16 Nov 2014 11:03:44 -0800 From: Steve Kargl To: Mark R V Murray Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141116190344.GC36021@troutmask.apl.washington.edu> References: <20141116054141.GA33186@troutmask.apl.washington.edu> <20141116175102.GA35649@troutmask.apl.washington.edu> <1416162070.4781.186.camel@revolution.hippie.lan> <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Dag-Erling Sm?rgrav , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 19:03:45 -0000 On Sun, Nov 16, 2014 at 06:55:53PM +0000, Mark R V Murray wrote: > > > On 16 Nov 2014, at 18:51, Steve Kargl wrote: > > > > If you have not read the entire thread, once the laptop keyboard and > > video output lock up, I can ssh into the laptop. If I run usbconfig, > > it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices > > have not been destroyed. > > Weirder and weirder :-(. > > Something with SX locks? Hmm. I do use those for attach and detach for > RNG sources. Could it be that that stick of yours is somehow getting > involved in the RNG source locks? > It's not limited to a single usb device. Plugging in/Unplugging a logitech mouse dongle, the memstick, a Western Digital MY Passport external usb hard drive, all lead to the locked keyboard and video. I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the mount of output is mind numbing. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 19:16:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 308AD96C; Sun, 16 Nov 2014 19:16:18 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE87BC2B; Sun, 16 Nov 2014 19:16:17 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id ADB8A1FE022; Sun, 16 Nov 2014 20:16:14 +0100 (CET) Message-ID: <5468F814.6010702@selasky.org> Date: Sun, 16 Nov 2014 20:16:36 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Steve Kargl , Mark R V Murray Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem References: <20141116054141.GA33186@troutmask.apl.washington.edu> <20141116175102.GA35649@troutmask.apl.washington.edu> <1416162070.4781.186.camel@revolution.hippie.lan> <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> <20141116190344.GC36021@troutmask.apl.washington.edu> In-Reply-To: <20141116190344.GC36021@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current , Ian Lepore , Dag-Erling Sm?rgrav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 19:16:18 -0000 On 11/16/14 20:03, Steve Kargl wrote: > On Sun, Nov 16, 2014 at 06:55:53PM +0000, Mark R V Murray wrote: >> >>> On 16 Nov 2014, at 18:51, Steve Kargl wrote: >>> >>> If you have not read the entire thread, once the laptop keyboard and >>> video output lock up, I can ssh into the laptop. If I run usbconfig, >>> it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices >>> have not been destroyed. >> >> Weirder and weirder :-(. >> >> Something with SX locks? Hmm. I do use those for attach and detach for >> RNG sources. Could it be that that stick of yours is somehow getting >> involved in the RNG source locks? >> > > It's not limited to a single usb device. Plugging in/Unplugging > a logitech mouse dongle, the memstick, a Western Digital MY Passport > external usb hard drive, all lead to the locked keyboard and video. > > I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the > mount of output is mind numbing. > Hi, Can you enter kgdb when the usbconfig is froozen, and backtrace all kernel threads. You should see exactly what locks are the problem. Maybe some lock didn't get properly unlocked! Thank you! --HPS From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 19:30:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD43FF0C; Sun, 16 Nov 2014 19:30:00 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B3DAD63; Sun, 16 Nov 2014 19:30:00 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAGJTxBq036379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Nov 2014 11:29:59 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAGJTxJS036378; Sun, 16 Nov 2014 11:29:59 -0800 (PST) (envelope-from sgk) Date: Sun, 16 Nov 2014 11:29:59 -0800 From: Steve Kargl To: Hans Petter Selasky Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141116192959.GB36339@troutmask.apl.washington.edu> References: <20141116175102.GA35649@troutmask.apl.washington.edu> <1416162070.4781.186.camel@revolution.hippie.lan> <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> <20141116190344.GC36021@troutmask.apl.washington.edu> <5468F814.6010702@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5468F814.6010702@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Adrian Chadd , freebsd-current , Ian Lepore , Dag-Erling Sm?rgrav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 19:30:00 -0000 On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote: > On 11/16/14 20:03, Steve Kargl wrote: > > On Sun, Nov 16, 2014 at 06:55:53PM +0000, Mark R V Murray wrote: > >> > >>> On 16 Nov 2014, at 18:51, Steve Kargl wrote: > >>> > >>> If you have not read the entire thread, once the laptop keyboard and > >>> video output lock up, I can ssh into the laptop. If I run usbconfig, > >>> it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices > >>> have not been destroyed. > >> > >> Weirder and weirder :-(. > >> > >> Something with SX locks? Hmm. I do use those for attach and detach for > >> RNG sources. Could it be that that stick of yours is somehow getting > >> involved in the RNG source locks? > >> > > > > It's not limited to a single usb device. Plugging in/Unplugging > > a logitech mouse dongle, the memstick, a Western Digital MY Passport > > external usb hard drive, all lead to the locked keyboard and video. > > > > I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the > > mount of output is mind numbing. > > > > > Can you enter kgdb when the usbconfig is froozen, and backtrace all > kernel threads. You should see exactly what locks are the problem. > > Maybe some lock didn't get properly unlocked! > I haven't tried kgdb. I did try to attach gdb to the usbconfig process via its pid, but gdb dumped core. I haven't looked at locks in kgdb, what command or commands should I try. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 19:32:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4055370; Sun, 16 Nov 2014 19:32:55 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E908E16; Sun, 16 Nov 2014 19:32:55 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 947541FE022; Sun, 16 Nov 2014 20:32:53 +0100 (CET) Message-ID: <5468FBFB.1090208@selasky.org> Date: Sun, 16 Nov 2014 20:33:15 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Steve Kargl Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem References: <20141116175102.GA35649@troutmask.apl.washington.edu> <1416162070.4781.186.camel@revolution.hippie.lan> <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> <20141116190344.GC36021@troutmask.apl.washington.edu> <5468F814.6010702@selasky.org> <20141116192959.GB36339@troutmask.apl.washington.edu> In-Reply-To: <20141116192959.GB36339@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current , Dag-Erling Sm?rgrav , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 19:32:55 -0000 On 11/16/14 20:29, Steve Kargl wrote: > On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote: >> On 11/16/14 20:03, Steve Kargl wrote: >>> On Sun, Nov 16, 2014 at 06:55:53PM +0000, Mark R V Murray wrote: >>>> >>>>> On 16 Nov 2014, at 18:51, Steve Kargl wrote: >>>>> >>>>> If you have not read the entire thread, once the laptop keyboard and >>>>> video output lock up, I can ssh into the laptop. If I run usbconfig, >>>>> it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices >>>>> have not been destroyed. >>>> >>>> Weirder and weirder :-(. >>>> >>>> Something with SX locks? Hmm. I do use those for attach and detach for >>>> RNG sources. Could it be that that stick of yours is somehow getting >>>> involved in the RNG source locks? >>>> >>> >>> It's not limited to a single usb device. Plugging in/Unplugging >>> a logitech mouse dongle, the memstick, a Western Digital MY Passport >>> external usb hard drive, all lead to the locked keyboard and video. >>> >>> I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the >>> mount of output is mind numbing. >>> >> >> >> Can you enter kgdb when the usbconfig is froozen, and backtrace all >> kernel threads. You should see exactly what locks are the problem. >> >> Maybe some lock didn't get properly unlocked! >> > > I haven't tried kgdb. I did try to attach gdb to the usbconfig > process via its pid, but gdb dumped core. > > I haven't looked at locks in kgdb, what command or commands should > I try. > > Hi, You enter: thread apply all bt That will give you the backtrace of all threads. Grep for usbconfig, and figure out which line is causing the problem in the kernel. Then look at the USB explore threads and see where they are stuck in the detach of umass! --HPS From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 19:41:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04B368CC for ; Sun, 16 Nov 2014 19:41:05 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA0BCEE5 for ; Sun, 16 Nov 2014 19:41:04 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id uz6so14741264obc.19 for ; Sun, 16 Nov 2014 11:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yhLXQmHRDuC1elsPipmxu7Ozvyliysy/qVsmzswxmag=; b=MaHdyL/7XTexDLracjBrAlFddveXJIClVJOiQypLwKrZE8JM+g+CbmhSimFW+yrnlz 5OQ4oV91ScGrnXQQSqhW0/gAxcWLy07Q6njD0PdRDNdaG9bSQ9kPU+nz+oelZQnFpAi2 uKtBiAgWauX+j2w93lQJUe9iR/IY2mlOa38RaFk3gHlsEqCxgKusB0TD3uyjEJuKeMg5 qmr9JXpb7wKdL/UVOLrORS8TrkpTGF5cj+t+ZonDF8/Jzr+JlbgrfF/DILMyClBj4BPa eubt7nlfUyopWXjAZ0iJgAu64EK+diYxWIKxzerUbWQwnL6g6hdmk2+v5aavNrVpPMct AYJw== MIME-Version: 1.0 X-Received: by 10.60.41.170 with SMTP id g10mr2984050oel.53.1416166863999; Sun, 16 Nov 2014 11:41:03 -0800 (PST) Received: by 10.202.6.21 with HTTP; Sun, 16 Nov 2014 11:41:03 -0800 (PST) Received: by 10.202.6.21 with HTTP; Sun, 16 Nov 2014 11:41:03 -0800 (PST) In-Reply-To: <20141116180733.GA35841@troutmask.apl.washington.edu> References: <20141116180733.GA35841@troutmask.apl.washington.edu> Date: Sun, 16 Nov 2014 11:41:03 -0800 Message-ID: Subject: Re: init(8) diagnostics? From: Freddie Cash To: Steve Kargl Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 19:41:05 -0000 On Nov 16, 2014 10:07 AM, "Steve Kargl" wrote: > > In init(8), one finds under DIAGNOSISTICS > > "some processes would not die; ps axl advised." > > So, just how is one to actually run 'ps axl advised' as > the message appears as init(8) is killing off the system? "shutdown now" will drop you to single-user mode with a running shell where you can run that command to see what hasn't been stopped. IIRC, that message appears right before you drop to the shell, although I haven't run it a long time, so going by memory. From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 19:57:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9478CAAA for ; Sun, 16 Nov 2014 19:57:24 +0000 (UTC) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BA4D7A for ; Sun, 16 Nov 2014 19:57:22 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id x12so23320620wgg.3 for ; Sun, 16 Nov 2014 11:57:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gySrAzSkwbvVIgpZVw2DvGMWiQ3pnThP0rTLMOO9Ksw=; b=mY8h3ZrD9CpV3PryBmd1qKuzDCvXYj8i5/ORmk+60h8KPbsAqAfHvQR4jnwB6joQv5 ruFOlOqEP6jqKhgsKDef7ZR6EWK82lqC8yDB/6+IM2p2SisK8o70aiXgDqd8dFTN1FAa +aBqvlqCHh3vvVXefo/QsdFruAck4Qfiw0jPQ+GvJALVLxI0IwqHivqKL7mVirHNEShR 6s1Gc4Y4C429lKiOjFFQHsIc4nZWv9/DpvKZW/F+qPs/fIpSNu1s7ksjLmLtxisCs+T+ g/PnqatxqKdwW9C01uTJCSTUqmaZ7bHC08Flm+9X1M9uZPfuVVWhM3t9ROq11qqEKH7Q QBzQ== X-Gm-Message-State: ALoCoQnfk34HFyvzZoDNx657kOuzDiszk+mUpSA5YpQPTD4Tk4F5Q5XycsllGjz4QxHYpbBc6nrZ X-Received: by 10.180.86.38 with SMTP id m6mr24997556wiz.65.1416167834684; Sun, 16 Nov 2014 11:57:14 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id kn5sm41081697wjb.48.2014.11.16.11.57.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Nov 2014 11:57:14 -0800 (PST) Message-ID: <5469019C.3070005@multiplay.co.uk> Date: Sun, 16 Nov 2014 19:57:16 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: init(8) diagnostics? References: <20141116180733.GA35841@troutmask.apl.washington.edu> In-Reply-To: <20141116180733.GA35841@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 19:57:24 -0000 Its usually something like stalled IO On 16/11/2014 18:07, Steve Kargl wrote: > In init(8), one finds under DIAGNOSISTICS > > "some processes would not die; ps axl advised." > > So, just how is one to actually run 'ps axl advised' as > the message appears as init(8) is killing off the system? > From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 20:57:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A897CDDF for ; Sun, 16 Nov 2014 20:57:27 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 863A289A for ; Sun, 16 Nov 2014 20:57:27 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAGKvQ69037029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Nov 2014 12:57:26 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAGKvQnh037028; Sun, 16 Nov 2014 12:57:26 -0800 (PST) (envelope-from sgk) Date: Sun, 16 Nov 2014 12:57:26 -0800 From: Steve Kargl To: Freddie Cash Subject: Re: init(8) diagnostics? Message-ID: <20141116205726.GA37019@troutmask.apl.washington.edu> References: <20141116180733.GA35841@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 20:57:27 -0000 On Sun, Nov 16, 2014 at 11:41:03AM -0800, Freddie Cash wrote: > On Nov 16, 2014 10:07 AM, "Steve Kargl" > wrote: > > > > In init(8), one finds under DIAGNOSISTICS > > > > "some processes would not die; ps axl advised." > > > > So, just how is one to actually run 'ps axl advised' as > > the message appears as init(8) is killing off the system? > > "shutdown now" will drop you to single-user mode with a running shell where > you can run that command to see what hasn't been stopped. IIRC, that > message appears right before you drop to the shell, although I haven't run > it a long time, so going by memory. Thanks! 'shutdown now' got me to a point where I found the root cause of my issues. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Nov 16 20:59:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB942EE9; Sun, 16 Nov 2014 20:59:26 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A87C8AA; Sun, 16 Nov 2014 20:59:26 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id kx10so658961pab.2 for ; Sun, 16 Nov 2014 12:59:26 -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=2k0WS/pPmM6hP5WwTyD8VqiQK3I/rEb2BvClUx2CY54=; b=hIH8IUPaWFAqAbocHNIlNPupJRcdauk+2fiVBzKQW2ZobHu8NegLph22KipsdFMaLr 10BlT6/MsR394AXMnL3Pl6YMZfjO/tM21fBqNvMRBX9Z1HBGrmKEK70Y63JBXTstwVa7 Xn2bcEFUOOVh7PfnkEFHUH9DkfRGL//pVDcbCyWMpHBzsvFcT1VoSS5teI1DO9wQ5tK4 fCvO1M6dxZ1WxnuLa6qltFqzbbFAwK2V3kTtCyS+Tqyn5rIQN5RMoTJhQMx06BFwNtL+ Dt3QVGbs41aGdcuwY8JiLy+NQ+TZh8nYfxGjlEN/k2ZvcLNV7Au66yiv/7JT2vqNpSwP 8zDg== MIME-Version: 1.0 X-Received: by 10.66.234.100 with SMTP id ud4mr25322446pac.36.1416171566186; Sun, 16 Nov 2014 12:59:26 -0800 (PST) Received: by 10.70.94.167 with HTTP; Sun, 16 Nov 2014 12:59:26 -0800 (PST) In-Reply-To: <20141116183753.GA36021@troutmask.apl.washington.edu> References: <20141116180733.GA35841@troutmask.apl.washington.edu> <5468EB84.2070309@freebsd.org> <20141116183753.GA36021@troutmask.apl.washington.edu> Date: Sun, 16 Nov 2014 14:59:26 -0600 Message-ID: Subject: Re: init(8) diagnostics? From: Adam Vande More To: Steve Kargl Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-current@freebsd.org" , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 20:59:26 -0000 On Sun, Nov 16, 2014 at 12:37 PM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Sun, Nov 16, 2014 at 01:23:00PM -0500, Allan Jude wrote: > > On 2014-11-16 13:07, Steve Kargl wrote: > > > In init(8), one finds under DIAGNOSISTICS > > > > > > "some processes would not die; ps axl advised." > > > > > > So, just how is one to actually run 'ps axl advised' as > > > the message appears as init(8) is killing off the system? > > > > > > > In this case 'advised' is not a literal part of the command, but rather, > > it is suggesting that running 'ps axl' will show which process(es) are > > still running, and those would be the ones that would not die. > > > > When this message comes up, how far through the shutdown are you? Does > > it stall there for a while? or continue quickly? > > > > Yes, I know that the message means that one should run 'ps axl'. > > The system is well beyond any hope of interactive commands at the > console. It appears right after init(8) stops syslogd and before > the 'stopping vnlru ... done.' message. > > I was hoping that I could put the command in /etc/shutdown.rc, but > reading that script did not provide the insight needed to automatically > run the command. > > It is somewhat surprising that init(8) does not give the PID(s) of > the offending process(es). Or why doesn't it just run it automatically. -- Adam From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 00:34:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F469673; Mon, 17 Nov 2014 00:34:40 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EEF5FC5; Mon, 17 Nov 2014 00:34:40 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id l15so7490357wiw.10 for ; Sun, 16 Nov 2014 16:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nOXW/sPHYGV/g6ZAG6+BlGxMmgeucdoiM69ByrpkUzY=; b=unFwvpaf2tv17Vama7ap8udGusBPfFfgozofwH2dxeEd+Tb6DqpuggRErYhDMgWK0R bRevz+nYnZLSVhP3je7rijxLl8zVqzgle+rTmv4YfaCjYi+p6Hm2CVc5q0CiF/SkCwXg W7HlPrvXIxvlSlWluE2KXaRWXJ1X34Kn2gCBMH5RNIGtlEGXPLCEpmi/G7dHiNtQXHry ayf693vN1VePiXo3LFwSG1ICR6BNwD2vlL9TlohFDRVpVyTePATUC3OoVgD5CzqQ9oWe 206xEvDohlKt4AgqE2gVDaXPCLqDBxjlGM7wQ3nFs3C1ZQTTy1gLK8YSbH/0KleLjTmy GNXQ== MIME-Version: 1.0 X-Received: by 10.194.71.84 with SMTP id s20mr135529wju.128.1416184478285; Sun, 16 Nov 2014 16:34:38 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sun, 16 Nov 2014 16:34:38 -0800 (PST) In-Reply-To: <5468FBFB.1090208@selasky.org> References: <20141116175102.GA35649@troutmask.apl.washington.edu> <1416162070.4781.186.camel@revolution.hippie.lan> <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> <20141116190344.GC36021@troutmask.apl.washington.edu> <5468F814.6010702@selasky.org> <20141116192959.GB36339@troutmask.apl.washington.edu> <5468FBFB.1090208@selasky.org> Date: Sun, 16 Nov 2014 16:34:38 -0800 X-Google-Sender-Auth: -8sX4G8oYPbfkl9JMGdkOU4LN40 Message-ID: Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Dag-Erling Sm?rgrav , freebsd-current , Ian Lepore , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 00:34:40 -0000 ... or since you can ssh into the thing, try as root: procstat -ka -adrian On 16 November 2014 11:33, Hans Petter Selasky wrote: > On 11/16/14 20:29, Steve Kargl wrote: >> >> On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote: >>> >>> On 11/16/14 20:03, Steve Kargl wrote: >>>> >>>> On Sun, Nov 16, 2014 at 06:55:53PM +0000, Mark R V Murray wrote: >>>>> >>>>> >>>>>> On 16 Nov 2014, at 18:51, Steve Kargl >>>>>> wrote: >>>>>> >>>>>> If you have not read the entire thread, once the laptop keyboard and >>>>>> video output lock up, I can ssh into the laptop. If I run usbconfig, >>>>>> it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* >>>>>> devices >>>>>> have not been destroyed. >>>>> >>>>> >>>>> Weirder and weirder :-(. >>>>> >>>>> Something with SX locks? Hmm. I do use those for attach and detach for >>>>> RNG sources. Could it be that that stick of yours is somehow getting >>>>> involved in the RNG source locks? >>>>> >>>> >>>> It's not limited to a single usb device. Plugging in/Unplugging >>>> a logitech mouse dongle, the memstick, a Western Digital MY Passport >>>> external usb hard drive, all lead to the locked keyboard and video. >>>> >>>> I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the >>>> mount of output is mind numbing. >>>> >>> >>> >>> Can you enter kgdb when the usbconfig is froozen, and backtrace all >>> kernel threads. You should see exactly what locks are the problem. >>> >>> Maybe some lock didn't get properly unlocked! >>> >> >> I haven't tried kgdb. I did try to attach gdb to the usbconfig >> process via its pid, but gdb dumped core. >> >> I haven't looked at locks in kgdb, what command or commands should >> I try. >> >> > > Hi, > > You enter: > > thread apply all bt > > That will give you the backtrace of all threads. Grep for usbconfig, and > figure out which line is causing the problem in the kernel. Then look at the > USB explore threads and see where they are stuck in the detach of umass! > > --HPS From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 00:46:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F09D49EB; Mon, 17 Nov 2014 00:46:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C8AC310C; Mon, 17 Nov 2014 00:46:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAH0kWPn037919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Nov 2014 16:46:32 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAH0kVQl037918; Sun, 16 Nov 2014 16:46:31 -0800 (PST) (envelope-from sgk) Date: Sun, 16 Nov 2014 16:46:31 -0800 From: Steve Kargl To: Adrian Chadd Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141117004631.GA37889@troutmask.apl.washington.edu> References: <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> <20141116190344.GC36021@troutmask.apl.washington.edu> <5468F814.6010702@selasky.org> <20141116192959.GB36339@troutmask.apl.washington.edu> <5468FBFB.1090208@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Hans Petter Selasky , freebsd-current , Ian Lepore , Dag-Erling Sm?rgrav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 00:46:34 -0000 On Sun, Nov 16, 2014 at 04:34:38PM -0800, Adrian Chadd wrote: > ... or since you can ssh into the thing, try as root: > > procstat -ka > I'll try that tomorrow. But, I now know that this is related to using hal from ports. If I comment out both enable_dbus and enable_hal in /etc/rc.conf, the system works as I would expect (ie., usb now works for unplugging devices!). I further suspect that the problems lies in hal_probe_storage, but haven't got too much further. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 01:45:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7346A84C; Mon, 17 Nov 2014 01:45:58 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4B9855; Mon, 17 Nov 2014 01:45:58 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id sAH1jvwK038210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Nov 2014 17:45:57 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id sAH1jusS038209; Sun, 16 Nov 2014 17:45:56 -0800 (PST) (envelope-from sgk) Date: Sun, 16 Nov 2014 17:45:56 -0800 From: Steve Kargl To: Hans Petter Selasky Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem Message-ID: <20141117014556.GA38184@troutmask.apl.washington.edu> References: <1416162070.4781.186.camel@revolution.hippie.lan> <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> <20141116190344.GC36021@troutmask.apl.washington.edu> <5468F814.6010702@selasky.org> <20141116192959.GB36339@troutmask.apl.washington.edu> <5468FBFB.1090208@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5468FBFB.1090208@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Adrian Chadd , freebsd-current , Dag-Erling Sm?rgrav , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 01:45:58 -0000 On Sun, Nov 16, 2014 at 08:33:15PM +0100, Hans Petter Selasky wrote: > > thread apply all bt > > That will give you the backtrace of all threads. Grep for usbconfig, and > figure out which line is causing the problem in the kernel. Then look at > the USB explore threads and see where they are stuck in the detach of umass! > I haven't tried the kgdb approach, yet. I can say that the problem is coming from sg device. If I have 'device sg' in my config file, the problems occur. Removing 'device sg' gives a working kernel. If I do not start hald in /etc/rc.conf, everything works as expected. Now, if hald was started at boot and I then stop hald with '/usr/local/etc/rc.d/hald stop' then the one hald relate process is not stopped. I've wrapped lines to keep this short. % ps axl | grep hald UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 1058 1 195 20 0 13180 3512 - I - 0:00.05 hald-probe-storage: /dev/sg1 (hald-probe-storage) Using the procstat as suggested by Adrian, I have % procstat -ka 1058 100157 hald-probe-storage hald-probe-stora mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep sgread giant_read devfs_read_f dofileread kern_readv sys_read syscall Xint0x80_syscall -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 06:53:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FBCDED3; Mon, 17 Nov 2014 06:53:14 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3BAE9784; Mon, 17 Nov 2014 06:53:13 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id C27F6A1B6; Mon, 17 Nov 2014 06:53:12 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 36BEB1B57; Mon, 17 Nov 2014 07:53:11 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Steve Kargl Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem References: <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> <20141116190344.GC36021@troutmask.apl.washington.edu> <5468F814.6010702@selasky.org> <20141116192959.GB36339@troutmask.apl.washington.edu> <5468FBFB.1090208@selasky.org> <20141117004631.GA37889@troutmask.apl.washington.edu> Date: Mon, 17 Nov 2014 07:53:11 +0100 In-Reply-To: <20141117004631.GA37889@troutmask.apl.washington.edu> (Steve Kargl's message of "Sun, 16 Nov 2014 16:46:31 -0800") Message-ID: <8661ee71yg.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 06:53:14 -0000 Steve Kargl writes: > I'll try that tomorrow. But, I now know that this is related to using > hal from ports. If I comment out both enable_dbus and enable_hal in > /etc/rc.conf, the system works as I would expect (ie., usb now works > for unplugging devices!). I further suspect that the problems lies in > hal_probe_storage, but haven't got too much further. HAL: the gift that keeps on giving. It also has this wonderful feature where it prevents you from unmounting anything you've ever mounted, because it watches for new mountpoints in the system, opens them, and keeps the file descriptors open indefinitely. I know this isn't really germane, but I just couldn't pass up a chance to complain about HAL. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 06:58:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E809B1; Mon, 17 Nov 2014 06:58:45 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 19E3D7C3; Mon, 17 Nov 2014 06:58:44 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id DDC30A1BE; Mon, 17 Nov 2014 06:58:43 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 668E71B5A; Mon, 17 Nov 2014 07:58:40 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Steve Kargl Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem References: <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> <20141116190344.GC36021@troutmask.apl.washington.edu> <5468F814.6010702@selasky.org> <20141116192959.GB36339@troutmask.apl.washington.edu> <5468FBFB.1090208@selasky.org> <20141117004631.GA37889@troutmask.apl.washington.edu> <8661ee71yg.fsf@nine.des.no> Date: Mon, 17 Nov 2014 07:58:40 +0100 In-Reply-To: <8661ee71yg.fsf@nine.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8r?= =?utf-8?Q?grav=22's?= message of "Mon, 17 Nov 2014 07:53:11 +0100") Message-ID: <861tp271pb.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 06:58:45 -0000 Dag-Erling Sm=C3=B8rgrav writes: > Steve Kargl writes: > > I'll try that tomorrow. But, I now know that this is related to using > > hal from ports. If I comment out both enable_dbus and enable_hal in > > /etc/rc.conf, the system works as I would expect (ie., usb now works > > for unplugging devices!). I further suspect that the problems lies in > > hal_probe_storage, but haven't got too much further. > HAL: the gift that keeps on giving. It also has this wonderful feature > where it prevents you from unmounting anything you've ever mounted, > because it watches for new mountpoints in the system, opens them, and > keeps the file descriptors open indefinitely. > > I know this isn't really germane, but I just couldn't pass up a chance > to complain about HAL. Hold on. It *is* germane: hal_probe_storage auto-mounted your USB stick and is holding on to it. If this also happens with mice and keyboards etc., you're probably looking at two different issues. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 08:40:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C024A931; Mon, 17 Nov 2014 08:40:12 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43D50238; Mon, 17 Nov 2014 08:40:12 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id h11so4882186wiw.13 for ; Mon, 17 Nov 2014 00:40:10 -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=dPW6uT9JBHmE5lOFG5FtN9sJRV2TW+YFJoG3k9vSIfk=; b=EnqXN0bYHuM2M8VyWBZlKok423zBg7fWAoOheWX40t8Z6eGEagVWeV/ymK5jHioWjf uBu1GFOxJ96b4y28r08WDcuS0dv/eZEwJr/gXlPVjDbTd0sm8z/YUulPjv1nWGw330YB KXOYUXwObdbcfe5ID1LyXcHQyVrxjCZS4hb/uiWrGNB1uP0i9eKeVvy5yb3j3qnS53J4 0hBvF60K5zsTf5+BDGM3TqSnbJ5BMU+IinmHMb6R0iombpfN7UZ/J6GX2nTHblYK32A/ RlZ2jNsasq5zru/6YNSusEm1c7dN2zBGm/LHRveKM5SH0069y3xZd/tcnhKzUzm0clJZ beFg== X-Received: by 10.181.12.6 with SMTP id em6mr28934012wid.24.1416213610656; Mon, 17 Nov 2014 00:40:10 -0800 (PST) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id t9sm50557006wjf.41.2014.11.17.00.40.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 00:40:08 -0800 (PST) Sender: Sulev-Madis Silber Message-ID: <5469B465.10208@hot.ee> Date: Mon, 17 Nov 2014 10:40:05 +0200 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Subject: Re: USB locks up system -- WAS Re: shutdown or acpi problem References: <1416162718.4781.192.camel@revolution.hippie.lan> <4F3B4E02-0ADD-46EB-BB90-BF360E810585@FreeBSD.org> <20141116185141.GB36021@troutmask.apl.washington.edu> <4443FEFB-17F1-4516-959F-4C70AB2A4382@FreeBSD.org> <20141116190344.GC36021@troutmask.apl.washington.edu> <5468F814.6010702@selasky.org> <20141116192959.GB36339@troutmask.apl.washington.edu> <5468FBFB.1090208@selasky.org> <20141117004631.GA37889@troutmask.apl.washington.edu> <8661ee71yg.fsf@nine.des.no> <861tp271pb.fsf@nine.des.no> In-Reply-To: <861tp271pb.fsf@nine.des.no> X-TagToolbar-Keys: D20141117104005042 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Hans Petter Selasky , Adrian Chadd , freebsd-current , Ian Lepore , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 08:40:13 -0000 On 2014-11-17 08:58, Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: >> Steve Kargl writes: >>> I'll try that tomorrow. But, I now know that this is related to using >>> hal from ports. If I comment out both enable_dbus and enable_hal in >>> /etc/rc.conf, the system works as I would expect (ie., usb now works >>> for unplugging devices!). I further suspect that the problems lies in >>> hal_probe_storage, but haven't got too much further. >> HAL: the gift that keeps on giving. It also has this wonderful feature >> where it prevents you from unmounting anything you've ever mounted, >> because it watches for new mountpoints in the system, opens them, and >> keeps the file descriptors open indefinitely. >> >> I know this isn't really germane, but I just couldn't pass up a chance >> to complain about HAL. > > Hold on. It *is* germane: hal_probe_storage auto-mounted your USB stick > and is holding on to it. If this also happens with mice and keyboards > etc., you're probably looking at two different issues. > > DES > I cursed at HAL a lot because it made uC inside r0ket to crap itself partially... this thing can be USB device but apparently didn't like black magic that HAL did. Maybe it tried to read from the beginning or something. It took lot of time to figure out why it doesn't work. Now I have set of ignore files to prevent grabbing for every single device in system. From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 13:19:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AEBC428 for ; Mon, 17 Nov 2014 13:19:53 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2159B289 for ; Mon, 17 Nov 2014 13:19:52 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id sAHDJmRl007447; Mon, 17 Nov 2014 14:19:48 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 3332F30D7; Mon, 17 Nov 2014 14:19:48 +0100 (CET) Message-ID: <5469F5EE.9000808@omnilan.de> Date: Mon, 17 Nov 2014 14:19:42 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Oliver Pinter Subject: Re: Changing makeoptions UKBD_DFLT_KEYMAP leads to kernel build fail References: <5467CEE2.908@banym.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig66DC2FAB562DC26386F56F5C" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Mon, 17 Nov 2014 14:19:48 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: Dominik Zajac , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 13:19:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig66DC2FAB562DC26386F56F5C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Oliver Pinter's Nachricht vom 16.11.2014 12:53 (localtime): > On 11/15/14, Dominik Zajac wrote: >> Hi, >> >> I am trying to change the default keymap for my keyboard therefore I >> added the following options to my kernel configuration which leads to >> the error bellow. >> >> Added options: >> >> options KBD_INSTALL_CDEV >> >> options UKBD_DFLT_KEYMAP >> >> makeoptions UKBD_DFLT_KEYMAP=3Dde.iso >> >> >> I tried it with this, too: >> >> makeoptions UKBD_DFLT_KEYMAP=3Dgerman.iso >> >> >> Both leads to the following problem: >> >> >> /usr/src/sys/dev/usb/input/ukbd.c:1209:18: error: use of undeclare= d >> identifier 'key_map' >> >> sc->sc_keymap =3D key_map; >> >> ^ >> >> /usr/src/sys/dev/usb/input/ukbd.c:1210:18: error: use of undeclare= d >> identifier 'accent_map' >> >> sc->sc_accmap =3D accent_map; >> >> ^ >> >> 2 errors generated. >> >> *** Error code 1 > Hi! > > See this ticket: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194744 and the > related bugs. > >> Is there a dynamic way to change the keyboard layout at boot time to t= yp >> the zfs passphrase on my default keyboardlayout? No, you need to change default keymap, like you already found how to. But even if you use the keymap-name matching your current console (unlucky dependency at least since vt and sc use different keymap names, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193865, already listed as related in Oliver Pinter's BugReport), it most likely won't work for you, since you actually use kbdmux(4) instead ukbd(4) (if you haven't changed in your kernel conf). So first you have to make kbdmux's default keymap customizable (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D153459), then you'll= probably want to get rid of the build-dependency of matching keymap-names to the build-machine's active console (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193865). The latter especially for kbdmux, wich is an extra patch you can find in the first BugReport. It's working fine here in some dozend setups, also had feedback that it works, but found none having time to give it a short review and commit it= =2E Wondering why you get "error: use of undeclared identifier 'accent_map'"; If our active console is vt(4) and you define "de" or "de.kbd" [found while writing, you named de.iso!]=85 -Harry --------------enig66DC2FAB562DC26386F56F5C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRp9fMACgkQLDqVQ9VXb8iJFwCeOeD7Aut6NmlaPmnyFG0SHwXg 4fcAoJVWEuz9HevZ4Wg5UpWDD7yFg2Cq =ygau -----END PGP SIGNATURE----- --------------enig66DC2FAB562DC26386F56F5C-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 14:54:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3086EAB4; Mon, 17 Nov 2014 14:54:27 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEF63F80; Mon, 17 Nov 2014 14:54:26 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAHEt7F2081999; Mon, 17 Nov 2014 06:55:09 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Luigi Rizzo , Rui Paulo In-Reply-To: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> References: , <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> From: "Chris H" Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) Date: Mon, 17 Nov 2014 06:55:09 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <121786de210f46237d17adb9b4febc53@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , "Wojciech A. Koszek" , Alan Somers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 14:54:27 -0000 On Thu, 13 Nov 2014 19:55:16 -0800 Rui Paulo wrote > On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: > > But please nuke the current list -- it is completely inadequate > > for the code-in candidates and misleading for whoever wants to > > suggest new tasks. Again i am not saying that the projects > > suggested there are not important, just belong somewhere else > > e.g. gsoc. > > I refrained from voicing my opinion while the call for help was going on, but > I completely agree that the target age of this Google initiative is > inadequate to FreeBSD. The target population is 13 years to 17 years old and > I cannot even imagine a 13 year old knowing what FreeBSD is. > > I'm not sure we should participate in Code In ever again and perhaps we > should focus our efforts on Summer of Code only. @Luigi Very insightful. Thanks for taking the time to share your thoughts. :) @Rui Would tasks in re, or Mk/ be too far off base? --Chris > > -- > Rui Paulo > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 16:44:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E50989E for ; Mon, 17 Nov 2014 16:44:06 +0000 (UTC) Received: from gwave1.banym.de (gwave1.banym.de [212.72.74.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EBB3212 for ; Mon, 17 Nov 2014 16:44:05 +0000 (UTC) Received: from tesla.banym.local (dslb-084-057-003-046.084.057.pools.vodafone-ip.de [84.57.3.46]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by gwave1.banym.de (Postfix) with ESMTP id 4BE681C003; Mon, 17 Nov 2014 17:43:27 +0100 (CET) Message-ID: <546A25BB.1050005@banym.de> Date: Mon, 17 Nov 2014 17:43:39 +0100 From: Dominik Zajac User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Harald Schmalzbauer , Oliver Pinter Subject: Re: Changing makeoptions UKBD_DFLT_KEYMAP leads to kernel build fail References: <5467CEE2.908@banym.de> <5469F5EE.9000808@omnilan.de> In-Reply-To: <5469F5EE.9000808@omnilan.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Banym-MailScanner-Information: Please contact the ISP for more information X-Banym-MailScanner-ID: 4BE681C003.A36B7 X-Banym-MailScanner: Found to be clean X-Banym-MailScanner-From: banym@banym.de X-Spam-Status: No Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 16:44:06 -0000 Hi Harald, thanks for the detailed answer. I will test this asap. Is there some work planed to make the keyboard layout dynamical changeable? I run into this problem because I have to enter my zfs encryption pass phrase in a different layout than I set it while installation. This maybe confuses others. It would be nice if the installer is able to set the default keymap to the chosen one so you can enter your pass phrase in the same keymap you set it. Dominik On 11/17/2014 02:19 PM, Harald Schmalzbauer wrote: > Bezüglich Oliver Pinter's Nachricht vom 16.11.2014 12:53 > (localtime): >> On 11/15/14, Dominik Zajac wrote: >>> Hi, >>> >>> I am trying to change the default keymap for my keyboard >>> therefore I added the following options to my kernel >>> configuration which leads to the error bellow. >>> >>> Added options: >>> >>> options KBD_INSTALL_CDEV >>> >>> options UKBD_DFLT_KEYMAP >>> >>> makeoptions UKBD_DFLT_KEYMAP=de.iso >>> >>> >>> I tried it with this, too: >>> >>> makeoptions UKBD_DFLT_KEYMAP=german.iso >>> >>> >>> Both leads to the following problem: >>> >>> >>> /usr/src/sys/dev/usb/input/ukbd.c:1209:18: error: use of >>> undeclared identifier 'key_map' >>> >>> sc->sc_keymap = key_map; >>> >>> ^ >>> >>> /usr/src/sys/dev/usb/input/ukbd.c:1210:18: error: use of >>> undeclared identifier 'accent_map' >>> >>> sc->sc_accmap = accent_map; >>> >>> ^ >>> >>> 2 errors generated. >>> >>> *** Error code 1 >> Hi! >> >> See this ticket: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 and the >> related bugs. >> >>> Is there a dynamic way to change the keyboard layout at boot >>> time to typ the zfs passphrase on my default keyboardlayout? > > No, you need to change default keymap, like you already found how > to. But even if you use the keymap-name matching your current > console (unlucky dependency at least since vt and sc use different > keymap names, see > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865, already > listed as related in Oliver Pinter's BugReport), it most likely > won't work for you, since you actually use kbdmux(4) instead > ukbd(4) (if you haven't changed in your kernel conf). > > So first you have to make kbdmux's default keymap customizable > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=153459), then > you'll probably want to get rid of the build-dependency of > matching keymap-names to the build-machine's active console > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865). The > latter especially for kbdmux, wich is an extra patch you can find > in the first BugReport. > > It's working fine here in some dozend setups, also had feedback > that it works, but found none having time to give it a short review > and commit it. > > Wondering why you get "error: use of undeclared identifier > 'accent_map'"; If our active console is vt(4) and you define "de" > or "de.kbd" [found while writing, you named de.iso!]… > > -Harry > From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 16:54:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41BC4AEF; Mon, 17 Nov 2014 16:54:00 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 2844737E; Mon, 17 Nov 2014 16:54:00 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id D1680341F874; Mon, 17 Nov 2014 08:53:59 -0800 (PST) Message-ID: <546A2827.3000607@mu.org> Date: Mon, 17 Nov 2014 08:53:59 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Chris H , Luigi Rizzo , Rui Paulo Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) References: , <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> <121786de210f46237d17adb9b4febc53@ultimatedns.net> In-Reply-To: <121786de210f46237d17adb9b4febc53@ultimatedns.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , "Wojciech A. Koszek" , Alan Somers , Kris Moore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 16:54:00 -0000 On 11/17/14, 6:55 AM, Chris H wrote: > On Thu, 13 Nov 2014 19:55:16 -0800 Rui Paulo wrote > >> On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: >>> But please nuke the current list -- it is completely inadequate >>> for the code-in candidates and misleading for whoever wants to >>> suggest new tasks. Again i am not saying that the projects >>> suggested there are not important, just belong somewhere else >>> e.g. gsoc. >> I refrained from voicing my opinion while the call for help was going on, but >> I completely agree that the target age of this Google initiative is >> inadequate to FreeBSD. The target population is 13 years to 17 years old and >> I cannot even imagine a 13 year old knowing what FreeBSD is. >> >> I'm not sure we should participate in Code In ever again and perhaps we >> should focus our efforts on Summer of Code only. > @Luigi > Very insightful. Thanks for taking the time to share your thoughts. :) > > @Rui > Would tasks in re, or Mk/ be too far off base? > > [[ cc'd Kris ]] Maybe PCBSD has some ideas for code-in? It's a bit easier on newbies than FreeBSD. Mind you, I was using FreeBSD at 19 years old (would have used it earlier if I'd know about it), coding in assembler at 14... so there are people out there. I just think for it to be something people will want to do it's going to be less "edit these text files to improve process" and more "make dancing daemons happen on the console." -Alfred From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 18:35:21 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44F19C2; Mon, 17 Nov 2014 18:35:21 +0000 (UTC) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECD05106; Mon, 17 Nov 2014 18:35:20 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward5l.mail.yandex.net (Yandex) with ESMTP id 94CAEC414E2; Mon, 17 Nov 2014 21:35:17 +0300 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 1AC961340C58; Mon, 17 Nov 2014 21:35:16 +0300 (MSK) Received: from 84.201.165.9-vpn.dhcp.yndx.net (84.201.165.9-vpn.dhcp.yndx.net [84.201.165.9]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id PScP7wSFpY-ZGg8wAEq; Mon, 17 Nov 2014 21:35:16 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 4ff82e88-1b38-4d30-8086-60161f4d1e46 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1416249316; bh=o9q5beg9yQiuUwD48mieZ/qc3d2K9eCDkLFhglmf7cc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=F1ipfvdYE+DrYaZ6kww5z9oJqE1hS6A5g/yHQ5BWCrMnh7Sa88e2BPjltPD97S2yO 9iRRl3vDte88qVyNHH6jGUb0lk5105VqG9X/sBGnlkVF/QyF8w5alfTJUT5SmJAfPv K5qKSYjJTU3zu8RG33Qn7g50WqGtLLPj0hvqnvrc= Authentication-Results: smtp1h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <546A3FB8.8080808@yandex.ru> Date: Mon, 17 Nov 2014 21:34:32 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org, current@freebsd.org Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> <546744B6.8040504@yandex.ru> <20141116061525.GG24601@funkthat.com> In-Reply-To: <20141116061525.GG24601@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xk5GosCE5S4w41ADP5rTJVQD7GArp2Tev" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 18:35:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xk5GosCE5S4w41ADP5rTJVQD7GArp2Tev Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 16.11.2014 09:15, John-Mark Gurney wrote: > Ok, I was able to reproduce the bug, and found that my optimization > for single mbuf packets was broken... I've attached a new patch > that has the fix... >=20 > This patch also has added a lock around the aesni fpu context setting > to deal w/ the issue that I had... >=20 > Let me know how things are w/ this new patch. Hi, with this patch all works as expected. --=20 WBR, Andrey V. Elsukov --xk5GosCE5S4w41ADP5rTJVQD7GArp2Tev 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUaj+/AAoJEAHF6gQQyKF6wD8H/RwpnNmiwCxKbApaNobGzvwX eVW4QvcSMvnJjdj67LHmf0yGv4GRf1tizk4XIvQk/Ca+AFwJULjASbSPpgPI6hW7 +WPSv/bsVmilSy6QIlOl25/BYDDAK0/w2nYdDplBh6Lb41fiv7i2BKtioQIW3QBk AIaXPz981Nw1JfpVX+nDxfIOxI2/x3KN2UrJuER/QXogZLICZNtqUONb0X4NUzfu GOUNazHReIwt31a61DZpx7gfhe5Up3NM9MXkkioJvEV3XYSMnE9L32LA19NOEXld kLX7TRqkWP12TtrXtAblzqyZmKgbWTGctaPU6boJDtkiBm8MJ1Boe68wHoMToHo= =1RaY -----END PGP SIGNATURE----- --xk5GosCE5S4w41ADP5rTJVQD7GArp2Tev-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 20:31:17 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD9B233B; Mon, 17 Nov 2014 20:31:17 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C9F7FF; Mon, 17 Nov 2014 20:31:16 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAHKVE3f035398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2014 12:31:15 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAHKVEJ2035397; Mon, 17 Nov 2014 12:31:14 -0800 (PST) (envelope-from jmg) Date: Mon, 17 Nov 2014 12:31:14 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141117203114.GQ24601@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , freebsd-security@freebsd.org, current@freebsd.org References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> <546744B6.8040504@yandex.ru> <20141116061525.GG24601@funkthat.com> <546A3FB8.8080808@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546A3FB8.8080808@yandex.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 17 Nov 2014 12:31:15 -0800 (PST) Cc: freebsd-security@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 20:31:17 -0000 Andrey V. Elsukov wrote this message on Mon, Nov 17, 2014 at 21:34 +0300: > On 16.11.2014 09:15, John-Mark Gurney wrote: > > Ok, I was able to reproduce the bug, and found that my optimization > > for single mbuf packets was broken... I've attached a new patch > > that has the fix... > > > > This patch also has added a lock around the aesni fpu context setting > > to deal w/ the issue that I had... > > > > Let me know how things are w/ this new patch. > > with this patch all works as expected. Just so you know, even tunnel mode w/ aesni on a clean HEAD can panic.. I just got a: panic: dummy ctx from the tunnel mode by having two machines ping -f'ing each other... This is a different form of the same panic I posted about earlier w/ the fpu context being reused for different threads... I plan on committing the patch w/o the mtx_lock as including the lock will significantly impact people who use geli... I am working on a fix for this w/ kib that will allow us to not allocate an fpu context and get things a little more stable, but there are other bugs that also need to be addressed before aesni is safe to use w/ IPsec... Thanks for testing! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Nov 17 21:28:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A01358CF; Mon, 17 Nov 2014 21:28:26 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 917F992E; Mon, 17 Nov 2014 21:28:26 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 76D029BD; Mon, 17 Nov 2014 21:28:26 +0000 (UTC) Date: Mon, 17 Nov 2014 21:28:26 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <315306939.51.1416259706070.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1863 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 21:28:26 -0000 See ------------------------------------------ Started by an SCM change Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace java.io.IOException: remote file operation failed: at hudson.remoting.Channel@270917b9:jenkins-10.freebsd.org: java.io.IOException: Remote call on jenkins-10.freebsd.org failed at hudson.FilePath.act(FilePath.java:977) at hudson.FilePath.act(FilePath.java:959) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:909) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:844) at hudson.model.AbstractProject.checkout(AbstractProject.java:1258) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528) at hudson.model.Run.execute(Run.java:1759) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: java.io.IOException: Remote call on jenkins-10.freebsd.org failed at hudson.remoting.Channel.call(Channel.java:760) at hudson.FilePath.act(FilePath.java:970) ... 11 more Caused by: java.lang.OutOfMemoryError: PermGen space From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 07:21:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6DB769F for ; Tue, 18 Nov 2014 07:21:24 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9BD4B1A for ; Tue, 18 Nov 2014 07:21:24 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id g10so7761682pdj.27 for ; Mon, 17 Nov 2014 23:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VTxkMibZvJbEwJcSsE9U85tJe6dLP3czYDfpAzTmOwE=; b=Hox2zkMsO2HGq2MOpQS5GtT4YKGc+lmaz/tBIGOsiloXcN9LRVrJ4ywRi1CF1v5FZE mZFz6WVcWteyJcSLeKJoD+r/UcGnkq9iVOSJ7LCz/ALGq7Vx8fcqS/EI2Jwy9PRm3OaA pcWWf6diMxoTumCimAdlEvV1Uw+wUbixzc0SD68P0BTu82inGRU5fJV4qBOmr/vdBYei yLpUkKcAVRmwia+H2Ka7xz41C+WUmq5b1EMs25DdvkE2rHZRE8oYdExO4EImMobzTV6V pQrc8aNkUCQesuBrSRUQ017hpYlZFD40fD/PDb/LoiqmgRniug4TCwzMhmqk/wp3NhSn gL4g== X-Received: by 10.70.109.140 with SMTP id hs12mr35007287pdb.30.1416295284137; Mon, 17 Nov 2014 23:21:24 -0800 (PST) Received: from raichu ([198.244.104.6]) by mx.google.com with ESMTPSA id o6sm37132730pdl.3.2014.11.17.23.21.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Nov 2014 23:21:23 -0800 (PST) Sender: Mark Johnston Date: Mon, 17 Nov 2014 23:21:18 -0800 From: Mark Johnston To: Ryan Stone Subject: Re: General Protection Fault in prelist_remove() Message-ID: <20141118072118.GA1883@raichu> References: <52372362.10506@bitfrost.no> <20130916171016.GA1509@charmander> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Hans Petter Selasky , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 07:21:25 -0000 On Sat, Nov 15, 2014 at 04:17:35PM -0500, Ryan Stone wrote: > On Mon, Sep 16, 2013 at 1:10 PM, Mark Johnston wrote: > > I've partially fixed this at work by adding a rw lock to protect access > > to the the prefix, default router, and DAD lists. The patch is here: > > http://people.freebsd.org/~markj/patches/ndp-locking.diff > > Hi Mark, > > I've hit a bug in this patch today. The problem is in the locking of > the DAD list. Many functions (e.g. > nd6_dad_duplicated) call nd6_dad_find() to look up a dadq structure, > and then manipulate the structure with no lock held. The problem that > once nd6_dad_find() releases the ND lock there is nothing preventing > another thread from going in and free'ing the structure. This causes > a use-after-free in nd6_dad_duplicated. I have a setup which is > somehow triggering DAD on link-local addresses (I don't understand > why; I don't have duplicate mac addresses on the network as best that > I can tell) and with INVARIANTS on I very frequently get a crash in > nd6_dad_duplicated. > > > It looks to me that the only way to fix it is either introduce > referencing counting into the structure, or push the locking out of > nd6_dad_find() and into the callers. Any opinions? I spent some time looking at the code. There seem to be a few miscellaneous bugs in addition to races you described above; nd6_dad_na_input() can potentially call nd6_dad_duplicated() with a NULL dadq, for example. I wasn't able to specifically reproduce the use-after-free that you described, but it's pretty easy to trigger crashes in the DAD code, e.g. by assigning a duplicate address to an interface in a loop. It's hard to fix these races directly because of the different contexts in which the DAD entry queue is manipulated: entries can be added or removed with ioctls when addresses are added or removed, the DAD callout can modify the queue, and nd6_dad_duplicated() can be called in the packet processing path for some NS or NA packets. It seems to me that this can be simplified somewhat though, which makes it easier to fix the races. The patch below (against HEAD) simplifies the DAD code and tries to fix remaining races by adding a refcount to struct dadq. Note that hrs@ added a lock for the DAD queue in r266857, so my ndp-locking patch needs to be rebased. It simplifies the code by having the DAD callout do most of the work: when a NS or NA packet indicates that an address is a duplicate, we just increment a counter and wait for the corresponding DAD callout to flag the address. With the patch, DAD is only cancelled when the corresponding address is removed from an interface. It also fixes some improper handling of the ifa references for struct dadq. Note that there are still some races around the struct dadq counters themselves (the increments are non-atomic), and the handling of in6_flags should be atomic. A copy of the patch is here: https://people.freebsd.org/~markj/patches/nd6_dad_races.diff It survives some basic tests and stress testing that previously exposed some races on HEAD. Thanks, -Mark diff --git a/sys/netinet6/nd6_nbr.c b/sys/netinet6/nd6_nbr.c index a917b76..819fe30 100644 --- a/sys/netinet6/nd6_nbr.c +++ b/sys/netinet6/nd6_nbr.c @@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -1167,6 +1168,7 @@ struct dadq { int dad_na_icount; struct callout dad_timer_ch; struct vnet *dad_vnet; + u_int dad_refcnt; }; static VNET_DEFINE(TAILQ_HEAD(, dadq), dadq); @@ -1183,12 +1185,22 @@ static VNET_DEFINE(struct rwlock, dad_rwlock); #define DADQ_WUNLOCK() rw_wunlock(&V_dad_rwlock) static void +nd6_dad_rele(struct dadq *dp) +{ + + if (refcount_release(&dp->dad_refcnt)) { + ifa_free(dp->dad_ifa); + free(dp, M_IP6NDP); + } +} + +static void nd6_dad_add(struct dadq *dp) { - ifa_ref(dp->dad_ifa); /* just for safety */ + refcount_acquire(&dp->dad_refcnt); DADQ_WLOCK(); - TAILQ_INSERT_TAIL(&V_dadq, (struct dadq *)dp, dad_list); + TAILQ_INSERT_TAIL(&V_dadq, dp, dad_list); DADQ_WUNLOCK(); } @@ -1196,10 +1208,10 @@ static void nd6_dad_del(struct dadq *dp) { - ifa_free(dp->dad_ifa); DADQ_WLOCK(); - TAILQ_REMOVE(&V_dadq, (struct dadq *)dp, dad_list); + TAILQ_REMOVE(&V_dadq, dp, dad_list); DADQ_WUNLOCK(); + nd6_dad_rele(dp); } static struct dadq * @@ -1209,8 +1221,10 @@ nd6_dad_find(struct ifaddr *ifa) DADQ_RLOCK(); TAILQ_FOREACH(dp, &V_dadq, dad_list) - if (dp->dad_ifa == ifa) + if (dp->dad_ifa == ifa) { + refcount_acquire(&dp->dad_refcnt); break; + } DADQ_RUNLOCK(); return (dp); @@ -1228,7 +1242,8 @@ static void nd6_dad_stoptimer(struct dadq *dp) { - callout_stop(&dp->dad_timer_ch); + callout_drain(&dp->dad_timer_ch); + nd6_dad_rele(dp); } /* @@ -1275,8 +1290,9 @@ nd6_dad_start(struct ifaddr *ifa, int delay) } if (ND_IFINFO(ifa->ifa_ifp)->flags & ND6_IFF_IFDISABLED) return; - if (nd6_dad_find(ifa) != NULL) { + if ((dp = nd6_dad_find(ifa)) != NULL) { /* DAD already in progress */ + nd6_dad_rele(dp); return; } @@ -1303,9 +1319,11 @@ nd6_dad_start(struct ifaddr *ifa, int delay) * (re)initialization. */ dp->dad_ifa = ifa; + ifa_ref(dp->dad_ifa); dp->dad_count = V_ip6_dad_count; dp->dad_ns_icount = dp->dad_na_icount = 0; dp->dad_ns_ocount = dp->dad_ns_tcount = 0; + refcount_init(&dp->dad_refcnt, 1); nd6_dad_add(dp); if (delay == 0) { nd6_dad_ns_output(dp, ifa); @@ -1334,8 +1352,16 @@ nd6_dad_stop(struct ifaddr *ifa) nd6_dad_stoptimer(dp); + /* + * The DAD queue entry may have been removed by nd6_dad_timer() while + * we were waiting for it to stop, so re-do the lookup. + */ + nd6_dad_rele(dp); + if (nd6_dad_find(ifa) == NULL) + return; + nd6_dad_del(dp); - free(dp, M_IP6NDP); + nd6_dad_rele(dp); } static void @@ -1354,38 +1380,30 @@ nd6_dad_timer(struct dadq *dp) } if (ND_IFINFO(ifp)->flags & ND6_IFF_IFDISABLED) { /* Do not need DAD for ifdisabled interface. */ - TAILQ_REMOVE(&V_dadq, (struct dadq *)dp, dad_list); log(LOG_ERR, "nd6_dad_timer: cancel DAD on %s because of " "ND6_IFF_IFDISABLED.\n", ifp->if_xname); - free(dp, M_IP6NDP); - dp = NULL; - ifa_free(ifa); - goto done; + goto dup; } if (ia->ia6_flags & IN6_IFF_DUPLICATED) { log(LOG_ERR, "nd6_dad_timer: called with duplicated address " "%s(%s)\n", ip6_sprintf(ip6buf, &ia->ia_addr.sin6_addr), ifa->ifa_ifp ? if_name(ifa->ifa_ifp) : "???"); - goto done; + goto dup; } if ((ia->ia6_flags & IN6_IFF_TENTATIVE) == 0) { log(LOG_ERR, "nd6_dad_timer: called with non-tentative address " "%s(%s)\n", ip6_sprintf(ip6buf, &ia->ia_addr.sin6_addr), ifa->ifa_ifp ? if_name(ifa->ifa_ifp) : "???"); - goto done; + goto dup; } /* timeouted with IFF_{RUNNING,UP} check */ if (dp->dad_ns_tcount > V_dad_maxtry) { nd6log((LOG_INFO, "%s: could not run DAD, driver problem?\n", if_name(ifa->ifa_ifp))); - - nd6_dad_del(dp); - free(dp, M_IP6NDP); - dp = NULL; - goto done; + goto dup; } /* Need more checks? */ @@ -1396,33 +1414,16 @@ nd6_dad_timer(struct dadq *dp) nd6_dad_ns_output(dp, ifa); nd6_dad_starttimer(dp, (long)ND_IFINFO(ifa->ifa_ifp)->retrans * hz / 1000); + goto done; } else { /* * We have transmitted sufficient number of DAD packets. * See what we've got. */ - int duplicate; - - duplicate = 0; - - if (dp->dad_na_icount) { - /* - * the check is in nd6_dad_na_input(), - * but just in case - */ - duplicate++; - } - - if (dp->dad_ns_icount) { - /* We've seen NS, means DAD has failed. */ - duplicate++; - } - - if (duplicate) { - /* (*dp) will be freed in nd6_dad_duplicated() */ + if (dp->dad_ns_icount > 0 || dp->dad_na_icount > 0) + /* We've seen NS or NA, means DAD has failed. */ nd6_dad_duplicated(ifa, dp); - dp = NULL; - } else { + else { /* * We are done with DAD. No NA came, no NS came. * No duplicate address found. Check IFDISABLED flag @@ -1436,13 +1437,11 @@ nd6_dad_timer(struct dadq *dp) "%s: DAD complete for %s - no duplicates found\n", if_name(ifa->ifa_ifp), ip6_sprintf(ip6buf, &ia->ia_addr.sin6_addr))); - - nd6_dad_del(dp); - free(dp, M_IP6NDP); - dp = NULL; } } - +dup: + nd6_dad_del(dp); + nd6_dad_rele(dp); done: CURVNET_RESTORE(); } @@ -1462,9 +1461,6 @@ nd6_dad_duplicated(struct ifaddr *ifa, struct dadq *dp) ia->ia6_flags &= ~IN6_IFF_TENTATIVE; ia->ia6_flags |= IN6_IFF_DUPLICATED; - /* We are done with DAD, with duplicate address found. (failure) */ - nd6_dad_stoptimer(dp); - ifp = ifa->ifa_ifp; log(LOG_ERR, "%s: DAD complete for %s - duplicate found\n", if_name(ifp), ip6_sprintf(ip6buf, &ia->ia_addr.sin6_addr)); @@ -1505,9 +1501,6 @@ nd6_dad_duplicated(struct ifaddr *ifa, struct dadq *dp) break; } } - - nd6_dad_del(dp); - free(dp, M_IP6NDP); } static void @@ -1535,7 +1528,6 @@ nd6_dad_ns_input(struct ifaddr *ifa) struct ifnet *ifp; const struct in6_addr *taddr6; struct dadq *dp; - int duplicate; if (ifa == NULL) panic("ifa == NULL in nd6_dad_ns_input"); @@ -1543,8 +1535,9 @@ nd6_dad_ns_input(struct ifaddr *ifa) ia = (struct in6_ifaddr *)ifa; ifp = ifa->ifa_ifp; taddr6 = &ia->ia_addr.sin6_addr; - duplicate = 0; dp = nd6_dad_find(ifa); + if (dp == NULL) + return; /* Quickhack - completely ignore DAD NS packets */ if (V_dad_ignore_ns) { @@ -1556,26 +1549,10 @@ nd6_dad_ns_input(struct ifaddr *ifa) return; } - /* - * if I'm yet to start DAD, someone else started using this address - * first. I have a duplicate and you win. - */ - if (dp == NULL || dp->dad_ns_ocount == 0) - duplicate++; - /* XXX more checks for loopback situation - see nd6_dad_timer too */ - if (duplicate) { - nd6_dad_duplicated(ifa, dp); - dp = NULL; /* will be freed in nd6_dad_duplicated() */ - } else { - /* - * not sure if I got a duplicate. - * increment ns count and see what happens. - */ - if (dp) - dp->dad_ns_icount++; - } + dp->dad_ns_icount++; + nd6_dad_rele(dp); } static void @@ -1587,9 +1564,8 @@ nd6_dad_na_input(struct ifaddr *ifa) panic("ifa == NULL in nd6_dad_na_input"); dp = nd6_dad_find(ifa); - if (dp) + if (dp != NULL) { dp->dad_na_icount++; - - /* remove the address. */ - nd6_dad_duplicated(ifa, dp); + nd6_dad_rele(dp); + } } From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 20:35:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14CD5D4B for ; Tue, 18 Nov 2014 20:35:58 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0069.outbound.protection.outlook.com [157.56.111.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A86DF1C for ; Tue, 18 Nov 2014 20:35:57 +0000 (UTC) Received: from [172.17.3.251] (63.252.212.99) by CO2PR0801MB662.namprd08.prod.outlook.com (10.141.247.25) with Microsoft SMTP Server (TLS) id 15.1.16.15; Tue, 18 Nov 2014 20:19:38 +0000 Message-ID: <546BA9D3.6070007@panasas.com> Date: Tue, 18 Nov 2014 15:19:31 -0500 From: "Ellis H. Wilson III" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: Subject: WITNESS observes 2 LORs on Boot of Release 10.1 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [63.252.212.99] X-ClientProxiedBy: BLUPR02CA045.namprd02.prod.outlook.com (25.160.23.163) To CO2PR0801MB662.namprd08.prod.outlook.com (10.141.247.25) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0801MB662; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0801MB662; X-Forefront-PRVS: 039975700A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(6049001)(189002)(199003)(28163001)(41574002)(53754006)(59896002)(107046002)(21056001)(95666004)(2351001)(122386002)(62966003)(107886001)(77156002)(97736003)(99396003)(450100001)(77096003)(229853001)(120916001)(105586002)(33656002)(106356001)(102836001)(4396001)(36756003)(31966008)(110136001)(83506001)(65956001)(65806001)(101416001)(64126003)(20776003)(47776003)(50466002)(64706001)(87266999)(54356999)(23756003)(86362001)(92566001)(50986999)(92726001)(40100003)(66066001)(46102003)(65816999)(80316001)(42186005)(87976001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0801MB662; H:[172.17.3.251]; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0801MB662; X-OriginatorOrg: panasas.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 20:35:58 -0000 Hi all, I'm observing the following two WITNESS LORs being thrown upon boot-up of 10.0 and I was tracking current, hoping they would go away by 10.1, but it seems they persist as shown below. I suspect this is because current is being built with WITNESS on but also with SKIPSPIN on. So these issues are unlikely to show up for any devs but those who specifically enable WITNESS and disable SKIPSPIN like myself. At my work we would greatly like to do our debugging with checking of spin-locking order included and panicing upon LOR detection. That's not possible with these in existence. Specifically: Event timer "RTC" frequency 32768 Hz quality 0 ppc0: cannot reserve I/O port range Timecounters tick every 10.000 msec pcm0: measured ac97 link rate at 29212 Hz lock order reversal: lock order reversal: 1st 0xffffffff8177a1a0 entropy harvest mutex (entropy harvest mutex) @ /usr/src/sys/dev/random/random_harvestq.c:198 2nd 0xffffffff81475108 scrlock (scrlock) @ /usr/src/sys/dev/syscons/syscons.c:2694 KDB: stack backtrace: #0 0xffffffff8092f020 at kdb_backtrace+0x60 #1 0xffffffff80944204 at witness_checkorder+0xc04 #2 0xffffffff808e6d5e at __mtx_lock_spin_flags+0x4e #3 0xffffffff80738b80 at sc_puts+0xb0 #4 0xffffffff8073c4e5 at sc_cnputc+0xe5 #5 0xffffffff808b6cf0 at cnputc+0x80 #6 0xffffffff808b6fa8 at cnputs+0x58 #7 0xffffffff80934011 at putchar+0x151 #8 0xffffffff80932c36 at kvprintf+0xf6 #9 0xffffffff809344ad at _vprintf+0x8d #10 0xffffffff809346c3 at printf+0x53 #11 0xffffffff80943fe0 at witness_checkorder+0x9e0 #12 0xffffffff808e6d5e at __mtx_lock_spin_flags+0x4e #13 0xffffffff8090019b at msleep_spin_sbt+0x5b #14 0xffffffff80698198 at random_kthread+0x78 #15 0xffffffff808cd941 at fork_exit+0x71 #16 0xffffffff80caee7e at fork_trampoline+0xe 1st 0xffffffff8177a1a0 entropy harvest mutex (entropy harvest mutex) @ /usr/src/sys/dev/random/random_harvestq.c:198 2nd 0xffffffff81568390 sleepq chain (sleepq chain) @ /usr/src/sys/kern/subr_sleepqueue.c:237 KDB: stack backtrace: #0 0xffffffff8092f020 at kdb_backtrace+0x60 #1 0xffffffff80944204 at witness_checkorder+0xc04 #2 0xffffffff808e6d5e at __mtx_lock_spin_flags+0x4e #3 0xffffffff8090019b at msleep_spin_sbt+0x5b #4 0xffffffff80698198 at random_kthread+0x78 #5 0xffffffff808cd941 at fork_exit+0x71 #6 0xffffffff80caee7e at fork_trampoline+0xe usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-6 device This is on a virtual machine via VirtualBox, but we have reproduced it on real hardware. Regarding the latter reversal, I have dug in the code and see the calls go about in the following order: In sys/dev/random/random_harvestq.c: 198 mtx_lock_spin(&harvest_mtx); 209 msleep_spin_sbt(&random_kthread_control, &harvest_mtx, Now in sys/kern/kern_synch.c: 297 sleepq_lock(ident); Now in sys/kern/subr_sleepqueue.c 237 mtx_lock_spin(&sc->sc_lock); The above line numbers might be a hair off from head since I'm looking at code synced last week. I'm happy to open a bug on this if that's the desirable course of action, or to even assist in fixing it, but I wanted to first see if anybody knew about these already (they didn't show up on the known LORs list on quick perusal) or if this was simply a case of WITNESS being overly conservative and throwing false positives. If this belongs on a different list just let me know. Thanks! ellis From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 22:39:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A027256E for ; Tue, 18 Nov 2014 22:39:24 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FBA0DD0 for ; Tue, 18 Nov 2014 22:39:23 +0000 (UTC) X-AuditID: 1209190e-f79696d000006c87-79-546bca943aa4 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 56.93.27783.49ACB645; Tue, 18 Nov 2014 17:39:16 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id sAIMdFVX025263; Tue, 18 Nov 2014 17:39:15 -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.8/8.12.4) with ESMTP id sAIMdDwK004723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Nov 2014 17:39:15 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAIMdD69011280; Tue, 18 Nov 2014 17:39:13 -0500 (EST) Date: Tue, 18 Nov 2014 17:39:13 -0500 (EST) From: Benjamin Kaduk To: "Ellis H. Wilson III" Subject: Re: WITNESS observes 2 LORs on Boot of Release 10.1 In-Reply-To: <546BA9D3.6070007@panasas.com> Message-ID: References: <546BA9D3.6070007@panasas.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrTvlVHaIweqXfBYnNrYwWsx584HJ gcljxqf5LB63j89jDWCK4rJJSc3JLEst0rdL4MrYefgmS8F//opNO46xNzB+5Oli5OSQEDCR 6Fz2nQ3CFpO4cG89kM3FISQwm0ni0O9tUM5GRomze69COYeYJDa2XGWEcBoYJX4+vccK0s8i oC2x+sxfJhCbTUBFYuabjWBzRQT0JM719IDVMAvIS/y/chmsRljARuLDhe0sIDYnUO+xb28Z QWxeAUeJGZMOMYPYQgJaEg+mrwCbIyqgI7F6/xQWiBpBiZMzn7BAzNSSWD59G8sERsFZSFKz kKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3ECA5WSb4djF8PKh1iFOBg VOLhTZyaFSLEmlhWXJl7iFGSg0lJlFfhaHaIEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFewW6g HG9KYmVValE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBK/9SaBGwaLU9NSKtMyc EoQ0EwcnyHAeoOFRIDW8xQWJucWZ6RD5U4yKUuK8H44DJQRAEhmleXC9sGTyilEc6BVhXiOQ dh5gIoLrfgU0mAlo8JwNmSCDSxIRUlINjAmPMqeb8n6/Gfsk8c3qwjtzdHaqy7yRsr4flBx1 2sE2hs2ZI37npjuFqUtOFj1b7ypmbnlnzu6b9WJPfdZ/T3h2d8Wh1imtDYc7Vni0ZBdNs1Sb 4qXd7zcnJ7jU4/lbJd87zIWvbOw/9S2udJv3LCCyOvFzZuTxr0ua71S9O8vpnPBEJjVyjxJL cUaioRZzUXEiAAigHgEBAwAA Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 22:39:24 -0000 On Tue, 18 Nov 2014, Ellis H. Wilson III wrote: > This is on a virtual machine via VirtualBox, but we have reproduced it on real > hardware. Regarding the latter reversal, I have dug in the code and see the > calls go about in the following order: > > In sys/dev/random/random_harvestq.c: > 198 mtx_lock_spin(&harvest_mtx); > 209 msleep_spin_sbt(&random_kthread_control, &harvest_mtx, > Now in sys/kern/kern_synch.c: > 297 sleepq_lock(ident); > Now in sys/kern/subr_sleepqueue.c > 237 mtx_lock_spin(&sc->sc_lock); > > The above line numbers might be a hair off from head since I'm looking at code > synced last week. > > I'm happy to open a bug on this if that's the desirable course of action, or > to even assist in fixing it, but I wanted to first see if anybody knew about > these already (they didn't show up on the known LORs list on quick perusal) or > if this was simply a case of WITNESS being overly conservative and throwing > false positives. If this belongs on a different list just let me know. I don't believe it is known, and this list is fine. > I'm observing the following two WITNESS LORs being thrown upon boot-up of 10.0 > and I was tracking current, hoping they would go away by 10.1, but it seems > they persist as shown below. I suspect this is because current is being built > with WITNESS on but also with SKIPSPIN on. So these issues are unlikely to > show up for any devs but those who specifically enable WITNESS and disable > SKIPSPIN like myself. At my work we would greatly like to do our debugging > with checking of spin-locking order included and panicing upon LOR detection. > That's not possible with these in existence. However, I was under the impression that a kernel built with WITNESS and without WITNESS_SKIPSPIN would panic on boot on the cnputs_mutx (see, e.g., https://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076864.html). So, (1) I'm surprised you can boot it, and (2) that would explain why no one else has been using it. -Ben From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 01:36:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 302366FE for ; Wed, 19 Nov 2014 01:36:05 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0072.outbound.protection.outlook.com [157.56.111.72]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5B091AC for ; Wed, 19 Nov 2014 01:36:04 +0000 (UTC) Received: from [IPv6:2601:7:9f80:1000::846c] (2601:7:9f80:1000::846c) by DM2PR0801MB667.namprd08.prod.outlook.com (10.242.173.25) with Microsoft SMTP Server (TLS) id 15.1.16.15; Wed, 19 Nov 2014 01:35:55 +0000 Message-ID: <546BF3F5.8030109@panasas.com> Date: Tue, 18 Nov 2014 20:35:49 -0500 From: "Ellis H. Wilson III" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: WITNESS observes 2 LORs on Boot of Release 10.1 References: <546BA9D3.6070007@panasas.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:7:9f80:1000::846c] X-ClientProxiedBy: BL2PR01CA0016.prod.exchangelabs.com (10.141.66.16) To DM2PR0801MB667.namprd08.prod.outlook.com (10.242.173.25) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB667; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB667; X-Forefront-PRVS: 04004D94E2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(189002)(199003)(164054003)(51704005)(479174003)(377454003)(86362001)(92566001)(102836001)(101416001)(50986999)(19580395003)(62966003)(50466002)(64126003)(80316001)(83506001)(15975445006)(92726001)(59896002)(23756003)(47776003)(20776003)(87266999)(46102003)(65956001)(122386002)(65816999)(54356999)(65806001)(64706001)(76176999)(33656002)(99396003)(77096003)(2171001)(87976001)(42186005)(107046002)(120916001)(31966008)(95666004)(4396001)(77156002)(40100003)(36756003)(21056001)(106356001)(105586002)(97736003)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB667; H:[IPv6:2601:7:9f80:1000::846c]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB667; X-OriginatorOrg: panasas.com Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 01:36:05 -0000 On 11/18/2014 05:39 PM, Benjamin Kaduk wrote: > On Tue, 18 Nov 2014, Ellis H. Wilson III wrote: >> I'm observing the following two WITNESS LORs being thrown upon boot-up of 10.0 >> and I was tracking current, hoping they would go away by 10.1, but it seems >> they persist as shown below. I suspect this is because current is being built >> with WITNESS on but also with SKIPSPIN on. So these issues are unlikely to >> show up for any devs but those who specifically enable WITNESS and disable >> SKIPSPIN like myself. At my work we would greatly like to do our debugging >> with checking of spin-locking order included and panicing upon LOR detection. >> That's not possible with these in existence. > > However, I was under the impression that a kernel built with WITNESS and > without WITNESS_SKIPSPIN would panic on boot on the cnputs_mutx (see, > e.g., > https://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076864.html). > So, (1) I'm surprised you can boot it, and (2) that would explain why no > one else has been using it. That's a very interesting thread. I've seen another where a fellow developer suggested just throwing on the WITNESS_SKIPSPIN flag to "solve" the issue. I can't say that I agree with the approach, but I understand. I'd be willing to tackle a bit of WITNESS massaging to help it be instructed about known false positives better, if that's desirable. Why I'm able to boot however, is simple: I haven't enabled a full suite of debugging flags, KDB/DDB being the key ones that cause a panic to occur on a failure like the one I've seen. We originally were seeing the panic so WITNESS in its entirety was shut off. I was asked to try and get that back on-track, so to start I at least wanted to see how many LORs we were dealing with on boot. 2 is apparently that magic number, and maybe 3 if the cputs issue you refer to is still possible to be hit in the 10.1 wild. If nobody has seen these before, I'll try and put together fixes for them. Please somebody speak up if you have seen them or have useful information for me to go on in my patches. Thanks, ellis From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 03:24:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8531AE19 for ; Wed, 19 Nov 2014 03:24:32 +0000 (UTC) Received: from BLU004-OMC2S31.hotmail.com (blu004-omc2s31.hotmail.com [65.55.111.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 404A1EEC for ; Wed, 19 Nov 2014 03:24:31 +0000 (UTC) Received: from BLU179-W50 ([65.55.111.72]) by BLU004-OMC2S31.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 18 Nov 2014 19:24:30 -0800 X-TMN: [Be8QqsRwWgkwXfzNia7inTbJ0mZfducC] X-Originating-Email: [brunolauze@msn.com] Message-ID: From: =?iso-8859-1?B?QnJ1bm8gTGF1euk=?= To: "freebsd-current@freebsd.org" Subject: reboot on wheel Date: Tue, 18 Nov 2014 22:24:29 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 19 Nov 2014 03:24:30.0092 (UTC) FILETIME=[5481B4C0:01D003A8] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 03:24:32 -0000 Is there a reason for this: @wheeluser: rebootOperation not permitted@wheeluser: shutdown -r nowSystem = halt What's the difference? = From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 07:32:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 866569DF for ; Wed, 19 Nov 2014 07:32:26 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B107B52 for ; Wed, 19 Nov 2014 07:32:26 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id rd18so10014iec.36 for ; Tue, 18 Nov 2014 23:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JSWV8nVxqN9ynC8n6B9H4ff08/yrw5P29i8cVzke+io=; b=mmpM2n2K9I2wOA/aTp8nz2ymU0569McAr/d7HESloDkymSMwijiib0GSc+r7qLz1VE F/1Y5JLjKxi8KTi7ojVdviep2WHjNUUzqrMHWC5wOz5XVHFZY9QBXiRoWjlXVhNMassp 075kLLhRbMBbfo5ibuyHMQP5LtEK37zbcFcUAsn02SQC4vyNEiaLytiAYclXmnwZCbil cBDiY2Yf1XUAY13U/ailXNDJuGMyIyeRgHXfsfdb8BFxafceR8zBsrrBhNbazmH+0rtv reCOQizXC6IFmTbDr0X3+I8S5mbRT4m6eYuSM7WvJGcFmsOMsCDBVb8TDSTiBbPpHsxa xKzQ== MIME-Version: 1.0 X-Received: by 10.50.79.166 with SMTP id k6mr8754791igx.0.1416382345603; Tue, 18 Nov 2014 23:32:25 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.7.169 with HTTP; Tue, 18 Nov 2014 23:32:25 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Nov 2014 23:32:25 -0800 X-Google-Sender-Auth: 1H9xmdRMK4mkBiq07DK0H5GzQJE Message-ID: Subject: Re: reboot on wheel From: Kevin Oberman To: =?UTF-8?B?QnJ1bm8gTGF1esOp?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 07:32:26 -0000 On Tue, Nov 18, 2014 at 7:24 PM, Bruno Lauz=C3=A9 wrot= e: > Is there a reason for this: > > @wheeluser: rebootOperation not permitted@wheeluser: shutdown -r > nowSystem halt > What's the difference? > shutdown(8) does a clean shutdown; i.e. it runs all rc.d stop routines. Cleanly stopping some things can be critical things like database shutdown (and many other things). reboot(8) and halt(8) don't run these. They are intended as emergency tools and require root. membership inoperator is all that is required for shutdown. (Didn't realize wheel would do the trick. Or maybe your wheeladm is in the operator group, too.) It frequently surprises me how common it is for even long time FreeBSD users seem to be unaware of this and the danger of reboot/halt(8) for some systems. Of course, for many systems it will make no real difference. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 07:43:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55E36EBD; Wed, 19 Nov 2014 07:43:10 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 43599C7A; Wed, 19 Nov 2014 07:43:10 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2B985C9B; Wed, 19 Nov 2014 07:43:10 +0000 (UTC) Date: Wed, 19 Nov 2014 07:43:06 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, imp@FreeBSD.org, glebius@FreeBSD.org, jhb@FreeBSD.org, ian@FreeBSD.org, kevlo@FreeBSD.org, loos@FreeBSD.org, dchagin@FreeBSD.org, jhibbits@FreeBSD.org, markj@FreeBSD.org, delphij@FreeBSD.org, feld@FreeBSD.org, marcel@FreeBSD.org, br@FreeBSD.org Message-ID: <1678158056.0.1416382990045.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1865 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-Mailman-Approved-At: Wed, 19 Nov 2014 12:23:06 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 07:43:10 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 19:02:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AD8441E; Wed, 19 Nov 2014 19:02:14 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D019C2DB; Wed, 19 Nov 2014 19:02:13 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C88151FE022; Wed, 19 Nov 2014 20:02:09 +0100 (CET) Message-ID: <546CE948.2070105@selasky.org> Date: Wed, 19 Nov 2014 20:02:32 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD Current , np@freebsd.org, Lawrence Stewart , Luigi Rizzo , Adrian Chadd Subject: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 19:02:14 -0000 Hi, The M_FLOWID flag is marked as deprecated in the FreeBSD kernel code and the patch below completely removes it. I suggest we will now be using the "m_pkthdr.rsstype" also known as "M_HASHTYPE" to decide if the flowid value is valid or not. When the "rsstype" is set to "M_HASHTYPE_NONE" the "m_pkthdr.flowid" field is not valid. Else this field contains valid data for both TX and RX direction. Background: =========== The network drivers today use the "rsstype" field only when receiving traffic. After my patch it is also used when sending traffic, and probably we should rename it. The reason for using the rsstype field for transmit, is to avoid introducing another field in the MBUF's packet header in order to steer outgoing traffic into special multiple purpose hardware FIFOs. This new feature should coexist with the existing flowid mechanism, and this is achieved by introducing a new hash type which I've named "M_HASHTYPE_HWRING" in my patch. This type can be selected by upper layers when generating traffic for lower layers, to indicate that the traffic is of a special kind and should have special treatment by the hardware, like rate-limiting. Hardware which doesn't support M_HASHTYPE_HWRING will send out the packets like usual. Patch is available from here: ============================= http://home.selasky.org:8192/m_flowid_removal.diff Comments are appreciated! --HPS From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 19:23:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBDD546B; Wed, 19 Nov 2014 19:23:31 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C5117B3; Wed, 19 Nov 2014 19:23:31 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id ex7so6485990wid.3 for ; Wed, 19 Nov 2014 11:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NeEkqzSpI5ao993Sk/HEJFskSWAIOt2f28GDHw8r+0s=; b=p6a5MO+u81CFVbIg0ZWgCXtpjFQSqJ0p23oA6cetuSRt9jtfeIjwI6kgB92NNzqbvF rr6nE98yLUR2GVXPXERwN7LL74SLnr+MqjpAr2xcKIk9PhurFS/2/iAz485Bq0Fur0hi UMXTaoH/oLTJHag3cmPmzGOcYDKjsA+u7sC+7QO3urk9ukspVY6LkUXHQgh62e2hZtHu eAVBkoyMsgAZu1PfGuAyDNk0Fyr8Tn+UhD1kmpjpWKP5nMlRfjw7+16nC1gHJ81CvnCS yvFWxFPNfcJM8QtEYSeeyPEo27cvpjvkn5hBksb9MnpbxlA50mHPNOOZ4SLpLQJzty0j 29rA== MIME-Version: 1.0 X-Received: by 10.194.47.226 with SMTP id g2mr60171005wjn.68.1416425009945; Wed, 19 Nov 2014 11:23:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 19 Nov 2014 11:23:29 -0800 (PST) In-Reply-To: <546CE948.2070105@selasky.org> References: <546CE948.2070105@selasky.org> Date: Wed, 19 Nov 2014 11:23:29 -0800 X-Google-Sender-Auth: 5m9os84WzKkSgQNPm2I1gIamQAY Message-ID: Subject: Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues] From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Lawrence Stewart , FreeBSD Current , Luigi Rizzo , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 19:23:31 -0000 Hm, how are we going to have the RSS stuff work at the same time as the hardware flow steering stuff you're prototyping? -adrian On 19 November 2014 11:02, Hans Petter Selasky wrote: > Hi, > > The M_FLOWID flag is marked as deprecated in the FreeBSD kernel code and the > patch below completely removes it. I suggest we will now be using the > "m_pkthdr.rsstype" also known as "M_HASHTYPE" to decide if the flowid value > is valid or not. When the "rsstype" is set to "M_HASHTYPE_NONE" the > "m_pkthdr.flowid" field is not valid. Else this field contains valid data > for both TX and RX direction. > > Background: > =========== > > The network drivers today use the "rsstype" field only when receiving > traffic. After my patch it is also used when sending traffic, and probably > we should rename it. > > The reason for using the rsstype field for transmit, is to avoid introducing > another field in the MBUF's packet header in order to steer outgoing traffic > into special multiple purpose hardware FIFOs. This new feature should > coexist with the existing flowid mechanism, and this is achieved by > introducing a new hash type which I've named "M_HASHTYPE_HWRING" in my > patch. This type can be selected by upper layers when generating traffic for > lower layers, to indicate that the traffic is of a special kind and should > have special treatment by the hardware, like rate-limiting. Hardware which > doesn't support M_HASHTYPE_HWRING will send out the packets like usual. > > > Patch is available from here: > ============================= > http://home.selasky.org:8192/m_flowid_removal.diff > > > Comments are appreciated! > > > --HPS From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 19:25:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C48D865A; Wed, 19 Nov 2014 19:25:13 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 825AA7CA; Wed, 19 Nov 2014 19:25:12 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 539AE1FE022; Wed, 19 Nov 2014 20:25:09 +0100 (CET) Message-ID: <546CEEAB.7000207@selasky.org> Date: Wed, 19 Nov 2014 20:25:31 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues] References: <546CE948.2070105@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , FreeBSD Current , Luigi Rizzo , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 19:25:13 -0000 On 11/19/14 20:23, Adrian Chadd wrote: > Hm, how are we going to have the RSS stuff work at the same time as > the hardware flow steering stuff you're prototyping? > Hi Adrain, RSS is only the receive side and its functionality is not touched. I'm just re-using the RSS fields for the transmit side, where the "rsstype" is currently not used. Do you see anything broken in my patch? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 19:30:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDCCC918; Wed, 19 Nov 2014 19:30:27 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F3AF842; Wed, 19 Nov 2014 19:30:27 +0000 (UTC) Received: from [192.168.1.200] (p508F059E.dip0.t-ipconnect.de [80.143.5.158]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 42B3D1C104FC7; Wed, 19 Nov 2014 20:30:24 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues] From: Michael Tuexen In-Reply-To: <546CE948.2070105@selasky.org> Date: Wed, 19 Nov 2014 20:30:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <546CE948.2070105@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Cc: Lawrence Stewart , Adrian Chadd , FreeBSD Current , Luigi Rizzo , np@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 19:30:27 -0000 On 19 Nov 2014, at 20:02, Hans Petter Selasky wrote: > Hi, >=20 > The M_FLOWID flag is marked as deprecated in the FreeBSD kernel code = and the patch below completely removes it. I suggest we will now be = using the "m_pkthdr.rsstype" also known as "M_HASHTYPE" to decide if the = flowid value is valid or not. When the "rsstype" is set to = "M_HASHTYPE_NONE" the "m_pkthdr.flowid" field is not valid. Else this = field contains valid data for both TX and RX direction. >=20 > Background: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The network drivers today use the "rsstype" field only when receiving = traffic. After my patch it is also used when sending traffic, and = probably we should rename it. >=20 > The reason for using the rsstype field for transmit, is to avoid = introducing another field in the MBUF's packet header in order to steer = outgoing traffic into special multiple purpose hardware FIFOs. This new = feature should coexist with the existing flowid mechanism, and this is = achieved by introducing a new hash type which I've named = "M_HASHTYPE_HWRING" in my patch. This type can be selected by upper = layers when generating traffic for lower layers, to indicate that the = traffic is of a special kind and should have special treatment by the = hardware, like rate-limiting. Hardware which doesn't support = M_HASHTYPE_HWRING will send out the packets like usual. >=20 >=20 > Patch is available from here: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > http://home.selasky.org:8192/m_flowid_removal.diff >=20 >=20 > Comments are appreciated! Before finally committing this, drop me a note. All the SCTP changes = need to be ported upstream. Depending on the time and if it is OK for you, I would try to integrate = this upstream and push it down to FreeBSD. Then you can commit the rest. This is simpler for me = than reintegrating your changes upstream... Best regards Michael >=20 >=20 > --HPS > _______________________________________________ > 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" >=20 From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 19:33:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E04EABEE; Wed, 19 Nov 2014 19:33:01 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 841408FE; Wed, 19 Nov 2014 19:33:01 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id b13so1696430wgh.31 for ; Wed, 19 Nov 2014 11:32: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:message-id:subject :from:to:cc:content-type; bh=NjSow/MTM5NHxeyowHQWK7uewTv/Z45O0MpQg6oel6o=; b=Vpb3eWeJCi4BKVoT0qZymonEbpAUyVOGrD/zHqa8nTvVaOnWa5WImf8eETqoVXg8vd BJWBVhfqHapY0TDOaAo9MWcWhSWmUOHxx/c8b6CLrXmrQHCH9qIklK/gk55j+EuKaUnc 9+PCpG8ixf9XpqZKLCTwb/hwvPaelJO3+LZWffoITfGdIvNmgvEtHO9iat61x8Z/+0UJ 080wICZr6OZWJ1hQD4vmKSlb2VvedZBcdb5o3jqPVlfYzoMwU4Gg/NA4wE5H6cPVOGi0 gn+68gDBGMlPB7wwGU5WbSonFfE6EuIPvQg4PVfxUakT6hZT9e42hzzSMYWobjcQDS3q Vrmg== MIME-Version: 1.0 X-Received: by 10.180.83.98 with SMTP id p2mr16252063wiy.20.1416425579817; Wed, 19 Nov 2014 11:32:59 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 19 Nov 2014 11:32:59 -0800 (PST) In-Reply-To: <546CEEAB.7000207@selasky.org> References: <546CE948.2070105@selasky.org> <546CEEAB.7000207@selasky.org> Date: Wed, 19 Nov 2014 11:32:59 -0800 X-Google-Sender-Auth: DF3fJGFOEaTB35A1twa8T-PEJU0 Message-ID: Subject: Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues] From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Lawrence Stewart , FreeBSD Current , Luigi Rizzo , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 19:33:02 -0000 The RSS hash is also used for: * TCP timers, * UDP transmit, and * the transmit path in RSS aware drivers (igb / ixgbe) -adrian On 19 November 2014 11:25, Hans Petter Selasky wrote: > On 11/19/14 20:23, Adrian Chadd wrote: >> >> Hm, how are we going to have the RSS stuff work at the same time as >> the hardware flow steering stuff you're prototyping? >> > > Hi Adrain, > > RSS is only the receive side and its functionality is not touched. I'm just > re-using the RSS fields for the transmit side, where the "rsstype" is > currently not used. > > Do you see anything broken in my patch? > > --HPS > From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 19:35:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00B98D91; Wed, 19 Nov 2014 19:35:27 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B48C991B; Wed, 19 Nov 2014 19:35:27 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 7B87A1FE023; Wed, 19 Nov 2014 20:35:25 +0100 (CET) Message-ID: <546CF114.2050309@selasky.org> Date: Wed, 19 Nov 2014 20:35:48 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues] References: <546CE948.2070105@selasky.org> <546CEEAB.7000207@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , FreeBSD Current , Luigi Rizzo , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 19:35:28 -0000 On 11/19/14 20:32, Adrian Chadd wrote: > The RSS hash is also used for: > > * TCP timers, > * UDP transmit, and > * the transmit path in RSS aware drivers (igb / ixgbe) > I know, and the RSS flowid values are still preserved as before in the receive path. It is just about how you tell the upper/lower layers that there is something in the "m_pkthdr.flowid" which they can use to accelerate traffic. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 20:46:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8C1AE79; Wed, 19 Nov 2014 20:46:06 +0000 (UTC) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 845F9114; Wed, 19 Nov 2014 20:46:06 +0000 (UTC) Received: by mail-yh0-f45.google.com with SMTP id f10so672612yha.18 for ; Wed, 19 Nov 2014 12:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=a/iAXKmlGTLh/JiiXwu+Z8r34jh/tVzuTgXRuw0en5U=; b=1EzRYx1bXNz709nZdLNwXO50StetdD35k6RDKrCL1BKpIu80TJrPGsuwg319SlMzK9 Zvq24PPt5qVkWl3p3kcVYoEY395JT+f8uAWABcBigT+ElInitFD5biEOh2N2KJgxXnzl oHYttjPc23P0C/Aed4sG3WwsQ6pUI1tgk55bdRdNKTRgvN1CeNI6AHmHd8XQCYXjstU2 kcvgiJlbQPru9ZBr8N0LWjWEPKuaekSaqVFfZQjfD7qCW193q1D8w7R1ZYDXEkDJfiIe ar82J8B0mg1CpqvCaRkRL82Zxt0QS60VAlMvfoduuVe+LCCyLA6JthXx+2cfMtQSl37A /9pg== MIME-Version: 1.0 X-Received: by 10.170.164.87 with SMTP id g84mr6511861ykd.10.1416429965730; Wed, 19 Nov 2014 12:46:05 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Wed, 19 Nov 2014 12:46:05 -0800 (PST) In-Reply-To: <546CE948.2070105@selasky.org> References: <546CE948.2070105@selasky.org> Date: Wed, 19 Nov 2014 12:46:05 -0800 X-Google-Sender-Auth: EHptYr0sw7MAE2hBzb5NKdY83Cs Message-ID: Subject: Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues] From: "K. Macy" To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Lawrence Stewart , Adrian Chadd , FreeBSD Current , Luigi Rizzo , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 20:46:07 -0000 Hi Hans, It mostly looks fine, but it's a large change and there are some places in the patch where it isn't clear that the right thing is being done by looking at the patch alone. Please give us some time to review. Thanks. -K On Wed, Nov 19, 2014 at 11:02 AM, Hans Petter Selasky wrote: > Hi, > > The M_FLOWID flag is marked as deprecated in the FreeBSD kernel code and the > patch below completely removes it. I suggest we will now be using the > "m_pkthdr.rsstype" also known as "M_HASHTYPE" to decide if the flowid value > is valid or not. When the "rsstype" is set to "M_HASHTYPE_NONE" the > "m_pkthdr.flowid" field is not valid. Else this field contains valid data > for both TX and RX direction. > > Background: > =========== > > The network drivers today use the "rsstype" field only when receiving > traffic. After my patch it is also used when sending traffic, and probably > we should rename it. > > The reason for using the rsstype field for transmit, is to avoid introducing > another field in the MBUF's packet header in order to steer outgoing traffic > into special multiple purpose hardware FIFOs. This new feature should > coexist with the existing flowid mechanism, and this is achieved by > introducing a new hash type which I've named "M_HASHTYPE_HWRING" in my > patch. This type can be selected by upper layers when generating traffic for > lower layers, to indicate that the traffic is of a special kind and should > have special treatment by the hardware, like rate-limiting. Hardware which > doesn't support M_HASHTYPE_HWRING will send out the packets like usual. > > > Patch is available from here: > ============================= > http://home.selasky.org:8192/m_flowid_removal.diff > > > Comments are appreciated! > > > --HPS > _______________________________________________ > 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 Wed Nov 19 21:18:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55429C7E; Wed, 19 Nov 2014 21:18:31 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CBAA6DD; Wed, 19 Nov 2014 21:18:31 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id tp5so1454490ieb.37 for ; Wed, 19 Nov 2014 13:18:30 -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=3YkZhWBxM72ggmCsYjTTeWXJnPCtLBVDzQ0F82+WBUE=; b=l1DCUOj6olpai79pPxE5HkAjM2kaXz7B6txAx+nADp/6h5Ht0XPQ2bthRy6j04J7Jf myyZ7DqmrqThxuY/+t5OpBOzkrllXxSolVe0XscWb81tSFRLZmM9J/oxcWOrs58VgiDT WP44exXr2aBGCd6VDQetMA+qX1stTCk9yOrzeVO2z/m1nOzhM0UvGQtC6E+A5y4XK9pa IcFAvESLA+WiOiJflx6iDLqIDCcvmr5/787p2jF6qP0gdjVC3WmT1JWwo7525S2HPlJI Atrn+rswmWJ1y0vHLYx7ZS22zbg7lAH3IDRgndHFCHvDvwrKtSXEbHLTgSEBw915sM31 WCqA== MIME-Version: 1.0 X-Received: by 10.50.28.14 with SMTP id x14mr5643456igg.39.1416431910496; Wed, 19 Nov 2014 13:18:30 -0800 (PST) Received: by 10.107.10.31 with HTTP; Wed, 19 Nov 2014 13:18:30 -0800 (PST) In-Reply-To: <20141118072118.GA1883@raichu> References: <52372362.10506@bitfrost.no> <20130916171016.GA1509@charmander> <20141118072118.GA1883@raichu> Date: Wed, 19 Nov 2014 16:18:30 -0500 Message-ID: Subject: Re: General Protection Fault in prelist_remove() From: Ryan Stone To: Mark Johnston Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 21:18:31 -0000 On Tue, Nov 18, 2014 at 2:21 AM, Mark Johnston wrote: > https://people.freebsd.org/~markj/patches/nd6_dad_races.diff I haven't had the chance to study the patch in detail, but I can confirm that it at least fixes the crashes that I was seeing earlier. From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 21:34:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EA3092D; Wed, 19 Nov 2014 21:34:14 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CEC3950; Wed, 19 Nov 2014 21:34:13 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 09B111FE022; Wed, 19 Nov 2014 22:34:04 +0100 (CET) Message-ID: <546D0CE3.602@selasky.org> Date: Wed, 19 Nov 2014 22:34:27 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "K. Macy" Subject: Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues] References: <546CE948.2070105@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , Adrian Chadd , FreeBSD Current , Luigi Rizzo , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 21:34:14 -0000 On 11/19/14 21:46, K. Macy wrote: > Hi Hans, > > It mostly looks fine, but it's a large change and there are some > places in the patch where it isn't clear that the right thing is being > done by looking at the patch alone. Please give us some time to > review. > No problem. Do you think you need more than a week? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 21:55:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D26AFDEF; Wed, 19 Nov 2014 21:55:08 +0000 (UTC) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C871BC9; Wed, 19 Nov 2014 21:55:08 +0000 (UTC) Received: by mail-yh0-f44.google.com with SMTP id c41so732177yho.31 for ; Wed, 19 Nov 2014 13:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PvbXOsc6Gaqs4Fs6fLpqNEWqteL35nmtailwmeeGqNw=; b=Fb4SPBhkuo1QM5XihftWNmqo+AdL7i2ErYLyqxHfK9x/DyTDPPT+d4zpCqzGukzp+y h4v8+RyTBS88RBBbz0oQJbUZpOEpqYbdjMEYPoZJ2MjxA2XcKK5/pspdqj3eCaoVA5uU u117EYQTLGQ5nEz8IoP6lHNwSFiKCNKpcdjxYB6wIzGmi31jjoan1wBMV73au8wE+c+I 8w3IiLSP4A0wWrpvdWfqiNr8NCfkegn8pY8kkwb1fg7JteKtGzB+BIU5DzkTV+//Tm16 l2BTAuqns/rvpSI++RwKc/4Jo3cPS+X9VQevJ/099Dh6B7/AlMRJ+Mynzbo/VQkwdbyT PVrg== MIME-Version: 1.0 X-Received: by 10.170.233.6 with SMTP id z6mr14156329ykf.101.1416434107742; Wed, 19 Nov 2014 13:55:07 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Wed, 19 Nov 2014 13:55:07 -0800 (PST) In-Reply-To: <546D0CE3.602@selasky.org> References: <546CE948.2070105@selasky.org> <546D0CE3.602@selasky.org> Date: Wed, 19 Nov 2014 13:55:07 -0800 X-Google-Sender-Auth: ifaGTCfY3uro9K_aoZBdgaZU7eg Message-ID: Subject: Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues] From: "K. Macy" To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Lawrence Stewart , Adrian Chadd , FreeBSD Current , Luigi Rizzo , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 21:55:08 -0000 On Wed, Nov 19, 2014 at 1:34 PM, Hans Petter Selasky wrote: > On 11/19/14 21:46, K. Macy wrote: >> >> Hi Hans, >> >> It mostly looks fine, but it's a large change and there are some >> places in the patch where it isn't clear that the right thing is being >> done by looking at the patch alone. Please give us some time to >> review. >> > > No problem. Do you think you need more than a week? (Didn't CC the others last time) I probably won't. But I speak only for myself. However, I don't think it's fair to ask you to wait more than two. I've been on the other end of that too many times myself. -K From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 17:06:12 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AC5E630; Thu, 20 Nov 2014 17:06:12 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1F1D885; Thu, 20 Nov 2014 17:06:11 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAKH78gS071061; Thu, 20 Nov 2014 09:07:08 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD STABLE" , "FreeBSD CURRENT" From: "Chris H" Subject: send-pr must live Date: Thu, 20 Nov 2014 09:07:08 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 17:06:12 -0000 Greetings, While I recognize that send-pr has pretty much become useless, with the advent of bugzilla, being made the new "official" FreeBSD bug reporting system. I really miss send-pr, and was hoping I could revive it, eg; integrate it with bugzilla. I had even contemplated adding a feature that would allow it to also work with local port/system building structures people often use to build, and maintain FreeBSD. Any objections to my reviving send-pr? Thank you for all your time, and consideration. --Chris From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 17:25:51 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 870C114A; Thu, 20 Nov 2014 17:25:51 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49254B69; Thu, 20 Nov 2014 17:25:51 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wp4so2566793obc.39 for ; Thu, 20 Nov 2014 09:25:50 -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=EygNMTTfIMilhMwDjnDg4usPlC8VZ1/UbzjwK45FDJ4=; b=PmtBR1pZKGlC2FyjZA4AIJta8N7aNBUYDFwM4H3rvXVzVlpivIEb/wVwCnui8Ba+ig z/ZQjDGEea7EwolOGU2JWhF/pKGgUFLIiyMUuy2GudOZknbRMeVEiqjGtypaKRuJfh2b 8pb/Jt5MOceIwsyGdyynHanriX7vuw/PM5YD72ySy5jbFHBb/mTy4K4dUjX9HoxWAQDm drPAWFSHMWwqEO0IoX7SXkXqVtb3btUuKRj6lq2GVkHQ7Za/fYmR6B9NFKnD109+KF6i TvSclV5za+Otl/BUeHXADuBx5eXeQbBmOzBZfdxrRMZWH9f7ZW3bpoIVnDF/FVNYUci/ mxfw== MIME-Version: 1.0 X-Received: by 10.60.161.115 with SMTP id xr19mr42541085oeb.8.1416504350626; Thu, 20 Nov 2014 09:25:50 -0800 (PST) Received: by 10.202.59.133 with HTTP; Thu, 20 Nov 2014 09:25:50 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Nov 2014 23:25:50 +0600 Message-ID: Subject: Re: send-pr must live From: Muhammad Moinur Rahman <5u623l20@gmail.com> To: Chris H Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers@freebsd.org, FreeBSD STABLE , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 17:25:51 -0000 Nice idea. However I am working on reviving porttools to migrate within bugzilla system. Maybe we can share some ideas. BR, Muhammad On Thu, Nov 20, 2014 at 11:07 PM, Chris H wrote: > Greetings, > While I recognize that send-pr has pretty much > become useless, with the advent of bugzilla, being made > the new "official" FreeBSD bug reporting system. I really > miss send-pr, and was hoping I could revive it, eg; > integrate it with bugzilla. I had even contemplated adding > a feature that would allow it to also work with local > port/system building structures people often use to build, > and maintain FreeBSD. > Any objections to my reviving send-pr? > > Thank you for all your time, and consideration. > > --Chris > > > _______________________________________________ > 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 20 17:39:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD5609EC; Thu, 20 Nov 2014 17:39:55 +0000 (UTC) Received: from gwave1.banym.de (gwave1.banym.de [212.72.74.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90724CED; Thu, 20 Nov 2014 17:39:55 +0000 (UTC) Received: from tesla.banym.local (dslb-084-057-003-046.084.057.pools.vodafone-ip.de [84.57.3.46]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by gwave1.banym.de (Postfix) with ESMTP id 3A8A41C003; Thu, 20 Nov 2014 18:39:18 +0100 (CET) Message-ID: <546E2752.3060609@banym.de> Date: Thu, 20 Nov 2014 18:39:30 +0100 From: Dominik Zajac User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: UEFI Boot fails if legacy mode is disabled completely in settings on ASUS Z87 board Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Banym-MailScanner-Information: Please contact the ISP for more information X-Banym-MailScanner-ID: 3A8A41C003.A327C X-Banym-MailScanner: Found to be clean X-Banym-MailScanner-From: banym@banym.de X-Spam-Status: No X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 17:39:55 -0000 Hi, on an ASUS Z87 Pro board, the UEFI boot media only work if the CSM mode in the Settings of the UEFI are set to "both". This means it is using UEFI boot and CSM mode for legacy booting. If I disable the legacy CSM and configure "UEFI only", the UEFI loader still loads but when it comes to load the kernel it just stops and the system is frozen at that point. Same with 10.1 and 11-current USB install media. The system now has FreeBSD 10.1 on one disc installed with UEFI mode and boots with it as long as the CSM compatibility mode is enabled. Has someone a similar problem or behaviour? This leads me to the next question. How can I debug or get more information what fails at this stage of the boot process? I would like to provide more detailed information and help to debug to hunt this bug down. Regards, Dominik From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 17:39:54 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E029B9EB; Thu, 20 Nov 2014 17:39:54 +0000 (UTC) Received: from mx.waitman.net (mx.waitman.net [136.0.16.173]) by mx1.freebsd.org (Postfix) with ESMTP id C7CA4CEC; Thu, 20 Nov 2014 17:39:54 +0000 (UTC) Received: by mx.waitman.net (Postfix, from userid 2) id 509ED435B6; Thu, 20 Nov 2014 09:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waitman.net; s=default; t=1416505216; bh=fno9McsvKYOX20BlnMd4YxNMDIpEMIfDS5T9tUfat3M=; h=In-Reply-To:References:Date:Subject:From:To:Cc:Reply-To; b=F6cjN4u0ljQ+QVyA0Uu6nTDbskH1HRNY7Aq/hkHi8B70pD7tBRzl4sasquIPUp771 hf9CwazOl2yhqVXHMnIX9emmxxIfHSxdzMlYj0szZCyyVdvJulZan4svN7xvQsj7k1 qvl99XzOtLPxzagkY9v54GA8QJZeQazvKJfzEAMc= Received: from 70.90.171.37 by mx.waitman.net with HTTP; Thu, 20 Nov 2014 09:40:16 -0800 Message-ID: In-Reply-To: References: Date: Thu, 20 Nov 2014 09:40:16 -0800 Subject: Re: send-pr must live From: "Waitman Gobble" To: "Muhammad Moinur Rahman" <5u623l20@gmail.com> Reply-To: waitman@waitman.net User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 20 Nov 2014 17:55:09 +0000 Cc: freebsd-hackers@freebsd.org, FreeBSD STABLE , FreeBSD CURRENT , Chris H X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 17:39:55 -0000 On Thu, November 20, 2014 9:25 am, Muhammad Moinur Rahman wrote: > Nice idea. However I am working on reviving porttools to migrate within > bugzilla system. Maybe we can share some ideas. > > BR, > Muhammad > > > On Thu, Nov 20, 2014 at 11:07 PM, Chris H wrote: > > >> Greetings, >> While I recognize that send-pr has pretty much >> become useless, with the advent of bugzilla, being made the new >> "official" FreeBSD bug reporting system. I really >> miss send-pr, and was hoping I could revive it, eg; integrate it with >> bugzilla. I had even contemplated adding a feature that would allow it >> to also work with local port/system building structures people often use >> to build, and maintain FreeBSD. Any objections to my reviving send-pr? >> >> >> Thank you for all your time, and consideration. >> >> >> --Chris >> >> >> >> _______________________________________________ >> 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" >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > I liked using send-pr. It looks like Bugzilla 5.0 will have a native REST API but current versions use plugin. Also I believe Bugzilla supports an email interface so it could be possible to keep send-pr as a shell script. -- Waitman Gobble Los Altos California USA +1.510-830-7975 From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 18:09:02 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FD37BC9; Thu, 20 Nov 2014 18:09:02 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 406D4E4; Thu, 20 Nov 2014 18:09:02 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAKI9xbB088551; Thu, 20 Nov 2014 10:09:59 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "Muhammad Moinur Rahman" <5u623l20@gmail.com>, "Waitman Gobble" In-Reply-To: References: , From: "Chris H" Subject: Re: send-pr must live Date: Thu, 20 Nov 2014 10:09:59 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, FreeBSD STABLE , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 18:09:02 -0000 On Thu, 20 Nov 2014 09:40:16 -0800 "Waitman Gobble" wrote > On Thu, November 20, 2014 9:25 am, Muhammad Moinur Rahman wrote: > > Nice idea. However I am working on reviving porttools to migrate within > > bugzilla system. Maybe we can share some ideas. > > > > BR, > > Muhammad > > > > > > On Thu, Nov 20, 2014 at 11:07 PM, Chris H wrote: > > > > > >> Greetings, > >> While I recognize that send-pr has pretty much > >> become useless, with the advent of bugzilla, being made the new > >> "official" FreeBSD bug reporting system. I really > >> miss send-pr, and was hoping I could revive it, eg; integrate it with > >> bugzilla. I had even contemplated adding a feature that would allow it > >> to also work with local port/system building structures people often use > >> to build, and maintain FreeBSD. Any objections to my reviving send-pr? > >> > >> > >> Thank you for all your time, and consideration. > >> > >> > >> --Chris > >> > >> > >> > >> _______________________________________________ > >> 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" > >> > >> > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > > I liked using send-pr. It looks like Bugzilla 5.0 will have a native REST > API but current versions use plugin. Also I believe Bugzilla supports an > email interface so it could be possible to keep send-pr as a shell script. Indeed. It is perfectly inclined to use email. Which makes [initial] integration perfectly *trivial*. :) As to it having been shell based. While there's nothing wrong with that at all, in fact it's advantageous in many respects. I was toying with the idea of perhaps converting (augmenting) it to being Perl based, by way of a statically linked mini-perl interpreter. I thought it would better *empower* it, also providing for a more "user friendly" dialog. But, like I said; just *toying* with the idea. :) --Chris > > > > -- > Waitman Gobble > Los Altos California USA > +1.510-830-7975 From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 18:26:10 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB9553D4; Thu, 20 Nov 2014 18:26:10 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39C7832E; Thu, 20 Nov 2014 18:26:10 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id h11so6304596wiw.15 for ; Thu, 20 Nov 2014 10:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wCxDUrA2UG1Gz/Xf3+YNp8drUcPvKUoWR3aNQlAT4dI=; b=dLSqhxQIQvalJhiG6YoPQ5KdXyWhUPhqpTibzKx4eCMSizyNd6nyo3D1/i1YnMpGoL xh+KFamFCNMaSJwK8sXwJKG3tWHMmbtvQ7YChNHt5xM+WQxB4a5nCPwFNbexmyE/dNxw Qf/01HPbDR0Wx5csrbbU1+7ItOu9d3E1fBTtDnVQ8itrhB9NhtTcUPUnNvP1sgjNQxGp dpQ9aB69jGmOmGTT5n0UHj/U494BNQIfjnqioAKi54z69BTYeXX7d7Xnb30yztfOgCFp MhlL73As6ho5/RsaVzJ0OKaR/XXOw+6vzT4qK/1QzYtHO6FZlwLGB8OXR9IIAtktKa7t +tbw== MIME-Version: 1.0 X-Received: by 10.194.47.226 with SMTP id g2mr69924715wjn.68.1416507968412; Thu, 20 Nov 2014 10:26:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 20 Nov 2014 10:26:08 -0800 (PST) In-Reply-To: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> References: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> Date: Thu, 20 Nov 2014 10:26:08 -0800 X-Google-Sender-Auth: RNO5kzpdqgp6onjOgQ11Wzg8FtM Message-ID: Subject: Re: send-pr must live From: Adrian Chadd To: Chris H Content-Type: text/plain; charset=UTF-8 Cc: Muhammad Moinur Rahman <5u623l20@gmail.com>, "freebsd-hackers@freebsd.org" , Waitman Gobble , FreeBSD CURRENT , FreeBSD STABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 18:26:10 -0000 Hi! If you'd like to make it work then please do - just make sure you check with the bugteam about it. I'm worried that you're signing them up for more work (dealing with email spam again) which I /think/ they don't have to deal with now. -adrian On 20 November 2014 10:09, Chris H wrote: > On Thu, 20 Nov 2014 09:40:16 -0800 "Waitman Gobble" wrote > >> On Thu, November 20, 2014 9:25 am, Muhammad Moinur Rahman wrote: >> > Nice idea. However I am working on reviving porttools to migrate within >> > bugzilla system. Maybe we can share some ideas. >> > >> > BR, >> > Muhammad >> > >> > >> > On Thu, Nov 20, 2014 at 11:07 PM, Chris H wrote: >> > >> > >> >> Greetings, >> >> While I recognize that send-pr has pretty much >> >> become useless, with the advent of bugzilla, being made the new >> >> "official" FreeBSD bug reporting system. I really >> >> miss send-pr, and was hoping I could revive it, eg; integrate it with >> >> bugzilla. I had even contemplated adding a feature that would allow it >> >> to also work with local port/system building structures people often use >> >> to build, and maintain FreeBSD. Any objections to my reviving send-pr? >> >> >> >> >> >> Thank you for all your time, and consideration. >> >> >> >> >> >> --Chris >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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" >> >> >> >> >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > >> > >> >> I liked using send-pr. It looks like Bugzilla 5.0 will have a native REST >> API but current versions use plugin. Also I believe Bugzilla supports an >> email interface so it could be possible to keep send-pr as a shell script. > Indeed. It is perfectly inclined to use email. Which makes > [initial] integration perfectly *trivial*. :) > As to it having been shell based. While there's nothing wrong with > that at all, in fact it's advantageous in many respects. I was toying > with the idea of perhaps converting (augmenting) it to being Perl > based, by way of a statically linked mini-perl interpreter. I thought > it would better *empower* it, also providing for a more "user friendly" > dialog. But, like I said; just *toying* with the idea. :) > > --Chris > >> >> >> >> -- >> Waitman Gobble >> Los Altos California USA >> +1.510-830-7975 > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 18:59:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D7A7216; Thu, 20 Nov 2014 18:59:43 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id 68483A70; Thu, 20 Nov 2014 18:59:43 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NFC00M1XNIN4N00@hades.sorbs.net>; Thu, 20 Nov 2014 10:04:01 -0800 (PST) Message-id: <546E2C06.7040606@sorbs.net> Date: Thu, 20 Nov 2014 18:59:34 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Dominik Zajac Subject: Re: UEFI Boot fails if legacy mode is disabled completely in settings on ASUS Z87 board References: <546E2752.3060609@banym.de> In-reply-to: <546E2752.3060609@banym.de> X-Mailman-Approved-At: Thu, 20 Nov 2014 19:08:05 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 18:59:43 -0000 Dominik Zajac wrote: > Hi, > > on an ASUS Z87 Pro board, the UEFI boot media only work if the CSM mode > in the Settings of the UEFI are set to "both". This means it is using > UEFI boot and CSM mode for legacy booting. > > If I disable the legacy CSM and configure "UEFI only", the UEFI loader > still loads but when it comes to load the kernel it just stops and the > system is frozen at that point. Same with 10.1 and 11-current USB > install media. > > The system now has FreeBSD 10.1 on one disc installed with UEFI mode and > boots with it as long as the CSM compatibility mode is enabled. > > Has someone a similar problem or behaviour? > Same Mobo, same problem here. > This leads me to the next question. How can I debug or get more > information what fails at this stage of the boot process? I would like > to provide more detailed information and help to debug to hunt this bug > down. > Sorry - I can't help here, I don't have time to debug as too busy fixing broken systems from Sept 1 changes. -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 19:22:10 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF54CAC4; Thu, 20 Nov 2014 19:22:10 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87DF2ED9; Thu, 20 Nov 2014 19:22:10 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAKJN71j009325; Thu, 20 Nov 2014 11:23:07 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Adrian Chadd In-Reply-To: References: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net>, From: "Chris H" Subject: Re: send-pr must live Date: Thu, 20 Nov 2014 11:23:07 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <9898ebc3c470ac0c6e3df470c6028e90@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: Muhammad Moinur Rahman <5u623l20@gmail.com>, "freebsd-hackers@freebsd.org" , Waitman Gobble , FreeBSD CURRENT , FreeBSD STABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 19:22:11 -0000 On Thu, 20 Nov 2014 10:26:08 -0800 Adrian Chadd wrote > On 20 November 2014 10:09, Chris H wrote: > > On Thu, 20 Nov 2014 09:40:16 -0800 "Waitman Gobble" > > wrote > > >> On Thu, November 20, 2014 9:25 am, Muhammad Moinur Rahman wrote: > >> > Nice idea. However I am working on reviving porttools to migrate within > >> > bugzilla system. Maybe we can share some ideas. > >> > > >> > BR, > >> > Muhammad > >> > > >> > > >> > On Thu, Nov 20, 2014 at 11:07 PM, Chris H > >> > wrote: >> > > >> > > >> >> Greetings, > >> >> While I recognize that send-pr has pretty much > >> >> become useless, with the advent of bugzilla, being made the new > >> >> "official" FreeBSD bug reporting system. I really > >> >> miss send-pr, and was hoping I could revive it, eg; integrate it with > >> >> bugzilla. I had even contemplated adding a feature that would allow it > >> >> to also work with local port/system building structures people often > >> >> use to build, and maintain FreeBSD. Any objections to my reviving > >> >> send-pr? >> >> > >> >> > >> >> Thank you for all your time, and consideration. > >> >> > >> >> > >> >> --Chris > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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" > >> >> > >> >> > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to > >> > "freebsd-current-unsubscribe@freebsd.org" >> > > >> > > >> > >> I liked using send-pr. It looks like Bugzilla 5.0 will have a native REST > >> API but current versions use plugin. Also I believe Bugzilla supports an > >> email interface so it could be possible to keep send-pr as a shell script. > > Indeed. It is perfectly inclined to use email. Which makes > > [initial] integration perfectly *trivial*. :) > > As to it having been shell based. While there's nothing wrong with > > that at all, in fact it's advantageous in many respects. I was toying > > with the idea of perhaps converting (augmenting) it to being Perl > > based, by way of a statically linked mini-perl interpreter. I thought > > it would better *empower* it, also providing for a more "user friendly" > > dialog. But, like I said; just *toying* with the idea. :) > > > > --Chris > > > >> > >> > >> > >> -- > >> Waitman Gobble > >> Los Altos California USA > >> +1.510-830-7975 > > > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Hi! > > If you'd like to make it work then please do - just make sure you > check with the bugteam about it. I'm worried that you're signing them > up for more work (dealing with email spam again) which I /think/ they > don't have to deal with now. > > > -adrian > > Thanks for the reply adrian. Count on it. I hate SPAM more than the bugteam! And as a result, I have some _very_ good strategies already employed. So "keeping things clean" should prove a trivial matter. I've already started the process. I'm loading up a copy of devel/bugzilla44 now. Thanks again, for your reply, Adrian -- even if it was an evil top post. ;) --Chris > _______________________________________________ > 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 20 20:14:41 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A140C7A; Thu, 20 Nov 2014 20:14:41 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11C036B3; Thu, 20 Nov 2014 20:14:41 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id eu11so3191786pac.8 for ; Thu, 20 Nov 2014 12:14:40 -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:from:subject:date:to; bh=ImO27GboyaxhKuKi73WN55bL7CVZzoWjtXXMm6CTE40=; b=gBswdy/tQ6lCFxHfN+OJQNAmh5OqLor7Bfa26uJIhYueV9fhOX/it6YQTtk0qOTegL M5eq8yOX1mnOzRweq94RTLggLWsGWsOVsp3KXTjydXw9tMwuoDIO5TYqvoeMeMTrdtcK cAg+UpuzWKpVMb9C5AGhz8GD5AZrH9YbTj/FQAIRdtg10mqguehXoewr5izXTPph4PBb i28zNvLWFGVaeLi2ORabKuuo6ZrrHbhWIoyQtj80WFgzYpdVJ9GuvrP0rFmjVWmIreNv 7nbpMe8AhJDKDweWayvZ/Ust71PEyA9aqfdCyCc1uOXRmarpMBPtDdn+gf4cmARhe+2N DM7Q== X-Received: by 10.68.194.199 with SMTP id hy7mr205644pbc.17.1416514480586; Thu, 20 Nov 2014 12:14:40 -0800 (PST) Received: from [10.30.20.156] (mobile-166-171-120-059.mycingular.net. [166.171.120.59]) by mx.google.com with ESMTPSA id fl2sm2842043pab.0.2014.11.20.12.14.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Nov 2014 12:14:39 -0800 (PST) References: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> <9898ebc3c470ac0c6e3df470c6028e90@ultimatedns.net> Mime-Version: 1.0 (1.0) In-Reply-To: <9898ebc3c470ac0c6e3df470c6028e90@ultimatedns.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: send-pr must live Date: Thu, 20 Nov 2014 12:14:35 -0800 To: Chris H Cc: Adrian Chadd , FreeBSD STABLE , FreeBSD CURRENT , "freebsd-hackers@freebsd.org" , Muhammad Moinur Rahman <5u623l20@gmail.com>, Waitman Gobble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 20:14:41 -0000 Please take a look at python-bugzilla (you'll need to install setuptools fro= m ports, then run "easy_install python-bugzilla"). If that interface is suff= icient and easy enough to use, I'll document some quick recipes for how to u= se it on the wiki and import it as a port. Cheers!= From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 21:50:23 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 581E5A08; Thu, 20 Nov 2014 21:50:23 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 285B118E; Thu, 20 Nov 2014 21:50:23 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAKLpJeE058720; Thu, 20 Nov 2014 13:51:20 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Garrett Cooper In-Reply-To: References: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> <9898ebc3c470ac0c6e3df470c6028e90@ultimatedns.net>, From: "Chris H" Subject: Re: send-pr must live Date: Thu, 20 Nov 2014 13:51:20 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <83bde838aaa0d084c046e11363f41d59@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: Adrian Chadd , FreeBSD STABLE , FreeBSD CURRENT , "freebsd-hackers@freebsd.org" , Muhammad Moinur Rahman <5u623l20@gmail.com>, Waitman Gobble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 21:50:23 -0000 On Thu, 20 Nov 2014 12:14:35 -0800 Garrett Cooper wrote > Please take a look at python-bugzilla Hmm... no sign of it. Do you possibly mean; py-bugzillatools? Just groping. > (you'll need to install setuptools from > ports, then run "easy_install python-bugzilla"). If that interface is > sufficient and easy enough to use, I'll document some quick recipes for how > to use it on the wiki and import it as a port. > > Cheers! --Chris From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 23:10:31 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 299B14DA; Thu, 20 Nov 2014 23:10:31 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E04A6C6C; Thu, 20 Nov 2014 23:10:30 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id y20so3828228ier.18 for ; Thu, 20 Nov 2014 15:10:30 -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=UTXX32UakTY9K51pmn6MuUjWXVzuYawmydeBw/4c4fU=; b=PtUtubZLP5ei385Pg4Fkh076mM5UupsolmOzOMpvNQefaGl/4xIsL4/ESRmt/kLM5E JLeJxEczjJ0RVVMHeNBkOLNslYBQYDQ/7qljhuafNMMop+D/ptgzRu6aJyTKv+vJOsMT 3BTkvwcbgJWoF9xhD3auiekeCzL8WpnUVpLUjLasXcfemc+iSkBOg6N1ee0sXNgjTWwy 4LEKyViwaBPoLAbtN7puKLQsOLJXIqgUV0rq3RiTLHOt3f/daFWmaM08yXyKNeA9T2Uo MZh89zIvmJMRBN86S+oLTXJrbLor3vcrY7W8EPqHePdVic0y5AXTP5KjyBa/IGBk17pw AIAg== MIME-Version: 1.0 X-Received: by 10.50.39.80 with SMTP id n16mr587055igk.49.1416525030159; Thu, 20 Nov 2014 15:10:30 -0800 (PST) Received: by 10.50.42.162 with HTTP; Thu, 20 Nov 2014 15:10:30 -0800 (PST) In-Reply-To: <83bde838aaa0d084c046e11363f41d59@ultimatedns.net> References: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> <9898ebc3c470ac0c6e3df470c6028e90@ultimatedns.net> <83bde838aaa0d084c046e11363f41d59@ultimatedns.net> Date: Thu, 20 Nov 2014 15:10:30 -0800 Message-ID: Subject: Re: send-pr must live From: NGie Cooper To: Chris H Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , FreeBSD STABLE , FreeBSD CURRENT , "freebsd-hackers@freebsd.org" , Muhammad Moinur Rahman <5u623l20@gmail.com>, Waitman Gobble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 23:10:31 -0000 On Thu, Nov 20, 2014 at 1:51 PM, Chris H wrote: > On Thu, 20 Nov 2014 12:14:35 -0800 Garrett Cooper wrote > >> Please take a look at python-bugzilla > Hmm... no sign of it. Do you possibly mean; py-bugzillatools? > Just groping. All the hints were in my original reply... [root@wkstn-lnx-ngie ngie]# easy_install python-bugzilla Searching for python-bugzilla Reading https://pypi.python.org/simple/python-bugzilla/ Best match: python-bugzilla 1.1.0 Downloading https://pypi.python.org/packages/source/p/python-bugzilla/python-bugzilla-1.1.0.tar.gz#md5=c95befd1fecad21f742beaa8180538c0 Processing python-bugzilla-1.1.0.tar.gz Writing /tmp/easy_install-lR6lpK/python-bugzilla-1.1.0/setup.cfg Running python-bugzilla-1.1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-lR6lpK/python-bugzilla-1.1.0/egg-dist-tmp-yjKZ_J zip_safe flag not set; analyzing archive contents... Adding python-bugzilla 1.1.0 to easy-install.pth file Installing bugzilla script to /usr/bin Installed /usr/lib/python2.7/site-packages/python_bugzilla-1.1.0-py2.7.egg Processing dependencies for python-bugzilla Finished processing dependencies for python-bugzilla From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 01:20:06 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6425B2AE for ; Fri, 21 Nov 2014 01:20:06 +0000 (UTC) Received: from rx7120.rapidns.com (rx7120.rapidns.com [206.183.111.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C1A6B39 for ; Fri, 21 Nov 2014 01:20:05 +0000 (UTC) Received: from emjhomes by rx7120.rapidns.com with local (Exim 4.84) (envelope-from ) id 1XrctE-00016u-Vi for current@freebsd.org; Fri, 21 Nov 2014 06:50:01 +0530 To: current@freebsd.org Subject: Check your recent activity in[Paypal] X-PHP-Script: www.emjhomes.in/tmp/3/SCRIPTE HOTMAIL.php for 105.157.216.249 X-Mailer: Microsoft Office Outlook, Build 17.551210 From: current@freebsd.org Message-Id: Date: Fri, 21 Nov 2014 06:50:00 +0530 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rx7120.rapidns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [624 635] / [47 12] X-AntiAbuse: Sender Address Domain - rx7120.rapidns.com X-Get-Message-Sender-Via: rx7120.rapidns.com: authenticated_id: emjhomes/only user confirmed/virtual account not confirmed MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 01:20:06 -0000 This is an automated email, please do not reply. Informations about your account : As part of our security measures, we regularty check the work of the screen PayPal. We have requested information from you for the following reason : ccess to your account. Once connected,follow the steps to activate your account. We appereciate your understanding as we work to ensure security. [1]Click here to Confirm Your Account Information. Departmen review PayPal accounts PayPal FSA Register Number:15825003750 PayPal Email ID PP190420 [2]Privacy Policy Copyright 1999 - 2014 PayPal.All rights reserved. References 1. http://www.gireeshsharmaphotography.com/Confirmation-account/Update 2. file:///tmp/tmpzKBD3S.html From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 06:10:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 992E68A6 for ; Fri, 21 Nov 2014 06:10:36 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EA84AD7 for ; Fri, 21 Nov 2014 06:10:36 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id i17so3304622qcy.21 for ; Thu, 20 Nov 2014 22:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=qx4cS1915L7uU1Id72xPO5Iimz7t5u2vX/95lz5SXmU=; b=JLlowLcD6Y/sURTvNH+ZlZU/WsZQfsH2JUqP1FGez0JOQlBe4Zq5QVnMHPX9rsaHTY kUgsUlH5/kj/QpBBzM2N9KexO6SswUzTadfXhMJaTExgY5kWdyhNzfV+OIW8AZHsxKs2 cOCKxFaWOgRiNj4883jhqgaAYmfKYowZ7kSy3vcIov45apJzD/sW65VeIaYeqzhwG3/J LfE8WjyCSvx77KNaH8eWlGMIrCBHjdou+pzMFX8PzBNPsoX0hotWN3r6Q92qEeo65oMt TKkvd/78GmPePv5nGojSucHjKu/Mubso81gEKmK6j0GfRq7hsY7avizyjFd+pnsV0gmA Gjfw== X-Received: by 10.140.96.203 with SMTP id k69mr3797821qge.33.1416550235492; Thu, 20 Nov 2014 22:10:35 -0800 (PST) Received: from [192.168.1.48] ([73.173.99.185]) by mx.google.com with ESMTPSA id v37sm3951754qge.29.2014.11.20.22.10.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Nov 2014 22:10:34 -0800 (PST) From: Shawn Webb Content-Type: multipart/signed; boundary="Apple-Mail=_DC6F0901-2DA4-401E-9821-56CC813F1B27"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Kernel Panic in frag6_slowtimeo Message-Id: <1E9CD103-709F-4AAE-B975-14429138293F@gmail.com> Date: Fri, 21 Nov 2014 01:10:33 -0500 To: freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 06:10:36 -0000 --Apple-Mail=_DC6F0901-2DA4-401E-9821-56CC813F1B27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Looks like I=92m getting a kernel panic on heavy work loads (poudriere = run with 10 build slaves on an Intel Core i7 box). Below is a link to an = imgur album of screenshots I took with my phone. I can reproduce this quite easily simply by spinning up a new poudriere = run. Should I file a bug report or is reporting here all that=92s = needed? Link to screenshots: http://imgur.com/a/h64uB Thanks, Shawn --Apple-Mail=_DC6F0901-2DA4-401E-9821-56CC813F1B27 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJUbtdZAAoJEGqEZY9SRW7uzYsP+wcTFJuluwLhDY7mCGiH5UYU DTTjYrnFmYq3QE6X32pCdq9uFXBQmP+Ks+0qGsIDULda5sgqOVnzkWWbqPFPDBdF FFku9nJkArj+jWwreQlUDapURqgvedrgMzUqgPE3zyL7juTSKiTbEeOL2q+/HMqd 7uUa5aqo0Uds8Y55eE6dcl61fHsOx2fJwYBsJsirFLCutS6D/7Y1Qf+CUHbSehwj ABA8gqNjNEWE+AGlFEanvURz1bbUKy2UEquQ4UCE6NfTfuEEdZiW+ZqnhipgMIqj r52TiCVXZ8kYY/FAloaYpdjVZH3Llj/ALIjOswlL6WHRg4Gfw5R3Ag4AvF7MbmvR xKaxs8quZAcCrUeZugD3eCqoYkYOtbLrX8wC1zgnAjSr1yG8zSp1RWWNRRYjUpPK 6lXF4hPt4eK87s7a4YoUT1SxM7iLBGzvv9hawvKUrL/y9mNN6jvtZ+U0LeB3infS mnL7JdFstTWo2KKn7NvoU47zcgS9kEAC4aWQSBvnlifyqJbPSkeI6yTaXtKn490W wioWqL3pSwMbfkBUxydoltiGMMCT6g+rowPNSIF153QruFOLKWsXui2dMGG3ilDX B6zHkKhbEuHSxZKVRadynDstDKVC9lZMXR0h0ul++phezCcv6CuTOisJtO2Usj1e Pi4tGGks3r5pgTS5CiBu =Xekr -----END PGP SIGNATURE----- --Apple-Mail=_DC6F0901-2DA4-401E-9821-56CC813F1B27-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 06:29:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 733A7F0F for ; Fri, 21 Nov 2014 06:29:00 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 4E191CD2 for ; Fri, 21 Nov 2014 06:28:59 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 5A5C073D4A for ; Fri, 21 Nov 2014 06:28:59 +0000 (UTC) Message-ID: <546EDBBC.1070300@freebsd.org> Date: Fri, 21 Nov 2014 01:29:16 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Kernel Panic in frag6_slowtimeo References: <1E9CD103-709F-4AAE-B975-14429138293F@gmail.com> In-Reply-To: <1E9CD103-709F-4AAE-B975-14429138293F@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PlReXTEinXE1kl43xa9mFTClWoxHrVGDL" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 06:29:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PlReXTEinXE1kl43xa9mFTClWoxHrVGDL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-11-21 01:10, Shawn Webb wrote: > Looks like I=92m getting a kernel panic on heavy work loads (poudriere = run with 10 build slaves on an Intel Core i7 box). Below is a link to an = imgur album of screenshots I took with my phone. >=20 > I can reproduce this quite easily simply by spinning up a new poudriere= run. Should I file a bug report or is reporting here all that=92s needed= ? >=20 > Link to screenshots: http://imgur.com/a/h64uB >=20 > Thanks, >=20 > Shawn >=20 Creating a PR in bugzilla is encouraged. --=20 Allan Jude --PlReXTEinXE1kl43xa9mFTClWoxHrVGDL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUbtu8AAoJEJrBFpNRJZKfa5IP/0cpw6Eg0JHDRJvVexdhwPs1 XVMniDhqFFXO+B30l0qikUHuwn7EA2VoWhyz/W+6rw3E+u3ZSMcP2itI6Ryoy65I 6eI9EIv/2LKXUij6NCiuE3E7twQ5geazF8B/OXHNPNR0ccLio4etJ/70f57kzHHW aRDmmMt2FTo6QyQ10cNJ3AQAXmZ0JwE7RUDoE6Ba2QZhQ63cLg+3rdF+M/R1b7dW gJLmAx/EkZq61VhnASJiCNNTTsTN4exHAK4+3Ukjr1xKRaUaTksk5mmXLURejNaH 8P/HfQBxlhwAzXNQH7o31xVBc2RC4W+sV05Zded+JT40E5/wM9hOyOpqZD4wQjpN olv5Eiq51ZZ/kafh173BwQtQUmX7L3IRTc7zjJDQyKOJjcKbCcIt7Zl4hTR4d64q LKtPYx3jU843XRLGZjonYN48cXfZVpnzNF2TENofvognycR2/stxGjYR4/1MiRR1 EcqgBe5+o4G1CvuwwTgKCMLNsvXlx0JiEB/O8Zmffmbras7SAMnLEo6xbUACGZmz KhXvurUsjksaECsGsv2h4vp/qWhBnX2mix99AyGXGMU0+uwSG4uSbTdwUr2ROuYI p6thOX1Fu3PPcjXf6n/whl24i2tCI81lDtdYXgSGW8iCHLAigPLirUQqY7keUa+T OQTI4h7CeDEKEK5hiten =zOUu -----END PGP SIGNATURE----- --PlReXTEinXE1kl43xa9mFTClWoxHrVGDL-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 08:12:04 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B974C582 for ; Fri, 21 Nov 2014 08:12:04 +0000 (UTC) Received: from mailrelay8.public.one.com (mailrelay8.public.one.com [91.198.169.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E7B6A53 for ; Fri, 21 Nov 2014 08:12:03 +0000 (UTC) X-HalOne-Cookie: 932198f25949c6e363e02dcf6d65f5e54bee5f3d DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cederstrand.dk; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=6+SEgozgBROlDHTlOILIqgpwgZ8ByuXjD/blWnHBg7Q=; b=sT869UsLVMDICKgUPwIiNZaRc8JXnszU708jL72sULY2oqH/Iwz5CqDQ6piwe233Cz2YwDvju2mUX IAHkVjMogxcdTuDUmkKJujKsq8zFyY+Wyob9X/FayrRFOAVWJYpJlGAa5QDEl6EYGNnw46OKveOsq1 Itk7zwqoQA5ywI3s= Received: from [192.168.1.58] (unknown [217.157.7.221]) by smtpfilter4.public.one.com (Halon Mail Gateway) with ESMTPSA; Fri, 21 Nov 2014 08:08:04 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: send-pr must live From: Erik Cederstrand In-Reply-To: Date: Fri, 21 Nov 2014 09:10:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <37F1EA3C-BAEC-4BC9-8EAD-8C5CC74295BA@cederstrand.dk> References: To: Chris H X-Mailer: Apple Mail (2.1993) Cc: freebsd-hackers@freebsd.org, FreeBSD STABLE , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 08:12:04 -0000 > Den 20/11/2014 kl. 18.07 skrev Chris H : >=20 > Greetings, > While I recognize that send-pr has pretty much > become useless, with the advent of bugzilla, being made > the new "official" FreeBSD bug reporting system. I really > miss send-pr, and was hoping I could revive it, eg; > integrate it with bugzilla. I had even contemplated adding > a feature that would allow it to also work with local > port/system building structures people often use to build, > and maintain FreeBSD. The original send-pr simply send an email to = freebsd-gnats-submit@freebsd.org. I wrote a script some years ago to = parse the contents of that email and import it into Bugzilla using the = Bugzilla XML-RPC API: https://github.com/ecederstrand/send-pr The advantage is that no changes are necessary to the original send-pr = because the script would run on a freebsd.org server. I haven't adapted = it to the Bugzilla that is running now, but it should be fairly easy. = Maybe this could be of use? Erik= From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 10:54:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94A8DB54 for ; Fri, 21 Nov 2014 10:54:03 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CDDDD70 for ; Fri, 21 Nov 2014 10:54:03 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 636DE25D37D1; Fri, 21 Nov 2014 10:54:00 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9958FC76FDF; Fri, 21 Nov 2014 10:53:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id cvHuar__9wOA; Fri, 21 Nov 2014 10:53:58 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C49DEC76FCE; Fri, 21 Nov 2014 10:53:57 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Kernel Panic in frag6_slowtimeo From: "Bjoern A. Zeeb" In-Reply-To: <1E9CD103-709F-4AAE-B975-14429138293F@gmail.com> Date: Fri, 21 Nov 2014 10:53:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <54F837A5-1301-4253-BA87-317C01311BA6@lists.zabbadoz.net> References: <1E9CD103-709F-4AAE-B975-14429138293F@gmail.com> To: Shawn Webb X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 10:54:03 -0000 On 21 Nov 2014, at 06:10 , Shawn Webb wrote: > Looks like I=92m getting a kernel panic on heavy work loads (poudriere = run with 10 build slaves on an Intel Core i7 box). Below is a link to an = imgur album of screenshots I took with my phone. >=20 > I can reproduce this quite easily simply by spinning up a new = poudriere run. Should I file a bug report or is reporting here all = that=92s needed? >=20 > Link to screenshots: http://imgur.com/a/h64uB Which exact revision/version of FreeBSD is this (SVN revision in case of = non-release)? =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 13:02:33 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A451B724 for ; Fri, 21 Nov 2014 13:02:33 +0000 (UTC) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6DCD57 for ; Fri, 21 Nov 2014 13:02:32 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id AA0541D7ED7D; Fri, 21 Nov 2014 13:56:32 +0100 (CET) Date: Fri, 21 Nov 2014 13:56:32 +0100 From: Roman Divacky To: current@freebsd.org Subject: [PATCH]: further shrinking of boot2 Message-ID: <20141121125632.GA23706@vlakno.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Fri, 21 Nov 2014 13:05:11 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 13:02:33 -0000 Hi all! In an effort to help import clang3.5 I looked at squeezing a few more bytes from boot2. http://rys.vlakno.cz/~rdivacky/boot2.diet.patch Please test and review the patch. It survived my qemu boot attempt so it's not completely broken. But I would like to have some more testing and review comments before I move forward with this. Fwiw, it shrinks boot2 by 16 bytes when compiled with clang34 and by 28 bytes when compiled with clang35. Thanks! Roman From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 13:07:58 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A5249F1 for ; Fri, 21 Nov 2014 13:07:58 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CE92D91 for ; Fri, 21 Nov 2014 13:07:57 +0000 (UTC) Received: from [192.168.0.106] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.9/8.14.9) with ESMTP id sALD7lX2051073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Nov 2014 13:07:49 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52] claimed to be [192.168.0.106] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH]: further shrinking of boot2 From: David Chisnall In-Reply-To: <20141121125632.GA23706@vlakno.cz> Date: Fri, 21 Nov 2014 13:07:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141121125632.GA23706@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.1878.6) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 13:07:58 -0000 Fir the clang 3.4 import, I had some patches (that never got applied), = which used clang -O0 and then opt with some custom optimisation order to = get a reasonable size saving. It might be worth trying that, so that = future changes to the default optimisation order don't make things worse = again. David On 21 Nov 2014, at 12:56, Roman Divacky wrote: > Hi all! >=20 > In an effort to help import clang3.5 I looked at squeezing a few more = bytes > from boot2. >=20 >=20 > http://rys.vlakno.cz/~rdivacky/boot2.diet.patch >=20 >=20 > Please test and review the patch. It survived my qemu boot attempt so = it's > not completely broken. But I would like to have some more testing and = review > comments before I move forward with this. >=20 > Fwiw, it shrinks boot2 by 16 bytes when compiled with clang34 and by = 28 bytes > when compiled with clang35. >=20 > Thanks! Roman > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 14:24:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 660AB969 for ; Fri, 21 Nov 2014 14:24:50 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C51E80F for ; Fri, 21 Nov 2014 14:24:50 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id f12so3510392qad.0 for ; Fri, 21 Nov 2014 06:24:49 -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=LYxSYIJZMrvyXfuDWF7cDEKc53e9hQ11QoY4Ew0I7M0=; b=TaamU6xaZenLTp36vakEXNaAMIIWFeyXgjyRy3LTCkoeMUEdIj1wnbVhBa0CiirAA8 mO7iTLUmzZWh7SVlgTSaeYMlTXLIjbr/0++DUKMBAvF1AtPMiIfj5PmGpr/jBCdbu+NK m79Sr2cht/oQb4EBmuwJ2kyw5XRX2AVa3+x12VDzCAxsfPzKyfciYsdB122Qu56mNicO 11PZQwHchBQ3jQPFf4SW0FoGV7LOX8aYgYsJlQNfycdlnOW0bSY9Se6LQgSU+7ohYyWH EKdFUW+8cNu0tv1LiiuUYRgZHpro0m7uzsLTG4LzO2GFiwkdAN0ZG48Tgix+9IiU3IG6 tw2Q== X-Received: by 10.224.80.6 with SMTP id r6mr6796662qak.5.1416579888418; Fri, 21 Nov 2014 06:24:48 -0800 (PST) Received: from [10.7.1.109] (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id h10sm4771791qge.16.2014.11.21.06.24.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Nov 2014 06:24:47 -0800 (PST) Message-ID: <546F4B2F.6050608@gmail.com> Date: Fri, 21 Nov 2014 09:24:47 -0500 From: Shawn Webb User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: Kernel Panic in frag6_slowtimeo References: <1E9CD103-709F-4AAE-B975-14429138293F@gmail.com> <54F837A5-1301-4253-BA87-317C01311BA6@lists.zabbadoz.net> In-Reply-To: <54F837A5-1301-4253-BA87-317C01311BA6@lists.zabbadoz.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 14:24:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =20 On 11/21/2014 5:53 AM, Bjoern A. Zeeb wrote: > > On 21 Nov 2014, at 06:10 , Shawn Webb wrote: > >> Looks like I=92m getting a kernel panic on heavy work loads (poudriere= run with 10 build slaves on an Intel Core i7 box). Below is a link to an imgur album of screenshots I took with my phone. >> >> I can reproduce this quite easily simply by spinning up a new poudriere run. Should I file a bug report or is reporting here all that=92s needed? >> >> Link to screenshots: http://imgur.com/a/h64uB > > > Which exact revision/version of FreeBSD is this (SVN revision in case of non-release)? I'm at r274745. The code in question was written in 2003. I've narrowed down the behavior to OpenVPN with IPv6 causing this kernel panic. My OpenVPN server dishes out IPv6 as well as IPv4 in routing mode and is configured to use UDP (which is the default). OpenVPN's default keepalive is 120 seconds. If the tunnel goes down within that 120 seconds and OpenVPN doesn't notice, the tun device is still active but packages are simply queued rather then delivered. Eventually OpenVPN re-establishes the tunnel while keeping the tun device open, reusing it rather than destroying/recreating it. The kernel panic is happening either while the tunnel is down (yet tun device still is open) or when the tunnel is being brought back up. If I set the keepalive to a really small value (I currently have it at two seconds), then the kernel panic doesn't happen. Really interesting behavior. Thanks, Shawn -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) =20 iQIcBAEBAgAGBQJUb0svAAoJEGqEZY9SRW7uXAsP/AzM3wfkDUQrBXtm2M3UdhLc Y0EI+eqj58wIQ3UvwuRTLKg6T+Zpz5+yTBIzysPGCtgoR9UzYePVkqLyE2qD0bHT FSPDpOKGzhZBOdElsTGZziw/tHK+jL/JIqVLS98T8uUpzb6YHJWMD6uT9ZjLkS3+ tvIoyL1R7BtVhpnu73HCH4aGrshEgn9Tmtq3FSczAOMysYwtGc0oVFiSXpPy0wBg n2zW56jIHOFl/h6NkGD6HYFaDainkSf4yH+BbyMT82OiGSxOW2boz6IdGiopf5qI lTEpbdUQQ0R0YhMIaDNwawC7VhsGFSAe8kkrs/ma8Ut/X2D1yGhhpD2tTnYUMf0l g3sn2K27WHldGqK/YQ1KUDk1vqnynB7aTqfD7lTx2h//kYZbhVdLUiTS1VwzOuZU Qgz4Y/SJycx/qE19OnZ7L41XtyIICNpqYkI1HoFZBPqNePn6j2oZ9sUp92Rmui6S wvYZ0WP3FYZVsPUiFrZfKFb/RJ7woMyklBiRs09D4V5oO3Fxk3uxbQE5sSnr1mhn cN0izfazAXePMcSE3zMgARv+M/GT2LgySlurOb+7xAs47YecN2IT33m+Ffd+rF7X /jEaGMHGObZtQCl20GGPDcfy/KQrwHN8BdGJ81+T61NYfN+F1MImWve3YdzEOF1N Y6jill9bzaksguJ5WYev =3DAiXD -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 16:15:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7C845ED for ; Fri, 21 Nov 2014 16:15:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3006635 for ; Fri, 21 Nov 2014 16:15:20 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A834DB989; Fri, 21 Nov 2014 11:15:19 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [PATCH]: further shrinking of boot2 Date: Fri, 21 Nov 2014 10:16:58 -0500 Message-ID: <40529392.oiqLG4jV1P@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-PRERELEASE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20141121125632.GA23706@vlakno.cz> References: <20141121125632.GA23706@vlakno.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 21 Nov 2014 11:15:19 -0500 (EST) Cc: Roman Divacky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 16:15:20 -0000 On Friday, November 21, 2014 01:56:32 PM Roman Divacky wrote: > Hi all! > > In an effort to help import clang3.5 I looked at squeezing a few more bytes > from boot2. > > > http://rys.vlakno.cz/~rdivacky/boot2.diet.patch > > > Please test and review the patch. It survived my qemu boot attempt so it's > not completely broken. But I would like to have some more testing and review > comments before I move forward with this. > > Fwiw, it shrinks boot2 by 16 bytes when compiled with clang34 and by 28 > bytes when compiled with clang35. I would prefer 'int k' over 'int i2/j2'. Also, do you really have to move the variable definitions to get the size change? I'd prefer to leave the variable declarations where they are if possible (and just add 'int k' or 'size_t k' in the existing variable blocks). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 19:39:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A22BBDB0; Fri, 21 Nov 2014 19:39:27 +0000 (UTC) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 6801AF31; Fri, 21 Nov 2014 19:39:26 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 6A79D1D7ED79; Fri, 21 Nov 2014 20:39:17 +0100 (CET) Date: Fri, 21 Nov 2014 20:39:17 +0100 From: Roman Divacky To: John Baldwin Subject: Re: [PATCH]: further shrinking of boot2 Message-ID: <20141121193917.GA42522@vlakno.cz> References: <20141121125632.GA23706@vlakno.cz> <40529392.oiqLG4jV1P@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40529392.oiqLG4jV1P@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Fri, 21 Nov 2014 19:44:16 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 19:39:27 -0000 Sure thing. Reload the patch from the same url. http://rys.vlakno.cz/~rdivacky/boot2.diet.patch On Fri, Nov 21, 2014 at 10:16:58AM -0500, John Baldwin wrote: > On Friday, November 21, 2014 01:56:32 PM Roman Divacky wrote: > > Hi all! > > > > In an effort to help import clang3.5 I looked at squeezing a few more bytes > > from boot2. > > > > > > http://rys.vlakno.cz/~rdivacky/boot2.diet.patch > > > > > > Please test and review the patch. It survived my qemu boot attempt so it's > > not completely broken. But I would like to have some more testing and review > > comments before I move forward with this. > > > > Fwiw, it shrinks boot2 by 16 bytes when compiled with clang34 and by 28 > > bytes when compiled with clang35. > > I would prefer 'int k' over 'int i2/j2'. Also, do you really have to move > the variable definitions to get the size change? I'd prefer to leave the > variable declarations where they are if possible (and just add 'int k' or > 'size_t k' in the existing variable blocks). > > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 20:34:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 676E95BB for ; Fri, 21 Nov 2014 20:34:51 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0056.outbound.protection.outlook.com [207.46.100.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E31B89D for ; Fri, 21 Nov 2014 20:34:50 +0000 (UTC) Received: from SN2PR0801MB671.namprd08.prod.outlook.com (25.160.17.149) by SN2PR0801MB0750.namprd08.prod.outlook.com (25.160.57.144) with Microsoft SMTP Server (TLS) id 15.1.16.15; Fri, 21 Nov 2014 20:34:43 +0000 Received: from [172.17.3.194] (63.252.212.99) by SN2PR0801MB671.namprd08.prod.outlook.com (25.160.17.149) with Microsoft SMTP Server (TLS) id 15.1.16.15; Fri, 21 Nov 2014 20:34:41 +0000 Message-ID: <546FA1DD.2070109@panasas.com> Date: Fri, 21 Nov 2014 15:34:37 -0500 From: "Ellis H. Wilson III" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: Subject: Re: WITNESS observes 2 LORs on Boot of Release 10.1 References: <546BA9D3.6070007@panasas.com> <546BF3F5.8030109@panasas.com> In-Reply-To: <546BF3F5.8030109@panasas.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [63.252.212.99] X-ClientProxiedBy: DM2PR03CA0044.namprd03.prod.outlook.com (10.141.96.43) To SN2PR0801MB671.namprd08.prod.outlook.com (25.160.17.149) X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:SN2PR0801MB671; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:SN2PR0801MB671; X-Forefront-PRVS: 0402872DA1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6049001)(199003)(41574002)(24454002)(377454003)(479174003)(189002)(36756003)(87976001)(450100001)(20776003)(66066001)(65956001)(83506001)(50466002)(59896002)(106356001)(77096003)(105586002)(21056001)(86362001)(64706001)(4396001)(92566001)(65816999)(92726001)(102836001)(76176999)(95666004)(46102003)(107046002)(122386002)(107886001)(50986999)(2351001)(54356999)(120916001)(47776003)(101416001)(31966008)(33656002)(80316001)(64126003)(99396003)(40100003)(42186005)(97736003)(62966003)(110136001)(23756003)(77156002)(87266999); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR0801MB671; H:[172.17.3.194]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:SN2PR0801MB671; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:SN2PR0801MB0750; X-OriginatorOrg: panasas.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 20:34:51 -0000 On 11/18/2014 08:35 PM, Ellis H. Wilson III wrote: > If nobody has seen these before, I'll try and put together fixes for > them. Please somebody speak up if you have seen them or have useful > information for me to go on in my patches. I've started to dig into the relevant code in sys/dev/random/random_harvestq.c, sys/dev/syscons/syscons.c, and sys/kern/subr_sleepqueue.c. Before I start, and this is mainly geared to my responder Benjamin Kaduk, based on your response, are you suggesting that the cnputc WITNESS panic you expected to happen is now completely unavoidable in FreeBSD 10? I.E., is this a spinlock that WITNESS falls over each time but that is provably deadlock free that the developers have decided cannot be BLESSED for some reason? I guess I just can't wrap my head around why we would ever move to a regime where SKIPSPIN is the default for testing... That just seems like an open invitation for introducing spinlock regressions. Moving onto the LORs I'm seeing, a question I have as a newbie to WITNESS debugging is how exactly to interpret the output if I see a stacktrace and then a LOR output like the following: lock order reversal: 1st 0xffffffff81633d88 entropy harvest mutex (entropy harvest mutex) @ /usr/src/sys/dev/random/random_harvestq.c:198 2nd 0xffffffff813b6208 scrlock (scrlock) @ /usr/src/sys/dev/syscons/syscons.c:2682 Does this mean WITNESS has already stored an ordering of #1 harvest_mtx then #2 scp->scr_lock, and somewhere somebody tried to lock scp->scr_lock without first getting harvest_mtx? Or the reverse (WITNESS previously recorded scrlock and then harvest and the lines it spit out were the offenders?) Along those lines, in 10.0 and 10.1 releases I get two LORs showing up almost on-top of each other, with the other LOR showing up as: lock order reversal: 1st 0xffffffff81633d88 entropy harvest mutex (entropy harvest mutex) @ /usr/src/sys/dev/random/random_harvestq.c:198 2nd 0xffffffff81424bb8 sleepq chain (sleepq chain) @ /usr/src/sys/kern/subr_sleepqueue.c:240 This seems like maybe two LORs are detected at the same time, which perhaps suggests that the harvest_mtx should have been taken /after/ both of the other locks mentioned (scrlock and sleepq). I'm happy to do the legwork implementing, testing, and submitting a patch for this, but I would really appreciate a pointer in the right direction from somebody who already has handled some LORs before. Thanks! ellis From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 21:09:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B2019BB for ; Fri, 21 Nov 2014 21:09:03 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43D8BC0C for ; Fri, 21 Nov 2014 21:09:03 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 31091B94F; Fri, 21 Nov 2014 16:09:02 -0500 (EST) From: John Baldwin To: Roman Divacky Subject: Re: [PATCH]: further shrinking of boot2 Date: Fri, 21 Nov 2014 16:00:35 -0500 Message-ID: <2347830.QJqypafd5I@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-PRERELEASE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20141121193917.GA42522@vlakno.cz> References: <20141121125632.GA23706@vlakno.cz> <40529392.oiqLG4jV1P@ralph.baldwin.cx> <20141121193917.GA42522@vlakno.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 21 Nov 2014 16:09:02 -0500 (EST) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 21:09:03 -0000 On Friday, November 21, 2014 08:39:17 PM Roman Divacky wrote: > Sure thing. Reload the patch from the same url. > > http://rys.vlakno.cz/~rdivacky/boot2.diet.patch Thanks. I haven't run tested it, but I'm ok with it otherwise. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 21:23:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 719052CB; Fri, 21 Nov 2014 21:23:19 +0000 (UTC) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 369C9DC3; Fri, 21 Nov 2014 21:23:18 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 151FF1D7ED7D; Fri, 21 Nov 2014 22:23:10 +0100 (CET) Date: Fri, 21 Nov 2014 22:23:10 +0100 From: Roman Divacky To: John Baldwin Subject: Re: [PATCH]: further shrinking of boot2 Message-ID: <20141121212310.GA47479@vlakno.cz> References: <20141121125632.GA23706@vlakno.cz> <40529392.oiqLG4jV1P@ralph.baldwin.cx> <20141121193917.GA42522@vlakno.cz> <2347830.QJqypafd5I@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2347830.QJqypafd5I@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Fri, 21 Nov 2014 21:31:39 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 21:23:19 -0000 On Fri, Nov 21, 2014 at 04:00:35PM -0500, John Baldwin wrote: > On Friday, November 21, 2014 08:39:17 PM Roman Divacky wrote: > > Sure thing. Reload the patch from the same url. > > > > http://rys.vlakno.cz/~rdivacky/boot2.diet.patch > > Thanks. I haven't run tested it, but I'm ok with it otherwise. Thanks for the review. I'll wait a couple of days, hopefully someone will test the patch in a different way I did. Unless someone reports a breakage I'll commit this sometime next week. Thanks! Roman From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 06:53:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B0F3124 for ; Sat, 22 Nov 2014 06:53:30 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id ECD86B35 for ; Sat, 22 Nov 2014 06:53:29 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2E8462EC for ; Sat, 22 Nov 2014 06:53:28 +0000 (UTC) Date: Sat, 22 Nov 2014 06:53:25 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <857671197.2.1416639206621.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #473 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 06:53:30 -0000 See ------------------------------------------ [...truncated 7869 lines...] -> ../de_DE.ISO8859-1/tcsh.cat -> ../de_DE.ISO8859-1/tcsh.cat -> ../el_GR.ISO8859-7/tcsh.cat -> ../it_IT.ISO8859-1/tcsh.ca= t -> ../it_IT.ISO8859-1/tcsh.c= at -> ../it_IT.ISO8859-1/tcsh.c= at -> ../it_IT.ISO8859-1/tcsh.cat -> ../it_IT.ISO8859-1/tcsh.cat -> ../ja_JP.eucJP/tcsh.cat -> ../ja_JP.eucJP/tcsh.cat -> ../ru_RU.KOI8-R/tcsh.cat -> ../ru_RU.KOI8-R/tcsh.cat -> ../ru_RU.KOI8-R/tcsh.cat -> ../ru_RU.KOI8-R/tcsh.cat -> ../es_ES.ISO8859-1/tcsh.c= at -> ../es_ES.ISO8859-1/tcsh.cat -> ../uk_UA.KOI8-U/tcsh.cat -> ../uk_UA.KOI8-U/tcsh.cat =3D=3D=3D> bin/date (install) install -s -o root -g wheel -m 555 date install -o root -g wheel -m 444 date.1.gz =3D=3D=3D> bin/date/tests (install) install -o root -g wheel -m 555 format_string_test install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/bin/date/tests && make -f /builds/FreeBSD_HEAD/bin= /date/tests/Makefile SUBDIR=3D _RECURSING_PROGS=3D install) install -o root -g wheel -m 555 format_string_test =3D=3D=3D> bin/dd (install) install -s -o root -g wheel -m 555 dd install -o root -g wheel -m 444 dd.1.gz =3D=3D=3D> bin/df (install) install -s -o root -g wheel -m 555 df install -o root -g wheel -m 444 df.1.gz =3D=3D=3D> bin/domainname (install) install -s -o root -g wheel -m 555 domainname install -o root -g wheel -m 444 domainname.1.gz =3D=3D=3D> bin/echo (install) install -s -o root -g wheel -m 555 echo install -o root -g wheel -m 444 echo.1.gz =3D=3D=3D> bin/ed (install) install -s -o root -g wheel -m 555 ed install -o root -g wheel -m 444 ed.1.gz -> -> =3D=3D=3D> bin/expr (install) install -s -o root -g wheel -m 555 expr install -o root -g wheel -m 444 expr.1.gz =3D=3D=3D> bin/freebsd-version (install) install -o root -g wheel -m 555 freebsd-version install -o root -g wheel -m 444 freebsd-version.1.gz =3D=3D=3D> bin/getfacl (install) install -s -o root -g wheel -m 555 getfacl install -o root -g wheel -m 444 getfacl.1.gz =3D=3D=3D> bin/hostname (install) install -s -o root -g wheel -m 555 hostname install -o root -g wheel -m 444 hostname.1.gz =3D=3D=3D> bin/kenv (install) install -s -o root -g wheel -m 555 kenv install -o root -g wheel -m 444 kenv.1.gz =3D=3D=3D> bin/kill (install) install -s -o root -g wheel -m 555 kill install -o root -g wheel -m 444 kill.1.gz =3D=3D=3D> bin/ln (install) install -s -o root -g wheel -m 555 ln install -o root -g wheel -m 444 ln.1.gz install -o root -g wheel -m 444 symlink.7.gz -> -> =3D=3D=3D> bin/ls (install) install -s -o root -g wheel -m 555 ls install -o root -g wheel -m 444 ls.1.gz =3D=3D=3D> bin/mkdir (install) install -s -o root -g wheel -m 555 mkdir install -o root -g wheel -m 444 mkdir.1.gz =3D=3D=3D> bin/mv (install) install -s -o root -g wheel -m 555 mv install -o root -g wheel -m 444 mv.1.gz =3D=3D=3D> bin/mv/tests (install) install -o root -g wheel -m 555 legacy_test install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/bin/mv/tests && make -f /builds/FreeBSD_HEAD/bin/m= v/tests/Makefile SUBDIR=3D _RECURSING_PROGS=3D install) install -o root -g wheel -m 555 legacy_test =3D=3D=3D> bin/pax (install) install -s -o root -g wheel -m 555 pax install -o root -g wheel -m 444 pax.1.gz =3D=3D=3D> bin/pax/tests (install) install -o root -g wheel -m 555 legacy_test install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/bin/pax/tests && make -f /builds/FreeBSD_HEAD/bin/= pax/tests/Makefile SUBDIR=3D _RECURSING_PROGS=3D install) install -o root -g wheel -m 555 legacy_test =3D=3D=3D> bin/pkill (install) install -s -o root -g wheel -m 555 pkill install -o root -g wheel -m 444 pkill.1.gz -> =3D=3D=3D> bin/pkill/tests (install) install -o root -g wheel -m 555 pgrep-F_test install -o root -g wheel -m 555 pgrep-LF_test install -o root -g wheel -m 555 pgrep-P_test install -o root -g wheel -m 555 pgrep-U_test install -o root -g wheel -m 555 pgrep-_g_test install -o root -g wheel -m 555 pgrep-_s_test install -o root -g wheel -m 555 pgrep-g_test install -o root -g wheel -m 555 pgrep-i_test install -o root -g wheel -m 555 pgrep-j_test install -o root -g wheel -m 555 pgrep-l_test install -o root -g wheel -m 555 pgrep-n_test install -o root -g wheel -m 555 pgrep-o_test install -o root -g wheel -m 555 pgrep-q_test install -o root -g wheel -m 555 pgrep-s_test install -o root -g wheel -m 555 pgrep-t_test install -o root -g wheel -m 555 pgrep-v_test install -o root -g wheel -m 555 pgrep-x_test install -o root -g wheel -m 555 pkill-F_test install -o root -g wheel -m 555 pkill-LF_test install -o root -g wheel -m 555 pkill-P_test install -o root -g wheel -m 555 pkill-U_test install -o root -g wheel -m 555 pkill-_g_test install -o root -g wheel -m 555 pkill-g_test install -o root -g wheel -m 555 pkill-i_test install -o root -g wheel -m 555 pkill-j_test install -o root -g wheel -m 555 pkill-s_test install -o root -g wheel -m 555 pkill-t_test install -o root -g wheel -m 555 pkill-x_test install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/bin/pkill/tests && make -f /builds/FreeBSD_HEAD/bi= n/pkill/tests/Makefile SUBDIR=3D _RECURSING_PROGS=3D install) install -o root -g wheel -m 555 pgrep-F_test install -o root -g wheel -m 555 pgrep-LF_test install -o root -g wheel -m 555 pgrep-P_test install -o root -g wheel -m 555 pgrep-U_test install -o root -g wheel -m 555 pgrep-_g_test install -o root -g wheel -m 555 pgrep-_s_test install -o root -g wheel -m 555 pgrep-g_test install -o root -g wheel -m 555 pgrep-i_test install -o root -g wheel -m 555 pgrep-j_test install -o root -g wheel -m 555 pgrep-l_test install -o root -g wheel -m 555 pgrep-n_test install -o root -g wheel -m 555 pgrep-o_test install -o root -g wheel -m 555 pgrep-q_test install -o root -g wheel -m 555 pgrep-s_test install -o root -g wheel -m 555 pgrep-t_test install -o root -g wheel -m 555 pgrep-v_test install -o root -g wheel -m 555 pgrep-x_test install -o root -g wheel -m 555 pkill-F_test install -o root -g wheel -m 555 pkill-LF_test install -o root -g wheel -m 555 pkill-P_test install -o root -g wheel -m 555 pkill-U_test install -o root -g wheel -m 555 pkill-_g_test install -o root -g wheel -m 555 pkill-g_test install -o root -g wheel -m 555 pkill-i_test install -o root -g wheel -m 555 pkill-j_test install -o root -g wheel -m 555 pkill-s_test install -o root -g wheel -m 555 pkill-t_test install -o root -g wheel -m 555 pkill-x_test -> -> /bin/pkill -> /bin/pgrep =3D=3D=3D> bin/ps (install) install -s -o root -g wheel -m 555 ps install -o root -g wheel -m 444 ps.1.gz =3D=3D=3D> bin/pwait (install) install -s -o root -g wheel -m 555 pwait install -o root -g wheel -m 444 pwait.1.gz =3D=3D=3D> bin/pwd (install) install -s -o root -g wheel -m 555 pwd install -o root -g wheel -m 444 pwd.1.gz =3D=3D=3D> bin/rcp (install) install -s -o root -g wheel -m 4555 -S rcp install -o root -g wheel -m 444 rcp.1.gz =3D=3D=3D> bin/realpath (install) install -s -o root -g wheel -m 555 realpath install -o root -g wheel -m 444 realpath.1.gz =3D=3D=3D> bin/rm (install) install -s -o root -g wheel -m 555 rm install -o root -g wheel -m 444 rm.1.gz -> -> =3D=3D=3D> bin/rmail (install) install -s -o root -g wheel -m 555 rmail install -o root -g wheel -m 444 rmail.8.gz =3D=3D=3D> bin/rmdir (install) install -s -o root -g wheel -m 555 rmdir install -o root -g wheel -m 444 rmdir.1.gz =3D=3D=3D> bin/setfacl (install) install -s -o root -g wheel -m 555 setfacl install -o root -g wheel -m 444 setfacl.1.gz =3D=3D=3D> bin/sh (install) install -s -o root -g wheel -m 555 -S sh install -o root -g wheel -m 444 sh.1.gz =3D=3D=3D> bin/sh/tests (install) =3D=3D=3D> bin/sh/tests/builtins (install) install -o root -g wheel -m 555 functional_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/bin/sh/tests/builtins= /alias.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/alias.0.stdout /builds/= FreeBSD_HEAD/bin/sh/tests/builtins/alias.1 /builds/FreeBSD_HEAD/bin/sh/test= s/builtins/alias.1.stderr /builds/FreeBSD_HEAD/bin/sh/tests/builtins/alias3= .0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/alias3.0.stdout /builds/FreeB= SD_HEAD/bin/sh/tests/builtins/alias4.0 /builds/FreeBSD_HEAD/bin/sh/tests/bu= iltins/break1.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/break2.0 /builds= /FreeBSD_HEAD/bin/sh/tests/builtins/break2.0.stdout /builds/FreeBSD_HEAD/bi= n/sh/tests/builtins/break3.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/bre= ak4.4 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/break5.4 /builds/FreeBSD_H= EAD/bin/sh/tests/builtins/break6.0 /builds/FreeBSD_HEAD/bin/sh/tests/builti= ns/builtin1.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/case1.0 /builds/Fr= eeBSD_HEAD/bin/sh/tests/builtins/case2.0 /builds/FreeBSD_HEAD/bin/sh/tests/= builtins/case3.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/case4.0 /builds= /FreeBSD_HEAD/bin/sh/tests/builtins/case5.0 /builds/FreeBSD_HEAD/bin/sh/tes= ts/builtins/case6.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/case7.0 /bui= lds/FreeBSD_HEAD/bin/sh/tests/builtins/case8.0 /builds/FreeBSD_HEAD/bin/sh/= tests/builtins/case9.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/case10.0 = /builds/FreeBSD_HEAD/bin/sh/tests/builtins/case11.0 /builds/FreeBSD_HEAD/bi= n/sh/tests/builtins/case12.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/cas= e13.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/case14.0 /builds/FreeBSD_H= EAD/bin/sh/tests/builtins/case15.0 /builds/FreeBSD_HEAD/bin/sh/tests/builti= ns/case16.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/case17.0 /builds/Fre= eBSD_HEAD/bin/sh/tests/builtins/case18.0 /builds/FreeBSD_HEAD/bin/sh/tests/= builtins/case19.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/cd1.0 /builds/= FreeBSD_HEAD/bin/sh/tests/builtins/cd2.0 /builds/FreeBSD_HEAD/bin/sh/tests/= builtins/cd3.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/cd4.0 /builds/Fre= eBSD_HEAD/bin/sh/tests/builtins/cd5.0 /builds/FreeBSD_HEAD/bin/sh/tests/bui= ltins/cd6.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/cd7.0 /builds/FreeBS= D_HEAD/bin/sh/tests/builtins/cd8.0 /builds/FreeBSD_HEAD/bin/sh/tests/builti= ns/command1.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/command2.0 /builds= /FreeBSD_HEAD/bin/sh/tests/builtins/command3.0 /builds/FreeBSD_HEAD/bin/sh/= tests/builtins/command3.0.stdout /builds/FreeBSD_HEAD/bin/sh/tests/builtins= /command4.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/command5.0 /builds/F= reeBSD_HEAD/bin/sh/tests/builtins/command5.0.stdout /builds/FreeBSD_HEAD/bi= n/sh/tests/builtins/command6.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/c= ommand6.0.stdout /builds/FreeBSD_HEAD/bin/sh/tests/builtins/command7.0 /bui= lds/FreeBSD_HEAD/bin/sh/tests/builtins/command8.0 /builds/FreeBSD_HEAD/bin/= sh/tests/builtins/command9.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/com= mand10.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/command11.0 /builds/Fre= eBSD_HEAD/bin/sh/tests/builtins/command12.0 /builds/FreeBSD_HEAD/bin/sh/tes= ts/builtins/dot1.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/dot2.0 /build= s/FreeBSD_HEAD/bin/sh/tests/builtins/dot3.0 /builds/FreeBSD_HEAD/bin/sh/tes= ts/builtins/dot4.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/eval1.0 /buil= ds/FreeBSD_HEAD/bin/sh/tests/builtins/eval2.0 /builds/FreeBSD_HEAD/bin/sh/t= ests/builtins/eval3.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/eval4.0 /b= uilds/FreeBSD_HEAD/bin/sh/tests/builtins/eval5.0 /builds/FreeBSD_HEAD/bin/s= h/tests/builtins/eval6.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/eval7.0= /builds/FreeBSD_HEAD/bin/sh/tests/builtins/eval8.7 /builds/FreeBSD_HEAD/bi= n/sh/tests/builtins/exec1.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/exec= 2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/exit1.0 /builds/FreeBSD_HEAD= /bin/sh/tests/builtins/exit2.8 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/e= xit3.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/export1.0 /builds/FreeBSD= _HEAD/bin/sh/tests/builtins/fc1.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtin= s/fc2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/for1.0 /builds/FreeBSD_H= EAD/bin/sh/tests/builtins/for2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins= /for3.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/getopts1.0 /builds/FreeB= SD_HEAD/bin/sh/tests/builtins/getopts1.0.stdout /builds/FreeBSD_HEAD/bin/sh= /tests/builtins/getopts2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/getop= ts2.0.stdout /builds/FreeBSD_HEAD/bin/sh/tests/builtins/getopts3.0 /builds/= FreeBSD_HEAD/bin/sh/tests/builtins/getopts4.0 /builds/FreeBSD_HEAD/bin/sh/t= ests/builtins/getopts5.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/getopts= 6.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/getopts7.0 /builds/FreeBSD_H= EAD/bin/sh/tests/builtins/getopts8.0 /builds/FreeBSD_HEAD/bin/sh/tests/buil= tins/getopts8.0.stdout /builds/FreeBSD_HEAD/bin/sh/tests/builtins/hash1.0 /= builds/FreeBSD_HEAD/bin/sh/tests/builtins/hash1.0.stdout /builds/FreeBSD_HE= AD/bin/sh/tests/builtins/hash2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins= /hash2.0.stdout /builds/FreeBSD_HEAD/bin/sh/tests/builtins/hash3.0 /builds/= FreeBSD_HEAD/bin/sh/tests/builtins/hash3.0.stdout /builds/FreeBSD_HEAD/bin/= sh/tests/builtins/hash4.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/jobid1= .0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/jobid2.0 /builds/FreeBSD_HEAD= /bin/sh/tests/builtins/kill1.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/k= ill2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/lineno.0 /builds/FreeBSD_= HEAD/bin/sh/tests/builtins/lineno.0.stdout /builds/FreeBSD_HEAD/bin/sh/test= s/builtins/lineno2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/lineno3.0 /= builds/FreeBSD_HEAD/bin/sh/tests/builtins/lineno3.0.stdout /builds/FreeBSD_= HEAD/bin/sh/tests/builtins/local1.0 /builds/FreeBSD_HEAD/bin/sh/tests/built= ins/local2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/local3.0 /builds/Fr= eeBSD_HEAD/bin/sh/tests/builtins/local4.0 /builds/FreeBSD_HEAD/bin/sh/tests= /builtins/locale1.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/printf1.0 /b= uilds/FreeBSD_HEAD/bin/sh/tests/builtins/printf2.0 /builds/FreeBSD_HEAD/bin= /sh/tests/builtins/printf3.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/pri= ntf4.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/read1.0 /builds/FreeBSD_H= EAD/bin/sh/tests/builtins/read1.0.stdout /builds/FreeBSD_HEAD/bin/sh/tests/= builtins/read2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/read3.0 /builds= /FreeBSD_HEAD/bin/sh/tests/builtins/read3.0.stdout /builds/FreeBSD_HEAD/bin= /sh/tests/builtins/read4.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/read4= .0.stdout /builds/FreeBSD_HEAD/bin/sh/tests/builtins/read5.0 /builds/FreeBS= D_HEAD/bin/sh/tests/builtins/read6.0 /builds/FreeBSD_HEAD/bin/sh/tests/buil= tins/read7.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/return1.0 /builds/F= reeBSD_HEAD/bin/sh/tests/builtins/return2.1 /builds/FreeBSD_HEAD/bin/sh/tes= ts/builtins/return3.1 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/return4.0 = /builds/FreeBSD_HEAD/bin/sh/tests/builtins/return5.0 /builds/FreeBSD_HEAD/b= in/sh/tests/builtins/return6.4 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/r= eturn7.4 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/return8.0 /builds/FreeB= SD_HEAD/bin/sh/tests/builtins/set1.0 /builds/FreeBSD_HEAD/bin/sh/tests/buil= tins/set2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/trap1.0 /builds/Free= BSD_HEAD/bin/sh/tests/builtins/trap10.0 /builds/FreeBSD_HEAD/bin/sh/tests/b= uiltins/trap11.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/trap12.0 /build= s/FreeBSD_HEAD/bin/sh/tests/builtins/trap13.0 /builds/FreeBSD_HEAD/bin/sh/t= ests/builtins/trap14.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/trap2.0 /= builds/FreeBSD_HEAD/bin/sh/tests/builtins/trap3.0 /builds/FreeBSD_HEAD/bin/= sh/tests/builtins/trap4.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/trap5.= 0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/trap6.0 /builds/FreeBSD_HEAD/b= in/sh/tests/builtins/trap7.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/tra= p8.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/trap9.0 /builds/FreeBSD_HEA= D/bin/sh/tests/builtins/type1.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/= type1.0.stderr /builds/FreeBSD_HEAD/bin/sh/tests/builtins/type2.0 /builds/F= reeBSD_HEAD/bin/sh/tests/builtins/type3.0 /builds/FreeBSD_HEAD/bin/sh/tests= /builtins/unalias.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/var-assign.0= /builds/FreeBSD_HEAD/bin/sh/tests/builtins/var-assign2.0 /builds/FreeBSD_H= EAD/bin/sh/tests/builtins/wait1.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtin= s/wait2.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/wait3.0 /builds/FreeBS= D_HEAD/bin/sh/tests/builtins/wait4.0 /builds/FreeBSD_HEAD/bin/sh/tests/buil= tins/wait5.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/wait6.0 /builds/Fre= eBSD_HEAD/bin/sh/tests/builtins/wait7.0 /builds/FreeBSD_HEAD/bin/sh/tests/b= uiltins/wait8.0 /builds/FreeBSD_HEAD/bin/sh/tests/builtins/wait9.127 /build= s/FreeBSD_HEAD/bin/sh/tests/builtins/wait10.0 (cd /builds/FreeBSD_HEAD/bin/sh/tests/builtins && make -f /builds/FreeBSD_H= EAD/bin/sh/tests/builtins/Makefile SUBDIR=3D _RECURSING_PROGS=3D install) install -o root -g wheel -m 555 functional_test =3D=3D=3D> bin/sh/tests/errors (install) install -o root -g wheel -m 555 functional_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/bin/sh/tests/errors/a= ssignment-error1.0 /builds/FreeBSD_HEAD/bin/sh/tests/errors/assignment-erro= r2.0 /builds/FreeBSD_HEAD/bin/sh/tests/errors/backquote-error1.0 /builds/Fr= eeBSD_HEAD/bin/sh/tests/errors/backquote-error2.0 /builds/FreeBSD_HEAD/bin/= sh/tests/errors/bad-binary1.126 /builds/FreeBSD_HEAD/bin/sh/tests/errors/ba= d-keyword1.0 /builds/FreeBSD_HEAD/bin/sh/tests/errors/bad-parm-exp1.0 /buil= ds/FreeBSD_HEAD/bin/sh/tests/errors/bad-parm-exp2.2 /builds/FreeBSD_HEAD/bi= n/sh/tests/errors/bad-parm-exp2.2.stderr /builds/FreeBSD_HEAD/bin/sh/tests/= errors/bad-parm-exp3.2 /builds/FreeBSD_HEAD/bin/sh/tests/errors/bad-parm-ex= p3.2.stderr /builds/FreeBSD_HEAD/bin/sh/tests/errors/bad-parm-exp4.2 /build= s/FreeBSD_HEAD/bin/sh/tests/errors/bad-parm-exp4.2.stderr /builds/FreeBSD_H= EAD/bin/sh/tests/errors/bad-parm-exp5.2 /builds/FreeBSD_HEAD/bin/sh/tests/e= rrors/bad-parm-exp5.2.stderr /builds/FreeBSD_HEAD/bin/sh/tests/errors/bad-p= arm-exp6.2 /builds/FreeBSD_HEAD/bin/sh/tests/errors/bad-parm-exp6.2.stderr = /builds/FreeBSD_HEAD/bin/sh/tests/errors/option-error.0 /builds/FreeBSD_HEA= D/bin/sh/tests/errors/redirection-error.0 /builds/FreeBSD_HEAD/bin/sh/tests= /errors/redirection-error2.2 /builds/FreeBSD_HEAD/bin/sh/tests/errors/redir= ection-error3.0 /builds/FreeBSD_HEAD/bin/sh/tests/errors/redirection-error4= .0 /builds/FreeBSD_HEAD/bin/sh/tests/errors/redirection-error5.0 /builds/Fr= eeBSD_HEAD/bin/sh/tests/errors/redirection-error6.0 /builds/FreeBSD_HEAD/bi= n/sh/tests/errors/redirection-error7.0 /builds/FreeBSD_HEAD/bin/sh/tests/er= rors/write-error1.0 (cd /builds/FreeBSD_HEAD/bin/sh/tests/errors && make -f /builds/FreeBSD_HEA= D/bin/sh/tests/errors/Makefile SUBDIR=3D _RECURSING_PROGS=3D install) install -o root -g wheel -m 555 functional_test =3D=3D=3D> bin/sh/tests/execution (install) install -o root -g wheel -m 555 functional_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/bin/sh/tests/executio= n/bg1.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/bg2.0 /builds/FreeBSD_H= EAD/bin/sh/tests/execution/bg3.0 /builds/FreeBSD_HEAD/bin/sh/tests/executio= n/bg4.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/bg5.0 /builds/FreeBSD_H= EAD/bin/sh/tests/execution/bg6.0 /builds/FreeBSD_HEAD/bin/sh/tests/executio= n/bg6.0.stdout /builds/FreeBSD_HEAD/bin/sh/tests/execution/bg7.0 /builds/Fr= eeBSD_HEAD/bin/sh/tests/execution/bg8.0 /builds/FreeBSD_HEAD/bin/sh/tests/e= xecution/bg9.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/bg10.0 /builds/F= reeBSD_HEAD/bin/sh/tests/execution/bg10.0.stdout /builds/FreeBSD_HEAD/bin/s= h/tests/execution/fork1.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/fork2= .0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/fork3.0 /builds/FreeBSD_HEAD= /bin/sh/tests/execution/func1.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution= /func2.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/func3.0 /builds/FreeBS= D_HEAD/bin/sh/tests/execution/hash1.0 /builds/FreeBSD_HEAD/bin/sh/tests/exe= cution/int-cmd1.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/killed1.0 /bu= ilds/FreeBSD_HEAD/bin/sh/tests/execution/killed2.0 /builds/FreeBSD_HEAD/bin= /sh/tests/execution/not1.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/not2= .0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/path1.0 /builds/FreeBSD_HEAD= /bin/sh/tests/execution/redir1.0 /builds/FreeBSD_HEAD/bin/sh/tests/executio= n/redir2.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/redir3.0 /builds/Fre= eBSD_HEAD/bin/sh/tests/execution/redir4.0 /builds/FreeBSD_HEAD/bin/sh/tests= /execution/redir5.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/redir6.0 /b= uilds/FreeBSD_HEAD/bin/sh/tests/execution/redir7.0 /builds/FreeBSD_HEAD/bin= /sh/tests/execution/set-n1.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/se= t-n2.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/set-n3.0 /builds/FreeBSD= _HEAD/bin/sh/tests/execution/set-n4.0 /builds/FreeBSD_HEAD/bin/sh/tests/exe= cution/set-x1.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/set-x2.0 /build= s/FreeBSD_HEAD/bin/sh/tests/execution/set-x3.0 /builds/FreeBSD_HEAD/bin/sh/= tests/execution/shellproc1.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/su= bshell1.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/subshell1.0.stdout /b= uilds/FreeBSD_HEAD/bin/sh/tests/execution/subshell2.0 /builds/FreeBSD_HEAD/= bin/sh/tests/execution/subshell3.0 /builds/FreeBSD_HEAD/bin/sh/tests/execut= ion/subshell4.0 /builds/FreeBSD_HEAD/bin/sh/tests/execution/unknown1.0 /bui= lds/FreeBSD_HEAD/bin/sh/tests/execution/var-assign1.0 (cd /builds/FreeBSD_HEAD/bin/sh/tests/execution && make -f /builds/FreeBSD_= HEAD/bin/sh/tests/execution/Makefile SUBDIR=3D _RECURSING_PROGS=3D install= ) install -o root -g wheel -m 555 functional_test =3D=3D=3D> bin/sh/tests/expansion (install) install -o root -g wheel -m 555 functional_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/bin/sh/tests/expansio= n/arith1.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/arith2.0 /builds/Fre= eBSD_HEAD/bin/sh/tests/expansion/arith3.0 /builds/FreeBSD_HEAD/bin/sh/tests= /expansion/arith4.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/arith5.0 /b= uilds/FreeBSD_HEAD/bin/sh/tests/expansion/arith6.0 /builds/FreeBSD_HEAD/bin= /sh/tests/expansion/arith7.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/ar= ith8.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/arith9.0 /builds/FreeBSD= _HEAD/bin/sh/tests/expansion/arith10.0 /builds/FreeBSD_HEAD/bin/sh/tests/ex= pansion/arith11.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/arith12.0 /bu= ilds/FreeBSD_HEAD/bin/sh/tests/expansion/arith13.0 /builds/FreeBSD_HEAD/bin= /sh/tests/expansion/arith14.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/a= ssign1.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/cmdsubst1.0 /builds/Fr= eeBSD_HEAD/bin/sh/tests/expansion/cmdsubst2.0 /builds/FreeBSD_HEAD/bin/sh/t= ests/expansion/cmdsubst3.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/cmds= ubst4.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/cmdsubst5.0 /builds/Fre= eBSD_HEAD/bin/sh/tests/expansion/cmdsubst6.0 /builds/FreeBSD_HEAD/bin/sh/te= sts/expansion/cmdsubst7.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/cmdsu= bst8.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/cmdsubst9.0 /builds/Free= BSD_HEAD/bin/sh/tests/expansion/cmdsubst10.0 /builds/FreeBSD_HEAD/bin/sh/te= sts/expansion/cmdsubst11.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/cmds= ubst12.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/cmdsubst13.0 /builds/F= reeBSD_HEAD/bin/sh/tests/expansion/cmdsubst14.0 /builds/FreeBSD_HEAD/bin/sh= /tests/expansion/cmdsubst15.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/c= mdsubst16.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/cmdsubst17.0 /build= s/FreeBSD_HEAD/bin/sh/tests/expansion/export1.0 /builds/FreeBSD_HEAD/bin/sh= /tests/expansion/export2.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/expo= rt3.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/heredoc1.0 /builds/FreeBS= D_HEAD/bin/sh/tests/expansion/heredoc2.0 /builds/FreeBSD_HEAD/bin/sh/tests/= expansion/ifs1.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/ifs2.0 /builds= /FreeBSD_HEAD/bin/sh/tests/expansion/ifs3.0 /builds/FreeBSD_HEAD/bin/sh/tes= ts/expansion/ifs4.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/length1.0 /= builds/FreeBSD_HEAD/bin/sh/tests/expansion/length2.0 /builds/FreeBSD_HEAD/b= in/sh/tests/expansion/length3.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion= /length4.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/length5.0 /builds/Fr= eeBSD_HEAD/bin/sh/tests/expansion/length6.0 /builds/FreeBSD_HEAD/bin/sh/tes= ts/expansion/length7.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/length8.= 0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/local1.0 /builds/FreeBSD_HEAD= /bin/sh/tests/expansion/local2.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansio= n/pathname1.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/pathname2.0 /buil= ds/FreeBSD_HEAD/bin/sh/tests/expansion/pathname3.0 /builds/FreeBSD_HEAD/bin= /sh/tests/expansion/pathname4.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion= /plus-minus1.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/plus-minus2.0 /b= uilds/FreeBSD_HEAD/bin/sh/tests/expansion/plus-minus3.0 /builds/FreeBSD_HEA= D/bin/sh/tests/expansion/plus-minus4.0 /builds/FreeBSD_HEAD/bin/sh/tests/ex= pansion/plus-minus5.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/plus-minu= s6.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/plus-minus7.0 /builds/Free= BSD_HEAD/bin/sh/tests/expansion/plus-minus8.0 /builds/FreeBSD_HEAD/bin/sh/t= ests/expansion/question1.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/read= only1.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/redir1.0 /builds/FreeBS= D_HEAD/bin/sh/tests/expansion/set-u1.0 /builds/FreeBSD_HEAD/bin/sh/tests/ex= pansion/set-u2.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/set-u3.0 /buil= ds/FreeBSD_HEAD/bin/sh/tests/expansion/tilde1.0 /builds/FreeBSD_HEAD/bin/sh= /tests/expansion/tilde2.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/trim1= .0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/trim2.0 /builds/FreeBSD_HEAD= /bin/sh/tests/expansion/trim3.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion= /trim4.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/trim5.0 /builds/FreeBS= D_HEAD/bin/sh/tests/expansion/trim6.0 /builds/FreeBSD_HEAD/bin/sh/tests/exp= ansion/trim7.0 /builds/FreeBSD_HEAD/bin/sh/tests/expansion/trim8.0 (cd /builds/FreeBSD_HEAD/bin/sh/tests/expansion && make -f /builds/FreeBSD_= HEAD/bin/sh/tests/expansion/Makefile SUBDIR=3D _RECURSING_PROGS=3D install= ) install -o root -g wheel -m 555 functional_test =3D=3D=3D> bin/sh/tests/parameters (install) install -o root -g wheel -m 555 functional_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/bin/sh/tests/paramete= rs/env1.0 /builds/FreeBSD_HEAD/bin/sh/tests/parameters/exitstatus1.0 /build= s/FreeBSD_HEAD/bin/sh/tests/parameters/mail1.0 /builds/FreeBSD_HEAD/bin/sh/= tests/parameters/mail2.0 /builds/FreeBSD_HEAD/bin/sh/tests/parameters/optin= d1.0 /builds/FreeBSD_HEAD/bin/sh/tests/parameters/optind2.0 /builds/FreeBSD= _HEAD/bin/sh/tests/parameters/positional1.0 /builds/FreeBSD_HEAD/bin/sh/tes= ts/parameters/positional2.0 /builds/FreeBSD_HEAD/bin/sh/tests/parameters/po= sitional3.0 /builds/FreeBSD_HEAD/bin/sh/tests/parameters/positional4.0 /bui= lds/FreeBSD_HEAD/bin/sh/tests/parameters/positional5.0 /builds/FreeBSD_HEAD= /bin/sh/tests/parameters/positional6.0 /builds/FreeBSD_HEAD/bin/sh/tests/pa= rameters/positional7.0 /builds/FreeBSD_HEAD/bin/sh/tests/parameters/pwd1.0 = /builds/FreeBSD_HEAD/bin/sh/tests/parameters/pwd2.0 (cd /builds/FreeBSD_HEAD/bin/sh/tests/parameters && make -f /builds/FreeBSD= _HEAD/bin/sh/tests/parameters/Makefile SUBDIR=3D _RECURSING_PROGS=3D insta= ll) install -o root -g wheel -m 555 functional_test =3D=3D=3D> bin/sh/tests/parser (install) make[7]: "/builds/FreeBSD_HEAD/share/mk/bsd.compiler.mk" line 37: Unable to= determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[6]: stopped in /builds/FreeBSD_HEAD/bin/sh/tests *** Error code 1 Stop. make[5]: stopped in /builds/FreeBSD_HEAD/bin/sh *** Error code 1 Stop. make[4]: stopped in /builds/FreeBSD_HEAD/bin *** Error code 1 Stop. make[3]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[2]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 09:42:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A9D2F0D for ; Sat, 22 Nov 2014 09:42:08 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 39A68B05 for ; Sat, 22 Nov 2014 09:42:08 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1F44B340 for ; Sat, 22 Nov 2014 09:42:08 +0000 (UTC) Date: Sat, 22 Nov 2014 09:42:07 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <144654357.3.1416649327976.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <857671197.2.1416639206621.JavaMail.jenkins@jenkins-9.freebsd.org> References: <857671197.2.1416639206621.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #474 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 09:42:08 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 11:47:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F9D368A for ; Sat, 22 Nov 2014 11:47:35 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 70D7C7BA for ; Sat, 22 Nov 2014 11:47:35 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6E89036B for ; Sat, 22 Nov 2014 11:47:35 +0000 (UTC) Date: Sat, 22 Nov 2014 11:47:35 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1703138070.4.1416656855419.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #293 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 11:47:35 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 11:57:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E5DFA3D for ; Sat, 22 Nov 2014 11:57:30 +0000 (UTC) Received: from st11p00mm-asmtp003.mac.com (st11p00mm-asmtpout003.mac.com [17.172.81.2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34EB08AD for ; Sat, 22 Nov 2014 11:57:29 +0000 (UTC) Received: from andersbo-mac.local (ti0025a400-7294.bb.online.no [85.167.207.148]) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NFF00GSKVVLYP10@st11p00mm-asmtp003.mac.com> for freebsd-current@freebsd.org; Sat, 22 Nov 2014 11:57:23 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-22_01:2014-11-21,2014-11-21,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411220099 Message-id: <54707A20.7060708@icloud.com> Date: Sat, 22 Nov 2014 12:57:20 +0100 From: Anders Bolt-Evensen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-version: 1.0 To: freebsd-current@freebsd.org Subject: Starting intel driver fails on boot Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 11:57:30 -0000 Hello. A few months ago I sent an e-mail to this mailing list and reported about problems related to starting X on FreeBSD when using EFI mode. I "fixed" that problem by using the "scfb" driver from ports. Today I, using "Xorg -configure", was playing around with the intel driver, since my Mac has a built-in Intel HD 3000 graphics card as well as a Radeon HD 6770M. For some reason, when I attempt to start X with the intel driver, the screen freezes. However, if I start X using scfb and then manually load the i915kms kernel module, the system works perfectly fine until I leave X (at that time the screen freezes again). When using the xorg.conf.new file generated by Xorg -configure, the system prefers to use the intel driver rather than the radeon driver (neither of which seem to work). Taking a look at the output of dmesg -a from a verbose boot, I noted the following messages: info: [drm] Initialized drm 1.1.0 20060810 drmn1: on vgapci1 vgapci1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 268 to local APIC 2 vector 50 vgapci1: using IRQ 268 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xa0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0x0 iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0x0 iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0x0 iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0x0 iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0x0 iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0x0 iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0x0 iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off drmn1: taking over the fictitious range 0xa0000000-0xb0000000 info: [drm] Connector LVDS-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.LVDS-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector VGA-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.VGA-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector HDMI-A-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.HDMI-A-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector DP-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.DP-1 info: [drm] - kern.vt.fb.default_mode fbd1 on drmn1 VT: Replacing driver "efifb" with new "fb". info: [drm] Changing LVDS panel from (+hsync, +vsync) to (-hsync, -vsync) info: [drm] Initialized i915 1.6.0 20080730 error: [drm:pid0:intel_lvds_enable] *ERROR* timed out waiting for panel to power off Can someone please tell me what those messages (especially the last 4 messages) mean? Are they somehow related to the reason why the screen freezes when the intel driver is loaded during the launch of X? Output of uname -a: FreeBSD andersbo-mac.local 11.0-CURRENT FreeBSD 11.0-CURRENT #11 r274793M: Fri Nov 21 16:26:45 CET 2014 root@andersbo-mac.local:/usr/obj/usr/src/sys/KERNEL amd64 From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 14:34:58 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACDDEC33; Sat, 22 Nov 2014 14:34:58 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 69C1990E; Sat, 22 Nov 2014 14:34:57 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id sAMEYuD1070354; Sat, 22 Nov 2014 06:34:56 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id sAMEYuVw070353; Sat, 22 Nov 2014 06:34:56 -0800 (PST) (envelope-from david) Date: Sat, 22 Nov 2014 06:34:56 -0800 From: David Wolfskill To: current@freebsd.org Subject: Problem with r274819? asr_timeout() not found Message-ID: <20141122143456.GU31571@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org, smh@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rpOPesfUXqAMaEty" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: smh@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 14:34:58 -0000 --rpOPesfUXqAMaEty Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Running: FreeBSD g1-253.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1434 r274= 790M/274790:1100047: Fri Nov 21 06:07:24 PST 2014 root@g1-253.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386 Updated sources to r274845; "make buildworld" is OK, but "make buildkernel": =2E.. >>> stage 3.2: building everything =2E.. =3D=3D=3D> asr (all) --- asr.o --- --- all_subdir_asmc --- ctfconvert -L VERSION -g asmc.o --- all_subdir_asr --- clang -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostd= inc -DHAVE_KERNEL_OPTION_HEADERS -include /common/S4/obj/usr/src/sys/GENE= RIC/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -fno-common= -g -I/common/S4/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -f= freestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Qunused-argumen= ts -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-e= xterns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -= Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-includ= e-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-erro= r-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -W= no-array-bounds -mno-aes -mno-avx -Qunused-arguments -c /usr/src/sys/modul= es/asr/../../dev/asr/asr.c --- all_subdir_asmc --- --- asmc.kld --- ld -d -warn-common -r -d -o asmc.kld asmc.o ctfmerge -L VERSION -g -o asmc.kld asmc.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk asmc.kld export_syms | xargs -J% ob= jcopy % asmc.kld --- asmc.ko.debug --- ld -Bshareable -d -warn-common -o asmc.ko.debug asmc.kld --- asmc.ko.symbols --- objcopy --only-keep-debug asmc.ko.debug asmc.ko.symbols --- all_subdir_asr --- /usr/src/sys/modules/asr/../../dev/asr/asr.c:393:15: error: use of undeclar= ed identifier 'asr_timeout' ch =3D timeout(asr_timeout, (caddr_t)ccb, ^ 1 error generated. --- all_subdir_asmc --- --- asmc.ko --- --- all_subdir_asr --- *** [asr.o] Error code 1 bmake: stopped in /usr/src/sys/modules/asr 1 error bmake: stopped in /usr/src/sys/modules/asr --- all_subdir_asmc --- objcopy --strip-debug --add-gnu-debuglink=3Dasmc.ko.symbols asmc.ko.debug a= smc.ko --- all_subdir_asr --- *** [all_subdir_asr] Error code 2 bmake: stopped in /usr/src/sys/modules --- all_subdir_asmc --- A failure has been detected in another branch of the parallel make bmake: stopped in /usr/src/sys/modules/asmc *** [all_subdir_asmc] Error code 2 bmake: stopped in /usr/src/sys/modules --- all_subdir_arcmsr --- ctfconvert -L VERSION -g arcmsr.o A failure has been detected in another branch of the parallel make bmake: stopped in /usr/src/sys/modules/arcmsr *** [all_subdir_arcmsr] Error code 2 bmake: stopped in /usr/src/sys/modules --- all_subdir_aic7xxx --- --- aic79xx.o --- ctfconvert -L VERSION -g aic79xx.o A failure has been detected in another branch of the parallel make bmake: stopped in /usr/src/sys/modules/aic7xxx/ahd *** [_sub.all] Error code 2 bmake: stopped in /usr/src/sys/modules/aic7xxx 1 error bmake: stopped in /usr/src/sys/modules/aic7xxx *** [all_subdir_aic7xxx] Error code 2 bmake: stopped in /usr/src/sys/modules 4 errors bmake: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 bmake: stopped in /common/S4/obj/usr/src/sys/GENERIC 1 error bmake: stopped in /common/S4/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 bmake: stopped in /usr/src 1 error bmake: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src freebeast(11.0-C)[3]=20 And r274819 did: Index: asr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- asr.c (revision 274818) +++ asr.c (revision 274819) @@ -386,8 +386,12 @@ STAILQ_HEAD_INITIALIZER(Asr_softc_list); =20 static __inline void -set_ccb_timeout_ch(union asr_ccb *ccb, struct callout_handle ch) +set_ccb_timeout_ch(union asr_ccb *ccb) { + struct callout_handle ch; + + ch =3D timeout(asr_timeout, (caddr_t)ccb, + (int)((u_int64_t)(ccb->ccb_h.timeout) * (u_int32_t)hz / 1000)); ccb->ccb_h.sim_priv.entries[0].ptr =3D ch.callout; } =20 @@ -812,8 +816,7 @@ */ ccb->ccb_h.timeout =3D 6 * 60 * 1000; } - set_ccb_timeout_ch(ccb, timeout(asr_timeout, (caddr_t)ccb, - (ccb->ccb_h.timeout * hz) / 1000)); + set_ccb_timeout_ch(ccb); } splx(s); } /* ASR_ccbAdd */ @@ -1337,9 +1340,7 @@ cam_sim_unit(xpt_path_sim(ccb->ccb_h.path)), s); if (ASR_reset (sc) =3D=3D ENXIO) { /* Try again later */ - set_ccb_timeout_ch(ccb, timeout(asr_timeout, - (caddr_t)ccb, - (ccb->ccb_h.timeout * hz) / 1000)); + set_ccb_timeout_ch(ccb); } return; } @@ -1353,9 +1354,7 @@ if ((ccb->ccb_h.status & CAM_STATUS_MASK) =3D=3D CAM_CMD_TIMEOUT) { debug_asr_printf (" AGAIN\nreinitializing adapter\n"); if (ASR_reset (sc) =3D=3D ENXIO) { - set_ccb_timeout_ch(ccb, timeout(asr_timeout, - (caddr_t)ccb, - (ccb->ccb_h.timeout * hz) / 1000)); + set_ccb_timeout_ch(ccb); } splx(s); return; @@ -1364,8 +1363,7 @@ /* If the BUS reset does not take, then an adapter reset is next! */ ccb->ccb_h.status &=3D ~CAM_STATUS_MASK; ccb->ccb_h.status |=3D CAM_CMD_TIMEOUT; - set_ccb_timeout_ch(ccb, timeout(asr_timeout, (caddr_t)ccb, - (ccb->ccb_h.timeout * hz) / 1000)); + set_ccb_timeout_ch(ccb); ASR_resetBus (sc, cam_sim_bus(xpt_path_sim(ccb->ccb_h.path))); xpt_async (AC_BUS_RESET, ccb->ccb_h.path, NULL); splx(s); Maybe something was omitted from the commit? Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --rpOPesfUXqAMaEty Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUcJ8QXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7ph4QAIpIr/9Rh++OCdCf85yRP2xu zoq25VlhqtZV5qwdfig9CqtEQnAwv7LykKdjMGd+kyE8KJkzUaBM5cUw6cCrqpQM EinzWW118lhLa7ZY93st/1VtqUPoVcu5lZsgOHQSiR4sFj0u5Y/1yTGPcCCIuLst N5S/hd7wWtExpU99m50Ytg7QLDg+XVXz0qlQ/teGVJWtWP1sWOmKBx0iw/vqY0US XomTQHRoUF5xjx/COr2qeLeqqTSFhI6r8MrmcBWQrWHBnXGRMjUQskyA0dNQXbTE q9krzKgXGmkG1BlLcCFA2RZBN89J7wW+zx75mhFHrVpf2A0H689fh94ccAG5oUKu p8O1Izk0qj2jP5EACWe5e9lWcssR/oIl8wsYC8Zww/k9bp4DHZ3mFHFEcGxX7tn6 oYLkqQviwZ+L29waA2yHAFN+1oUw0kA5SSjnKte3QreOpL4ql0PGL00qtjpuKjgz xLLV30qy5J0oLN9cZ0djMW3OqSs57M/viFbj3jI68FGl12VX1DqBdNCEsUwCmx2/ xLFFTL/sfr5hDXlnGNHmj8m3HKyLzQNyFEx56/eAIKokdaQGaBLh3DwWFFSmVZOH ILjaNlKSJ4VZudMKu9yzJCJv5P/1GcWU4pHI6Srifqv6bRqHoOwkPXhKL2IAEx5I ESHLvkwvuz1kmalF3JU9 =EtPQ -----END PGP SIGNATURE----- --rpOPesfUXqAMaEty-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 14:58:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C16B515A for ; Sat, 22 Nov 2014 14:58:09 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B0247AE0 for ; Sat, 22 Nov 2014 14:58:09 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2276B39B for ; Sat, 22 Nov 2014 14:58:10 +0000 (UTC) Date: Sat, 22 Nov 2014 14:58:10 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1054013936.5.1416668290009.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1703138070.4.1416656855419.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1703138070.4.1416656855419.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #294 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 14:58:09 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 15:51:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E58A1C2D for ; Sat, 22 Nov 2014 15:51:32 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B71EF47 for ; Sat, 22 Nov 2014 15:51:32 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x12so8883626wgg.36 for ; Sat, 22 Nov 2014 07:51:31 -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=eJMT0a2lSWwF3g5rtVq10qB5vzZJfXO0/DPqvOKqfXY=; b=msdPT70bDmyF+gW//0VNeITKc3i33wxt96Rk7jZj6T6y7gagIM1xvH/9nrEhE6ENC7 EKHuM2t9k9PFAkFKMaYvGD3gh1Ek3w84bBmdjQ3vLdVy0C21G7B0ZCQqkFysfZN6ZuKQ QmYrqsXxPaezYI67BVuh0AfZ7L34Bs7SludPFaiq4EdIlEiGWa9rANjozRoQhmJ/vKMB PlCIhlJZhg3kSepbaAWHoqwjduoO1qPIod2HbICmYMkXHpw29+574WArIes4y2v6LN9c kZs4rQFw+ChPkoDFUO4uaofJammhXTwnc1EAL9N4nOjLIvhafA5RS5W18L8pdVsKM+7s mtLA== MIME-Version: 1.0 X-Received: by 10.194.178.231 with SMTP id db7mr17650506wjc.112.1416671490953; Sat, 22 Nov 2014 07:51:30 -0800 (PST) Received: by 10.194.45.199 with HTTP; Sat, 22 Nov 2014 07:51:30 -0800 (PST) Date: Sat, 22 Nov 2014 17:51:30 +0200 Message-ID: Subject: How much memory do I need for buildworld? From: Rostislav Krasny To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 15:51:33 -0000 Hi, I've a fresh FreeBSD 10.1 installed on an old 32-bit machine. I've checked out revision 274850 of the base sources and ran 'make buildworld'. After some time it has failed: ===> lib/clang/libllvmx86disassembler (depend) tblgen -gen-disassembler -I /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/include -I /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target/X86 -d X86GenDisassemblerTables.inc.d -o X86GenDisassemblerTables.inc.h /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target/X86/X86.td *** Signal 9 Stop. make[4]: stopped in /usr/src/lib/clang/libllvmx86disassembler *** Error code 1 According to /var/log/messages it was killed because of out of memory: Nov 22 16:55:13 mercury kernel: swap_pager: out of swap space Nov 22 16:55:13 mercury kernel: swap_pager_getswapspace(16): failed Nov 22 16:55:13 mercury kernel: pid 22841 (tblgen), uid 0, was killed: out of swap space This machine has 256MB of RAM and one 64MB swap partition. Previously I used FreeBSD 7.4-CURRENT on this machine with two swap partitions of 64MB each and never had such a problem. I use it as a router, i.e. there is no X and no other memory greedy processes. Could it be related to an llvm bug fixed by following commit? http://svnweb.freebsd.org/base?view=revision&revision=274696 From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 17:01:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94596965 for ; Sat, 22 Nov 2014 17:01:42 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EA6F91C for ; Sat, 22 Nov 2014 17:01:41 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b130:3e2f:8715:b8f9] (unknown [IPv6:2001:7b8:3a7:0:b130:3e2f:8715:b8f9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5AF67B80A; Sat, 22 Nov 2014 18:01:31 +0100 (CET) Subject: Re: How much memory do I need for buildworld? Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B193BAA1-52EF-4874-A31C-E0CF6B8FACD5"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b1 From: Dimitry Andric In-Reply-To: Date: Sat, 22 Nov 2014 18:01:23 +0100 Message-Id: <5EBF0BB1-1E2A-4517-A7BB-22FD3150FF06@FreeBSD.org> References: To: Rostislav Krasny X-Mailer: Apple Mail (2.1993) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 17:01:42 -0000 --Apple-Mail=_B193BAA1-52EF-4874-A31C-E0CF6B8FACD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Nov 2014, at 16:51, Rostislav Krasny wrote: > I've a fresh FreeBSD 10.1 installed on an old 32-bit machine. I've > checked out revision 274850 of the base sources and ran 'make > buildworld'. After some time it has failed: >=20 > =3D=3D=3D> lib/clang/libllvmx86disassembler (depend) > tblgen -gen-disassembler -I > = /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/include > -I = /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target= /X86 > -d X86GenDisassemblerTables.inc.d -o X86GenDisassemblerTables.inc.h > = /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target= /X86/X86.td > *** Signal 9 >=20 > Stop. > make[4]: stopped in /usr/src/lib/clang/libllvmx86disassembler > *** Error code 1 >=20 >=20 > According to /var/log/messages it was killed because of out of memory: >=20 > Nov 22 16:55:13 mercury kernel: swap_pager: out of swap space > Nov 22 16:55:13 mercury kernel: swap_pager_getswapspace(16): failed > Nov 22 16:55:13 mercury kernel: pid 22841 (tblgen), uid 0, was killed: > out of swap space >=20 > This machine has 256MB of RAM and one 64MB swap partition. This is most likely the problem: you need more RAM for this particular instance of tblgen. On my -CURRENT i386 box, it takes ~369MiB of RSS to build the X86 disassembler tables. I'm surprised you didn't run into OOM problems earlier, with so little memory. For such "router" like machines, it is obviously easier to do the build on a fast desktop machine, then install over NFS, or rsync /usr/src and /usr/obj to the target machine. > Previously > I used FreeBSD 7.4-CURRENT on this machine with two swap partitions of > 64MB each and never had such a problem. I use it as a router, i.e. > there is no X and no other memory greedy processes. Yes, 7.4 is much smaller, and does not have any big C++ programs in it, so a buildworld is more likely to succeed on small memory machines. > Could it be related to an llvm bug fixed by following commit? >=20 > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D274696 No, this is unlikely. This problem only occurred 1) in the compiler itself, 2) very specific ports, and 3) when compiling with debug info enabled. -Dimitry --Apple-Mail=_B193BAA1-52EF-4874-A31C-E0CF6B8FACD5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlRwwWkACgkQsF6jCi4glqMNHQCg3vLIGho553FMm50mRgLFRWvx dNwAoJyvpjuhMi0W7rpSYcIarAD+Yrxj =ShNo -----END PGP SIGNATURE----- --Apple-Mail=_B193BAA1-52EF-4874-A31C-E0CF6B8FACD5-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 15:01:19 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A50483A5 for ; Sat, 22 Nov 2014 15:01:19 +0000 (UTC) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3507BB8C for ; Sat, 22 Nov 2014 15:01:18 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id y19so8871190wgg.7 for ; Sat, 22 Nov 2014 07:01:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6+sT4S9Rt4T7vOcldcRos+hifB1PzJWiRZ4pTqWuuek=; b=AiU6bxPXPFSuD1O/8XzZUHOW4bX5r+zqoQTdiH16xLRNS7wMM/VUrsomUjMOCcJ36g 69plAXkBBrHARaHE/WT0Rc1xsH4KcDMA5hxUSZ7luUexWFHKuoHm3oUHQSt2GfsXvVA5 cKdHuIDeA1NXZuJv8M0F+nxXTKK3wljcfUO/UHsh37VS/2RezLC4XGbiKaiSOK0368+m mGlhu3AXGQyHg9OjG2taYqdb1kr9ImD4EPT8/amiIFmgrGFvvlKLdT9nqiAm5ULfCyuh ymCCw4yPC8rSpWfZ1sR4lPVOmXJlIhm5Bxn4i7199Gi+z2bSvzRfyI0fSqWqu2DuNKxj fDeA== X-Gm-Message-State: ALoCoQn1rHhj/AGud6kIjov8bc1QwwMe4M67fBVWmKqya7efJzUEKn/vAQrBlbKNMDgceCkkzOKU X-Received: by 10.180.93.132 with SMTP id cu4mr6325874wib.46.1416668476467; Sat, 22 Nov 2014 07:01:16 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id r10sm3560362wiy.19.2014.11.22.07.01.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Nov 2014 07:01:15 -0800 (PST) From: Steven Hartland X-Google-Original-From: Steven Hartland Message-ID: <5470A53A.4010008@freebsd.org> Date: Sat, 22 Nov 2014 15:01:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Wolfskill , current@freebsd.org Subject: Re: Problem with r274819? asr_timeout() not found References: <20141122143456.GU31571@albert.catwhisker.org> In-Reply-To: <20141122143456.GU31571@albert.catwhisker.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Nov 2014 17:03:48 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 15:01:19 -0000 Fixed, sorry forgot asr wasn't in GENERIC, so missed it in testing. On 22/11/2014 14:34, David Wolfskill wrote: > Running: > FreeBSD g1-253.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1434 r274790M/274790:1100047: Fri Nov 21 06:07:24 PST 2014 root@g1-253.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 > > > Updated sources to r274845; "make buildworld" is OK, but "make buildkernel": > > ... >>>> stage 3.2: building everything > ... > ===> asr (all) > --- asr.o --- > --- all_subdir_asmc --- > ctfconvert -L VERSION -g asmc.o > --- all_subdir_asr --- > clang -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /common/S4/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -fno-common -g -I/common/S4/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Qunused-arguments -std=iso9899:1999 -fstack-protector -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-array-bounds -mno-aes -mno-avx -Qunused-arguments -c /usr/src/sys/modules/asr/../../dev/asr/asr.c > --- all_subdir_asmc --- > --- asmc.kld --- > ld -d -warn-common -r -d -o asmc.kld asmc.o > ctfmerge -L VERSION -g -o asmc.kld asmc.o > :> export_syms > awk -f /usr/src/sys/conf/kmod_syms.awk asmc.kld export_syms | xargs -J% objcopy % asmc.kld > --- asmc.ko.debug --- > ld -Bshareable -d -warn-common -o asmc.ko.debug asmc.kld > --- asmc.ko.symbols --- > objcopy --only-keep-debug asmc.ko.debug asmc.ko.symbols > --- all_subdir_asr --- > /usr/src/sys/modules/asr/../../dev/asr/asr.c:393:15: error: use of undeclared identifier 'asr_timeout' > ch = timeout(asr_timeout, (caddr_t)ccb, > ^ > 1 error generated. > --- all_subdir_asmc --- > --- asmc.ko --- > --- all_subdir_asr --- > *** [asr.o] Error code 1 > > bmake: stopped in /usr/src/sys/modules/asr > 1 error > > bmake: stopped in /usr/src/sys/modules/asr > --- all_subdir_asmc --- > objcopy --strip-debug --add-gnu-debuglink=asmc.ko.symbols asmc.ko.debug asmc.ko > --- all_subdir_asr --- > *** [all_subdir_asr] Error code 2 > > bmake: stopped in /usr/src/sys/modules > --- all_subdir_asmc --- > A failure has been detected in another branch of the parallel make > > bmake: stopped in /usr/src/sys/modules/asmc > *** [all_subdir_asmc] Error code 2 > > bmake: stopped in /usr/src/sys/modules > --- all_subdir_arcmsr --- > ctfconvert -L VERSION -g arcmsr.o > A failure has been detected in another branch of the parallel make > > bmake: stopped in /usr/src/sys/modules/arcmsr > *** [all_subdir_arcmsr] Error code 2 > > bmake: stopped in /usr/src/sys/modules > --- all_subdir_aic7xxx --- > --- aic79xx.o --- > ctfconvert -L VERSION -g aic79xx.o > A failure has been detected in another branch of the parallel make > > bmake: stopped in /usr/src/sys/modules/aic7xxx/ahd > *** [_sub.all] Error code 2 > > bmake: stopped in /usr/src/sys/modules/aic7xxx > 1 error > > bmake: stopped in /usr/src/sys/modules/aic7xxx > *** [all_subdir_aic7xxx] Error code 2 > > bmake: stopped in /usr/src/sys/modules > 4 errors > > bmake: stopped in /usr/src/sys/modules > *** [modules-all] Error code 2 > > bmake: stopped in /common/S4/obj/usr/src/sys/GENERIC > 1 error > > bmake: stopped in /common/S4/obj/usr/src/sys/GENERIC > *** [buildkernel] Error code 2 > > bmake: stopped in /usr/src > 1 error > > bmake: stopped in /usr/src > *** [buildkernel] Error code 2 > > make: stopped in /usr/src > 1 error > > make: stopped in /usr/src > freebeast(11.0-C)[3] > > > And r274819 did: > > Index: asr.c > =================================================================== > --- asr.c (revision 274818) > +++ asr.c (revision 274819) > @@ -386,8 +386,12 @@ > STAILQ_HEAD_INITIALIZER(Asr_softc_list); > > static __inline void > -set_ccb_timeout_ch(union asr_ccb *ccb, struct callout_handle ch) > +set_ccb_timeout_ch(union asr_ccb *ccb) > { > + struct callout_handle ch; > + > + ch = timeout(asr_timeout, (caddr_t)ccb, > + (int)((u_int64_t)(ccb->ccb_h.timeout) * (u_int32_t)hz / 1000)); > ccb->ccb_h.sim_priv.entries[0].ptr = ch.callout; > } > > @@ -812,8 +816,7 @@ > */ > ccb->ccb_h.timeout = 6 * 60 * 1000; > } > - set_ccb_timeout_ch(ccb, timeout(asr_timeout, (caddr_t)ccb, > - (ccb->ccb_h.timeout * hz) / 1000)); > + set_ccb_timeout_ch(ccb); > } > splx(s); > } /* ASR_ccbAdd */ > @@ -1337,9 +1340,7 @@ > cam_sim_unit(xpt_path_sim(ccb->ccb_h.path)), s); > if (ASR_reset (sc) == ENXIO) { > /* Try again later */ > - set_ccb_timeout_ch(ccb, timeout(asr_timeout, > - (caddr_t)ccb, > - (ccb->ccb_h.timeout * hz) / 1000)); > + set_ccb_timeout_ch(ccb); > } > return; > } > @@ -1353,9 +1354,7 @@ > if ((ccb->ccb_h.status & CAM_STATUS_MASK) == CAM_CMD_TIMEOUT) { > debug_asr_printf (" AGAIN\nreinitializing adapter\n"); > if (ASR_reset (sc) == ENXIO) { > - set_ccb_timeout_ch(ccb, timeout(asr_timeout, > - (caddr_t)ccb, > - (ccb->ccb_h.timeout * hz) / 1000)); > + set_ccb_timeout_ch(ccb); > } > splx(s); > return; > @@ -1364,8 +1363,7 @@ > /* If the BUS reset does not take, then an adapter reset is next! */ > ccb->ccb_h.status &= ~CAM_STATUS_MASK; > ccb->ccb_h.status |= CAM_CMD_TIMEOUT; > - set_ccb_timeout_ch(ccb, timeout(asr_timeout, (caddr_t)ccb, > - (ccb->ccb_h.timeout * hz) / 1000)); > + set_ccb_timeout_ch(ccb); > ASR_resetBus (sc, cam_sim_bus(xpt_path_sim(ccb->ccb_h.path))); > xpt_async (AC_BUS_RESET, ccb->ccb_h.path, NULL); > splx(s); > > Maybe something was omitted from the commit? > > Peace, > david From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 19:20:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A52F0223 for ; Sat, 22 Nov 2014 19:20:26 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 848EE8FE for ; Sat, 22 Nov 2014 19:20:25 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id BE7D2193964 for ; Sat, 22 Nov 2014 19:20:23 +0000 (UTC) Subject: zfs/vfs lockups, via poudriere From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-current@freebsd.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-FDS7Yuw1ZMAYwiX4klol" Date: Sat, 22 Nov 2014 11:20:21 -0800 Message-ID: <1416684021.7423.77.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 19:20:26 -0000 --=-FDS7Yuw1ZMAYwiX4klol Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable bdrewery reported a vfs/zfs condition where operations will stall out and block (rm, mv, file) during a poudriere build. I've hit this now and it seems to be alleviated by setting vfs.lookup_shared=3D0 I seem to be able to trivially reproduce this on my builders and want to know if anyone is looking to diagnose this further. original message: https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020035.html On my builders I see: procstat -kka | grep zfs 0 100666 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0= x3a _sleep+0x2ad taskqueue_thread_loop+0xf5 fork_exit+0x9a fork_trampoline+= 0xe=20 3 100151 zfskern arc_reclaim_thre mi_switch+0xe1 sleepq_timedw= ait+0x3a _cv_timedwait_sbt+0x1ad arc_reclaim_thread+0x288 fork_exit+0x9a fo= rk_trampoline+0xe=20 3 100152 zfskern l2arc_feed_threa mi_switch+0xe1 sleepq_timedw= ait+0x3a _cv_timedwait_sbt+0x1ad l2arc_feed_thread+0x16f fork_exit+0x9a for= k_trampoline+0xe=20 3 100657 zfskern trim zroot mi_switch+0xe1 sleepq_timedw= ait+0x3a _cv_timedwait_sbt+0x1ad trim_thread+0x9e fork_exit+0x9a fork_tramp= oline+0xe=20 3 100675 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0= x3a _cv_wait+0x190 txg_quiesce_thread+0x39b fork_exit+0x9a fork_trampoline+= 0xe=20 3 100676 zfskern txg_thread_enter mi_switch+0xe1 sleepq_timedw= ait+0x3a _cv_timedwait_sbt+0x1ad txg_sync_thread+0x1dc fork_exit+0x9a fork_= trampoline+0xe=20 31071 100995 rm - mi_switch+0xe1 sleepq_wait+0= x3a sleeplk+0x18d __lockmgr_args+0x9ab vop_stdlock+0x3c VOP_LOCK1_APV+0xab = _vn_lock+0x43 zfs_lookup+0x45d zfs_freebsd_lookup+0x6d VOP_CACHEDLOOKUP_APV= +0xa1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xa1 lookup+0x5a1 namei+0x534 ke= rn_rmdirat+0x8d amd64_syscall+0x3fb Xfast_syscall+0xfb=20 31075 100693 mv - mi_switch+0xe1 sleepq_wait+0= x3a sleeplk+0x18d __lockmgr_args+0xd5d vop_stdlock+0x3c VOP_LOCK1_APV+0xab = _vn_lock+0x4 --=-FDS7Yuw1ZMAYwiX4klol Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUcOH1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5keYMH/0qv44STnzEhLnRJQvp1TJju oppyD9CIYHE8fBB27mmD1lvECFWo/M6ueZLD/QUbyxdNLkwa5hhrRm3SRN2VBNVh fDzeSpxY/TTCDC36+Qe+6v1/sQ7ZAt2WHqZ8uTbApmQ1Rt5ehg1fKgdVx+15+Wym faz5DUD3Rf+Zpc8WrOFVrYYK/fh+2qr1NcjD7MK314hPeYiInaAmIBsJ4biAwZaq AdDh0mgtDPLtg5oVCWQcACEh/xrHTli1hsftWmoMUtQp4gx3LZE7O65YCcJZGqSX P4vPoW6Hyn4Gqww0vXA6PXaQHQqlfzYrul3kTAwnVFYsfRRQsyxnjs29F6fq0nw= =GCm3 -----END PGP SIGNATURE----- --=-FDS7Yuw1ZMAYwiX4klol-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 20:52:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F158511 for ; Sat, 22 Nov 2014 20:52:05 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CA081FD for ; Sat, 22 Nov 2014 20:52:04 +0000 (UTC) X-AuditID: 1209190f-f79b36d0000037ef-89-5470f76df574 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 53.93.14319.D67F0745; Sat, 22 Nov 2014 15:51:57 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id sAMKpudk005209; Sat, 22 Nov 2014 15:51:57 -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.8/8.12.4) with ESMTP id sAMKpstx019119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Nov 2014 15:51:56 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAMKps9B004268; Sat, 22 Nov 2014 15:51:54 -0500 (EST) Date: Sat, 22 Nov 2014 15:51:54 -0500 (EST) From: Benjamin Kaduk To: "Ellis H. Wilson III" Subject: Re: WITNESS observes 2 LORs on Boot of Release 10.1 In-Reply-To: <546FA1DD.2070109@panasas.com> Message-ID: References: <546BA9D3.6070007@panasas.com> <546BF3F5.8030109@panasas.com> <546FA1DD.2070109@panasas.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrZv7vSDEYMkGBYsTG1sYLea8+cDk wOQx49N8Fo/bx+exBjBFcdmkpOZklqUW6dslcGWsXLeCreAoX8W6m79YGxifcXcxcnJICJhI PNnygBHCFpO4cG89WxcjF4eQwGwmifV7z7NAOBsZJXYv/8ME4Rxikph1ZQEzhNPAKLF1xgoW kH4WAW2JmU+3sILYbAIqEjPfbGQDsUUE9CTO9fSAxZkF5CX+X7nMBGILC9hIfLiwHayXE6j3 +ZdNYPW8Ao4Sk080QW2bxyhxedkXsGZRAR2J1funsEAUCUqcnPmEBWKolsTy6dtYJjAKzkKS moUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGuiV5uZoleakrpJkZwuEry72D8dlDpEKMA B6MSD6/DgoIQIdbEsuLK3EOMkhxMSqK8Tp+BQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4dXqA crwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErxvvwI1ChalpqdWpGXm lCCkmTg4QYbzAA23+AYyvLggMbc4Mx0if4pRUUqctwGkWQAkkVGaB9cLSyevGMWBXhHmTQFp 5wGmIrjuV0CDmYAG/12aCzK4JBEhJdXAqOvU/+zl7kVNwS9Yvl0/n1vMuEox6G/34xd3N1Ud /P240SR7/cXq+UnJXokfV6mcnFsy90T6Ts/iTy8YnXcmzNVsN+HI2SVU1lN/Xz9UnJv1Rv+z azaCFhFva1RL9sypVz3X9J534j/nW3PkiisM+Vcwbsm/2S+58QGfPSPfvvdG+/YrfYzaq8RS nJFoqMVcVJwIANgmfAYCAwAA Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 20:52:05 -0000 On Fri, 21 Nov 2014, Ellis H. Wilson III wrote: > Before I start, and this is mainly geared to my responder Benjamin Kaduk, > based on your response, are you suggesting that the cnputc WITNESS panic you > expected to happen is now completely unavoidable in FreeBSD 10? I.E., is this > a spinlock that WITNESS falls over each time but that is provably deadlock > free that the developers have decided cannot be BLESSED for some reason? https://lists.freebsd.org/pipermail/freebsd-current/2012-January/031316.html looks to be a better explanation than the previous link I sent ... in short, console output is hard. > I guess I just can't wrap my head around why we would ever move to a regime > where SKIPSPIN is the default for testing... That just seems like an open > invitation for introducing spinlock regressions. I don't think anyone made the conscious decision to do that, it just happened by default as no one spent the time to fix the aforementioned issue. > Moving onto the LORs I'm seeing, a question I have as a newbie to WITNESS > debugging is how exactly to interpret the output if I see a stacktrace and > then a LOR output like the following: > > lock order reversal: > 1st 0xffffffff81633d88 entropy harvest mutex (entropy harvest mutex) @ > /usr/src/sys/dev/random/random_harvestq.c:198 > 2nd 0xffffffff813b6208 scrlock (scrlock) @ > /usr/src/sys/dev/syscons/syscons.c:2682 > > Does this mean WITNESS has already stored an ordering of #1 harvest_mtx then > #2 scp->scr_lock, and somewhere somebody tried to lock scp->scr_lock without > first getting harvest_mtx? Or the reverse (WITNESS previously recorded > scrlock and then harvest and the lines it spit out were the offenders?) I believe it is the latter (the ordering being printed is the bad one which caused WITNESS to complain). -Ben From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 22:10:45 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BD79290; Sat, 22 Nov 2014 22:10:45 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C4947ACD; Sat, 22 Nov 2014 22:10:44 +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 AAA26477; Sun, 23 Nov 2014 00:12:29 +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 1XsIt0-000AAq-L3; Sun, 23 Nov 2014 00:10:34 +0200 Message-ID: <547109A2.9010506@FreeBSD.org> Date: Sun, 23 Nov 2014 00:09:38 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: sbruno@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: zfs/vfs lockups, via poudriere References: <1416684021.7423.77.camel@bruno> In-Reply-To: <1416684021.7423.77.camel@bruno> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 22:10:45 -0000 On 22/11/2014 21:20, Sean Bruno wrote: > bdrewery reported a vfs/zfs condition where operations will stall out > and block (rm, mv, file) during a poudriere build. I've hit this now > and it seems to be alleviated by setting vfs.lookup_shared=0 > > I seem to be able to trivially reproduce this on my builders and want to > know if anyone is looking to diagnose this further. > > original message: > https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020035.html > > On my builders I see: > > procstat -kka | grep zfs > > 0 100666 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x2ad taskqueue_thread_loop+0xf5 fork_exit+0x9a fork_trampoline+0xe > 3 100151 zfskern arc_reclaim_thre mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad arc_reclaim_thread+0x288 fork_exit+0x9a fork_trampoline+0xe > 3 100152 zfskern l2arc_feed_threa mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad l2arc_feed_thread+0x16f fork_exit+0x9a fork_trampoline+0xe > 3 100657 zfskern trim zroot mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad trim_thread+0x9e fork_exit+0x9a fork_trampoline+0xe > 3 100675 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x190 txg_quiesce_thread+0x39b fork_exit+0x9a fork_trampoline+0xe > 3 100676 zfskern txg_thread_enter mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad txg_sync_thread+0x1dc fork_exit+0x9a fork_trampoline+0xe > 31071 100995 rm - mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x18d __lockmgr_args+0x9ab vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x43 zfs_lookup+0x45d zfs_freebsd_lookup+0x6d VOP_CACHEDLOOKUP_APV+0xa1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xa1 lookup+0x5a1 namei+0x534 kern_rmdirat+0x8d amd64_syscall+0x3fb Xfast_syscall+0xfb > 31075 100693 mv - mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x18d __lockmgr_args+0xd5d vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x4 The last line looks incomplete. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Nov 22 22:21:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAD7C664; Sat, 22 Nov 2014 22:21:15 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EB2FC35; Sat, 22 Nov 2014 22:21:15 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id gf13so6040912lab.13 for ; Sat, 22 Nov 2014 14:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=a5OyK/de1Cdt5Zj1DYhWFKS7M7x1bwVZlr8phFSPGF0=; b=hkqdWKYmovyfDcRusALvdHv8aHWW+AozXM3bNhLV8IrTBubDO6miVze0K6nwG2wxri /C5bkF8+MS1YTvo4VqpLkHBMuYHoC1ynDlUiAXb8P9RQ0oA6LxUbJZWDpWYbOXGS/gWw iE1HdxD5HKVJJ05Cb3NcGs/UR5NBzWBEvU+zLiy81llJ7UuAO0D3cBD7hMRflw266r/z Tt6/FVFrfTM4/HPXe7X/D5QwKgJRQo0gc3hwP4vLU6a7LkOW0CKmPna8XX7wUJJzHRlh OYTxzdr/aNt7djVdF0xePy4qB1K1nlLIZMrTq5197KxOkhtLwCdsh2ZDESaK6C/QFIYH jyYg== MIME-Version: 1.0 X-Received: by 10.152.7.193 with SMTP id l1mr12418422laa.57.1416694873566; Sat, 22 Nov 2014 14:21:13 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Sat, 22 Nov 2014 14:21:13 -0800 (PST) Date: Sat, 22 Nov 2014 14:21:13 -0800 X-Google-Sender-Auth: kVaE_84ItKF9AHXwr4LllFJLFqA Message-ID: Subject: Call for Help: Flame Graphs and Continuous Integration From: Craig Rodrigues To: freebsd-current Current , FreeBSD stable , freebsd-python@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 22:21:16 -0000 FYI: https://lists.freebsd.org/pipermail/freebsd-testing/2014-November/000667.html Please send follow-ups to freebsd-testing@FreeBSD.org -- Craig