On Mon, 17 Mar 2003, Ed Vance wrote:
[SNIPPED...]
> >
> Hi Richard,
>
> What you are doing looks just fine.
>
> As long as HUPCL is set when the close happens, DTR will drop. There are
> delays that are enforced in both open and close when a second process is
> blocked opening a closing port. Of course, that would not be your case,
> because the open does not occur until the closing process terminates. In a
> quick look, I didn't see an enforced close-to-open delay for your case.
> Maybe I missed something. I am looking at 2.4.18 Red Hat -3. I didn't notice
> a patch to serial.c in the 2.4.19 or 2.4.20 changelog that would affect
> this. There are some weird calculations that appear to scale the close_delay
> field value based on HZ.
>
> Which was the last "working" kernel rev that you used?
>
> Did you switch to a faster CPU?
>
> Are you using any "low latency" patches?
>
> Did the HZ value change between the last rev that worked and 2.4.20?
>
> What HZ value are you running with?
>
> Cheers,
> Ed
I'm now using 2.4.20. The previous version was 2.2.18 (yikes)!
I just transferred my old hard disks (SCSI) to a new system and
everything worked fine, so I decided to upgrade to a later more
stable kernel. I use this system to be my own internet provider
and I am, in fact, logged in running a ppp link from home over
the modem at this time. I had to modify `agetty` to make it
work with the new kernel and a faster CPU (1.2 GHz, 330 MHz
front-side bus, Tyan Thunder-II).
The agetty code is attached. It hangs up before it sleeps for
a new connection because when the previous process terminates,
init instantly starts a new instance, the modem never hangs up
even though, possibly the DTR was lowered for that instant.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
This archive was generated by hypermail 2b29 : Sun Mar 23 2003 - 22:00:21 EST