Phil Budne <budd@cs.bu.edu> wrote:
[ with various pieces cut at random ]
> I implemented CD following, glad THAT'S working for you!

Like a champ! (At least the ONE time I tried it 8-)  It makes
backing down to 1.2 a bit more unpleasent because I can't say:  I
backed down because current is just like what I had, but with more
bugs 8-)

> The original driver didn't try to do flow control, and didn't report
> failures.  Some detail;

I suspected as much wrt interrupts, but I never had reason to
believe it was dropping lots of characters.  However, just thinking
about it right now... That may explain why I have real throughput
problems using the pc532 as a firewall.  Mac->pc532, pc532->mac,
and Internet->pc532 transfers all seem to work fine, but trying
internet->pc532->mac bites big.  I traced it down to the Internet
sending lots of data, and the pc532 sitting on it until the Internet
started to resend, THEN the pc532 sent an ACK for the first packet
in the window, and made the process repeat.  Losing characters by
overflowing ring buffers could do that quite easily.

On the other hand, thinking about it a bit more while typing...
That wouldn't explain why Internet->pc532 transactions work while
Internet->pc532->mac transfers don't.  Hmmm...  Maybe the light
will turn on some day, and I'll figure it out.

> I use the special RXRDY interrupt line that George and Dave
> architected so that RXRDY interrupts are NEVER masked (and herein
> lies a problem).

Doesn't that cause problems with corrupting the shared variables used
to communicate between the interrupt routine and the rest of the system?
Or can you make all operations on those variables atomic somehow?

> Ian Dall just sent me mail noting that once the ring buffer (or higher
> level structures in the line discipline) fill that information isn't
> passed down to the interrupt service routine to STOP removing
> characters from the FIFO, and force the chip's hardware flow control
> to turn off CTS.  Ian said he wouldn't have the time to do anything
> immediately, and neither do I, so backing down to a 1.2-release kernel
> should fix you up for now!

This doesn't sound TOO hard, and if it's not what Mathias just
checked in to the tree, (see below) I may try to work on it myself
in a little while, however, I suspect that someone else will free up
some time, look at the problem, ndd fix it before I figure it out what's
going on.

And "Matthias Pfaller" <leo@dachau.marco.de> wrote:

> Ian Dall has problems connecting his sun3 to his pc532 with the new
> driver. I just tested it between two pc532s running ppp with 57600
> baud (and hardware handshake). I never get fifo overruns. When doing
> tests with ftp, I get about 5400 bytes/second. The console port of my
> second pc532 is connected to tty01 on my main machine. When I connect
> to the second pc532's console (without handshake) I get fifo overruns
> from time to time (not often).

My setup should test out flow control much better, since all I have to do
is send a compressed file out the PPP line at 38400, and wait for the
modem to say "Hold it, I can only get this on the phone line at 14.4Kbps!"

> BTW, I just checked in a new method to handle software interrupts. It
> works fine on my machine, but I'd be glad if there where some testers
> out there. The new method is based on a idea from Phil Budne. I'm using
> a spare interrupt in the ICU to trigger a call to check_sir. The interrupt
> I'm using is the same as Phil is using in the scn driver when the HSOFT
> option is present. If you have HSOFT in your config file, this will no
> longer work.

I just SUPped to see if I could get it, as I saw the notice on
source-changes.  Guess I'll have to wait for teh SUP scan tonight
though, as I didn't get them.  What is HSOFT anyway?  Never heard
of it and don't use it.  Guess that's good from a serial driver
and upgrading standpoint 8-)

Jon Buller