Serial Console

Serial Console

[Steve Hill]

I'm building boxes with the console set to /dev/ttyS0.  However, I can't
guarantee that there will always be a term plugged into the serial
port.  If there is no term on the port, eventually the buffer fills and
any processes that write to the console (i.e. init) block.  Is there some
option somewhere to stop this happening (i.e. either ignoring the
flow-control or just allowing the buffer to overflow)?

-- 

- Steve Hill
System Administrator         Email: steve@navaho.co.uk
Navaho Technologies Ltd.       Tel: +44-870-7034015


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Miquel van Smoorenburg]

In article <Pine.LNX.4.21.0012051202120.1578-100000@sorbus.navaho>,
Steve Hill  <steve@navaho.co.uk> wrote:
>I'm building boxes with the console set to /dev/ttyS0.  However, I can't
>guarantee that there will always be a term plugged into the serial
>port.  If there is no term on the port, eventually the buffer fills and
>any processes that write to the console (i.e. init) block.  Is there some
>option somewhere to stop this happening (i.e. either ignoring the
>flow-control or just allowing the buffer to overflow)?

Offtopic, but anyway ..

Sure, turn flow control off. You'll probably have to configure this
on the getty process that runs on ttyS0

Mike.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Paul Jakma]

On Tue, 5 Dec 2000, Steve Hill wrote:

>
> I'm building boxes with the console set to /dev/ttyS0.

how? symlink to /dev/ttyS0, or with console=ttyS0 boot option?

> However, I can't
> guarantee that there will always be a term plugged into the serial
> port.  If there is no term on the port, eventually the buffer fills and
> any processes that write to the console (i.e. init) block.  Is there some
> option somewhere to stop this happening (i.e. either ignoring the
> flow-control or just allowing the buffer to overflow)?

IIRC/AFAIK:

use /dev/console (char, 5,1) for all your programmes and boot the
kernel with serial console support and .

/dev/console will go to serial, but afaik it doesn't block for lack of
a terminal. (has something to do with /dev/console being semantically
different to /dev/tty..., eg it doesn't block, not sure of the exact
details).

--paulj

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Steve Hill]

On Tue, 5 Dec 2000, PaulJakma wrote:

> how? symlink to /dev/ttyS0, or with console=ttyS0 boot option?

console=ttyS0

> use /dev/console (char, 5,1) for all your programmes and boot the
> kernel with serial console support and .
> 
> /dev/console will go to serial, but afaik it doesn't block for lack of
> a terminal. (has something to do with /dev/console being semantically
> different to /dev/tty..., eg it doesn't block, not sure of the exact
> details).

Nope, /dev/console *does* block.  ATM I've found a quick workaround - I
use "stty -F /dev/console clocal -crtscts" to turn off the serial flow
control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite
well... of course it doesn't stop some program turning flow control back
on and ballsing it all up again :)

-- 

- Steve Hill
System Administrator         Email: steve@navaho.co.uk
Navaho Technologies Ltd.       Tel: +44-870-7034015


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Chad Schwartz]

> Nope, /dev/console *does* block.  ATM I've found a quick workaround - I
> use "stty -F /dev/console clocal -crtscts" to turn off the serial flow
> control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite
> well... of course it doesn't stop some program turning flow control back
> on and ballsing it all up again :)

...and to fix that, you could easily travel into
/usr/src/linux/drivers/char/serial.c, and a quick conditionional to check
whether or not the change was being made to a console port - and if it is,
dont allow CRTSCTS to be set.

Chad




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Paul Jakma]

On Tue, 5 Dec 2000, Steve Hill wrote:

> On Tue, 5 Dec 2000, PaulJakma wrote:
>
> > how? symlink to /dev/ttyS0, or with console=ttyS0 boot option?
>
> console=ttyS0
>
> Nope, /dev/console *does* block.

very weird.. the reason i replied to you, even though i have no direct
experience of serial console, was that last night i read a mail on the
linux-mips on almost exactly the same subject (serial console being
quite common on linux-mips), and IIRC Ralf Baechle explained how there
was a fundamental difference between tty and console precisely because
/dev/console might not be going anywhere.

Quoting from Ralf's email:

"/dev/console (as chardev 5/1) differs from another device in some important
ways:

- When opened by a process without controlling tty it will not become
  a CTTY even if the NOCTTY flag is not set.

