found a system where x2apic reports an MSI-X irq initialization
failure:

[  302.859446] igbvf 0000:81:10.4: enabling device (0000 -> 0002)
[  302.874369] igbvf 0000:81:10.4: using 64bit DMA mask
[  302.879023] igbvf 0000:81:10.4: using 64bit consistent DMA mask
[  302.894386] igbvf 0000:81:10.4: enabling bus mastering
[  302.898171] igbvf 0000:81:10.4: setting latency timer to 64
[  302.914050] reserve_memtype added 0xefb08000-0xefb0c000, track uncached-minus, req uncached-minus, ret uncached-minus
[  302.933839] reserve_memtype added 0xefb28000-0xefb29000, track uncached-minus, req uncached-minus, ret uncached-minus
[  302.940367]   alloc irq_desc for 265 on node 4
[  302.956874]   alloc kstat_irqs on node 4
[  302.959452] alloc irq_2_iommu on node 0
[  302.974328] igbvf 0000:81:10.4: irq 265 for MSI/MSI-X
[  302.977778]   alloc irq_desc for 266 on node 4
[  302.980347]   alloc kstat_irqs on node 4
[  302.995312] free_memtype request 0xefb28000-0xefb29000
[  302.998816] igbvf 0000:81:10.4: Failed to initialize MSI-X interrupts.

... it turns out that when trying to enable MSI-X,
__assign_irq_vector(new, cfg_new, apic->target_cpus()) can not
get vector because for x2apic target-cpus returns cpumask_of(0)

Update that to online_mask like xapic.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <4A785AFF.3050902@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

With CONFIG_STACK_PROTECTOR turned on, VMI doesn't boot with
more than one processor. The problem is with the gs value not
being initialized correctly when registering the secondary
processor for VMI's case.

The patch below initializes the gs value for the AP to
__KERNEL_STACK_CANARY. Without this the secondary processor
keeps on taking a GP on every gs access.
Signed-off-by: NAlok N Kataria <akataria@vmware.com>
Cc: <stable@kernel.org> # for v2.6.30.x
LKML-Reference: <1249425262.18955.40.camel@ank32.eng.vmware.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The following fix was initially inspired by David Howells fix
few days back:

  http://lkml.org/lkml/2009/7/9/109

However, Ingo disapproves such fixes as it's dangerous (it can
hide future, relevant warnings) - in something as
performance-uncritical.

So, initialize 'err' to '0' to work around a GCC false positive
warning:

  http://lkml.org/lkml/2009/7/18/89

Signed-off-by: Subrata Modak<subrata@linux.vnet.ibm.com>
Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
LKML-Reference: <20090721023226.31855.67236.sendpatchset@subratamodak.linux.ibm.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

In uv_setup_irq(), the call to create_irq() initially assigns
IRQ vectors to cpu 0. The subsequent call to
assign_irq_vector() in arch_enable_uv_irq() migrates the IRQ to
another cpu and frees the cpu 0 vector - at least it will be
freed as soon as the "IRQ move" completes.

arch_enable_uv_irq() needs to send a cleanup IPI to complete
the IRQ move. Otherwise, assignment of GRU interrupts on large
systems (>200 cpus) will exhaust the cpu 0 interrupt vectors
and initialization of the GRU driver will fail.
Signed-off-by: NJack Steiner <steiner@sgi.com>
LKML-Reference: <20090720142840.GA8885@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

With VMALLOC_END included in the calculation of MAXMEM (as of
2.6.28) it is no longer correct to also bump __VMALLOC_RESERVE
in reserve_top_address(). Doing so results in needlessly small
lowmem.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
LKML-Reference: <4A71DD2A020000780000D482@vpn.id2.novell.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

One system has socket 1 come up as BSP.

kexeced kernel reports BSP as:

[    1.524550] Initializing cgroup subsys cpuacct
[    1.536064] initial_apicid:20
[    1.537135] ht_mask_width:1
[    1.538128] core_select_mask:f
[    1.539126] core_plus_mask_width:5
[    1.558479] CPU: Physical Processor ID: 0
[    1.559501] CPU: Processor Core ID: 0
[    1.560539] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.579098] CPU: L2 cache: 256K
[    1.580085] CPU: L3 cache: 24576K
[    1.581108] CPU 0/0x20 -> Node 0
[    1.596193] CPU 0 microcode level: 0xffff0008

It doesn't have correct physical processor id and will get an
error:

[   38.840859] CPU0 attaching sched-domain:
[   38.848287]  domain 0: span 0,8,72 level SIBLING
[   38.851151]   groups: 0 8 72
[   38.858137]   domain 1: span 0,8-15,72-79 level MC
[   38.868944]    groups: 0,8,72 9,73 10,74 11,75 12,76 13,77 14,78 15,79
[   38.881383] ERROR: parent span is not a superset of domain->span
[   38.890724]    domain 2: span 0-7,64-71 level CPU
[   38.899237] ERROR: domain->groups does not contain CPU0
[   38.909229]     groups: 8-15,72-79
[   38.912547] ERROR: groups don't span domain->span
[   38.919665]     domain 3: span 0-127 level NODE
[   38.930739]      groups: 0-7,64-71 8-15,72-79 16-23,80-87 24-31,88-95 32-39,96-103 40-47,104-111 48-55,112-119 56-63,120-127

it turns out: we can not use current_cpu_data in phys_pgd_id
for x2apic.

identify_boot_cpu() is called by check_bugs() before
smp_prepare_cpus() and till smp_prepare_cpus() current_cpu_data
for bsp is assigned with boot_cpu_data.

Just make phys_pkg_id for x2apic is aligned to xapic.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <4A6ADD0D.10002@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Change SGI UV default apicid mode to "physical". This is
required to match settings in the UV hub chip.
Signed-off-by: NJack Steiner <steiner@sgi.com>
LKML-Reference: <20090727143856.GA8905@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The UV chipset automatically supplies the upper bits on nodes
being referenced by MMR accesses. These bit can be deleted from
the hub addressing macros.
Signed-off-by: NJack Steiner <steiner@sgi.com>
LKML-Reference: <20090727143808.GA8076@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The UV BIOS has added additional MMR ranges that are mapped via
EFI virtual mode mappings. These ranges should be deleted from
ranges mapped by uv_system_init().
Signed-off-by: NJack Steiner <steiner@sgi.com>
Cc: linux-mm@kvack.org
LKML-Reference: <20090727143656.GA7698@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

UV blades may not have any blade-local memory. Add a field
(nid) to the UV blade structure to indicates whether the node
has local memory. This is needed by the GRU driver (pushed
separately).
Signed-off-by: NJack Steiner <steiner@sgi.com>
Cc: linux-mm@kvack.org
LKML-Reference: <20090727143507.GA7006@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

From Gabe Black in bugzilla 13888:

native_save_fl is implemented as follows:

  11static inline unsigned long native_save_fl(void)
  12{
  13        unsigned long flags;
  14
  15        asm volatile("# __raw_save_flags\n\t"
  16                     "pushf ; pop %0"
  17                     : "=g" (flags)
  18                     : /* no input */
  19                     : "memory");
  20
  21        return flags;
  22}

If gcc chooses to put flags on the stack, for instance because this is
inlined into a larger function with more register pressure, the offset
of the flags variable from the stack pointer will change when the
pushf is performed. gcc doesn't attempt to understand that fact, and
address used for pop will still be the same. It will write to
somewhere near flags on the stack but not actually into it and
overwrite some other value.

I saw this happen in the ide_device_add_all function when running in a
simulator I work on. I'm assuming that some quirk of how the simulated
hardware is set up caused the code path this is on to be executed when
it normally wouldn't.

A simple fix might be to change "=g" to "=r".
Reported-by: NGabe Black <spamforgabe@umich.edu>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Stable Team <stable@kernel.org>

Make rdmsr_on_cpus/wrmsr_on_cpus execute on the current CPU only if it
is in the supplied bitmask.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Older versions of binutils did not accept the naked "ASSERT" syntax;
it is considered an expression whose value needs to be assigned to
something.
Reported-tested-and-fixed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Booting current 64-bit x86 kernels on the latest Apple MacBook
(MacBook5,2) via EFI gives the following warning:

