1. 27 6月, 2006 14 次提交
  2. 26 6月, 2006 2 次提交
  3. 23 6月, 2006 7 次提交
  4. 22 6月, 2006 1 次提交
    • C
      [PATCH] PCI: fix issues with extended conf space when MMCONFIG disabled because of e820 · ead2bfeb
      Chuck Ebbert 提交于
      On 15 Jun 2006 03:45:10 +0200, Andi Kleen wrote:
      
      > Anyways I would say that if the BIOS can't get MCFG right then
      > it's likely not been validated on that board and shouldn't be used.
      
      According to Petr Vandrovec:
      
       ... "What is important (and checked) is address of MMCONFIG reported by MCFG
       table...  Unfortunately code does not bother with printing that address :-(
      
       "Another problem is that code has hardcoded that MMCONFIG area is 256MB large.
       Unfortunately for the code PCI specification allows any power of two between 2MB
       and 256MB if vendor knows that such amount of busses (from 2 to 128) will be
       sufficient for system.  With notebook it is quite possible that not full 8 bits
       are implemented for MMCONFIG bus number."
      
      So here is a patch.  Unfortunately my system still fails the test because
      it doesn't reserve any part of the MMCONFIG area, but this may fix others.
      
      Booted on x86_64, only compiled on i386.  x86_64 still remaps the max area
      (256MB) even though only 2MB is checked... but 2.6.16 had no check at all
      so it is still better.
      
      PCI: reduce size of x86 MMCONFIG reserved area check
      
      1.  Print the address of the MMCONFIG area when the test for that area
          being reserved fails.
      
      2.  Only check if the first 2MB is reserved, as that is the minimum.
      Signed-off-by: NChuck Ebbert <76306.1226@compuserve.com>
      Acked-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ead2bfeb
  5. 09 6月, 2006 1 次提交
    • A
      [PATCH] Fix HPET operation on 64-bit NVIDIA platforms · a2ef3a50
      Andy Currid 提交于
      From: "Andy Currid" <ACurrid@nvidia.com>
      
      This patch fixes a kernel panic during boot that occurs on NVIDIA platforms
      that have HPET enabled.
      
      When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2 and is
      advertised as such in the ACPI APIC table - but an earlier workaround in the
      kernel was ignoring this override.  The fix is to honor timer IRQ overrides
      from ACPI when HPET is detected on an NVIDIA platform.
      Signed-off-by: NAndy Currid <acurrid@nvidia.com>
      Cc: "Brown, Len" <len.brown@intel.com>
      Cc: "Yu, Luming" <luming.yu@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a2ef3a50
  6. 31 5月, 2006 6 次提交
  7. 22 5月, 2006 1 次提交
  8. 16 5月, 2006 3 次提交
  9. 09 5月, 2006 5 次提交
    • A
      [PATCH] x86_64: Avoid EBDA area in early boot allocator · ac71d12c
      Andi Kleen 提交于
      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: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ac71d12c
    • C
      [PATCH] x86_64: add nmi_exit to die_nmi · 8b1ffe95
      Corey Minyard 提交于
      Playing with NMI watchdog on x86_64, I discovered that it didn't
      do what I expected.  It always panic-ed, even when it didn't
      happen from interrupt context.  This patch solves that
      problem for me.  Also, in this case, do_exit() will be called
      with interrupts disabled, I believe.  Would it be wise to also
      call local_irq_enable() after nmi_exit()?
      [Yes I added it -AK]
      
      Currently, on x86_64, any NMI watchdog timeout will cause a panic
      because the irq count will always be set to be in an interrupt
      when do_exit() is called from die_nmi().  If we add nmi_exit() to
      the die_nmi() call (since the nmi will never exit "normally")
      it seems to solve this problem.  The following small program
      can be used to trigger the NMI watchdog to reproduce this:
        main ()
        {
              iopl(3);
              for (;;) asm("cli");
        }
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8b1ffe95
    • C
      [PATCH] x86_64: fix die_lock nesting · cdc60a4c
      Corey Minyard 提交于
      I noticed this when poking around in this area.
      
      The oops_begin() function in x86_64 would only conditionally claim
      the die_lock if the call is nested, but oops_end() would always
      release the spinlock. This patch adds a nest count for the die lock
      so that the release of the lock is only done on the final oops_end().
      Signed-off-by: NCorey Minyard <minyard@acm.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cdc60a4c
    • A
      [PATCH] x86_64: Check for too many northbridges in IOMMU code · 5192d84e
      Andi Kleen 提交于
      The IOMMU code can only deal with 8 northbridges. Error out when
      more are found.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5192d84e
    • K
      [PATCH] x86_64: avoid IRQ0 ioapic pin collision · e0c1e9bf
      Kimball Murray 提交于
      The patch addresses a problem with ACPI SCI interrupt entry, which gets
      re-used, and the IRQ is assigned to another unrelated device.  The patch
      corrects the code such that SCI IRQ is skipped and duplicate entry is
      avoided.  Second issue came up with VIA chipset, the problem was caused by
      original patch assigning IRQs starting 16 and up.  The VIA chipset uses
      4-bit IRQ register for internal interrupt routing, and therefore cannot
      handle IRQ numbers assigned to its devices.  The patch corrects this
      problem by allowing PCI IRQs below 16.
      
      Cc: len.brown@intel.com
      
      Signed-off by: Natalie Protasevich <Natalie.Protasevich@unisys.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e0c1e9bf