Date: Tue, 22 Aug 1995 13:57:48 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@cs.weber.edu Cc: gibbs@freefall.FreeBSD.org, hackers@freefall.FreeBSD.org Subject: Re: Clock interrupts during probes? Message-ID: <199508220357.NAA22174@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> if (p) {
>> ...
>> pstats = p->p_stats;
>> ...
>> if (timerrisset(&pstats->p_timer[ITIMER_PROF].it_value) ...
>> }
>This is critically bogus. There is no reason for the timer code to need
>to have knowledge of the process -- ESPECIALLY the initialization code.
Er, the timer code needs to gather statistics for the current process.
Most statistics is gathered in statclock() which has slower than necessary
code to allow for p->pstats being NULL.
>> traps from buggy interrupt handlers. Perhaps all traps that occur
>> before proc0 is initialized should be fatal.
>A trap can result in a wakeup, done on the process address.
>This is actually also a bogus assumption, since it neglects both SMP
>and the fact that the scheduler isn't running yet. Interrupts to the
The kernel isn't paged, so I don't think any traps should normally occur
before init is started. Software bugs can cause division by zero and
hardware bugs can cause NMI (NMI is unsafely handled as a trap. It
should be handled as an interrupt).
>devices prior to the scheduler/processor startup should be ignored
>in all cases. The only "benefit" to aking them is that you get an
>extra I/O when it's possible to process them.
Interrupts during device probing would be useful.
>In the issue of SPL's, the spl0 is set in the forked processes prior to
>them going into their tight loop. I can see no reasonable benefit from
>this, specificall in vmdaemon().
I think it is a no-op.
>Also in the neighborhood of the SPL's: the s = splimp() / stuff / splx(s)
>trap around the car interfaces and domain initialization is all rather
>silly, since it implies interrupts are enables prior to the cards being
>active. Most likely, the probe routines should shutdown the interrupts
>once it has been probed true, and the interrupts should be restarted as
>part of the attach, which should take place after domain initialization.
Attach takes place very early, so interrupts for all configured devices
are enabled very early.
>> 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).
>As you point out, no sleep context, which implies no sleepers, which implies
>the idea of wakeup is bogus.
Each coroutine instance would provide a sleeper.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508220357.NAA22174>