Dear all !!!
I was having data loss problems using my serial ports at 115200 with
software flow control (I can't use hw flow control) and I ended up
figuring out that the problem was happening because of the small value
of the tty buffer high water mark (TTY_THRESHOLD_THROTTLE). Changing
that define value and recompiling the kernel was the only solution i
found to my problem.
The way this code is implemented today is bad. The water marks are hard
coded and the only way to change them is recompiling the kernel again,
and this is not a good solution for that. I want to change that.
My idea is:
-------------------------------------------------------------------------
1 - Create two new variables in the tty struct: high_watermark and
low_watermark;
2 - Initialize this variables with the values they have today: 128 and 128;
3 - Create 4 ioctl's to set and get the values of this 2 variables;
4 - Change the file n_tty.c. The line that has
if (n_tty_receive_room(tty) < TTY_THRESHOLD_THROTTLE) {
will have:
if (n_tty_receive_room(tty) < tty->high_watermark) {
and the same thing will be done for the low watermark
-------------------------------------------------------------------------
I would appreciate any comment on this matter. If you guys don't see any
problem on this I will commit a patch as soon as possible
later
Henrique
Henrique Gobbi <[email protected]> writes:
> Dear all !!!
>
Disclaimer: I'm not an expert in Linux kernel internals. Everything I'll say
below could well be plain wrong as my opinion is based only on superficial
investigation of tty source code and 3-months-long monitoring of this mailing
list.
> I was having data loss problems using my serial ports at 115200 with software
> flow control (I can't use hw flow control) and I ended up figuring out that
> the problem was happening because of the small value of the tty buffer high
> water mark (TTY_THRESHOLD_THROTTLE). Changing that define value and
> recompiling the kernel was the only solution i found to my problem.
I've faced with a similar problem and my attempt to get any help from any guru
here failed (you can try to find my post called "Q: problems interfacing with
tty ldisc using flipbufs" posted 02 Dec 2002 that describes the problem). It
seems that your post won't have any response either :-(
>
> The way this code is implemented today is bad. The water marks are hard coded
> and the only way to change them is recompiling the kernel again, and this is
> not a good solution for that. I want to change that.
Not only hard-coded, but also are private for n_tty.c, so a tty driver has no
way to find out what are the values :-( It would be fine if there were a way
to send data to the n_tty line discipline without knowledge of the values, but
unfortunately it seems that it's impossible using current interface to line
disciplines.
> My idea is:
> -------------------------------------------------------------------------
> 1 - Create two new variables in the tty struct: high_watermark and
> low_watermark;
> 2 - Initialize this variables with the values they have today: 128 and 128;
> 3 - Create 4 ioctl's to set and get the values of this 2 variables;
> 4 - Change the file n_tty.c. The line that has
> if (n_tty_receive_room(tty) < TTY_THRESHOLD_THROTTLE) {
> will have:
> if (n_tty_receive_room(tty) < tty->high_watermark) {
> and the same thing will be done for the low watermark
> -------------------------------------------------------------------------
1. I don't think that adding n_tty--specific field(s) to the tty structure is
a good idea.
2. I think that the interface between tty drivers and line disciplines is
broken in the sense that it fails to provide reliable method of data
transfer between tty driver and line discipline. I believe that either the
interface should be re-designed (that may involve quite large amount of
work as it will affect line disciplines other than n_tty), or a work-around
local to n_tty.c should be implemented. As what you suggest is neither of
the above two solutions (as adding the fields to the tty structure won't
fix the interface), I don't think it's a correct way to fix the problem.
My own solution to this problem is to make TTY_THRESHOLD_THROTTLE to be at
least as large as TTY_FLIPBUF_SIZE. It will guarantee that driver's throttle
routine will be called without data loss. I have no idea though which
unfortunate side effects this change may have.
--
Sergei.