Bug 433872 - softlockups at 1024p boot sequence
softlockups at 1024p boot sequence
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
ia64 Linux
low Severity low
: rc
: ---
Assigned To: George Beshers
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-21 16:24 EST by George Beshers
Modified: 2011-04-25 15:13 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-25 15:13:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
console log (30.20 KB, text/plain)
2008-02-21 16:24 EST, George Beshers
no flags Details

  None (edit)
Description George Beshers 2008-02-21 16:24:03 EST
Description of problem:

The point of this BZ is just the softlockups.  I have included
the boot sequence with the threshold at the default 10secs.


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

How reproducible:
  I always get at least 2, where, when, and other than cpu#0
  which processor varies some.

Steps to Reproduce:
1.  Simple boot of 5.1 with the 2.6.18-80 kernel.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 George Beshers 2008-02-21 16:24:03 EST
Created attachment 295558 [details]
console log
Comment 2 Luming Yu 2008-03-16 23:46:10 EDT
Is the softlockup related to staring autofs?
If the problem is harmless and un-avoidable due to the scale of the system,
should we suppress the message? 
Also I'd like to know if upstream behaves different?

Comment 3 Prarit Bhargava 2008-03-17 09:06:07 EDT
(In reply to comment #2)
> Is the softlockup related to staring autofs?
> If the problem is harmless and un-avoidable due to the scale of the system,
> should we suppress the message? 

No -- we shouldn't.  The issue is real and if it is a scaling issue it should be
resolved upstream and then backported into RHEL.

> Also I'd like to know if upstream behaves different?
> 
> 

Comment 4 George Beshers 2008-03-17 12:06:59 EDT
1.  I don't think it was specifically related to autofs; it was semi-random
    after init started except that there usually was one just before the
    login prompt.

2.  It is certainly related to the scale of the system --- I cut the number
    of cpus to 512 still w/ 4Tb of memory and the problem disappeared.  NOTE
    however that any area of the kernel that must be shared with all cpus
    would have been on a node associated with one of the 512 CPUs and not
    on the other 4 racks which would have had longer latency's.

3.  The machine got shipped before I could get to this, grumble grumble.
Comment 5 George Beshers 2011-04-25 15:13:24 EDT
Lack of customer interest.

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