Re: Sources of jiffy inconsistencies.

Rafael R. Reilova (rreilova@ececs.uc.edu)
Thu, 28 May 1998 13:04:56 -0500 (EST)


Hello Andre,

On Thu, 28 May 1998, Andrew Derrick Balsa wrote:

> I have been looking for sources of jiffy inconsistencies (missed timer
> interrupts, mostly), and I think I just found a nasty one: the beep code
> in /drivers/char/vt.c.
>
> First, it has the horrible cli()-sti() pair in function _kd_mksound. I
> checked 2.1.92 and 2.0.33, and both have cli()-sti(). I don't know about
> 2.1.10x kernels. Could you check that for me, since I know you keep your
> kernel at the cutting edge?

Its in there! (2.1.103) I think you're on to something more here. People
have reported "random" freezeups with heavy network traffic, I wonder if
this would account for part of it. I remember someone mentioned running
pine, well, pine beeps when a new message arrives. OTOH, in not familiar
with the code, so I may be completely mistaken.

> Second, interrupts shouldn't be disabled the way they are. There is
> nothing critical at all around some parts of the code.

It looks quite dangerous to me too!

> I am certain that looking well into what the code does and how it does
> it, one can completely remove the cli()-sti() pair, or at least make it
> limited to the CTC programming instructions. I wouldn't care too much if
> the beep lasts 1/100th of a second more than it should, but I _do_ care
> about not losing any timer interrupts :-)

I don't see any use at all for the cli/sti, unless somewhere else in the
kernel someone is also using timer2 at the same time (and then that would
be a bug, wouldn't it). The add_timer/del_timer are already protected (of
course ;-) I don't have a hardware reference nearby, but why would it
matter if we write to the timer2 ports w/ interrupts enabled. Nobody else
should be using them, right?

The only thing that comes to mind is the case where you're setting the
timer for a new beep, and a previous beep finishes. The timer interrupts
you in the middle of setting up. IMHO, this only requires mutual
exclusion between kd_mksound and kd_nosound plus a flag to keep kd_nosound
from disconnecting the PC speaker if a new beep just begun. Unless you
want a short break between beeps instead of a long continuous one :-)

> Can I ask you to report this on the kernel list? My posts don't seem to
> be making it to the list these days...
>

Sent!

> Cheers,
> ------------------------
> André Balsa
> andrebalsa@altern.org
>

--
Rafael

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu