On Wednesday, July 10, 2013 3:59:40 pm Marcel Moolenaar wrote: > > On Jul 10, 2013, at 11:09 AM, John Baldwin <j...@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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"