1. 27 2月, 2006 4 次提交
  2. 25 2月, 2006 5 次提交
  3. 21 2月, 2006 1 次提交
  4. 18 2月, 2006 1 次提交
  5. 15 2月, 2006 3 次提交
  6. 12 2月, 2006 2 次提交
    • I
      [PATCH] x86: print out early faults via early_printk() · c0cdf193
      Ingo Molnar 提交于
      Lost a few hours debugging an early-bootup fault within printk itself,
      which manifested itself as a hard to debug early hang.
      
      This patch makes it much easier by printing out early faults via
      early_printk(), which function is a lot simpler than a full printk, and
      hence more likely to succeed in emergencies.  (We do not recover from early
      faults anyway, so there's no loss from not having these messages in the
      normal printk buffer.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c0cdf193
    • U
      [PATCH] fstatat64 support · cff2b760
      Ulrich Drepper 提交于
      The *at patches introduced fstatat and, due to inusfficient research, I
      used the newfstat functions generally as the guideline.  The result is that
      on 32-bit platforms we don't have all the information needed to implement
      fstatat64.
      
      This patch modifies the code to pass up 64-bit information if
      __ARCH_WANT_STAT64 is defined.  I renamed the syscall entry point to make
      this clear.  Other archs will continue to use the existing code.  On x86-64
      the compat code is implemented using a new sys32_ function.  this is what
      is done for the other stat syscalls as well.
      
      This patch might break some other archs (those which define
      __ARCH_WANT_STAT64 and which already wired up the syscall).  Yet others
      might need changes to accomodate the compatibility mode.  I really don't
      want to do that work because all this stat handling is a mess (more so in
      glibc, but the kernel is also affected).  It should be done by the arch
      maintainers.  I'll provide some stand-alone test shortly.  Those who are
      eager could compile glibc and run 'make check' (no installation needed).
      
      The patch below has been tested on x86 and x86-64.
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cff2b760
  7. 11 2月, 2006 1 次提交
    • A
      [PATCH] x86: don't initialise cpu_possible_map to all ones · 7a8ef1cb
      Andrew Morton 提交于
      Initialising cpu_possible_map to all-ones with CONFIG_HOTPLUG_CPU means that
      
      a) All for_each_cpu() loops will iterate across all NR_CPUS CPUs, rather
         than over possible ones.  That can be quite expensive.
      
      b) Soon we'll be allocating per-cpu areas only for possible CPUs.  So with
         CPU_MASK_ALL, we'll be wasting memory.
      
      I also switched voyager over to not use CPU_MASK_ALL in the non-CPU-hotplug
      case.  Should be OK..
      
      I note that parisc is also using CPU_MASK_ALL.  Suggest that it stop doing
      that.
      
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Zwane Mwaikambo <zwane@linuxpower.ca>
      Cc: Paul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7a8ef1cb
  8. 08 2月, 2006 2 次提交
  9. 06 2月, 2006 5 次提交
  10. 05 2月, 2006 2 次提交
  11. 04 2月, 2006 1 次提交
    • T
      [PATCH] OProfile: fixed x86_64 incorrect kernel call graphs · 23332c2e
      Tong Li 提交于
      Fix the problem in kernel 2.6.15.1 (and early versions) that OProfile on
      x86_64 does not correctly collect the stack traces for kernel functions.
      
      The original code in valid_kernel_stack() in arch/i386/oprofile/backtrace.c
      assumes that the frame pointer (headaddr) should be greater than stack
      (i.e., regs).
      
      This assumption is wrong for x86_64 because NMIs in x86_64 use a seperate
      stack different from the kernel stack.  Therefore, the variable stack now
      points to some location on the NMI stack, which turns out to be at a higher
      address than the frame pointer (headaddr) on the kernel stack.  The correct
      comparison here should be between headaddr and regs->rsp for x86_64.
      Signed-off-by: NTong Li <tong.n.li@intel.com>
      Cc: John Levon <levon@movementarian.org>
      Cc: Philippe Elie <phil.el@wanadoo.fr>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      23332c2e
  12. 03 2月, 2006 1 次提交
  13. 02 2月, 2006 3 次提交
  14. 01 2月, 2006 2 次提交
  15. 27 1月, 2006 2 次提交
  16. 20 1月, 2006 1 次提交
    • A
      [CPUFREQ] X86_GX_SUSPMOD must depend on PCI · cdc9cc1d
      Adrian Bunk 提交于
      This patch fixes the following compile error:
      
      ...
        CC      arch/i386/kernel/cpu/cpufreq/gx-suspmod.o
      arch/i386/kernel/cpu/cpufreq/gx-suspmod.c: In function 'gx_detect_chipset':
      arch/i386/kernel/cpu/cpufreq/gx-suspmod.c:193: error: implicit declaration of function 'pci_match_id'
      arch/i386/kernel/cpu/cpufreq/gx-suspmod.c:193: warning: comparison between pointer and integer
      make[3]: *** [arch/i386/kernel/cpu/cpufreq/gx-suspmod.o] Error 1
      
      <--  snip  -->
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      cdc9cc1d
  17. 19 1月, 2006 4 次提交