Date: Thu, 11 Jul 2013 09:41:34 -0400 From: John Baldwin <jhb@freebsd.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar <marcel@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r253161 - head/sys/dev/uart Message-ID: <201307110941.34400.jhb@freebsd.org> In-Reply-To: <BF25167F-A24A-479E-85C7-6D47588DEDAD@xcllnt.net> References: <201307101742.r6AHgKOm024113@svn.freebsd.org> <201307101409.42228.jhb@freebsd.org> <BF25167F-A24A-479E-85C7-6D47588DEDAD@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, July 10, 2013 3:59:40 pm Marcel Moolenaar wrote: > > On Jul 10, 2013, at 11:09 AM, John Baldwin <jhb@FreeBSD.org> wrote: > > > 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? > > No. I only have proof of a hard hang during auto configuration that > cannot be fixed in any other way than not to setup the interrupt at > all. Ok. I think what is happening is that you are just spinning in the interrupt handler forever due to the hardware being stuck in that case in the old code. I assume you tried just using the count first but it still hung? (Perhaps the interrupt was for a PCI device and level-triggered and so it kept reasserting anyway?) I think your change is correct for a uart that is stuck in this way regardless, I just think the hang isn't related to weirdness with x86 temporarily re-enabling interrupts. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307110941.34400.jhb>