Latest update 2.6.9-42.0.2.EL does not boot because times is not found. When trying to boot with suggested apic=debug, kernel boot normally. U4 kernel kernel-2.6.9-42.EL is booting ok too. This is ASUS A8N-E board with Athlon 64 3000+ (32 bit kernel). The latest messages on the console are (sorry, this has been hand-writed): ENABLING IO-APIC IRQs ..TIMER: vector 0x31 pin1=2 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A... failed. ...trying to set up timer as Virtual Wire IRQ.. failed ...trying to set up timer as ExtINT IRQ.. failed :(. Kernel Panic - not syncing: IO-APIC timer doesn't work! Boot with apic=debug and send report then noapic # lspci 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Ethernet controller: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] 01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE] 05:06.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02) 05:07.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
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.