- It will never block but rather loose data.  This may sound like a
  disadvantage but it's actually very important for proper operation.
  For example, if /dev/console'd block due to a serial console with
  hardware handshaking enabled (DON'T) syslogd writing to it may also
  block for an unbounded time and thus as soon as /dev/log is full all
  services trying to log via syslog(3) will also freeze.

 Syslogd actually tries to be clever about avoiding this from
 happening but fails to handle one case correctly, so this is a real
 world scenario.

- It uses different routines to access the console device than normal
  write access to i.e. ttyS0."

perhaps linux-mips is just different? or i386 serial-console is
incorrect?

> ATM I've found a quick workaround - I
> use "stty -F /dev/console clocal -crtscts" to turn off the serial flow
> control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite
> well... of course it doesn't stop some program turning flow control back
> on and ballsing it all up again :)

yukkk...

/dev/console having non-blocking semantics sounds much cleaner.

regards,

--paulj

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Steve Hill]

On Tue, 5 Dec 2000, PaulJakma wrote:

> > ATM I've found a quick workaround - I
> > use "stty -F /dev/console clocal -crtscts" to turn off the serial flow
> > control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite
> > well... of course it doesn't stop some program turning flow control back
> > on and ballsing it all up again :)
> 
> yukkk...
> 
> /dev/console having non-blocking semantics sounds much cleaner.

Yep - having a blocking console just seems like plain stupidity :(

-- 

- Steve Hill
System Administrator         Email: steve@navaho.co.uk
Navaho Technologies Ltd.       Tel: +44-870-7034015


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Chad Schwartz]

Unless of course you really DO have RTS/CTS (Or DTR-->CTS) flow control
turned on - on your terminal, and the terminal shuts off RTS (or DTR) to
indicate its fifo level is too high.

That *IS* useful.

but the ability to hard-code it in a shut-off state is *MUCH* better.

Chad

> On Tue, 5 Dec 2000, PaulJakma wrote:
>
> > > ATM I've found a quick workaround - I
> > > use "stty -F /dev/console clocal -crtscts" to turn off the serial flow
> > > control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite
> > > well... of course it doesn't stop some program turning flow control back
> > > on and ballsing it all up again :)
> >
> > yukkk...
> >
> > /dev/console having non-blocking semantics sounds much cleaner.
>
> Yep - having a blocking console just seems like plain stupidity :(
>
> --
>
> - Steve Hill
> System Administrator         Email: steve@navaho.co.uk
> Navaho Technologies Ltd.       Tel: +44-870-7034015
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Rogier Wolff]

Paul Jakma wrote:
> perhaps linux-mips is just different? or i386 serial-console is
> incorrect?

No. serial console on i386 doesn't and should not block. 
We're constantly using serial consoles here, so I really think I've 
seen this work... .

				Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Miquel van Smoorenburg]

In article <200012051625.RAA02860@cave.bitwizard.nl>,
Rogier Wolff <R.E.Wolff@BitWizard.nl> wrote:
>Paul Jakma wrote:
>> perhaps linux-mips is just different? or i386 serial-console is
>> incorrect?
>
>No. serial console on i386 doesn't and should not block. 
>We're constantly using serial consoles here, so I really think I've 
>seen this work... .

It can block.

Funny, no message on this list has been quite right ;)

/dev/console can block
/dev/ttyS0   can block
printk()     never blocks

init(8) reads the tty settings from /etc/ioctl.save at startup.
After it leaves single user mode it writes that file again. So
mods made in single user mode are saved to /etc/ioctl.save.
Every time init executes a program, it restores the console
settings to those from /etc/ioctl.save.
[Perhaps I should rip that stuff out]

However a getty on /dev/ttyS0 which you usually have running in
runlevels [12345789] can change the tty settings and they will
take effect immidiately. So if you run a getty that turns on
hardware handshaking (like mgetty) - you're fscked.

The only things in which /dev/console is special are:

- it's an alias for the current console
- it's always opened with O_NOCTTY

Mike.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Vitaly Luban]

Hi,

Steve Hill wrote:

> I'm building boxes with the console set to /dev/ttyS0.  However, I can't
> guarantee that there will always be a term plugged into the serial
> port.  If there is no term on the port, eventually the buffer fills and
> any processes that write to the console (i.e. init) block.  Is there some
> option somewhere to stop this happening (i.e. either ignoring the
> flow-control or just allowing the buffer to overflow)?
>

Try the following into /etc/inittab

s1:12345:respawn:/sbin/agetty -L 19200 ttyS0 vt100

"-L" here means "ignore flow control", the rest, as you wish.

