Bug 128081 - hwbrowser crashes under kernel-2.4.22-2197.nptlsmp
hwbrowser crashes under kernel-2.4.22-2197.nptlsmp
Product: Fedora
Classification: Fedora
Component: hwbrowser (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Nils Philippsen
Depends On:
  Show dependency treegraph
Reported: 2004-07-17 02:28 EDT by Gary Bastin
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 2199.nptlsmp
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-11 12:33:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gary Bastin 2004-07-17 02:28:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

Description of problem:
If start hwbrowser from Redhat shortcut menu in gnome, or from
commandline in terminal mode when logged in as root, system crashes. 

Once system crashes, unable to telnet in from outside, to kill
process(es).  Telnet connection coming in from outside drops if
already connected.  Unable to bring up menu or another terminal
session. Keyboard locks up. Have to power system down and re-boot to
get system running again.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Boot kernel-2.4.22-1.2197.nptlsmp
2. Start hwbrowse from Redhat shortcut menu
3. enter root password
4. message that this may take a while comes up
5. part of hwbrowse GUI comes up (not all) and system crashes
6. system never "wakes back up"

Actual Results:  Computer is locked up.  Keyboard not functional to
KVM switch on scoll-lock key sequence.  Can manually switch kvm switch
to another computer and attempt to telnet in to kill process(es), but
cannot connect.  Have to power down and re-boot crashed Linux system.

Expected Results:  hwbrowse should show hardware configuration on
system whether booting in 2.4.22-1.2197.nptlsmp or 2.4.22-1.2115
without crashing system

Additional info:

hwbrowse works fine if boot in 2.4.22-1.2115.nptlsmp and no lockup occurs

Motherboard: Asus P4P800E-Deluxe, 
Processor: 3.2 GHz P4 800FSB
RAM: 1 Gig Kingston DDR, 
Video: Nvidia GeForce5200 128Mb
HD: 80 Gig WD IDE
CDROM: Mitsumi CD-RW
Comment 1 Gary Bastin 2004-07-29 03:49:27 EDT
hwbrowser works fine in 2.4.22-1.2197.nptl and doesn't crash.  Looks
like an SMP problem.
Comment 2 Gary Bastin 2004-08-11 12:33:28 EDT
There were a total of three problems noted running the
2.4.22-1.2197.nptlsmp kernel:

1. hwbrowser would crash system
2. bringing up add / delete applications screen would crash system
3. starting a powerdown would properly do all the steps until actually
powering down the computer.  (You had to manually hit the power button
to actually power down the computer.)

Note: All three problem area functions mentioned here functioned fine
with the 2.4.22-1.2197.nptl kernel.

Note:  I made a typo in entering the hardware inventory information
listed previously, as my motherboard is actually an ASUS
P4C800E-Deluxe, not an ASUS P4P800E-Deluxe.  I have also flashed the
BIOS on the ASUS motherboard to update it to the latest ASUS BIOS in
place of the earlier BIOS dated February 2004, thinking this might fix
the crashing with the SMP kernel. Doing this update didn't have any
impact on stopping the crashes with 2197.nptlsmp kernel.

Note: Tried the new 2199.nptlsmp kernel, and hwbrowser and add/delete
applications screens do not crash system.  All the problems noted
above with 2197.nptlsmp kernel appear to have been fixed by installing
the new 2199.nptlsmp kernel.  Two processors are now showing correctly
when examining the processor info file.  No problems noted with new
2199.nptlsmp kernel.

Possible Problem Explanation: There are a total of 8 USB ports on this
PC, running off different USB interface chips. The changes reported as
having been made to the USB code in this latest 2199 kernel may very
well have fixed a modprobe error in USB operation that could have been
causing the 2197 SMP kernel crashes.  This also could explain the
total lockup of the keyboard, and the failure of a KVM switch from
being able to switch away from the locked-up P4 system through the
keyboard hotkey sequence, as without a clock there is no way for the
keyboard/KVM combo to operate through the keyboard hotkey sequence.

Note You need to log in before you can comment on or make changes to this bug.