Dunno why this pops out in only in the allmodconfig build.
Though the warning is accurate, all the callers of the flagged
non __init function are __init, this is not a functional change.
WARNING: vmlinux - Section mismatch: reference to .init.data:acpi_sci_flags from .text between 'acpi_sci_ioapic_setup' (at offset 0xc010f0a
6) and 'acpi_gsi_to_irq' WARNING: vmlinux - Section mismatch: reference to .init.text:mp_override_legacy_irq from .text between 'acpi_sci_ioapic_setup' (at offset 0
xc010f0de) and 'acpi_gsi_to_irq' WARNING: vmlinux - Section mismatch: reference to .init.data:acpi_sci_override_gsi from .text between 'acpi_sci_ioapic_setup' (at offset 0x c010f0e4) and 'acpi_gsi_to_irq'
[PATCH] i386: mark cpu identify functions as __cpuinit
Mark i386-specific cpu identification functions as __cpuinit. They are all
only called from arch/i386/common.c:identify_cpu() that already is marked as
__cpuinit.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp> Signed-off-by: Andi Kleen <ak@suse.de>
identify_cpu() 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.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: Andi Kleen <ak@suse.de>
In init/main.c we have a reference from rest_init() to .init.text
which is intentional.
Rename the function 'init' to 'kernel_init' to make it a
kernel wide unique symbol and whitelist the reference.
[PATCH] generic: Break init() in two parts to avoid MODPOST warnings
o init() is a non __init function in .text section but it calls many
functions which are in .init.text section. Hence MODPOST generates lots
of cross reference warnings on i386 if compiled with CONFIG_RELOCATABLE=y
WARNING: vmlinux - Section mismatch: reference to .init.text:smp_prepare_cpus from .text between 'init' (at offset 0xc0101049) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to .init.text:migration_init from .text between 'init' (at offset 0xc010104e) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to .init.text:spawn_ksoftirqd from .text between 'init' (at offset 0xc0101053) and 'rest_init'
o This patch breaks down init() in two parts. One part which can go
in .init.text section and can be freed and other part which has to
be non __init(init_post()). Now init() calls init_post() and init_post()
does not call any functions present in .init sections. Hence getting
rid of warnings.
[PATCH] i386: Convert some functions to __init to avoid MODPOST warnings
o Some functions which should have been in init sections as they are called
only once. Put them in init sections. Otherwise MODPOST generates warning
as these functions are placed in .text and they end up accessing something
in init sections.
WARNING: vmlinux - Section mismatch: reference to .init.text:migration_init
from .text between 'do_pre_smp_initcalls' (at offset 0xc01000d1) and
'run_init_process'
[PATCH] i386: move startup_32() in text.head section
o Entry startup_32 was in .text section but it was accessing some init
data too and it prompts MODPOST to generate compilation warnings.
WARNING: vmlinux - Section mismatch: reference to .init.data:boot_params from
.text between '_text' (at offset 0xc0100029) and 'startup_32_smp'
WARNING: vmlinux - Section mismatch: reference to .init.data:boot_params from
.text between '_text' (at offset 0xc0100037) and 'startup_32_smp'
WARNING: vmlinux - Section mismatch: reference to
.init.data:init_pg_tables_end from .text between '_text' (at offset
0xc0100099) and 'startup_32_smp'
o Can't move startup_32 to .init.text as this entry point has to be at the
start of bzImage. Hence moved startup_32 to a new section .text.head and
instructed MODPOST to not to generate warnings if init data is being
accessed from .text.head section. This code has been audited.
o SMP boot up code (startup_32_smp) can go into .init.text if CPU hotplug
is not supported. Otherwise it generates more warnings
WARNING: vmlinux - Section mismatch: reference to .init.data:new_cpu_data from
.text between 'checkCPUtype' (at offset 0xc0100126) and 'is486'
WARNING: vmlinux - Section mismatch: reference to .init.data:new_cpu_data from
.text between 'checkCPUtype' (at offset 0xc0100130) and 'is486'
[ATM]: fore200e_param_bs_queue() must be __devinit
WARNING: drivers/built-in.o(.text+0x6203bb): Section mismatch: reference to .init.text:fore200e_param_bs_queue (between 'fore200e_initialize' and 'fore200e_monitor_putc')
Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
he_init_one() is declared __devinit, but calls lots of init functions
that are marked __init. However, if CONFIG_HOTPLUG is enabled,
__devinit functions go into normal .text, which leads to
WARNING: drivers/atm/he.o - Section mismatch: reference to .init.text: from .text between 'he_start' (at offset 0x2130) and 'he_service_tbrq'
Fix this by changing the __init functions to __devinit.
Signed-off-by: Roland Dreier <roland@digitalvampire.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Initialize module_subsys earlier (or at least earlier than devices) since
it could be used very early in the boot process if kmod loads a module
before the device initcalls. Otherwise, kmod will crash in
kernel/module.c:mod_sysfs_setup() since the kset in module_subsys is not
initialized yet.
I only noticed this problem because occasionally, kmod loads the modules
for my SCSI and Ethernet adapters very early, during the boot process
itself. I don't quite understand why it loads them sometimes and doesn't
load them other times. Or who is telling kmod to do so. Can someone
explain?
Signed-off-by: Mark Huang <mlhuang@cs.princeton.edu> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Keir Fraser [Thu, 18 Dec 2008 11:51:36 +0000 (11:51 +0000)]
netback: handle non-netback foreign pages
An SKB can contain pages which are foreign but not tracked by netback,
such as those created by gnttab_copy_grant_page when in
NETBK_DELAYED_COPY_SKB mode. These pages do not have a mapping field
which points to a valid offset in the pending_tx_info array.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Keir Fraser [Thu, 2 Oct 2008 10:29:02 +0000 (11:29 +0100)]
xen: fix kdump kernel crash on Xen3.2
The kernel is supposed to create some "Crash note" resources (children
of the "Hypervisor code and data" resource in /proc/iomem). However,
when running on Xen 3.2, xen_machine_kexec_setup_resources()
encounters an error and returns prior to doing this.
The error occurs when it calls the "kexec_get_range" hypercall to
determine the location of the "vmcoreinfo". This was only implemented
in Xen 3.3.
This patch makes the kernel handle this error gracefully by simply not
creating the sysfs file "hypervisor/vmcoreinfo" if the hypervisor is
unable to provide the info - rather than bailing out of
xen_machine_kexec_setup_resources() early.
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
ACPI: Backport latest T-state support from latest Linux upstream
The purpose is to:
- add ACPI 3.0 _TPC _TSS _PTC throttling support
- Enable MSR (FixedHW) support for T-States
- Update the t-state for every affected cpu when t-state is changed
Keir Fraser [Fri, 29 Aug 2008 15:12:50 +0000 (16:12 +0100)]
xen: don't round up swiotlb slab count
This has been unnecessary for a long time, as
xen_create_contiguous_region() is no longer called on the whole area
at once, and the rounding can (under certain circumstances) prevent
the kernel from successfully booting when a larger than the default
size is needed.
Isaku Yamahata [Tue, 5 Aug 2008 03:19:38 +0000 (12:19 +0900)]
[IA64] improve response time in dom 0 at creating a guest domain
The hypercall takes several hundred mili seconds,
and it takes around 5 mili seconds with my new patch.
Time of one hypercall should be smaller than a vcpu time slice.
linux/blkfront: Add "media" file to vbd sysfs directory
Patch adds "media" file to the vbd sysfs directory. File contains a
string, cdrom or disk.
Currently all PV vbd devices are seen by HAL as "disk". Applications
that query HAL info.capabilities attribute to determine a block
devices capabilities fail to see a PV cdrom as having CDROM
capabilities. With the attached patch and a small corresponding patch
to HAL, applications that query HAL for the storage type of the block
device will see it as a disk or a cdrom. Standard Linux IDE devices
use this same mechanism.
lshal of vbd without patches:
info.capabilities = {'storage', 'block'} (string list)
lshal of vbd with patches:
info.capabilities = {'storage', 'block', 'storage.cdrom'} (string
list)
Decouple xen controlled cpufreq path from dom0 CONFIG_CPU_FREQ,
since only processor_perflib.o is required for necessary freq
information parse. This avoids hacks to cpufreq drivers and
fortunately the change is not intrusive.
Signed-off-by Kevin Tian <kevin.tian@intel.com>
Signed-off-by Jinsong Liu <jinsong.liu@inte.com>
Fn arch_acpi_processor_init_extcntl need to be called before any
acpi_processor init stuff, otherwise many special paths for
xen-cpu-idle & xen-cpu-freq can't get executed. So keep
arch_acpi_processor_init_extcntl call in processor_extcntl_init and
call it very early, move other stuff of processor_extcntl_init into a
new fn processor_extcntl_prepare.
There is no specific reason to reduce memory and stack registers
for kexec. Because the page for relocate_kernel code is allocated
by kimage_alloc_pages() which calls xen_limit_pages_to_max_mfn()
so that pages are guaranteed to be machine contiguous.
Remove those unnecessary #ifdef CONFIG_XEN.
[IA64] initialize /proc/iomem_machine properly when discontig mem.
With CONFIG_DISCONTIGMEM enabled /proc/iomem_machine isn't
initialized properly so that kexec failes because kexec-tools wrongly
tries to use ia64 boot mem (or efi memmap area).
This patch fixes /proc/iomem_machine.
> linux-2.6.18-xen.hg/arch/ia64/kernel/efi.c: In function 'efi_initialize_iomem_machine_resources':
> linux-2.6.18-xen.hg/arch/ia64/kernel/efi.c:1185: warning: control reaches end of non-void function
Now, for a platform bug check, we issue an IPI for the IA64_TIMER_VECTOR
and wait for it to show up in the IRR. Since a PV kernel doesn't
support a timer IPI, this never happens. The fix is simply to tie this
into xen_send_ipi() for this case. This doesn't actually happen on
2.6.18, but since vendors are backporting changes from upstream, I think
it's good to have this in the reference tree
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Keir Fraser [Fri, 8 Aug 2008 13:24:33 +0000 (14:24 +0100)]
linux/x86: fix issues with the assignment of huge amounts of memory
At the same time remove the non-applicable and broken support for the
memmap= command line option.
Also fix the overlap of the modules area with the fixmaps on x86-64.
x86: restrict keyboard io ports reservation to make ipmi driver
work
On some of our (single board computer) boards (x86) we are using
an IPMI controller that uses I/O ports 0x62 and 0x66 for a KCS
(keyboard controller style) IPMI system interface.
Trying to load the openipmi driver fails, because the ports
(0x62/0x66) are reserved for keyboard. keyboard reserves the full
range 0x60-0x6F while it doesn't need to.
Reserve only ports 0x60 and 0x64 for the legacy PS/2 i8042 keyboad
controller instead of 0x60-0x6F to allow the openipmi driver to
work.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Markus Armbruster <armbru@redhat.com>
linux/acpi: adjust extcntl's changes to (mostly) common code, mostly for readability
While I realize that it may have been upon my request that all these
#ifdef-s were introduced, I think this went too far here: With the
abstraction in include/acpi/processor.h in place, the code still
guarantees even without all these #ifdef-s that in native kernels
built from the same source the logic will not change.
The one thing that appears a little weak still is the NR_ACPI_CPUS
construct - nothing guarantees that the ACPI IDs are constrained to 8
bits, and hence using an array here doesn't seem either safe or
scalable looking forward. To make the issue explict, the patch adds a
respective BUG_ON().
linux/evtchn: Add memory barriers to evtchn ring accesses.
Xenstore infrequently hangs up on IA64.
Actually the xenstored is still alive but no response from
xenstore-XXX commands.
After tracking down, I've found that evtchn_read() infrequently
returns a wrong evtchn port number and evtchn_write() never
unmask the exact port.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
Yes, updates of the ring_prod and ring_cons are separately protected
by different locks/mutexes, but the data communication between
producer and consumer is lock-free. Barriers are needed.
When resuming from S3, some platforms may clear SCI_EN bit in
PM1_CONTROL register and cause SCI interrupt disabled in Domain0. This
patch fixes this issue as Linux-2.6.19 does.
A recent need for our kernel was to be able to run on 3.0.2-based Xen,
and this pointed out that while the fallback code in hypercall.h deals
with most of the cases, the multicalls used in the context switch code
didn't have appropriate fallback mechanisms. Short of breaking up the
multicall or checking individual operation status, the easier method
to fix this seemed to be to simply use the old hypercalls when
CONFIG_XEN_COMPAT_030002_AND_LATER is defined.
This patch fixes the following compilation error.
scsiback_interface_exit() is called by scsiback_init().
remove __exit.
> LD .tmp_vmlinux1
>`scsiback_interface_exit' referenced in section `.init.text' of
>drivers/built-in.o: defined in discarded section `.exit.text' of
>drivers/built-in.o
- Sanity check for REPORT_LUN emulation.
- Return "residual" value from backend to frontend. The residual value
is used to represent difference between request size the frontend
requested and size backend actually responded.
Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com> Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>
projects / xenclient / kernel.git / log