search for: rest_init

...162.490334] __handle_domain_irq+0x84/0xf0 [ 162.493834] gic_handle_irq+0x58/0xa8 [ 162.498464] el1_irq+0xb4/0x130 [ 162.500621] arch_cpu_idle+0x18/0x28 [ 162.504729] default_idle_call+0x1c/0x34 [ 162.508005] do_idle+0x17c/0x1f0 [ 162.510184] cpu_startup_entry+0x20/0x28 [ 162.515050] rest_init+0x250/0x260 [ 162.518228] start_kernel+0x3f0/0x41c [ 162.522987] BUG: sleeping function called from invalid context at mm/mempool.c:320 [ 162.533762] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0 [ 162.540375] INFO: lockdep is turned off. [ 162.542696] irq event stamp: 3670810...

...rm_init+0x4d/0x4f > [ 0.633732] [<ffffffff81000312>] do_one_initcall+0x122/0x170 > [ 0.633734] [<ffffffff81af6f49>] kernel_init_freeable+0x108/0x197 > [ 0.633735] [<ffffffff81af681c>] ? do_early_param+0x8c/0x8c > [ 0.633737] [<ffffffff815d4d20>] ? rest_init+0xe0/0xe0 > [ 0.633738] [<ffffffff815d4d2e>] kernel_init+0xe/0xf0 > [ 0.633740] [<ffffffff815f6b1c>] ret_from_fork+0x7c/0xb0 > [ 0.633741] [<ffffffff815d4d20>] ? rest_init+0xe0/0xe0 >

...162.490334] __handle_domain_irq+0x84/0xf0 [ 162.493834] gic_handle_irq+0x58/0xa8 [ 162.498464] el1_irq+0xb4/0x130 [ 162.500621] arch_cpu_idle+0x18/0x28 [ 162.504729] default_idle_call+0x1c/0x34 [ 162.508005] do_idle+0x17c/0x1f0 [ 162.510184] cpu_startup_entry+0x20/0x28 [ 162.515050] rest_init+0x250/0x260 [ 162.518228] start_kernel+0x3f0/0x41c [ 162.522987] BUG: sleeping function called from invalid context at mm/mempool.c:320 [ 162.533762] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0 [ 162.540375] INFO: lockdep is turned off. [ 162.542696] irq event stamp: 3670810...

...x84/0xf0 > [ 162.493834] gic_handle_irq+0x58/0xa8 > [ 162.498464] el1_irq+0xb4/0x130 > [ 162.500621] arch_cpu_idle+0x18/0x28 > [ 162.504729] default_idle_call+0x1c/0x34 > [ 162.508005] do_idle+0x17c/0x1f0 > [ 162.510184] cpu_startup_entry+0x20/0x28 > [ 162.515050] rest_init+0x250/0x260 > [ 162.518228] start_kernel+0x3f0/0x41c > [ 162.522987] BUG: sleeping function called from invalid context at mm/mempool.c:320 > [ 162.533762] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0 > [ 162.540375] INFO: lockdep is turned off. > [ 162.542696]...

...[<ffffffff816c727a>] kernel_init+0xa/0x100 [ 0.690623] [<ffffffff816d485f>] ret_from_fork+0x1f/0x40 [ 0.696659] DWARF2 unwinder stuck at ret_from_fork+0x1f/0x40 [ 0.698858] [ 0.699533] Leftover inexact backtrace: [ 0.699533] [ 0.701580] [<ffffffff816c7270>] ? rest_init+0x90/0x90 [ 0.703944] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

