Date: Sat, 5 Nov 2005 23:23:26 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Poul-Henning Kamp <phk@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/puc puc.c Message-ID: <20051105232325.A41277@newtrinity.zeist.de> In-Reply-To: <200511052104.jA5L4rBS020286@repoman.freebsd.org>; from phk@freebsd.org on Sat, Nov 05, 2005 at 09:04:53PM %2B0000 References: <200511052104.jA5L4rBS020286@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 05, 2005 at 09:04:53PM +0000, Poul-Henning Kamp wrote: > > phk 2005-11-05 21:04:53 UTC > > FreeBSD src repository > > Modified files: > sys/dev/puc puc.c > Log: > Now that fast interrupts can be shared we can use them in puc. > > Revision Changes Path > 1.42 +1 -0 src/sys/dev/puc/puc.c PUC_FASTINTR used to cause problems on sparc64 where puc(4) is (ab)used to multiplex the resources of SCCs for uart(4) which then attaches to each channel of a SCC separately. IIRC what's going was that when say uart0 attaches to the first channel an interrupt fires and uart(4) doesn't manage to clear the interrupt pending bits because uart1 isn't attached to the second channel, yet, causing uart_intr() to loop endlessly. This would only happen with an INTR_FAST handler as unlike non-fast handlers the former are instantly active when set up. I'm unsure about the details, e.g. the endless loop might actually occur a bit later during probing uart1 or before it's fully attached but I think the problem is still there. Marius -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051105232325.A41277>