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: [email protected]
Navaho Technologies Ltd. Tel: +44-870-7034015
In article <[email protected]>,
Steve Hill <[email protected]> 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.
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
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: [email protected]
Navaho Technologies Ltd. Tel: +44-870-7034015
> 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
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
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: [email protected]
Navaho Technologies Ltd. Tel: +44-870-7034015
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: [email protected]
> 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 [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
>>
>> /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
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 [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
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.
--
** [email protected] ** 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.
In article <[email protected]>,
Rogier Wolff <[email protected]> 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.
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
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.