On Fri, 16 Apr 2004 00:19:42 +0000, tm wrote:
> Scott Eberl wrote:

[ Snip, lots of helpfull stuff (for the OP). ]

> On the second linux box you will need to edit the /etc/inittab file.
> Locate the section
> #Local Serial Lines
> #s1:12345:respawn:/sbin/agetty -L ttyS0 9600 vt100
>
> and remove the '#' from in front of s1.
>
>
>
> then do kill -s HUP Pidofinetd

What you probably ment to say here:

kill -s HUP `pidof init`

(Or similar), but maybe just:

telinit q

--
-Menno.

Menno Duursma <menno@desktop.lan> wrote:
> What you probably ment to say here:
>
> kill -s HUP `pidof init`

Yes, and as "pid of init" is always 1 (it IS the first real process),
just kill -HUP 1 will work too.
The original poster confused init (the unix startup process) with
inetd (the Internet Daemon), I've seem it happen before.

> (Or similar), but maybe just:
>
> telinit q

And that is the official command, indeed, to make init re-read its
config (/etc/inittab).
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************

"Menno Duursma" <menno@desktop.lan> wrote in message
newsan.2004.04.16.01.07.28.10864@desktop.lan...
> On Thu, 15 Apr 2004 16:19:57 -0500, Scott Eberl wrote:
>
> > In short closing, for instance, [ALT]+F4 from CLI would switch to that
> > terminal which would be the console on the third linux box through
> > a serial cable.
> >
> > Anybody help me out on this one?
>
> Have a look at "cu" (part of the "uucp" package) and "minicom", for the
> client site - as others have pointed out. For the server site:
>
http://www.google.nl/groups?selm=pan...0deskt op.lan
>
> And add "ttyS0" to /etc/securetty if you want root access.
>
> I wouldn't set the port at a very hi baud rate, as it might get less
> reliable then. Specially when using an UART with single byte Rx and Tx
> buffers (ie: 8250 or 16450). With 16550A you should be ok to crank it up a
> bit, you can check it out what you have with: "/sbin/setserial /dev/ttyS0"
>
> And better to use hardware flow-control. Linux can do that using RTS/CTS
> so if you're wireing your own cable, and want to use that, appart from pin
> 2 and 3 also cross pin 7 and 8 and enable it in software.
>
> When in that case you're using twisted pair cable, you might want to use
> pairs for Rx/Tx RTS/CTS (so if pin 2 is green, pin 3 would be
green/white).
> The RS232C standard doesn't define that, but it should make for a more
> reliable link, none the less.
>
> Have fun.
>
> --
> -Menno.
>
Actually having receive and transmit on the same pair will give you no noise
immunity whatsoever.
The signaling is ground referenced so it is always going to be susceptible
to EM noise, unless it is shielded.
Also, in this case, it would be best if the RX and TX were shielded from
each other, so you don't induce crosstalk.
T.

> > When in that case you're using twisted pair cable, you might want to use
> > pairs for Rx/Tx RTS/CTS (so if pin 2 is green, pin 3 would be
> green/white).
> > The RS232C standard doesn't define that, but it should make for a more
> > reliable link, none the less.
> >
> > Have fun.
> >
> > --
> > -Menno.
> >
> Actually having receive and transmit on the same pair will give you no
noise
> immunity whatsoever.
> The signaling is ground referenced so it is always going to be susceptible
> to EM noise, unless it is shielded.
> Also, in this case, it would be best if the RX and TX were shielded from
> each other, so you don't induce crosstalk.
> T.
>
>
Well, I guess... given that there is a lot of voltage imunity in the spec, I
don't know if there is a big problem with crosstalk.
T.

On Fri, 16 Apr 2004 12:48:49 -0400, Anthony Marchini wrote:

>> > When in that case you're using twisted pair cable, you might want to use
>> > pairs for Rx/Tx RTS/CTS (so if pin 2 is green, pin 3 would be
>> > green/white).
>> > The RS232C standard doesn't define that, but it should make for a more
>> > reliable link, none the less.

>> > -Menno.

>> Actually having receive and transmit on the same pair will give you no
>> noise immunity whatsoever.
>> The signaling is ground referenced so it is always going to be susceptible
>> to EM noise, unless it is shielded.

Ok.

>> Also, in this case, it would be best if the RX and TX were shielded from
>> each other, so you don't induce crosstalk.

So, best you could do with UTP cable, would be to pair data with common ...
That does make sense.

> Well, I guess... given that there is a lot of voltage imunity in the spec,

Yes.

