An error occurred fetching the project authors.
  1. 22 Jul, 2007 2 commits
  2. 08 May, 2007 1 commit
  3. 02 May, 2007 1 commit
  4. 16 Mar, 2007 1 commit
    • Sam Ravnborg's avatar
      [PATCH] x86-64: fix section mismatch warnings · 43999d9e
      Sam Ravnborg authored
      Fix the following section mismatch warnings on x86_64:
      (build using defconfig)
      
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:mtrr_bp_init from .text between 'identify_cpu' (at offset 0x65eb) and 'IRQ0x20_interrupt'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data: from .text between 'finish_e820_parsing' (at offset 0x7dc2) and 'early_panic'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:e820_print_map from .text between 'finish_e820_parsing' (at offset 0x7de1) and 'early_panic'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:num_processors from .text between 'acpi_unmap_lsapic' (at offset 0xc88f) and 'acpi_register_ioapic'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:disabled_cpus from .text between 'MP_processor_info' (at offset 0x11f35) and 'mp_register_lapic'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:num_processors from .text between 'MP_processor_info' (at offset 0x11f6e) and 'mp_register_lapic'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:num_processors from .text between 'MP_processor_info' (at offset 0x11f93) and 'mp_register_lapic'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:fix_aperture from .text between 'gart_parse_options' (at offset 0x15517) and 'iommu_full'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:fix_aperture from .text between 'gart_parse_options' (at offset 0x1552c) and 'iommu_full'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_allowed from .text between 'gart_parse_options' (at offset 0x1553d) and 'iommu_full'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_allowed from .text between 'gart_parse_options' (at offset 0x15552) and 'iommu_full'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_allowed from .text between 'gart_parse_options' (at offset 0x15561) and 'iommu_full'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_allowed from .text between 'gart_parse_options' (at offset 0x15577) and 'iommu_full'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:fallback_aper_force from .text between 'gart_parse_options' (at offset 0x1558a) and 'iommu_full'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:fallback_aper_order from .text between 'gart_parse_options' (at offset 0x155bf) and 'iommu_full'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:timer_over_8254 from .text between 'ati_bugs' (at offset 0x16344) and 'via_bugs'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:timer_over_8254 from .text between 'ati_bugs' (at offset 0x16356) and 'via_bugs'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_allowed from .text between 'via_bugs' (at offset 0x16380) and 'nvidia_bugs'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_disabled from .text between 'via_bugs' (at offset 0x16397) and 'nvidia_bugs'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:acpi_use_timer_override from .text between 'nvidia_bugs' (at offset 0x163a7) and 'arch_unregister_cpu'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:nvidia_hpet_check from .text between 'nvidia_bugs' (at offset 0x163b1) and 'arch_unregister_cpu'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data: from .text between 'nvidia_bugs' (at offset 0x163be) and 'arch_unregister_cpu'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data: from .text between 'nvidia_bugs' (at offset 0x163d1) and 'arch_unregister_cpu'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:acpi_skip_timer_override from .text between 'nvidia_bugs' (at offset 0x163e1) and 'arch_unregister_cpu'
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:quirk_intel_irqbalance from .text between 'intel_bugs' (at offset 0x1633c) and 'ati_bugs'
      
      But adds:
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:get_mtrr_state from .text between 'mtrr_bp_init' (at offset 0xb887) and 'ipi_handler'
      
      The warnings does not show up during a normal build due to kbuild
      failing to check for section mismatch in vmlinux.
      To see these warnings run:
      scripts/mod/modpost arch/x86_64/kernel/built-in.o
      
      kbuild will be fixed but the 'noise-level' had to be decresed first.
      There remains a few section mismatch warnigns for x86_64 for areas where I did
      not feel confident.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      43999d9e
  5. 03 Feb, 2007 1 commit
  6. 07 Dec, 2006 1 commit
  7. 04 Oct, 2006 1 commit
  8. 29 Sep, 2006 1 commit
  9. 26 Sep, 2006 11 commits
  10. 30 Jun, 2006 1 commit
  11. 08 May, 2006 1 commit
    • Kimball Murray's avatar
      [PATCH] x86_64: avoid IRQ0 ioapic pin collision · e0c1e9bf
      Kimball Murray authored
      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: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e0c1e9bf
  12. 25 Mar, 2006 1 commit
  13. 17 Feb, 2006 1 commit
  14. 28 Dec, 2005 1 commit
  15. 10 Dec, 2005 1 commit
    • Bob Moore's avatar
      [ACPI] ACPICA 20050930 · 50eca3eb
      Bob Moore authored
      Completed a major overhaul of the Resource Manager code -
      specifically, optimizations in the area of the AML/internal
      resource conversion code. The code has been optimized to
      simplify and eliminate duplicated code, CPU stack use has
      been decreased by optimizing function parameters and local
      variables, and naming conventions across the manager have
      been standardized for clarity and ease of maintenance (this
      includes function, parameter, variable, and struct/typedef
      names.)
      
      All Resource Manager dispatch and information tables have
      been moved to a single location for clarity and ease of
      maintenance. One new file was created, named "rsinfo.c".
      
      The ACPI return macros (return_ACPI_STATUS, etc.) have
      been modified to guarantee that the argument is
      not evaluated twice, making them less prone to macro
      side-effects. However, since there exists the possibility
      of additional stack use if a particular compiler cannot
      optimize them (such as in the debug generation case),
      the original macros are optionally available.  Note that
      some invocations of the return_VALUE macro may now cause
      size mismatch warnings; the return_UINT8 and return_UINT32
      macros are provided to eliminate these. (From Randy Dunlap)
      
      Implemented a new mechanism to enable debug tracing for
      individual control methods. A new external interface,
      acpi_debug_trace(), is provided to enable this mechanism. The
      intent is to allow the host OS to easily enable and disable
      tracing for problematic control methods. This interface
      can be easily exposed to a user or debugger interface if
      desired. See the file psxface.c for details.
      
      acpi_ut_callocate() will now return a valid pointer if a
      length of zero is specified - a length of one is used
      and a warning is issued. This matches the behavior of
      acpi_ut_allocate().
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      50eca3eb
  16. 15 Nov, 2005 4 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: Increase the maximum number of local APICs to the maximum · 8893166f
      Andi Kleen authored
      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: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8893166f
    • Andi Kleen's avatar
      [PATCH] x86_64: New heuristics to find out hotpluggable CPUs. · 420f8f68
      Andi Kleen authored
      With a NR_CPUS==128 kernel with CPU hotplug enabled we would waste 4MB
      on per CPU data of all possible CPUs.  The reason was that HOTPLUG
      always set up possible map to NR_CPUS cpus and then we need to allocate
      that much (each per CPU data is roughly ~32k now)
      
      The underlying problem is that ACPI didn't tell us how many hotplug CPUs
      the platform supports.  So the old code just assumed all, which would
      lead to this memory wastage.
      
      This implements some new heuristics:
      
       - If the BIOS specified disabled CPUs in the ACPI/mptables assume they
         can be enabled later (this is bending the ACPI specification a bit,
         but seems like a obvious extension)
       - The user can overwrite it with a new additionals_cpus=NUM option
       - Otherwise use half of the available CPUs or 2, whatever is more.
      
      Cc: ashok.raj@intel.com
      Cc: len.brown@intel.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      420f8f68
    • Siddha, Suresh B's avatar
      [PATCH] x86_64: Unmap NULL during early bootup · f6c2e333
      Siddha, Suresh B authored
      We should zap the low mappings, as soon as possible, so that we can catch
      kernel bugs more effectively. Previously early boot had NULL mapped
      and didn't trap on NULL references.
      
      This patch introduces boot_level4_pgt, which will always have low identity
      addresses mapped.  Druing boot, all the processors will use this as their
      level4 pgt.  On BP, we will switch to init_level4_pgt as soon as we enter C
      code and zap the low mappings as soon as we are done with the usage of
      identity low mapped addresses.  On AP's we will zap the low mappings as
      soon as we jump to C code.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f6c2e333
    • James Cleverdon's avatar
      [PATCH] i386/x86-64: Share interrupt vectors when there is a large number of interrupt sources · 6004e1b7
      James Cleverdon authored
      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: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6004e1b7
  17. 12 Sep, 2005 3 commits
  18. 24 Aug, 2005 2 commits
  19. 30 Jul, 2005 1 commit
  20. 29 Jul, 2005 1 commit
  21. 23 Jun, 2005 2 commits
    • Natalie Protasevich's avatar
      [PATCH] x86_64: avoid wasting IRQs · 701067c4
      Natalie Protasevich authored
      I suggest to change the way IRQs are handed out to PCI devices.
      
      Currently, each I/O APIC pin gets associated with an IRQ, no matter if the
      pin is used or not.  It is expected that each pin can potentually be
      engaged by a device inserted into the corresponding PCI slot.  However,
      this imposes severe limitation on systems that have designs that employ
      many I/O APICs, only utilizing couple lines of each, such as P64H2 chipset.
      
      It is used in ES7000, and currently, there is no way to boot the system
      with more that 9 I/O APICs.
      
      The simple change below allows to boot a system with say 64 (or more) I/O
      APICs, each providing 1 slot, which otherwise impossible because of the IRQ
      gaps created for unused lines on each I/O APIC.  It does not resolve the
      problem with number of devices that exceeds number of possible IRQs, but
      eases up a tension for IRQs on any large system with potentually large
      number of devices.
      
      I only implemented this for the ACPI boot, since if the system is this big
      and using newer chipsets it is probably (better be!) an ACPI based system
      :).  The change is completely "mechanical" and does not alter any internal
      structures or interrupt model/implementation.  The patch works for both
      i386 and x86_64 archs.  It works with MSIs just fine, and should not
      intervene with implementations like shared vectors, when they get worked
      out and incorporated.
      
      To illustrate, below is the interrupt distribution for 2-cell ES7000 with
      20 I/O APICs, and an Ethernet card in the last slot, which should be eth1
      and which was not configured because its IRQ exceeded allowable number (it
      actially turned out huge - 480!):
      
      zorro-tb2:~ # cat /proc/interrupts
                 CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
        0:      65716      30012      30007      30002      30009      30010      30010      30010    IO-APIC-edge  timer
        4:        373          0        725        280          0          0          0          0    IO-APIC-edge  serial
        8:          0          0          0          0          0          0          0          0    IO-APIC-edge  rtc
        9:          0          0          0          0          0          0          0          0   IO-APIC-level  acpi
       14:         39          3          0          0          0          0          0          0    IO-APIC-edge  ide0
       16:        108         13          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb1
       18:          0          0          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb3
       19:         15          0          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb2
       23:          3          0          0          0          0          0          0          0   IO-APIC-level  ehci_hcd:usb4
       96:       4240        397         18          0          0          0          0          0   IO-APIC-level  aic7xxx
       97:         15          0          0          0          0          0          0          0   IO-APIC-level  aic7xxx
      192:        847          0          0          0          0          0          0          0   IO-APIC-level  eth0
      NMI:          0          0          0          0          0          0          0          0
      LOC:     273423     274528     272829     274228     274092     273761     273827     273694
      ERR:          7
      MIS:          0
      
      Even though the system doesn't have that many devices, some don't get
      enabled only because of IRQ numbering model.
      
      This is the IRQ picture after the patch was applied:
      
      zorro-tb2:~ # cat /proc/interrupts
                 CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
        0:      44169      10004      10004      10001      10004      10003      10004       6135    IO-APIC-edge  timer
        4:        345          0          0          0          0        244          0          0    IO-APIC-edge  serial
        8:          0          0          0          0          0          0          0          0    IO-APIC-edge  rtc
        9:          0          0          0          0          0          0          0          0   IO-APIC-level  acpi
       14:         39          0          3          0          0          0          0          0    IO-APIC-edge  ide0
       17:       4425          0          9          0          0          0          0          0   IO-APIC-level  aic7xxx
       18:         15          0          0          0          0          0          0          0   IO-APIC-level  aic7xxx, uhci_hcd:usb3
       21:        231          0          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb1
       22:         26          0          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb2
       23:          3          0          0          0          0          0          0          0   IO-APIC-level  ehci_hcd:usb4
       24:        348          0          0          0          0          0          0          0   IO-APIC-level  eth0
       25:          6        192          0          0          0          0          0          0   IO-APIC-level  eth1
      NMI:          0          0          0          0          0          0          0          0
      LOC:     107981     107636     108899     108698     108489     108326     108331     108254
      ERR:          7
      MIS:          0
      
      Not only we see the card in the last I/O APIC, but we are not even close to
      using up available IRQs, since we didn't waste any.
      Signed-off-by: default avatarNatalie Protasevich <Natalie.Protasevich@unisys.com>
      Acked-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      701067c4
    • Christoph Lameter's avatar
      [PATCH] x86/x86_64: pcibus_to_node · 8c5a0908
      Christoph Lameter authored
      Define pcibus_to_node to be able to figure out which NUMA node contains a
      given PCI device.  This defines pcibus_to_node(bus) in
      include/linux/topology.h and adjusts the macros for i386 and x86_64 that
      already provided a way to determine the cpumask of a pci device.
      
      x86_64 was changed to not build an array of cpumasks anymore.  Instead an
      array of nodes is build which can be used to generate the cpumask via
      node_to_cpumask.
      Signed-off-by: default avatarChristoph Lameter <christoph@lameter.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8c5a0908
  22. 31 May, 2005 1 commit