01 Feb, 2008

25 commits


31 Jan, 2008

3 commits

  • Paul Mackerras
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus: (27 commits)
    lguest: use __PAGE_KERNEL instead of _PAGE_KERNEL
    lguest: Use explicit includes rateher than indirect
    lguest: get rid of lg variable assignments
    lguest: change gpte_addr header
    lguest: move changed bitmap to lg_cpu
    lguest: move last_pages to lg_cpu
    lguest: change last_guest to last_cpu
    lguest: change spte_addr header
    lguest: per-vcpu lguest pgdir management
    lguest: make pending notifications per-vcpu
    lguest: makes special fields be per-vcpu
    lguest: per-vcpu lguest task management
    lguest: replace lguest_arch with lg_cpu_arch.
    lguest: make registers per-vcpu
    lguest: make emulate_insn receive a vcpu struct.
    lguest: map_switcher_in_guest() per-vcpu
    lguest: per-vcpu interrupt processing.
    lguest: per-vcpu lguest timers
    lguest: make hypercalls use the vcpu struct
    lguest: make write() operation smp aware
    ...

    Manual conflict resolved (maybe even correctly, who knows) in
    drivers/lguest/x86/core.c

    Linus Torvalds
     
  • Fix docbook fatal error:
    docproc: linux-2.6.24-git8/block/ll_rw_blk.c: No such file or directory

    Signed-off-by: Randy Dunlap
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

30 Jan, 2008

