Port-sparc archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: mostly working SMP again
On Mon, Jan 04, 2010 at 04:47:41PM +1100, matthew green wrote:
>
> hi folks.
>
>
> i've commited several changes to -current today that make SMP almost
> work for me. i have to comment the stray interrupts panic and beyond
> that it seems to mostly work.
What defines a 'stray interrupt' ?
one where no driver claims it. in this case, it is always cpu0
reporting the stray. sparc/intr.c will panic with "crazy
interrupts" if it sees more than 10 strays in 10 seconds.
If an ISR writes to the hw control register to remove the IRQ
immediately before returning from the ISR it is very easy for the
cpu to take an interrupt before the IRQ line is deasserted.
This can lead to none of the ISR in the ISR chain 'claiming' the
interrupt. It might also mean the the IACK sequence fails to find
an asserted IRQ line - for sparc this might be software.
(the interrupt controller on i386 returns IRQ7).
If this is likely to be the case then it isn't really an error.
Device drivers need to minimise the number of times this happens,
but the cost of a full flush of the write is only needed in the case
where the IRQ returns quickly (and it may need the PCI bus to be busy).
so this occurs only on polled console output (maybe input, but
those are very rare...)
the sparc zscnputc() routine does the following:
a - splhigh()
b - redirect all interrupts to me
c - waits for transmitter to be ready
d - write character
e - redirect all interrupts to original source
f - splx()
and my current assumption is that if cpu1 is running this code,
we end up with a spurious interrupt on cpu0. my guess is that
sometime after (e) above, the transmitter clears and then an
interrupt is generated for this, now sent to cpu0.
more investigation is needed at this point.
.mrg.
Home |
Main Index |
Thread Index |
Old Index