Having grown tired of using a 9600 baud rate over ttya for the console
(headless Sun Blade 100) I just tried increasing the speed to 19200 or
38400. Neither new speed worked. (Well, 19200 worked long enough for
Solaris to print the first three or four lines of text that always
appear when it first boots, but that's it. 38400 baud didn't work at
all.) Is it possible to use higher speeds than 9600 for the console?
If so, then how does one do it?

drag <drag@alongthe.path> writes:
>
>Having grown tired of using a 9600 baud rate over ttya for the console
>(headless Sun Blade 100) I just tried increasing the speed to 19200 or
>38400. Neither new speed worked. (Well, 19200 worked long enough for
>Solaris to print the first three or four lines of text that always
>appear when it first boots, but that's it. 38400 baud didn't work at
>all.) Is it possible to use higher speeds than 9600 for the console?
>If so, then how does one do it?
>

You have to change the speed in 4 places:

1. The open boot prom's ttya-mode parameter.

2. The /kernel/drv/options.conf file.

3. The /etc/ioctl.syscon file.

4. The "console" line in /etc/ttydefs.

#2 and #3 are in "stty -g" format. The easiest way to get the
right settings into those files is to change #1 and #4, then
reboot. Live with the messed up boot messages until you get
the good login prompt. Log in as root on the console, and type
"stty -g > /tmp/console.speed". Then edit the files in #2 and
#3 using the formatted data in the /tmp/console.speed file.

Reboot and everything should work at the new speed.

Notes:
When editing the /kernel/drv/options.conf file, make sure to
replace just the data between the quote marks. Don't leave
off the other parts of the line, or your new data won't be used.

When editing the ioctl.syscon file, make a backup copy of the
original file (e.g. "cp /etc/ioctl/syscon /etc/ioctl/syscon.CYA")
before changing the file. Don't worry if the new data creates a
longer line in the file than the original data. Init knows how
to parse the longer line as well as the shorter one.

-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.

gerg@panix.com (Greg Andrews) writes:
>
>You have to change the speed in 4 places:
>
>1. The open boot prom's ttya-mode parameter.
>
>2. The /kernel/drv/options.conf file.
>
>3. The /etc/ioctl.syscon file.
>
>4. The "console" line in /etc/ttydefs.
>

Those are listed in the order in which they control the serial
port speed as the machine boots. #1 controls the port parameters
before the Solaris kernel loads (and after the kernel exits upon
shutdown), #2 controls the port after the kernel has loaded,
#3 controls the port after init starts running, and #4 controls
the port when booting is finished and init starts the console
ttymon process.

>
>Notes:
>
>When editing the ioctl.syscon file, make a backup copy of the
>original file (e.g. "cp /etc/ioctl/syscon /etc/ioctl/syscon.CYA")
>

Oops, that should be "cp /etc/ioctl.syscon /etc/ioctl.syscon.CYA".

-Greg

--
Do NOT reply via e-mail.
Reply in the newsgroup.

In article <bg1pul$63e$1@reader1.panix.com>, gerg@panix.com says...
> drag <drag@alongthe.path> writes:
> >
> >Having grown tired of using a 9600 baud rate over ttya for the console
> >(headless Sun Blade 100) I just tried increasing the speed to 19200 or
> >38400. Neither new speed worked. (Well, 19200 worked long enough for
> >Solaris to print the first three or four lines of text that always
> >appear when it first boots, but that's it. 38400 baud didn't work at
> >all.) Is it possible to use higher speeds than 9600 for the console?
> >If so, then how does one do it?
> >
>
> You have to change the speed in 4 places:
>
> 1. The open boot prom's ttya-mode parameter.
>
> 2. The /kernel/drv/options.conf file.
>
> 3. The /etc/ioctl.syscon file.
>
> 4. The "console" line in /etc/ttydefs.
>
> #2 and #3 are in "stty -g" format. The easiest way to get the
> right settings into those files is to change #1 and #4, then
> reboot. Live with the messed up boot messages until you get
> the good login prompt. Log in as root on the console, and type
> "stty -g > /tmp/console.speed". Then edit the files in #2 and
> #3 using the formatted data in the /tmp/console.speed file.
>
> Reboot and everything should work at the new speed.
>
> Notes:
> When editing the /kernel/drv/options.conf file, make sure to
> replace just the data between the quote marks. Don't leave
> off the other parts of the line, or your new data won't be used.
>
> When editing the ioctl.syscon file, make a backup copy of the
> original file (e.g. "cp /etc/ioctl/syscon /etc/ioctl/syscon.CYA")
> before changing the file. Don't worry if the new data creates a
> longer line in the file than the original data. Init knows how
> to parse the longer line as well as the shorter one.

