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
>  


-- No attachments (even text) are allowed --
-- Type: application/ms-tnef


 
 
_______________________________________________________________________
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: