L4-Linux worked on 486!

[Michael Hohmuth]

edmundo at rano.demon.co.uk writes:

> Jochen Liedtke asked, and I think it's a crucial question:
> 
> > are the interrupts constantly disabled from raising the interrupt
> >until executing that code?
> 
> Looking at the code, I think the answer is yes. (There is, however,
> quite a lot of code between the interrupt happening and the
> non-specific EOI being issued, and there are lots of macros and
> conditional compilations, so I might be wrong. 

Unfortunately, you are wrong: Fiasco likes to enable interrupts
(because it is a real-time kernel), and there is no guaranty at all
that irqs will remain disabled until the EOI is issued (even if the
irq thread enters the kernel with interrupts disabled).

> Is it possible to inspect the state of the interrupt-disable flag
> using remote gdb?)

Yes, with "info registers" (or "i r" for short).  But when you're in
the debugger, it will be too late.

> In which case I no longer understand what Jean Wolter wrote about
> priority assignment to interrupt threads. If interrupts are
> constantly disabled from raising the interrupt until the
> non-specific EOI, how can the priorities matter? If the PIC can
> "deliver" an interrupt with higher priority while interrupts are
> disabled,

It can't.

> and if the non-specific EOI then acknowledges the highest-priority
> interrupt that was delivered, 

It doesn't, in the sense of "deliver" you defined above.

> as opposed to the hightest-priority interrupt that is being
> serviced, then we are always in trouble if we issue a non-specific
> EOI with interupts disabled. In this case, should we reenable
> interrupts before doing the EOI?
> 
> But I can't think why the PIC should have been designed this way.

It isn't.  Unspecific EOI acknowledges the latest irq that has been
accepted by the CPU, and if the CPU is in "cli" mode, it will not
accept an irq no matter what its hardware priority in the PIC is.

So, given that the CPU operates in "cli" mode, hardware priorities
don't matter.  

But it doesn't operate in "cli" mode at all times.  And even if it
would, there are problems with the irq threads' software priorities:
Unlike L4/x86, Fiasco doesn't deliver an irq-IPC message to an
interrupt thread if there is a different thread with a higher
priority; instead, the irq ``sender'' is blocked and queued in the irq
thread's sender queue.  This can lead to a thread different from the
irq thread being scheduled and, as a consequence, to interrupts being
enabled in the CPU ("sti" mode).

> [...]
> To reconcile this, I am lead to conclude that my inspection of the
> code is mistaken, interrupts are not disabled constantly from raising
> the interrupt until issuing the EOI, and this is deliberately so, 

This is correct.

> but somehow we are ending up in the wrong interrupt thread after a
> higher-priority interrupts interrupts a lower-priority one.

Yep.  Maybe some event or IPC caused an lower-priority irq thread to
be scheduled before a higher-priority irq thread could acknowledge its
irq.

> I'm really out of my depth here. Can anyone recommend a good book, or
> other source of information, about x86 and PIC programming? (I don't
> need an introduction to assembler programming, as I did a lot of 6502
> and 8080 as a child, but I don't know much about x86 specifics or
> about interrupt details.)

I don't know of any good book describing PIC programming.  The best
reference I could find was a specification of the ``legacy interrupt
controller'' for the PowerPC CHRP platform (which probably emulates
the PIC's interface for old x86-PC hardware).  But this is only a
specification and not a programming manual.  Among other places, it's
available in Chapter 4 of <URL:
ftp://ftp.austin.ibm.com/pub/technology/spec/chrp/inwork/CHRP_IORef_1.0.pdf>.

You might also want to try doing a websearch on "programmable
interrupt controller programming" or somesuch; I just did a quick
search, and <URL:http://www.geocities.com/SiliconValley/Bay/8302/interupt.htm>
seems to be a nice intro, but it doesn't discuss the special fully
nested mode Fiasco uses.  A search on "special fully nested mode"
brought up a description of a PCI bridge containing PIC functionality
at <URL:http://www.intel.com/design/intarch/techinfo/430tx/ticTOC.htm>.

Michael
-- 
hohmuth at innocent.com, hohmuth at inf.tu-dresden.de
http://home.pages.de/~hohmuth/