Bug 35652 - Boot hangs in "switching to clocksource tsc" step
Boot hangs in "switching to clocksource tsc" step
Status: CLOSED INVALID
Product: Other
Classification: Unclassified
Component: Other
All Linux
: P1 normal
Assigned To: other_other
:
Depends on:
Blocks: 32012
  Show dependency treegraph
 
Reported: 2011-05-23 07:06 UTC by Nikos Chantziaras
Modified: 2011-06-12 20:42 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.39
Tree: Mainline
Regression: Yes


Attachments
config-2.6.39-gentoo (51.29 KB, application/octet-stream)
2011-05-23 07:06 UTC, Nikos Chantziaras
Details

Description Nikos Chantziaras 2011-05-23 07:06:47 UTC
Created attachment 59062 [details]
config-2.6.39-gentoo

I've built 2.6.39 on a Gentoo machine (x86_64).  I used my 2.6.38 .config and configured with "make oldconfig".  All new options (new drivers and such) were answered with the default, which was "no".  The kernel hangs when booting it.  The last message printed is:

switching to clocksource tsc

I am attaching my .config file.
Comment 1 john stultz 2011-06-01 22:38:14 UTC
Can you attach a dmesg from a working 2.6.38 boot?
Comment 2 john stultz 2011-06-01 23:14:11 UTC
Using your .config, my system booted, but the last things on the console for quite awhile was the "switching to clocksource tsc". After a few seconds the system came up fine (well, no usb, no networking.. so I couldn't do too much debugging), but X did load.

I'm suspicious that there is something else at play, and the tsc message is just the last thing on the screen at that time (before udev starts).

One way to check would be to boot using clocksource=acpi_pm or clocksource=hpet to see if those function or not.

You might also try booting w/ initcall_debug to see if that points to anything else.
Comment 3 Nikos Chantziaras 2011-06-07 21:09:32 UTC
Sorry for the big delay. Finally found some time to get back to this.

I saw that 2.6.39.1 is now released, so I tried with that one, using the same .config. I'm happy to report that it now boots correctly. So I guess whatever this regression was, it's now fixed :-)

For the record, the difference seems to be that I now get "Switching to clocksource hpet" first instead of "Switching to clocksource tsc". Later on in the boot process, "Switching to clocksource tsc" is printed. This is the same behavior as with 2.6.38.  (I take it that tsc is a better clocksource than hpet?)

On an unrelated matter, when building the kernel, I get this:

warning: (DRM_RADEON_KMS && DRM_I915 && STUB_POULSBO && FB_BACKLIGHT && PANEL_SHARP_LS037V7DW01 && PANEL_ACX565AKM && USB_APPLEDISPLAY && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && EEEPC_LAPTOP && ACPI_ASUS && ACPI_CMPC) selects BACKLIGHT_CLASS_DEVICE which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)

Does that warrant a new bugreport or is this a user error?
Comment 4 john stultz 2011-06-07 21:54:09 UTC
(In reply to comment #3)
> Sorry for the big delay. Finally found some time to get back to this.
> 
> I saw that 2.6.39.1 is now released, so I tried with that one, using the same
> .config. I'm happy to report that it now boots correctly. So I guess whatever
> this regression was, it's now fixed :-)

Good to hear!

> For the record, the difference seems to be that I now get "Switching to
> clocksource hpet" first instead of "Switching to clocksource tsc". Later on in
> the boot process, "Switching to clocksource tsc" is printed. This is the same
> behavior as with 2.6.38.  (I take it that tsc is a better clocksource than
> hpet?)

Does booting with "clocksource=hpet" cause the bug to re-appear?

thanks
-john
Comment 5 Nikos Chantziaras 2011-06-07 22:09:18 UTC
OK, strike that. I'm officially an idiot :-/

The problem was a Gentoo patch. I thought I removed them, but I was booting with a patch still there: the fbcondecor patch (framebuffer console decorations). To make it worse, the bug only manifests when an initrd is also present (the initrd has some *.png and *.ttf files in it, so that graphical boot is there right after the Grub screen, before mounting the rootfs) which is why I didn't notice this; without an "initrd" line in grub.conf, it would work.

Sorry for the noise :-/

Note You need to log in before you can comment on or make changes to this bug.