L4-Linux worked on 486!

[Jochen Liedtke]

are the interrupts constantly disabled from raising the interrupt until executing that code?
	(Unspecific eoi (0x20) always clears the highest irq. If an interrupt can happen between raising the original interrupt and executing the unspecific eoi, this might clear a higher irq instead of the currently handled irq. Consequences: arbitrary confusion: the higher irq is cleared too early, the next unspecific eoi clears a lower irq, ...) 

	Jochen


> -----Original Message-----
> From: owner-l4-hackers at os.inf.tu-dresden.de
> [mailto:owner-l4-hackers at os.inf.tu-dresden.de]On Behalf Of
> edmundo at rano.demon.co.uk
> Sent: Sonntag, 1. August 1999 17:46
> To: suzukis at file.phys.tohoku.ac.jp
> Cc: l4-hackers at os.inf.tu-dresden.de
> Subject: Re: L4-Linux worked on 486!
> 
> 
> > >It dies after saying "irq still active".
> > >(To get that message I'm using the patch that Michael Hohmuth
> > > posted to the list on July 25.)
> > > I think I may have found a bug in the SANITY code in
> > > linux22/arch/l4-i386/kernel/irq.c, by the way. See below.
> > 
> > I remember, I've ever seen same message & following crash,
> > thanks for the patch.
> 
> Unfortunately I still don't understand why the irq is "still active".
> 
> Here's the corresponding bit of code in irq.c. (The lines which aren't
> indented as much as they should be came from Michael's debugging
> patch.)
> 
> 
>   mask = 1 << (irq & 7);
>   if (irq < 8)
>     {
>       outb(inb(0x21) | mask, 0x21);	/* block the irq */
>       outb(0x20, 0x20);	/* acknowledge the irq */
> 
> outb(0x0B, 0x20);
> if (inb(0x20) & mask)
>   enter_kdebug("irq still active");
>     }
>   else 
>     {
> unsigned foo;
> 
>       outb(inb(0xA1) | mask, 0xA1);	/* block */
>       outb(0x20, 0xA0);	/* acknowledge */
>       outb(0x0B, 0xA0);
>       if ((foo = inb(0xA0)) == 0)
> 	outb(0x20, 0x20);
> if (foo & mask)
>   enter_kdebug("irqslave still active");
> 
>     }      
> 
> 
> If you look at the bottom of kernel/fiasco/src/irq.h you'll find an
> unused function irq_ack() which does roughly the same thing, because
> acknowleding the IRQ is something that ought to be done by L4/Fiasco,
> but is at present done by Linux.
> 
> So why do we get "irq still active" during heavy use of the network
> card? Is there a PIC expert in the house?
> 
> Is it possible that the problem is caused by the interrupt not being
> acknowledged quickly enough? If so, maybe I should move the ack from
> Linux into Fiasco ...
> 
> Edmund
>