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.
Can you attach a dmesg from a working 2.6.38 boot?
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.
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?
(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
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 :-/