1. 08 7月, 2008 6 次提交
  2. 05 7月, 2008 5 次提交
  3. 04 7月, 2008 4 次提交
  4. 03 7月, 2008 2 次提交
    • A
      arch/x86/mm/init_64.c: early_memtest(): fix types · 27df66a4
      Andrew Morton 提交于
      fix this warning:
      
      arch/x86/mm/init_64.c: In function 'early_memtest':
      arch/x86/mm/init_64.c:524: warning: passing argument 2 of 'find_e820_area_size' from incompatible pointer type
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      27df66a4
    • H
      x86: fix Intel Mac booting with EFI · 216705d2
      Hugh Dickins 提交于
      Fedora reports that mem_init()'s zap_low_mappings(), extended to SMP in
      61165d7a x86: fix app crashes after SMP
      resume causes 32-bit Intel Mac machines to reboot very early when
      booting with EFI.
      
      The EFI code appears to manage low mappings for itself when needed; but
      like many before it, confuses PSE with PAE.  So it has only been mapping
      half the space it needed when PSE but not PAE.  This remained unnoticed
      until we moved the SMP zap_low_mappings() before
      efi_enter_virtual_mode().  Presumably could have been noticed years ago
      if anyone ran a UP kernel on such machines?
      Reported-by: NPeter Jones <pjones@redhat.com>
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Glauber Costa <gcosta@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Tested-by: NPeter Jones <pjones@redhat.com>
      216705d2
  5. 02 7月, 2008 3 次提交
  6. 01 7月, 2008 4 次提交
  7. 30 6月, 2008 2 次提交
    • T
      ptrace GET/SET FPXREGS broken · 11dbc963
      TAKADA Yoshihito 提交于
      When I update kernel 2.6.25 from 2.6.24, gdb does not work.
      On 2.6.25, ptrace(PTRACE_GETFPXREGS, ...) returns ENODEV.
      
      But 2.6.24 kernel's ptrace() returns EIO.
      It is issue of compatibility.
      
      I attached test program as pt.c and patch for fix it.
      
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include <signal.h>
      #include <errno.h>
      #include <sys/ptrace.h>
      #include <sys/types.h>
      
      struct user_fxsr_struct {
      	unsigned short	cwd;
      	unsigned short	swd;
      	unsigned short	twd;
      	unsigned short	fop;
      	long	fip;
      	long	fcs;
      	long	foo;
      	long	fos;
      	long	mxcsr;
      	long	reserved;
      	long	st_space[32];	/* 8*16 bytes for each FP-reg = 128 bytes */
      	long	xmm_space[32];	/* 8*16 bytes for each XMM-reg = 128 bytes */
      	long	padding[56];
      };
      
      int main(void)
      {
        pid_t pid;
      
        pid = fork();
      
        switch(pid){
        case -1:/*  error */
          break;
        case 0:/*  child */
          child();
          break;
        default:
          parent(pid);
          break;
        }
        return 0;
      }
      
      int child(void)
      {
        ptrace(PTRACE_TRACEME);
        kill(getpid(), SIGSTOP);
        sleep(10);
        return 0;
      }
      int parent(pid_t pid)
      {
        int ret;
        struct user_fxsr_struct fpxregs;
      
        ret = ptrace(PTRACE_GETFPXREGS, pid, 0, &fpxregs);
        if(ret < 0){
          printf("%d: %s.\n", errno, strerror(errno));
        }
        kill(pid, SIGCONT);
        wait(pid);
        return 0;
      }
      
      /* in the kerel, at kernel/i387.c get_fpxregs() */
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      11dbc963
    • Z
      x86: fix cpu hotplug crash · fcb43042
      Zhang, Yanmin 提交于
      Vegard Nossum reported crashes during cpu hotplug tests:
      
        http://marc.info/?l=linux-kernel&m=121413950227884&w=4
      
      In function _cpu_up, the panic happens when calling
      __raw_notifier_call_chain at the second time. Kernel doesn't panic when
      calling it at the first time. If just say because of nr_cpu_ids, that's
      not right.
      
      By checking the source code, I found that function do_boot_cpu is the culprit.
      Consider below call chain:
       _cpu_up=>__cpu_up=>smp_ops.cpu_up=>native_cpu_up=>do_boot_cpu.
      
      So do_boot_cpu is called in the end. In do_boot_cpu, if
      boot_error==true, cpu_clear(cpu, cpu_possible_map) is executed. So later
      on, when _cpu_up calls __raw_notifier_call_chain at the second time to
      report CPU_UP_CANCELED, because this cpu is already cleared from
      cpu_possible_map, get_cpu_sysdev returns NULL.
      
      Many resources are related to cpu_possible_map, so it's better not to
      change it.
      
      Below patch against 2.6.26-rc7 fixes it by removing the bit clearing in
      cpu_possible_map.
      Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com>
      Tested-by: NVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fcb43042
  8. 26 6月, 2008 1 次提交
    • D
      x86: section/warning fixes · 0b1faeef
      Daniel J Blueman 提交于
      WARNING: arch/x86/mm/built-in.o(.text+0x3a1): Section mismatch in
      reference from the function set_pte_phys() to the function
      .init.text:spp_getpage()
      The function set_pte_phys() references
      the function __init spp_getpage().
      This is often because set_pte_phys lacks a __init
      annotation or the annotation of spp_getpage is wrong.
      
      arch/x86/mm/init_64.c: In function 'early_memtest':
      arch/x86/mm/init_64.c:520: warning: passing argument 2 of
      'find_e820_area_size' from incompatible pointer type
      Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Cc: "Linus Torvalds" <torvalds@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0b1faeef
  9. 25 6月, 2008 9 次提交
    • B
      Blackfin arch: fix up section mismatch warning · 8d0a6003
      Bryan Wu 提交于
      --
      WARNING: vmlinux.o(.text+0x721a): Section mismatch in reference from the function ___fill_code_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_code_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_code_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x7238): Section mismatch in reference from the function ___fill_code_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_code_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_code_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x7250): Section mismatch in reference from the function ___fill_code_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_code_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_code_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x7264): Section mismatch in reference from the function ___fill_code_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_code_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_code_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x72a2): Section mismatch in reference from the function ___fill_data_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_data_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_data_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x72bc): Section mismatch in reference from the function ___fill_data_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_data_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_data_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x72d4): Section mismatch in reference from the function ___fill_data_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_data_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_data_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      
      WARNING: vmlinux.o(.text+0x72e8): Section mismatch in reference from the function ___fill_data_cplbtab() to the function .init.text:_fill_cplbtab()
      The function ___fill_data_cplbtab() references
      the function __init _fill_cplbtab().
      This is often because ___fill_data_cplbtab lacks a __init
      annotation or the annotation of _fill_cplbtab is wrong.
      --
      Signed-off-by: NBryan Wu <cooloney@kernel.org>
      8d0a6003
    • S
      Blackfin arch: fix bug - kernel boot fails when Spinlock and rw-lock debugging enabled · 71a7d155
      Sonic Zhang 提交于
      Initialize the lock of bad_irq_desc properly.
      The content of irq_desc array is replaced by bad_irq_desc in blackfin
      arch irqchip init code. So, do it properly as common irq init code.
      Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
      Signed-off-by: NBryan Wu <cooloney@kernel.org>
      71a7d155
    • G
      x86: KVM guest: Use the paravirt clocksource structs and functions · f6e16d5a
      Gerd Hoffmann 提交于
      This patch updates the kvm host code to use the pvclock structs
      and functions, thereby making it compatible with Xen.
      
      The patch also fixes an initialization bug: on SMP systems the
      per-cpu has two different locations early at boot and after CPU
      bringup.  kvmclock must take that in account when registering the
      physical address within the host.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      f6e16d5a
    • G
      KVM: Make kvm host use the paravirt clocksource structs · 50d0a0f9
      Gerd Hoffmann 提交于
      This patch updates the kvm host code to use the pvclock structs.
      It also makes the paravirt clock compatible with Xen.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      50d0a0f9
    • G
      x86: Make xen use the paravirt clocksource structs and functions · 1c7b67f7
      Gerd Hoffmann 提交于
      This patch updates the xen guest to use the pvclock structs
      and helper functions.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      1c7b67f7
    • G
      x86: Add structs and functions for paravirt clocksource · 7af192c9
      Gerd Hoffmann 提交于
      This patch adds structs for the paravirt clocksource ABI
      used by both xen and kvm (pvclock-abi.h).
      
      It also adds some helper functions to read system time and
      wall clock time from a paravirtual clocksource (pvclock.[ch]).
      They are based on the xen code.  They are enabled using
      CONFIG_PARAVIRT_CLOCK.
      
      Subsequent patches of this series will put the code in use.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      7af192c9
    • J
      [IA64] Eliminate NULL test after alloc_bootmem in iosapic_alloc_rte() · e2569b7e
      Julia Lawall 提交于
      As noted by Akinobu Mita alloc_bootmem and related functions never return
      NULL and always return a zeroed region of memory.  Thus a NULL test or
      memset after calls to these functions is unnecessary.
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      e2569b7e
    • C
      [IA64] Handle count==0 in sn2_ptc_proc_write() · 8097110d
      Cliff Wickman 提交于
      The fix applied in e0c6d97c
      "security hole in sn2_ptc_proc_write" didn't take into account
      the case where count==0 (which results in a buffer underrun
      when adding the trailing '\0').  Thanks to Andi Kleen for
      pointing this out.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      8097110d
    • J
      [IA64] Fix boot failure on ia64/sn2 · 2826f8c0
      Jes Sorensen 提交于
      Call check_sal_cache_flush() after platform_setup() as
      check_sal_cache_flush() now relies on being able to call platform
      vector code.
      
      Problem was introduced by: 3463a93d
      "Update check_sal_cache_flush to use platform_send_ipi()"
      Signed-off-by: NJes Sorensen <jes@sgi.com>
      Tested-by: NAlex Chiang: <achiang@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      2826f8c0
  10. 24 6月, 2008 4 次提交