From owner-svn-src-head@FreeBSD.ORG Wed Jul 10 18:09:47 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 468E9145; Wed, 10 Jul 2013 18:09:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 23FFE11C4; Wed, 10 Jul 2013 18:09:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8D89FB97F; Wed, 10 Jul 2013 14:09:46 -0400 (EDT) From: John Baldwin To: Marcel Moolenaar Subject: Re: svn commit: r253161 - head/sys/dev/uart Date: Wed, 10 Jul 2013 14:09:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307101742.r6AHgKOm024113@svn.freebsd.org> <201307101405.44158.jhb@freebsd.org> In-Reply-To: <201307101405.44158.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201307101409.42228.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 10 Jul 2013 14:09:46 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 18:09:47 -0000 On Wednesday, July 10, 2013 2:05:43 pm John Baldwin wrote: > On Wednesday, July 10, 2013 1:42:20 pm Marcel Moolenaar wrote: > > Author: marcel > > Date: Wed Jul 10 17:42:20 2013 > > New Revision: 253161 > > URL: http://svnweb.freebsd.org/changeset/base/253161 > > > > Log: > > Protect against broken hardware. In this particular case, protect against > > H/W not de-asserting the interrupt at all. On x86, and because of the > > following conditions, this results in a hard hang with interrupts disabled: > > 1. The uart(4) driver uses a spin lock to protect against concurrent > > access to the H/W. Spin locks disable and restore interrupts. > > 2. Restoring the interrupt on x86 always writes the flags register. Even > > if we're restoring the interrupt from disabled to disabled. > > 3. The x86 CPU has a short window in which interrupts are enabled when the > > flags register is written. > > Do you have proof of this? I have never seen anything like this documented. > It would be fundamentally broken if true. In fact, if anything the evidence > I have seen is the exact opposite: that Intel is very careful to prevent races > of this sort. Specifically, Intel CPUs have long had a feature of disabling > interrupts for the instruction following POP SS to permit atomic loads of > SS:ESP (for code that doesn't use LSS). I highly doubt your claim is true. > > In fact, I think you might be confused by the VME bits (VIP and VIF). The > POPF instruction is documented to clear VIP and VIF, but those flags only > matter when operating in virtual 86 mode. They are not relevant to our > kernel. I think you need to find a real explanation for the hang you are > seeing. Also, to be clear, if CPUs behave the way you described, our x86 ports would have been horribly unstable since at least 5.0. We depend on nested unlocks not transparently enabling interrupts to prevent nested interrupt frames (which can quickly exhaust the kernel stack and lead to a double fault, back when doing early ithread work these were not hard to provoke). I have not see a single report of a double fault due to this type of recursion since 5.0 was released -- John Baldwin