Date: Thu, 14 Oct 2004 11:46:18 +0100 From: Peter Edwards <peadar.edwards@gmail.com> To: Randy Bush <randy@psg.com> Cc: freebsd-current@freebsd.org Subject: Re: NOTICE: /dev/cuaa%d -> /dev/cuad%d renaming Message-ID: <34cb7c84041014034649c63c3b@mail.gmail.com> In-Reply-To: <16750.7355.130098.892269@ran.psg.com> References: <16749.52145.110218.317549@ran.psg.com> <200410140048.i9E0mjjM015658@realtime.exit.com> <16749.58484.912537.379555@ran.psg.com> <200410141537.11242.doconnor@gsoft.com.au> <16750.7355.130098.892269@ran.psg.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Oct 2004 23:29:15 -0700, Randy Bush <randy@psg.com> wrote: > > Tie DCD to DTR. (I think) > > i was not clear. this affects production racks in strange > bunker-like facilities. > All this talk of soldering irons and 12v batteries is making me queasy. Can I suggest something? The problem is that your serial setup doesn't provide DCD, but you're using a device that requires it to be available before completing the open(2). Think of DCD as indicating that a "connection is established" with the other side. The ttyd device is _supposed_ to block until a remote connection is established. If you can't provide a DCD signal, then just use "cuad" instead of "ttyd": The intention is that's for making outgoing calls you use cuad, so a getty waiting to open ttyd won't stop the open on cuad. In your case, it's probably ok for the getty to just hog the modem itself, so using /dev/cuad0 sounds like the right thing to do. I've no idea why it was working with ttyd before: it sounds like its working correctly now: maybe phk has fixed a bug in whatever was driving your serial hardware. Cheers, Peadar.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34cb7c84041014034649c63c3b>