SPACE (0), send: +5/+15V ,receive: +3/+15V (+27V wount fry line driver)
MARK (1), send: -5/-15V ,receive: -3/-15V (-27V wount fry line driver)

This against common (ground) which is 0V in the above table.

> I don't know if there is a big problem with crosstalk. T.

I don't think so. It runs over cat3 UTP more then 60 meters length no
problemo, at 19200 baud (and i'd bet it would do more, no sweat.)

--
-Menno.

"Menno Duursma" <menno@desktop.lan> wrote in message
newsan.2004.04.15.22.59.19.130838@desktop.lan...
> On Fri, 16 Apr 2004 01:05:11 +0000, jealous xmp wrote:
>
> >>On the second linux box you will need to edit the /etc/inittab file.
> >>Locate the section
> >>#Local Serial Lines
> >>#s1:12345:respawn:/sbin/agetty -L ttyS0 9600 vt100
> >>
> >>and remove the '#' from in front of s1.
> >
> > You can change the install iso contents like that, and have a headless
install,
> > no?
>
> No, the install uses BusyBox. Try instead, something like this:
>
http://lists.routerlinux.com/piperma...ry/000133.html
>
> --
> -Menno.
>
Thats a cool way of doing things. It wouldn't have occured to me to have the
boot directly
configure console over the serial port but it makes sense given the legacy
of the Linux that being large
computers that held sway over nothing but serial terminals.
Is that true that the install program uses the BusyBox to run the command
line? That is also very
cool. Interesting usage for a program developed for embedded applications.
If it were not for work and my family life, I think I could play with linux
forever.
TM.

> If it were not for work and my family life, I think I could play with
linux
> forever.
> TM.
>
Given the company of the newsgroup and the actual value of Linux to the
computing community along with the actual REAL work that it does, I should
not have used the term "play" , as if Linux were a toy...I appologise.
TM

On Fri, 16 Apr 2004 16:39:36 -0400, Anthony Marchini wrote:
> "Menno Duursma" <menno@desktop.lan> wrote in message
>> On Fri, 16 Apr 2004 01:05:11 +0000, jealous xmp wrote:
>>
>> >>On the second linux box you will need to edit the /etc/inittab file.
>> >>Locate the section
>> >>#Local Serial Lines
>> >>#s1:12345:respawn:/sbin/agetty -L ttyS0 9600 vt100
>> >>
>> >>and remove the '#' from in front of s1.
>> >
>> > You can change the install iso contents like that, and have a headless
>> > install, no?

To be more clear: you can run serial, but not exactly like that.

>> No, the install uses BusyBox. Try instead, something like this:
>>
> http://lists.routerlinux.com/piperma...ry/000133.html

Or create a boot (Lilo, Grub, Syslinux) floppy,
with serial-console support.
(In any case, modify the initrd.img).

> Thats a cool way of doing things.

Yes. And it's not very hard to do either.

> It wouldn't have occured to me to have the boot directly configure
> console over the serial port

That's not what i did though. I just created a boot-floppy with lilo
telling the kernel to use serial-console. And modified the initrd.img on
the install CD-ROM.

> but it makes sense given the legacy of the Linux that being large
> computers that held sway over nothing but serial terminals.

Yes. The problem is with PC firmware however. Ie: BIOSs generally have no
support for running their console over a serial-line in the x86 world.
Exeptions to this where/are rather hi-end (Pentium Pro/Xeon boards, etc).

I think this is the main reason LinuxBIOS exists:
http://www.linuxbios.org/

BTW, most newer "business" PCs can boot over Ethernet (via PXE)...
(Still no console access, but you might not need it, in that case).

> Is that true that the install program uses the BusyBox to run the command
> line?

Yes. You can have a look at it, like so:

mount /mnt/cdrom/
gzip -dc /mnt/cdrom/isolinux/initrd.img >/tmp/initrd.img
mount -o loop /tmp/initrd.img /mnt/
cd /mnt

> That is also very cool.

Indeed. I copy it over to the "/boot" partition most of the time (probably
i should always do that though). Hence 'when shit hits the fan' i can
tell the kernel to ramdisk that and mount it at "/". And manually proceed
to try and fix the problem at hand ...

> Interesting usage for a program developed for embedded applications.

You might also want to have a look at: "sash"
(StandAlone SHell) - and some patches for that:
http://www.baiti.net/sash/

> If it were not for work and my family life, I think I could play with
> linux forever. TM.

Same here. Funny thing is if you play with this stuff at home, they call
you a "hobbyist". Do the same at work, suddenly you are "professional" ...

If you have a free PCI slot, easier to just get a Weasel cart though:
http://www.real-weasel.com/intro.html

--
-Menno.