Why "NOTICE: asy0: local queue full" on Sol x86?

Why "NOTICE: asy0: local queue full" on Sol x86?

Post by Yatish Mish » Thu, 18 May 1995 04:00:00



I am running a program which is receiving lots of data at 38400 baud on port
/dev/cua/a.  In the console window, I get "NOTICE: asy0: local queue full"
which is often followed by my program window locking up.  My program is a
communications program and is receiving a ZMODEM file transfer.  Everything
works fine if I send files (I use RTS/CTS flow) but not when I receive files.

I was just running tip and I did a cat of a file on the remote system and
I am getting "NOTICE: asy0: silo overflow" in the console.  What's the
deal with receiving data on a serial port under Solaris x86 2.4?  I am running
on a 486DX4-100 with high speed 16550 uarts.

Is there anything I should be looking out for in my serial IO code?

Any help is greatly appreciated.  Thanks.
--
               _______________________________________________
                 Yatish Mishra, Microlink Technologies, Inc.


               _______________________________________________

 
 
 

Why "NOTICE: asy0: local queue full" on Sol x86?

Post by Dan Mi » Tue, 27 Jun 1995 04:00:00




>I am running a program which is receiving lots of data at 38400 baud on port
>/dev/cua/a.  In the console window, I get "NOTICE: asy0: local queue full"
>which is often followed by my program window locking up.  My program is a
>communications program and is receiving a ZMODEM file transfer.  Everything
>works fine if I send files (I use RTS/CTS flow) but not when I receive files.

>I was just running tip and I did a cat of a file on the remote system and
>I am getting "NOTICE: asy0: silo overflow" in the console.  What's the
>deal with receiving data on a serial port under Solaris x86 2.4?  I am running
>on a 486DX4-100 with high speed 16550 uarts.

>Is there anything I should be looking out for in my serial IO code?

>Any help is greatly appreciated.  Thanks.
>--
>               _______________________________________________
>                 Yatish Mishra, Microlink Technologies, Inc.


>               _______________________________________________

The "standard" for inbound flow control (the computer says "wait" when
its buffers are full) is a relatively new invention for RS232.  The
most-common method seems to be to overload the meaning of RTS/CTS again
and have the DTE (computer) drop RTS when it's full, to tell the modem
not to send any more.  The Solaris serial drivers are being updated to
conform to this emerging standard.  Until that time, inbound
flow-control is software-only.  We realize this is a problem and are
working to fix it.  Watch for a driver update soon.

 
 
 

Why "NOTICE: asy0: local queue full" on Sol x86?

Post by Andrew Fullfo » Sun, 02 Jul 1995 04:00:00



Quote:>The "standard" for inbound flow control (the computer says "wait" when
>its buffers are full) is a relatively new invention for RS232.  The
>most-common method seems to be to overload the meaning of RTS/CTS again
>and have the DTE (computer) drop RTS when it's full, to tell the modem
>not to send any more.  The Solaris serial drivers are being updated to
>conform to this emerging standard.  Until that time, inbound
>flow-control is software-only.  We realize this is a problem and are
>working to fix it.  Watch for a driver update soon.

RTS/CTS flow control for full duplex transfers was standardized
in RS232-E, a couple of years ago.  You said "overload ... again".
Is that redundant tautology or is there really a third
use for the signal lines?  I was astounded to find that rts/cts
was not supported on solaris x86.  It is the only PC operating
system I know of that doesn't support it and you can't use the
argument we've been getting for years in the SPARC world that the
Zilog hardware doesn't support it.  Anyway, glad to hear you guys
are getting finally around to it.
--
Andrew Fullford                                 a.out computer consultants

 
 
 

Why "NOTICE: asy0: local queue full" on Sol x86?

Post by Dan Mi » Thu, 10 Aug 1995 04:00:00





>>The "standard" for inbound flow control (the computer says "wait" when
>>its buffers are full) is a relatively new invention for RS232.  The
>>most-common method seems to be to overload the meaning of RTS/CTS again
>>and have the DTE (computer) drop RTS when it's full, to tell the modem
>>not to send any more.  The Solaris serial drivers are being updated to
>>conform to this emerging standard.  Until that time, inbound
>>flow-control is software-only.  We realize this is a problem and are
>>working to fix it.  Watch for a driver update soon.

>RTS/CTS flow control for full duplex transfers was standardized
>in RS232-E, a couple of years ago.  

...and RS232 has been around a lot longer than a couple of years,
and so has Unix, and there's an awful lot of backward-compatibility
stuff in the serial drivers.  I didn't mean that no one at Sun was
aware of it, just that a lot of changes have gone on in various
standards for serial port hardware use as well as serial port
software convention, and SunSoft is trying to ride them all.
We're finally getting to hardware-flow-control with RTS/CTS,
and it's probably overdue, but this is why; go try to make sense
of SVID, XPG4, and "existing practice" in all the Unix clones.
It's no fun.

Quote:>You said "overload ... again".
>Is that redundant tautology or is there really a third
>use for the signal lines?  

The three I meant were

1) the original: RTS means "the DTE is ready" and CTS means "The DCE
is ready"; RTS is established at the beginning of a session and not
dropped, and CTS is used mostly for half-duplex turnaround time

2) the "but I need some flow control from DCE to DTE" mode, where the
terminal/computer is faster than the modem, so the modem needs to
say "hang on" by dropping CTS during the course of a session

3) the "but we need flow-control *both* directions", where RTS
and CTS are used for the corresponding flow-control

I didn't mention

4) Other signals are pressed into use as hardware flow-control,
like DSR/DTR

>I was astounded to find that rts/cts
>was not supported on solaris x86.  It is the only PC operating
>system I know of that doesn't support it and you can't use the
>argument we've been getting for years in the SPARC world that the
>Zilog hardware doesn't support it.  Anyway, glad to hear you guys
>are getting finally around to it.
>--
>Andrew Fullford                                 a.out computer consultants