[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.044 / U:5.380 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site