1. 26 Sep, 2006 5 commits
  2. 30 Aug, 2006 1 commit
  3. 10 Jul, 2006 1 commit
  4. 30 Jun, 2006 1 commit
  5. 26 Jun, 2006 15 commits
  6. 25 Jun, 2006 2 commits
  7. 23 Jun, 2006 1 commit
  8. 30 May, 2006 1 commit
    • Daniel Yeisley's avatar
      [PATCH] x86_64: Handle empty node zero · 0d015324
      Daniel Yeisley authored
      
      
      From: Daniel Yeisley <dan.yeisley@unisys.com>
      
      It is possible to boot a Unisys ES7000 with CPUs from multiple cells, and not
      also include the memory from those cells.  This can create a scenario where
      node 0 has cpus, but no associated memory.  The system will boot fine in a
      configuration where node 0 has memory, but nodes 2 and 3 do not.
      
      [AK: I rechecked the code and generic code seems to indeed handle that already.
      Dan's original patch had a change for mm/slab.c that seems to be already in now.]
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0d015324
  9. 08 May, 2006 1 commit
    • Andi Kleen's avatar
      [PATCH] x86_64: Avoid EBDA area in early boot allocator · ac71d12c
      Andi Kleen authored
      
      
      Based on analysis&patch from Robert Hentosch
      
      Observed on a Dell PE6850 with 16GB
      
      The problem occurs very early on, when the kernel allocates space for the
      temporary memory map called bootmap. The bootmap overlaps the EBDA region.
      EBDA region is not historically reserved in the e820 mapping. When the
      bootmap is freed it marks the EBDA region as usable.
      
      If you notice in setup.c there is already code to work around the EBDA
      in reserve_ebda_region(), this check however occurs after the bootmap
      is allocated and doesn't prevent the bootmap from using this range.
      
      AK: I redid the original patch. Thanks also to Jan Beulich for
      spotting some mistakes.
      
      Cc: Robert_Hentosch@dell.com
      Cc: jbeulich@novell.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ac71d12c
  10. 01 May, 2006 1 commit
    • Mikael Pettersson's avatar
      [PATCH] x86_64: make PC Speaker driver work · 160bd18e
      Mikael Pettersson authored
      
      
      The PC Speaker driver's ->probe() routine doesn't even get called in the
      64-bit kernels.  The reason for that is that the arch code apparently has
      to explictly add a "pcspkr" platform device in order for the driver core to
      call the ->probe() routine.  arch/i386/kernel/setup.c unconditionally adds
      a "pcspkr" device, but the x86_64 kernel has no code at all related to the
      PC Speaker.
      
      The patch below copies the relevant code from i386 to x86_64, which makes
      the PC Speaker work for me on x86_64.
      
      Cc: Dmitry Torokhov <dtor_core@ameritech.net>
      Acked-by: default avatarAndi Kleen <ak@muc.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      160bd18e
  11. 20 Apr, 2006 1 commit
    • Andi Kleen's avatar
      [PATCH] i386/x86-64: Fix x87 information leak between processes · 18bd057b
      Andi Kleen authored
      
      
      AMD K7/K8 CPUs only save/restore the FOP/FIP/FDP x87 registers in FXSAVE
      when an exception is pending.  This means the value leak through
      context switches and allow processes to observe some x87 instruction
      state of other processes.
      
      This was actually documented by AMD, but nobody recognized it as
      being different from Intel before.
      
      The fix first adds an optimization: instead of unconditionally
      calling FNCLEX after each FXSAVE test if ES is pending and skip
      it when not needed. Then do a x87 load from a kernel variable to
      clear FOP/FIP/FDP.
      
      This means other processes always will only see a constant value
      defined by the kernel in their FP state.
      
      I took some pain to make sure to chose a variable that's already
      in L1 during context switch to make the overhead of this low.
      
      Also alternative() is used to patch away the new code on CPUs
      who don't need it.
      
      Patch for both i386/x86-64.
      
      The problem was discovered originally by Jan Beulich. Richard
      Brunner provided the basic code for the workarounds, with contribution
      from Jan.
      
      This is CVE-2006-1056
      
      Cc: richard.brunner@amd.com
      Cc: jbeulich@novell.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      18bd057b
  12. 09 Apr, 2006 1 commit
  13. 31 Mar, 2006 1 commit
    • OGAWA Hirofumi's avatar
      [PATCH] Don't pass boot parameters to argv_init[] · 9b41046c
      OGAWA Hirofumi authored
      
      
      The boot cmdline is parsed in parse_early_param() and
      parse_args(,unknown_bootoption).
      
      And __setup() is used in obsolete_checksetup().
      
      	start_kernel()
      		-> parse_args()
      			-> unknown_bootoption()
      				-> obsolete_checksetup()
      
      If __setup()'s callback (->setup_func()) returns 1 in
      obsolete_checksetup(), obsolete_checksetup() thinks a parameter was
      handled.
      
      If ->setup_func() returns 0, obsolete_checksetup() tries other
      ->setup_func().  If all ->setup_func() that matched a parameter returns 0,
      a parameter is seted to argv_init[].
      
      Then, when runing /sbin/init or init=app, argv_init[] is passed to the app.
      If the app doesn't ignore those arguments, it will warning and exit.
      
      This patch fixes a wrong usage of it, however fixes obvious one only.
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9b41046c
  14. 27 Mar, 2006 1 commit
    • Siddha, Suresh B's avatar
      [PATCH] sched: new sched domain for representing multi-core · 1e9f28fa
      Siddha, Suresh B authored
      
      
      Add a new sched domain for representing multi-core with shared caches
      between cores.  Consider a dual package system, each package containing two
      cores and with last level cache shared between cores with in a package.  If
      there are two runnable processes, with this appended patch those two
      processes will be scheduled on different packages.
      
      On such systems, with this patch we have observed 8% perf improvement with
      specJBB(2 warehouse) benchmark and 35% improvement with CFP2000 rate(with 2
      users).
      
      This new domain will come into play only on multi-core systems with shared
      caches.  On other systems, this sched domain will be removed by domain
      degeneration code.  This new domain can be also used for implementing power
      savings policy (see OLS 2005 CMP kernel scheduler paper for more details..
      I will post another patch for power savings policy soon)
      
      Most of the arch/* file changes are for cpu_coregroup_map() implementation.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1e9f28fa
  15. 25 Mar, 2006 7 commits