On Wed, 7 May 1997, Michael Schmitz wrote:
> >I have written some SCC report just befor reading this topic...
> We've all read it - does your problem with the interrupts relate to 2.1.35, or
> to all 2.0/2.1 kernels in general ??
:)) When I was going to srart writing this I was still using 2.1.5 and all
that was in my mind was related to 2.0/2.1 kernels. But I had an idea to
try writing sth and because 2.1.5 sources exists only on my Falcon and I
have 2.1.35 sources ready on some pentium, I was intend to try making some
changes in 2.1.35 but before that I have wanted to see if 2.1.35 works at
all... Well it works but not very good...
> If 2.1.35: that seems to be extraordinarily broken as far as I could guess from
> the discussion here.
Yes generally you're right... I can say even more - AFAIK there was some
changes made from 2.1.34 in the interrupts structure which was supposed to
make things better but the results seems to be oposite...
> >I was quickly looking at usage of cli/sti's in whole kernel code and IMHO
> >things looks very bad. I think that INT blocking should be restricted to
> >cases when we are 100% sure that we're doing this for no more than few
> >(anyway some realistic walue) lines of assembly code, and of course no
> >loops... May be it is a time to redesign interrupts structure in whole
> >kernel code? I really don't belive that all those long time INT blocking
> As far as I recall, restore_flags should be used instead of sti if possible
> - but the problem is rather a general Linux problem, so you might want to
> address the linux-kernel list.
IMO the problem is not in restoring the INTs flags but in long duration of
blocking it at all. Surely the problem is general Linux related...
> The problem isn't new (quite some time ago, I stumbled across a unneeded cli()
> in the scsi.c that had been removed in one of the old m68k kernels but
> reintroduced by the i386 kernel. Might be fixed by either the i386 people
> fixing their low-level drivers to get along without so much cli(), or
> by #ifdef __mc68000__ (a fine thing to start a Linux flame war).
:)) Yes - I think it's a time to start Linux++ project - object oriented
kernel sources :) Then Cli()/Sti() would be protected methods of some
atomic, low level kernel object and it would not be so easy to use them
(but there will be some other, slower methods that yoy can use instead for
any larger parts of code) :) Anyway it would be interested wouldn't it?
To be more serious I think that there should be some higher level of
intterupts servicing for high level code. IMHO Cli/Sti are sigle
instruction (sometimes more in case of some other architectures) because
they are to be used in some time important parts of code - and nowhere
else.
> >rutines really needs to block out all the interrupts (but it would be hard
> >work to check every cli/sti sequence), in most cases it should be enoug to
>
> That's what would be required, though.
>
> >define more precisely what is forbidden while inside such piece of code
> >and use some semaphores to controll access to those limited areas... (and
>
> If you can come up with a general outline how to find out what interrupts can
> safely be masked out for each of the problematic cli/sti-pairs, fine. But
> remember: it has to work on every architecture, unless it's in the m68k
> hardware drivers (where these problems have long been solved AFAIK).
It should be a general interface so different architectures can
specify itself and install any immediate-service requiring interrupts -
there might be some software interrupt structure like:
1) true no interrupts - very rare cases (eg. software read-modify-writes,
some exact time depending code like our two stage acces to SCC
registers and so)
2) only interrupt buffering is allowed for devices with too small buffers
and some similar cases where it can leads to loosing important data
(such as our keyboard, SCC). By buffering I mean only save all the
important data in some software fifo (unless the main routine is
very short) so after the interrupts are enabled the main routines are
called to service requests pending in the FIFO.
3) rest of scheme might stay untouched unless some other ideas comes
> And semaphores are already used widely to handle concurrent access in SMP
> machines.
So that usage shoul be spread to whole the kernel sources.
> >now it is a time to do that before entering into 2.2 age). IMO it is the
> >only solution otherwise we have to create some new special version of
> >cli() and sti() and make some of the interrupts non-linux-maskable...
> >Yes - things don't look good :((
>
> cli() and sti() on the Atari already are special versions (at least STI() is
> available) and are used in the IDE driver, to mention one example.
Atari case is not enough however it is a good example for the others.
> What interrupts would you like to prevent from being masked? Can these
> interrupts have side-effects (serial interrupt leading to changes in device
> requests queues)??
As I wrote above those not masked interrupts (I was talking about SCC)
would have to be queued in some separate FIFO and after reenabling
interrupts the (slightly modified) main service routine will be called in
an old way.
regards,
Szymon Stasik.
------------------------------
A kto rodakom cmoka? Dorotka!
------------------------------