Mailing List Archive

On Thu, Jun 20, 2002 at 08:19:48AM +0100, Nicholas.Penney@uk.ing.com wrote:
> However no matter what I do I cannot get the servers to drop to the OK
> prompt when connecting through the console software. Issuing ctrl-e,c,l0
> and/or ctrl-e,c,l2 both display the "[halt sent]" message and display ~^B on
> the screen but the server just carries on in full multi-user mode.
>
> Has anybody got these CS9000's working with this software? Can you offer
> any suggestions as to how I can proceed to get this working?

i doubt the cs9000's are the problem. i personally don't have an
alt-break setup to test with, but my best guess is that there needs to
be a 0.5 second delay between each character for this to work. at
least, that's the info i'm seeing at sunsolve. there is no delay in
the code. so, the big test is, can you type <cr>,~,<ctrl-b> by hand
during a console session and get a machine to halt? if so, it's
probably the delay issue. unfortunately, there is no way to fix this
without some code changes. but, if typing the sequence by hand doesn't
work either, something else is going on. lemme know how it goes with
the test (it'll prove we *really* need that delay capability).

Bryan

On Thu, 20 Jun 2002, Bryan Stansell wrote:

> On Thu, Jun 20, 2002 at 08:19:48AM +0100, Nicholas.Penney@uk.ing.com wrote:
> > However no matter what I do I cannot get the servers to drop to the OK
> > prompt when connecting through the console software. Issuing ctrl-e,c,l0
> > and/or ctrl-e,c,l2 both display the "[halt sent]" message and display ~^B on
> > the screen but the server just carries on in full multi-user mode.
> >
> > Has anybody got these CS9000's working with this software? Can you offer
> > any suggestions as to how I can proceed to get this working?
>
> i doubt the cs9000's are the problem. i personally don't have an
> alt-break setup to test with, but my best guess is that there needs to
> be a 0.5 second delay between each character for this to work. at
> least, that's the info i'm seeing at sunsolve. there is no delay in
> the code. so, the big test is, can you type <cr>,~,<ctrl-b> by hand
> during a console session and get a machine to halt? if so, it's
> probably the delay issue. unfortunately, there is no way to fix this
> without some code changes. but, if typing the sequence by hand doesn't
> work either, something else is going on. lemme know how it goes with
> the test (it'll prove we *really* need that delay capability).
>

expect has some really good code for doing delay if you feel like
'borrowing'. There's one part, send_human, that will even simulate
a human typing at the keyboard (with all the inherent variability
therein). Most of it is C. You'd have to replace some of the Tcl
buffer translation, but it doesn't look too hard on the surface.
(You may even have already thought of this. :)

Doug

I have tried and tried but cannot get the \r~^b key sequence to cause a
break whilst connected to any of my servers using the CS9000's, however they
DO respond when I attach direct using a vt100 console!

The servers I tested (Netra's) do respond to a #. sequence to cause them to
drop to the LOM prompt, and from there I can do a reset but it's "just not
right".

Even though I haven't got the "alternate break sequence" for Sun's working
yet, could you look at introducing the 0.5 second delays in the sequence as,
as I read it, they are needed.

-----Original Message-----
From: Bryan Stansell [mailto:bryan@conserver.com]
Sent: Thursday, June 20, 2002 10:16 AM
To: users@conserver.com
Subject: Re: break sequence not working CS9000 -> Sun's


On Thu, Jun 20, 2002 at 08:19:48AM +0100, Nicholas.Penney@uk.ing.com wrote:
> However no matter what I do I cannot get the servers to drop to the OK
> prompt when connecting through the console software. Issuing ctrl-e,c,l0
> and/or ctrl-e,c,l2 both display the "[halt sent]" message and display ~^B
on
> the screen but the server just carries on in full multi-user mode.
>
> Has anybody got these CS9000's working with this software? Can you offer
> any suggestions as to how I can proceed to get this working?

i doubt the cs9000's are the problem. i personally don't have an
alt-break setup to test with, but my best guess is that there needs to
be a 0.5 second delay between each character for this to work. at
least, that's the info i'm seeing at sunsolve. there is no delay in
the code. so, the big test is, can you type <cr>,~,<ctrl-b> by hand
during a console session and get a machine to halt? if so, it's
probably the delay issue. unfortunately, there is no way to fix this
without some code changes. but, if typing the sequence by hand doesn't
work either, something else is going on. lemme know how it goes with
the test (it'll prove we *really* need that delay capability).

Bryan


------------------------------------------------------------------------------
The information in this Internet email is confidential and may be
legally privileged. It is intended solely for the addressee. Access
to this Internet email by anyone else is unauthorised.

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this Internet email are subject to the terms and conditions
expressed in any applicable governing ING terms of business or
client engagement letter.

Visit us at www.ing.com

------------------------------------------------------------------------------

On Mon, Jun 24, 2002 at 08:48:14AM +0100, Nicholas.Penney@uk.ing.com wrote:
> I have tried and tried but cannot get the \r~^b key sequence to cause a
> break whilst connected to any of my servers using the CS9000's, however they
> DO respond when I attach direct using a vt100 console!

i was curious, so i took a quick peek at the cs9000 docs that are
online. i couldn't find anything except for the 'set telnet' command.
there's a 'mapnl' option that looks interesting. a 'show telnet line
1' should show if it's on for line 1. i'd bet it shouldn't be. the
'mode' option probably should be off as well. i'm thinking that either
the CR is being mapped to NL or a NL is being inserted or some other
such manipulation is being done and therefore the sun isn't seeing the
right sequence. at least, that's my theory - based on no real idea of
what those options are supposed to do since they aren't documented
well.

> The servers I tested (Netra's) do respond to a #. sequence to cause them to
> drop to the LOM prompt, and from there I can do a reset but it's "just not
> right".

i agree, but it's at least a fallback position.

> Even though I haven't got the "alternate break sequence" for Sun's working
> yet, could you look at introducing the 0.5 second delays in the sequence as,
> as I read it, they are needed.

yeah, i'm looking into it no matter what. just not sure how to deal
with the code yet.

Bryan

--- Bryan Stansell <bryan@conserver.com> wrote:
> On Mon, Jun 24, 2002 at 08:48:14AM +0100,
> Nicholas.Penney@uk.ing.com wrote:
> > I have tried and tried but cannot get the \r~^b
> key sequence to cause a
> > break whilst connected to any of my servers using
> the CS9000's, however they
> > DO respond when I attach direct using a vt100
> console!
>
> i was curious, so i took a quick peek at the cs9000
> docs that are
> online. i couldn't find anything except for the
> 'set telnet' command.
> there's a 'mapnl' option that looks interesting. a
> 'show telnet line
> 1' should show if it's on for line 1. i'd bet it
> shouldn't be. the
> 'mode' option probably should be off as well. i'm
> thinking that either
> the CR is being mapped to NL or a NL is being
> inserted or some other
> such manipulation is being done and therefore the
> sun isn't seeing the
> right sequence. at least, that's my theory - based
> on no real idea of
> what those options are supposed to do since they
> aren't documented
> well.
>
> > The servers I tested (Netra's) do respond to a #.
> sequence to cause them to
> > drop to the LOM prompt, and from there I can do a
> reset but it's "just not
> > right".

Since Netra's have no keyboard, they will not
accept the alternate break sequence of
~CNTLB.

I have tested the alternate break sequence with
our CLIM and the CS9000 on an ultra10 with
KEYBOARD_ABORT=alternate set in /etc/default/kbd and
it
works fine.


>
> i agree, but it's at least a fallback position.
>
> > Even though I haven't got the "alternate break
> sequence" for Sun's working
> > yet, could you look at introducing the 0.5 second
> delays in the sequence as,
> > as I read it, they are needed.
>
> yeah, i'm looking into it no matter what. just not
> sure how to deal
> with the code yet.
>
> Bryan
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

On Tue, 25 Jun 2002, corr0823 wrote:

> Since Netra's have no keyboard, they will not
> accept the alternate break sequence of
> ~CNTLB.

As I understand it, there existed a undocumented bug in the Netra OBP that
did not allow the alternate break to be set correctly. I am uncertain
which rev of the OBP patch fixed it, but all of our netra devices are
flashed with both the stdalone and system OBP flash files (patch 108620-04
and 108673-02 respectively), and all respond to the ~^B sequence. This has
been tested with a direct connection to serial B on another sun (E4500)
and through the conserver with the netra attached to a Digi PSCM32 console
device.

Try upgrading your OBP.

Remember though, the alternate break mapping isnt consulted until part way
through the boot sequence, so ~# should be used during memory test or very
early in the boot cycle.

-dolan