serial console

serial console

[Dong Liu]

Ok, I got a serial cable , connect it, type "nvram console d", now I
can boot irix from a serial terminal, but for linux, the message
didn't come out, maybe all the serial parameters are not set right.

Dong.

Re: serial console

[ralf]

On Thu, Apr 02, 1998 at 03:06:21PM -0500, Dong Liu wrote:

> Ok, I got a serial cable , connect it, type "nvram console d", now I
> can boot irix from a serial terminal, but for linux, the message
> didn't come out, maybe all the serial parameters are not set right.

Linux doesn't accept the value ``dd'' for the console variable.  If you
try, Linux should complain about the setting and enter the interactive
firmware mode again.  Could you try setting console to either d1 or d2
according to the serial line you're using?

Thanks for testing this; having working serial consoles is on of the
missing parts in supporting the Challenge S.

  Ralf

Re: serial console

[William J. Earl]

ralf@uni-koblenz.de writes:
 > On Thu, Apr 02, 1998 at 03:06:21PM -0500, Dong Liu wrote:
 > 
 > > Ok, I got a serial cable , connect it, type "nvram console d", now I
 > > can boot irix from a serial terminal, but for linux, the message
 > > didn't come out, maybe all the serial parameters are not set right.
 > 
 > Linux doesn't accept the value ``dd'' for the console variable.  If you
 > try, Linux should complain about the setting and enter the interactive
 > firmware mode again.  Could you try setting console to either d1 or d2
 > according to the serial line you're using?

     For reduced user confusion, accepting "console=d" as an alias
for "console=d1" might reduce user confusion.

Re: serial console

[Dong Liu]

William J. Earl writes:
 > ralf@uni-koblenz.de writes:
 >  > On Thu, Apr 02, 1998 at 03:06:21PM -0500, Dong Liu wrote:
 >  > 
 >  > > Ok, I got a serial cable , connect it, type "nvram console d", now I
 >  > > can boot irix from a serial terminal, but for linux, the message
 >  > > didn't come out, maybe all the serial parameters are not set right.
 >  > 
 >  > Linux doesn't accept the value ``dd'' for the console variable.  If you
 >  > try, Linux should complain about the setting and enter the interactive
 >  > firmware mode again.  Could you try setting console to either d1 or d2
 >  > according to the serial line you're using?
 > 
 >      For reduced user confusion, accepting "console=d" as an alias
 > for "console=d1" might reduce user confusion.
 > 

Yes, but from arch/mips/sgi/setup.c

	ctype = prom_getenv("console");
	serial_console = 0;
	if(*ctype == 'd') {
		if(*(ctype+1)=='2')
			serial_console = 1;
		else
			serial_console = 2;
		if(!serial_console) {
			prom_printf("Weird console env setting %s\n", ctype);
			prom_printf("Press a key to reboot.\n");
			prom_getchar();
			prom_imode();
		}
	}

It got it the wrong serial_console, "d2" means serial port 1, "d"
means serial port 2.

Any way, I think I found out why serial port doesn't work, con_init()
call rs_cons_hook() before rs_init got called. 

But now I got another problem, I got the patch from
ftp://zero.aec.at/pub/sgi-linux, using the same .config file from the
same ftp site, I got

Exception: <vector=UTLB Miss>
Status register: 0x30044803<CU1,CU0,CH,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x8008<CE=0,IP8,EXC=RMISS>
Exception PC: 0x880ec7f0, Exception RA: 0x880f0294
exception, bad address: 0x0
Local I/O interrupt register 1: 0x80 <VR/GIO2>
  Saved user regs in hex (&gpda 0xa8740e08, &_regs 0xa8741008):
  arg: 0 8bfffcae 8bfffc24 88107498
  tmp: e 8813e5bc a 8811216c 100000 88100000 0 48
  sve: 88121228 2 8813e570 4 4 1 88121220 9fc47a40
  t8 48 t9 bfbd9833 at 4f v0 1 v1 88107498 k1 bad11bad
  gp 8bf70000 fp 9fc47bac sp 8bfff840 ra 880f0294

PANIC: Unexpected exception

[Press reset or ENTER to restart.]

So I can't compile the kernel my self:=(.

Dong

Re: serial console

[ralf]

On Thu, Apr 02, 1998 at 06:53:46PM -0500, Dong Liu wrote:

>  >      For reduced user confusion, accepting "console=d" as an alias
>  > for "console=d1" might reduce user confusion.

Correct.

> Yes, but from arch/mips/sgi/setup.c
> 
> 	ctype = prom_getenv("console");
> 	serial_console = 0;
> 	if(*ctype == 'd') {
> 		if(*(ctype+1)=='2')
> 			serial_console = 1;
> 		else
> 			serial_console = 2;
> 		if(!serial_console) {
> 			prom_printf("Weird console env setting %s\n", ctype);
> 			prom_printf("Press a key to reboot.\n");
> 			prom_getchar();
> 			prom_imode();
> 		}
> 	}
> 
> It got it the wrong serial_console, "d2" means serial port 1, "d"
> means serial port 2.

Ooops.

> Any way, I think I found out why serial port doesn't work, con_init()
> call rs_cons_hook() before rs_init got called. 
> 
> But now I got another problem, I got the patch from
> ftp://zero.aec.at/pub/sgi-linux, using the same .config file from the
> same ftp site, I got
> 
> Exception: <vector=UTLB Miss>
> Status register: 0x30044803<CU1,CU0,CH,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE>
> Cause register: 0x8008<CE=0,IP8,EXC=RMISS>
> Exception PC: 0x880ec7f0, Exception RA: 0x880f0294
> exception, bad address: 0x0
> Local I/O interrupt register 1: 0x80 <VR/GIO2>
>   Saved user regs in hex (&gpda 0xa8740e08, &_regs 0xa8741008):
>   arg: 0 8bfffcae 8bfffc24 88107498
>   tmp: e 8813e5bc a 8811216c 100000 88100000 0 48
>   sve: 88121228 2 8813e570 4 4 1 88121220 9fc47a40
>   t8 48 t9 bfbd9833 at 4f v0 1 v1 88107498 k1 bad11bad
>   gp 8bf70000 fp 9fc47bac sp 8bfff840 ra 880f0294

