Date: Mon, 21 Aug 95 22:32:26 MDT From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, gibbs@freefall.FreeBSD.org, hackers@freefall.FreeBSD.org Subject: Re: Clock interrupts during probes? Message-ID: <9508220432.AA28561@cs.weber.edu> In-Reply-To: <199508220357.NAA22174@godzilla.zeta.org.au> from "Bruce Evans" at Aug 22, 95 01:57:48 pm
next in thread | previous 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.
0 isn't a real process. The 'if (p) {' code implies that a NULL process
is possible -- any place other than boot where this would be the case?
> 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).
AGREE!
> >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.
Yes. But then again, that's a special case, where they can be enabled
during the probe but disable again until they are subsequently attached.
I think this might be the issue with the ft driver hanging on boot,
actually. It doesn't affect the fact that they are disabled at
once after the probe and thus don't cause traps.
The question is then whether you trap them all to you when you enable
them, or whether on probe succes, ownership is assumed by a NULL
handler and the interrupt-with-no-handler case is the probe coming true.
I'd actually vote for the second: The PCI case of shared interrupts
argues for not trapping ownership. That would let ISA nad EISA non
shared instances assume ownership. This implies the probe-true state
is kept seperately, not derived from the fact that it has an interrupt
hooked (which is better than every device having their own null routine
anyway).
In the case of interrupts occurring on a device that has been probed
but not attached (and therefore shouldn't be generating them in the
first place) during a subsequent probe, well, the NULL handler grabs
them before the fall into the interrupt-with-no-handler case and cause
a false "probe true". This is already partially handled in to non
"allow conflicts" case, but that doesn't help serial or other devices
that are going to spit no matter what.
> >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.
Yeah, me too. I wanted an opinion from the author, though.
> >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.
Probably I should have stated this as "attach should take place later".
The problem here, of course, if NFS mount of root.
> >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.
Hmmm. This complicates the probe a bit, but not unreasonably so. It would
actually help in the case of where you are trying to get the interrupts
up early and probe the clock first. It's probably the right way to clean
it up. It buys you simultaneous attach for long delay devices, if the
interrupt stuff is handled correctly. 8-).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508220432.AA28561>