Bug 204388
| Summary: | Kernel 42.0.2 hangs because timer not found | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Milan Kerslager <milan.kerslager> |
| Component: | kernel | Assignee: | Jason Baron <jbaron> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.4 | CC: | darford, jbaron, jburke, knoel |
| Target Milestone: | --- | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-03-01 17:13:23 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
Milan Kerslager
2006-08-28 20:10:18 UTC
Created attachment 135079 [details]
Output messages of succesfull 42.0.2 boot with apic=debug
The same kernel normally does not boot (without apic=debug).
So this is the x86 up kernel? Can you double check that the up x86 -42 kernel boots correctly? Also, for the 42.0.2 kernel that boots with apic=debug, can you try passing 'noapic'? thanks. I double checked that on this UP machine -42 kernel boots without a problem and -42.0.2 kernel does not boot (boots only with apic=debug or noapic parameter). Created attachment 136884 [details]
dmesg output - system boots with 2.6.9-42.EL
Created attachment 136885 [details]
dmesg output - system boots with 2.6.9-42.0.2.EL and "noapic" parameter
Created attachment 136886 [details]
dmesg output - system boots with 2.6.9-42.0.2.EL and "apic=debug" parameter
Created attachment 136888 [details]
dmidecode output
Created attachment 136889 [details]
lspci output
hmmm very strange. b/c none of the patches in -42.0.2 seem like they would cause the kernel not to boot like this. i'd like for us to iterate over the 10 or so patches in the kernel to determine which one is causing this problem...unfotunately i don't have time today to compile these 10 kernels for you...i could though send you the 10 pathces and you could try them yourself. otherwise, i'll get you the test kernels next week. thanks. I see patch difference in the SPEC file (Patch2213 Patch5057 Patch5058 Patch5059 Patch5060 Patch5061 Patch5062 Patch5063 Patch5064). I'm able to build -42 with every one patch selectively enabled. I'll post the results here next week. ok great! thanks. I'm unable to recompile kernel. This may be related to HW problem on my build system. I'l try tomorow. Soory for the delay. Babysitting is a little bit overloading problem :-) I created chroot build environment on another machine. Kernels are builded righ now so I expect to be able to reboot the server multiple times today or tomorow late evening. All subsequent kernels with only one of the delta patches between 42.EL and 42.0.2.EL kernels has been builded and all the kernels boots without timer problem. Only RH's kernel 42.0.2.EL fails to boot. All booted kernels are named 42.0.0.[0-9].EL and dmesg output are in the attachment. Kernel with .0 is without patches (so this is like 42.EL), 1 to 9 are kernels with only one patch enabled of the all 9 patches difference between 42.EL and 42.0.2.EL. Kernel with all the patches included (ie like 42.0.2.EL) has not been tested and is builded right now. I'll test it later. So I'm wondering where the problem is. Actual building environment is not RHEL4 system but fresh chroot up-to-date CentOS4 (ie RHEL4 rebuild) system because HW problem on my RHEL4 system. I'm able to create chroot build environment from RHEL4 packages as well if you wish to compare the resulting kernels. Please tell me if you want to test anything else. # cat /proc/version (problematic version) Linux version 2.6.9-42.0.2.EL (bhcompile.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) #1 Thu Aug 17 17:36:53 EDT 2006 Created attachment 137830 [details]
dmesg output from testing kernels
very strange. i'm really at a loss ot explain this....we just released 42.0.3 yesterday...i wonder if that works...this bug reminds me a lot of bz #203423 where a BIOS upgrad fixed the problem... BIOS upgrade fix the problem. There must be a hidden bug in the compiler or something similar. I have old BIOS saved so I'm able to do more tesing if you want to. This sounds similar to Bug 175784, most recently reported to have occurred on my AMD64 system after a BIOS upgrade. Are there some docs explaining how to boot with the noapic option if I poke around a bit? As the current kernel 2.6.9-42.0.8.EL has no problem and BIOS update fixed the problem I'm suggetsing to close this bug. I tryed but even I'm the submiter I'm not allowed to close this bug... The strange part is that my plain-rebuilded kernel worked but RH's kernel did not. So there may be hidden bug in the building system (maybe already fixed). (In reply to comment #17) > BIOS upgrade fix the problem. > There must be a hidden bug in the compiler or something similar. I have old BIOS > saved so I'm able to do more tesing if you want to. I'd like to try to reproduce this result (because it would make my system work under linux again.) Do you remember what Rev BIOS and kernel you tested? I thought I had the latest HP BIOS, but life could get so much better if I'm wrong about this. ok thanks Milan. I've going to close this. Darlene, if you are still seeing an issue please open a new bug. |