search for: initcall_blacklist

...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 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 l...

...bug report: https://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

...hey're supermicro'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...

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, Du...

...860 > > 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 > 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...

...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:...

...gt; >> AMD Turion64 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

...o 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" 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. g...

On Tue, Oct 24, 2017 at 3:36 AM, Akemi Yagi <amyagi at gmail.com> wrote: > On Mon, Oct 23, 2017 at 11:08 PM, Akemi Yagi <amyagi at gmail.com> wrote: > >> On Mon, Oct 23, 2017 at 12:57 PM, Karl Johnson <karljohnson.it at gmail.com> >> wrote: >> >>> On Sat, May 20, 2017 at 8:30 PM, Sarah Newman <srn at prgmr.com> wrote: >>>

...ff813f6e70>] ? gnttab_init+0x260/0x260 [ 0.077000] [<ffffffff813f6e93>] __gnttab_init+0x23/0x40 [ 0.077000] [<ffffffff810020e8>] do_one_initcall+0xb8/0x230 [ 0.077000] [<ffffffff81b5d1fb>] kernel_init_freeable+0x17a/0x219 [ 0.077000] [<ffffffff81b5c9d4>] ? initcall_blacklist+0xb0/0xb0 [ 0.077000] [<ffffffff816a3d20>] ? rest_init+0x80/0x80 [ 0.077000] [<ffffffff816a3d2e>] kernel_init+0xe/0xf0 [ 0.077000] [<ffffffff816c5f98>] ret_from_fork+0x58/0x90 [ 0.077000] [<ffffffff816a3d20>] ? rest_init+0x80/0x80 [ 0.077000] Code: 00 00 6...

...race: [ 0.600395] [<c1421c1b>] ? panic+0x74/0x194 [ 0.600442] [<c1608052>] ? mount_block_root+0x250/0x258 [ 0.600490] [<c16081cd>] ? perpare_namespace+0x117/0x15d [ 0.600537] [<c1607d58>] ? kernel_init_freeable+0x1a6/0x1b1 [ 0.600585] [<c1607574>] ? initcall_blacklist+0x97/0x97 [ 0.600632] [<c141f620>] ? kernel_init+0x10/0xe0 [ 0.600680] [<c10607c7<] ? schedule_tail+0x17/0x40 [ 0.600728] [<c1427a40>] ? ret_from_kernel_thread+0x20/0x30 [ 0.600766] [<c141f610>] ? rest_init+0x60/0x60 [ 0.600823] Kernel Offset: 0x0 from 0xc...

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: >

On 03/18/2017 03:02 PM, Thomas Schmitt via Syslinux wrote: > Hi, > > David Christensen wrote: >> I use this USB flash drive for bootable installer images; I do not >> attempt to mount it. I don't know that I could, even if I wanted to: > > mkdir /mnt/iso > mount /dev/sdc /mnt/iso > > or, because partition 1 starts at block 0, you may mount it too >

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

From: Sui Jingfeng <suijingfeng at loongson.cn> On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to hook up with this stub by calling the vga_client_register() function. Once the