Skip site navigation (1)Skip section navigation (2)
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>