1. 14 7月, 2008 12 次提交
  2. 11 7月, 2008 1 次提交
  3. 10 7月, 2008 1 次提交
  4. 09 7月, 2008 3 次提交
  5. 08 7月, 2008 2 次提交
  6. 07 7月, 2008 1 次提交
  7. 05 7月, 2008 5 次提交
  8. 04 7月, 2008 4 次提交
  9. 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
  10. 02 7月, 2008 3 次提交
  11. 01 7月, 2008 4 次提交
  12. 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