1. 03 5月, 2007 24 次提交
  2. 29 4月, 2007 1 次提交
    • J
      libata/IDE: remove combined mode quirk · 8cdfb29c
      Jeff Garzik 提交于
      Both old-IDE and libata should be able handle all controllers and
      devices found using normal resource reservation methods.
      
      This eliminates the awful, low-performing split-driver configuration
      where old-IDE drove the PATA portion of a PCI device, in PIO-only mode,
      and libata drove the SATA portion of the /same/ PCI device, in DMA mode.
      Typically vendors would ship SATA hard drive / PATA optical
      configuration, which would lend itself to slow (PIO-only) CD-ROM
      performance.
      
      For Intel users running in combined mode, it is now wholly dependent on
      your driver choice (potentially link order, if you compile both drivers
      in) whether old-IDE or libata will drive your hardware.
      
      In either case, you will get full performance from both SATA and PATA
      ports now, without having to pass a kernel command line parameter.
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      8cdfb29c
  3. 24 4月, 2007 2 次提交
  4. 18 4月, 2007 1 次提交
  5. 17 4月, 2007 1 次提交
  6. 16 4月, 2007 2 次提交
    • A
      [PATCH] x86: Fix potential overflow in perfctr reservation · 1714f9bf
      Andi Kleen 提交于
      While reviewing this code again I found a potential overflow of the bitmap.
      The p4 oprofile can theoretically set bits beyond the reservation bitmap for
      specific configurations. Avoid that by sizing the bitmaps properly.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      1714f9bf
    • A
      [PATCH] x86: Fix gcc 4.2 _proxy_pda workaround · 08269c6d
      Andi Kleen 提交于
      Due to an over aggressive optimizer gcc 4.2 cannot optimize away _proxy_pda
      in all cases (counter intuitive, but true).  This breaks loading of some
      modules.
      
      The earlier workaround to just export a dummy symbol didn't work unfortunately
      because the module code ignores exports with 0 value.
      
      Make it 1 instead.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      08269c6d
  7. 15 4月, 2007 1 次提交
  8. 09 4月, 2007 1 次提交
    • A
      [PATCH] x86_64 early quirks: fix early_qrk[] section tag · c993c735
      Andrew Morton 提交于
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:nvidia_bugs from .data between 'early_qrk' (at offset 0x8428) and 'enable_cpu_hotplug'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:via_bugs from .data between 'early_qrk' (at offset 0x8438) and 'enable_cpu_hotplug'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:ati_bugs from .data between 'early_qrk' (at offset 0x8448) and 'enable_cpu_hotplug'
      
      The compiler is putting it into .data because the __initdata is in the wrong
      place.
      
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c993c735
  9. 02 4月, 2007 3 次提交
  10. 29 3月, 2007 1 次提交
  11. 28 3月, 2007 1 次提交
    • R
      [PATCH] Revert "swsusp: disable nonboot CPUs before entering platform suspend" · 436ce716
      Rafael J. Wysocki 提交于
      This reverts commit 94985134 and
      insteads removes the WARN_ON() that caused that commit in the first
      place.
      
      The problem is that we call disable_nonboot_cpus() in swsusp before
      powering down the system in order to avoid triggering the WARN_ON()
      in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() and this doesn't
      work well on Thomas' system.
      
      So instead, remove the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:
      init_low_mapping(), which triggers every time during the suspend to disk
      in the platform mode, as the potential problem it is related to doesn't
      seem to occur in practice.
      
      [ I think we might want to disallow the case of multiple users of that
        mm, or something.  Normally, playing with the current process page
        tables on the current CPU should be fine as long as we don't have
        other threads using those tables at the same time..
      
        Anyway, not pretty, but better than the warning or the lockup - Linus ]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      436ce716
  12. 24 3月, 2007 2 次提交