Date: Tue, 22 Aug 1995 02:45:34 +1000 From: Bruce Evans <bde@zeta.org.au> To: gibbs@freefall.FreeBSD.org, hackers@freefall.FreeBSD.org Subject: Re: Clock interrupts during probes? Message-ID: <199508211645.CAA01423@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>What are the issues involved in allowing clock interrupts during
>probes? The PCI code already does this so I would think it possible
>to do it for the others.
Actually, the PCI code only allows previously enabled interrupts.
Interrupts for previously configured devices are usually enabled at
this point, but clock interrupts aren't enabled until quite late in
init_main.c (by initclocks()).
The PCI code and the EISA code shouldn't be allowing interrupts.
Some of the ISA code called by the PCI and EISA code was written
under the assumption that interrupts are disabled. E.g., INTREN().
It's not obvious that INTREN() is safe to call at splhigh() like the
ISA code does. Perhaps it isn't safe :-[.
I don't see many reasons why clock interrupts need to be enabled so
late. Perhaps the only reason is that curproc is bogusly initialized to
&proc0 before proc0 is initialized. curproc is statically initialized
and is reinitalized to the same thing near the start of init_main().
This would cause hardclock() to follow a null pointer if it was called
early:
if (p) {
...
pstats = p->p_stats;
...
if (timerrisset(&pstats->p_timer[ITIMER_PROF].it_value) ...
}
It would be more natural to leave curproc initialized to NULL until quite
late, but init_main() says
/*
* Initialize the current process pointer (curproc) before
* any possible traps/probes to simplify trap processing.
*/
I think the idea is that traps should only occur in process context
so trap handlers need not check for (curproc == NULL). However, at
least the i386 pagefault handler checks curproc, and all trap handlers
should probably check it, if only to panic as early as possible for
traps from buggy interrupt handlers. Perhaps all traps that occur
before proc0 is initialized should be fatal.
>It would certainly make the job of having
>the SCSI code perform the proper delays between retries easier. It
>would also be the first step in getting rid of the ugly DELAY()'s in
>driver code.
Not much easier - there would be no process context to sleep on. I
think we need something using coroutines to probe and attach all (or
large batches of) devices concurrently at boot time. Make the
coroutine switch mechanism look like tsleep() and have the same
semantics as tsleep() so that the same probe and attach code works
correctly after the system is up. DELAY(n) would become
csleep(&foo, PRIBIO, "foodelay", (n * hz) / 1000000).
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508211645.CAA01423>