1. 17 Apr, 2008 1 commit
  2. 16 Apr, 2008 3 commits
  3. 15 Apr, 2008 5 commits
  4. 14 Apr, 2008 1 commit
  5. 11 Apr, 2008 1 commit
    • Roland McGrath's avatar
      asmlinkage_protect replaces prevent_tail_call · 54a01510
      Roland McGrath authored
      
      
      The prevent_tail_call() macro works around the problem of the compiler
      clobbering argument words on the stack, which for asmlinkage functions
      is the caller's (user's) struct pt_regs.  The tail/sibling-call
      optimization is not the only way that the compiler can decide to use
      stack argument words as scratch space, which we have to prevent.
      Other optimizations can do it too.
      
      Until we have new compiler support to make "asmlinkage" binding on the
      compiler's own use of the stack argument frame, we have work around all
      the manifestations of this issue that crop up.
      
      More cases seem to be prevented by also keeping the incoming argument
      variables live at the end of the function.  This makes their original
      stack slots attractive places to leave those variables, so the compiler
      tends not clobber them for something else.  It's still no guarantee, but
      it handles some observed cases that prevent_tail_call() did not.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      54a01510
  6. 10 Apr, 2008 5 commits
  7. 07 Apr, 2008 3 commits
  8. 06 Apr, 2008 1 commit
  9. 04 Apr, 2008 11 commits
    • Sergei Shtylyov's avatar
      [MIPS] Make KGDB compile on UP · e64a3cfc
      Sergei Shtylyov authored
      
      
      Building UP kernel with KGDB enabled produces the following errors and warning
      (fatal due to -Werror in arch/mips/kernel/Makefile):
      
      In file included from arch/mips/kernel/gdb-stub.c:142:
      include/asm/smp.h:25:1: "raw_smp_processor_id" redefined
      In file included from include/linux/sched.h:69,
                       from arch/mips/kernel/gdb-stub.c:126:
      include/linux/smp.h:88:1: this is the location of the previous definition
      In file included from arch/mips/kernel/gdb-stub.c:142:
      include/asm/smp.h:62: error: redefinition of 'smp_send_reschedule'
      include/linux/smp.h:102: error: previous definition of 'smp_send_reschedule' was here
      include/asm/smp.h: In function `smp_send_reschedule':
      include/asm/smp.h:65: error: dereferencing pointer to incomplete type
      arch/mips/kernel/gdb-stub.c: At top level:
      arch/mips/kernel/gdb-stub.c:660: warning: 'kgdb_wait' defined but not used
      
      Fix the errors by not directly including <asm/smp.h> (which is already included
      by <linux/smp.h>) and the warning by enclosing kgdb_wait() in #ifdef CONFIG_SMP.
      Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      e64a3cfc
    • Geert Uytterhoeven's avatar
      m68k: update defconfigs for 2.6.25 · a1aa758d
      Geert Uytterhoeven authored
      
      
      Long overdue update of the m68k defconfigs
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a1aa758d
    • Adrian Bunk's avatar
      m68k: use KBUILD_DEFCONFIG · ef85ecbf
      Adrian Bunk authored
      
      
      The default defconfig should be one from arch/m68k/configs/
      
      arch/m68k/defconfig was not exactly identical to amiga_defconfig but
      also considering how long they have been without any update that doesn't
      seem to have been on purpose.
      Signed-off-by: default avatarAdrian Bunk <adrian.bunk@movial.fi>
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ef85ecbf
    • Thomas Gleixner's avatar
      x86: revert assign IRQs to hpet timer · 5761d64b
      Thomas Gleixner authored
      The commits:
      
      commit 37a47db8
      Author: Balaji Rao <balajirrao@gmail.com>
      Date:   Wed Jan 30 13:30:03 2008 +0100
      
          x86: assign IRQs to HPET timers, fix
      
      and
      
      commit e3f37a54
      Author: Balaji Rao <balajirrao@gmail.com>
      Date:   Wed Jan 30 13:30:03 2008 +0100
      
          x86: assign IRQs to HPET timers
      
      have been identified to cause a regression on some platforms due to
      the assignement of legacy IRQs which makes the legacy devices
      connected to those IRQs disfunctional.
      
      Revert them.
      
      This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10382
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5761d64b
    • Thomas Gleixner's avatar
      x86: tsc prevent time going backwards · 47001d60
      Thomas Gleixner authored
      We already catch most of the TSC problems by sanity checks, but there
      is a subtle bug which has been in the code for ever. This can cause
      time jumps in the range of hours.
      
      This was reported in:
           http://lkml.org/lkml/2007/8/23/96
      and
           http://lkml.org/lkml/2008/3/31/23
      
      
      
      I was able to reproduce the problem with a gettimeofday loop test on a
      dual core and a quad core machine which both have sychronized
      TSCs. The TSCs seems not to be perfectly in sync though, but the
      kernel is not able to detect the slight delta in the sync check. Still
      there exists an extremly small window where this delta can be observed
      with a real big time jump. So far I was only able to reproduce this
      with the vsyscall gettimeofday implementation, but in theory this
      might be observable with the syscall based version as well.
      
      CPU 0 updates the clock source variables under xtime/vyscall lock and
      CPU1, where the TSC is slighty behind CPU0, is reading the time right
      after the seqlock was unlocked.
      
      The clocksource reference data was updated with the TSC from CPU0 and
      the value which is read from TSC on CPU1 is less than the reference
      data. This results in a huge delta value due to the unsigned
      subtraction of the TSC value and the reference value. This algorithm
      can not be changed due to the support of wrapping clock sources like
      pm timer.
      
      The huge delta is converted to nanoseconds and added to xtime, which
      is then observable by the caller. The next gettimeofday call on CPU1
      will show the correct time again as now the TSC has advanced above the
      reference value.
      
      To prevent this TSC specific wreckage we need to compare the TSC value
      against the reference value and return the latter when it is larger
      than the actual TSC value.
      
      I pondered to mark the TSC unstable when the readout is smaller than
      the reference value, but this would render an otherwise good and fast
      clocksource unusable without a real good reason.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      47001d60
    • Mark McLoughlin's avatar
      xen: Clear PG_pinned in release_{pt,pd}() · c946c7de
      Mark McLoughlin authored
      
      Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
      Cc: xen-devel@lists.xensource.com
      Cc: Mark McLoughlin <markmc@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c946c7de
    • Mark McLoughlin's avatar
      xen: Do not pin/unpin PMD pages · a684d69d
      Mark McLoughlin authored
      i.e. with this simple test case:
      
          int fd = open("/dev/zero", O_RDONLY);
          munmap(mmap((void *)0x40000000, 0x1000_LEN, PROT_READ, MAP_PRIVATE, fd, 0), 0x1000);
          close(fd);
      
      we currently get:
      
         kernel BUG at arch/x86/xen/enlighten.c:678!
         ...
         EIP is at xen_release_pt+0x79/0xa9
         ...
         Call Trace:
          [<c041da25>] ? __pmd_free_tlb+0x1a/0x75
          [<c047a192>] ? free_pgd_range+0x1d2/0x2b5
          [<c047a2f3>] ? free_pgtables+0x7e/0x93
          [<c047b272>] ? unmap_region+0xb9/0xf5
          [<c047c1bd>] ? do_munmap+0x193/0x1f5
          [<c047c24f>] ? sys_munmap+0x30/0x3f
          [<c0408cce>] ? syscall_call+0x7/0xb
          =======================
      
      and xen complains:
      
        (XEN) mm.c:2241:d4 Mfn 1cc37 not pinned
      
      Further details at:
      
        https://bugzilla.redhat.com/436453
      
      Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
      Cc: xen-devel@lists.xensource.com
      Cc: Mark McLoughlin <markmc@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a684d69d
    • Mark McLoughlin's avatar
      xen: refactor xen_{alloc,release}_{pt,pd}() · f6433706
      Mark McLoughlin authored
      
      Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
      Cc: xen-devel@lists.xensource.com
      Cc: Mark McLoughlin <markmc@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f6433706
    • Pavel Machek's avatar
      x86, agpgart: scary messages are fortunately obsolete · 8f59610d
      Pavel Machek authored
      
      
      Fix obsolete printks in aperture-64. We used not to handle missing
      agpgart, but we handle it okay now.
      Signed-off-by: default avatarPavel Machek <pavel@suse.cz>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8f59610d
    • Ingo Molnar's avatar
      x86: print message if nmi_watchdog=2 cannot be enabled · 9c9b81f7
      Ingo Molnar authored
      
      
      right now if there's no CPU support for nmi_watchdog=2 we'll just
      refuse it silently.
      
      print a useful warning.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9c9b81f7
    • Ingo Molnar's avatar
      x86: fix nmi_watchdog=2 on Pentium-D CPUs · 4f14bdef
      Ingo Molnar authored
      
      
      implement nmi_watchdog=2 on this class of CPUs:
      
        cpu family      : 15
        model           : 6
        model name      : Intel(R) Pentium(R) D CPU 3.00GHz
      
      the watchdog's ->setup() method is safe anyway, so if the CPU
      cannot support it we'll bail out safely.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4f14bdef
  10. 03 Apr, 2008 9 commits