Console speed is now 38400. Much better.

In article <Pine.GSO.4.44.0307271426420.449-100000@zaphod.rite-
group.com>, rich.teer@rite-group.com says...
> On Sun, 27 Jul 2003, drag wrote:
>
> > Having grown tired of using a 9600 baud rate over ttya for the console
> > (headless Sun Blade 100) I just tried increasing the speed to 19200 or
> > 38400. Neither new speed worked. (Well, 19200 worked long enough for
> > Solaris to print the first three or four lines of text that always
> > appear when it first boots, but that's it. 38400 baud didn't work at
> > all.) Is it possible to use higher speeds than 9600 for the console?
> > If so, then how does one do it?
>
> I'm not sure if there's a reliable way of increasing the speed.
> But I'm cursious to know why you're using the console so much,
> instead of logging in across the network.

I usually use SSH. (Actually, that's the only network service my
machine offers, because I disabled all the other stuff.) But now and
then one has to use the console. Like when installing patches in
single-user mode, or when SSH gets farked, or when one has to login
directly as root, or for a few other reasons that escape me at the
moment. Seems like I use the console at least once a week, and it
really blows when I do something that causes lots of text to scroll
because that takes a while at 9600 baud. (I try to do as much as
possible via SSH before going to the console, but sometimes I forget to
untar a file or something.)

But now the console is 38400 baud, so who cares.

drag <drag@path.along> writes:
[...]
> then one has to use the console. Like when installing patches in
> single-user mode, or when SSH gets farked, or when one has to login

You don't have to install patches in single user mode. (Though it may
be a 'best practices'.(?)) What are you doing so that SSH gets messed
up? It should just run (and does in my experience).

> directly as root, or for a few other reasons that escape me at the

Why would you need to login directly as root? Login (through SSH),
and then do a 'su -'.

[...]
> possible via SSH before going to the console, but sometimes I forget to
> untar a file or something.)
[...]

When you un-tar(1), don't use the "-v" option and there won't be an
output.

--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

David Magda <dmagda+trace030725@ee.ryerson.ca> writes:
>drag <drag@path.along> writes:
>[...]
>> then one has to use the console. Like when installing patches in
>> single-user mode, or when SSH gets farked, or when one has to login
>
>You don't have to install patches in single user mode.
>

Most kernel patches you do.

-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.

Greg Andrews <gerg@panix.com> probably said:
>David Magda <dmagda+trace030725@ee.ryerson.ca> writes:
>>You don't have to install patches in single user mode.
>Most kernel patches you do.

The text from the README included with the Solaris 8 (and all other
that I can recall) kernel patch says it should be done in single user
mode if possible, if not possible then in as quiet a system state as
you can manage.

I don't recall ever seeing a kernel patch say you _have_ to install in
single user mode, and I never have installed patches in single user
mode.

P.

--
pir pir-sig@pir.net pir-sig@net.tufts.edu

gerg@panix.com (Greg Andrews) writes:
> David Magda <dmagda+trace030725@ee.ryerson.ca> writes:
> >You don't have to install patches in single user mode.
>
> Most kernel patches you do.

To apply? I thought they could be applied in multi-user, but they
wouldn't take effect until you reboot. Am I mistaken in this?

--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

On 29 Jul 2003, David Magda wrote:

> To apply? I thought they could be applied in multi-user, but they
> wouldn't take effect until you reboot. Am I mistaken in this?

Strictly speaking, yes you are. Once a file is overwritten (by
a patch for example), the old contents are gone. If the old
contents stay in memory (i.e., are not paged out), life will be
OK, probably. But suppose something that's expecting the old
file pages in the new one? Boom.

Now, if the system is in mutliuser mode, but is otherwise
quiescent, then yeah, as a rule, you can get away with adding
patches - assuming a reboot is performed shortly thereafter.
But I wouldn't recommend it on a busy production system.

Patches for stuff that isn't currently being used can be
added in multiuser mode more safely. For example, if there
are no ssh sessions currently running on the machine, patching
ssh can be done safely by disabling it, adding the patch, and
then re-enabling it. No reboot required.

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net