Which looks similar to the Challenge S report recently posted to this
list, but not the same.

  Ralf

Re: serial console

[Oliver Frommel]

Hi,

i think i fixed the serial console, at least it works here after linking
/dev/console to /dev/ttyS1 (i have no idea if this is the correct behaviour
however)
you can find the patch on ftp://zero.aec.at/pub/sgi-linux/serial-patch.gz

bye
-oliver

serial console

[Pat O'Rourke]

I have an Ultra-1 clone whose console is redirected to the serial port,
Console: ttyS0 (SAB82532), however it is only working intermittently when
linux boots.  By "working" I mean no output is seen, nor is any input
possible.

Messages sent directly to the prom seem okay, i.e. at the'ok' prompt or via
prom_printf() calls.  I tried various incantations of the serial= option to
noavail.  This problem is only when linux is booted, if I shutdown the OS
the console comes back and I can interact with OBP.

It seems that if I power cycle the machine the serial console will work,
but on subsequent reboots it does not.  Has anyone else encountered this?
The behavior is the same whether I am booting a 2.2.x or 2.3.x kernel.

Any suggestions would be greatly appreciated.

Thanks in advance,

Pat

-- 
Patrick O'Rourke
orourke@missioncriticallinux.com

Re: serial console

[Matthew Jacob]

> Messages sent directly to the prom seem okay, i.e. at the'ok' prompt or via
> prom_printf() calls.  I tried various incantations of the serial= option to
> noavail.  This problem is only when linux is booted, if I shutdown the OS
> the console comes back and I can interact with OBP.
> 
> It seems that if I power cycle the machine the serial console will work,
> but on subsequent reboots it does not.  Has anyone else encountered this?
> The behavior is the same whether I am booting a 2.2.x or 2.3.x kernel.
> 
> Any suggestions would be greatly appreciated.

define 'not work'? I've had the serial console just be 'strange' when running
it in a screen session so I just type 'reset'.

Re: serial console

[Pat O'Rourke]

Matthew Jacob wrote:

> define 'not work'? I've had the serial console just be 'strange' when running
> it in a screen session so I just type 'reset'.

It receives no output (kernel printk's don't show up) and does not accept
input.  I've been using minicom and the status bar shows 'offline' right
after the message 'Booting Linux...' appears (note this is a prom_printf
as opposed to a printk).

Pat


-- 
Patrick O'Rourke
orourke@missioncriticallinux.com

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

[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/

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

[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

[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

[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

[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/

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

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

[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

Re: Serial Console

[Stuart MacDonald]

From: "Carlos Velasco" <carlosev@newipnet.com>
>   append="console=ttyS0,115200n8r console=tty0 vga=0x0301"

I'm don't know the parameter syntax, but are you sure the above is
correct? A) n8r? Perhaps that r should be a 1? B) Can you set the
console twice like that?

> 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.

It sounds like the serial port is waiting for a signal, like DCD, to
become active before proceeding. I believe this has been discussed
before, have you checked the linux-kernel mailing archive? Use google
to find it.

..Stu

--
We make multiport serial boards.
<http://www.connecttech.com>
(800) 426-8979

Serial Console

[Aman]

Hi All

I have an custom board which has PPC 440GP as its processor. I have build a
kernel image and ramdisk to run on the custom board, which is running fine.
Now I want to disable the serial console in my kernel and use the serial
port for some other purpose. If I have to disable the serial console , what
command should be given for it in the kernel.

Thanking you in advance
Regards
Aman


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Serial Console

[Aman]

 Hi

 In the Redhat 7.0 linux, I was able to enable/disable the serial console
 using the following command in the inittab
 " T0:12345:respawn:/sbin/getty ttyS0 9600 vt100"
 However in the case of the 440 Linux the serial console is enabled already.
 I wanted to know how this enabling is done. Can someone add some points to
 this.

 Thanking you in advance
 Regards
 Aman


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial Console

[Mark Hatle]

Aman wrote:
>  Hi
>
>  In the Redhat 7.0 linux, I was able to enable/disable the serial console
>  using the following command in the inittab
>  " T0:12345:respawn:/sbin/getty ttyS0 9600 vt100"

That is actually not a serial "console", it is a serial "login".  (It's a small
distinction but an important one)

On a workstation system (with say VGA), when the system boots the "console"
comes up and displays your boot messages.  Eventually init executes and starts a
login sesssion on the same device as the default console.  Thus your screen has
both a "console" and "login" active.

>  However in the case of the 440 Linux the serial console is enabled already.
>  I wanted to know how this enabling is done. Can someone add some points to
>  this.

Probably with your configuration, the default system console is on a serial
port.  This means all boot and kernel messages will go there.

Again you will want to start a login process via init in order to do multi-user
logins.

(But in the embedded world, init, getty/login and such aren't required.  You can
just as easily boot right into /bin/sh.)

Now back to your original question.. How is it enabled:

The console is enabled either by the system configuration or by the kernel
command line, "console=".  Look in the "Documentation" directory in the kernel,
something in there explains serial consoles and the cmdline semantics.

--Mark

>
>  Thanking you in advance
>  Regards
>  Aman
>
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial Console

[Ibon Gotxi Garcia]

On Tue, 2003-03-04 at 15:40, Mark Hatle wrote:

>
> The console is enabled either by the system configuration or by the kernel
> command line, "console=".  Look in the "Documentation" directory in the kernel,
> something in there explains serial consoles and the cmdline semantics.
>

newbie question:
is there any chance of having virtual terminals through the serial port?

Cheers.

--
Ibon Gotxi Garcia <igotxi@jazzfree.com>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial Console

[Dave Wolfe]

[ Ibon Gotxi Garcia writes: ]
>
> newbie question:
> is there any chance of having virtual terminals through the serial port?

Check out screen ftp:ftp.uni-erlangen.de/pub/utilities/screen

   Screen is a full-screen window manager that multiplexes a physical ter-
   minal between several processes (typically interactive  shells).  Each
   virtual terminal provides the functions of a DEC VT100 terminal and, in
   addition, several control functions from the ISO 6429  (ECMA  48, ANSI
   X3.64)  and ISO 2022 standards (e.g. insert/delete line and support for
   multiple character sets).  There is a  scrollback  history buffer  for
   each virtual terminal and a copy-and-paste mechanism that allows moving
   text regions between windows.

and much, much more... It's not limited to serial terminals, BTW.

--
 Dave Wolfe

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

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

[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 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

[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

[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

[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

[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/

Serial console

[Daniel Ann]

Hi folks,

Just wondering if anyone could lend a hand with this problem I have
with serial console. I'm trying to boot up my board (very similar to
sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
working but console will display up to,
[snip]
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 112k init                                    =
   =20

I've done series of printk in sys_execve() to see if /sbin/init is
working, and found out it went thru the whole rcS file okay. Mind you,
printk is successfully displaying the output on the console while I'm
still not getting anything from the user processes.

Having all the kernel boot up log on console means that I've done some
part right. But why am I not getting anything from the user processes
on the console screen ?

Is there anything I need to do on the kernel config ?

--=20
Daniel

Re: Serial console

[Josh Boyer]

On Sat, 2005-07-30 at 10:06 +0900, Daniel Ann wrote:
> Hi folks,
> 
> Just wondering if anyone could lend a hand with this problem I have
> with serial console. I'm trying to boot up my board (very similar to
> sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> working but console will display up to,
> [snip]
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 112k init                                        
> 
> I've done series of printk in sys_execve() to see if /sbin/init is
> working, and found out it went thru the whole rcS file okay. Mind you,
> printk is successfully displaying the output on the console while I'm
> still not getting anything from the user processes.
> 
> Having all the kernel boot up log on console means that I've done some
> part right. But why am I not getting anything from the user processes
> on the console screen ?
> 
> Is there anything I need to do on the kernel config ?

Do you have a /dev/console device node in your initrd?  If not, that is
one of the reasons you could be seeing that problem.  Make
sure /dev/null is there too.

josh

Re: Serial console

[Ricardo Scop]

Hi Daniel,

On Friday 29 July 2005 22:06, Daniel Ann wrote:
> Hi folks,
>
> Just wondering if anyone could lend a hand with this problem I have
> with serial console. I'm trying to boot up my board (very similar to
> sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> working but console will display up to,
> [snip]
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 112k init
>
> I've done series of printk in sys_execve() to see if /sbin/init is
> working, and found out it went thru the whole rcS file okay. Mind you,
> printk is successfully displaying the output on the console while I'm
> still not getting anything from the user processes.
>
> Having all the kernel boot up log on console means that I've done some
> part right. But why am I not getting anything from the user processes
> on the console screen ?
>
Please verify that you have a /dev/console in your rootfs, and that it's =
being=20
correctly acessed by the init process.

HTH,

--=20
Ricardo Scop.

        \|/
    ___ -*-
   (@ @)/|\
  /  V  \|  R SCOP Consult.
 /(     )\  Linux-based communications
--^^---^^+------------------------------
rscop@matrix.com.br
+55 51 999-36-777
Porto Alegre, RS - BRazil

Re: Serial console

[Daniel Ann]

Looks like I have /dev/console
0 crw-------  1 root root 5, 1 Sep 26  2002 console
0 crw-rw-rw-  1 root root 4, 64 Jun 17  2004 ttyS0

I havent yet figured out how I should go about seeing if init is
correctly accessing it tho. Let me take a look at busybox init part.
BTW, any more reasons why this problem might exist ?



On 7/30/05, Ricardo Scop <scop@digitel.com.br> wrote:
> Hi Daniel,
>=20
> On Friday 29 July 2005 22:06, Daniel Ann wrote:
> > Hi folks,
> >
> > Just wondering if anyone could lend a hand with this problem I have
> > with serial console. I'm trying to boot up my board (very similar to
> > sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> > working but console will display up to,
> > [snip]
> > RAMDISK: Compressed image found at block 0
> > VFS: Mounted root (ext2 filesystem) readonly.
> > Freeing unused kernel memory: 112k init
> >
> > I've done series of printk in sys_execve() to see if /sbin/init is
> > working, and found out it went thru the whole rcS file okay. Mind you,
> > printk is successfully displaying the output on the console while I'm
> > still not getting anything from the user processes.
> >
> > Having all the kernel boot up log on console means that I've done some
> > part right. But why am I not getting anything from the user processes
> > on the console screen ?
> >
> Please verify that you have a /dev/console in your rootfs, and that it's =
being
> correctly acessed by the init process.
>=20
> HTH,
>=20
> --
> Ricardo Scop.
>=20
>        \|/
>    ___ -*-
>   (@ @)/|\
>  /  V  \|  R SCOP Consult.
>  /(     )\  Linux-based communications
> --^^---^^+------------------------------
> rscop@matrix.com.br
> +55 51 999-36-777
> Porto Alegre, RS - BRazil
>=20
>=20


--=20
Daniel

Re: Serial console

[Daniel Ann]

I too have /dev/null
0 crw-rw-rw-  1 root root 1, 3 Aug 31  2001 null

However, Im not using initrd. null, and console devices are in my RAMDISK t=
ho.

On 7/30/05, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> On Sat, 2005-07-30 at 10:06 +0900, Daniel Ann wrote:
> > Hi folks,
> >
> > Just wondering if anyone could lend a hand with this problem I have
> > with serial console. I'm trying to boot up my board (very similar to
> > sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> > working but console will display up to,
> > [snip]
> > RAMDISK: Compressed image found at block 0
> > VFS: Mounted root (ext2 filesystem) readonly.
> > Freeing unused kernel memory: 112k init
> >
> > I've done series of printk in sys_execve() to see if /sbin/init is
> > working, and found out it went thru the whole rcS file okay. Mind you,
> > printk is successfully displaying the output on the console while I'm
> > still not getting anything from the user processes.
> >
> > Having all the kernel boot up log on console means that I've done some
> > part right. But why am I not getting anything from the user processes
> > on the console screen ?
> >
> > Is there anything I need to do on the kernel config ?
>=20
> Do you have a /dev/console device node in your initrd?  If not, that is
> one of the reasons you could be seeing that problem.  Make
> sure /dev/null is there too.
>=20
> josh
>=20
>=20


--=20
Daniel

Re: Serial console

[Daniel Ann]

I've got a feeling that this has alot to do with IRQ.
Would I be correct to assume printk doesnt require interrupt to work
but printf does ?

After doing some testing, I've found my network interface ping-able
when I got printf working in 2.4.31. But if I alter the openpic source
to not initialize the interrupt, it also stop displaying at the same
point and network interface isnt pingable.

I guess my next problem would be then, why isnt my openpic working. :(
I've done exactly the same as what I did with 2.4.31 and that works.
Hmmm. Something must have changed in 2.6.12.3.

I dont think this is has anything to do with serial console, so I'm
gonna end the thread here.

Thanks.

On 7/30/05, Daniel Ann <ktdann@gmail.com> wrote:
> I too have /dev/null
> 0 crw-rw-rw-  1 root root 1, 3 Aug 31  2001 null
>=20
> However, Im not using initrd. null, and console devices are in my RAMDISK=
 tho.
>=20
> On 7/30/05, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> > On Sat, 2005-07-30 at 10:06 +0900, Daniel Ann wrote:
> > > Hi folks,
> > >
> > > Just wondering if anyone could lend a hand with this problem I have
> > > with serial console. I'm trying to boot up my board (very similar to
> > > sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> > > working but console will display up to,
> > > [snip]
> > > RAMDISK: Compressed image found at block 0
> > > VFS: Mounted root (ext2 filesystem) readonly.
> > > Freeing unused kernel memory: 112k init
> > >
> > > I've done series of printk in sys_execve() to see if /sbin/init is
> > > working, and found out it went thru the whole rcS file okay. Mind you=
,
> > > printk is successfully displaying the output on the console while I'm
> > > still not getting anything from the user processes.
> > >
> > > Having all the kernel boot up log on console means that I've done som=
e
> > > part right. But why am I not getting anything from the user processes
> > > on the console screen ?
> > >
> > > Is there anything I need to do on the kernel config ?
> >
> > Do you have a /dev/console device node in your initrd?  If not, that is
> > one of the reasons you could be seeing that problem.  Make
> > sure /dev/null is there too.
> >
> > josh
> >
> >
>=20
>=20
> --
> Daniel
>=20


--=20
Daniel

Re: Serial console

[Anton Wöllert]

Daniel Ann wrote:
> Hi folks,
> 
> Having all the kernel boot up log on console means that I've done some
> part right. But why am I not getting anything from the user processes
> on the console screen ?
> 
> Is there anything I need to do on the kernel config ?
> 

Hi, we've had the same problem some time ago on a tqm850l (mpc850). Our 
problem was, that we had registered two serial consoles in the kernel 
config or something like that. we had to disable all serial-driver stuff 
and enable just the platform-specific serial-console driver. we tracked 
this down with inserting a printk(buf) into the tty_write fs-op of the 
serial-port driver in drivers/char/tty_io.c. the ttyS0 was used but has 
taken another serial-driver than the platform specific.

may this help you :)


anton

Re: Serial console

[Daniel Ann]

Thanks for your input Anton.
I'm not all that certain about sandpoint platform has its own serial
driver so I've worked with 8250.c. Anyway, I've got it working now. It
was problem with interrupt. As soon as I changed interrupt from EGDE
to LEVEL it began working. Altho I'm faced with yet another problem
with openpic but I'm digging thru it at the moment.

BTW, I have no idea why EDGE didnt work and LEVEL does.

Cheers,
Daniel

On 7/30/05, Anton W=F6llert <a.woellert@gmail.com> wrote:
> Daniel Ann wrote:
> > Hi folks,
> >
> > Having all the kernel boot up log on console means that I've done some
> > part right. But why am I not getting anything from the user processes
> > on the console screen ?
> >
> > Is there anything I need to do on the kernel config ?
> >
>=20
> Hi, we've had the same problem some time ago on a tqm850l (mpc850). Our
> problem was, that we had registered two serial consoles in the kernel
> config or something like that. we had to disable all serial-driver stuff
> and enable just the platform-specific serial-console driver. we tracked
> this down with inserting a printk(buf) into the tty_write fs-op of the
> serial-port driver in drivers/char/tty_io.c. the ttyS0 was used but has
> taken another serial-driver than the platform specific.
>=20
> may this help you :)
>=20
>=20
> anton
>=20


--=20
Daniel

RE: Serial console

[JohnsonCheng]

Dear Daniel,

I also meet this problem on MPC8245 with linux-2.6.12.3, and I found it =
uses
LEVEL for interrupt in sandpoint.c. Do you have any idea for it?

Thanks,
Johnson Cheng

-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Daniel Ann
Sent: Monday, August 01, 2005 9:27 AM
To: Anton W=F6llert
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Serial console

Thanks for your input Anton.
I'm not all that certain about sandpoint platform has its own serial
driver so I've worked with 8250.c. Anyway, I've got it working now. It
was problem with interrupt. As soon as I changed interrupt from EGDE
to LEVEL it began working. Altho I'm faced with yet another problem
with openpic but I'm digging thru it at the moment.

BTW, I have no idea why EDGE didnt work and LEVEL does.

Cheers,
Daniel

On 7/30/05, Anton W=F6llert <a.woellert@gmail.com> wrote:
> Daniel Ann wrote:
> > Hi folks,
> >
> > Having all the kernel boot up log on console means that I've done =
some
> > part right. But why am I not getting anything from the user =
processes
> > on the console screen ?
> >
> > Is there anything I need to do on the kernel config ?
> >
>=20
> Hi, we've had the same problem some time ago on a tqm850l (mpc850). =
Our
> problem was, that we had registered two serial consoles in the kernel
> config or something like that. we had to disable all serial-driver =
stuff
> and enable just the platform-specific serial-console driver. we =
tracked
> this down with inserting a printk(buf) into the tty_write fs-op of the
> serial-port driver in drivers/char/tty_io.c. the ttyS0 was used but =
has
> taken another serial-driver than the platform specific.
>=20
> may this help you :)
>=20
>=20
> anton
>=20


--=20
Daniel
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Serial console

[Kumar Gala]

On Aug 1, 2005, at 10:38 PM, JohnsonCheng wrote:

> Dear Daniel,
>
> I also meet this problem on MPC8245 with linux-2.6.12.3, and I =20
> found it uses
> LEVEL for interrupt in sandpoint.c. Do you have any idea for it?

All internal interrupts on the MPC8245/1 should be LEVEL interrupts.

- kumar

> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Daniel Ann
> Sent: Monday, August 01, 2005 9:27 AM
> To: Anton W=F6llert
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Serial console
>
> Thanks for your input Anton.
> I'm not all that certain about sandpoint platform has its own serial
> driver so I've worked with 8250.c. Anyway, I've got it working now. It
> was problem with interrupt. As soon as I changed interrupt from EGDE
> to LEVEL it began working. Altho I'm faced with yet another problem
> with openpic but I'm digging thru it at the moment.
>
> BTW, I have no idea why EDGE didnt work and LEVEL does.
>
> Cheers,
> Daniel
>
> On 7/30/05, Anton W=F6llert <a.woellert@gmail.com> wrote:
>
>> Daniel Ann wrote:
>>
>>> Hi folks,
>>>
>>> Having all the kernel boot up log on console means that I've done =20=

>>> some
>>> part right. But why am I not getting anything from the user =20
>>> processes
>>> on the console screen ?
>>>
>>> Is there anything I need to do on the kernel config ?
>>>
>>>
>>
>> Hi, we've had the same problem some time ago on a tqm850l =20
>> (mpc850). Our
>> problem was, that we had registered two serial consoles in the kernel
>> config or something like that. we had to disable all serial-driver =20=

>> stuff
>> and enable just the platform-specific serial-console driver. we =20
>> tracked
>> this down with inserting a printk(buf) into the tty_write fs-op of =20=

>> the
>> serial-port driver in drivers/char/tty_io.c. the ttyS0 was used =20
>> but has
>> taken another serial-driver than the platform specific.
>>
>> may this help you :)
>>
>>
>> anton
>>
>>
>
>
> --=20
> Daniel
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

Re: Serial console

[Daniel Ann]

Right. Guess I found it hard way :)
After using LEVEL interrupt, it all works now.

On 8/2/05, Kumar Gala <kumar.gala@freescale.com> wrote:
>=20
> On Aug 1, 2005, at 10:38 PM, JohnsonCheng wrote:
>=20
> > Dear Daniel,
> >
> > I also meet this problem on MPC8245 with linux-2.6.12.3, and I
> > found it uses
> > LEVEL for interrupt in sandpoint.c. Do you have any idea for it?
>=20
> All internal interrupts on the MPC8245/1 should be LEVEL interrupts.
>=20
> - kumar
>=20
> > -----Original Message-----
> > From: linuxppc-embedded-bounces@ozlabs.org
> > [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Daniel Ann
> > Sent: Monday, August 01, 2005 9:27 AM
> > To: Anton W=F6llert
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: Serial console
> >
> > Thanks for your input Anton.
> > I'm not all that certain about sandpoint platform has its own serial
> > driver so I've worked with 8250.c. Anyway, I've got it working now. It
> > was problem with interrupt. As soon as I changed interrupt from EGDE
> > to LEVEL it began working. Altho I'm faced with yet another problem
> > with openpic but I'm digging thru it at the moment.
> >
> > BTW, I have no idea why EDGE didnt work and LEVEL does.
> >
> > Cheers,
> > Daniel
> >
> > On 7/30/05, Anton W=F6llert <a.woellert@gmail.com> wrote:
> >
> >> Daniel Ann wrote:
> >>
> >>> Hi folks,
> >>>
> >>> Having all the kernel boot up log on console means that I've done
> >>> some
> >>> part right. But why am I not getting anything from the user
> >>> processes
> >>> on the console screen ?
> >>>
> >>> Is there anything I need to do on the kernel config ?
> >>>
> >>>
> >>
> >> Hi, we've had the same problem some time ago on a tqm850l
> >> (mpc850). Our
> >> problem was, that we had registered two serial consoles in the kernel
> >> config or something like that. we had to disable all serial-driver
> >> stuff
> >> and enable just the platform-specific serial-console driver. we
> >> tracked
> >> this down with inserting a printk(buf) into the tty_write fs-op of
> >> the
> >> serial-port driver in drivers/char/tty_io.c. the ttyS0 was used
> >> but has
> >> taken another serial-driver than the platform specific.
> >>
> >> may this help you :)
> >>
> >>
> >> anton
> >>
> >>
> >
> >
> > --
> > Daniel
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>=20
>=20


--=20
Daniel

serial console

[KokHow Teh]

Hi;
      I have debian linux running on my PQ2FADS-ZU with devfs and seria=
l
driver compiled in. I have read Documentation/serial-console.txt and I =
have
tried both passing "console=3D" option as well as without passing that =
to the
kernel and both don't give me the expected results.
      When I pass "console=3Dtts/0,115200n8" to the kernel, I don't get=
 any
console output until the login prompt which I set to 115200 in
/etc/inittab. When I don't pass "console=3D" option to the kernel, I ge=
t
console output all the way until "Freeing unused kernel memory:" and th=
e
console output is garbled and I don't see any login prompt. Here is the=

/dev/* content:


(none) login:
Debian GNU/Linux 3.1 (none) tts/0
Password:
Last login: Thu Jan  1 02:29:06 1970 on tts/0

The programs included with the Debian GNU/Linux system are free softwar=
e;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
(none):~# l /dev
total 0
crw-------  1 root root 8, 0 Jan  1 02:00 .devfsd
lr-xr-xr-x  1 root root   13 Jan  1 02:37 MAKEDEV -> /sbin/MAKEDEV
crw-------  1 root root 5, 1 Jan  1 02:00 console
drwxr-xr-x  1 root root    0 Jan  1 02:00 discs
crw-rw-rw-  1 root root 1, 7 Jan  1 02:00 full
drwxr-xr-x  1 root root    0 Jan  1 02:00 ide
prw-------  1 root root    0 Jan  1 02:37 initctl
crw-r-----  1 root root 1, 2 Jan  1 02:00 kmem
srw-rw-rw-  1 root root    0 Jan  1 02:37 log
crw-r-----  1 root root 1, 1 Jan  1 02:00 mem
drwxr-xr-x  1 root root    0 Jan  1 02:00 misc
drwxr-xr-x  1 root root    0 Jan  1 02:00 mtd
drwxr-xr-x  1 root root    0 Jan  1 02:00 mtdblock
crw-rw-rw-  1 root root 1, 3 Jan  1 02:00 null
crw-r-----  1 root root 1, 4 Jan  1 02:00 port
crw-rw-rw-  1 root root 5, 2 Jan  1 02:00 ptmx
drwxr-xr-x  1 root root    0 Jan  1 02:00 pts
drwxr-xr-x  1 root root    0 Jan  1 02:00 pty
crw-r--r--  1 root root 1, 8 Jan  1 02:00 random
drwxr-xr-x  1 root root    0 Jan  1 02:00 rd
lr-xr-xr-x  1 root root   33 Jan  1 02:37 root -> ide/host0/bus0/target=
0/lun0/part2
drwxrwxrwt  3 root root   60 Jan  1 02:37 shm
drwxr-xr-x  1 root root    0 Jan  1 02:00 soc
drwxr-xr-x  1 root root    0 Jan  1 02:00 tts
crw-rw-rw-  1 root root 5, 0 Jan  1 02:00 tty
crw-r--r--  1 root root 1, 9 Jan  1 02:37 urandom
prw-r-----  1 root adm     0 Jan  1 02:37 xconsole
crw-rw-rw-  1 root root 1, 5 Jan  1 02:00 zero
(none):~#

      This is what I end up without "console=3D" option passed to the k=
ernel:

<snip>
Mounted devfs on /dev
Freeing unused kernel memory: 232k init 4k prep
..=EF=BF=BD=EF=BF=BD=EF=BF=BD.=EF=BF=BD...=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD.=EF=BF=BD=EF=BF=BD.=EF=BF=BD=
...=EF=BF=BD...=EF=BF=BD=EF=BF=BD=EF=BF=BD......=EF=BF=BD..=EF=BF=BD...=
=EF=BF=BD=EF=BF=BD=EF=BF=BD..=EF=BF=BD.=EF=BF=BD.=EF=BF=BD=EF=BF=BD.=EF=
=BF=BD=EF=BF=BD.....=EF=BF=BD=EF=BF=BD[42;124H.
 <no login prompt>

      My question is, how can I get a complete serial console output al=
l
the way from bootup to the login prompt? I am missing something. It is
either the kernel configuration or I have to tweak the codes somewhere.=
 Any
input and insight is appreciated.

Regards,
TEH
=

Re: serial console

[David Jander]

On Tuesday 04 October 2005 08:54, KokHow Teh wrote:
> Hi;
>       I have debian linux running on my PQ2FADS-ZU with devfs and serial
> driver compiled in. I have read Documentation/serial-console.txt and I have
> tried both passing "console=" option as well as without passing that to the
> kernel and both don't give me the expected results.
>       When I pass "console=tts/0,115200n8" to the kernel, I don't get any
> console output until the login prompt which I set to 115200 in
> /etc/inittab. When I don't pass "console=" option to the kernel, I get
> console output all the way until "Freeing unused kernel memory:" and the
> console output is garbled and I don't see any login prompt. Here is the
> /dev/* content:

I don't know exactly what I am talking about right now, but the string "tts/0" 
in the console-line sounds suspicious to me. AFAIK when using devfs still 
device names on the kernel-commandline have to be old-style.
Just a guess: try using "console=ttyS0,115200n8" and see if this helps.

Greetings,

-- 
David Jander

Re: serial console

[Vitaly Bordug]

> On Tuesday 04 October 2005 08:54, KokHow Teh wrote:
> 
>>Hi;
>>      I have debian linux running on my PQ2FADS-ZU with devfs and serial
>>driver compiled in. I have read Documentation/serial-console.txt and I have
>>tried both passing "console=" option as well as without passing that to the
>>kernel and both don't give me the expected results.
>>      When I pass "console=tts/0,115200n8" to the kernel, I don't get any
>>console output until the login prompt which I set to 115200 in
>>/etc/inittab. When I don't pass "console=" option to the kernel, I get
>>console output all the way until "Freeing unused kernel memory:" and the
>>console output is garbled and I don't see any login prompt. Here is the
>>/dev/* content:
> 
> 
> I don't know exactly what I am talking about right now, but the string "tts/0" 
> in the console-line sounds suspicious to me. AFAIK when using devfs still 
> device names on the kernel-commandline have to be old-style.
> Just a guess: try using "console=ttyS0,115200n8" and see if this helps.
> 
Yes, but PQ2FADS use cpm_uart and hence the commandline should be
console=ttyCPM0,115200

> Greetings,
> 


-- 
Sincerely,
Vitaly

Re: serial console

[KokHow Teh]

Hi;
      I have tried with 4 types of command lines with my linux kernel with
devfs and serial device compiled in and none gives me the desired results:

(1)   console=tts/0,115200n8 OR console=ttyCPM0,115200n8

      no serial console output at all during boot time but it gives me
login prompt at the end.

(2)   without "console=" OR console=ttyS0,115200n8

      serial console output fine during bootup but only until the point
when it prints out "Freeing unused kernel memory: 232k init 4k prep". After
that, the serial console output is garbled.

      So this has not solved my problem. I need more advice. Here are some
more questions and observations:

(1)   David Jander's comment:

I don't know exactly what I am talking about right now, but the string
"tts/0"
in the console-line sounds suspicious to me. AFAIK when using devfs still
device names on the kernel-commandline have to be old-style.
Just a guess: try using "console=ttyS0,115200n8" and see if this helps.

      Is it confirmed that kernel-commandline has to be old-style even
though the kernel is using devfs?

(2)   Vitaly Bordug's suggestion of using "console=ttyCPM0". May I know
where is ttyCPM0 defined and how is it bound to the serial console device
driver in the source?

      Thanks for any input and pointer.

Regards,
TEH



Vitaly Bordug <vbordug@ru.mvista.com> on 10/04/2005 11:16:10 PM

To:    KokHow.Teh@marconi.com
cc:    linuxppc-embedded list <linuxppc-embedded@ozlabs.org>

Subject:    Re: serial console



> On Tuesday 04 October 2005 08:54, KokHow Teh wrote:
>
>>Hi;
>>      I have debian linux running on my PQ2FADS-ZU with devfs and serial
>>driver compiled in. I have read Documentation/serial-console.txt and I
have
>>tried both passing "console=" option as well as without passing that to
the
>>kernel and both don't give me the expected results.
>>      When I pass "console=tts/0,115200n8" to the kernel, I don't get any
>>console output until the login prompt which I set to 115200 in
>>/etc/inittab. When I don't pass "console=" option to the kernel, I get
>>console output all the way until "Freeing unused kernel memory:" and the
>>console output is garbled and I don't see any login prompt. Here is the
>>/dev/* content:
>
>
> I don't know exactly what I am talking about right now, but the string
"tts/0"
> in the console-line sounds suspicious to me. AFAIK when using devfs still
> device names on the kernel-commandline have to be old-style.
> Just a guess: try using "console=ttyS0,115200n8" and see if this helps.
>
Yes, but PQ2FADS use cpm_uart and hence the commandline should be
console=ttyCPM0,115200

> Greetings,
>


--
Sincerely,
Vitaly

Re: serial console

[KokHow Teh]

Hi;
      I have tried with 4 types of command lines with my linux kernel with
devfs and serial device compiled in and none gives me the desired results:

(1)   console=tts/0,115200n8 OR console=ttyCPM0,115200n8

      no serial console output at all during boot time but it gives me
login prompt at the end.

(2)   without "console=" OR console=ttyS0,115200n8

      serial console output fine during bootup but only until the point
when it prints out "Freeing unused kernel memory: 232k init 4k prep". After
that, the serial console output is garbled. No login prompt.

      So this has not solved my problem. I need more advice. Here are some
more questions and observations:

(1)   David Jander's comment:

I don't know exactly what I am talking about right now, but the string
"tts/0"
in the console-line sounds suspicious to me. AFAIK when using devfs still
device names on the kernel-commandline have to be old-style.
Just a guess: try using "console=ttyS0,115200n8" and see if this helps.

      Is it confirmed that kernel-commandline has to be old-style even
though the kernel is using devfs?

(2)   Vitaly Bordug's suggestion of using "console=ttyCPM0". May I know
where is ttyCPM0 defined and how is it bound to the serial console device
driver in the source?

      Thanks for any input and pointer.

Regards,
TEH

Re: serial console

[David Jander]

On Tuesday 04 October 2005 17:16, Vitaly Bordug wrote:
> Yes, but PQ2FADS use cpm_uart and hence the commandline should be
> console=ttyCPM0,115200

You are totally right. I did that same mistake once in the past and again now. 
Shame on me ;-)
Now that I remeber, this might give trouble if you happen to use a normal uart 
(16550 or similar) also, and devfs. I had to slightly hack serial.c in my 
version of the kernel for this combination to work. I don't remeber right now 
exactly what I did, but it had to do with "SERIAL_DEV_OFFSET" and major/minor 
numbers ;-)
Anyway, I don't think your board has this combination.

Greetings,

-- 
David Jander

Re: serial console

[Vitaly Bordug]

KokHow Teh wrote:
> Hi;
>       I have tried with 4 types of command lines with my linux kernel with
> devfs and serial device compiled in and none gives me the desired results:
> 
> (1)   console=tts/0,115200n8 OR console=ttyCPM0,115200n8
> 
>       no serial console output at all during boot time but it gives me
> login prompt at the end.
> 
> (2)   without "console=" OR console=ttyS0,115200n8
> 
>       serial console output fine during bootup but only until the point
> when it prints out "Freeing unused kernel memory: 232k init 4k prep". After
> that, the serial console output is garbled. No login prompt.
> 
>       So this has not solved my problem. I need more advice. Here are some
> more questions and observations:
> 
> (1)   David Jander's comment:
> 
> I don't know exactly what I am talking about right now, but the string
> "tts/0"
> in the console-line sounds suspicious to me. AFAIK when using devfs still
> device names on the kernel-commandline have to be old-style.
> Just a guess: try using "console=ttyS0,115200n8" and see if this helps.
> 
>       Is it confirmed that kernel-commandline has to be old-style even
> though the kernel is using devfs?
> 
> (2)   Vitaly Bordug's suggestion of using "console=ttyCPM0". May I know
> where is ttyCPM0 defined and how is it bound to the serial console device
> driver in the source?
> 
Ummm.. The driver itself is in drivers/serial/cpm_uart. It does have the 
different major than ordinary ttyS... This relates to the 2.6.x kernel 
of course. I could suggest you to try the latest kernel.org release, in 
which you board is known to work fine.

>       Thanks for any input and pointer.
> 
> Regards,
> TEH
> 
> 
> 


-- 
Sincerely,
Vitaly

serial console

[Raymond Burns]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 501 bytes --]

Hi

It's tough to debug a headless box :)

I believe the call to register_console() is the significant code.
Where it should go I have no idea.

I did not cleanup the patch in case something else mattered. 

I've had a sparc booted to linux for all of one week so I know the
code is not "right" but it works. Therefore it may save some one some
time in making the "right" patch.

Now to track down the "BUG_ON(sparc_cpu_model != sun4m)"  's and find
some code that will work for a sun4d

Thanx
  Ray


[-- Attachment #2: context diff serial console --]
[-- Type: TEXT/PLAIN, Size: 1838 bytes --]

*** arch/sparc/kernel/setup.c	Thu May 11 23:31:53 2006
--- /sparc.d2/linux-2.6.16.15/arch/sparc/kernel/setup.c	Fri May 19 08:57:28 2006
***************
*** 158,163 ****
--- 158,170 ----
  	}
  }
  
+ static struct console boot_serial_console = {
+ 	.name =		"ttyS0",
+ 	.write =	prom_console_write,
+ 	.flags =	CON_ENABLED,
+ 	.index =	-1,
+ };
+ 
  static void __init process_console(char *commands)
  {
  	serial_console = 0;
***************
*** 170,175 ****
--- 177,185 ----
  		/* Solaris-style serial */
  		if (c == 'a' || c == 'b')
  			serial_console = c - 'a' + 1;
+ 		register_console(&boot_serial_console);
+ 		add_preferred_console("ttyS",serial_console - 1,NULL);
+ 		prom_printf ("Using /dev/tty%c as console.\n",'a' -1 + serial_console);
  		/* else Linux-style fbcon, not serial */
  	}
  #if defined(CONFIG_PROM_CONSOLE)
***************
*** 302,309 ****
--- 313,322 ----
  	};
  
  #ifdef CONFIG_DUMMY_CONSOLE
+ if (serial_console==0) 
  	conswitchp = &dummy_con;
  #elif defined(CONFIG_PROM_CONSOLE)
+ if (serial_console==0) 
  	conswitchp = &prom_con;
  #endif
  	boot_flags_init(*cmdline_p);
***************
*** 356,363 ****
  	int idev, odev;
  
  	/* The user has requested a console so this is already set up. */
! 	if (serial_console >= 0)
! 		return -EBUSY;
  
  	idev = prom_query_input_device();
  	odev = prom_query_output_device();
--- 369,380 ----
  	int idev, odev;
  
  	/* The user has requested a console so this is already set up. */
! 	if (serial_console >= 0) {
! 		prom_printf("keeping console %d\n",serial_console);
! 		/* everything that is except */
! 		return add_preferred_console("ttyS", serial_console - 1, NULL);
! /*		return -EBUSY;*/
!         }
  
  	idev = prom_query_input_device();
  	odev = prom_query_output_device();

Re: serial console

[David S. Miller]

Why does booting with the "-p" option not work?
That uses the PROM as the output console just like
your patch does.

Re: serial console

[Raymond Burns]

Hi

On Sun, 21 May 2006, David S. Miller wrote:

> 
> Why does booting with the "-p" option not work?
> That uses the PROM as the output console just like
> your patch does.
> 

I believe testing -p was where I placed 
 if (serial_console=0)
before 
 conswitchp = &(dummy_con/prom_con)

The result of testing -p which led to this was the console (wyse 150
as vt100) tried to do some sort of mode change / clear screen then
fill a screen buffer with blanks (?) then sit inertly at top left
corner. The prom_printf's I have been adding to track down troubles
did not show.

I could not determine if this was something to do with frame buffer or
virtual terminal, but it interfered with prom_printf. I do have
virtual terminals enabled for use with telnet / rlogin from
un-beheaded boxes when it boots and have found no way to turn off the
CONFIG_VT_CONSOLE if CONFIG_VT is set (editing .config doesn't).

With the patch I get prom_printf's and printk's 
Without the patch I get prom_printf only 
And yes with -p I get nothing (I am sorry, once I got printk's on the
screen I did not go back and test the -p so I don't know what it does
after the patch).

I would not mind testing patches that attempt to do this "right"

Thanx
  Ray

serial console

[sylarrrrrrr]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

Hi



I have two computers which I would like to connect to each other with a serial cable and have a serial console thus. I would like to know (before I search and buy and install all the serial brackets for motherboard headers, and cable) if I would be able to use the serial console in parallel to the normal VGA screen. (that is that I will able to see and? interact with the computer both from the serial console(via the second computer), and from the normal VGA via mouse and keyboard)



[-- Attachment #2: Type: text/html, Size: 925 bytes --]

Re: serial console

[Pavel Roskin]

On Wed, 2009-07-08 at 05:53 -0400, sylarrrrrrr@aim.com wrote:

> I have two computers which I would like to connect to each other with
> a serial cable and have a serial console thus. I would like to know
> (before I search and buy and install all the serial brackets for
> motherboard headers, and cable) if I would be able to use the serial
> console in parallel to the normal VGA screen. (that is that I will
> able to see and  interact with the computer both from the serial
> console(via the second computer), and from the normal VGA via mouse
> and keyboard)

I believe it's not implemented yet.  Only one handler for terminal input
or terminal output can be active at any time.

-- 
Regards,
Pavel Roskin

serial console

[Riccardo Veraldi]

hello,
how is possible ins ome way to have access to serial console using libvirt ?

until now I used quemu-kvm started inside a screen process.

but now I am managing my kvm machines with libvirt and in this way I 
have no access to a serial console.
IS there some way to do it ?

thanks

Rick

Re: serial console

[Avi Kivity]

On 12/30/2009 05:52 PM, Riccardo Veraldi wrote:
>
> hello,
> how is possible ins ome way to have access to serial console using 
> libvirt ?
>
> until now I used quemu-kvm started inside a screen process.
>
> but now I am managing my kvm machines with libvirt and in this way I 
> have no access to a serial console.
> IS there some way to do it ?
>

Please direct libvirt questions to the libvirt mailing list 
(libvir-list@redhat.com).

-- 
error compiling committee.c: too many arguments to function