Re: OldWorld floppy and serial port work

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

>On Thu, Jul 08, 2010 at 05:41:25PM +0200, Martin Husemann wrote:
>> Hmm, seems to work for me - what variant of nervous break down do you see?
>
>Duh, did not closely pay attention to this being on port-macppc; I actually
>tested on mac68k and it works there - my macppc serial port hardware seems
>broken (a stealth G4 card, the rx line seems to be dead), so I couldn't test
>there - sorry.
>
>Martin

I have been running a Cyclades serial port card to do dial-in PPP on a NetBSD
MacPPC box for some time.  I initially could not get the serial ports to
work reliably, but ended up doing some debugging and modified the Cyclades
driver to get it to work.

What did I do?

I modified the driver, so that the polling loop "manually" called the
interrupt handler when the driver got "stuck".  This only happened under
"heavy load", almost never when the serial port was lightly used (like for
login, console traffic, etc)

Once I added the code to detect its being "stuck" and calling the int
handler, the problem was 100% fixed.  I even put syslog entries in to track
how often this happened, and it was "frequent".  I have been running this way
for years.  (NetBSD 2.1 !)

My conclusion was that the driver was "losing" an interrupt on rare occasion.

Note that I did quite a bit of debugging in this driver to satisfy myself that
it was not the driver losing the interrupt.  There were no race conditions or
other driver bugs that I could find that would explain these "lost"
interrupts.  My conclusions are supported by the fact that the problem is
similar on the "built-in" serial drivers and the drivers are (mostly)
architecture independent.

Given my experience, and subsequent improvements I have seen in more recent
NetBSD releases coupled with comments on this list about improvements
to the low level interrupt handling machinery, I strongly suspect that
the problem with the serial drivers, and USB, (and also ATA, for that matter)
are likely caused by "lost" interrupts.

I have tried the serial ports on NetBSD 4.x and 5.0 (not 5.1, yet) and
they still show this problem, though it seems much less frequent.  The
bug - where the incoming serial data gets "stuck" and the serial port
freezes - still happens when you throw enough data at it.

Running PPP on the serial ports is a great test.  Crank up the speed, run
some TCP streaming tests and watch it fail.

I don't know much about the HW on these machines, so my opinions
are suspect, but my experience hints at a problem in the low level
interrupt handlers.

-dgl-