Subject: Re: malloc above splimp

From: [email-masked] (Niklas Hallqvist)

>>>>> "Hamish" == h  <hamish> writes:

>>>>> On Wed Aug 31 13:22:00 1994,
>>>>> You wrote:

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

Hamish> I believe that the problem that Niklas is seeing is:

[explanation deleted]

Thanks, you got the point exactly!

Niklas

---

From: [email-masked] (Niklas Hallqvist)

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  <[email-masked]> 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

---

From: [email-masked] (Niklas Hallqvist)

>>>>> "Michael" == Michael L Hitch <[email-masked]> writes:

Michael> On Aug 31, 8:23pm, Niklas Hallqvist wrote:
>> 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

Michael>   I think you misunderstand the Amiga serial driver.  The
Michael> only thing done at interrupt level 5 is the character is read
Michael> from the serial input buffer and stored into a local fifo
Michael> buffer.  The fifo buffer is processed later by a routine
Michael> called from the vertical blank interrupt.

Doh!  Brain-damage... I *knew* this, I don't know why I mixed it up
with the sicallbacks.  Anyway, Maybe I should do it like this for my
COM driver as well...  Well, it would use up 1/2 a K for every port
then, maybe not too good.

Niklas

---

From: [email-masked] (Ethan Dicks) (Ethan Dicks)

> sure want a jumper choose betwwen INT2 and INT6.

While I did not design the GG2, I do currently manufacture it.  AFAIK, the
reason that David Salamon designed the card to use INT6 is that under
AmigaDOS, it's the Right Thing.  I can certainly understand how people might
want an INT2-interrupting board, but consider that the GG2 might be asked to
handle interrupts from an IDE hard disk, an Ethernet card and a couple of
high-speed serial ports.  This is all do-able inside an A4000 with two ISA
cards.

It is of no technical consequence to modify the board.  I just checked the
schematics; the INT6 line is driven by an Open Collector NAND gate.  To
modify a card in the field would probably take aboiut 10 minutes to cut
the line from the Z2 INT6 pin and run a wire to the Z2 INT2 pin.  In the
future, it may be possible to produce a GG2 card that has an INT2/INT6 jumper,
but remember that there are a few hundred GG1 and GG2 cards already out there
and that they won't have a jumper.  It is also possible to retro-fit a jumper
to an existing board, but I wouldn't consider charging less than an hour's
bench-time to drill new holes in the board, epoxy a jumper plug to the board,
run wires and test the board.

Combining the current demand for the product with the number of boards that
we have on hand, I do not anticipate needing to schedule another run of
boards for several months, perhaps not until next year.  If anyone is 
interested in a GG2 Bus+ board with an INT2/INT6 jumper, contact me at
<[email-masked]> and we can probably work something out.

Thanks,
-ethan