First of all, this is written via an ISA multifunction card accessed
through the GoldenGateII bridge.  I use kermit and a speed of 19200
baud.  38400 is still flakey and will perhaps continue to be as the
card I'm using for the moment is a FIFO-less one (i.e. not 16550A)
and I still only have a 33MHz '030.  Anyway 19200 works OK as far as
I have tested it.

>>>>> "Chris" == chopps  <chopps@emunix.emich.edu> writes:

>> I'm getting successful with the GoldenGate and the com driver.  Now
>> I can actually use it for logging in and dialout.  However at high
>> speeds there can occur some problems, one of them being malloc
>> messing up its internal state.  After some investigation I found
>> that malloc does splimp which is spl3 in the amiga port.  As I use
>> si_addcallback at spl6 this can (and will) result in bad behaviour.
>> This morning I saw the following call chain (from memory, excuse me
>> if I don't remember the exact names):

Chris> The point of si_callbacks as far as I saw was that you wanted
Chris> to delay processing of a certain interrupt code to lower
Chris> priority.  I guess I need to here why your callbacks need
Chris> splhigh() protection (if I understand what your requesting).

You misunderstand.  I do exactly what you do, I call add_sicallback
from an INT6 handler.  When add_sicallback calls malloc, malloc will do
a splimp() ** lowering ** the interrupt processing level of the cpu,
thus allowing a new INT6 to get through although the last one was not
yet ready (still inside malloc's splimp() critical region).  A new
add_sicallback will get issued which will call malloc once more and
the fact of two threads of control concurrently (virtually speaking)
being inside the same critical region is now true and disaster may
follow.  What I find peculiar is that our good old serial driver doesn't
trigger this.  Am I forgetting a fact?  It may of course be pure luck
as it is quite timing-dependent problem.

Chris> If its do to interrupts from the IO bridge, is it possible to
Chris> use interrupt level 2 instead?  This is the level that IO
Chris> should take place at not level 6.  Interrupt level 6 is
Chris> reserved for system clocks and other things (?) of such high
Chris> importance.

I cannot do this without patching the circuit board, which I don't
want to.  The reason INT6 is used is because there may really be
time-critical devices on the ISA bus.  The bridgecard designer can't
possibly know what the user intends to use it for.  But, yes, I'd
sure want a jumper choose betwwen INT2 and INT6.

Chris> Changing splimp() to splhigh() whould have many unwanted
Chris> side-effects I would think.  I don't like the idea at all.  For
Chris> example spltty() would be interrupted by a level 6 interrupt to
Chris> what would you do for that?

That's why I use sicallbacks.  I don't know what splimp is used
for except malloc.  I can sure think of raising splimp being a bad
idea.  The reason I brought the solution up was more for completeness
rather than a real suggestion.

Chris> I have run into a similar problem however with the ASDG LAN
Chris> Rover.  My board interrupts only at level 6.  To solve this I
Chris> will use an si_callback that processes most of the interrupt.
Chris> With the actual level 6 handler just clearing the interrupt and
Chris> saving it in a software register for processing by the call
Chris> back.  This is messy but its really the only way to handle such
Chris> problems.

I do the same, although in a very messy way indeed.  As I use com.c
from i386 almost unchanged I just changed the line discipline calls
from the interrupt handlers to be sicallbacks.  It works but looks
very bad.  I intend to rewrite it when I get to know the HW a little
better.

>> using a callback pool instead.  This would both be faster than
>> malloc and an easy fix as it will only have local influences.  The
>> drawback is that it has to be a static limit of callbacks, but as
>> the descriptors

Chris> Using malloc is nice in that it doesn't waste any memory and it
Chris> can accomadte many requests all made at `once'.  I think we
Chris> should keep it.

If it is possible, I like it as well, but I don't see how to if
malloc lowers our IPL to 3 in a hard manner.  Maybe just malloc
should be splhigh?  Now that's a machine-independent move which
may cause some discussion.  I'd rather try to fix it locally (i.e.
in the amiga-port) first, but if you want to pursue the question
with the core group, please do.

>> On a related topic, we need to redo the interrupt system a bit in
>> order to have drivers being LKMs.  We must have a interrupt
>> handling registration during attachment like the i386 port.  I'm
>> willing to write this if Chris says go.

Chris> I was going to write this and put it in after the release.  If
Chris> you can wait I would appreciate it.  If you need it now however
Chris> go ahead.

I don't *need* it now, but I've missed it a long time.  I guess I can
live without it for some weeks more.

I hope I made sense this time, and that I've understood the issues
involved correctly.

Niklas

------------------------------------------------------------------------------