Description of problem: RHEL 5.4 x86 edit the boot kernel " acpi=off" in default mode & use Intel Westmere-EP B0/B1 6-cores processors, SUT will halt (80 debug port shows "04") How reproducible: Steps to Reproduce: 1. Install Intel Westmere-EP B0/B1 6-Core processors 2. Boot on SUT under RHEL 5.4 x86 3. Edit boot kernel command "acpi=off" 4. System will halt. Actual results: System halt (80 debug port shows "04") Expected results: system should boot up ok. Additional info: 1. XEN mode is without this problem. 2. In default mode, if using Intel Westmere-EP B0/B1 4-core processors, it can also boot up okay.
When is the system halt? Which processor exactly - Inel Xeon Processor {X,W,L,E}<number> Could you provide more details - e.g. boot log, /var/log/messages, dmesg
Created attachment 402455 [details] attach dmesg & /var/log/messages files Here is the requested log files. Please help. Thanks!
(In reply to comment #1) > When is the system halt? > Which processor exactly - Inel Xeon Processor {X,W,L,E}<number> > Could you provide more details - e.g. boot log, /var/log/messages, dmesg (In reply to comment #1) > When is the system halt? After we issue command acpi=off and reboot > Which processor exactly - Inel Xeon Processor {X,W,L,E}<number> Intel Westmere-EP 3.46G 12M B0 130W 6.4GT/s 4Cores X5677 (AT80614005145AB Q3V5/) > Could you provide more details - e.g. boot log, /var/log/messages, dmesg Already provided the log files on 3/25
1. Well, this bug is filed against apmd but dmesg contains: apm: BIOS not found. Therefore I thing that you should replace apm usage by acpi. 2. I don't understand there is "Install Intel Westmere-EP B0/B1 6-Core processors" in the description of bug but the processor specification describes 4-cores processor. What is wrong?
1. Intel Westmere has 4-core type and 6-core type, but only 6-core types cannot issue issue apm=off in normal mode, 4-core type is without this issue. 2. In XEN mode, no matter use 4-core or 6-core type and issue apm=off are okay, system can boot up ok.
(In reply to comment #4) > 1. Well, this bug is filed against apmd but dmesg contains: > apm: BIOS not found. > Therefore I thing that you should replace apm usage by acpi. sorry for the typo, we issue acpi=off, not apm=off as titled shown. can you give comments on this why issue acpi=off showns bios not found? > 2. I don't understand there is "Install Intel Westmere-EP B0/B1 6-Core > processors" in the description of bug but the processor specification describes > 4-cores processor. What is wrong?
You use acpi=off and dmesg says apm: BIOS not found (apm on? but ...). This could be something in bios or kernel. Please, could you clarify a couple of things: 1. Usage 4-cores physical CPU works fine. Usage 6-cores physical CPU generates described issue. Is it right? 2. Could you explain what does it mean: 80 debug port shows "04"? What about BIOS issue? 3. What problem do you try to solve with apci=off? I've got info acpi=off can lead to system freezes, upstream do not guarantee stable work of the system with acpi=off. acpi=off is a workaround for some problems, and not a recommended option.
(In reply to comment #7) > You use acpi=off and dmesg says apm: BIOS not found (apm on? but ...). This > could be something in bios or kernel. Please, could you clarify a couple of > things: > 1. Usage 4-cores physical CPU works fine. Usage 6-cores physical CPU generates > described issue. Is it right? Yes > 2. Could you explain what does it mean: 80 debug port shows "04"? What about > BIOS issue? There is a kind debug port card that can output system behavior. Different number means different behavior but "04" is not a code reported by BIOS. > 3. What problem do you try to solve with apci=off? I've got info acpi=off can > lead to system freezes, upstream do not guarantee stable work of the system > with acpi=off. acpi=off is a workaround for some problems, and not a > recommended option. We've been assuming that the correct system behavior should have system booted up ok when issuing acpi=off. We have been using this command for system test, so according to your comments, issue this kind of command for the test is not recommended?
still one question and one remark: - which kernel version do you use? - RHEL 5.5 is currently released ...
(In reply to comment #9) > still one question and one remark: > - which kernel version do you use? RHEL 5.4 : 2.6.18-164.el5 > - RHEL 5.5 is currently released ... We also tested RHEL 5.5, result remains the same. Kernel version as follows: RHEL 5.5 : 2.6.18-186.el5
I recently inherited this open problem report. Since it's been over 2 years since there has been any update on this problem, I'd like to check if this problem is still reproducible with RHEL 5.9?
Given how long this problem has gone unresolved, it's relatively low severity, and the lifecycle stage that RHEL 5 is currently in, the problem reported will not be fixed in RHEL 5. -Lenny.