[lkml]   [1999]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: a modem problem introduced in 2.2.4
> > > 
> > > On Sun, 4 Apr 1999, Sergei Ivanov wrote:
> > >
> > > > Hello
> > > >
> > > > The changes to drivers/char/serial.c made between 2.2.3 and 2.2.4
> > > > introduced a problem with my modem and uucp. It remains there
> > > > under 2.2.5.
> > > >
> > > > In short, the problem is that uucp can dial out only once after boot.
> Yes some bugs were introduced. I discovered that it would no longer
> hang up and Alan fixed that, however the problems are more far-reaching.
> Basically, the driver now "remembers" stuff that it shouldn't and
> won't let you reset things.
> The work-around is to use setserial to reset everything between
> accesses. You have to change the parameters to something phony,
> then set them back to get them to "take" (stay after the port is
> closed).
> Cheers,
> Dick Johnson

I traced it a bit. It's a timing problem rather than a bad reinit.
At least setserial does not help, and a pause before the first
read/write in uucico makes the problem go away. And maybe it's
not a kernel fault at all.

Here is what happens. At hangup, uucico sends ATH and immediately
switches to B0 state - which now means dropping DTR. The modem
used to reply with OK to the ATH, but with low DTR it doesn't
send it (yet). Next time DTR is set is when uucico starts again,
due to open(). Then uucico flushes input and writes its AT.

But these flush and write are too early - before the first serial
interrupt comes. And this interrupt brings that old OK to the driver.
So flush did not really work and the OK appears to be read *after*
the AT is written. Then the second AT command is sent - while the
modem has not yet accepted the first one. The modem gets confused
and returns only a garbed echo of the two AT commands.

I don't know why the modem takes this so hard. Maybe it's buggy or
about to die its natural death. But this behavior is also specific
to the moment when DTR is just set.

What a "standard" RS-232 is supposed to do? Does it assume an interval
between switching DTR and doing send/receive? If so, it would be nice
to have this forced by the kernel. Otherwise what I have is a hardware
fault, to be worked around via delays in chat scripts.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.035 / U:9.028 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site