- 08 8月, 2009 1 次提交
-
-
由 Yinghai Lu 提交于
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>
-
- 05 8月, 2009 1 次提交
-
-
由 Alok Kataria 提交于
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>
-
- 04 8月, 2009 38 次提交
-
-
由 Subrata Modak 提交于
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>
-
由 Jack Steiner 提交于
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>
-
由 Jan Beulich 提交于
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>
-
由 Yinghai Lu 提交于
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>
-
由 Jack Steiner 提交于
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>
-
由 Jack Steiner 提交于
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>
-
由 Jack Steiner 提交于
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>
-
由 Jack Steiner 提交于
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>
-
由 H. Peter Anvin 提交于
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>
-
由 Borislav Petkov 提交于
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>
-
由 H. Peter Anvin 提交于
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>
-
由 Paul Mackerras 提交于
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>
-
由 Paul Mackerras 提交于
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>
-
由 Thomas Hellstrom 提交于
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>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
None of these is used outside the VPE loader. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
This may happen if a bad sequence of relocations is being encountered. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Raghu Gandham 提交于
Signed-off-by: NRaghu Gandham <raghu@mips.com> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
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>
-
由 David Daney 提交于
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>
-
由 Roel Kluin 提交于
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>
-
由 Julia Lawall 提交于
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>
-
由 Florian Fainelli 提交于
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>
-
由 Florian Fainelli 提交于
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>
-
由 Florian Fainelli 提交于
Signed-off-by: NFlorian Fainelli <florian@openwrt.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Florian Fainelli 提交于
Signed-off-by: NFlorian Fainelli <florian@openwrt.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Florian Fainelli 提交于
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>
-
由 Roel Kluin 提交于
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Florian Fainelli 提交于
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>
-
由 David Daney 提交于
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>
-
由 Atsushi Nemoto 提交于
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>
-
由 Shane McDonald 提交于
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>
-
由 Florian Fainelli 提交于
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>
-
由 Florian Fainelli 提交于
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>
-
由 Gabor Juhos 提交于
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>
-
由 Kurt Martin 提交于
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>
-