Hope this helps,

Vitaly.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: serial console

[Coywolf Qi Hunt]

On 5/17/05, Matt Mackall <mpm@selenic.com> wrote:
> On Tue, May 17, 2005 at 09:24:23AM +0800, Coywolf Qi Hunt wrote:
> > On 5/17/05, Matt Mackall <mpm@selenic.com> wrote:
> > > On Mon, May 16, 2005 at 04:37:12PM -0700, Andrew Morton wrote:
> > > >
> > > > It would be nicer if this was a static inline, so all the function call
> > > > code at the callsites is removed by the compiler.
> > >
> > > Better yet, a patch that's actually right. add_preferred_console is
> > > setting the console used by init and so on, so it's still relevant
> > > with CONFIG_PRINTK off. So I just move it out of the ifdef. Obviously
> > > more correct(tm).
> > >
> > > Move add_preferred_console out of CONFIG_PRINTK so serial console does
> > > the right thing.
> >
> >
> > What's the purpose of serial console if printk is disabled?  I suggest
> > we put add_preferred_console and all its callers, console code etc
> > into CONFIG_PRINTK.
> 
> Serial console is currently two things: where to write kernel
> messages, and the terminal init is attached to.


For init, console_setup should be moved out of ifdef too, imho.

-- 
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

Re: serial console

[Matt Mackall]

On Tue, May 17, 2005 at 09:24:23AM +0800, Coywolf Qi Hunt wrote:
> On 5/17/05, Matt Mackall <mpm@selenic.com> wrote:
> > On Mon, May 16, 2005 at 04:37:12PM -0700, Andrew Morton wrote:
> > >
> > > It would be nicer if this was a static inline, so all the function call
> > > code at the callsites is removed by the compiler.
> > 
> > Better yet, a patch that's actually right. add_preferred_console is
> > setting the console used by init and so on, so it's still relevant
> > with CONFIG_PRINTK off. So I just move it out of the ifdef. Obviously
> > more correct(tm).
> > 
> > Move add_preferred_console out of CONFIG_PRINTK so serial console does
> > the right thing.
> 
> 
> What's the purpose of serial console if printk is disabled?  I suggest
> we put add_preferred_console and all its callers, console code etc
> into CONFIG_PRINTK.

Serial console is currently two things: where to write kernel
messages, and the terminal init is attached to.

-- 
Mathematics is the supreme nostalgia of our time.

Re: serial console

[Rob Landley]

On Monday 16 May 2005 07:15 pm, Matt Mackall wrote:

> +int __init add_preferred_console(char *name, int idx, char *options)
> +{
> +	return 0;
> +}
> +

Inline that puppy please.  I can be optimized away.  Having it be __init makes 
no sense...

Rob

Re: serial console

[Coywolf Qi Hunt]

On 5/17/05, Matt Mackall <mpm@selenic.com> wrote:
> On Mon, May 16, 2005 at 04:37:12PM -0700, Andrew Morton wrote:
> >
> > It would be nicer if this was a static inline, so all the function call
> > code at the callsites is removed by the compiler.
> 
> Better yet, a patch that's actually right. add_preferred_console is
> setting the console used by init and so on, so it's still relevant
> with CONFIG_PRINTK off. So I just move it out of the ifdef. Obviously
> more correct(tm).
> 
> Move add_preferred_console out of CONFIG_PRINTK so serial console does
> the right thing.


What's the purpose of serial console if printk is disabled?  I suggest
we put add_preferred_console and all its callers, console code etc
into CONFIG_PRINTK.

-- 
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

Re: serial console

[Matt Mackall]

On Mon, May 16, 2005 at 04:37:12PM -0700, Andrew Morton wrote:
> 
> It would be nicer if this was a static inline, so all the function call
> code at the callsites is removed by the compiler.

Better yet, a patch that's actually right. add_preferred_console is
setting the console used by init and so on, so it's still relevant
with CONFIG_PRINTK off. So I just move it out of the ifdef. Obviously
more correct(tm).


Move add_preferred_console out of CONFIG_PRINTK so serial console does
the right thing.

Signed-off-by: Matt Mackall <mpm@selenic.com>

