On 11/01/19 3:27 PM, Felix Miata wrote: > Richard Hector composed on 2019-01-11 14:03 (UTC+1300): > >> This machine is taking ages to boot. > >> It's a fresh install. > >> According to dmesg, this is where it appears to hang: > >> [ 2.717311] device-mapper: uevent: version 1.0.3 >> [ 2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) >> initialised: dm-d >> evel@redhat.com >> [ 2.978281] clocksource: Switched to clocksource tsc >> [ 121.459392] md: linear personality registered for level -1 >> [ 121.460391] md: multipath personality registered for level -4 >> [ 121.461444] md: raid0 personality registered for level 0 > >> I have started wondering recently about the hardware - could I have a >> clock problem? > >> None of the other 'clocksource' entries have a similar lag, and there's >> no similar lag at that point on my desktop. > >> Do I need to provide more context, or do more diagnostics? > > Possibly kernel-parameters.txt has a clock suggestion, maybe > > clocksource=hpet > > or forcing tsc from cmdline would switch to it at a more opportune time? > Thanks Felix. Well that's interesting - if I put clocksource=hpet on the kernel command line, it still pauses at the same place, but the clocksource message isn't there - which seems to me to eliminate it as the source of the problem. (when I use clocksource=tsc, that line does appear as before) But then I also got rid of those md messages by blacklisting the modules, so now I have different messages both sides of the hang. So either there's something else unlogged happening between, or there's parallelism happening. Either way, I'm not sure where to look next :-( Hints on where to look for the boot sequence in the kernel source, perhaps? Cheers, Richard
Attachment:
signature.asc
Description: OpenPGP digital signature