- 05 1月, 2011 3 次提交
-
-
由 Huang Ying 提交于
Prevent the long delay in io_check_error making NMI watchdog timeout. Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NDon Zickus <dzickus@redhat.com> LKML-Reference: <1294198689-15447-3-git-send-email-dzickus@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Dongdong Deng 提交于
The spin_lock_debug/rcu_cpu_stall detector uses trigger_all_cpu_backtrace() to dump cpu backtrace. Therefore it is possible that trigger_all_cpu_backtrace() could be called at the same time on different CPUs, which triggers and 'unknown reason NMI' warning. The following case illustrates the problem: CPU1 CPU2 ... CPU N trigger_all_cpu_backtrace() set "backtrace_mask" to cpu mask | generate NMI interrupts generate NMI interrupts ... \ | / \ | / The "backtrace_mask" will be cleaned by the first NMI interrupt at nmi_watchdog_tick(), then the following NMI interrupts generated by other cpus's arch_trigger_all_cpu_backtrace() will be taken as unknown reason NMI interrupts. This patch uses a test_and_set to avoid the problem, and stop the arch_trigger_all_cpu_backtrace() from calling to avoid dumping a double cpu backtrace info when there is already a trigger_all_cpu_backtrace() in progress. Signed-off-by: NDongdong Deng <dongdong.deng@windriver.com> Reviewed-by: NBruce Ashfield <bruce.ashfield@windriver.com> Cc: fweisbec@gmail.com LKML-Reference: <1294198689-15447-2-git-send-email-dzickus@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NDon Zickus <dzickus@redhat.com>
-
由 Don Zickus 提交于
There are some paths that walk the die_chain with preemption on. Make sure we are in an NMI call before we start doing anything. This was triggered by do_general_protection calling notify_die with DIE_GPF. Reported-by: NJan Kiszka <jan.kiszka@web.de> Signed-off-by: NDon Zickus <dzickus@redhat.com> LKML-Reference: <1294198689-15447-1-git-send-email-dzickus@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 04 1月, 2011 2 次提交
-
-
由 Thomas Renninger 提交于
Add these new power trace events: power:cpu_idle power:cpu_frequency power:machine_suspend The old C-state/idle accounting events: power:power_start power:power_end Have now a replacement (but we are still keeping the old tracepoints for compatibility): power:cpu_idle and power:power_frequency is replaced with: power:cpu_frequency power:machine_suspend is newly introduced. Jean Pihet has a patch integrated into the generic layer (kernel/power/suspend.c) which will make use of it. the type= field got removed from both, it was never used and the type is differed by the event type itself. perf timechart userspace tool gets adjusted in a separate patch. Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NIngo Molnar <mingo@elte.hu> Acked-by: NArjan van de Ven <arjan@linux.intel.com> Acked-by: NJean Pihet <jean.pihet@newoldbits.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: rjw@sisk.pl LKML-Reference: <1294073445-14812-3-git-send-email-trenn@suse.de> Signed-off-by: NIngo Molnar <mingo@elte.hu> LKML-Reference: <1290072314-31155-2-git-send-email-trenn@suse.de>
-
由 Andrew Morton 提交于
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=25702Reported-by: NMartin Ettl <ettl.martin@gmx.de> Cc: David Howells <dhowells@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 1月, 2011 5 次提交
-
-
由 Aric D. Blumer 提交于
Before this patch, the following error would sometimes occur after a resume on pxa3xx: /path/to/mm/memory.c:144: bad pmd 8040542e. The problem was that a temporary page table mapping was being improperly restored. The PXA3xx resume code creates a temporary mapping of resume_turn_on_mmu to avoid a prefetch abort. The pxa3xx_resume_after_mmu code requires that the r1 register holding the address of this mapping not be modified, however, resume_turn_on_mmu does modify it. It is mostly correct in that r1 receives the base table address, but it may also get other bits in 13:0. This results in pxa3xx_resume_after_mmu restoring the original mapping to the wrong place, corrupting memory and leaving the temporary mapping in place. Signed-off-by: NMatt Reimer <mreimer@sdgsystems.com> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Mike Rapoport 提交于
The commit 6ac6b817 (ARM: pxa: encode IRQ number into .nr_irqs) removed definition of ITE_LAST_IRQ which caused the following build error: CC arch/arm/common/it8152.o arch/arm/common/it8152.c: In function 'it8152_init_irq': arch/arm/common/it8152.c:86: error: 'IT8152_LAST_IRQ' undeclared (first use in this function) arch/arm/common/it8152.c:86: error: (Each undeclared identifier is reported only once arch/arm/common/it8152.c:86: error: for each function it appears in.) make[2]: *** [arch/arm/common/it8152.o] Error 1 Defining the IT8152_LAST_IRQ in the arch/arm/include/hardware/it8152.c fixes the build. Signed-off-by: NMike Rapoport <mike@compulab.co.il> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Lennert Buytenhek 提交于
As arch/arm/mach-pxa/eseries.c references w100fb_gpio_{read,write}() directly. Signed-off-by: NLennert Buytenhek <buytenh@secretlab.ca> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Robert Richter 提交于
Disable preemption in init_ibs(). The function only checks the ibs capabilities and sets up pci devices (if necessary). It runs only on one cpu but operates with the local APIC and some MSRs, thus it is better to disable preemption. [ 7.034377] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/483 [ 7.034385] caller is setup_APIC_eilvt+0x155/0x180 [ 7.034389] Pid: 483, comm: modprobe Not tainted 2.6.37-rc1-20101110+ #1 [ 7.034392] Call Trace: [ 7.034400] [<ffffffff812a2b72>] debug_smp_processor_id+0xd2/0xf0 [ 7.034404] [<ffffffff8101e985>] setup_APIC_eilvt+0x155/0x180 [ ... ] Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22812 Reported-by: <atswartz@gmail.com> Signed-off-by: NRobert Richter <robert.richter@amd.com> Cc: oprofile-list@lists.sourceforge.net <oprofile-list@lists.sourceforge.net> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Dan Carpenter <error27@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: <stable@kernel.org> [2.6.37.x] LKML-Reference: <20110103111514.GM4739@erda.amd.com> [ small cleanups ] Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Axel Lin 提交于
This patch fixes below build error by adding the missing asm/memory.h, which is needed for arch_is_coherent(). $ make pxa3xx_defconfig; make CC init/do_mounts_rd.o In file included from include/linux/list_bl.h:5, from include/linux/rculist_bl.h:7, from include/linux/dcache.h:7, from include/linux/fs.h:381, from init/do_mounts_rd.c:3: include/linux/bit_spinlock.h: In function 'bit_spin_unlock': include/linux/bit_spinlock.h:61: error: implicit declaration of function 'arch_is_coherent' make[1]: *** [init/do_mounts_rd.o] Error 1 make: *** [init] Error 2 Signed-off-by: NAxel Lin <axel.lin@gmail.com> Acked-by: NPeter Huewe <peterhuewe@gmx.de> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 02 1月, 2011 1 次提交
-
-
由 Avi Kivity 提交于
isr_ack is never initialized. So, until the first PIC reset, interrupts may fail to be injected. This can cause Windows XP to fail to boot, as reported in the fallout from the fix to https://bugzilla.kernel.org/show_bug.cgi?id=21962. Reported-and-tested-by: NNicolas Prochazka <prochazka.nicolas@gmail.com> Signed-off-by: NAvi Kivity <avi@redhat.com>
-
- 29 12月, 2010 2 次提交
-
-
由 Avi Kivity 提交于
We use the physical address instead of the base gfn for the four PAE page directories we use in unpaged mode. When the guest accesses an address above 1GB that is backed by a large host page, a BUG_ON() in kvm_mmu_set_gfn() triggers. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=21962Reported-and-tested-by: NNicolas Prochazka <prochazka.nicolas@gmail.com> KVM-Stable-Tag. Signed-off-by: NAvi Kivity <avi@redhat.com>
-
由 Imre Kaloz 提交于
arm: export dma_set_coherent_mask While a regression was fixed with commit 710224fa (arm: fix "arm: fix pci_set_consistent_dma_mask for dmabounce devices"), a new one was introduced as dma_set_coherent_mask wasn't exported for modules. This patch takes care for this issue. Signed-off-by: NImre Kaloz <kaloz@openwrt.org> Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 27 12月, 2010 1 次提交
-
-
由 Jesper Juhl 提交于
In arch/x86/kernel/microcode_intel.c::generic_load_microcode() we have this: while (leftover) { ... if (get_ucode_data(mc, ucode_ptr, mc_size) || microcode_sanity_check(mc) < 0) { vfree(mc); break; } ... } if (mc) vfree(mc); This will cause a double free of 'mc'. This patch fixes that by just removing the vfree() call in the loop since 'mc' will be freed nicely just after we break out of the loop. There's also a second change in the patch. I noticed a lot of checks for pointers being NULL before passing them to vfree(). That's completely redundant since vfree() deals gracefully with being passed a NULL pointer. Removing the redundant checks yields a nice size decrease for the object file. Size before the patch: text data bss dec hex filename 4578 240 1032 5850 16da arch/x86/kernel/microcode_intel.o Size after the patch: text data bss dec hex filename 4489 240 984 5713 1651 arch/x86/kernel/microcode_intel.o Signed-off-by: NJesper Juhl <jj@chaosbits.net> Acked-by: NTigran Aivazian <tigran@aivazian.fsnet.co.uk> Cc: Shaohua Li <shaohua.li@intel.com> LKML-Reference: <alpine.LNX.2.00.1012251946100.10759@swampdragon.chaosbits.net> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 24 12月, 2010 6 次提交
-
-
由 Todd Android Poynor 提交于
If the irqsoff tracer is in use, stop tracing the interrupt disable interval when returning to userspace. Tracing userspace execution time as interrupts disabled time is not helpful for kernel performance analysis purposes. Only do so if the irqsoff tracer is enabled, to avoid overhead for lockdep, which doesn't care. Signed-off-by: NTodd Poynor <toddpoynor@google.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Stephen Warren 提交于
... and also remove misleading comment stating that this header is auto-generated. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NUwe Kleine-Knig <u.kleine-koenig@pengutronix.de> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Paul Mundt 提交于
The master clock initialization for SH7201 was wholly bogus. Users of the legacy API must initialize the clock rate through the struct clk itself rather than returning the clock frequency. Given that the init function itself is void, returning the frequency isn't terribly effective. Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Paul Mundt 提交于
With some recent tidying of duplicate register definitions the se7206 IRQ code broke: arch/sh/boards/mach-se/7206/irq.c: error: 'INTC_ICR' undeclared (first use in this function) arch/sh/boards/mach-se/7206/irq.c: error: (Each undeclared identifier is reported only once arch/sh/boards/mach-se/7206/irq.c: error: for each function it appears in.) Fix it up. Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Paul Mundt 提交于
Some of the SH4-202 code was overlooked in the set_rate() API conversion, resulting in: arch/sh/kernel/cpu/sh4/clock-sh4-202.c: error: too many arguments to function 'clk->ops->set_rate' Fix it up. Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Wolfram Sang 提交于
Fix build errors like these (from a randconfig and my defconfig for a custom board): src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:549: error: dereferencing pointer to incomplete type: 1 errors in 1 logs src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:636: error: implicit declaration of function 'nonseekable_open': 1 errors in 1 logs src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:657: error: variable 'mpc52xx_wdt_fops' has initializer but incomplete type: 1 errors in 1 logs src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: excess elements in struct initializer: 1 errors in 1 logs src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: unknown field 'owner' specified in initializer: 1 errors in 1 logs ... Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 23 12月, 2010 1 次提交
-
-
由 Don Zickus 提交于
The x86 arch has shifted its use of the nmi_watchdog from a local implementation to the global one provide by kernel/watchdog.c. This shift has caused a whole bunch of compile problems under different config options. I attempt to simplify things with the patch below. In order to simplify things, I had to come to terms with the meaning of two terms ARCH_HAS_NMI_WATCHDOG and CONFIG_HARDLOCKUP_DETECTOR. Basically they mean the same thing, the former on a local level and the latter on a global level. With the old x86 nmi watchdog gone, there is no need to rely on defining the ARCH_HAS_NMI_WATCHDOG variable because it doesn't make sense any more. x86 will now use the global implementation. The changes below do a few things. First it changes the few places that relied on ARCH_HAS_NMI_WATCHDOG to use CONFIG_X86_LOCAL_APIC (the former was an alias for the latter anyway, so nothing unusual here). Those pieces of code were relying more on local apic functionality the nmi watchdog functionality, so the change should make sense. Second, I removed the x86 implementation of touch_nmi_watchdog(). It isn't need now, instead x86 will rely on kernel/watchdog.c's implementation. Third, I removed the #define ARCH_HAS_NMI_WATCHDOG itself from x86. And tweaked the include/linux/nmi.h file to tell users to look for an externally defined touch_nmi_watchdog in the case of ARCH_HAS_NMI_WATCHDOG _or_ CONFIG_HARDLOCKUP_DETECTOR. This changes removes some of the ugliness in that file. Finally, I added a Kconfig dependency for CONFIG_HARDLOCKUP_DETECTOR that said you can't have ARCH_HAS_NMI_WATCHDOG _and_ CONFIG_HARDLOCKUP_DETECTOR. You can only have one nmi_watchdog. Tested with ARCH=i386: allnoconfig, defconfig, allyesconfig, (various broken configs) ARCH=x86_64: allnoconfig, defconfig, allyesconfig, (various broken configs) Hopefully, after this patch I won't get any more compile broken emails. :-) v3: changed a couple of 'linux/nmi.h' -> 'asm/nmi.h' to pick-up correct function prototypes when CONFIG_HARDLOCKUP_DETECTOR is not set. Signed-off-by: NDon Zickus <dzickus@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: fweisbec@gmail.com LKML-Reference: <1293044403-14117-1-git-send-email-dzickus@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 22 12月, 2010 1 次提交
-
-
由 Yauhen Kharuzhy 提交于
The AT91 MCI has special SDIO transfer types: SDIO block and SDIO byte transfers, but at91_mci driver doesn't use them and handles all SDIO transfers as ordinary MMC block transfers. This causes problems for multiple-block SDIO transfers (in particular for 256-bytes blocks). Fix this situation by checking the opcode for SDIO CMD53 and setting the transfer type in the AT91_MCI_CMDR register properly. This patch was tested with libertas SDIO driver: problem with TX timeouts on big packets was eliminated. Signed-off-by: NYauhen Kharuzhy <yauhen.kharuzhy@promwad.com> Cc: <stable@kernel.org> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 21 12月, 2010 1 次提交
-
-
由 Nicolas Pitre 提交于
The cnt32_to_63 algorithm relies on proper counter data evaluation ordering to work properly. This was missing from the provided documentation. Let's augment the documentation with the missing usage constraint and fix the only instance that got it wrong. Signed-off-by: NNicolas Pitre <nico@fluxnic.net> Acked-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 12月, 2010 3 次提交
-
-
由 Nicolas Pitre 提交于
Since commit 3e4d3af5 "mm: stack based kmap_atomic()", it is actively wrong to rely on fixed kmap type indices (namely KM_L2_CACHE) as kmap_atomic() totally ignores them and a concurrent instance of it may happily reuse any slot for any purpose. Because kmap_atomic() is now able to deal with reentrancy, we can get rid of the ad hoc mapping here. While the code is made much simpler, there is a needless cache flush introduced by the usage of __kunmap_atomic(). It is not clear if the performance difference to remove that is worth the cost in code maintenance (I don't think there are that many highmem users on that platform anyway) but that should be reconsidered when/if someone cares enough to do some measurements. Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
-
由 Nicolas Pitre 提交于
Since commit 3e4d3af5 "mm: stack based kmap_atomic()", it is actively wrong to rely on fixed kmap type indices (namely KM_L2_CACHE) as kmap_atomic() totally ignores them and a concurrent instance of it may happily reuse any slot for any purpose. Because kmap_atomic() is now able to deal with reentrancy, we can get rid of the ad hoc mapping here, and we even don't have to disable IRQs anymore (highmem case). While the code is made much simpler, there is a needless cache flush introduced by the usage of __kunmap_atomic(). It is not clear if the performance difference to remove that is worth the cost in code maintenance (I don't think there are that many highmem users on that platform if at all anyway). Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
-
由 Nicolas Pitre 提交于
Since commit 3e4d3af5 "mm: stack based kmap_atomic()", it is no longer necessary to carry an ad hoc version of kmap_atomic() added in commit 7e5a69e8 "ARM: 6007/1: fix highmem with VIPT cache and DMA" to cope with reentrancy. In fact, it is now actively wrong to rely on fixed kmap type indices (namely KM_L1_CACHE) as kmap_atomic() totally ignores them now and a concurrent instance of it may reuse any slot for any purpose. Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
-
- 19 12月, 2010 2 次提交
-
-
由 Robert Richter 提交于
This patch adds support for up to 6 hardware counters for AMD family 15h cpus. There is a new MSR range for hardware counters beginning at MSRC001_0200 Performance Event Select (PERF_CTL0). Signed-off-by: NRobert Richter <robert.richter@amd.com>
-
由 Robert Richter 提交于
This patch adds support for AMD family 15h (Interlagos/Valencia/ Zambezi) cpus. Signed-off-by: NRobert Richter <robert.richter@amd.com>
-
- 18 12月, 2010 10 次提交
-
-
由 Russell King 提交于
We should not be incrementing mm_users when we startup a secondary CPU - doing so results in mm_users incrementing by one each time we hotplug a CPU, which will eventually wrap, and will cause problems. Other architectures such as x86 do not increment mm_users, but only mm_count, so we follow that pattern. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 H. Peter Anvin 提交于
Keep the crash kernel address below 512 MiB for 32 bits and 896 MiB for 64 bits. For 32 bits, this retains compatibility with earlier kernel releases, and makes it work even if the vmalloc= setting is adjusted. For 64 bits, we should be able to increase this substantially once a hard-coded limit in kexec-tools is fixed. Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Stanislaw Gruszka <sgruszka@redhat.com> Cc: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <20101217195035.GE14502@redhat.com>
-
由 Chris Metcalf 提交于
The current tile rt_sigreturn() syscall pattern uses the common idiom of loading up pt_regs with all the saved registers from the time of the signal, then anticipating the fact that we will clobber the ABI "return value" register (r0) as we return from the syscall by setting the rt_sigreturn return value to whatever random value was in the pt_regs for r0. However, this breaks in our 64-bit kernel when running "compat" tasks, since we always sign-extend the "return value" register to properly handle returned pointers that are in the upper 2GB of the 32-bit compat address space. Doing this to the sigreturn path then causes occasional random corruption of the 64-bit r0 register. Instead, we stop doing the crazy "load the return-value register" hack in sigreturn. We already have some sigreturn-specific assembly code that we use to pass the pt_regs pointer to C code. We extend that code to also set the link register to point to a spot a few instructions after the usual syscall return address so we don't clobber the saved r0. Now it no longer matters what the rt_sigreturn syscall returns, and the pt_regs structure can be cleanly and completely reloaded. Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
-
由 Chris Metcalf 提交于
Previously we were just setting up the "tp" register in the new task as started by clone() in libc. However, this is not quite right, since in principle a signal might be delivered to the new task before it had its TLS set up. (Of course, this race window still exists for resetting the libc getpid() cached value in the new task, in principle. But in any case, we are now doing this exactly the way all other architectures do it.) This change is important for 2.6.37 since the tile glibc we will be submitting upstream will not set TLS in user space any more, so it will only work on a kernel that has this fix. It should also be taken for 2.6.36.x in the stable tree if possible. Signed-off-by: NChris Metcalf <cmetcalf@tilera.com> Cc: stable <stable@kernel.org>
-
由 Kevin Cernekee 提交于
Seen with malta_defconfig on Linus' tree: CC arch/mips/mm/sc-mips.o arch/mips/mm/sc-mips.c: In function 'mips_sc_is_activated': arch/mips/mm/sc-mips.c:77: error: 'config2' undeclared (first use in this function) arch/mips/mm/sc-mips.c:77: error: (Each undeclared identifier is reported only once arch/mips/mm/sc-mips.c:77: error: for each function it appears in.) arch/mips/mm/sc-mips.c:81: error: 'tmp' undeclared (first use in this function) make[2]: *** [arch/mips/mm/sc-mips.o] Error 1 make[1]: *** [arch/mips/mm] Error 2 make: *** [arch/mips] Error 2 [Ralf: Cosmetic changes to minimize the number of arguments passed to mips_sc_is_activated] Signed-off-by: NKevin Cernekee <cernekee@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/1752/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Bjorn Helgaas 提交于
This prevents allocation of the last 2MB before 4GB. The experiment described here shows Windows 7 ignoring the last 1MB: https://bugzilla.kernel.org/show_bug.cgi?id=23542#c27 This patch ignores the top 2MB instead of just 1MB because H. Peter Anvin says "There will be ROM at the top of the 32-bit address space; it's a fact of the architecture, and on at least older systems it was common to have a shadow 1 MiB below." Acked-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Bjorn Helgaas 提交于
When we allocate address space, e.g., to assign it to a PCI device, don't allocate anything mentioned in the BIOS E820 memory map. On recent machines (2008 and newer), we assign PCI resources from the windows described by the ACPI PCI host bridge _CRS. On many Dell machines, these windows overlap some E820 reserved areas, e.g., BIOS-e820: 00000000bfe4dc00 - 00000000c0000000 (reserved) pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff] If we put devices at 0xbff00000, they don't work, probably because that's really RAM, not I/O memory. This patch prevents that by removing the 0xbfe4dc00-0xbfffffff area from the "available" resource. I'm not very happy with this solution because Windows solves the problem differently (it seems to ignore E820 reserved areas and it allocates top-down instead of bottom-up; details at comment 45 of the bugzilla below). That means we're vulnerable to BIOS defects that Windows would not trip over. For example, if BIOS described a device in ACPI but didn't mention it in E820, Windows would work fine but Linux would fail. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=16228Acked-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Bjorn Helgaas 提交于
This implements arch_remove_reservations() so allocate_resource() can avoid any arch-specific reserved areas. This currently just avoids the BIOS area (the first 1MB), but could be used for E820 reserved areas if that turns out to be necessary. We previously avoided this area in pcibios_align_resource(). This patch moves the test from that PCI-specific path to a generic path, so *all* resource allocations will avoid this area. Acked-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Bjorn Helgaas 提交于
This reverts commit dc9887dc. Acked-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Bjorn Helgaas 提交于
This reverts commit 1af3c2e4. Acked-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 17 12月, 2010 2 次提交
-
-
由 Christian Glindkamp 提交于
As PControl G20 is a carrier board for the Stamp9G20 SoM, some code can be shared. Therefore board-stamp9g20.c is refactored to allow reusing the SoM initialization and board-pcontrol-g20.c is modified to use it. Signed-off-by: NChristian Glindkamp <christian.glindkamp@taskit.de> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Ryan Mallon 提交于
The uhpck clock should be divided from the utmi clock, not its parent (main). This change is mostly cosmetic as the uhpck rate value is not used anywhere except for the debugfs clock output. Signed-off-by: NRyan Mallon <ryan@bluewatersys.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-