Bug 433872
| Summary: | softlockups at 1024p boot sequence | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | George Beshers <gbeshers> | ||||
| Component: | kernel | Assignee: | George Beshers <gbeshers> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 5.2 | CC: | dwa, dzickus, jh, jlim, luyu, martinez, prarit, tee | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | ia64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-04-25 19:13:24 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
George Beshers
2008-02-21 21:24:03 UTC
Created attachment 295558 [details]
console log
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? (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? > >
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.
Lack of customer interest. |