Re: atari/dev/zs.c interrupt issue

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

tjamaloo%gmail.com@localhost wrote:

> >>> I tried to transfer some files to my Falcon running NetBSD 5 kernel
> >>> with ppp. I'm using zs0b (ttyA1) device which is standard Falcon
> >>> serial port.
> >>>
> >>> However I started to see "zs0b: ring overrun" messages early during
> >>> transfer and occasional freezing.
> >>
> >> Hmm, what baud rate?  I'm afraid zs can't handle >38400 bps.
> 
> I tried with 38400 and 57600 and both speeds produced overruns, but
> they work without BASEPRI().

In this case, we have to consider how interrupts priority levels
should be handled in each interrupt handler.

First, there is one obvious problem in your patch.
Calling spl1() in !BASEPRI() case implicitly lowers
interrupt level and enables all interrupts higher than
IPL_SOFT (i.e. IPL_VM and IPL_CLOCK), so it might cause
invalid recursive interrupts as seen on wdc_mb.
At least we should use splsoft()/splx() pair around calling zssoft().

Second, we have to also consider interrupt latency.
The reason why we have two handlers of zshard() and zssoft()
is to avoid long delays in a high priority interrupt handler.
In current design, zshard() only handles minimum processes in
hardware layer on each interrupt, and zssoft() handles other
tty(4) level processes which can be defered.
(that's the reason why software interrupt was implemented
 even in ancient 4.3BSD)

Calling zssoft() from zshard() means that all necessary
processes on the zs interrupts are handled with less latency
(so that it could avoid overflows) but all other interrupts
which have the same or lower priority could be blocked
until all tty(4) processes are done in zshard() and zssoft().

If the overflows occur only on higher baud rate, what happens
if you increase ZLRB_RING_SIZE from 4KB to 64KB (or more)?

Of course we also have to fix freezes on overflows,
but it might be better to consider to use MI z8530 drivers
as other ports..
---
Izumi Tsutsui