Conference csc32::consolemanager

Tim,

  This restriction only applies if your system is running OSF/1. This
  is not being worked, we went as far as we could to get this changed
  without success. If you want to do this and are running OSF/1 then
  I suggest you add your weight to every body elses and raise this with
  USG Product Management and/or the folks who create the hardware
  console interfaces.

Cheers,
Phil

    
    
    Yeah... where to I sign up? I want my (VMS style) ^P under OSF...
    
    Even worse, I just MOM loaded a device diagnostic, but rebooting
    OSF fails (Bootstrap address collision, image loading aborted).
    No amount of P00>>> typing I could come up with resolved this.
    Had to walk to the computer room to hit the reboot button :-(.
    
    (I could do with a controller that is addressed via a terminal line
    and has a bank of remote trigger switches: On, Off, Pulse. Connect
    those to front control panels for a bank of Sables, and drive from
    the comfort of my cube. Now where's my soldering iron again? :-).
    
    fwiw,
    	Hein.
    
    

1. Send a message to Neil Davies, STAR::NDAVIES, asking when this problem
will be fixed.  (He will ask me, and I'll say, "beats me, I haven't heard
anything...")

If that fails, send a note to Don Harbert explaining that you have some
Sable cluster customers who are going to be very unhappy if this isn't fixed.

There is a formal process for communicating with Neil; its called a CLD against
Digital UNIX.  Neil manages several groups, and the one that is most visible
is the unix problem management group.

2. Go to Radio Shack and buy the X-10 power controllers and the computer
interface option and power cycle the systems when you need to restart them.
This was the solution recommended by the engineers involved, from what I
can tell.

3. Sell VMS; their heads are screwed on pretty much in the right direction
and they know that they get paid by the customer.

This ranks up there in the stupid qar catagory, along with the two and half
year old qar about the fact that time ends Jan 1, 2000.

I talked to the firmware engineering manager (Kevin Peterson) for the sable
yesterday. Like you mentioned earlier, it's out of his hands and needs to be
addressed in the operating system. He pointed me to a fellow by the name of
Richard Freiss. I tried calling him but no luck.

Kevin went on to say that a EISA bus option board was planned to come out
called PCRSM. He went on to say that sending a signal to this card will be
the same has hitting the halt button.

Are you folks in console manager land aware of this thing? If so, will it
be built into your product? If not, that's a pain. Kevin did mention that
Richard Freiss may have more information on this. I'll try to find out more
and post it here.

Tim

Tim,

  We are aware of the PCRSM product and have been since FT Training
  for PCM V1.5 18 Months ago, we have yet to see product although we
  were promised one by the PCRSM team at the time.

  The bottom line is that we would have loved to support the PCRSM
  product, but unless we are given the opportunity to aquire the hardware
  our hands are tied.

Cheers,
Phil

    
    If customers want to have UNIX and remote halt they can
    buy HP9000/8xx and plug its' console to PCM ;-).
    CTRL-A of B works as well as CTRL-P on VMS system.
    
    I belive Digital Unix people should know about this problem
    already. Other problem has been how to setup permanently
    syslogd and others to write events to /dev/console.
    I haven't tried this with V3.2 nut with V3.0 after someone
    logged in on /dev/console there wasn't new messages anymore.
    There is not very much you can use PCM for when you manage
    Digital Unix system if you don't have someone at remote site
    to press halt button
    
    -Olli
    
     

    
    I know I'm a little late to this one but could someone explain the root
    of the problem? Does the O/S have to watch for the halt button to be
    pressed and then halt itself? Is this why the operating system has to
    "support" crtl-P? 
    
    I find this absolutely amazing that theres no way to remotely halt an
    OSF/1 system. I thought the requirement for remote managment of boxes
    was something clearly understood and accepted.
    
    I'm an internal user who really needs this ability on the AlphaServer
    1000, 2000 and 2100. We manage systems from hundreds, if not thousands,
    of miles away and having to find someone to hit the halt button locally
    is a real pain!
    
    Thanks,
    Ray
    
    

    This is more a function of the console subsystem so it's more firmware
    related I believe. I feel for you but this is the wrong place to ask.
    We need to push on the OSF and hardware groups for a solution. Send
    mail to Rae Collier at MUZICK::KUNG. She is the PCM product manager and
    see if she has made any progress or has any additonal info.
    
    Regards,
       Dan

The console/PALcode firmware include support for halting the CPU for _ALL_
VAX and Alpha systems.

The laser/tlaser and other systems that I'm not sure of use a DUART with the
console input fed to both halves and then have a state machine in one of their
PALs or GAs that pulls the characters out of one of the UARTs and matches
against ^P.  If there is a match, then the "halt" line to the CPU is asserted.
This triggers an interrupt into the PALcode which then dispatches to the
user requested halt action, including "halting" at the >>> prompt.  Of course,
the CPU doesn't actually halt, its actually looping waiting on a character
to be typed which is received thru the other half of the DUART.

On the systems that don't implement the DUART/state machine to assert the
halt line, the console (conditionally) scans for ^P and when seen jumps to
the console prompt logic.  For this to work, it is necessary to use the
console callback for reading and writing to the console port(s).  UNIX does
not use the console callbacks and instead acesses the console port directly.
In my opinion, when the problem with this approach was pointed out, they
started on the list of excuses for not using the console callback:
	1) the console callback is too slow
	2) the console firmware doesn't always work
	3) the console firmware doesn't support modem control
	4) the console firmware doesn't support dialup security
and my favorite
	5) the unix console driver can't conditionally scan for ^P because
	   it would be incompatible with the OSF code, too much overhead,
	   impossible to do on just the console port, etc.
and finally
	6) it doesn't work 100% of the time so there isn't any reason to do it
	   at all.
I got a commitment from a couple of UNIX engineering managers that this would
be resolved before truclusters shipped, but even they weren't able to get
the engineers and managers involved with this issue to just match what VMS
has done from day one.  Clearly the PM&D concept is something that isn't
embraced by some important parts of engineering: "I don't care what customers
want, I'm the unix hacker and they will like whatever I decide to give them."

Supposedly the Tlaser follow-on will have a real service processor and maybe
this will influence a real inexpensive service processor architecture that
will hit all platforms, but that depends on DEC surviving and I feel that
there are a lot of minor points like this that (from marketing to sales model
to service to product engineering) that are driving customers away.

    Excellent info! Thanks for posting that!
    
    Regards,
       Dan