...ll+0x35/0x50 xen_do_hypervisor_callback+0x1e/0x40 <EOI> ? xen_hypercall_sched_op+0xa/0x20 ? xen_hypercall_sched_op+0xa/0x20 ? xen_safe_halt+0x10/0x20 ? default_idle+0x1e/0xd0 ? arch_cpu_idle+0xf/0x20 ? default_idle_call+0x2c/0x40 ? cpu_startup_entry+0x1ac/0x240 ? rest_init+0x77/0x80 ? start_kernel+0x4a7/0x4b4 ? set_init_arg+0x55/0x55 ? x86_64_start_reservations+0x24/0x26 ? xen_start_kernel+0x555/0x561 general protection fault: 0000 [#1] SMP Call Trace: <IRQ> ? napi_gro_complete+0x5e/0xa0 skb_release_all+0x24/0x30 kfree_skb+0x32/0x90...

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

...the smp_prepare_cpus which now changes the pv_lock_ops again, *but not* run any patching again. So the _raw_spin_*lock calls still use the ticket calls. start_kernel setup_arch -> xen_hvm_smp_init (set smp_ops) ... check_bugs -> alternative_instructions (patches pv_locks sites) ... rest_init (triggers kernel_init as a thread) kernel_init ... smp_prepare_cpus (calls xen_init_spinlocks through smp_ops hook) To make things even more fun, there is the possibility that some spinlock functions are forced to be inlined and others are not (CONFIG_INLINE_SPIN_*). In our special...

...ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000 [ 2.514722] [<ffffffff81061540>] ? xen_safe_halt+0x10/0x20 [ 2.514782] [<ffffffff81075cfa>] ? default_idle+0xba/0x570 [ 2.514841] [<ffffffff810778af>] ? cpu_idle+0xdf/0x140 [ 2.514900] [<ffffffff81a4d881>] ? rest_init+0x135/0x144 [ 2.514960] [<ffffffff81a4d74c>] ? csum_partial_copy_generic+0x16c/0x16c [ 2.515022] [<ffffffff82520c45>] ? start_kernel+0x3db/0x3e8 [ 2.515081] [<ffffffff8252066a>] ? repair_env_string+0x5a/0x5a [ 2.515141] [<ffffffff82520356>] ? x86_64_start_res...

...ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000 [ 2.514722] [<ffffffff81061540>] ? xen_safe_halt+0x10/0x20 [ 2.514782] [<ffffffff81075cfa>] ? default_idle+0xba/0x570 [ 2.514841] [<ffffffff810778af>] ? cpu_idle+0xdf/0x140 [ 2.514900] [<ffffffff81a4d881>] ? rest_init+0x135/0x144 [ 2.514960] [<ffffffff81a4d74c>] ? csum_partial_copy_generic+0x16c/0x16c [ 2.515022] [<ffffffff82520c45>] ? start_kernel+0x3db/0x3e8 [ 2.515081] [<ffffffff8252066a>] ? repair_env_string+0x5a/0x5a [ 2.515141] [<ffffffff82520356>] ? x86_64_start_res...

...Q+0x75/0xf0 [<ffffffff8100b9d3>] ? ret_from_intr+0x0/0x11 <EOI> [<ffffffff81016627>] ? mwait_idle+0x77/0xd0 [<ffffffff815176fa>] ? atomic_notifier_call_chain+0x1a/0x20 [<ffffffff81009fc6>] ? cpu_idle+0xb6/0x110 [<ffffffff814f6e3a>] ? rest_init+0x7a/0x80 [<ffffffff81c25f70>] ? start_kernel+0x405/0x411 [<ffffffff81c2533a>] ? x86_64_start_reservations+0x125/0x129 [<ffffffff81c25453>] ? x86_64_start_kernel+0x115/0x124 Does anyone know the reason?

..._idle+0xde/0x170 Feb 18 05:04:36 kernel: [<ffffffff812c49c1>] ? intel_idle+0xc1/0x170 Feb 18 05:04:36 kernel: [<ffffffff813f9ef7>] ? cpuidle_idle_call+0xa7/0x140 Feb 18 05:04:36 kernel: [<ffffffff81009e06>] ? cpu_idle+0xb6/0x110 Feb 18 05:04:36 kernel: [<ffffffff814d40ca>] ? rest_init+0x7a/0x80 Feb 18 05:04:36 kernel: [<ffffffff81c1ff76>] ? start_kernel+0x424/0x430 Feb 18 05:04:36 kernel: [<ffffffff81c1f33a>] ? x86_64_start_reservations+0x125/0x129 Feb 18 05:04:36 kernel: [<ffffffff81c1f438>] ? x86_64_start_kernel+0xfa/0x109 Feb 18 05:04:36 kernel: ---[ end tra...

...;ffffffff81d0ee34>] ? ttm_init+0x62/0x62 [<ffffffff81d0ee77>] nouveau_drm_init+0x43/0x45 [<ffffffff8100023f>] do_one_initcall+0x3f/0x150 [<ffffffff81cd7f47>] kernel_init_freeable+0x138/0x1c7 [<ffffffff81cd7837>] ? do_early_param+0x86/0x86 [<ffffffff8169e590>] ? rest_init+0x80/0x80 [<ffffffff8169e59e>] kernel_init+0xe/0xf0 [<ffffffff816ad9ac>] ret_from_fork+0x7c/0xb0 [<ffffffff8169e590>] ? rest_init+0x80/0x80 ---[ end trace 0bc6b5945c0022a8 ]--- It is not showing if I enable GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub I'm attaching the...

...cpuidle_idle_call+0xd6/0x1d0 [<ffffffff81091312>] ? __atomic_notifier_call_chain+0x12/0x20 [<ffffffff810b24a5>] ? cpu_idle_loop+0x135/0x1e0 [<ffffffff810b256b>] ? cpu_startup_entry+0x1b/0x70 [<ffffffff810b25b0>] ? cpu_startup_entry+0x60/0x70 [<ffffffff81667c57>] ? rest_init+0x77/0x80 [<ffffffff81d774c9>] ? start_kernel+0x441/0x448 [<ffffffff81d76ea6>] ? set_init_arg+0x5d/0x5d [<ffffffff81d76603>] ? x86_64_start_reservations+0x2a/0x2c [<ffffffff81d7aae1>] ? xen_start_kernel+0x5ef/0x5f1 Code: 00 0f 87 06 07 00 00 44 8b b3 b8 00 00 00 44 03 b3...

...f6e93>] __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 66 2e 0f 1f 84 00 00 00 00 00 83 c3 01 41 39 dd 0f 86 84 00 00 00...

...e first pass, but absolutely no *-xen.c code copying. I'm just starting this, but at least with the version magic check (see http://lists.xensource.com/archives/html/xen-devel/2007-11/msg00601.html ) out of the way, an SMP dom0 running pv_ops gets all the way through start_kernel() and into rest_init() before dying with an unsupported cr0 write. (I'm using direct console hypercalls for printk for now, full xencons is not working yet.) Current goal is to get as far as I can with the normal domU boot process in a dom0 environment (getting console set up correctly, etc), before starting to p...

...e first pass, but absolutely no *-xen.c code copying. I'm just starting this, but at least with the version magic check (see http://lists.xensource.com/archives/html/xen-devel/2007-11/msg00601.html ) out of the way, an SMP dom0 running pv_ops gets all the way through start_kernel() and into rest_init() before dying with an unsupported cr0 write. (I'm using direct console hypercalls for printk for now, full xencons is not working yet.) Current goal is to get as far as I can with the normal domU boot process in a dom0 environment (getting console set up correctly, etc), before starting to p...

...e first pass, but absolutely no *-xen.c code copying. I'm just starting this, but at least with the version magic check (see http://lists.xensource.com/archives/html/xen-devel/2007-11/msg00601.html ) out of the way, an SMP dom0 running pv_ops gets all the way through start_kernel() and into rest_init() before dying with an unsupported cr0 write. (I'm using direct console hypercalls for printk for now, full xencons is not working yet.) Current goal is to get as far as I can with the normal domU boot process in a dom0 environment (getting console set up correctly, etc), before starting to p...

...nel: >> [<ffffffff812c49c1>] ? intel_idle+0xc1/0x170 Feb 18 05:04:36 >> kernel: [<ffffffff813f9ef7>] ? cpuidle_idle_call+0xa7/0x140 Feb >> 18 05:04:36 kernel: [<ffffffff81009e06>] ? cpu_idle+0xb6/0x110 >> Feb 18 05:04:36 kernel: [<ffffffff814d40ca>] ? rest_init+0x7a/0x80 >> Feb 18 05:04:36 kernel: [<ffffffff81c1ff76>] ? >> start_kernel+0x424/0x430 Feb 18 05:04:36 kernel: >> [<ffffffff81c1f33a>] ? >> x86_64_start_reservations+0x125/0x129 >> Feb 18 05:04:36 kernel: [<ffffffff81c1f438>] ? >> x86_64_start_...

Hi all, I have 5 CentOS 7 virtual guests installed (all fully patched to latest release) and i have the following error in all of them: systemd-journald[7779]: File /run/log/journal/b4a41f4214ca44f898638301891a6f2e/system.journal corrupted or uncleanly shut down, renaming and replacing. ?? .. And I don't understand why. I have configured "Storage=volatile" in journald.conf ...