[    0.182209] ------------[ cut here ]------------
[    0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
[    0.182227] Hardware name: MacBook5,2
[    0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000
[    0.182236] Modules linked in:
[    0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6
[    0.182246] Call Trace:
[    0.182254]  [<ffffffff8102c754>] ? __cpa_process_fault+0x44/0xa0
[    0.182261]  [<ffffffff81048668>] warn_slowpath_common+0x78/0xd0
[    0.182266]  [<ffffffff81048744>] warn_slowpath_fmt+0x64/0x70
[    0.182272]  [<ffffffff8102c7ec>] ? update_page_count+0x3c/0x50
[    0.182280]  [<ffffffff818d25c5>] ? phys_pmd_init+0x140/0x22e
[    0.182286]  [<ffffffff8102c754>] __cpa_process_fault+0x44/0xa0
[    0.182292]  [<ffffffff8102ce60>] __change_page_attr_set_clr+0x5f0/0xb40
[    0.182301]  [<ffffffff810d1035>] ? vm_unmap_aliases+0x175/0x190
[    0.182307]  [<ffffffff8102d4ae>] change_page_attr_set_clr+0xfe/0x3d0
[    0.182314]  [<ffffffff8102dcca>] _set_memory_uc+0x2a/0x30
[    0.182319]  [<ffffffff8102dd4b>] set_memory_uc+0x7b/0xb0
[    0.182327]  [<ffffffff818afe31>] efi_enter_virtual_mode+0x2ad/0x2c9
[    0.182334]  [<ffffffff818a1c66>] start_kernel+0x2db/0x3f4
[    0.182340]  [<ffffffff818a1289>] x86_64_start_reservations+0x99/0xb9
[    0.182345]  [<ffffffff818a1389>] x86_64_start_kernel+0xe0/0xf2
[    0.182357] ---[ end trace 4eaa2a86a8e2da22 ]---
[    0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000
[    0.182993]  00ffffc000 - 0100000000 page 4k

This happens because the 64-bit version of efi_ioremap calls
init_memory_mapping for all addresses, regardless of whether they are
RAM or MMIO.  The EFI tables on this machine ask for runtime access to
some MMIO regions:

[    0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB)
[    0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB)
[    0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB)
[    0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB)
[    0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB)
[    0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB)
[    0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB)

This arranges to pass the EFI memory type through to efi_ioremap, and
makes efi_ioremap use ioremap rather than init_memory_mapping if the
type is EFI_MEMORY_MAPPED_IO.  With this, the above warning goes away.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

The latest Apple MacBook (MacBook5,2) doesn't reboot successfully
under Linux; neither the EFI reboot method nor the default method
using the keyboard controller works (the system just hangs and doesn't
reset).  However, the method using the "PCI reset register" at 0xcf9
does work.

This adds a quirk to detect this machine via DMI and force the
reboot_type to BOOT_CF9.  With this it reboots successfully without
requiring a command-line option.  Note that the EFI code forces
reboot_type to BOOT_EFI when the machine is booted via EFI, but this
overrides that since the core_initcall runs after the EFI
initialization code.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
LKML-Reference: <19062.56420.501516.316181@cargo.ozlabs.ibm.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

The code was incorrectly reserving memtypes using the page
virtual address instead of the physical address. Furthermore,
the code was not ignoring highmem pages as it ought to.

( upstream does not pass in highmem pages yet - but upcoming
  graphics code will do it and there's no reason to not handle
  this properly in the CPA APIs.)

Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13884Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: <stable@kernel.org>
Cc: dri-devel@lists.sourceforge.net
Cc: venkatesh.pallipadi@intel.com
LKML-Reference: <1249284345-7654-1-git-send-email-thellstrom@vmware.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

None of these is used outside the VPE loader.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This may happen if a bad sequence of relocations is being encountered.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRaghu Gandham <raghu@mips.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

There were three different errors resulting in a "dangerous relocation"
message.  Add the relocation type to the messgages to make them more
useful.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

In mm/slab.c the function do_ccupdate_local requires that interrupts be
disabled.  If they are not, we panic with CONFIG_DEBUG_SLAB.

So we disable interrupts while processing IPIs.  Also these are not shared
irqs, so get rid of the IRQF_SHARED flag.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Check whether index is within bounds before testing the element.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d
but is perhaps more readable.

The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@haskernel@
@@

#include <linux/kernel.h>

@depends on haskernel@
expression x,__divisor;
@@

- (((x) + ((__divisor) / 2)) / (__divisor))
+ DIV_ROUND_CLOSEST(x,__divisor)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch fixes the following warning at boot time:
WARNING: at drivers/gpio/gpiolib.c:83 0x8021d5e0()
autorequest GPIO-207
Modules linked in:
Call Trace:[<8011e0ec>] 0x8011e0ec
[<80110a28>] 0x80110a28
[<80110a28>] 0x80110a28
[..snip..]

The current code does not request the GPIO and attempts
to set its direction, which is a violation of the GPIO API.
This patch also unhardcode the GPIO we request and use
the one we defined in the button driver.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Now that we have removed all warnings from the ar7 board code we can use
-Werror like on other MIPS boards.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch fixes the following build failure when CONFIG_SERIAL_8250
is not enabled in the kernel configuration:
arch/mips/ar7/built-in.o: In function 'ar7_register_devices':
platform.c:(.init.text+0x61c): undefined reference to 'early_serial_setup'
platform.c:(.init.text+0x61c): relocation truncated to fit: R_MIPS_26 against 'early_serial_setup'
platform.c:(.init.text+0x68c): undefined reference to 'early_serial_setup'
platform.c:(.init.text+0x68c): relocation truncated to fit: R_MIPS_26 against 'early_serial_setup'
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch fixes the following build warning:
arch/mips/ar7/memory.c: In function 'memsize':
arch/mips/ar7/memory.c:55: warning: passing argument 1 of 'writel' makes integer from pointer without a cast
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Some SiliconImage PCIe SATA controlers are not detected when the bus
numbers differ.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The rbtx4939_update_ioc_pen() expects txx9_ce_res[] already initialized.
Call it after tx4939_setup().
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The current interrupt handling code for the MSP4200 always masks an
interrupt before acknowledging it.  This is not required, as that will be
handled by the level interrupt handler.  This change simplifies the MSP4200
code to remove the masking in the ack routine, and makes sure that the
minimum required operation is performed for masking and acking, rather
than always both masking and acking the interrupt.
Signed-off-by: NShane McDonald <mcdonald.shane@gmail.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Trying to build a PMC-Sierra MSP4200 VoIP gateway defconfig will not work
since MIPS34K_MISSED_ITLB_WAR is not defined for all boards supported
within pmc-serria/msp71xx. This patch defines MIPS34K_MISSED_ITLB_WAR to
prevent such build failures:

  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-mips
  CC      arch/mips/kernel/asm-offsets.s
In file included fromlinux-msp71xx/linux-2.6.29/arch/mips/include/asm/bitops.h:24,
                 from include/linux/bitops.h:17,
                 from include/linux/kernel.h:15,
                 from include/linux/sched.h:52,
                 from arch/mips/kernel/asm-offsets.c:13:
linux-msp71xx/linux-2.6.29/arch/mips/include/asm/war.h:241:2: error: #error Check setting of MIPS34K_MISSED_ITLB_WAR for your
platform

This fixes a compile error when building for the MSP4200 boards.  Identical
patches to fix this were send by

  Florian Fainelli <florian@openwrt.org>
  Shane McDonald <mcdonald.shane@gmail.com>
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Trying to build MSP4200 VoIP defconfig also fails on msp_irq_slp.c with a
non-existing reference to mask_slp_irq, which is in turn mask_msp_slp_irq.
Passed that, we will also miss a comma when calling
set_irq_chip_and_handler. This patch fixes both issues.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Acked-by: NShane McDonald <mcdonald.shane@gmail.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Loading of modules with unresolved weak symbols fails on MIPS
since '88173507'.

Modules: handle symbols that have a zero value

The module subsystem cannot handle symbols that are zero.  If symbols
are present that have a zero value then the module resolver prints out a
message that these symbols are unresolved.

We have to use IS_ERR_VALUE() to check that a symbol has been resolved
or not.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NChris Dearman <chris@mips.com>
Signed-off-by: NRaghu Gandham <raghu@mips.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>