Created attachment 41952 [details] complete kernel configuration (first variant) First of all, I'm not completely sure if this is a bug or a misunderstanding on my end. Please correct me if I'm wrong. My 2.6.37-rc7 kernel fails to boot (freezes during timer setup) with specific combinations of the configuration parameters - CONFIG_CRASH_DUMP - CONFIG_PHYSICAL_START - CONFIG_RELOCATABLE which seem contradictory to me. Booting fails on my "real" machine and with qemu all the same; this is why I suspect a problem with configuration logic (or worse). Following tests conducted with attached .config and qemu (qemu-kvm-0.12.5), command line "make bzImage && qemu -kernel arch/x86/boot/bzImage". Failed boots yield the following output: [...] [ 0.003427] Enabling APIC mode: Flat. Using 1 I/O APICs [ 0.003427] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.003427] ..MP-BIOS bug: 8254 timer not connected to IO-APIC [ 0.003427] ...trying to set up timer (IRQ0) through the 8259A ... [ 0.003427] ..... (found apic 0 pin 2) ... [ 0.003427] ....... failed. [ 0.003427] ...trying to set up timer as Virtual Wire IRQ... [ 0.004000] ..... failed. [ 0.004000] ...trying to set up timer as ExtINT IRQ... [ 0.004000] ..... failed :(. [ 0.004000] Kernel panic - not syncing: IO-APIC + timer doesn't work! [...] First variant (boots ok): # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x1000000 # CONFIG_RELOCATABLE is not set Second variant (also works): CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x1000000 # CONFIG_RELOCATABLE is not set Third variant (fails): CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x1000000 CONFIG_RELOCATABLE=y Fourth variant (works again!): CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x100000 # <= one zero less CONFIG_RELOCATABLE=y Observations: - Timer setup always works if CONFIG_RELOCATABLE is off - If CONFIG_RELOCATABLE is on, timer setup fails with CONFIG_PHYSICAL_START value of 0x1000000 (six zeroes, default value) and succeeds with 0x100000 (five zeroes). - But CONFIG_RELOCATABLE help text states that if it is active, parameter CONFIG_PHYSICAL_START is ignored. This is obviously not the case because with physical start at default value booting fails, and changing it fixes booting. - Also note: If I use third variant and turn off crash dumps, CONFIG_PHYSICAL_START is no more available to edit and thus booting always fails. "make bzImage" resets any manual changes of CONFIG_PHYSICAL_START to the default (defunct?) value. N.B.: Variant four was inspired by my distro's kernel config (Ubuntu linux-image 2.6.35.24.28). I suspect a problem with the relocation configuration or code. Or am I mistaken?
I've recently encountered a related problem at a different site (approx. 15 machines ranging from 486DX2 to Pentium III, all booted per TFTP). Using the latest stable kernel (2.6.36.2) some of them failed to boot (two Pentium 75 and the 486, IIRC), they hung even before "Decompressing" stage. All others booted fine. Bisecting led me to commit ceefccc93932b920a8ec6f35f596db05202a12fe, where the default value for PHYSICAL_START was changed to 0x1000000. Since I compile for machines which can't cope with CONFIG_HIGHMEM, but enabling CONFIG_CRASH_DUMP needs it, I helped myself by removing PHYSICAL_START's dependency "if (EMBEDDED || CRASH_DUMP)" from arch/x86/Kconfig. Setting PHYSICAL_START to 0x100000 resolved the booting problems.
I've been unable to reproduce under qemu using the config provided + 3rd variant changes, or with my own config enabling all three options as described against v2.6.37-rc7 or -rc8. Are there any other qemu options your using? What kind of machine is your real machine? thanks -john
I don't use any other qemu options (though note that kvm is enabled); my real machine is a Lenovo Thinkpad X201. Just recompiled bzImage from a clean git tree v2.6.37-rc7 and provided config adjusted for variant three; still fails with the aforementioned output. If I unload kvm-intel before launching qemu, the output is the same, but already freezes after "Virtual Wire IRQ" line. But what troubles me most is not the timer error but the strange showing/hiding policy of CONFIG_PHYSICAL_START. For the case that it helps though I'll attach the complete traceback (with kvm). Without kvm, the output is the same but line 9 is the last.
Created attachment 42372 [details] v2.6.37-rc7 freeze in qemu with kvm_intel enabled
I've been experiencing what I assume is this bug since 2.6.36.2, which I can't boot. Can't boot 2.6.37, either. Intel DG33FBC mobo, 2.33GHz C2D Conroe. Switching back to 2.6.36.1 boots and works fine. I'm going to try manipulating CONFIG_PHYSICAL_START as mentioned to see if that helps as a work-around. I'm also seeing some mentions of switching off HPET to get past these bugs, so I'll try that also.
...nope. Can't boot > 2.6.31.1 kernels with or without HPET, with or without CONFIG_PHYSICAL_START modified.
I have the same issue on a 2.6.37 kernel with a configuration that worked perfectly under 2.6.36.2. Setting that CONFIG_PHYSICAL_START to 0x10000 solved my issue. Thanks.
Duplicated on second DG33FBC mainboard, same amount and type (G.SKILL) RAM, 3GHz Wolfdale C2D. Both boot failures are on the bare hardware. Fixing the boards' DSDT (originally two errors and one warning from iasl recompile of disassembly) and including it statically didn't change anything, but I was hoping...
--I just realized PHYSICAL_START was never changed; it was being overridden (overwritten) by the default set in arch/x86/Kconfig. Now that I've edited the default, and the kernel's really being built with CONFIG_PHYSICAL_START=0x100000, I can confirm this change allows 2.6.37 (2.6.36.2 unknown) to boot on both DG33FBCs.