Re: MacPPC serial ports in 4.0.1 - not quite

[Donald Lee <MacPPC2%caution.icompute.com@localhost>]

At 4:51 PM -0500 12/30/08, Michael wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hello,
>
>On Dec 30, 2008, at 4:48 PM, Donald Lee wrote:
>
>> Oddly enough, what I did in the Cyclades driver was to add a call to
>> the interrupt handler every time it made a trip through the
>> "top half" polling loop.
>>
>> It didn't fix the interrupts, but it got the job done.
>
>Well, it kept calling the interrupt handler so even if the signalling 
>mechanism was borked the interrupts were dealt with eventually.
>
>> On the 4.0.1 machine,
>> I can set up an account on the machine for debugging,
>> or run some tests, w/ extra debug code on the machine in
>> question if that is helpful.  I would need a patch or at least
>> some pointers on what debug code would be required.  It's a
>> production machine, but I can "mess with it" at will because all
>> it does is monitor the other machines, so its operation is
>> not critical.
>
>First you should try to reproduce the problem and maybe narrow it down a bit.
>I have a beige G3 here but I'd have to get a serial cable somehow, my 
>mini-DIN->DB9 adaptor seems to have wandered off.
>

I figured out what locks up the serial ports on the G3 Beige.

After quite a bit of head-banging, I got "failures" on both the input
and output side.  On the output (serial xmit from host), the write()
ops to the tty fail, until the tty is closed and re-opened.  On the
input side, no incoming data appears on the host until re-booted.

The way to reproduce this appears to be to simply overrun the serial
port.

On the input side, I used a 68K machine, and just did:

        od -xc /netbsd > /dev/tty00

with a serial cable (and null modem) between the machines.
It is important to have  program reading data from the serial on the
input side, but during the transfer, I just killed the program
harvesting the data from serial.  After that, although the data continued
to be sent from the 68K (according to the LEDs on a little serial diag tool
on my cable), no more data appeared on the G3.  A reboot is required to
get serial working again.

On the output side, I did something very similar,  but used a little
utility program to force data to the serial output.  When I send "too much"
data, the write() ops start failing.  Nothing I do short of killing the
program seems to fix it.  (68K harvest of the incoming data seems
irrelevant)

My theory is that this is the same (or similar) problem on both sides.
If you overrun the serial port (buffer maybe?) it gets confused and
stuck.

I must admit that I don't know how this is *supposed* to work.
Serial ports have several flavors of flow control, and I'm not
sure what the rules are for data overrunning the HW.  It's safe
to say, though, that re-opening the device and changing its params
really should "clean up" this sort of thing and restore the serial to
operation regardless of previous overruns.  Also, I would think that
a serial port that was *not* open (and no user harvesting data)
should probably silently discard incoming data.

I would have normally done this with ppp, because ppp does such a nice
job of loading down the serial.  unfortunately, the default kernel does
not appear to have ppp configured, and I didn't want to build my own kernel,
so I stuck with my crude tools.

Let me know if you need any serial cables.  I have spares. ;->
I also highly recommend the little LED serial inline thing.
It lets me "see" the data being xferred, and is absolutely wonderful.

http://www.electronix.com/catalog/product_info.php/cPath/17_489/products_id/6870

The picture on this one looks like mine.  At $12, it's easy to justify if
you every mess with serial.

Joy,

-dgl-