Date: Fri, 1 Sep 2000 22:43:13 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-stable@FreeBSD.ORG Subject: Re: bad 16550A maybe? Message-ID: <20000901224313.K252@speedy.gsinet> In-Reply-To: <004d01c01448$9dfabcf0$a44b8486@jking>; from jim@jimking.net on Fri, Sep 01, 2000 at 02:12:48PM -0500 References: <002d01c01444$350c8b00$a44b8486@jking> <200009010501.WAA54972@tao.thought.org> <200009011832.MAA37168@harmony.village.org> <200009011853.MAA37372@harmony.village.org> <004d01c01448$9dfabcf0$a44b8486@jking>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 01, 2000 at 14:12 -0500, Jim King wrote:
>
> [ ... it's about reducing FIFO trigger from 14 to 8 ... ]
>
> FreeBSD and 16-bit Windows are the only systems I've used that
> defaulted to setting the trigger to 14. (They also share the
> unfortunate characteristic that you have to re-compile
> something to change the default; Windows was more unfortunate
> in that you had to own the Windows DDK to do this.) All the
> DOS-based communications software I used when the 16550A first
> hit the scene used 8 (usually easily changed in a configuration
> file), and all the 32-bit versions of Windows default to 8
> (easily changed in a fancy GUI configuration dialog).
Looking at the sio(4), termios(4) and comcontrol(8) manpages I
fail to see how one could set the FIFO trigger "on the fly", too.
And I'm reluctant to believe it. :)
Although there are commands for changing bitrates, datalength,
stopbits, etc. I guess all these parameters are equally "cruel"
to currently running communication sessions. But I don't see how
it could be a bad idea(TM) to have an ioctl(2) to change FIFO
trigger depths to use it when no process accesses the sio driver.
This could be once after booting as well as reacting to "silo
overflow" messages (trying the default of 14 at first).
Should I dig inside sys/isa/sio.c to extend the sioioctl()
function for such an extension (and file a PR) or is it evil to
even think about this for longer than two seconds and not come up
with "hell, no!" as the result? This solution wouldn't collide
with cvsup(1)s and would leave the problematic machines up and
happily running without a need for a new kernel and a reboot (of
course there had to be a userland tool, too -- stty maybe?). And
the unaffected won't notice the change since the default is still
to have a deep queue.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000901224313.K252>