1. 13 7月, 2007 1 次提交
  2. 10 7月, 2007 2 次提交
    • I
      sched: x86, track TSC-unstable events · bb29ab26
      Ingo Molnar 提交于
      track TSC-unstable events and propagate it to the scheduler code.
      Also allow sched_clock() to be used when the TSC is unstable,
      the rq_clock() wrapper creates a reliable clock out of it.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bb29ab26
    • I
      sched: zap the migration init / cache-hot balancing code · 0437e109
      Ingo Molnar 提交于
      the SMP load-balancer uses the boot-time migration-cost estimation
      code to attempt to improve the quality of balancing. The reason for
      this code is that the discrete priority queues do not preserve
      the order of scheduling accurately, so the load-balancer skips
      tasks that were running on a CPU 'recently'.
      
      this code is fundamental fragile: the boot-time migration cost detector
      doesnt really work on systems that had large L3 caches, it caused boot
      delays on large systems and the whole cache-hot concept made the
      balancing code pretty undeterministic as well.
      
      (and hey, i wrote most of it, so i can say it out loud that it sucks ;-)
      
      under CFS the same purpose of cache affinity can be achieved without
      any special cache-hot special-case: tasks are sorted in the 'timeline'
      tree and the SMP balancer picks tasks from the left side of the
      tree, thus the most cache-cold task is balanced automatically.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0437e109
  3. 08 7月, 2007 1 次提交
  4. 07 7月, 2007 4 次提交
    • A
      GEODE: reboot fixup for geode machines with CS5536 boards · 95069f89
      Andres Salomon 提交于
      Writing to MSR 0x51400017 forces a hard reset on CS5536-based machines,
      this has the reboot fixup do just that if such a board is detected.
      Acked-by: NJordan Crouse <jordan.crouse@amd.com>
      Signed-off-by: NAndres Salomon <dilinger@debian.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      95069f89
    • V
      i386: es7000 build breakage fix · 071922c0
      Vivek Goyal 提交于
      o Commit 1833d6bc broke the build if
        compiled with CONFIG_ES7000=y and CONFIG_X86_GENERICARCH=n
      
      arch/i386/kernel/built-in.o(.init.text+0x4fa9): In function `acpi_parse_madt':
      : undefined reference to `acpi_madt_oem_check'
      arch/i386/kernel/built-in.o(.init.text+0x7406): In function `smp_read_mpc':
      : undefined reference to `mps_oem_check'
      arch/i386/kernel/built-in.o(.init.text+0x8990): In function
      `connect_bsp_APIC':
      : undefined reference to `enable_apic_mode'
      make: *** [.tmp_vmlinux1] Error 1
      
      o Fix the build issue. Provided the definitions of missing functions.
      
      o Don't have ES7000 machine. Only compile tested.
      
      Cc: Len Brown <lenb@kernel.org>
      Cc: Natalie Protasevich <protasnb@gmail.com>
      Cc: Roland Dreier <rolandd@cisco.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      071922c0
    • L
      MTRR: Fix race causing set_mtrr to go into infinite loop · d25c1ba2
      Loic Prylli 提交于
      Processors synchronization in set_mtrr requires the .gate field to be set
      after .count field is properly initialized.  Without an explicit barrier,
      the compiler was reordering those memory stores.  That was sometimes
      causing a processor (in ipi_handler) to see the .gate change and decrement
      .count before the latter is set by set_mtrr() (which then hangs in a
      infinite loop with irqs disabled).
      Signed-off-by: NLoic Prylli <loic@myri.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d25c1ba2
    • J
      i386: fix regression, endless loop in ptrace singlestep over an int80 · 1e2e99f0
      Jason Wessel 提交于
      The commit 635cf99a introduced a
      regression.  Executing a ptrace single step after certain int80
      accesses will infinitely loop and never advance the PC.
      
      The TIF_SINGLESTEP check should be done on the return from the syscall
      and not before it.
      
      I loops on each single step on the pop right after the int80 which writes out
      to the console.  At that point you can issue as many single steps as you want
      and it will not advance any further.
      
      The test case is below:
      
      /* Test whether singlestep through an int80 syscall works.
       */
      #define _GNU_SOURCE
      #include <stdio.h>
      #include <unistd.h>
      #include <fcntl.h>
      #include <sys/ptrace.h>
      #include <sys/wait.h>
      #include <sys/mman.h>
      #include <asm/user.h>
      #include <string.h>
      
      static int child, status;
      static struct user_regs_struct regs;
      
      static void do_child()
      {
      	char str[80] = "child: int80 test\n";
      
      	ptrace(PTRACE_TRACEME, 0, 0, 0);
      	kill(getpid(), SIGUSR1);
      	write(fileno(stdout),str,strlen(str));
      	asm ("int $0x80" : : "a" (20)); /* getpid */
      }
      
      static void do_parent()
      {
      	unsigned long eip, expected = 0;
      again:
      	waitpid(child, &status, 0);
      	if (WIFEXITED(status) || WIFSIGNALED(status))
      		return;
      
      	if (WIFSTOPPED(status)) {
      		ptrace(PTRACE_GETREGS, child, 0, &regs);
      		eip = regs.eip;
      		if (expected)
      			fprintf(stderr, "child stop @ %08lx, expected %08lx %s\n",
      					eip, expected,
      					eip == expected ? "" : " <== ERROR");
      
      		if (*(unsigned short *)eip == 0x80cd) {
      			fprintf(stderr, "int 0x80 at %08x\n", (unsigned int)eip);
      			expected = eip + 2;
      		} else
      			expected = 0;
      
      		ptrace(PTRACE_SINGLESTEP, child, NULL, NULL);
      	}
      	goto again;
      }
      
      int main(int argc, char * const argv[])
      {
      	child = fork();
      	if (child)
      		do_parent();
      	else
      		do_child();
      	return 0;
      }
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: <stable@kernel.org>
      Cc: Chuck Ebbert <76306.1226@compuserve.com>
      Acked-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1e2e99f0
  5. 04 7月, 2007 3 次提交
  6. 02 7月, 2007 2 次提交
    • A
      i386: mtrr crash fix · 84288ad8
      Andrew Morton 提交于
      Commit 3ebad590 ("[PATCH] x86: Save and
      restore the fixed-range MTRRs of the BSP when suspending") added mtrr
      operations without verifying that the CPU has MTRRs.  Crashes transmeta
      CPUs.
      
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <linux@horizon.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      84288ad8
    • L
      i386: remove bogus mtrr range check · 4710bcce
      Linus Torvalds 提交于
      Commit 9215da33 "fixed" the MTRR range
      check to not allow any MTRR's under the 1MB mark (since that's where the
      fixed MTRR's are active).
      
      However, that was totally bogus, since it's normal (and almost required)
      to have a large variable MTRR that starts at 0, and covers some large
      percentage of the whole RAM, and then using the fixed MTRR's to override
      that large MTRR to handle the special ISA hole in the 640k-1M region.
      
      The old check was bogus too (checking that no variable MTRR is used that
      is entirely under the 1MB range), but at least it wasn't actively
      detrimental, because no sane situation would ever trigger such MTRR
      usage in the first place.
      
      That said, the whole notion of not allowing variable MTRR's in the low
      1MB is just stupid, so rather than revert the commit, this just removes
      the whole sad and unnecessary check entirely.
      
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Tested-by: NLuca Palermo <darkmage@sabayonlinux.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4710bcce
  7. 29 6月, 2007 1 次提交
    • R
      mtrr/cyrix: fix sections · 80581c43
      Randy Dunlap 提交于
      main.c::mtrr_add() or mtrr_del() [exported]
      calls main.c::mtrr_add_page() or mtrr_del_page() or mtrr_restore() [resume]
      calls main.c::set_mtrr()
      calls main.c::ipi_handler()
      calls main.c::mtrr_if->set_all() == which can be cyrix_set_all
      
      WARNING: arch/i386/kernel/built-in.o(.text+0x8657): Section mismatch: reference to .init.data: (between 'cyrix_set_all' and 'centaur_get_free_region')
      WARNING: arch/i386/kernel/built-in.o(.text+0x866b): Section mismatch: reference to .init.data: (between 'cyrix_set_all' and 'centaur_get_free_region')
      WARNING: arch/i386/kernel/built-in.o(.text+0x867e): Section mismatch: reference to .init.data: (between 'cyrix_set_all' and 'centaur_get_free_region')
      WARNING: arch/i386/kernel/built-in.o(.text+0x8684): Section mismatch: reference to .init.data: (between 'cyrix_set_all' and 'centaur_get_free_region')
      WARNING: arch/i386/kernel/built-in.o(.text+0x868a): Section mismatch: reference to .init.data: (between 'cyrix_set_all' and 'centaur_get_free_region')
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      80581c43
  8. 24 6月, 2007 1 次提交
  9. 23 6月, 2007 1 次提交
  10. 22 6月, 2007 1 次提交
  11. 21 6月, 2007 4 次提交
  12. 17 6月, 2007 3 次提交
  13. 09 6月, 2007 1 次提交
  14. 08 6月, 2007 1 次提交
    • S
      enable interrupts in user path of page fault. · e5e3c84b
      Steven Rostedt 提交于
      This is a minor fix, but what is currently there is essentially wrong.
      In do_page_fault, if the faulting address from user code happens to be
      in kernel address space (int *p = (int*)-1; p = 0xbed;)  then the
      do_page_fault handler will jump over the local_irq_enable with the
      
        goto bad_area_nosemaphore;
      
      But the first line there sees this is user code and goes through the
      process of sending a signal to send SIGSEGV to the user task. This whole
      time interrupts are disabled and the task can not be preempted by a
      higher priority task.
      
      This patch always enables interrupts in the user path of the
      bad_area_nosemaphore.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e5e3c84b
  15. 05 6月, 2007 1 次提交
  16. 01 6月, 2007 5 次提交
  17. 31 5月, 2007 1 次提交
  18. 24 5月, 2007 2 次提交
  19. 22 5月, 2007 5 次提交