Re: 2.4.20 kernel/timer.c may incorrectly reenable interrupts

Ingo Oeser (ingo.oeser@informatik.tu-chemnitz.de)
Tue, 15 Apr 2003 22:32:05 +0200


Hi George,
hi Keith,
hi lkml,

On Mon, Apr 14, 2003 at 02:49:39PM -0700, george anzinger wrote:
> Ingo Oeser wrote:
> > On Fri, Apr 11, 2003 at 02:21:38PM -0700, george anzinger wrote:
> >
> >>Ingo Oeser wrote:
> Yes, I believe this is what RTLinux and RTIA do. The sti macro then
> needs to check for pending interrupt work, much as the bh_unlock does.

Ok, NOW we are talking ;-)

> > Not suitable for drivers. They must read the registers, set some
> > other registers and ACK the IRQ in the ISR. There is no way
> > around that.
>
> The lock has two sides, the reader and the writer. The writer still
> takes the irq/ spinlock, only the reader gets the speed up.

But the read can read garbage and may need a retry. This is not
acceptable for me, since one of my cards will do destructive
reads. They implement a hardware FIFO (of one element depth),
where the register I read from is removing the element while
reading. This is a common design you'll find in PCI-bridge chips
(I used the S5933 from AMCC for this).

So this scheme still doesn't help me and is not the proper
drop-in replacement, we are looking for.

BTW: Please note, that you can assume I know the semantics of all
the locking functions currently in Linus' tree. So you can
stop explaining me the details of them and continue with
defining a proper cli/sti replacement. Thanks!

> > So if there would be a schedule_work_deadline() then this would
> > be nice. The routine called later in process context called will
> > be noticed, if the deadline is missed or not and can act
> > correctly.
[...]
> > We currently have timers, but they are not suitable for doing the
> > work only for triggering it and that's a source of complexity in
> > driver design.
>
> Something of this sort is present in the workqueues design. There is
> a schedule work for later call.

Yes, but it doesn't solve the problem, that I've illustrated. You'll not
know, WHEN this scheduled work will trigger (kernel tells us: ASAP)
and you need another kernel thingie again. And you must check,
whether the deadline is over yourself.

This isn't that nice design. I just don't feel that experienced,
that I can change the scheduler.

But maybe we can talk about that now, that we both know that we
know the current kernel API well enough ;-)

Regards

Ingo Oeser
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/