Subject: zs bitch.
To: 'port-sparc@netbsd.org' <port-sparc@NetBSD.ORG>
From: Graham, James <James.Graham@Schwab.COM>
List: port-sparc
Date: 04/30/1997 11:52:58
Back to the zs thing on the SPARCstation.

#define REFRESH "SS IPX, 64M, NetBSD 1.2.1D-current"

I think I have a legit complaint here, at the risk
of opening myself to flamage.

It would appear, from all indications, that the older
zs driver was actually more efficient at picking up
the characters from the zs port.  I can't attribute it
to anything else, because 38400 has worked FLAWLESSLY
for me until I upgraded.

Now, I laud the machine-independence and all that so that
specialised drivers don't have to be built everywhere.
_Most_ of the time, anyway.  In this case I would have
to make an exception.  If this is a result of moving from
MD to MI code, I think it a misstep, because to downgrade
functionality is, I think, to BREAK an implementation.

And this sucks, frankly, because I like everything else
that's happening.

I'm limping along thru my ISP, but I still can't get a
complete sup -avsz because of the goddamn zs0a
overruns.  Dropping the 'z' doesn't help, and I need to
do the -a option because I'm trying to track -current.

It would be REALLY cool if there was a way to
multiplex ttya and ttyb.  Course, then I won't be
able to hook up my printer...

Is there any solution to this in sight?
I think the latency within the software byte reader
is proving to be a difficulty, and the more layers or
code you add to the driver, the more the overruns
will happen because the kernel won't be able to
haul the stuff off the zs easily.

Is there anything I could do to the SPARCstation
short of buying a multiport serial card?

If that's the only solution, does NetBSD support
a multiport serial card, and how much does one
of those things run, anyway?  Four ports would
be fine...


Reply-To: greywolf@starwolf.com

This message made possible by
Microsoft
"I'VE GOT A BAD FEELING ABOUT THIS"