[Top] [All Lists]

Re: kernel sources?

To: "Kevin D. Kissell" <>
Subject: Re: kernel sources?
From: Geert Uytterhoeven <>
Date: Sun, 16 Jan 2000 13:32:46 +0100 (CET)
Cc: Ralf Baechle <>, Linux/MIPS <>
In-reply-to: <005e01bf5f7d$fc1cf490$>
On Sat, 15 Jan 2000, Kevin D. Kissell wrote:
> >On Thu, Jan 13, 2000 at 05:03:39PM +0100, Geert Uytterhoeven wrote:
> >
> >> I used the R5000 CP0_COUNTER/CP0_COMPARE registers for the timer 
> >> interrupt. I
> >> know it's not accurate, but it's better than nothing. I still have to 
> >> figure
> >> out how more complex interrupts work in the MIPS source tree.
> >
> >It is accurate as driven by the CPU's clock.  It is just somewhat tricky to
> >handle and even more tricky on some broken CPUs.  From an old email written
> >by Bill Earl:
> >
> >[...]
> >As far as I know, all R4000 processors, and possibly some R4400 processors,
> >are affected.  The bug is that, if you read $count exactly when it equals
> >$compare, the count/compare interrupt for that count/compare crossing is
> >discarded.  The workaround from IRIX is appended.  The variable
> >r4000_clock_war is set to 1 if the system is an Indy with an R4000 processor.
> >The r4k_compare_shadow is set to the same value as $compare whenever $compare
> >is updated (with interrupts masked while the variable and $compare are
> >updated together).
> >[...]
> There is also a race condition inherent in many implementations of
> the timer interrupt handler, and the main stream of the current
> MIPS/Linux distributions is no exception.   The SGI code looks
> a bit like this:


> The inherent race is in the fact that the count is sampled
> once at the beginnning of the routine and used throughout.
> It is possible (with bad luck and sloppy drivers) to be very
> late into the handler, so much so that the new time-out time
> can be reached between the sample and the programming
> of the compare register.  If that happens, one gets no timer
> interrupt for a full wrap of the count register.   I first observed
> this in OpenBSD, where the problem was worse, but Linux
> has the same conceptual hole.  A more robust handler
> looks a bit like this:

I noticed this as well, especially if I put serial debug code in the interrupt
handler. Then it's safer to always reset count to 0 in the interrupt handler.
Of course it's very inaccurate then, but at least you keep on getting
interrupts in a reasonable time frame.

Now I'm using one of the timers in the host bridge to generate the actual timer
interrupt, which seems to work fine. I could also use the normal PC RTC, but
then I have to get the i8259 interrupts working first. Fortunately PCI
interrupts are handled by the host bridge as well, so I see no hurry in getting
the i8259 interrupts working too soon :-)

Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} --

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                                            -- Linus Torvalds

<Prev in Thread] Current Thread [Next in Thread>