search for: clocksource_done_booting

...>> https://bugzilla.redhat.com/show_bug.cgi?id=1285235 >> >> might possibly be related to the kernel panic the original poster >> reported. There is a workaround that may be worth a try: >> >> Boot with the kernel parameter : >> >> initcall_blacklist=clocksource_done_booting >> >> Akemi >> > Thanks Akemi, that worked perfectly That is indeed good news. Now, this is only a workaround. As seen in the RH bugzilla, the patch is in the z-series kernel and the target is set to "7.3". That will be CentOS 7 (1605) [or later]. At any rate it'...

...//bugs.centos.org/view.php?id=9860 and its upstream (RH) reference: https://bugzilla.redhat.com/show_bug.cgi?id=1285235 might possibly be related to the kernel panic the original poster reported. There is a workaround that may be worth a try: Boot with the kernel parameter : initcall_blacklist=clocksource_done_booting Akemi

...ro's - the 327 kernel fell into the rdosshell, I guess. I finally got one the three up by going back to the 228.14 kernel. Now, after googling and finding the CentOS bugzilla, 0009860, that referenced the upstream bugzilla, I applied the workaround discussed in it, Adding initcall_blacklist=clocksource_done_booting to GRUB_CMDLINE_LINUX in /etc/default/grub and then grub2-mkconfig -o /etc/grub2.cfg" On one. On the other, that's got a *large* RAID appliance (a JetStor w/ 42 4TB drives...), it seemed to work... then gave me a dozen or so ERROR: unsupported sector size 4096 on /dev/sdd. ERROR: unsup...

Tru Huynh wrote: > On Fri, Jan 01, 2016 at 11:53:51PM +0100, Timothy Murphy wrote: >> My HP MicroServer crashes with a kernel panic >> when booted into kernel-3.10.0-327.3.1.el7.x86_64, >> but runs perfectly under kernel-3.10.0-229.20.1.el7.x86_64 . > AMD Turion64 cpu? > Could be related to: > https://bugs.centos.org/view.php?id=9860 > uptream at

CentOS-7-x86_64-LiveKDE-1511.iso crashes on my AMD/ATI Radeon machine. I installed CentOS-7.2 by first installing CentOS-7-x86_64-LiveKDE-1503.iso, then appending GRUB_CMDLINE_LINUX_DEFAULT="initcall_blacklist=clocksource_done_booting" to /etc/default/grub and running update-grub. My question is: would there be any way, short of re-compiling the ISO, of altering the grub.cfg seen when booting from a USB stick? -- Timothy Murphy gayleard /at/ eircom.net School of Mathematics, Trinity College, Dublin

...ts upstream (RH) reference: > > https://bugzilla.redhat.com/show_bug.cgi?id=1285235 > > might possibly be related to the kernel panic the original poster > reported. There is a workaround that may be worth a try: > > Boot with the kernel parameter : > > initcall_blacklist=clocksource_done_booting > > Akemi > Thanks Akemi, that worked perfectly I've managed this twice in a week now, a simple question on the mythtv-users list ended up turning into a huge debate about 4k TV's http://lists.mythtv.org/pipermail/mythtv-users/2015-December/383441.html Still got the problem sor...

...l into the > rdosshell, I guess. I finally got one the three up by going back to the > 228.14 kernel. > > Now, after googling and finding the CentOS bugzilla, 0009860, that > referenced the upstream bugzilla, I applied the workaround discussed in > it, Adding initcall_blacklist=clocksource_done_booting to > GRUB_CMDLINE_LINUX in /etc/default/grub and then grub2-mkconfig -o > /etc/grub2.cfg" > > On one. On the other, that's got a *large* RAID appliance (a JetStor w/ > 42 4TB drives...), it seemed to work... then gave me a dozen or so > ERROR: unsupported sector size 4...

...urion64 cpu? >> Could be related to: >> https://bugs.centos.org/view.php?id=9860 >> uptream at https://bugzilla.redhat.com/show_bug.cgi?id=1285235 Thank you again. I followed a suggestion in this bug report, appending the line GRUB_CMDLINE_LINUX_DEFAULT="initcall_blacklist=clocksource_done_booting" to /etc/default/grub , and running # grub2-mkconfig > /boot/grub2/grub.cfg Now I could re-boot into CentOS-7.2 with kernel 3.10.0-327.3.1.el7.x86_64 . -- Timothy Murphy gayleard /at/ eircom.net School of Mathematics, Trinity College, Dublin

...shell, I guess. I finally got one the three up by going back to the >> 228.14 kernel. >> >> Now, after googling and finding the CentOS bugzilla, 0009860, that >> referenced the upstream bugzilla, I applied the workaround discussed in >> it, Adding initcall_blacklist=clocksource_done_booting to >> GRUB_CMDLINE_LINUX in /etc/default/grub and then grub2-mkconfig -o >> /etc/grub2.cfg" You're writing the grub.cfg to the wrong location with the wrong name. It needs to go to /boot/grub2/grub.cfg - that's where the bootloader looks for it. grubby looks for /etc/grub...

On Sun, Dec 06, 2015 at 09:22:15PM -0500, Jonathan Billings wrote: > On Sun, Dec 06, 2015 at 06:35:58PM +0000, Timothy Murphy wrote: > > Always Learning wrote: > > > > > I always admire Johnny's prose, passion for Centos and his calm approach > > > to everything. > > > > Agreed. > > But two possibly OT and probably ignorant queries: >

Sylvain CANOINE wrote: > Could you share your whole Xorg.0.log ? Do you use a custom xorg.conf, or > custom xorg.conf.d files ? Opensource Ati driver, ou proprietary blobs ? Thank you for your interest. I am running CentOS-7 installed from CentOS-7-x86_64-LiveKDE-1503.iso and later upgraded to CentOS-7.2. The only packages I have installed have been from CentOS and Epel repos. I'm sure

Hi, another issue I''m seeing with 3.0-rc2 and Xen is that there is an unexpectedly high amount of kernel reserved memory. I suspect that Linux allocates page table entries and corresponding data structures for the whole 6GB areas of the provided ''physical RAM map'' even though it has rather big unusable holes in it. [ 0.000000] BIOS-provided physical RAM map: [

...returned 0 after 3906 usecs [ 36.388968] calling hpet_late_init+0x0/0x16b @ 1 [ 36.393735] initcall hpet_late_init+0x0/0x16b returned -19 after 0 usecs [ 36.400497] calling init_k8_nbs+0x0/0x1b @ 1 [ 36.404923] initcall init_k8_nbs+0x0/0x1b returned 0 after 0 usecs [ 36.411157] calling clocksource_done_booting+0x0/0x4b @ 1 [ 36.416703] Switching to clocksource xen [ 36.421732] initcall clocksource_done_booting+0x0/0x4b returned 0 after 4329 usecs [ 36.429205] calling rb_init_debugfs+0x0/0x25 @ 1 [ 36.433999] initcall rb_init_debugfs+0x0/0x25 returned 0 after 26 usecs [ 36.440645] calling trac...

Lots of changes since v2, too much to remember or summarize. Please ignore patch 11/11, it's just for my testing. Rich.