Serial ports to control peripherals w/3-wire interface? Okay on 5.x, isn't working on 6.x - BSD

This is a discussion on Serial ports to control peripherals w/3-wire interface? Okay on 5.x, isn't working on 6.x - BSD ; I have some disk storage systems that communicate via 3-wire serial interface (9600/8/N/1), literally coming off the storage unit via a 1/8" stereo audio plug, and a provided cable converts this into a IBM-PC style serial port DB-9 connector. In ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Serial ports to control peripherals w/3-wire interface? Okay on 5.x, isn't working on 6.x

  1. Serial ports to control peripherals w/3-wire interface? Okay on 5.x, isn't working on 6.x

    I have some disk storage systems that communicate via 3-wire
    serial interface (9600/8/N/1), literally coming off the storage
    unit via a 1/8" stereo audio plug, and a provided cable converts
    this into a IBM-PC style serial port DB-9 connector.

    In FreeBSD 5.x, you simply plugged this cable into COM 1
    and typed:
    cu -l /dev/cuaa0 -s 9600

    and you were in communication with the device. Works as expected
    and like it has for decades.

    However, I have found that in 6.x the same command with its
    apparent device name successor
    cu -l /dev/cuad0 -s 9600

    connects but will not display any of the received data. An
    external RS-232 activity monitor shows the external hardware
    is transmitting a stream of data once a second (a screen status
    update), but the FreeBSD 6.x system is not displaying anything.

    Shifting the same cable to a nearby system running 5.4
    immediately shows the continuous updates. Moving the cable
    back to a FreeBSD 6.1 or 6.2 system and they both display nothing
    in cu or ppp, but an external RS-232 monitor shows the data is
    there and should have been received.

    I am reasonably confident that this is not a hardware fault, as
    two of the machines tested were just uncrated, new from
    the manufacturer.

    I have diff'ed the /etc/remote on the 5.x and the 6.1 system and
    do not find insufficient differences to explain the failure I am
    encountering. In both OSes, /etc/ttys has the port turned off
    for dial-in activity (a getty war could do bad things to the
    storage unit).

    The 6.2 system was freshly installed today from ISO image, no
    kernel build, no kernel tweaks. It shows the same symptom.

    Now, stty -a < /dev/cuaa0 (or whatever) does show considerably
    different settings for the serial port between 5.x and 6.x,
    but adjusting these via stty command has failed to unjam an
    ongoing cu or ppp terminal session. I also see no apparent
    documentation noting this change in default behavior.

    I haven't found anything in Google or other searches that covers
    this specific problem, but I'm certain someone somewhere must use
    the serial ports without modem control signals for something other
    than dial-in/login sessions, and must know what has to be done
    to make this continue to work under 6.x.

    The COM hardware in question (all HP servers of different sizes and
    ages, oldest are DL380s, newest are monster DL585s), all reporting
    16650 class SIO interfaces.

    So, what's the secret for a simple direct serial connection?
    Thanks.


    Frank Durda IV - send mail to this address and remove the "LOSE":
    http://nemesis.lonestar.org
    A sign mounted high on a telephone pole in the country says: "Please do not
    shoot at the telephone wires. We appreciate your cooperation, Mr. Cheney."
    Copyright 2007, ask before reprinting.


  2. Re: Serial ports to control peripherals w/3-wire interface? Okay on5.x, isn't working on 6.x

    Frank Durda IV wrote:
    > I have some disk storage systems that communicate via 3-wire
    > serial interface (9600/8/N/1), literally coming off the storage
    > unit via a 1/8" stereo audio plug, and a provided cable converts
    > this into a IBM-PC style serial port DB-9 connector.
    >
    > In FreeBSD 5.x, you simply plugged this cable into COM 1
    > and typed:
    > cu -l /dev/cuaa0 -s 9600
    >
    > and you were in communication with the device. Works as expected
    > and like it has for decades.
    >
    > However, I have found that in 6.x the same command with its
    > apparent device name successor
    > cu -l /dev/cuad0 -s 9600
    >
    > connects but will not display any of the received data. An
    > external RS-232 activity monitor shows the external hardware
    > is transmitting a stream of data once a second (a screen status
    > update), but the FreeBSD 6.x system is not displaying anything.


    The tty subsystem was majorly overhauled between FreeBSD 5.x and 6.x. I think
    a side-effect of this is that callout devices will now only work when you are
    connecting to a device which asserts DCD (which it should actually do). If I
    am not mistaken, you can use ttyd0 to talk to devices which don't assert DCD,
    but I'm not sure about that.

    In any case, the "clean" solution is to pull DCD up. If you're using a level
    shifter, it's just a matter of soldering on an extra resistor.

    > Now, stty -a < /dev/cuaa0 (or whatever) does show considerably different
    > settings for the serial port between 5.x and 6.x, but adjusting these via
    > stty command has failed to unjam an ongoing cu or ppp terminal session. I
    > also see no apparent documentation noting this change in default behavior.


    Mmm -- maybe you can set a flag with stty to ignore the carrier status.

    > So, what's the secret for a simple direct serial connection?


    The secret to any serial connection are the lovely Max232 level shifting bits.
    Addictive. :-)

    - Philip

    --
    Philip Paeps Please don't email any replies
    philip@paeps.cx I follow the newsgroup.

    A crisis is when you can't say "let's forget the
    whole thing".

  3. Re: Serial ports to control peripherals w/3-wire interface? Okay on5.x, isn't working on 6.x

    In article Philip
    Paeps writes:
    >
    >The tty subsystem was majorly overhauled between FreeBSD 5.x and 6.x. I think
    >a side-effect of this is that callout devices will now only work when you are
    >connecting to a device which asserts DCD (which it should actually do). If I
    >am not mistaken, you can use ttyd0 to talk to devices which don't assert DCD,
    >but I'm not sure about that.


    That's entirely backwards - callout devices are "supposed" to be able to
    talk to a modem and tell it to dial, and by definition and spec a modem
    won't assert DCD until it has connected and established carrier. The
    ttyd* devices on the other hand are "callin", where getty is "supposed"
    to be hanging in the open() until an incoming call causes the modem to
    assert DCD, in turn causing getty to complete the open() and produce a
    login: prompt. (More importantly, this keeps getty out of the way of the
    callout programs.)

    If versions of FreeBSD actually behave like you say, they are completely
    broken, and I don't really think that is the case - nor that this has
    anything to do with DCD, I think (without looking at the source) that
    'cu' will time out and fail a connection attempt where it hangs due to
    lack of DCD - and certainly not report "Connected".

    There was a long discussion here in the past about serial comm with a
    printer failing, in a way that sounds very similar to the OP's, after a
    FreeBSD upgrade to 6.0 - unfortunately there didn't seem to be a
    resolution, but maybe some wisdom can be gained from the thread at:

    http://groups.google.com/group/comp....001eca1b5409ba

    --Per Hedeland
    per@hedeland.org

  4. Re: Serial ports to control peripherals w/3-wire interface? Okay on 5.x, isn't working on 6.x

    Per Hedeland wrote:
    >
    > There was a long discussion here in the past about serial comm with a
    > printer failing, in a way that sounds very similar to the OP's, after a
    > FreeBSD upgrade to 6.0 - unfortunately there didn't seem to be a
    > resolution, but maybe some wisdom can be gained from the thread at:
    >
    > http://groups.google.com/group/comp....001eca1b5409ba
    >


    Said printer is still running under 5.4, and alas, no new wisdom has
    emerged. I am somewhat shocked on re-reading the thread at how much
    effort went into it 8-)

    At the time, the 6.x release notes "to do" list included an entry on
    "unreliable serial console". That notation eventually dissapeared,
    replaced by a commemnt that serial comms were due for a major
    overhaul. My inference was that things would improve in 7.x, but
    I have not checked. It might be worth a look.

    bob prohaska



    bob prohaska


  5. Re: Serial ports to control peripherals w/3-wire interface? Okay on 5.x, isn't working on 6.x

    bob prohaska's usenet account wrote:
    : Said printer is still running under 5.4, and alas, no new wisdom has
    : emerged. I am somewhat shocked on re-reading the thread at how much
    : effort went into it 8-)
    :
    : At the time, the 6.x release notes "to do" list included an entry on
    : "unreliable serial console". That notation eventually dissapeared,
    : replaced by a commemnt that serial comms were due for a major
    : overhaul. My inference was that things would improve in 7.x, but
    : I have not checked. It might be worth a look.


    This may explain why the storage vendor unexpectedly shipped me
    multiple Lantronix ethernet to serial console modules (one per
    storage unit) which I saw no reason to use, but perhaps the vendor
    also knew that "simple 3-wire serial" no longer works on 6.x, an OS
    version which I had told the vendor I planned to run on the servers
    attached to the storage units.

    Hey, at $90K total for all the gear I just bought, the cost of these
    external gadgets was probably noise, but I would prefer to not have the
    additional failure point in my remotely administered systems and to
    not waste ethernet ports unless I am forced to. I bought machines
    with a real COM port. It would be nice if the OS let me use them.

    I also agree that by default, inbound and outbound serial character
    I/O MUST not be blocked due to lack of DCD or the absence of other
    hardware flow control signals - how could you ever dial a properly
    configured modem (&C1 command & default) where you don't have a carrier
    indication until you get the modem dialed and connected to the remote
    modem but you can't dial because you don't have carrier because...
    Something has broken traditional behavior here.

    See http://nemesis.lonestar.org/referenc...ersand-at.html

    for AT aka Hayes aka EIA/TIA-602 modem commands mentioned.


    Frank Durda IV - send mail to this address and remove the "LOSE":
    http://nemesis.lonestar.org
    "Your company has become synonymous with incompetence and crime. Stop
    trying to be all things to all people. Focus on either the incompetence
    or the crime."-Dogbert
    Copyright 2007, ask before reprinting.


  6. Re: Serial ports to control peripherals w/3-wire interface? Okay on 5.x, isn't working on 6.x

    Frank Durda IV wrote:
    >
    > Hey, at $90K total for all the gear I just bought, the cost of these
    > external gadgets was probably noise, but I would prefer to not have the
    > additional failure point in my remotely administered systems and to
    > not waste ethernet ports unless I am forced to. I bought machines
    > with a real COM port. It would be nice if the OS let me use them.
    >
    > I also agree that by default, inbound and outbound serial character
    > I/O MUST not be blocked due to lack of DCD or the absence of other
    > hardware flow control signals - how could you ever dial a properly
    > configured modem (&C1 command & default) where you don't have a carrier
    > indication until you get the modem dialed and connected to the remote
    > modem but you can't dial because you don't have carrier because...
    > Something has broken traditional behavior here.
    >

    I suspect you're right, but rs232 is an ancient interface little used
    (I suspect) by folks with an active interest in FreeBSD's development.
    The "unreliable serial console" report heartened me in that developers
    _do_ use serial consoles and so might be motivated to fix a problem
    related to it. I'm downloading a 7-current snapshot now to see how it
    behaves.

    My guess is that some new, well understood code broke some very old,
    poorly understood serial I/O code. The choice is now to either re-
    discover how the old code worked and fix it, start over and replace
    it, or abandon the serial interface. The last could be an option
    preferred by many, as I'll wager almost nobody among the kernel
    developers uses RS232 devices except perhaps serial consoles.

    bob prohaska


  7. Re: Serial ports to control peripherals w/3-wire interface? Okay on 5.x, isn't working on 6.x

    bob prohaska's usenet account wrote:
    > related to it. I'm downloading a 7-current snapshot now to see how it
    > behaves.
    >


    The January '07 7-CURRENT snapshot behaves exactly like 6.X:
    serial printer activity lights flash, the scanner never spins
    up and the print system reports "lp is not responding".

    If anybody has suggestions on things to try I'd be happy to
    give it a whirl.

    bob prohaska
    >


  8. Re: Serial ports to control peripherals w/3-wire interface? Okay on 5.x, isn't working on 6.x

    bob prohaska's usenet account wrote:
    >
    > The January '07 7-CURRENT snapshot behaves exactly like 6.X:
    > serial printer activity lights flash, the scanner never spins
    > up and the print system reports "lp is not responding".
    >
    > If anybody has suggestions on things to try I'd be happy to
    > give it a whirl.
    >

    Just tried the uart driver....same behavior. Maybe it's not the serial
    driver after all, but then what??

    bob prohaska


+ Reply to Thread