Re: atari/dev/zs.c interrupt issue

["T. Makinen" <tjamaloo%gmail.com@localhost>]

On Mon, Jan 26, 2009 at 11:12 AM, Izumi Tsutsui 
<tsutsui%ceres.dti.ne.jp@localhost> wrote:
> 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().

Ah, I see; thanks for explaining this :)

> 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..

Ok, anyway I tried atari/dev/zs.c with your patch and different
ZLRB_RING_SIZE and ZLRB_RING_MASK values to see if we can fix atari zs
driver and I found out that we only need to use 8KB buffer to make it
function without overruns and freezing (at 57600 bps). So it seems that
at least we can use current driver with patched zs.c and zsvar.h.

Index: zsvar.h
===================================================================
RCS file: /cvsroot/src/sys/arch/atari/dev/zsvar.h,v
retrieving revision 1.12
diff -u -r1.12 zsvar.h
--- zsvar.h     29 Apr 2008 06:53:01 -0000      1.12
+++ zsvar.h     27 Jan 2009 20:20:55 -0000
@@ -105,8 +105,8 @@
  * When the value is a character + RR1 status, the character is in the
  * upper 8 bits of the RR1 status.
  */
-#define ZLRB_RING_SIZE         4096            /* ZS line ring buffer size */
-#define        ZLRB_RING_MASK          4095            /* mask for same */
+#define ZLRB_RING_SIZE         8192            /* ZS line ring buffer size */
+#define        ZLRB_RING_MASK          8191            /* mask for same */

 /* 0 is reserved (means "no interrupt") */
 #define        ZRING_RINT              1               /* receive
data interrupt */


-Tuomo