Re: [foxboro] WP51 Keyboard lockups

Russ,
        The following statement describes just one of the many strange
scenarios that we have seen since the introduction of the Motif
applications.  The keyboard going south but the mouse and cursor still
working is a common problem that we have and is related to the same scenario
that is described in the dreaded cursor lock up issue.  This statement
pulled from below is an accurate description of what we often see but
doesn't begin to include all of the weird things that happen on the 20 + B,
C, and D style sunboxes we have spread across our site. 

"This morning both machines had this problem, so we both went over there,
and indeed the keyboards were not working. We check to make certain that the
cable from the keyboard was plugged in (it was). Then we rebooted one of the
machines, and the keyboard came up working fine. All 3 times this has
happened we have been able to change the state of the numlock LED with the
numlock key, even though the rest of the keys were not being recognized by
the system. I've looked in the Sun logs, and found no problems."

You said in your note: "A system would not have run for 3 years....had a
couple of recent keyboard lockups...trackball still working and then come
back to life on their own....if it was the dreaded Cursor lockup issue."

That is absolutely wrong!  We have had the same thing happen.  We have had
times where the only thing we did to fix it was to restart the DM and then
the keyboard worked.  Other times that was unsuccessful and a reboot was the
only way to fix it.  It is obvious that it isn't a hardware problem because
rebooting the box ALWAYS fixes it for awhile. The 51 Series never had a
keyboard lockup until the new Motif Alarm Manager was used.  We actually had
an Area where they used a WP-30 CAD Alarm window to manage alarms and never
opened the Alarm Manager on the 51 Series stations.  Guess what, the
keyboards never locked up on those SUN boxes.  We have found that the
keyboard can go south 1st but we can still use the mouse.  Eventually the
mouse gets to the point where you can't pick anything and you have to hard
boot.

There is no doubt in my mind that all of these strange happenings are
related to the "dreaded Cursor lockup issue". The fact that so many users
are experiencing these same symptoms should be a dead giveaway!

Tom VandeWater

-----Original Message-----
From: Russ_Boulay/FOXBORO/SCD%siebeia@xxxxxxxxxxxx
[mailto:Russ_Boulay/FOXBORO/SCD%siebeia@xxxxxxxxxxxx]
Sent: Thursday, July 18, 2002 11:33 AM
To: foxboro@xxxxxxxxxxxxx; tom.vandewater@xxxxxxxxxxxxxx
Subject: RE: [foxboro] WP51 Keyboard lockups


Tom....as you can see from the original listing that started some 30 +
responses...this system does not have the symptoms that you speak of in the
HH workaround.

A system would not have run for 3 years....had a couple of recent keyboard
lockups...trackball still working and then come back to life on their
own....if it was the dreaded Cursor lockup issue.

The described problem did not set off "cursor lockup" issue in my mind...or
the 30 + listees that have responded. All well versed.
As the problem that was described...I would have troubleshot the problem as
hardware, which other listees were already offering info.

I understand your pain on the cursor lockup issue...


We have an IA system with 2 WP51B's located in a control room, which is not
the best environment of all the systems we have. This system has been in
place for about 3 years now. The WP's have GCIO's and anuciator keypads.
They also have the standard Sun keyboard, and plugged into that, they have
Foxboro trackballs.

3 times lately (twice on one machine, and once on the other), my co worker
has gone over o do something on these machines, and found that the keyboard
keystones were not getting to the system. The trackballs were still working
all 3 times. On the first occurrence of this problem, I went over a couple
of
days later & the keyboard _was_ working. This morning both machines had
this problem, so we both went over there, and indeed they keyboards were
not working. We check to make certain that they cable from the keyboard was
plugged in (it was). Then we rebooted one of the machines, and the keyboard
came up working fine. All 3 times this has happened we have been able to
change the state of the numlock LED with the numlock key, even though the
rest of the keys were not being recognized by the system. I've looked in
the Sun logs, and found no problems.

