RH7.3 keyborad lock-up

DISCUSSION Peter 3 participants 3 messages Aug 9, 2002

lore

Share & tools

lore

Peter

author

2002-08-09 07:13 UTC #0 lore raw

Thanks Riley

Quoted 8 lines · pfheiss@philonline said:

.....
When I recently upgraded to RH7.3 I got total keyboard locks when trying to run xscreensaver, tuxracer and chromium and may be others, necessitating dirty reboot by the reset botton. >
.....
I, therefore, conclude that the problem is somewhere whithin with RH7.3 and possibly not with my video card which is SiS 630 since it works fine in RH7.1. >

Quoted 4 lines · [email protected] said:

2. For each program where those versions are different, please see if you can install a copy of the same version used under RH 7.3 on your RH 7.1 based system. If you can, please determine if it is stable under 7.1 or if it also fails there.

I tried it with xscreensaver. The version in RH7.1 is/was 3.29-3.i386.rpm and the one of RH7.3 is 3.33-4.i386.rpm. It upgraded flawlessly and seems to be stable. No hang no keyboard lock-up which I could induce in RH7.3 by clicking on Blank Screen Now in xscreensaver-demo or when the display at set time would change.

If I recall correctly I tried to install the xsceensaver of RH7.1 in Rh7.3 and it would lock-up as well, however, I am not so sure anymore if it did install at all.

So the problem does not semm to be with the particular programs it must be most likely within the kernel of RH7.3.

Regards

Signature · 6 lines

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Riley Williams

2002-08-09 08:02 UTC #1 lore raw

Hi Peter.

Quoted 19 lines

Quoted 4 lines
Quoted 4 lines
When I recently upgraded to RH7.3 I got total keyboard locks when trying to run xscreensaver, tuxracer and chromium and may be others, necessitating dirty reboot by the reset botton. >
Quoted 8 lines
Quoted 3 lines
I, therefore, conclude that the problem is somewhere whithin with RH7.3 and possibly not with my video card which is SiS 630 since it works fine in RH7.1. >
2. For each program where those versions are different, please see if you can install a copy of the same version used under RH 7.3 on your RH 7.1 based system. If you can, please determine if it is stable under 7.1 or if it also fails there.
I tried it with xscreensaver. The version in RH7.1 is/was 3.29-3.i386.rpm and the one of RH7.3 is 3.33-4.i386.rpm. It upgraded flawlessly and seems to be stable. No hang no keyboard lock-up which I could induce in RH7.3 by clicking on Blank Screen Now in xscreensaver-demo or when the display at set time would change.

Quoted 6 lines

If I recall correctly I tried to install the xsceensaver of RH7.1 in Rh7.3 and it would lock-up as well, however, I am not so sure anymore if it did install at all.
So the problem does not semm to be with the particular programs it must be most likely within the kernel of RH7.3.

There are several possible areas where the problem could be...

1. In the kernel itself, as you state.

2. In the libc or glibc library.

3. In one of the other libraries used by the said program.

4. In the program itself.

Basically, to locate the actual problem, we need to confirm the precice differences between a working configuration and one that isn't. Also, where there are two or more programs that can be identified as causing a specific problem in one configuration but not in another, we can be fairly sure that the problem is in something that is common to all of those programs.

For this reason, can you first confirm that you can upgrade tuxracer and chromium to the versions supplied with 7.3 without having this problem turn up on you?

When you have done so, can you run ldd on each of the resulting programs and post the results here please? That will give us a list of libraries used by each of those programs. The important ones are the libraries that are common to all three programs, and the libraries that are not common to all three can be ignored. You will find that the glibc library is common to every program on your system, but specific programs use specific other libraries as well. Always check the other libraries first as a problem in glibc would normally show itself right across the system.

The next stage would be to check which versions of those libraries are installed on a 7.3 system, and then upgrade the libraries one at a time until either the problem recurs or you have the same versions of all of the libraries installed on your 7.1 system.

If the problem recurs when any one of the libraries is installed, then the problem is in that library. Only if one succeeds in installing all of the libraries without the problem occurring can one definitely state that the problem is in the kernel.

Best wishes from Riley.

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Ray Olszewski

2002-08-09 14:10 UTC #2 lore raw

See below.

Quoted 12 lines · Riley Williams

[...]
Quoted 2 lines
So the problem does not semm to be with the particular programs it must be most likely within the kernel of RH7.3.
There are several possible areas where the problem could be...
1. In the kernel itself, as you state.
2. In the libc or glibc library.
3. In one of the other libraries used by the said program.

Quoted 8 lines

4. In the program itself.
Basically, to locate the actual problem, we need to confirm the precice differences between a working configuration and one that isn't. Also, where there are two or more programs that can be identified as causing a specific problem in one configuration but not in another, we can be fairly sure that the problem is in something that is common to all of those programs.

May I add one suggestion to the (otherwise) excellent list you provided? The problem might be in X11, which surely changed version between RH 7.1 and 7.3. This source of the problem would, in fact, be my first *guess*. It would be worth knowing --

A. If Peter sees the RH 7.3 failure with -ANY- command-line app. (Including the details if the answer is yes.)

B. What video card and X server are involved, and what versions are in the "before" and "after" serups.

C. When the keyboard locks, is the system still running or not? For example, can you ssh or telnet to it? Can you ping it? I assume the keyboard problem prevents your switching to a vt, but if you have (say) "top" running in an xterm, does it continue to run and show sensible process behavior? Any one of these tests should do; I list several because I can't remember is this system is on a LAN, or what services it might be running if it is. If you can do nothing else, set up a background job that writes the time to a file every minute, then after you reboot, see when it stopped writing.

Also, I am not a Red Hat user, but RH does have a system for online updates to correct, at least, security holes and other critical bugs. Peter, have you applied all the updates and patches RH has released for 7.3? Specifically, the ones listed in the directory at ftp://ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386/ . From the package names, I'd guess these are mostly security updates ... but there is a set of glibc updates here. And one for libstdc++.

--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [email protected]
-------------------------------------------------------------------------------