12 commits

  • This patch adds a new configuration option, which adds support for a new
    early_param which gets checked in arch/x86/kernel/setup_{32,64}.c:setup_arch()
    to decide wether OHCI-1394 FireWire controllers should be initialized and
    enabled for physical DMA access to allow remote debugging of early problems
    like issues ACPI or other subsystems which are executed very early.

    If the config option is not enabled, no code is changed, and if the boot
    paramenter is not given, no new code is executed, and independent of that,
    all new code is freed after boot, so the config option can be even enabled
    in standard, non-debug kernels.

    With specialized tools, it is then possible to get debugging information
    from machines which have no serial ports (notebooks) such as the printk
    buffer contents, or any data which can be referenced from global pointers,
    if it is stored below the 4GB limit and even memory dumps of of the physical
    RAM region below the 4GB limit can be taken without any cooperation from the
    CPU of the host, so the machine can be crashed early, it does not matter.

    In the extreme, even kernel debuggers can be accessed in this way. I wrote
    a small kgdb module and an accompanying gdb stub for FireWire which allows
    to gdb to talk to kgdb using remote remory reads and writes over FireWire.

    An version of the gdb stub fore FireWire is able to read all global data
    from a system which is running a a normal kernel without any kernel debugger,
    without any interruption or support of the system's CPU. That way, e.g. the
    task struct and so on can be read and even manipulated when the physical DMA
    access is granted.

    A HOWTO is included in this patch, in Documentation/debugging-via-ohci1394.txt
    and I've put a copy online at
    ftp://ftp.suse.de/private/bk/firewire/docs/debugging-via-ohci1394.txt

    It also has links to all the tools which are available to make use of it
    another copy of it is online at:
    ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diff

    Signed-Off-By: Bernhard Kaindl
    Tested-By: Thomas Renninger
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Bernhard Kaindl
     
  • The new "mfgptfix" boot command line option may be usd to fix MFGPT
    timers on AMD Geode platforms when the BIOS has incorrectly applied
    a workaround. TinyBIOS version 0.98 is known to be affected, 0.99
    fixes the problem by letting the user disable the workaround.

    Signed-off-by: Willy Tarreau
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Willy Tarreau
     
  • when MTRRs are not covering the whole e820 table, we need to trim the
    RAM and need to update e820.

    reuse some code on 64-bit as well.

    here need to add early_get_cap and use it in early_cpu_detect, and move
    mtrr_bp_init early.

    The code successfully trimmed the memory map on Justin's system:

    from:

    [ 0.000000] BIOS-e820: 0000000100000000 - 000000022c000000 (usable)

    to:

    [ 0.000000] modified: 0000000100000000 - 0000000228000000 (usable)
    [ 0.000000] modified: 0000000228000000 - 000000022c000000 (reserved)

    According to Justin it makes quite a difference:

    | When I boot the box without any trimming it acts like a 286 or 386,
    | takes about 10 minutes to boot (using raptor disks).

    Signed-off-by: Yinghai Lu
    Tested-by: Justin Piszcz
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Yinghai Lu
     
  • Add a generic option to clear any cpuid bit. I added it because it was
    very easy to add with the new generic cpuid disable bitmap and perhaps
    it will be useful in the future.

    Signed-off-by: Andi Kleen
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Andi Kleen
     
  • To disable CLFLUSH usage, especially in change_page_attr().

    Signed-off-by: Andi Kleen
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Andi Kleen
     
  • On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all
    available RAM, meaning the last few megs (or even gigs) of memory will be
    marked uncached. Since Linux tends to allocate from high memory addresses
    first, this causes the machine to be unusably slow as soon as the kernel
    starts really using memory (i.e. right around init time).

    This patch works around the problem by scanning the MTRRs at boot and
    figuring out whether the current end_pfn value (setup by early e820 code)
    goes beyond the highest WB MTRR range, and if so, trimming it to match. A
    fairly obnoxious KERN_WARNING is printed too, letting the user know that
    not all of their memory is available due to a likely BIOS bug.

    Something similar could be done on i386 if needed, but the boot ordering
    would be slightly different, since the MTRR code on i386 depends on the
    boot_cpu_data structure being setup.

    This patch fixes a bug in the last patch that caused the code to run on
    non-Intel machines (AMD machines apparently don't need it and it's untested
    on other non-Intel machines, so best keep it off).

    Further enhancements and fixes from:

    Yinghai Lu
    Andi Kleen

    Signed-off-by: Jesse Barnes
    Tested-by: Justin Piszcz
    Cc: Andi Kleen
    Cc: "Eric W. Biederman"
    Cc: Yinghai Lu
    Signed-off-by: Andrew Morton
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Jesse Barnes
     
  • For K8 system: 4G RAM with memory hole remapping enabled, or more than
    4G RAM installed.

    when try to use kexec second kernel, and the first doesn't include
    gart_shutdown. the second kernel could have different aper position than
    the first kernel. and second kernel could use that hole as RAM that is
    still used by GART set by the first kernel. esp. when try to kexec
    2.6.24 with sparse mem enable from previous kernel (from RHEL 5 or SLES
    10). the new kernel will use aper by GART (set by first kernel) for
    vmemmap. and after new kernel setting one new GART. the position will be
    real RAM. the _mapcount set is lost.

    Bad page state in process 'swapper'
    page:ffffe2000e600020 flags:0x0000000000000000 mapping:0000000000000000 mapcount:1 count:0
    Trying to fix it up, but a reboot is needed
    Backtrace:
    Pid: 0, comm: swapper Not tainted 2.6.24-rc7-smp-gcdf71a10-dirty #13

    Call Trace:
    [] bad_page+0x63/0x8d
    [] __free_pages_ok+0x7c/0x2a5
    [] free_all_bootmem_core+0xd0/0x198
    [] numa_free_all_bootmem+0x3b/0x76
    [] mem_init+0x3b/0x152
    [] start_kernel+0x236/0x2c2
    [] _sinittext+0x11a/0x121

    and
    [ffffe2000e600000-ffffe2000e7fffff] PMD ->ffff81001c200000 on node 0
    phys addr is : 0x1c200000

    RHEL 5.1 kernel -53 said:
    PCI-DMA: aperture base @ 1c000000 size 65536 KB

    new kernel said:
    Mapping aperture over 65536 KB of RAM @ 3c000000

    So could try to disable that GART if possible.

    According to Ingo

    > hm, i'm wondering, instead of modifying the GART, why dont we simply
    > _detect_ whatever GART settings we have inherited, and propagate that
    > into our e820 maps? I.e. if there's inconsistency, then punch that out
    > from the memory maps and just dont use that memory.
    >
    > that way it would not matter whether the GART settings came from a [old
    > or crashing] Linux kernel that has not called gart_iommu_shutdown(), or
    > whether it's a BIOS that has set up an aperture hole inconsistent with
    > the memory map it passed. (or the memory map we _think_ i tried to pass
    > us)
    >
    > it would also be more robust to only read and do a memory map quirk
    > based on that, than actively trying to change the GART so early in the
    > bootup. Later on we have to re-enable the GART _anyway_ and have to
    > punch a hole for it.
    >
    > and as a bonus, we would have shored up our defenses against crappy
    > BIOSes as well.

    add e820 modification for gart inconsistent setting.

    gart_fix_e820=off could be used to disable e820 fix.

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Yinghai Lu
     
  • The 32 bit x86 tree has a very useful feature that prints the Code: line
    for the code even before the trapping instrution (and the start of the
    trapping instruction is then denoted with a <>). Unfortunately, the 64 bit
    x86 tree does not yet have this feature, making diagnosing backtraces harder
    than needed.

    This patch adds this feature in the same was as the 32 bit tree has
    (including the same kernel boot parameter), and including a bugfix
    to make the code use probe_kernel_address() rarther than a buggy (deadlocking)
    __get_user.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Arjan van de Ven
     
  • support according to fixes of x86_64 support.

    - Delete efi_rt_lock because it is used during system early boot,
    before SMP is initialized.

    - Change local_flush_tlb() to __flush_tlb_all() to flush global page
    mapping.

    - Clean up includes.

    - Revise Kconfig description.

    - Enable noefi kernel parameter on i386.

    Signed-off-by: Huang Ying
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Huang, Ying
     
  • This patch adds document for EFI x86_64 runtime services support.

    Signed-off-by: Chandramouli Narayanan
    Signed-off-by: Huang Ying
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Huang, Ying
     
  • Add the ability to reboot an x86_64 based machine using the RESET_REG in the
    FADT ACPI table.

    Signed-off-by: Aaron Durbin
    Cc: Len Brown
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Aaron Durbin
     
  • This makes x86_64's ia32 emulation support share the sources used in the
    32-bit kernel for the 32-bit vDSO and much of its setup code.

    The 32-bit vDSO mapping now behaves the same on x86_64 as on native 32-bit.
    The abi.syscall32 sysctl on x86_64 now takes the same values that
    vm.vdso_enabled takes on the 32-bit kernel. That is, 1 means a randomized
    vDSO location, 2 means the fixed old address. The CONFIG_COMPAT_VDSO
    option is now available to make this the default setting, the same meaning
    it has for the 32-bit kernel. (This does not affect the 64-bit vDSO.)

    The argument vdso32=[012] can be used on both 32-bit and 64-bit kernels to
    set this paramter at boot time. The vdso=[012] argument still does this
    same thing on the 32-bit kernel.

    Signed-off-by: Roland McGrath
    Cc: Andrew Morton
    Cc: Linus Torvalds
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Roland McGrath