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

[Ingo Oeser]

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