Subject: Re: com(4) and speeds >115200
To: Daniel Carosone <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 09/30/2004 23:15:33
On Fri, 1 Oct 2004, Daniel Carosone wrote:
> On Fri, Oct 01, 2004 at 10:17:37AM +1000, Daniel Carosone wrote:
>> On Thu, Sep 30, 2004 at 02:32:35PM -0500, Frederick Bruckman wrote:
>>> Try building a current kernel with options COM_16650 (COM16650 on 2.0).
>> Well, this is interesting. I saw that option in the sources, but my
>> eyes misled me to read it as 16550 and I just assumed it was on.
>> However, cu still doesn't accept -s >115200, nor does stty.
>> EINVAL from tcsetattr.
> And on further reading, I can't really see how it makes a difference
> for speed; the #ifdef'd code is only at probe time, and results in a
> sc->sc_fifolen = 32, but nothing that I can see affects the speed or
> the frequency (like is done for the HAYESP).
> Likewise, comspeed() takes a type argument that goes unused, even if
> sc_type were set differently for 16650, which it isn't.
> Is the 16650 support incomplete?
Oh, yes. I have fashioned some patches against netbsd-1-6 to set the
multiplier, vary the trigger level dynamically, and a couple of other
things. The multiplier is actually a small part of it, and I'd
forgotten about that.
Here's the patch I've been running on my ISDN-TA-connected mail server
for five months now:
Unfortunately, intervening changes make a pull-down to current
non-trivial. I'm also not happy with the design. As it is, you must
recompile to turn features such as the dynamic trigger level and
AUTO_RTS off and on. I think it would be better to let a utility
handle that at run-time, through sysctls. Also, the "burst" thing
doesn't work at all.