Has anyone else seen this problem? Any thoughts?

   -----Original Message-----
   From:   foxboro-bounce@xxxxxxxxxxxxx@CORP  On Behalf Of
             tom.vandewater@xxxxxxxxxxxxxx
   Sent:   Thursday, July 18, 2002 10:15 AM
   To:     foxboro@xxxxxxxxxxxxx
   Subject:  [foxboro] WP51 Keyboard lockups


   List,
      I have been watching all of the dialog fly about the WP51 keyboard
   and mouse lockups with a measure of disbelief.  When the new and
   improved
   Alarm Manager and Foxview were introduced so was this problem and is not
   specific to "B" style boxes.  It happens on "D" boxes also.
   "The problem is related to Motif applications such as Foxdraw, Foxview,
   Alarm Manager, and Alarm Configuration Tools on Solaris."
      The thing that amazes me is just like all of you other users out
   there, we had to find the problem ourselves and absolutely describe it
   to
   Foxboro before they told us that they already knew about it and had
   developed a workaround.  We chased our tails thinking that we had bad
   keyboard cables, keyboards or other hardware problems and when I hear
   all of
   you going through the same pain it really ticks me off.  The symptoms
   are so
   intermittent and unpredictable that it is difficult for anyone to
   describe.
   It leads most people to believe that it is a physical problem with the
   keyboard bus.
      The problem was known by Foxboro at the time of the release of the
   above mentioned applications or shortly thereafter.  They blame the
   problem
   on Solaris but they have provided both Solaris and Motif window
   applications
   as a solution and should be held accountable for that.  The problem has
   never been fixed and the workarounds described below in Helpful Hint 864
   only mask the real problem.   I know that there are many Foxboro people
   that
   subscribe to this list and have a hard time believing that none of them
   know
   about this VERY COMMON problem.  I was waiting to see if any of them
   would
   step up to the plate and pass the information on to struggling users and
   am
   greatly disappointed to see that it hasn't happened. There have been
   many
   CAR's written on this problem and the workaround below is the best that
   Foxboro has provided and is unnacceptable to us.  Although it does
   reduce
   the frequency of the lock-ups it doesn't fix the problem and thus
   reboots
   are still required!!!  The "Follow Mouse" window focus has caused much
   frustration among users that use more than a single window.
      So fellow users, quit spending time looking for faulty keyboard
   cable connections and start sending CAR's to Foxboro to voice your
   concerns
   about this ongoing problem.  It is our only recourse.  Don't accept the:
   "This CAR is now closed. " answer that we have been programmed to think
   is
   the "final answer"!

   Tom VandeWater
   Dow Corning Corp.
   Carrollton, KY USA

   HH#:  HH864
                                       IA INFO:  kjb9703a
                                          File:  System
                                       Release:  All
                                          Date:  Dec. 18, 1997
   Subject:  Cursor Lockup
    Source:  SD&E
                                CURSOR LOCKUP
   There are two workarounds that solve the cursor lockup issue.  One is to
   vi
   the .Xdefaults file and the other to change the workspace property for
   cursor input.

   It is recommended that the .Xdefaults be done first. This has either
   resolved or has greatly reduced the occurrence of the cursor lockup
   problem.

   If the .Xdefaults did not solve the problem entirely than do the
   workspace
   properties workaround. Be sure to verify that the .Xdefaults was done
   correctly.  We have had cases were the upper and lower case letters and
   underscores were not done correctly.

                                CURSOR LOCKUP
   Two problem have been discovered which can cause the OpenLook window
   manager to " hang" .  When the window manager is hung,  all mouse clicks
   and keyboard inputs are ignored until the offending application is
   killed
   or the machine is rebooted.

   The problem is related to Motif applications such as Foxdraw,  Foxview
   ,Alarm Manager, and  Alarm Configuration Tools on Solaris.

     Problem #1 workaround

   The workaround for this problem is to edit the file " /.Xdefaults

   1. Open a VT100 window.
   2. Change directory to the root directory .       cd /
   3. Edit the /.Xdefaults file to include (or modify) the following two
   lines
      exactly as they appear here (be careful about the underscores and
      upper/lower case letters).  (Note: the "." character makes this file
      invisible to an "ls" command ).
   4. vi  .Xdefaults
   5. Make edits such that the following lines appear exactly as they do
      below:
         olwm.Modifier.WMGrab:
         olwm.Modifier.Ignore:   mod5,Alt,Num_Lock,Mode_switch,Lock
   6. After completing the edits, reboot  the workstation.

     Problem #2 workaround

   The second defect is related to handling of rapid mouse clicks by
   the window manager and can be avoided entirely by setting the window
   focus
   property to "move pointer" as follows:

   1.  From the Workspace menu (click the right mouse button with the mouse
   cursor on the blue "background" screen), and  select "properties...".

   2.  On the resulting "Workspace Properties" dialog, click on the
   "Category"
   icon and select "Miscellaneous" from the drop-down menu.

   3.  On the "Miscellaneous" page, under "Set Active Window" , click the
   "Move Pointer" button.

   4.  Select the "Apply" button at the bottom of the dialog box to apply
   the change.

   5.  Click on the "pushpin" in the upper left corner of the dialog to
   dismiss the dialog.

   This will put the workstation in the "follow mouse" mode. In this
   mode,keyboard focus belongs to the window which contains the mouse
   cursor.

   Note that if the mouse cursor is accidentally moved,keyboard input can
   inadvertently go to another window.


   ________________________________________________________________________
   This email has been scanned for all viruses by the MessageLabs SkyScan
   service. For more information on a proactive anti-virus service working
   around the clock, around the globe, visit http://www.messagelabs.com
   ________________________________________________________________________


   _______________________________________________________________________
   This mailing list is neither sponsored nor endorsed by Invensys Process
   Systems (formerly The Foxboro Company). Use the info you obtain here at
   your own risks. Read http://www.thecassandraproject.org/disclaimer.html

   foxboro mailing list:             http://www.freelists.org/list/foxboro
   to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
   to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: