search for: identify_boot_cpu

...u() is used to identify both the boot CPU and secondary CPUs, but it performs some actions which only apply to the boot CPU. Those functions are therefore really __init functions, but because they're called by identify_cpu(), they must be marked __cpuinit. This patch splits identify_cpu() into identify_boot_cpu() and identify_secondary_cpu(), and calls the appropriate init functions from each. Also, identify_boot_cpu() and all the functions it dominates are marked __init. The same change applies to both i386 and x86_64, and both have to be changed together because they share the mtrr setup code. Signed...

...u() is used to identify both the boot CPU and secondary CPUs, but it performs some actions which only apply to the boot CPU. Those functions are therefore really __init functions, but because they're called by identify_cpu(), they must be marked __cpuinit. This patch splits identify_cpu() into identify_boot_cpu() and identify_secondary_cpu(), and calls the appropriate init functions from each. Also, identify_boot_cpu() and all the functions it dominates are marked __init. The same change applies to both i386 and x86_64, and both have to be changed together because they share the mtrr setup code. Signed...

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

.../0x3d7() [ 0.005875] Hardware name: H8DG6/H8DGi [ 0.005879] Modules linked in: [ 0.005885] Pid: 0, comm: swapper Not tainted 2.6.32.26 #7 [ 0.005890] Call Trace: [ 0.005898] [] ? warn_slowpath_common+0x76/0x8c [ 0.005905] [] ? init_hw_perf_events+0x337/0x3d7 [ 0.005912] [] ? identify_boot_cpu+0x15/0x3d [ 0.005918] [] ? check_bugs+0x9/0x2e [ 0.005924] [] ? start_kernel+0x3cb/0x3e5 [ 0.005931] [] ? xen_start_kernel+0x5a4/0x5a8 [ 0.005941] ---[ end trace a7919e7f17c0a725 ]--- [ 0.005946] ... version: 0 [ 0.005950] ... bit width: 48 [ 0.00...

Hello! I'm having problems getting PCI pass-through to work. This is on a AMD64 system, paravirtualized with xen-hypervisor-4.0-amd64 4.0.0-1~experimental.1, dom0: linux-image-2.6.32-5-xen-amd64 2.6.32-12. From IRC, earlier today: <tschwinge> waldi: Aren't the Debian xen domU-capable kernels supposed to contain the PCI frontend (needed for PCI pass-through)? I'm getting:

Hello! I'm having problems getting PCI pass-through to work. This is on a AMD64 system, paravirtualized with xen-hypervisor-4.0-amd64 4.0.0-1~experimental.1, dom0: linux-image-2.6.32-5-xen-amd64 2.6.32-12. From IRC, earlier today: <tschwinge> waldi: Aren't the Debian xen domU-capable kernels supposed to contain the PCI frontend (needed for PCI pass-through)? I'm getting:

Hello, I tried out kernel 3.1.0-rc2 on my i386 Laptop with Xen 4.1.1. Booting hangs after these messages on the VGA console: pci 0000:02:09.0: address space collision: [mem 0x000da000-0x000dafff] conflicts with reserved [mem 0x0009f800-0x000fffff] reserve RAM buffer: 00000000 0009f000 - 00000000 0009ffff reserve RAM buffer: 00000000 38400000 - 00000000 3bffffff reserve RAM buffer: 00000001

Hello, I tried out kernel 3.1.0-rc2 on my i386 Laptop with Xen 4.1.1. Booting hangs after these messages on the VGA console: pci 0000:02:09.0: address space collision: [mem 0x000da000-0x000dafff] conflicts with reserved [mem 0x0009f800-0x000fffff] reserve RAM buffer: 00000000 0009f000 - 00000000 0009ffff reserve RAM buffer: 00000000 38400000 - 00000000 3bffffff reserve RAM buffer: 00000001