Index: l-p/kernel/printk.c
===================================================================
--- l-p.orig/kernel/printk.c	2005-05-16 16:37:15.000000000 -0700
+++ l-p/kernel/printk.c	2005-05-16 16:40:31.000000000 -0700
@@ -160,42 +160,6 @@ static int __init console_setup(char *st
 
 __setup("console=", console_setup);
 
-/**
- * add_preferred_console - add a device to the list of preferred consoles.
- *
- * The last preferred console added will be used for kernel messages
- * and stdin/out/err for init.  Normally this is used by console_setup
- * above to handle user-supplied console arguments; however it can also
- * be used by arch-specific code either to override the user or more
- * commonly to provide a default console (ie from PROM variables) when
- * the user has not supplied one.
- */
-int __init add_preferred_console(char *name, int idx, char *options)
-{
-	struct console_cmdline *c;
-	int i;
-
-	/*
-	 *	See if this tty is not yet registered, and
-	 *	if we have a slot free.
-	 */
-	for(i = 0; i < MAX_CMDLINECONSOLES && console_cmdline[i].name[0]; i++)
-		if (strcmp(console_cmdline[i].name, name) == 0 &&
-			  console_cmdline[i].index == idx) {
-				selected_console = i;
-				return 0;
-		}
-	if (i == MAX_CMDLINECONSOLES)
-		return -E2BIG;
-	selected_console = i;
-	c = &console_cmdline[i];
-	memcpy(c->name, name, sizeof(c->name));
-	c->name[sizeof(c->name) - 1] = 0;
-	c->options = options;
-	c->index = idx;
-	return 0;
-}
-
 static int __init log_buf_len_setup(char *str)
 {
 	unsigned long size = memparse(str, &str);
@@ -671,6 +635,42 @@ static void call_console_drivers(unsigne
 #endif
 
 /**
+ * add_preferred_console - add a device to the list of preferred consoles.
+ *
+ * The last preferred console added will be used for kernel messages
+ * and stdin/out/err for init.  Normally this is used by console_setup
+ * above to handle user-supplied console arguments; however it can also
+ * be used by arch-specific code either to override the user or more
+ * commonly to provide a default console (ie from PROM variables) when
+ * the user has not supplied one.
+ */
+int __init add_preferred_console(char *name, int idx, char *options)
+{
+	struct console_cmdline *c;
+	int i;
+
+	/*
+	 *	See if this tty is not yet registered, and
+	 *	if we have a slot free.
+	 */
+	for(i = 0; i < MAX_CMDLINECONSOLES && console_cmdline[i].name[0]; i++)
+		if (strcmp(console_cmdline[i].name, name) == 0 &&
+			  console_cmdline[i].index == idx) {
+				selected_console = i;
+				return 0;
+		}
+	if (i == MAX_CMDLINECONSOLES)
+		return -E2BIG;
+	selected_console = i;
+	c = &console_cmdline[i];
+	memcpy(c->name, name, sizeof(c->name));
+	c->name[sizeof(c->name) - 1] = 0;
+	c->options = options;
+	c->index = idx;
+	return 0;
+}
+
+/**
  * acquire_console_sem - lock the console system for exclusive use.
  *
  * Acquires a semaphore which guarantees that the caller has


-- 
Mathematics is the supreme nostalgia of our time.

Re: serial console

[Andrew Morton]

Matt Mackall <mpm@selenic.com> wrote:
>
> Fix compile bug with serial console and printk disabled.
> 
> Signed-off-by: Matt Mackall <mpm@selenic.com>
> 
> Index: l-p/kernel/printk.c
> ===================================================================
> --- l-p.orig/kernel/printk.c	2005-05-16 15:13:51.000000000 -0700
> +++ l-p/kernel/printk.c	2005-05-16 15:29:56.000000000 -0700
> @@ -665,6 +665,11 @@ asmlinkage long sys_syslog(int type, cha
>  	return 0;
>  }
>  
> +int __init add_preferred_console(char *name, int idx, char *options)
> +{
> +	return 0;
> +}
> +

It would be nicer if this was a static inline, so all the function call
code at the callsites is removed by the compiler.

Yes, it's presumably __init code anyway, but that's no excuse ;)

Re: serial console

[Matt Mackall]

On Mon, May 16, 2005 at 01:57:31PM -0700, Matt Mackall wrote:
> On Mon, May 16, 2005 at 02:16:55PM -0700, YhLu wrote:
> > it says
> > 
> > drivers/built-in.o(.init.text+0x1b68): In function
> > `serial8250_start_console':
> > : undefined reference to `add_preferred_console'
> > 
> > add_preferred_console is defined in printk.c
> 
> Ahh. Turn CONFIG_PRINTK back on and it should work. This is broken in
> mainline too, I need to find time to fix it.

This should fix it (against 2.6.12-rc4, should apply cleanly to the
last -tiny release as well):

Fix compile bug with serial console and printk disabled.

Signed-off-by: Matt Mackall <mpm@selenic.com>

Index: l-p/kernel/printk.c
===================================================================
--- l-p.orig/kernel/printk.c	2005-05-16 15:13:51.000000000 -0700
+++ l-p/kernel/printk.c	2005-05-16 15:29:56.000000000 -0700
@@ -665,6 +665,11 @@ asmlinkage long sys_syslog(int type, cha
 	return 0;
 }
 
+int __init add_preferred_console(char *name, int idx, char *options)
+{
+	return 0;
+}
+
 int do_syslog(int type, char __user * buf, int len) { return 0; }
 static void call_console_drivers(unsigned long start, unsigned long end) {}
 



-- 
Mathematics is the supreme nostalgia of our time.

Re: Serial Console

[Russell King]

On Mon, Aug 19, 2002 at 11:10:45AM +0200, Carlos Velasco wrote:
>   append="console=ttyS0,115200n8r console=tty0 vga=0x0301"
                                  ^
The 'r' means "use rts/cts flow control".  If CTS is not active, the
kernel will spin waiting to write the next characters to the serial
console.

> Is there something to solve this issue?

Don't specify 'r' in the append line.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Serial Console

[Carlos Velasco]

Hi,

I have configured kernel to do output to tty0 and ttyS0 (serial console).

LILO:
image = /boot/vmlinuz_2419
  root = /dev/hda3
  label = linux_2419
  append="console=ttyS0,115200n8r console=tty0 vga=0x0301"


However I have seen that if I don't open the serial port from another machine, I can't reboot or boot kernel, as the output seems to freeze until port is open. When I open the serial port, normal operation is resumed.
Is there something to solve this issue?
I would like to use the serial console only when needed not always that I want boot or reboot machine.

Regards,
Carlos Velasco

Re: Serial Console

[Jon Burgess]

Yes it could be a modem on the line, so my comment about DCD is wrong, a comms
program must be able to send AT commands to the modem when DCD is not asserted
before the call is setup. I was being confused by the login getty which we run
on the same serial port. This drops back to the login prompt if it sees DCD
being dropped.

     Jon




PLANET PROJECT will connect millions of people worldwide through the combined
technology of 3Com and the Internet. Find out more and register now at
http://www.planetproject.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Chad Schwartz]

See, in an ideal world, that shouldn't be the case, at all.

Since we're NOT operating under the assumption that the serial console is
a modem, we should be - instead - operating under the assumption
that it is a 3-wire NULL connection. (thus, making NO assumptions about
the user's hardware..)

If the user wants to ADD RTS/CTS flow control or DCD based state checking
as an OPTION, well, hey.  whatever. Pick your poison.  But i sure as hell
wouldn't do it that way.

Chad

> Lilo 'append="console=ttyS0"' and it boots fine without a connection to the
> serial port without having to do any specific manipulation of the flow control.
> I think that all serial output is dumped to /dev/null if DCD is not asserted no
> matter what the flow control says. Perhaps there are some hardware differences
> in the configuration of the control signal pull-up/downs.
>
>      Jon Burgess
>
>
>
>
> PLANET PROJECT will connect millions of people worldwide through the combined
> technology of 3Com and the Internet. Find out more and register now at
> http://www.planetproject.com
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Serial Console

[Jon Burgess]

>>
>> /dev/console will go to serial, but afaik it doesn't block for lack of
>> a terminal. (has something to do with /dev/console being semantically
>> different to /dev/tty..., eg it doesn't block, not sure of the exact
>> details).

>Nope, /dev/console *does* block.  ATM I've found a quick workaround - I
>use "stty -F /dev/console clocal -crtscts" to turn off the serial flow
>control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite
>well... of course it doesn't stop some program turning flow control back
>on and ballsing it all up again :)

I've got a machine here which redirects the console to the serial port using
Lilo 'append="console=ttyS0"' and it boots fine without a connection to the
serial port without having to do any specific manipulation of the flow control.
I think that all serial output is dumped to /dev/null if DCD is not asserted no
matter what the flow control says. Perhaps there are some hardware differences
in the configuration of the control signal pull-up/downs.

     Jon Burgess




PLANET PROJECT will connect millions of people worldwide through the combined
technology of 3Com and the Internet. Find out more and register now at
http://www.planetproject.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/