Bug 126180 - Updated kernel (2.6.6-1.435.x86_64) unstable
Summary: Updated kernel (2.6.6-1.435.x86_64) unstable
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 2
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-06-17 07:01 UTC by Lamont Peterson
Modified: 2015-01-04 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-16 05:30:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Lamont Peterson 2004-06-17 07:01:14 UTC
Description of problem:
Several hard lockups occured after updating the kernel.

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

How reproducible:

Steps to Reproduce:
1.  Install kernel-(smp-)?2.6.6-1.435.x86_64.rpm
Actual results:
After 5-15 minutes use, the system would grind down (in just 10-30
seconds) to a complete hardlocked state.  Running apps would stop
responding one by one for a bit, but the whole system would be gone
before it could work through all of the running apps (never more than
5-6 running at any time I was doing this though).

The problem occured using SMP and UP kernels.

I did not try the 2.6.6-1.427 kernels.

Booting into the 2.6.5-1.358smp kernel (shipped w/FC2)

Expected results:
System should keep running, or at least be sufficiently responsive to
allow for some kind of diagnosis.

Additional info:
I was trying to rip audio CDs to FLAC at the time this was happening,
but latter determined that the lockups would still occur, without ever
starting any such processes.

My system is:
2 x Opterson 242 (1.6GHz)
1 x Tyan K8W (S2875) Motherboard
2 x 512MB PC2700 Registered ECC DIMMs (from Crucial)
1 x ATI Radeon 9800Pro 128MB (using vesa X driver)
1 x Seagate Barracuda 7200RPM 160GB SATA Hard Drive (ST3160023AS)
1 x Pioneer slot-loading DVD Drive (used for the CD ripping)
1 x Plextor PleXWritter CD-R/RW Drive (16/10/40A)
1 x LS-120 Floppy Drive

FC2 installed from DVD ISO:

# fdisk -l
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14       11624    93265357+  8e  Linux LVM
/dev/sda4           11625       19457    62918572+   7  HPFS/NTFS

Uses these LVs:
# ls /dev/vg0/
download  home  opt  root  swap  tmp  usr  var  varlog

No third party RPMs are installed; only FC2 packages.  All available
updates are installed (all packages --checksig OK before installation).

Comment 1 Lamont Peterson 2004-06-28 19:16:00 UTC
This text from my original post: 
Booting into the 2.6.5-1.358smp kernel (shipped w/FC2) 
...should continue on to include: 
fixed the problem and the ststem has been rock solid since. 

Comment 2 Lamont Peterson 2004-07-12 07:32:10 UTC
The newer 2.6.6-1.435.2.3smp kernel also exhibits the same instability
problems on AMD64, though it does take just a little bit longer to
manifest than for the 2.6.6-1.435smp kernel.  There are still no log
messages that seem to indicate anything related, but I need to spend
more time to finish digging through them to be sure.

Comment 3 Tim Fletcher 2004-08-23 13:36:28 UTC
Just to add to this we have seen this exact same effect on 3 Dual
opteron servers running 2.6.6-1.435.2.3smp works without problems,
kernel-smp-2.6.7-1.494.2.2 hard locks up. the ammount of time varies
from about 15 minutes to 12 hours. The load on the machine seems to
make little difference and there is no debugging information on the
console, local syslog logs or remote syslog logs. 

We have Tyan 2882 motherboards with 2Gb of ECC RAM (no errors
reported) and Opteron 242s. There is a 3ware 7000-series ATA-RAID
controller card in the machines as well.

Should I open this as a seperate bug or leave it here?

Comment 4 Lamont Peterson 2004-09-08 01:33:15 UTC
For me, the 2.6.7 & 2.6.8 kernels run flawlessly.  The problem has
disappeared, entirely.  I only experienced problems with the whole
2.6.6 line of kernel packages.

I have gone back and tried to find something that was common that I
could nail down as a cause (like, "when I do X if Y, Z, W & V are like
thus, then it crashes), without any success.

Comment 5 Tim Fletcher 2004-09-08 22:57:14 UTC
It's helpful to know that the problem has gone (in same ways at
least), I feel more confident to update to the 521 kernel now.

Comment 6 Need Real Name 2004-09-11 06:25:30 UTC
I'm still having hard lockups with 2.6.8-1.521. The system is the

1x Athlon64 3000+ CPU (754 pin)
1x VIA k8vm800m MicroATX motherboard
1x Nvidia GF4-MX 440 AGP 8x GPU (using the nv open-source driver)
2x PC3200 512MB RAM (1GB total)
1x Seagate 120GB SATA HD
1x Seagage 40GB  PATA HD
1x SONY DRU-700a DVD writer

FC2 installed from CD-ROM and updated via yum.

The system lock up hard randomly after 5-120 minutes, irrespective of
the load and component temperature. No log is left behind, total
mystery, very frustrating.

The system is solid so far (uptime of a few hours) under WinXP SP2 and
Linux FC2 for Athlon32, same level of patching.

Comment 7 Dave Jones 2004-11-27 20:19:03 UTC
mass update for old bugs:

Is this still a problem with the 2.6.9 based update kernel ?

Comment 8 Lamont Peterson 2004-11-28 10:30:30 UTC
The 2.6.8 & 2.6.9 kernels are all completly stable.  No problems that 
I can see.  My system still has all the same hardware as I listed at 
the top of this bug. 

Comment 9 Dave Jones 2005-04-16 05:30:57 UTC
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

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