1. 15 11月, 2005 2 次提交
    • A
      [PATCH] x86_64: Increase the maximum number of local APICs to the maximum · 8893166f
      Andi Kleen 提交于
      This is needed for large multinode IBM systems which have a sparse
      APIC space in clustered mode, fully covering the available 8 bits.
      
      The previous kernels would limit the local APIC number to 127,
      which caused it to reject some of the CPUs at boot.
      
      I increased the maximum and shrunk the apic_version array a bit
      to make up for that (the version is only 8 bit, so don't need
      an full int to store)
      
      Cc:  Chris McDermott <lcm@us.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8893166f
    • J
      [PATCH] i386/x86-64: Share interrupt vectors when there is a large number of interrupt sources · 6004e1b7
      James Cleverdon 提交于
      Here's a patch that builds on Natalie Protasevich's IRQ compression
      patch and tries to work for MPS boots as well as ACPI.  It is meant for
      a 4-node IBM x460 NUMA box, which was dying because it had interrupt
      pins with GSI numbers > NR_IRQS and thus overflowed irq_desc.
      
      The problem is that this system has 270 GSIs (which are 1:1 mapped with
      I/O APIC RTEs) and an 8-node box would have 540.  This is much bigger
      than NR_IRQS (224 for both i386 and x86_64).  Also, there aren't enough
      vectors to go around.  There are about 190 usable vectors, not counting
      the reserved ones and the unused vectors at 0x20 to 0x2F.  So, my patch
      attempts to compress the GSI range and share vectors by sharing IRQs.
      
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@unisys.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6004e1b7
  2. 25 8月, 2005 1 次提交
  3. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4