mills@ccu.umanitoba.ca (Gary Mills) (06/11/91)
Is c.u.w the right place to ask about device drivers? Is there a better place? I have a bisync driver running on a Sun-4/280 that works correctly most of the time, but 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. Does anyone know of any tricks to avoid this problem? I would like to be able to run it at 19.2 kb. 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. Am I up against a limit here? The receiver seems to handle the speed with no problem, but it has a 3-byte FIFO. -- -Gary Mills- -Networking Group- -U of M Computer Services-
torek@elf.ee.lbl.gov (Chris Torek) (06/11/91)
In article <1991Jun11.030213.21943@ccu.umanitoba.ca> mills@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@ee.lbl.gov
gerry@gallahad.Central.Sun.COM (/usr/local/name) (06/12/91)
Hi Gary, I hope this is what you need, This was written by a hardware engineer after my request about a similer problem.. ------------- Refer to any of the Hardware Configuration Guides under the section heading "Serial Port Configuration and Speed". "The serial ports are programmed I/O devices (rather than DMA devices) and have only a three-character hardware buffer each although they support both high-speed output (up to 19.2 kbaud) and input (up to 9.6 kbaud)." This statement holds true for Sun-2, Sun-3, and Sun-4 and goes back as far as the Aug 1984 Config Guide and as current as the Nov 1989 Config Guide. ----------- Gerry
greg@cheers.Bungi.COM (Greg Onufer) (06/12/91)
gerry@gallahad.Central.Sun.COM (/usr/local/name) writes: >This was written by a hardware engineer after my request >about a similer problem.. >------------- >Refer to any of the Hardware Configuration Guides > under the section heading "Serial Port Configuration and Speed". > "The serial ports are programmed I/O devices (rather than DMA devices) > and have only a three-character hardware buffer each although they > support both high-speed output (up to 19.2 kbaud) and input (up to > 9.6 kbaud)." > This statement holds true for Sun-2, Sun-3, and Sun-4 and goes back > as far as the Aug 1984 Config Guide and as current as the Nov 1989 > Config Guide. And the glossies on the SparcStations say that you can perform 38.4kbaud on one port or 19.2kbaud on both ports. One would hope that the older Sun-4's and even the Sun-3's could do it as well. Cheers!greg