1. 16 11月, 2006 11 次提交
  2. 15 11月, 2006 18 次提交
  3. 14 11月, 2006 11 次提交
    • A
      [PATCH] x86-64: Fix race in exit_idle · 9446868b
      Andi Kleen 提交于
      When another interrupt happens in exit_idle the exit idle notifier
      could be called an incorrect number of times.
      
      Add a test_and_clear_bit_pda and use it handle the bit
      atomically against interrupts to avoid this.
      
      Pointed out by Stephane Eranian
      Signed-off-by: NAndi Kleen <ak@suse.de>
      9446868b
    • A
      [PATCH] x86-64: Fix vgetcpu when CONFIG_HOTPLUG_CPU is disabled · 8c131af1
      Andi Kleen 提交于
      The vgetcpu per CPU initialization previously relied on CPU hotplug
      events for all CPUs to initialize the per CPU state. That only
      worked only on kernels with CONFIG_HOTPLUG_CPU enabled.  On the
      others some CPUs didn't get their state initialized properly
      and vgetcpu wouldn't work.
      
      Change the initialization sequence to instead run in a normal
      initcall (which runs after the normal CPU bootup) and initialize
      all running CPUs there. Later hotplug CPUs are still handled
      with an hotplug notifier.
      
      This actually simplifies the code somewhat.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      8c131af1
    • A
      [PATCH] x86: Add acpi_user_timer_override option for Asus boards · fa18f477
      Andi Kleen 提交于
      Timer overrides are normally disabled on Nvidia board because
      they are commonly wrong, except on new ones with HPET support.
      Unfortunately there are quite some Asus boards around that
      don't have HPET, but need a timer override.
      
      We don't know yet how to handle this transparently,
      but at least add a command line option to force the timer override
      and let them boot.
      
      Cc: len.brown@intel.com
      Signed-off-by: NAndi Kleen <ak@suse.de>
      fa18f477
    • M
      [PATCH] x86-64: setup saved_max_pfn correctly (kdump) · 15803a43
      Magnus Damm 提交于
      x86_64: setup saved_max_pfn correctly
      
      2.6.19-rc4 has broken CONFIG_CRASH_DUMP support on x86_64. It is impossible
      to read out the kernel contents from /proc/vmcore because saved_max_pfn is set
      to zero instead of the max_pfn value before the user map is setup.
      
      This happens because saved_max_pfn is initialized at parse_early_param() time,
      and at this time no active regions have been registered. save_max_pfn is setup
      from e820_end_of_ram(), more exact find_max_pfn_with_active_regions() which
      returns 0 because no regions exist.
      
      This patch fixes this by registering before and removing after the call
      to e820_end_of_ram().
      Signed-off-by: NMagnus Damm <magnus@valinux.co.jp>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      15803a43
    • A
      [PATCH] x86-64: Handle reserve_bootmem_generic beyond end_pfn · 5e58a02a
      Andi Kleen 提交于
      This can happen on kexec kernels with some configurations, in particularly
      on Unisys ES7000 systems.
      
      Analysis by Amul Shah
      
      Cc: Amul Shah <amul.shah@unisys.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      5e58a02a
    • S
      [PATCH] x86-64: shorten the x86_64 boot setup GDT to what the comment says · 51d67a48
      Steven Rostedt 提交于
      Stephen Tweedie, Herbert Xu, and myself have been struggling with a very
      nasty bug in Xen.  But it also pointed out a small bug in the x86_64
      kernel boot setup.
      
      The GDT limit being setup by the initial bzImage code when entering into
      protected mode is way too big.  The comment by the code states that the
      size of the GDT is 2048, but the actual size being set up is much bigger
      (32768). This happens simply because of one extra '0'.
      
      Instead of setting up a 0x800 size, 0x8000 is set up.  On bare metal this
      is fine because the CPU wont load any segments unless  they are
      explicitly used.  But unfortunately, this breaks Xen on vmx FV, since it
      (for now) blindly loads all the segments into the VMCS if they are less
      than the gdt limit. Since the real mode segments are around 0x3000, we are
      getting junk into the VMCS and that later causes an exception.
      
      Stephen Tweedie has written up a patch to fix the Xen side and will be
      submitting that to those folks. But that doesn't excuse the GDT limit
      being a magnitude too big.
      
      AK: changed to compute true gdt size in assembler, fixed comment
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      51d67a48
    • A
      [PATCH] x86-64: Fix PTRACE_[SG]ET_THREAD_AREA regression with ia32 emulation. · 14679eb3
      Andi Kleen 提交于
      ptrace(PTRACE_[SG]ET_THREAD_AREA) calls from ia32 code
      should be passed onto the x86_64 implementation.
      
      The default case in sys32_ptrace used to call to sys_ptrace(), but is
      now EINVAL.  This patch fixes a regression caused by that changed.
      Signed-off-by: NMike McCormack <mike@codeweavers.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      14679eb3
    • A
      [PATCH] x86-64: Fix partial page check to ensure unusable memory is not being marked usable. · 14f448e3
      Aaron Durbin 提交于
      Fix partial page check in e820_register_active_regions to ensure
      partial pages are
      not being marked as active in the memory pool.
      Signed-off-by: NAaron Durbin <adurbin@google.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      14f448e3
    • A
      Revert "[PATCH] MMCONFIG and new Intel motherboards" · 64e72e41
      Andi Kleen 提交于
      This reverts 4c6e052a commit.
      
      Following Linus' i386 change: revert resource reservation
      for mmcfg config now. Will be revisited in .20 hopefully.
      64e72e41
    • D
      libata: fix double-completion on error · 253b92ec
      Darrick J. Wong 提交于
      A curious thing happens, however, when ata_qc_new_init fails to get
      an ata_queued_cmd:
      
      First, ata_qc_new_init handles the failure like this:
          cmd->result = (DID_OK << 16) | (QUEUE_FULL << 1);
          done(cmd);
      
      Then, we return to ata_scsi_translate and do this:
          err_mem:
              cmd->result = (DID_ERROR << 16);
              done(cmd);
      
      It appears to me that first we set a status code indicating that we're
      ok but the device queue is full and finish the command,  but then
      we blow away that status code and replace it with an error flag and
      finish the command a second time!  That does not seem to be desirable
      behavior since we merely want the I/O to wait until a command slot
      frees up, not send errors up the block layer.
      
      In the err_mem case, we should simply exit out of ata_scsi_translate
      instead.
      Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      253b92ec
    • A
      [PATCH] pata_artop: fix "& (1 >>" typo · 3f9dd27a
      Alexey Dobriyan 提交于
      Signed-off-by: NAlexey Dobriyan <adobriyan@openvz.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      3f9dd27a