> Hello,
> 
> I have a few questions which I hope someone reading this list knows more about
> than I do.
> 
> These are the result of trying to track a race condition or two...
> 
> With spl levels is there a recommended order (and what is it)? How much danger
> is there likely to be associated with deviating from this order? I thought I
> knew the answer to these but experience has taught me that perhaps I didn't...

There is a recomended order, well a dependancy list. I think it's in
the red book, and it's burried in the code, too. But it's burried
deep, I'll admit. :-)

> printf()/log() seem to be used all over the place in drivers and in various
> bits of debugging throughout the NetBSD kernel, much of which can be called by
> interrupt routines. I have spent about 6 hours tracing the logic of the tty
> code and it looks to me as if the functions in question should not be called
> from interrupts capable of occurring at spltty() (cf my first question). The
> comments on the functions say that they can be used in interrupt routines but
> make no reference to any limitations. If nobody can explain why it is safe to
> call the functions from interrupts capable of interrupting spltty() I suggest
> that these comments should be changed to explicitly mention any limitations.

As I've debugged the serial drivers for the mac, I've run into this
problem. You're right that printf's at interrupt time are bad. The
8530 serial driver (zsc & zstty & friends) will only do logging in a
routine which sets spltty.

A number of the spl level stuff is a form of blanket resource lock. spltty
locks ALL the tty queues. But a process (or an interrupt handler..) only
needs to worry about access to one particular tty queue. Thus the printf's
will probably work if they are touching one queue when the process which
asserted spltty is touching another.

I was told that there was some sort of mechanism to make kernel printfs
safe, but I'm not familiar with it. It sounds like you've looked at that
part of the code more recently.

For debugging interrupt routines, I now just call one of the console
putc routines to put up a letter indicating what's up. These messages don't
get logged, but they get the point across. I use itecnputc, for those who
care. :-)

> If the above is true and different ports use different spl orderings then
> presumably use of printf()/log() in the interrupt routines of generic drivers
> (or anything that can be called by them) is a Bad Thing (tty code excepted).

Documenting things better is good. But I think the reason we get away with
the status quo is that only the bottom half side of the driver has
this restriction.

Take care,

Bill