summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2008-10-10Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds2-0/+199
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: skcipher - Use RNG interface instead of get_random_bytes crypto: rng - RNG interface and implementation crypto: api - Add fips_enable flag crypto: skcipher - Move IV generators into their own modules crypto: cryptomgr - Test ciphers using ECB crypto: api - Use test infrastructure crypto: cryptomgr - Add test infrastructure crypto: tcrypt - Add alg_test interface crypto: tcrypt - Abort and only log if there is an error crypto: crc32c - Use Intel CRC32 instruction crypto: tcrypt - Avoid using contiguous pages crypto: api - Display larval objects properly crypto: api - Export crypto_alg_lookup instead of __crypto_alg_lookup crypto: Kconfig - Replace leading spaces with tabs
2008-10-10Merge phase #1 of ↵Linus Torvalds81-1238/+2247
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip This merges phase 1 of the x86 tree, which is a collection of branches: x86/alternatives, x86/cleanups, x86/commandline, x86/crashdump, x86/debug, x86/defconfig, x86/doc, x86/exports, x86/fpu, x86/gart, x86/idle, x86/mm, x86/mtrr, x86/nmi-watchdog, x86/oprofile, x86/paravirt, x86/reboot, x86/sparse-fixes, x86/tsc, x86/urgent and x86/vmalloc and as Ingo says: "these are the easiest, purely independent x86 topics with no conflicts, in one nice Octopus merge". * 'x86-v28-for-linus-phase1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (147 commits) x86: mtrr_cleanup: treat WRPROT as UNCACHEABLE x86: mtrr_cleanup: first 1M may be covered in var mtrrs x86: mtrr_cleanup: print out correct type v2 x86: trivial printk fix in efi.c x86, debug: mtrr_cleanup print out var mtrr before change it x86: mtrr_cleanup try gran_size to less than 1M, v3 x86: mtrr_cleanup try gran_size to less than 1M, cleanup x86: change MTRR_SANITIZER to def_bool y x86, debug printouts: IOMMU setup failures should not be KERN_ERR x86: export set_memory_ro and set_memory_rw x86: mtrr_cleanup try gran_size to less than 1M x86: mtrr_cleanup prepare to make gran_size to less 1M x86: mtrr_cleanup safe to get more spare regs now x86_64: be less annoying on boot, v2 x86: mtrr_cleanup hole size should be less than half of chunk_size, v2 x86: add mtrr_cleanup_debug command line x86: mtrr_cleanup optimization, v2 x86: don't need to go to chunksize to 4G x86_64: be less annoying on boot x86, olpc: fix endian bug in openfirmware workaround ...
2008-10-09[CPUFREQ] correct broken links and email addressesNémeth Márton2-2/+2
Replace the no longer working links and email address in the documentation and in source code. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Dave Jones <davej@redhat.com>
2008-10-08[MIPS] Sibyte: Register PIO PATA device only for Swarm and Litte SurRalf Baechle1-0/+4
Symbol name spaghetti which is too complicated to cleanup on this stage of the release cycle breaks the build on BCM1480 platforms. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-07Merge branch 'for_linus' of ↵Linus Torvalds1-6/+1
git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb: kgdb: call touch_softlockup_watchdog on resume kgdb, x86: Avoid invoking kgdb_nmicallback twice per NMI
2008-10-07Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds1-9/+11
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: gart iommu have direct mapping when agp is present too
2008-10-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6Linus Torvalds2-1/+83
* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: ide: workaround for bogus gcc warning in ide_sysfs_register_port() ide-cd: Optiarc DVD RW AD-7200A does play audio IDE: Fix platform device registration in Swarm IDE driver (v2) ide-dma: fix ide_build_dmatable() for TRM290 ide-cd: temporary tray close fix
2008-10-07Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds2-11/+17
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] IP27: Fix build errors if CONFIG_MAPPED_KERNEL=y [MIPS] Fix CMP Kconfig configuration and mark as broken.
2008-10-06kgdb, x86: Avoid invoking kgdb_nmicallback twice per NMIJan Kiszka1-6/+1
Stress-testing KVM's latest NMI support with kgdbts inside an SMP guest, I came across spurious unhandled NMIs while running the singlestep test. Looking closer at the code path each NMI takes when KGDB is enabled, I noticed that kgdb_nmicallback is called twice per event: One time via DIE_NMI_IPI notification, the second time on DIE_NMI. Removing the first invocation cures the unhandled NMIs here. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2008-10-06x86 ACPI: Blacklist two HP machines with buggy BIOSesRafael J. Wysocki1-0/+16
There is a bug in the BIOSes of some HP boxes with AMD Turions which connects IO-APIC pins with ACPI thermal trip points in such a way that if the state of the IO-APIC is not as expected by the (buggy) BIOS, the thermal trip points are set to insanely low values (usually all of them become 16 degrees Celsius). As a result, thermal throttling kicks in and knock the system down to its shoes. Unfortunately some of the recent IO-APIC changes made the bug show up. To prevent this from happening, blacklist machines that are known to be affected (nx6115 and 6715b in this particular case). This fixes http://bugzilla.kernel.org/show_bug.cgi?id=11516 listed as a regression from 2.6.26. On my box it was caused by: commit 691874fa96d6349a8b60f8ea9c2bae52ece79941 Author: Maciej W. Rozycki <macro@linux-mips.org> Date: Tue May 27 21:19:51 2008 +0100 x86: I/O APIC: timer through 8259A second-chance Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> and the whole story is described in this (huge) thread: http://marc.info/?l=linux-kernel&m=121358440508410&w=4 Matthew Garrett told us about that happening on the nx6125: http://marc.info/?l=linux-kernel&m=121396307411930&w=4 and then Maciej analysed the breakage on the basis of a DSDT from the nx6325: http://marc.info/?l=linux-kernel&m=121401068718826&w=4 As far as the Dmitry's and Jason's boxes are concerned, I recognized the symptoms and asked them to verify that the blacklisting helped. It appears that the buggy BIOS code has been copy-pasted to the entire range of machines, for no good reason. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Jason Vas Dias <jason.vas.dias@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-06Merge branches 'x86/alternatives', 'x86/cleanups', 'x86/commandline', ↵Ingo Molnar63-697/+1162
'x86/crashdump', 'x86/debug', 'x86/defconfig', 'x86/doc', 'x86/exports', 'x86/fpu', 'x86/gart', 'x86/idle', 'x86/mm', 'x86/mtrr', 'x86/nmi-watchdog', 'x86/oprofile', 'x86/paravirt', 'x86/reboot', 'x86/sparse-fixes', 'x86/tsc', 'x86/urgent' and 'x86/vmalloc' into x86-v28-for-linus-phase1
2008-10-06Merge branch 'x86/tracehook' into x86-v28-for-linus-phase1Ingo Molnar4-65/+30
Conflicts: arch/x86/kernel/signal_64.c Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-06Merge branch 'x86/prototypes' into x86-v28-for-linus-phase1Ingo Molnar19-10/+26
Conflicts: arch/x86/kernel/process_32.c Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-06Merge branch 'x86/pebs' into x86-v28-for-linus-phase1Ingo Molnar6-471/+1036
Conflicts: include/asm-x86/ds.h Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-06Merge branch 'x86/header-guards' into x86-v28-for-linus-phase1Ingo Molnar3-4/+4
Conflicts: include/asm-x86/dma-mapping.h include/asm-x86/gpio.h include/asm-x86/idle.h include/asm-x86/kvm_host.h include/asm-x86/namei.h include/asm-x86/uaccess.h Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-06[MIPS] IP27: Fix build errors if CONFIG_MAPPED_KERNEL=yRalf Baechle1-0/+1
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-06[MIPS] Fix CMP Kconfig configuration and mark as broken.Ralf Baechle1-11/+16
Because sync-r4k.c doesn't build. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-05IDE: Fix platform device registration in Swarm IDE driver (v2)Ralf Baechle2-1/+83
The Swarm IDE driver uses a release method which is defined in the driver itself thus potentially oopsable. The simple fix would be to just leak the device but this patch goes the full length and moves the entire handling of the platform device in the platform code and retains only the platform driver code in drivers/ide/mips/swarm.c. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Cc: "Maciej W. Rozycki" <macro@linux-mips.org> Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> [bart: remove no longer needed BLK_DEV_IDE_SWARM from ide/Kconfig] Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2008-10-05x86: gart iommu have direct mapping when agp is present tooYinghai Lu1-9/+11
move init_memory_mapping() out of init_k8_gatt. for: http://bugzilla.kernel.org/show_bug.cgi?id=11676 2.6.27-rc2 to rc8, apgart fails, iommu=soft works, regression This is needed because we need to map the GART aperture even if the GATT is not initialized. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-05x86: mtrr_cleanup: treat WRPROT as UNCACHEABLEYinghai Lu1-1/+4
For the purpose of MTRR canonicalization, treat WRPROT as UNCACHEABLE. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-10-05x86: mtrr_cleanup: first 1M may be covered in var mtrrsYinghai Lu1-0/+9
The first 1M is don't care when it comes to the variables MTRRs. Cover it as WB as a heuristic approximation; this is generally what we want to minimize the number of registers. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-10-05x86: mtrr_cleanup: print out correct type v2Yinghai Lu1-1/+3
Print out the correct type when the Write Protected (WP) type is seen. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-10-04Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86 setup: correct segfault in generation of 32-bit reloc kernel
2008-10-04Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds14-297/+548
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] SMTC: Fix SMTC dyntick support. [MIPS] SMTC: Close tiny holes in the SMTC IPI replay system. [MIPS] SMTC: Fix holes in SMTC and FPU affinity support. [MIPS] SMTC: Build fix: Fix filename in Makefile [MIPS] Build fix: Fix irq flags type
2008-10-04x86 setup: correct segfault in generation of 32-bit reloc kernelH. Peter Anvin1-1/+1
Impact: segfault on build of a 32-bit relocatable kernel When converting arch/x86/boot/compressed/relocs.c to support unlimited sections, the computation of sym_strtab in walk_relocs() was done incorrectly. This causes a segfault for some people when building the relocatable 32-bit kernel. Pointed out by Anonymous <pageexec@freemail.hu>. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-10-03[S390] nohz: Fix __udelay.Heiko Carstens2-34/+56
This fixes a regression that came with 934b2857cc576ae53c92a66e63fce7ddcfa74691 ("[S390] nohz/sclp: disable timer on synchronous waits."). If udelay() gets called from a disabled context it sets the clock comparator to a value where it expects the next interrupt. When the interrupt happens the clock comparator gets not reset and therefore the interrupt condition doesn't get cleared. The result is an endless timer interrupt loop. In addition this patch fixes also the following: rcutorture reveals that our __udelay implementation is still buggy, since it might schedule tasklets, but prevents their execution: NOHZ: local_softirq_pending 42 NOHZ: local_softirq_pending 02 NOHZ: local_softirq_pending 142 NOHZ: local_softirq_pending 02 To fix this we make sure that only the clock comparator interrupt is enabled when the enabled wait psw is loaded. Also no code gets called anymore which might schedule tasklets. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-10-03[MIPS] SMTC: Fix SMTC dyntick support.Kevin D. Kissell8-273/+523
Rework of SMTC support to make it work with the new clock event system, allowing "tickless" operation, and to make it compatible with the use of the "wait_irqoff" idle loop. The new clocking scheme means that the previously optional IPI instant replay mechanism is now required, and has been made more robust. Signed-off-by: Kevin D. Kissell <kevink@paralogos.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-03[MIPS] SMTC: Close tiny holes in the SMTC IPI replay system.Kevin D. Kissell2-6/+6
Signed-off-by: Kevin D. Kissell <kevink@paralogos.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-03[MIPS] SMTC: Fix holes in SMTC and FPU affinity support.Kevin D. Kissell3-13/+14
Signed-off-by: Kevin D. Kissell <kevink@paralogos.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-03[MIPS] SMTC: Build fix: Fix filename in MakefileRalf Baechle1-1/+1
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-03[MIPS] Build fix: Fix irq flags typeRalf Baechle2-4/+4
Though from a hardware perspective it would be sensible to use only a 32-bit unsigned int type Linux defines interrupt flags to be stored in an unsigned long and nothing else. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-03x86: trivial printk fix in efi.cRuss Anderson1-2/+4
[patch] x86: Trivial printk fix in efi.c The following line is lacking a space between "memdesc" and "doesn't". "Kernel-defined memdescdoesn't match the one from EFI!" Fixed the printk by adding a space. Signed-off-by: Russ Anderson <rja@sgi.com> Cc: Russ Anderson <rja@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-03x86, debug: mtrr_cleanup print out var mtrr before change itYinghai Lu1-1/+24
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-03x86: mtrr_cleanup try gran_size to less than 1M, v3Yinghai Lu1-1/+1
J.A. Magallón reported: >> Also, on a 64 bit box with 4Gb, it gives this: >> >> cicely:~# cat /proc/mtrr >> reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 >> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1 >> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1 >> reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1 boundary handling has a problem ... fix it. Reported-by: J.A. Magallón <jamagallon@ono.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-03x86: mtrr_cleanup try gran_size to less than 1M, cleanupJ.A. Magallón1-2/+2
Patch below cleans up formatting, with space for big bases and sizes (64 Gb). Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-02powerpc: Fix boot hang regression on MPC8544DSKumar Gala1-1/+11
Commit 00c5372d37a78990c1530184a9c792ee60a30067 caused the MPC8544DS board to hang at boot. The MPC8544DS is unique in that it doesn't use the PCI slots on the ULI (unlike the MPC8572DS or MPC8610HPCD). So the dummy read at the end of the address space causes us to hang. We can detect the situation by comparing the bridge's BARs versus the root complex. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2008-10-01Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, vmi: fix broken LDT access x86: fix typo in enable_mtrr_cleanup early parameter
2008-10-01MN10300: Fix IRQ handlingDavid Howells3-28/+47
Fix the IRQ handling on the MN10300 arch. This patch makes a number of significant changes: (1) It separates the irq_chip definition for edge-triggered interrupts from the one for level-triggered interrupts. This is necessary because the MN10300 PIC latches the IRQ channel's interrupt request bit (GxICR_REQUEST), even after the device has ceased to assert its interrupt line and the interrupt channel has been disabled in the PIC. So for level-triggered interrupts we need to clear this bit when we re-enable - which is achieved by setting GxICR_DETECT but not GxICR_REQUEST when writing to the register. Not doing this results in spurious interrupts occurring because calling mask_ack() at the start of handle_level_irq() is insufficient - it fails to clear the REQUEST latch because the device that caused the interrupt is still asserting its interrupt line at this point. (2) IRQ disablement [irq_chip::disable_irq()] shouldn't clear the interrupt request flag for edge-triggered interrupts lest it lose an interrupt. (3) IRQ unmasking [irq_chip::unmask_irq()] also shouldn't clear the interrupt request flag for edge-triggered interrupts lest it lose an interrupt. (4) The end() operation is now left to the default (no-operation) as __do_IRQ() is compiled out. This may affect misrouted_irq(), but according to Thomas Gleixner it's the correct thing to do. (5) handle_level_irq() is used for edge-triggered interrupts rather than handle_edge_irq() as the MN10300 PIC latches interrupt events even on masked IRQ channels, thus rendering IRQ_PENDING unnecessary. It is sufficient to call mask_ack() at the start and unmask() at the end. (6) For level-triggered interrupts, ack() is now NULL as it's not used, and there is no effective ACK function on the PIC. mask_ack() is now the same as mask() as the latch continues to latch, even when the channel is masked. Further, the patch discards the disable() op implementation as its now the same as the mask() op implementation, which is used instead. It also discards the enable() op implementations as they're now the same as the unmask() op implementations, which are used instead. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-01x86: change MTRR_SANITIZER to def_bool yYinghai Lu1-2/+2
This option has been added in v2.6.26 as a default-disabled feature and went through several revisions since then. The feature fixes a wide range of MTRR setup problems that BIOSes leave us with: slow system, slow Xorg, slow system when adding lots of RAM, etc., so we want to enable it by default for v2.6.28. See: [Bug 10508] Upgrade to 4GB of RAM messes up MTRRs http://bugzilla.kernel.org/show_bug.cgi?id=10508 and the test results in: http://lkml.org/lkml/2008/9/29/273 1. hpa reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 reg01: base=0x13c000000 (5056MB), size= 64MB: uncachable, count=1 reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg03: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 will get Found optimal setting for mtrr clean up gran_size: 1M chunk_size: 128M num_reg: 6 lose RAM: 0M range0: 0000000000000000 - 00000000c0000000 Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB hole: 00000000bf700000 - 00000000c0000000 Setting variable MTRR 2, base: 3063MB, range: 1MB, type UC Setting variable MTRR 3, base: 3064MB, range: 8MB, type UC range0: 0000000100000000 - 0000000140000000 Setting variable MTRR 4, base: 4096MB, range: 1024MB, type WB hole: 000000013c000000 - 0000000140000000 Setting variable MTRR 5, base: 5056MB, range: 64MB, type UC 2. Dylan Taft reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg01: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg02: base=0x120000000 (4608MB), size= 256MB: write-back, count=1 reg03: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 reg04: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg05: base=0xc7e00000 (3198MB), size= 2MB: uncachable, count=1 reg06: base=0xc8000000 (3200MB), size= 128MB: uncachable, count=1 will get Found optimal setting for mtrr clean up gran_size: 1M chunk_size: 4M num_reg: 6 lose RAM: 0M range0: 0000000000000000 - 00000000c8000000 Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB Setting variable MTRR 2, base: 3072MB, range: 128MB, type WB hole: 00000000c7e00000 - 00000000c8000000 Setting variable MTRR 3, base: 3198MB, range: 2MB, type UC rangeX: 0000000100000000 - 0000000130000000 Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB 3. Gabriel reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 will get Found optimal setting for mtrr clean up gran_size: 1M chunk_size: 16M num_reg: 7 lose RAM: 0M range0: 0000000000000000 - 00000000d0000000 Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB hole: 00000000cf600000 - 00000000cf800000 Setting variable MTRR 3, base: 3318MB, range: 2MB, type UC rangeX: 0000000100000000 - 000000012c000000 Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB Setting variable MTRR 5, base: 4608MB, range: 128MB, type WB Setting variable MTRR 6, base: 4736MB, range: 64MB, type WB 4. Mika Fischer reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 will get Found optimal setting for mtrr clean up gran_size: 1M chunk_size: 16M num_reg: 5 lose RAM: 0M range0: 0000000000000000 - 00000000c0000000 Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB hole: 00000000bf700000 - 00000000c0000000 Setting variable MTRR 2, base: 3063MB, range: 1MB, type UC Setting variable MTRR 3, base: 3064MB, range: 8MB, type UC rangeX: 0000000100000000 - 0000000140000000 Setting variable MTRR 4, base: 4096MB, range: 1024MB, type WB Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-30x86, vmi: fix broken LDT accessZachary Amsden1-1/+1
This one took a long time to rear up because LDT usage is not very common, but the bug is quite serious. It got introduced along with another bug, already fixed, by 75b8bb3e56ca09a467fbbe5229bc68627f7445be After investigating a JRE failure, I found this bug was introduced a long time ago, and had already managed to survive another bugfix which occurred on the same line. The result is a total failure of the JRE due to LDT selectors not working properly. Signed-off-by: Zachary Amsden <zach@vmware.com> Cc: Glauber de Oliveira Costa <gcosta@redhat.com> Cc: stable@kernel.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-30x86: Fix broken LDT access in VMIZachary Amsden1-1/+1
After investigating a JRE failure, I found this bug was introduced a long time ago, and had already managed to survive another bugfix which occurred on the same line. The result is a total failure of the JRE due to LDT selectors not working properly. This one took a long time to rear up because LDT usage is not very common, but the bug is quite serious. It got introduced along with another bug, already fixed, by 75b8bb3e56ca09a467fbbe5229bc68627f7445be Signed-off-by: Zachary Amsden <zach@vmware.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Glauber de Oliveira Costa <gcosta@redhat.com> Cc: <stable@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-09-30Merge branch 'release' of ↵Linus Torvalds5-9/+15
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] Put the space for cpu0 per-cpu area into .data section
2008-09-30Merge branch 'merge' of ↵Linus Torvalds2-58/+54
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc: Fix failure to shutdown with CPU hotplug powerpc: Fix PCI in Holly device tree
2008-09-30x86, debug printouts: IOMMU setup failures should not be KERN_ERRAdam Jackson1-3/+3
The number of BIOSes that have an option to enable the IOMMU, or fix anything about its configuration, is vanishingly small. There's no good reason to punish quiet boot for this. Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-30x86: fix typo in enable_mtrr_cleanup early parameterJ.A. Magallón1-1/+1
Correct typo for 'enable_mtrr_cleanup' early boot param name. Signed-off-by: J.A. Magallon <jamagallon@ono.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-30x86: export set_memory_ro and set_memory_rwBruce Allan1-0/+2
Export set_memory_ro() and set_memory_rw() calls for use by drivers that need to have more debug information about who might be writing to memory space. this was initially developed for use while debugging a memory corruption problem with e1000e. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-30x86: mtrr_cleanup try gran_size to less than 1MYinghai Lu1-4/+4
one have gran < 1M reg00: base=0xd8000000 (3456MB), size= 128MB: uncachable, count=1 reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 reg05: base=0xd7f80000 (3455MB), size= 512KB: uncachable, count=1 will get Found optimal setting for mtrr clean up gran_size: 512K chunk_size: 2M num_reg: 7 lose RAM: 0G range0: 0000000000000000 - 00000000d8000000 Setting variable MTRR 0, base: 0GB, range: 2GB, type WB Setting variable MTRR 1, base: 2GB, range: 1GB, type WB Setting variable MTRR 2, base: 3GB, range: 256MB, type WB Setting variable MTRR 3, base: 3328MB, range: 128MB, type WB hole: 00000000d7f00000 - 00000000d7f80000 Setting variable MTRR 4, base: 3455MB, range: 512KB, type UC rangeX: 0000000100000000 - 0000000128000000 Setting variable MTRR 5, base: 4GB, range: 512MB, type WB Setting variable MTRR 6, base: 4608MB, range: 128MB, type WB so start from 64k instead of 1M Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-09-30x86: mtrr_cleanup prepare to make gran_size to less 1MYinghai Lu1-24/+79
make the print out right with size < 1M Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-09-30powerpc: Fix failure to shutdown with CPU hotplugJohannes Berg1-5/+1
I tracked down the shutdown regression to CPUs not dying when being shut down during power-off. This turns out to be due to the system_state being SYSTEM_POWER_OFF, which this code doesn't take as a valid state for shutting off CPUs in. This has never made sense to me, but when I added hotplug code to implement hibernate I only "made it work" and did not question the need to check the system_state. Thomas Gleixner helped me dig, but the only thing we found is that it was added with the original commit that added CPU hotplug support. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Joel Schopp <jschopp@austin.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-09-30powerpc: Fix PCI in Holly device treeDavid Gibson1-53/+53
The PCI bridge on the Holly board is incorrectly represented in the device tree. The current device tree node for the PCI bridge sits under the tsi-bridge node. That's not obviously wrong, but the PCI bridge translates some PCI spaces into CPU address ranges which were not translated by the "ranges" property in tsi-bridge node. We used to get away with this problem because the PCI bridge discovery code was also buggy, assuming incorrectly that PCI host bridge nodes were always directly under the root bus and treating the translated addresses as raw CPU addresses, rather than parent bus addresses. This has since been fixed, thus breaking Holly. This could be fixed by adding extra translations to the tsi-bridge node, but this patch instead moves the Holly PCI bridge out of the tsi-bridge node to the root bus. This makes the tsi-bridge node represent only the built-in IO devices in the bridge, with a more-or-less contiguous address range. This is the same convention used on Freescale SoC chips, where the "soc" node represents only the IMMR region, and the PCI and other bus bridges are separate nodes under the root bus. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>