Re: IRQ handling

[robert@par.univie.ac.at (Robert Mayer - Student) writes:]

>...
>After a little bit of kernel reading I found the reason: IRQ 7 is
>disabled by pointing it's vector to a routine that simply IRETs (in the
>comment it says that there were problems with stray interrupts).

Yes, I'm afraid you have headed down the Wrong Path. Not only does IRQ 7
provide interrupts spuriously, it also does not deliver printer interrupts
reliably. This is why 386BSD's (and, I believe, Linux's and FreeBSD's) LP
drivers usually are the so-called "interruptless" versions. they use timing
loops and polling instead.

Let me know if you would like a copy to examine.

>In os/mach/trap.c line 597 there is a call to hardclock() without parameters.
>The function hardclock lives in os/kern/xclock.c and it is implemented like
>this:
>void hardclock(uint x)
>{
> struct trapframe *f = (struct trapframe *)&x;
>...
>I don't know if this really is a bug, because everything works fine, but it
>sure looks strange to me.

The 386 places the internal state on the stack, and then starts running
at our interrupt handling code. So, at the place where parameter "x"
*would* have been, if it had been called from C, is a stack frame with the
format described by "struct trapframe". So when you set a pointer to where
a parameter *would* have been, you are saying that you *know* the format of
the frame at that place, and the format is "struct trapframe". I might have
written it as:

void hardclock(struct trapframe f)
{
}

But C has a lot of latitude in how it implements call-by-value for passing
of structures, and I wanted to avoid this gray area entirely.

                                        Regards,
                                        Andy
Received on Sun Mar 13 13:22:32 1994