[PATCH] md: new sysfs interface for setting bits in the write-intent-bitmap
Add a new sysfs interface that allows the bitmap of an array to be dirtied.
The interface is write-only, and is used as follows:
echo "1000" > /sys/block/md2/md/bitmap
(dirty the bit for chunk 1000 [offset 0] in the in-memory and on-disk
bitmaps of array md2)
echo "1000-2000" > /sys/block/md1/md/bitmap
(dirty the bits for chunks 1000-2000 in md1's bitmap)
This is useful, for example, in cluster environments where you may need to
combine two disjoint bitmaps into one (following a server failure, after a
secondary server has taken over the array). By combining the bitmaps on
the two servers, a full resync can be avoided (This was discussed on the
list back on March 18, 2005, "[PATCH 1/2] md bitmap bug fixes" thread).
Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The ip_hdrlen() buddy, created to reduce the number of skb->h.th-> uses and to
avoid the longer, open coded equivalent.
Ditched a no-op in bnx2 in the process.
I wonder if we should have a BUG_ON(skb->h.th->doff < 5) in tcp_optlen()...
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Edited: Ian Campbell -- just definition.
For the quite common 'skb->h.raw - skb->data' sequence.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Edited: Ian Campbell -- just definition.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Edited: Ian Campbell -- just definition.
WARNING: vmlinux - Section mismatch: reference to .init.text:spi_register_board_info from __ksymtab_gpl between '__ksymtab_spi_register_board_info' (at offset 0xc032f7d0) and '__ksymtab_spi_alloc_master'
Fix this by removing the export.
Acked-by: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
WARNING: vmlinux - Section mismatch: reference to .init.data:acpi_noirq from .text between 'pcibios_penalize_isa_irq' (at offset 0xc026ffa1) and 'pirq_serverworks_get'
(It will cause a warning when we run the section checking, but that's a
false-positive and it simply changes the source of an existing warning, which
is also a false-positive)
Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PATCH] i386: cpu hotplug/smpboot misc MODPOST warning fixes
o Misc smpboot/cpu hotplug path cleanups. I did those to supress the
warnings generated by MODPOST. These warnings are visible only
if CONFIG_RELOCATABLE=y.
o CONFIG_RELOCATABLE compiles the kernel with --emit-relocs option. This
option retains relocation information in vmlinux file and MODPOST
is quick to spit out "Section mismatch" warnings.
o This patch fixes some of those warnings. Many of the functions in
smpboot case are __devinit type and they in turn accesses text/data which
if of type __cpuinit. Now if CONFIG_HOTPLUG=y and CONFIG_HOTPLUG_CPU=n
then we end up in cases where a function in .text segment is calling
another function in .init.text segment and MODPOST emits warning.
WARNING: vmlinux - Section mismatch: reference to .init.text:identify_cpu from .text between 'smp_store_cpu_info' (at offset 0xc011020d) and 'do_boot_cpu'
WARNING: vmlinux - Section mismatch: reference to .init.text:init_gdt from .text between 'do_boot_cpu' (at offset 0xc01102ca) and '__cpu_up'
WARNING: vmlinux - Section mismatch: reference to .init.text:print_cpu_info from .text between 'do_boot_cpu' (at offset 0xc01105d0) and '__cpu_up'
o It also fixes the issues where CONFIG_HOTPLUG_CPU=y and start_secondary()
is calling smp_callin() which in-turn calls synchronize_tsc_ap() which is
of type __init. This should have meant broken CPU hotplug.
WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'start_secondary' (at offset 0xc011603f) and 'initialize_secondary'
WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'MP_processor_info' (at offset 0xc0116a4f) and 'mp_register_lapic'
WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'MP_processor_info' (at offset 0xc0116a4f) and 'mp_register_lapic'
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>
projects / xenclient / kernel.git / log