Synchronous Device Driver for SunOS

[Chris Torek]

In article <1991Jun11.030213.21943 at ccu.umanitoba.ca>
mills at ccu.umanitoba.ca (Gary Mills) writes:
>Is c.u.w the right place to ask about device drivers? Is there a better place?

It is a good general place; there may be better specific places in some
cases (newsgroups oriented towards your particular hardware or O/S, e.g.).

>I have a bisync driver running on a Sun-4/280 ... under certain
>conditions, the remote host reports transmission errors.  These occur,
>for example, when the Sun is heavily loaded with disk i/o, when it's
>writing a lot of console log messages, or when I raise the bit rate
>from 9600 to 19.2 kb.  I believe the errors are caused by transmitter
>underrun in the Z8530 serial device.  This implies that the cpu is not
>able to respond quickly enough to the transmitter interrupt.

Probably true.

>Does anyone know of any tricks to avoid this problem?

On the Sun-4 series (including the 4c series) the onboard ZSCC chips
interrupt at ipl 12.  The only higher priority interrupts are:

  - ipl 15: memory (parity/ecc) errors, which should not normally occur;
  - ipl 14: profiling clock interrupts;
  - ipl 13: VME level 7 (Sun-4) or /dev/audio (AM79C30A chip, Sun-4c).

Both machines also have lower priority software interrupts.  The best
way to use this, since the Zilog chip has neither DMA nor a decent
FIFO, is to split the interrupt handler into two pieces: a hardware
interrupt handler (which merely moves bytes to/from the chip) and a
software interrupt handler (which does the `hard work' of interpreting
packets, but at a lower priority, hence does not prevent further
transmission or reception).

It sounds as though you have already done this:

>... The bottom half of the driver merely moves a byte from a buffer to
>the device at each transmitter interrupt, so that part can't be too slow.

so I suspect that:

  - you are not using the on-board chip, but rather a VME device
    at too low a priority; or
  - you have another VME device at VME-7 (move it to VME-6 or lower); or
  - you have not quite done the above.

Note that, on the Sun-4c (and perhaps the Sun-4 as well), the ROM
console putchar routine is not reentrant, and anything that calls the
this routine (i.e., console output, unless done via some other method)
must protect calls to it with splhigh().  (I found this out the hard
way: my kernel kept crashing until I deduced this and put in the
splhigh().)  This *will* block ipl-12 interrupts.  Furthermore, the ROM
code on the 4c series is abysmally slow---it takes *seconds* to print
just a few lines.  I intend to stop using the ROM putchar routine as
soon as I write a frame buffer driver.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov