On Apr 24, 2008, at 9:27 AM, Marius Strobl wrote:
On Wed, Apr 23, 2008 at 06:26:14PM -0700, Marcel Moolenaar wrote:
On Apr 23, 2008, at 5:40 PM, Peter Wemm wrote:
On Wed, Apr 23, 2008 at 5:58 AM, John Baldwin <[EMAIL PROTECTED]>
wrote:
On Saturday 19 April 2008 03:25:57 am Peter Wemm wrote:
peter 2008-04-19 07:25:57 UTC
FreeBSD src repository
Modified files:
sys/amd64/amd64 machdep.c
Log:
Put in a real isa_irq_pending() stub in order to remove two lines
of
dmesg noise from sio per unit. sio likes to probe if interrupts
are
configured correctly by looking at the pending bits of the atpic
in order
to put a non-fatal warning on the console. I think I'd rather
read the
pending bits from the apics, but I'm not sure its worth the
hassle.
Actually, the x86 interrupt sources have a pending method so this
can be
replaced. Could probably easily write something like this:
int
intr_pending(u_int irq)
{
struct intsrc *isrc;
isc = intr_lookup_source(irq);
if (isrc == NULL)
panic("bizarre");
return (isrc->is_pic->pic_pending(isrc));
}
For intr_machdep.c and use this in sio:
#if defined(__i386__) || defined(__amd64__)
foo = intr_pending(rman_get_start(irq_resource));
#else
foo = isa_irq_pending() & (1 << rman_get_start(irq_resource));
#endif
or some such. I'd really prefer to kill isa_irq_pending().
Let's just add intr_pending() to all MD backends that currently
provide isa_irq_pending() for sio's benenfit. Either as a simple
wrapper around the now-static local isa_irq_pending() (ia64), or by
simplifying and converting isa_irq_pending() into intr_pending()
(sparc64).
sio() is only for i386 and amd64, isa_irq_pending() should be
removed from all MD code, except from i386 and amd64.
How likely is it that another driver starts using
isa_irq_pending() or a intr_pending()?
I think it's Very unlikely.
There's no portable use of these functions possible. The best
way to check if IRQ settings are correct is by registering an
ISR, raise an interrupt and check if the ISR gets called.
This is because PICs get programmed as part of setting up ISRs.
Thus, interrupts without an ISR have undefined behaviour.
Of course, registering an ISR and raising an interrupt to check
if the settings are correct has the same side-effects as
unchecked interrupt use: storms and/or stray interrupts.
--
Marcel Moolenaar
[EMAIL PROTECTED]
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
