From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 15:43:24 2015 Return-Path: Delivered-To: freebsd-arch@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 D2CDF9E9; Sun, 11 Jan 2015 15:43:24 +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 8D012F57; Sun, 11 Jan 2015 15:43:24 +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 DDC9C1FE022; Sun, 11 Jan 2015 16:43:21 +0100 (CET) Message-ID: <54B29A49.3080600@selasky.org> Date: Sun, 11 Jan 2015 16:44:09 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jason Wolfe Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 15:43:24 -0000 On 01/07/15 00:10, Jason Wolfe wrote: > > Hans, > > We've been running into 'spin lock held too long' panics in the kernel > idle threads on 10-STABLE over the past 6 months, so I was interested > to see your work here in the callout code. I went ahead and brought > this patch back to a recent 10.1-STABLE base without much issue, > kern_timeout.c was actually the only piece with some easily resolvable > rejections. > > I've had a box running stable under load with this patch for a few > days, and 10 more have just been added to the rotation. Anyway just > figured you might be interested in the some feedback while the changes > are reviewed. > Hi, Thank your for testing this patch. Any updates? --HPS From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 18:08:13 2015 Return-Path: Delivered-To: freebsd-arch@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 E4B1F62F; Sun, 11 Jan 2015 18:08:13 +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 759F3D92; Sun, 11 Jan 2015 18:08:13 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id h11so10636026wiw.1; Sun, 11 Jan 2015 10:08:11 -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=VnGetawWylm6NWbF7Xtqco8qkR2obuELXhzTC30b8q4=; b=eva84R1V5MkpdhSDeXpYHCYXilQD1pXiQVYtbQWnbJsgUYiaaKiquVWUdu8H28w+3E 7OUGdBWXIXmeSgVmywZNAz6zS6IZiInO7MFai5cO5jvGja6A43ipIIdVdXFL6kvm3rqP FInEbuOFmgBJTIAxxhLtPrqcNFq3P8N0DMwPNGaDOKbw0IQL7bx+U8u0pw2cOidesHFh 2KOKFQ9rghClon2CQSou3sf+nujZow1P0E7//K5HmMKieH5e0VKNgHYN9qSxv4Oy7d5i nvOpCRBKvoAj58Qko2JWPQeEApn5qt6jvr/5X+NC5fvugWnpmHrP7Ut4gBH7rmeRAgLX AMHQ== MIME-Version: 1.0 X-Received: by 10.194.234.40 with SMTP id ub8mr24213326wjc.100.1420999691727; Sun, 11 Jan 2015 10:08:11 -0800 (PST) Received: by 10.216.0.129 with HTTP; Sun, 11 Jan 2015 10:08:11 -0800 (PST) In-Reply-To: <54B29A49.3080600@selasky.org> References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> Date: Sun, 11 Jan 2015 11:08:11 -0700 Message-ID: Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress From: Jason Wolfe To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 18:08:14 -0000 Hans, We've had 50 machines running 10.1-STABLE with this patch for the better part of a week without issue. Prior we would have seen a panic every few days at the least, so things are looking very promising on our front. Jason On Sun, Jan 11, 2015 at 8:44 AM, Hans Petter Selasky wrote: > On 01/07/15 00:10, Jason Wolfe wrote: >> >> >> Hans, >> >> We've been running into 'spin lock held too long' panics in the kernel >> idle threads on 10-STABLE over the past 6 months, so I was interested >> to see your work here in the callout code. I went ahead and brought >> this patch back to a recent 10.1-STABLE base without much issue, >> kern_timeout.c was actually the only piece with some easily resolvable >> rejections. >> >> I've had a box running stable under load with this patch for a few >> days, and 10 more have just been added to the rotation. Anyway just >> figured you might be interested in the some feedback while the changes >> are reviewed. >> > > Hi, > > Thank your for testing this patch. Any updates? > > --HPS > From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 16:16:10 2015 Return-Path: Delivered-To: arch@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 CCB20DEE for ; Mon, 12 Jan 2015 16:16:10 +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 A46C213E for ; Mon, 12 Jan 2015 16:16:10 +0000 (UTC) Received: from new-host-4.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AE281B93B; Mon, 12 Jan 2015 11:16:09 -0500 (EST) Message-ID: <54B3F349.9050703@FreeBSD.org> Date: Mon, 12 Jan 2015 11:16:09 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org> <6155572.yV5dxPJznD@ralph.baldwin.cx> In-Reply-To: <6155572.yV5dxPJznD@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 12 Jan 2015 11:16:09 -0500 (EST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:16:10 -0000 On 1/5/15 4:18 PM, John Baldwin wrote: > On Monday, January 05, 2015 09:58:19 PM Hans Petter Selasky wrote: >> On 01/05/15 21:37, John Baldwin wrote: >>> On 1/5/15 3:13 PM, Hans Petter Selasky wrote: >>>> On 01/05/15 21:01, John Baldwin wrote: >>>>> The devctl(8) utility is then a thin wrapper around libdevctl (and >>>>> does not >>>>> yet have a manpage). >>>>> >>>>> Do folks have any feedback? >>>> >>>> Hi, >>>> >>>> In the USB area attach and detach must be synchronized to the USB stack >>>> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" should >>>> be used to avoid races attaching and detaching drivers! >>> >>> I think this points to one or more missing bus methods so that the bus >>> can hook into device_probe_and_attach() to reset a device as needed. >>> (e.g. if you had bus_probe_started / bus_probe_finished and possibly >>> similar methods for attach. PCI could use a bus_attach_finished() >>> callback so that it could clean up any dangling resources and possibly >>> power down on a failed attach the way it does in bus_child_detached as >>> well). >> >> Hi, >> >> USB has its own threads to allocate/free devices. Another problem is how >> to atomically get a reference count across multiple layers like PCI and >> USB. It doesn't allow probe/attach when called from outside these threads. > > That just means you need to use some locks. :) Cardbus also uses an event > thread to handle auto-attach of devices when it detected a card change event, > but that doesn't prevent it from servicing an ioctl request. Another option btw would be to add bus methods that wrap probe and attach (rather than pre and post event hooks). I wish bus_add_child() were done this way such that device_add_child_ordered() were renamed to bus_generic_add_child() (and was the default add_child method) and that device_add_child_ordered() called 'BUS_ADD_CHILD()' so that 'device_add_child()' was the proper public API (instead of exposing BUS_ADD_CHILD()). Similarly, I think that 'device_attach()' and 'device_probe_and_attach()' should be the public API and that one way or another we should add hooks to allow bus drivers to modify their behavior if needed. However, they should be fine for devctl ioctls to invoke as well as other kernel bits. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 16:55:57 2015 Return-Path: Delivered-To: arch@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 2BC4635D for ; Mon, 12 Jan 2015 16:55:57 +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 04D4389A for ; Mon, 12 Jan 2015 16:55:57 +0000 (UTC) Received: from new-host-4.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E4FAEB915; Mon, 12 Jan 2015 11:55:55 -0500 (EST) Message-ID: <54B3FC9B.6040209@FreeBSD.org> Date: Mon, 12 Jan 2015 11:55:55 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Slawa Olhovchenkov Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <20150107181750.GB5588@zxy.spb.ru> In-Reply-To: <20150107181750.GB5588@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 12 Jan 2015 11:55:56 -0500 (EST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:55:57 -0000 On 1/7/15 1:17 PM, Slawa Olhovchenkov wrote: > On Mon, Jan 05, 2015 at 03:01:00PM -0500, John Baldwin wrote: >> >> % devctl detach uart1 >> >> # does a full detach, which means the device is now unnamed > > Can be now this device used for VirtualBox USB passthrough? Maybe? I'm not sure because I do not know what vbox requires for passthrough. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 16:58:10 2015 Return-Path: Delivered-To: arch@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 2AD17516; Mon, 12 Jan 2015 16:58:10 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 D8F2D8C4; Mon, 12 Jan 2015 16:58:09 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YAiJc-0001YM-1y; Mon, 12 Jan 2015 19:58:08 +0300 Date: Mon, 12 Jan 2015 19:58:08 +0300 From: Slawa Olhovchenkov To: John Baldwin Subject: Re: devctl(8): A device control utility Message-ID: <20150112165808.GA3698@zxy.spb.ru> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <20150107181750.GB5588@zxy.spb.ru> <54B3FC9B.6040209@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B3FC9B.6040209@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:58:10 -0000 On Mon, Jan 12, 2015 at 11:55:55AM -0500, John Baldwin wrote: > On 1/7/15 1:17 PM, Slawa Olhovchenkov wrote: > > On Mon, Jan 05, 2015 at 03:01:00PM -0500, John Baldwin wrote: > >> > >> % devctl detach uart1 > >> > >> # does a full detach, which means the device is now unnamed > > > > Can be now this device used for VirtualBox USB passthrough? > > Maybe? I'm not sure because I do not know what vbox requires for > passthrough. Hm, attaching to ugenX.Y, may be? For passthrough USB flash need to unload umass module, for example. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 16:59:31 2015 Return-Path: Delivered-To: arch@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 45C345F3 for ; Mon, 12 Jan 2015 16:59:31 +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 1FDBF8D2 for ; Mon, 12 Jan 2015 16:59:31 +0000 (UTC) Received: from new-host-4.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 39A93B93B for ; Mon, 12 Jan 2015 11:59:30 -0500 (EST) Message-ID: <54B3FD71.20601@FreeBSD.org> Date: Mon, 12 Jan 2015 11:59:29 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: arch@freebsd.org Subject: Re: Change default VFS timestamp precision? References: <201412161348.41219.jhb@freebsd.org> In-Reply-To: <201412161348.41219.jhb@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 12 Jan 2015 11:59:30 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:59:31 -0000 On 12/16/14 1:48 PM, John Baldwin wrote: > We still ship with vfs.timestamp_precision=0 by default meaning that VFS > timestamps have a granularity of one second. It is not unusual on modern > systems for multiple updates to a file or directory to occur within a single > second (and thus share the same effective timestamp). This can break things > that depend on timestamps to know when something has changed or is stale (such > as make(1) or NFS clients). On hardware that has a cheap timecounter, I we > should use the most-precise timestamps (vfs.timestamp_precision=3). However, > I'm less sure of what to do for other cases such as i386/amd64 when not using > TSC, or on other platforms. OTOH, perhaps you aren't doing lots of heavy I/O > access on a system with a slow timecounter (or if you are doing heavy I/O, > slow timecounter access won't be your bottleneck)? > > I can think of a few options: > > 1) Change vfs.timestamp_precision default to 3 for all systems. > > 2) Only change vfs.timestamp_precision default to 3 for amd64/i386 using an > #ifdef. > > 3) Something else? > > What do other folks think? I think the result of this is that we should change all platforms if we make a chance, and that until Jilles can fix 'cp -p' to use ns precision, we should stick with us precision. So I think that we should change the default to 2 (not 3). Once Jilles commits his in-progress changes we can then change from 2 to 3. Any strong objections to this approach? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 17:01:13 2015 Return-Path: Delivered-To: arch@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 BD2D7819 for ; Mon, 12 Jan 2015 17:01:13 +0000 (UTC) Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) (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 7DE1F904 for ; Mon, 12 Jan 2015 17:01:13 +0000 (UTC) Received: by mail-yh0-f47.google.com with SMTP id f73so10113531yha.6 for ; Mon, 12 Jan 2015 09:01:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=1N+HsL2Q0Olbq+KP2lE8EZOY390mS0DhSGBYYWTqv3k=; b=gThkwPZ4WXIxzohvlXm2+m8JkUhaj418H7toboS5wW1N6dVFOyOIcf2rFxQObFa1k6 Mov6YnJGVQlFpvg/BDVYZvn1QpewSntXImv9kA0P8Qjn9Dj4tM9DHVIkveCYV3muaPPd m8Ez6Sv13Lu4JpuotlCH4zgNZdW1vCIZN56nQ1jy9LSLWNfSZxf5Nsqb2RdlWk2tX6Zo JKEB47DZnHGfFqaiSqJSUcd359txVGt6DbEjOup1AXuWRG2dchEe4eTcFSvMyQ3HMlj5 MM0T/Gyn3iqgpil4+0gb//ZOj2MvV9MpTlFU2hOgZVi0phbRMCOdriA+6R3FAj5LOKaw lGhg== X-Gm-Message-State: ALoCoQmYNCMH4PRncjhCfPNr0wXTBmVAXs9POHQic6JMJWyD0R6wEoDJWdWEQQ2NcLJCA4gzS43c X-Received: by 10.236.103.133 with SMTP id f5mr23506492yhg.50.1421082066174; Mon, 12 Jan 2015 09:01:06 -0800 (PST) Received: from [10.64.26.9] ([69.53.236.236]) by mx.google.com with ESMTPSA id y42sm2015616yhc.11.2015.01.12.09.01.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 09:01:05 -0800 (PST) Sender: Warner Losh Subject: Re: devctl(8): A device control utility Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D6493F37-45A7-4144-A238-62995AB12EF8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <54B3F349.9050703@FreeBSD.org> Date: Mon, 12 Jan 2015 10:01:03 -0700 Message-Id: <11219A27-4C5B-4429-8847-3E54F9C4CD1E@bsdimp.com> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org> <6155572.yV5dxPJznD@ralph.baldwin.cx> <54B3F349.9050703@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.1993) Cc: Hans Petter Selasky , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 17:01:13 -0000 --Apple-Mail=_D6493F37-45A7-4144-A238-62995AB12EF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 12, 2015, at 9:16 AM, John Baldwin wrote: >=20 > On 1/5/15 4:18 PM, John Baldwin wrote: >> On Monday, January 05, 2015 09:58:19 PM Hans Petter Selasky wrote: >>> On 01/05/15 21:37, John Baldwin wrote: >>>> On 1/5/15 3:13 PM, Hans Petter Selasky wrote: >>>>> On 01/05/15 21:01, John Baldwin wrote: >>>>>> The devctl(8) utility is then a thin wrapper around libdevctl = (and >>>>>> does not >>>>>> yet have a manpage). >>>>>>=20 >>>>>> Do folks have any feedback? >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> In the USB area attach and detach must be synchronized to the USB = stack >>>>> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" = should >>>>> be used to avoid races attaching and detaching drivers! >>>>=20 >>>> I think this points to one or more missing bus methods so that the = bus >>>> can hook into device_probe_and_attach() to reset a device as = needed. >>>> (e.g. if you had bus_probe_started / bus_probe_finished and = possibly >>>> similar methods for attach. PCI could use a bus_attach_finished() >>>> callback so that it could clean up any dangling resources and = possibly >>>> power down on a failed attach the way it does in bus_child_detached = as >>>> well). >>>=20 >>> Hi, >>>=20 >>> USB has its own threads to allocate/free devices. Another problem is = how >>> to atomically get a reference count across multiple layers like PCI = and >>> USB. It doesn't allow probe/attach when called from outside these = threads. >>=20 >> That just means you need to use some locks. :) Cardbus also uses an = event >> thread to handle auto-attach of devices when it detected a card = change event, >> but that doesn't prevent it from servicing an ioctl request. >=20 > Another option btw would be to add bus methods that wrap probe and > attach (rather than pre and post event hooks). I wish bus_add_child() > were done this way such that device_add_child_ordered() were renamed = to > bus_generic_add_child() (and was the default add_child method) and = that > device_add_child_ordered() called 'BUS_ADD_CHILD()' so that > 'device_add_child()' was the proper public API (instead of exposing > BUS_ADD_CHILD()). Similarly, I think that 'device_attach()' and > 'device_probe_and_attach()' should be the public API and that one way = or > another we should add hooks to allow bus drivers to modify their > behavior if needed. However, they should be fine for devctl ioctls to > invoke as well as other kernel bits. When I was doing CardBus and PC Card I wished for similar things. Then I realized I didn=E2=80=99t need them because as the bus author, I know = when these events happened and could take appropriate actions for the bus. I = didn=E2=80=99t have that atomic access issues though, since as the bus author I also = controlled how and when mutexes were taken out and when I allowed access to the bus. I only used mutexes in CardBus and PC Card because most of the sleeps were short, but other ways to do locking are quite possible... Warner --Apple-Mail=_D6493F37-45A7-4144-A238-62995AB12EF8 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUs/3PAAoJEGwc0Sh9sBEArfwP/2oRtY/d7tvFxbZ4C5+w77tt MPzQhy2V21ehXlba3oPiefx7Nck8XV8koW4W44VuxFKw84q477TOnUPsMGK/3JN4 cQw6WUXcWn7Z8kAmd3dQv3UGSnO44Tg64WFYdTSczluqOvBxocGGY9d5WaC2U/Qo lG99tq7xwcwmvNYz4Hw2DkN5puwJ38IXyFyDl826oz9JIuKhCToRSOncWLIpJfPL 4B9LxZeGyY4f1XXn1ABQiRHk6osGvAf0VEMrUyyRQ3BYAwNyGFesoOJU3FGc1a1i VTHrdKgp8MZNAzKw4IbNeYOCPkhYVOAE1VbKxx4GsKLKJ6Sm1vS3IxoKXDJup+1S IvDeVXKI9P4yalyVu2llaT116mYaaxJ2jj9hZT2woFIPy5qg753SfTSK3zVBHpwe OWbbSguFILcbSh4hxBRxbsMVySeL+CQ4VOgzG+V0MLb7+hyQG0DbWJENRdNuRxNe MYO6Zwwltwk81CE6GiTlzT26+trWKyUsqQ4EONLs1FTq3E8JBwYb1MYWKXLtFV4h 97bCzkdf880jrb89gOAEaASvEiCyJCyMbPYSVrwpR+bTyTDJK6FYWeBiSXu4G3hk q7Dl7xJkuiydodNLNlk2jLCD/6gbCGpHu1TfiKZqmMseyIt3huoOMtuTs+4NTiqf zXEFtYopM+QNnVqkx0w0 =Wv8m -----END PGP SIGNATURE----- --Apple-Mail=_D6493F37-45A7-4144-A238-62995AB12EF8-- From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 22:01:48 2015 Return-Path: Delivered-To: arch@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 40DADB72 for ; Mon, 12 Jan 2015 22:01:48 +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 16DD93ED for ; Mon, 12 Jan 2015 22:01:48 +0000 (UTC) Received: from new-host-4.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C391EB915; Mon, 12 Jan 2015 17:01:45 -0500 (EST) Message-ID: <54B44448.1090901@FreeBSD.org> Date: Mon, 12 Jan 2015 17:01:44 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org> <6155572.yV5dxPJznD@ralph.baldwin.cx> <54B3F349.9050703@FreeBSD.org> <11219A27-4C5B-4429-8847-3E54F9C4CD1E@bsdimp.com> In-Reply-To: <11219A27-4C5B-4429-8847-3E54F9C4CD1E@bsdimp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 12 Jan 2015 17:01:45 -0500 (EST) Cc: Hans Petter Selasky , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 22:01:48 -0000 On 1/12/15 12:01 PM, Warner Losh wrote: > >> On Jan 12, 2015, at 9:16 AM, John Baldwin wrote: >> >> On 1/5/15 4:18 PM, John Baldwin wrote: >>> On Monday, January 05, 2015 09:58:19 PM Hans Petter Selasky wrote: >>>> On 01/05/15 21:37, John Baldwin wrote: >>>>> On 1/5/15 3:13 PM, Hans Petter Selasky wrote: >>>>>> On 01/05/15 21:01, John Baldwin wrote: >>>>>>> The devctl(8) utility is then a thin wrapper around libdevctl (and >>>>>>> does not >>>>>>> yet have a manpage). >>>>>>> >>>>>>> Do folks have any feedback? >>>>>> >>>>>> Hi, >>>>>> >>>>>> In the USB area attach and detach must be synchronized to the USB stack >>>>>> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" should >>>>>> be used to avoid races attaching and detaching drivers! >>>>> >>>>> I think this points to one or more missing bus methods so that the bus >>>>> can hook into device_probe_and_attach() to reset a device as needed. >>>>> (e.g. if you had bus_probe_started / bus_probe_finished and possibly >>>>> similar methods for attach. PCI could use a bus_attach_finished() >>>>> callback so that it could clean up any dangling resources and possibly >>>>> power down on a failed attach the way it does in bus_child_detached as >>>>> well). >>>> >>>> Hi, >>>> >>>> USB has its own threads to allocate/free devices. Another problem is how >>>> to atomically get a reference count across multiple layers like PCI and >>>> USB. It doesn't allow probe/attach when called from outside these threads. >>> >>> That just means you need to use some locks. :) Cardbus also uses an event >>> thread to handle auto-attach of devices when it detected a card change event, >>> but that doesn't prevent it from servicing an ioctl request. >> >> Another option btw would be to add bus methods that wrap probe and >> attach (rather than pre and post event hooks). I wish bus_add_child() >> were done this way such that device_add_child_ordered() were renamed to >> bus_generic_add_child() (and was the default add_child method) and that >> device_add_child_ordered() called 'BUS_ADD_CHILD()' so that >> 'device_add_child()' was the proper public API (instead of exposing >> BUS_ADD_CHILD()). Similarly, I think that 'device_attach()' and >> 'device_probe_and_attach()' should be the public API and that one way or >> another we should add hooks to allow bus drivers to modify their >> behavior if needed. However, they should be fine for devctl ioctls to >> invoke as well as other kernel bits. > > When I was doing CardBus and PC Card I wished for similar things. Then > I realized I didn’t need them because as the bus author, I know when these > events happened and could take appropriate actions for the bus. I didn’t have > that atomic access issues though, since as the bus author I also controlled how > and when mutexes were taken out and when I allowed access to the bus. I > only used mutexes in CardBus and PC Card because most of the sleeps were > short, but other ways to do locking are quite possible... I think the problem here is that devctl introduces events that happen without the bus's knowledge. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 14 08:14:53 2015 Return-Path: Delivered-To: freebsd-arch@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 94D0E773; Wed, 14 Jan 2015 08:14:53 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0108.outbound.protection.outlook.com [157.56.111.108]) (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 0D42BAB2; Wed, 14 Jan 2015 08:14:52 +0000 (UTC) Received: from BL2PR05CA0016.namprd05.prod.outlook.com (10.255.226.16) by BLUPR05MB436.namprd05.prod.outlook.com (10.141.27.152) with Microsoft SMTP Server (TLS) id 15.1.53.17; Wed, 14 Jan 2015 08:14:44 +0000 Received: from BY2FFO11FD020.protection.gbl (2a01:111:f400:7c0c::197) by BL2PR05CA0016.outlook.office365.com (2a01:111:e400:c04::16) with Microsoft SMTP Server (TLS) id 15.1.59.20 via Frontend Transport; Wed, 14 Jan 2015 08:14:44 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Wed, 14 Jan 2015 08:14:44 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 14 Jan 2015 00:14:43 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t0E8EfW51483; Wed, 14 Jan 2015 00:14:41 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t0E8EQRV053545; Wed, 14 Jan 2015 03:14:26 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201501140814.t0E8EQRV053545@idle.juniper.net> To: Alfred Perlstein Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML In-Reply-To: <549B8223.4010602@freebsd.org> Date: Wed, 14 Jan 2015 03:14:26 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(86362001)(92566002)(76506005)(97736003)(15975445007)(77156002)(62966003)(68736005)(77096005)(53416004)(64706001)(6806004)(47776003)(81156004)(50466002)(48376002)(110136001)(558084003)(87936001)(46102003)(69596002)(19580395003)(106466001)(105596002)(50986999)(2950100001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB436; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BLUPR05MB436; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB436; X-Forefront-PRVS: 04569283F9 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2015 08:14:44.2202 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB436 Cc: "adrian@FreeBSD.org" , Marcel Moolenaar , "Simon J. Gerraty" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov , Garrett Cooper X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 08:14:53 -0000 Alfred Perlstein writes: >https://reviews.freebsd.org/D1379 FWIW, linux puts __flbf() in stdio_ext.h rather that stdio.h. Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Wed Jan 14 14:30:18 2015 Return-Path: Delivered-To: freebsd-arch@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 237EA715; Wed, 14 Jan 2015 14:30:18 +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 CFB7094B; Wed, 14 Jan 2015 14:30: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 57D5C1FE022; Wed, 14 Jan 2015 15:30:15 +0100 (CET) Message-ID: <54B67DA7.3070106@selasky.org> Date: Wed, 14 Jan 2015 15:31:03 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jason Wolfe Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 14:30:18 -0000 On 01/11/15 19:08, Jason Wolfe wrote: > Hans, > > We've had 50 machines running 10.1-STABLE with this patch for the > better part of a week without issue. Prior we would have seen a panic > every few days at the least, so things are looking very promising on > our front. > > Jason Hi, I've updated D1438 including the manual page changes needed for timeout.9 aswell in addition to a minor fix for those using timeout() and untimeout() and KTR(). https://reviews.freebsd.org/D1438 --HPS From owner-freebsd-arch@FreeBSD.ORG Wed Jan 14 16:21:52 2015 Return-Path: Delivered-To: arch@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 EF10F733 for ; Wed, 14 Jan 2015 16:21:52 +0000 (UTC) Received: from ccm198.constantcontact.com (ccm198.constantcontact.com [208.75.123.198]) by mx1.freebsd.org (Postfix) with ESMTP id 7D3BA837 for ; Wed, 14 Jan 2015 16:21:52 +0000 (UTC) Received: from p2-jb638.ad.prodcc.net (p2-pen3.ad.prodcc.net [10.252.0.103]) by p2-mail163.ccm198.constantcontact.com (Postfix) with ESMTP id 3A0A8FA43A2 for ; Wed, 14 Jan 2015 11:21:52 -0500 (EST) DKIM-Signature: v=1; q=dns/txt; a=rsa-sha256; c=relaxed/relaxed; s=1000073432; d=auth.ccsend.com; h=to:X-Feedback-ID:subject:mime-version:message-id:from:date:list-unsubscribe:reply-to; bh=/OxZ+zVDrFCHQP7VO1XLveL2Wu4D1CeDYc63povlflg=; b=SsVjufSo8C85o0KzHEcKgGI+kry3SS0AZKLQ147jHTaYWD5Ur+dk6TEqZJR+p8KTV+ph1ifTU+6lmGb8pFDZN8tQaag6db9k9ejDIxeDPp+0/xqj1Nxo6YEYnCOAUyc+mjuxXZcevqRK8LlmeJbW0uDs04SPzdUgYML9Mc7GpNA= Message-ID: <1119764708435.1115603422701.1254712288.0.241121JL.1002@scheduler.constantcontact.com> Date: Wed, 14 Jan 2015 11:21:52 -0500 (EST) From: Salvage Drive Reply-To: info@salvagedrive.com To: arch@freebsd.org Subject: Special Package Deal 4 Cars MIME-Version: 1.0 X-Campaign-Activity-ID: bc46b500-0079-4568-a2df-8c3cbcd0be98 X-Channel-ID: 8b131940-9839-11e4-9cca-d4ae528eade9 X-Mailer: Roving Constant Contact 2012 (http://www.constantcontact.com) X-Return-Path-Hint: AvEa1AAB5RWii34w8vNC+mA==_1115603422701_ixMZQJg5EeScytSuUo6t6Q==@in.constantcontact.com X-Roving-Campaignid: 1119764708435 X-Roving-Id: 1115603422701.1254712288 X-Feedback-ID: 8b131940-9839-11e4-9cca-d4ae528eade9:bc46b500-0079-4568-a2df-8c3cbcd0be98:1115603422701:CTCT X-CTCT-ID: 8a6a7d30-9839-11e4-9c25-d4ae528eade9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 16:21:53 -0000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ HOT PACKAGE DEAL!!! 4 Cars for ONLY $9,999 Selling our in-house inventory No Auction Fees No Salvage Drive Fees ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2009 Hyundai Elantra Salvage Title Odometer: 47,136 miles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2010 Kia Sportage Salvage Title Odometer: 85,328 miles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2011 Hyundai Santa Fe Salvage Title Odometer: 75,470 miles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2009 Toyota Corolla Salvage Title Odometer: n/a ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ Disclaimer: These vehicles are sold as is and where is, without warranty. T= he price offered only applies to the actual purchase of all 4 (Four) vehicles as a "= Package Deal" Buyer will be responsible for shipping cost of each unit, plus $50 Document= ation fee for each Vehicle. No Cars may be removed by the purchaser prior to mak= ing full payment. This offer is based on First-come, first-served (FCFS) Policy. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ SalvageDrive.com [http://r20.rs6.net/tn.jsp?f=3D001ELVijS5E-2wKONURIV28orxZ= 8ckw8zIY4ntcXx2OmI5LxZwX6_CFmU5B7em_L5p9MF29Vml4jXREAuP0agTrY_kFKH-mUthzWSG= 1pINgK2sYoTIG-nnL8LBajyGC-xBivXX0Ru8XJSjNHQL3FHW0sh75vxRcG1R6kd7RyTlHz6cZx5= TxSjBeiA=3D=3D&c=3Di1fcX5LizTp_0bf2nRYcqBj1AYbvQZwYT1Vk2KRqbJTlO_U_wnUOtg= =3D=3D&ch=3Da-ElDxCcHM-DN4nLL1_lUeD7pRyPgXCDtDUBXUGd52_m7JxRQs1nEQ=3D=3D] SalvageDrive.com [http://r20.rs6.net/tn.jsp?f=3D001ELVijS5E-2wKONURIV28orxZ= 8ckw8zIY4ntcXx2OmI5LxZwX6_CFmWL-5hFR-7y8mEjC7QGz69Kvl5HFjApBVd1rIc4D-gDuKPA= P_FvuJ0JmltCxtHzQog5pVXX3d2QiozYgpkmB8YKQReBdSiyzexZ0LlOlH_39QkeAkQdGYLQcHl= 87NbxtlOuZTWTnQ8IakyH0VwGrevnKoTWP-CAq8eV7yXwmybnf&c=3Di1fcX5LizTp_0bf2nRYc= qBj1AYbvQZwYT1Vk2KRqbJTlO_U_wnUOtg=3D=3D&ch=3Da-ElDxCcHM-DN4nLL1_lUeD7pRyPg= XCDtDUBXUGd52_m7JxRQs1nEQ=3D=3D] 1-844-227-7411 Toll Free 1-347-492-1727 Tel. Skype: salvagedrive info@SalvageDrive.com [mailto:info@SalvageDrive.com] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ Sincerely, Salvage Drive Team ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ ___________________________________________________________________________= __________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ You can choose to unsubscribe from our Email Newsletters service by replyin= g to=20 this email with the word "STOP" and we will remove you from any future mail= ings. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ Don't forget to add info@salvagedrive.com to your Address Book to keep it f= rom skipping your inbox or getting caught in spam filters. We want your experience with the Salvage Drive to be as smooth and reassuri= ng as possible. Accordingly, we diligently safeguard your privacy. If you wish t= o review our Privacy Policy at any time, please click on the link below, or copy and= paste it into your web browser's location window Salvage Drive Privacy Policy [http://r20.rs6.net/tn.jsp?f=3D001ELVijS5E-2wK= ONURIV28orxZ8ckw8zIY4ntcXx2OmI5LxZwX6_CFmWL-5hFR-7y8YCQgjliJDM3ZQMaGzS0vcL7= lRdlOJQaOXvZxewGMpJaO8kUqEDHadw08VhB3NRrNUkUU0_rcVPHAwQ3y24KgjcEoYPT4lOz_yG= 8MuUNuAodgdy9Ng_xojkteHnP0Oa90UsUrT4mVw5E1gnzPFY6HH_2zRWNHGshV&c=3Di1fcX5Li= zTp_0bf2nRYcqBj1AYbvQZwYT1Vk2KRqbJTlO_U_wnUOtg=3D=3D&ch=3Da-ElDxCcHM-DN4nLL= 1_lUeD7pRyPgXCDtDUBXUGd52_m7JxRQs1nEQ=3D=3D] =C2=A9 2014 SalvageDrive, Inc. | All rights reserved ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ This email was sent to arch@freebsd.org by info@salvagedrive.com. Update Profile/Email Address http://visitor.constantcontact.com/do?p=3Doo&m=3D001byRd3MOrEzrBc_e8AIN5jg%= 3D%3D&ch=3D8b131940-9839-11e4-9cca-d4ae528eade9&ca=3Dbc46b500-0079-4568-a2d= f-8c3cbcd0be98 Instant removal with SafeUnsubscribe(TM) http://visitor.constantcontact.com/do?p=3Dun&m=3D001byRd3MOrEzrBc_e8AIN5jg%= 3D%3D&ch=3D8b131940-9839-11e4-9cca-d4ae528eade9&ca=3Dbc46b500-0079-4568-a2d= f-8c3cbcd0be98 Privacy Policy: http://ui.constantcontact.com/roving/CCPrivacyPolicy.jsp Online Marketing by Constant Contact(R) www.constantcontact.com Salvage Drive, Inc | 217 Broadway | Suite 515 | New York | NY | 10007 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 14 23:56:23 2015 Return-Path: Delivered-To: arch@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 9ED5EE11 for ; Wed, 14 Jan 2015 23:56:23 +0000 (UTC) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (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 6A2AA3EE for ; Wed, 14 Jan 2015 23:56:23 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id y10so1377802pdj.13 for ; Wed, 14 Jan 2015 15:56:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=VHELp2LLMnbh7EUNsX+NOw0vjTq9bdpviLVZV8J1cRY=; b=CLVn4OMteX33i4TkvYMVDgyOPmQXoaUa4er6C5iOITeamb4CUMqMch98hq8LOW2ds2 hz8F03qmDrMxBrgaqu5TKSZaYMAXfR/tzr1Vt/Tv22Zu6kK4MCpDbO34/aqnAci1waOe 75/dklU1zL/Sg6y3hJwJoRI5ZQckG+Vk1aHPTjI+nLSkFDNhHdYiujzKRFazIxpcajlT /x2AJ9JWrh8bv12f+zAtnWBe8t2H8NShTPwNso4ERwqO8vDHR/qfc7zJKbQEPoLp6oBo Su0U3+OTwtQztqn+LYTfAQhJ5AZtLGWbeVtO/vwddaTKJrFdIZCLX5rFoh8de4O7HkNm SxiA== X-Gm-Message-State: ALoCoQnUMVg1UVVkQGv6KCpY2XuYIHFQS29CmcsuzrZL0HRxPs0GmUelFL9H29DZP68sGtv0XwyD X-Received: by 10.70.103.197 with SMTP id fy5mr9599565pdb.131.1421279782576; Wed, 14 Jan 2015 15:56:22 -0800 (PST) Received: from [10.64.25.14] ([69.53.236.236]) by mx.google.com with ESMTPSA id pf10sm20655309pbc.82.2015.01.14.15.56.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 15:56:21 -0800 (PST) Sender: Warner Losh Subject: Re: devctl(8): A device control utility Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_724ABB64-B20B-4A5C-8428-9E19B43BA4A9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <54B44448.1090901@FreeBSD.org> Date: Wed, 14 Jan 2015 16:56:18 -0700 Message-Id: References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org> <6155572.yV5dxPJznD@ralph.baldwin.cx> <54B3F349.9050703@FreeBSD.org> <11219A27-4C5B-4429-8847-3E54F9C4CD1E@bsdimp.com> <54B44448.1090901@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.1993) Cc: Hans Petter Selasky , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 23:56:23 -0000 --Apple-Mail=_724ABB64-B20B-4A5C-8428-9E19B43BA4A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 12, 2015, at 3:01 PM, John Baldwin wrote: >=20 > On 1/12/15 12:01 PM, Warner Losh wrote: >>=20 >>> On Jan 12, 2015, at 9:16 AM, John Baldwin wrote: >>>=20 >>> On 1/5/15 4:18 PM, John Baldwin wrote: >>>> On Monday, January 05, 2015 09:58:19 PM Hans Petter Selasky wrote: >>>>> On 01/05/15 21:37, John Baldwin wrote: >>>>>> On 1/5/15 3:13 PM, Hans Petter Selasky wrote: >>>>>>> On 01/05/15 21:01, John Baldwin wrote: >>>>>>>> The devctl(8) utility is then a thin wrapper around libdevctl = (and >>>>>>>> does not >>>>>>>> yet have a manpage). >>>>>>>>=20 >>>>>>>> Do folks have any feedback? >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> In the USB area attach and detach must be synchronized to the = USB stack >>>>>>> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" = should >>>>>>> be used to avoid races attaching and detaching drivers! >>>>>>=20 >>>>>> I think this points to one or more missing bus methods so that = the bus >>>>>> can hook into device_probe_and_attach() to reset a device as = needed. >>>>>> (e.g. if you had bus_probe_started / bus_probe_finished and = possibly >>>>>> similar methods for attach. PCI could use a = bus_attach_finished() >>>>>> callback so that it could clean up any dangling resources and = possibly >>>>>> power down on a failed attach the way it does in = bus_child_detached as >>>>>> well). >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> USB has its own threads to allocate/free devices. Another problem = is how >>>>> to atomically get a reference count across multiple layers like = PCI and >>>>> USB. It doesn't allow probe/attach when called from outside these = threads. >>>>=20 >>>> That just means you need to use some locks. :) Cardbus also uses = an event >>>> thread to handle auto-attach of devices when it detected a card = change event, >>>> but that doesn't prevent it from servicing an ioctl request. >>>=20 >>> Another option btw would be to add bus methods that wrap probe and >>> attach (rather than pre and post event hooks). I wish = bus_add_child() >>> were done this way such that device_add_child_ordered() were renamed = to >>> bus_generic_add_child() (and was the default add_child method) and = that >>> device_add_child_ordered() called 'BUS_ADD_CHILD()' so that >>> 'device_add_child()' was the proper public API (instead of exposing >>> BUS_ADD_CHILD()). Similarly, I think that 'device_attach()' and >>> 'device_probe_and_attach()' should be the public API and that one = way or >>> another we should add hooks to allow bus drivers to modify their >>> behavior if needed. However, they should be fine for devctl ioctls = to >>> invoke as well as other kernel bits. >>=20 >> When I was doing CardBus and PC Card I wished for similar things. = Then >> I realized I didn=E2=80=99t need them because as the bus author, I = know when these >> events happened and could take appropriate actions for the bus. I = didn=E2=80=99t have >> that atomic access issues though, since as the bus author I also = controlled how >> and when mutexes were taken out and when I allowed access to the bus. = I >> only used mutexes in CardBus and PC Card because most of the sleeps = were >> short, but other ways to do locking are quite possible... >=20 > I think the problem here is that devctl introduces events that happen > without the bus's knowledge. When we did the kludge sysctl power stuff for cardbus (which was never = committed), we sent a message to the bus to tell it to do the power off and cope with = whatever else was needed. There were times that it couldn=E2=80=99t comply, iirc, so this =E2=80=98command= =E2=80=99 allowed errors to be returned for things that were forbidden / not allowed for some reason at the time rather = than getting a message that this thing happened and we had to mop up now. Warner --Apple-Mail=_724ABB64-B20B-4A5C-8428-9E19B43BA4A9 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUtwIjAAoJEGwc0Sh9sBEAC68QANxHxKO4hnx82BojE9fMVi6/ /oPh7toXq1YqLLq4QwMBH2izkL+5XjwHQbe0EGItQXKVasIwiIu8Bf5fIv04FIfy 5++do7LVUE1yA3LBHdiOVnFP5eXQ59kYR+cIwAEjpA1mevt8Psqd8frYlzwdgj2z pFw1OAil4LXWG/ujAzNP60iP6Pxu5f4offHk12Sqn22x3tHpN6cIASW+h4rmPLEM tBhhc0AbpnunP8MCEBy/BrZi/jgKvQOh1PTpG0Xo4F4Uo4ZbG0absy8cut/+s4dq 9O+0UAXabNN68hLUqLtl92SnLNv89gl3GcE6NeUAF0+L7JjYexZBVuNQmZZpGyaI ms9t8K/PxzLKxTmFiwgnzzQaox8/PzrXb9ffkx4stFG8K1mzoRkl6A/qFNjK0x1J RTdzYbjyBVVGxlNkXYBmyCbN0MBoa53pSIkx40YF1z1+MI579XdJfLxqG7vWlS/R 2BMxYakT2ORHunX0U9JEG9psHGOa0t6GCskEhNv6yJkwgCLAHBjTrJKMusQIgf9z HdYJTc4XDNSJi/N5AKAvTwYaxoO5b3tta9//elSSqQePA3VtVfo1YkiOR6Mhxe46 VevVt6RP405SiUzoJ574iHuLI3X1BoGrVAwZQRyQ185BelUWhso12Tuzvp0Vc6Bw aCQI7s7kIzNIhu6mCWiW =MGb6 -----END PGP SIGNATURE----- --Apple-Mail=_724ABB64-B20B-4A5C-8428-9E19B43BA4A9-- From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 15:37:06 2015 Return-Path: Delivered-To: freebsd-arch@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 2C90CDC1; Thu, 15 Jan 2015 15:37:06 +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 D5EEF1BC; Thu, 15 Jan 2015 15:37:05 +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 33D1D1FE022; Thu, 15 Jan 2015 16:37:03 +0100 (CET) Message-ID: <54B7DECF.8070209@selasky.org> Date: Thu, 15 Jan 2015 16:37:51 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jason Wolfe Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> In-Reply-To: <54B67DA7.3070106@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , sbruno@freebsd.org, "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 15:37:06 -0000 On 01/14/15 15:31, Hans Petter Selasky wrote: > On 01/11/15 19:08, Jason Wolfe wrote: >> Hans, >> >> We've had 50 machines running 10.1-STABLE with this patch for the >> better part of a week without issue. Prior we would have seen a panic >> every few days at the least, so things are looking very promising on >> our front. >> >> Jason > > Hi, > > I've updated D1438 including the manual page changes needed for > timeout.9 aswell in addition to a minor fix for those using timeout() > and untimeout() and KTR(). > > https://reviews.freebsd.org/D1438 > > --HPS FYI: Now in -current: https://svnweb.freebsd.org/changeset/base/277213 Thanks for all good comments and reviews. --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 15:46:19 2015 Return-Path: Delivered-To: freebsd-arch@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 C1301289; Thu, 15 Jan 2015 15:46:19 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 74295320; Thu, 15 Jan 2015 15:46:19 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YBmcj-0002sd-4T; Thu, 15 Jan 2015 18:46:17 +0300 Date: Thu, 15 Jan 2015 18:46:17 +0300 From: Slawa Olhovchenkov To: Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress Message-ID: <20150115154617.GB10325@zxy.spb.ru> References: <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B7DECF.8070209@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Adrian Chadd , FreeBSD Current , sbruno@freebsd.org, Jason Wolfe , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 15:46:19 -0000 On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: > On 01/14/15 15:31, Hans Petter Selasky wrote: > > On 01/11/15 19:08, Jason Wolfe wrote: > >> Hans, > >> > >> We've had 50 machines running 10.1-STABLE with this patch for the > >> better part of a week without issue. Prior we would have seen a panic > >> every few days at the least, so things are looking very promising on > >> our front. > >> > >> Jason > > > > Hi, > > > > I've updated D1438 including the manual page changes needed for > > timeout.9 aswell in addition to a minor fix for those using timeout() > > and untimeout() and KTR(). > > > > https://reviews.freebsd.org/D1438 > > > > --HPS > > FYI: > > Now in -current: > > https://svnweb.freebsd.org/changeset/base/277213 > > Thanks for all good comments and reviews. Only stability impovement? Or performance too? From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 15:50:15 2015 Return-Path: Delivered-To: freebsd-arch@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 396BA4DD; Thu, 15 Jan 2015 15:50:15 +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 E4EED366; Thu, 15 Jan 2015 15:50:14 +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 71B9A1FE022; Thu, 15 Jan 2015 16:50:12 +0100 (CET) Message-ID: <54B7E1E4.6040906@selasky.org> Date: Thu, 15 Jan 2015 16:51:00 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Slawa Olhovchenkov Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <20150115154617.GB10325@zxy.spb.ru> In-Reply-To: <20150115154617.GB10325@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , sbruno@freebsd.org, Jason Wolfe , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 15:50:15 -0000 On 01/15/15 16:46, Slawa Olhovchenkov wrote: > On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: > > Only stability impovement? > Or performance too? Hi, Stability improvement mostly. Should not affect performance from what I know. Some changes are made about when and how we can select a different callback CPU for a callout callback. Try reading the updated timeout(9) man manual page first. Maybe it answers your question. Else feel free to ask here. --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 15:58:12 2015 Return-Path: Delivered-To: freebsd-arch@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 62A65B6E; Thu, 15 Jan 2015 15:58:12 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 1444A68E; Thu, 15 Jan 2015 15:58:12 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YBmoE-00034s-4N; Thu, 15 Jan 2015 18:58:10 +0300 Date: Thu, 15 Jan 2015 18:58:10 +0300 From: Slawa Olhovchenkov To: Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress Message-ID: <20150115155810.GE3698@zxy.spb.ru> References: <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <20150115154617.GB10325@zxy.spb.ru> <54B7E1E4.6040906@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B7E1E4.6040906@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Adrian Chadd , FreeBSD Current , sbruno@freebsd.org, Jason Wolfe , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 15:58:12 -0000 On Thu, Jan 15, 2015 at 04:51:00PM +0100, Hans Petter Selasky wrote: > On 01/15/15 16:46, Slawa Olhovchenkov wrote: > > On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: > > > > Only stability impovement? > > Or performance too? > > Hi, > > Stability improvement mostly. Should not affect performance from what I > know. Some changes are made about when and how we can select a different > callback CPU for a callout callback. Try reading the updated timeout(9) I am not kernel guru and can't be draw a conclusion from manual page. > man manual page first. Maybe it answers your question. Else feel free to > ask here. As I understand performance for massive TCP connections (tens of thousands connections) will be same, no improvement, no degraded? (very high lock congestion on TCP timers working). From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 16:41:50 2015 Return-Path: Delivered-To: freebsd-arch@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 C91FA98C; Thu, 15 Jan 2015 16:41:50 +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 8294CC70; Thu, 15 Jan 2015 16:41:50 +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 8619C1FE022; Thu, 15 Jan 2015 17:41:48 +0100 (CET) Message-ID: <54B7EDFC.9020406@selasky.org> Date: Thu, 15 Jan 2015 17:42:36 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Slawa Olhovchenkov Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <20150115154617.GB10325@zxy.spb.ru> <54B7E1E4.6040906@selasky.org> <20150115155810.GE3698@zxy.spb.ru> In-Reply-To: <20150115155810.GE3698@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , sbruno@freebsd.org, Jason Wolfe , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 16:41:50 -0000 On 01/15/15 16:58, Slawa Olhovchenkov wrote: > On Thu, Jan 15, 2015 at 04:51:00PM +0100, Hans Petter Selasky wrote: > >> On 01/15/15 16:46, Slawa Olhovchenkov wrote: >>> On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: >>> >>> Only stability impovement? >>> Or performance too? >> >> Hi, >> >> Stability improvement mostly. Should not affect performance from what I >> know. Some changes are made about when and how we can select a different >> callback CPU for a callout callback. Try reading the updated timeout(9) > > I am not kernel guru and can't be draw a conclusion from manual page. > >> man manual page first. Maybe it answers your question. Else feel free to >> ask here. > > As I understand performance for massive TCP connections (tens of > thousands connections) will be same, no improvement, no degraded? > (very high lock congestion on TCP timers working). Hi, There is no difference in memory footprint per TCP connection. There is no significant different in the amount of code executed when a callout is started/stopped or reset. There might be a reduction in the number of times the spinlocks inside the callout subsystem are locked/unlocked, due to some simplifications made and checks for redundant locking. The changes are mainly about closing some races in the callout subsystem and cornercases towards the TCP/IP stack which use callouts. There is a patch for the TCP/IP stack coming possibly next week to take advantage of the new callout_drain_async() function. It is not ready yet, and I'm waiting for the current callout patch to settle first. --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 16:48:04 2015 Return-Path: Delivered-To: freebsd-arch@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 D36DACD9; Thu, 15 Jan 2015 16:48:04 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 87E78CE9; Thu, 15 Jan 2015 16:48:04 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YBnaS-0003wC-Ph; Thu, 15 Jan 2015 19:48:00 +0300 Date: Thu, 15 Jan 2015 19:48:00 +0300 From: Slawa Olhovchenkov To: Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress Message-ID: <20150115164800.GF3698@zxy.spb.ru> References: <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <20150115154617.GB10325@zxy.spb.ru> <54B7E1E4.6040906@selasky.org> <20150115155810.GE3698@zxy.spb.ru> <54B7EDFC.9020406@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B7EDFC.9020406@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Adrian Chadd , FreeBSD Current , sbruno@freebsd.org, Jason Wolfe , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 16:48:04 -0000 On Thu, Jan 15, 2015 at 05:42:36PM +0100, Hans Petter Selasky wrote: > On 01/15/15 16:58, Slawa Olhovchenkov wrote: > > On Thu, Jan 15, 2015 at 04:51:00PM +0100, Hans Petter Selasky wrote: > > > >> On 01/15/15 16:46, Slawa Olhovchenkov wrote: > >>> On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: > >>> > >>> Only stability impovement? > >>> Or performance too? > >> > >> Hi, > >> > >> Stability improvement mostly. Should not affect performance from what I > >> know. Some changes are made about when and how we can select a different > >> callback CPU for a callout callback. Try reading the updated timeout(9) > > > > I am not kernel guru and can't be draw a conclusion from manual page. > > > >> man manual page first. Maybe it answers your question. Else feel free to > >> ask here. > > > > As I understand performance for massive TCP connections (tens of > > thousands connections) will be same, no improvement, no degraded? > > (very high lock congestion on TCP timers working). > > Hi, > > There is no difference in memory footprint per TCP connection. > > There is no significant different in the amount of code executed when a > callout is started/stopped or reset. > > There might be a reduction in the number of times the spinlocks inside > the callout subsystem are locked/unlocked, due to some simplifications > made and checks for redundant locking. > > The changes are mainly about closing some races in the callout subsystem > and cornercases towards the TCP/IP stack which use callouts. > > There is a patch for the TCP/IP stack coming possibly next week to take > advantage of the new callout_drain_async() function. It is not ready > yet, and I'm waiting for the current callout patch to settle first. Thanks. I am going to try this patch in 10-STABLE branch. From owner-freebsd-arch@FreeBSD.ORG Sat Jan 17 07:47:47 2015 Return-Path: Delivered-To: freebsd-arch@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 38279B58 for ; Sat, 17 Jan 2015 07:47:47 +0000 (UTC) Received: from spazito3.arvixevps.com (spazito3.arvixevps.com [108.175.154.180]) (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 1839B5FC for ; Sat, 17 Jan 2015 07:47:47 +0000 (UTC) Received: from diariodoestadoms by spazito3.arvixevps.com with local (Exim 4.84) (envelope-from ) id 1YCO6l-000Cj1-Kw for freebsd-arch@freebsd.org; Fri, 16 Jan 2015 23:47:47 -0800 To: freebsd-arch@freebsd.org Subject: Dear Beloved From: Madam Abra Jericho. Reply-To: mrsabrajerichofamily@gmail.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: Date: Fri, 16 Jan 2015 23:47:47 -0800 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spazito3.arvixevps.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [505 504] / [47 12] X-AntiAbuse: Sender Address Domain - spazito3.arvixevps.com X-Get-Message-Sender-Via: spazito3.arvixevps.com: authenticated_id: diariodoestadoms/only user confirmed/virtual account not confirmed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 07:47:47 -0000 Dear Beloved I am Madam Abra Jericho.A complete citizen of the Philippines, widow to the late Mr Mayor Jericho who was a victim of the terrorist attack in my country.We were married for 7 years without a child and my late husband was a government contractor. Before his death he had a foreign account in Germany the sum of $7.8M. This deposit was coded under a secret arrangement as a family treasure. This means that the security company does not know the real content of this trunk box which he distinguished and deposited with a security company in Germany I want you to do me a favor to receive this funds to a safe account in your country or any safer place as the beneficiary. I have plans to do investment in your country,like real estate and industrial production and I plead you take it as personal task to assist the widow like me. This is my reason for writing to you.Please if you are willing to assist me indicate your interest in replying. Yours Madam Abra Jericho From owner-freebsd-arch@FreeBSD.ORG Sat Jan 17 19:11:11 2015 Return-Path: Delivered-To: freebsd-arch@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 60A829BF; Sat, 17 Jan 2015 19:11:11 +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 028D5D49; Sat, 17 Jan 2015 19:11:11 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id l18so25516wgh.8; Sat, 17 Jan 2015 11:11:09 -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=v6jicreNp+iU9J+2pinh4dDEBuH3xAlE72cgbT3I0LY=; b=rJejnzvxq6OzLB0CdCrbDSKhP6WGJOn/B5ySq5KAuDPJcaPB+t9EuKxsqcJXcr5xyV oAk5MOEOXl/XadjbQccfJrwMXa2/Q079Z7s2/4d23vXrQ4YPaUvT+m1u14vrBnSnZUBB Qf7NVpMBRXxjco3jM0L5IR45Z0VgNmdMvzbv8/Z83yPHu2vf67gC+d6tDTU2z2CTE8id jKNqqIDxgUvoSovTYZA8rfLzeV/tGzk25DJluV5bA3b4NS7s9LE0555e9Hyz5waMHPDm X8vhlC95VQgvaqppba77ZMvofb/UUDgzdVRNzV3DDd0RVYwq7NVclS2c0AY8OoxzNFzj ZhNQ== MIME-Version: 1.0 X-Received: by 10.180.104.9 with SMTP id ga9mr18890378wib.9.1421521868935; Sat, 17 Jan 2015 11:11:08 -0800 (PST) Received: by 10.216.37.68 with HTTP; Sat, 17 Jan 2015 11:11:08 -0800 (PST) In-Reply-To: <54B7DECF.8070209@selasky.org> References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> Date: Sat, 17 Jan 2015 12:11:08 -0700 Message-ID: Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress From: Jason Wolfe To: Hans Petter Selasky , John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , FreeBSD Current , Sean Bruno , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 19:11:11 -0000 On Thu, Jan 15, 2015 at 8:37 AM, Hans Petter Selasky wrote: > On 01/14/15 15:31, Hans Petter Selasky wrote: >> >> On 01/11/15 19:08, Jason Wolfe wrote: >>> >>> Hans, >>> >>> We've had 50 machines running 10.1-STABLE with this patch for the >>> better part of a week without issue. Prior we would have seen a panic >>> every few days at the least, so things are looking very promising on >>> our front. >>> >>> Jason >> >> >> Hi, >> >> I've updated D1438 including the manual page changes needed for >> timeout.9 aswell in addition to a minor fix for those using timeout() >> and untimeout() and KTR(). >> >> https://reviews.freebsd.org/D1438 >> >> --HPS > > > FYI: > > Now in -current: > > https://svnweb.freebsd.org/changeset/base/277213 > > Thanks for all good comments and reviews. > > --HPS HPS, Just to give a quick status update, this patch has most certainly resolved our spin lock held too long panics on stable/10. Thank you to JHB for spending some time digging into the issue and leading us to td_slpcallout as the culprit, and HPS for your rewrite. I had heard rumors of other being affected by similar issues, so this seems like a fine candidate for an MFC if possible. Jason From owner-freebsd-arch@FreeBSD.ORG Sat Jan 17 22:17:48 2015 Return-Path: Delivered-To: freebsd-arch@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 A710CC85; Sat, 17 Jan 2015 22:17:48 +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 5A112FAE; Sat, 17 Jan 2015 22:17:48 +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 B41C31FE023; Sat, 17 Jan 2015 23:17:38 +0100 (CET) Message-ID: <54BADFB3.3030405@selasky.org> Date: Sat, 17 Jan 2015 23:18:27 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jason Wolfe , John Baldwin Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , Sean Bruno , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 22:17:48 -0000 On 01/17/15 20:11, Jason Wolfe wrote: > > HPS, > > Just to give a quick status update, this patch has most certainly > resolved our spin lock held too long panics on stable/10. > > Thank you to JHB for spending some time digging into the issue and > leading us to td_slpcallout as the culprit, and HPS for your rewrite. > I had heard rumors of other being affected by similar issues, so this > seems like a fine candidate for an MFC if possible. > > Jason > Hi Jason, I'm glad to hear that my patch has resolved your issue and I'm happy we now have a more stable system. It was actually a co-worker at work which wrote some bad code which I started debugging which then lead me to look at the callout subsystem. One bug kills the other ;-) I'm planning a MFC to 10-stable - yes, and will possibly add the _callout_stop_safe() function to not break binary compatibility with existing drivers as part of the MFC. --HPS