1. 02 Jun, 2008 3 commits
    • Pavel Machek's avatar
      suspend-vs-iommu: prevent suspend if we could not resume · f529626a
      Pavel Machek authored
      iommu/gart support misses suspend/resume code, which can do bad stuff,
      including memory corruption on resume.  Prevent system suspend in case we
      would be unable to resume.
      Signed-off-by: default avatarPavel Machek <pavel@suse.cz>
      Tested-by: default avatarPatrick <ragamuffin@datacomm.ch>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f529626a
    • Miquel van Smoorenburg's avatar
      x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY · db9f600b
      Miquel van Smoorenburg authored
      On Wed, 2008-05-28 at 04:47 +0200, Andi Kleen wrote:
      > > So...  why not just remove the setting of __GFP_NORETRY?  Why is it
      > > wrong to oom-kill things in this case?
      >
      > When the 16MB zone overflows (which can be common in some workloads)
      > calling the OOM killer is pretty useless because it has barely any
      > real user data [only exception would be the "only 16MB" case Alan
      > mentioned]. Killing random processes in this case is bad.
      >
      > I think for 16MB __GFP_NORETRY is ok because there should be
      > nothing freeable in there so looping is useless. Only exception would be the
      > "only 16MB total" case again but I'm not sure 2.6 supports that at all
      > on x86.
      >
      > On the other hand d_a_c() does more allocations than just 16MB, especially
      > on 64bit and the other zones need different strategies.
      
      Okay, so how about this then ?
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      db9f600b
    • Bertram Felgenhauer's avatar
      pci, x86: add workaround for bug in ASUS A7V600 BIOS (rev 1005) · 75b19b79
      Bertram Felgenhauer authored
      This BIOS claims the VIA 8237 south bridge to be compatible with VIA 586,
      which it is not.
      
      Without this patch, I get the following warning while booting,
      among others,
      
      | PCI: Using IRQ router VIA [1106/3227] at 0000:00:11.0
      | ------------[ cut here ]------------
      | WARNING: at arch/x86/pci/irq.c:265 pirq_via586_get+0x4a/0x60()
      | Modules linked in:
      | Pid: 1, comm: swapper Not tainted 2.6.26-rc4-00015-g1ec7d99c #1
      |  [<c0119fd4>] warn_on_slowpath+0x54/0x70
      |  [<c02246e0>] ? vt_console_print+0x210/0x2b0
      |  [<c02244d0>] ? vt_console_print+0x0/0x2b0
      |  [<c011a413>] ? __call_console_drivers+0x43/0x60
      |  [<c011a482>] ? _call_console_drivers+0x52/0x80
      |  [<c011aa89>] ? release_console_sem+0x1c9/0x200
      |  [<c0291d21>] ? raw_pci_read+0x41/0x70
      |  [<c0291e8f>] ? pci_read+0x2f/0x40
      |  [<c029151a>] pirq_via586_get+0x4a/0x60
      |  [<c02914d0>] ? pirq_via586_get+0x0/0x60
      |  [<c029178d>] pcibios_lookup_irq+0x15d/0x430
      |  [<c03b895a>] pcibios_irq_init+0x17a/0x3e0
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c03a6763>] kernel_init+0x73/0x250
      |  [<c03b87e0>] ? pcibios_irq_init+0x0/0x3e0
      |  [<c0114d00>] ? schedule_tail+0x10/0x40
      |  [<c0102dee>] ? ret_from_fork+0x6/0x1c
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c010324b>] kernel_thread_helper+0x7/0x1c
      |  =======================
      | ---[ end trace 4eaa2a86a8e2da22 ]---
      
      and IRQ trouble later,
      
      | irq 10: nobody cared (try booting with the "irqpoll" option)
      
      Now that's an VIA 8237 chip, so pirq_via586_get shouldn't be called
      at all; adding this workaround to via_router_probe() fixes the
      problem for me.
      
      Amazingly I have a 2.6.23.8 kernel that somehow works fine ... I'll
      never understand why.
      Signed-off-by: default avatarBertram Felgenhauer <int-e@gmx.de>
      Acked-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      75b19b79
  2. 24 May, 2008 1 commit
  3. 22 May, 2008 1 commit
    • Tony Camuso's avatar
      PCI: Correct last two HP entries in the bfsort whitelist · a1676072
      Tony Camuso authored
      Greetings.
      
      There is a code flaw in the bfsort whitelist, where there are redundant
      entries for the same two HP systems, DL385 G2 and DL585 G2. This patch
      replaces those redundant entries with the correct ones. The correct
      entries are for large-volume systems, the DL360 and DL380.
      
      -----------------------------------------------------------------------
      
      commit ec69f0374c3b0ad7ea991b0e9ac00377acfe5b1a
      Author: Tony Camuso <tony.camuso@hp.com>
      Date:   Wed May 14 07:09:28 2008 -0400
      
           Replace Redundant Whitelist Entries with the Correct Ones
      
           The ProLiant DL585 G2 and the DL585 G2 are entered reundantly
           in the dmi_system_id table. What should have been there are the
           DL360 and DL380. This patch simply replaces the redundant
           entries with the correct entries.
      
       arch/x86/pci/common.c |    8 ++++----
       1 file changed, 4 insertions(+), 4 deletions(-)
      Signed-off-by: default avatarTony Camuso <tony.camuso@hp.com>
      Signed-off-by: default avatarPat Schoeller <patrick.schoeller@hp.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      a1676072
  4. 21 May, 2008 25 commits
  5. 20 May, 2008 10 commits