13

Hardware: Dell Dimension 4500S : i845G, Pentium 4, stock + 2GB RAM and latest (circa 2002) BIOS update.

I've been building a Linux system from source, so far it's LFS 7.0 by the book. The first kernel I built works fine, but has alot of fluff and bloat, so I'm now optimizing the kernel for my target hardware (see above).

My latest configuration attempt, and several trial and error variations, have been continually hanging at the printk "Switching to clocksource tsc" statement. My "good" kernel never has had an issue...this is version 3.1.0 btw. Both are being built from the same source tree, no patches, make mrproper, make menuconfig, etc, so obviously I'm just missing some key CONFIG_XXX flag.

I've been staring at this problem for over a day now, and I've built the kernel who knows how many times, but to no avail.

One thing that I find interesting is with the good kernel I get:

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

also, it might be useful to know....

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc acpi_pm

I'v attempted the build configuration with various options, but at this point I can't remember any specifics so please don't ask. From my searching I've found and tested several kernel parameters, like clocksource=pit and notsc, but all of these fail as well. Again, I wish I had written down every thing I've tried so far, hindsight...

Most of the forum examples are for 2.x kernels and were solved with some variation of the boot options, but my good kernel uses only root=/dev/sdaX ro. So I know I'm golden with this hardware and kernel 3.1.0 combination if I can find the right build configuration.

Also, most of the people out there that have posted a similar issue say that after a few minutes the system will continue loading and everything is peachy. I've let it idle long enough to cook supper and it still hasn't resumed loading.

I'm hoping one of you guru's will read this and say "hey yeah I just set CONFIG_XXX=y on my P4 dinosaur and it worked great." :)

Let me know what you need me to try or check, I'll be happy to post the results.

8
  • @tripleee Where can I view that information...the reason behind a close vote? Jan 16, 2012 at 8:03
  • Maybe you can't, your reputation may not suffice. Anyhow, since this isn't programming-related, it makes sense to move, but all it takes are a few more close votes. I'll add mine as well.
    – tripleee
    Jan 16, 2012 at 8:09
  • I am facing similar issues with the new kernel with Pentium 4. Everything works if I disable hyperthreading. Spent two nights debugging, not sure about details yet.
    – choroba
    Jan 16, 2012 at 13:02
  • @choroba noht doesn't do it for me. Let me know if you have other ideas. Jan 16, 2012 at 22:01
  • 1
    In fact, I had to switch off ht at BIOS level, or specify acpi=off.
    – choroba
    Jan 16, 2012 at 22:32

4 Answers 4

8

From a quick search this problem seems to have quite many possible reasons, and seems to point to the fact that your new kernel's default for clock-source is wrong for your motherboard.

One advice that worked for some was to use clocksource=hpet or clocksource=acpi_pm.

In another thread, someone fixed this with clocksource=jiffies, another advised to try noapic or nolapic, another to turn acpi off in the BIOS, and still another blamed the Synaptics touchpad and fixed his problem by deleting Xorg.conf.

One kernel builder fixed his problem by recompiling initrd without fbcondecor.

Hope this helps, as it seems that this problem can have many causes.

10
  • Thank you for your answer, however I'm seeking kernel build configuration options that will cause (or prevent) the hang at boot time that I am observing, not a work around. I have tried all of the relavent boot parameters (clocksource=, no*, etc.) that were noted in various forum threads, with no effect. I did these expriments in an attempt to narrow down my real issue. I already have a kernel that boots perfectly without any special parameters (aside from root= and ro) built from the same source tree, but this kernel contains more things that I don't need, than those that I do... Jan 23, 2012 at 10:10
  • ...except that one key CONFIG_ flag that will solve my issue. Jan 23, 2012 at 10:12
  • Is it possible that your problem is that you have turned off too many kernel options ?
    – harrymc
    Jan 23, 2012 at 10:13
  • Precisely. :) That is the answer I'm looking for, what have I disabled that is actually needed. I've done this several times with no change in the outcome. Jan 23, 2012 at 10:18
  • I can't help you with one magic word. It seems like your current clocksource is acpi_pm, but you will need to delve into the kernel's sources to find out with kernel config you loused up. The other option is to return to the configuration that worked and turn off options in increments so as to locate the problem. To "cheer" you up I can also say that this might not be one option but several, meaning a conflict or a non-viable config combination or non-documented dependency.
    – harrymc
    Jan 23, 2012 at 10:31
0

I got the exact same problem here and read a LOT. @harrymc did a pretty good summary.

I will just add 2 things I learned from my research:

  • The problem comes from your Linux kernel which does not know how to handle your processor because it cannot figure out what's your processing clock. You can observe this by checking out the kernel boot log. It looks like the kernel is trying to measure your processing clock (for me it was like "2997.1333" but every boot changing to "2997.1445", "2997.1379", ...).

  • After trying a lot of things, I finally got here and find out about the BIOS. Mine is GYGABITE UEFI. I set parameters back to "Optimized default settings" and set "Intel Virtualization Technology" to "enabled".

Now, everything is back to normal for me! Hopes this helps.

0

A few cents from me, not sure if it's a common thing or not but I was able to make Ubuntu work by disabling 'high precision timer' in BIOS. My mb is gigabyte z77x-d3h

1
  • The OP's system doesn't support the High Precision Event Timer. That was introduced in 2005, and the original poster's system predates that by several years. Jun 15, 2015 at 21:30
-2

I fixed the problem by adding following kernelparameter:

noapic
2
  • 5
    Welcome to Super User. Can you expand your answer by explaining what this does/how it solves the OP's problem? Jul 3, 2018 at 1:29
  • no sry, just played around with the kernel parameters.
    – Kiroe
    Jul 3, 2018 at 8:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .