1. 06 8月, 2010 1 次提交
    • E
      x86, apic: Map the local apic when parsing the MP table. · 5989cd6a
      Eric W. Biederman 提交于
      This fixes a regression in 2.6.35 from 2.6.34, that is
      present for select models of Intel cpus when people are
      using an MP table.
      
      The commit cf7500c0
      "x86, ioapic: In mpparse use mp_register_ioapic" started
      calling mp_register_ioapic from MP_ioapic_info.  An extremely
      simple change that was obviously correct.  Unfortunately
      mp_register_ioapic did just a little more than the previous
      hand crafted code and so we gained this call path.
      
      The problem call path is:
      MP_ioapic_info()
        mp_register_ioapic()
         io_apic_unique_id()
           io_apic_get_unique_id()
             get_physical_broadcast()
               modern_apic()
                 lapic_get_version()
                   apic_read(APIC_LVR)
      
      Which turned out to be a problem because the local apic
      was not mapped, at that point, unlike the similar point
      in the ACPI parsing code.
      
      This problem is fixed by mapping the local apic when
      parsing the mptable as soon as we reasonably can.
      
      Looking at the number of places we setup the fixmap for
      the local apic, I see some serious simplification opportunities.
      For the moment except for not duplicating the setting up of the
      fixmap in init_apic_mappings, I have not acted on them.
      
      The regression from 2.6.34 is tracked in bug
      https://bugzilla.kernel.org/show_bug.cgi?id=16173
      
      Cc: <stable@kernel.org> 2.6.35
      Reported-by: NDavid Hill <hilld@binarystorm.net>
      Reported-by: NTvrtko Ursulin <tvrtko.ursulin@sophos.com>
      Tested-by: NTvrtko Ursulin <tvrtko.ursulin@sophos.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <m1eiee86jg.fsf_-_@fess.ebiederm.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      5989cd6a
  2. 10 6月, 2010 1 次提交
    • E
      x86, irq: Rename gsi_end gsi_top, and fix off by one errors · a4384df3
      Eric W. Biederman 提交于
      When I introduced the global variable gsi_end I thought gsi_end on
      io_apics was one past the end of the gsi range for the io_apic.  After
      it was pointed out the the range on io_apics was inclusive I changed
      my global variable to match.  That was a big mistake.  Inclusive
      semantics without a range start cannot describe the case when no gsi's
      are allocated.  Describing the case where no gsi's are allocated is
      important in sfi.c and mpparse.c so that we can assign gsi numbers
      instead of blindly copying the gsi assignments the BIOS has done as we
      do in the acpi case.
      
      To keep from getting the global variable confused with the gsi range
      end rename it gsi_top.
      
      To allow describing the case where no gsi's are allocated have gsi_top
      be one place the highest gsi number seen in the system.
      
      This fixes an off by one bug in sfi.c:
      Reported-by: Njacob pan <jacob.jun.pan@linux.intel.com>
      
      This fixes the same off by one bug in mpparse.c:
      
      This fixes an off unreachable by one bug in acpi/boot.c:irq_to_gsi
      Reported-by: NYinghai <yinghai.lu@oracle.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <m17hm9jre7.fsf_-_@fess.ebiederm.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      a4384df3
  3. 05 5月, 2010 1 次提交
    • E
      x86, ioapic: In mpparse use mp_register_ioapic · cf7500c0
      Eric W. Biederman 提交于
      Long ago MP_ioapic_info was the primary way of setting up our
      ioapic data structures and mp_register_ioapic was a compatibility
      shim for acpi code.  Now the situation is reversed and
      and mp_register_ioapic is the primary way of setting up our
      ioapic data structures.
      
      Keep the setting up of ioapic data structures uniform by
      having mp_register_ioapic call mp_register_ioapic.
      
      This changes a few fields:
      
      - type: is now hardset to MP_IOAPIC but type had to
        bey MP_IOAPIC or MP_ioapic_info would not have been called.
      
      - flags: is now hard coded to MPC_APIC_USABLE.
        We require flags to contain at least MPC_APIC_USEBLE in
        MP_ioapic_info and we don't ever examine flags so dropping
        a few flags that might possibly exist that we have never
        used is harmless.
      
      - apicaddr: Unchanged
      
      - apicver: Read from the ioapic instead of using the cached
        hardware value in the MP table.  The real hardware value
        will be more accurate.
      
      - apicid: Now verified to be unique and changed if it is not.
        If the BIOS got this right this is a noop.  If the BIOS did
        not fixing things appears to be the better solution.
      
      This adds gsi_base and gsi_end values to our ioapics defined with
      the mpatable, which will make our lives simpler later since
      we can always assume gsi_base and gsi_end are valid.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <1269936436-7039-10-git-send-email-ebiederm@xmission.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      cf7500c0
  4. 02 4月, 2010 1 次提交
  5. 10 2月, 2010 1 次提交
    • S
      x86, apic: Don't use logical-flat mode when CPU hotplug may exceed 8 CPUs · 681ee44d
      Suresh Siddha 提交于
      We need to fall back from logical-flat APIC mode to physical-flat mode
      when we have more than 8 CPUs.  However, in the presence of CPU
      hotplug(with bios listing not enabled but possible cpus as disabled cpus in
      MADT), we have to consider the number of possible CPUs rather than
      the number of current CPUs; otherwise we may cross the 8-CPU boundary
      when CPUs are added later.
      
      32bit apic code can use more cleanups (like the removal of vendor checks in
      32bit default_setup_apic_routing()) and more unifications with 64bit code.
      Yinghai has some patches in works already. This patch addresses the boot issue
      that is reported in the virtualization guest context.
      
      [ hpa: incorporated function annotation feedback from Yinghai Lu ]
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <1265767304.2833.19.camel@sbs-t61.sc.intel.com>
      Acked-by: NShaohui Zheng <shaohui.zheng@intel.com>
      Reviewed-by: NYinghai Lu <yinghai@kernel.org>
      Cc: <stable@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      681ee44d
  6. 11 12月, 2009 1 次提交
    • Y
      x86: Use find_e820() instead of hard coded trampoline address · 893f38d1
      Yinghai Lu 提交于
      Jens found the following crash/regression:
      
      [    0.000000] found SMP MP-table at [ffff8800000fdd80] fdd80
      [    0.000000] Kernel panic - not syncing: Overlapping early reservations 12-f011 MP-table mpc to 0-fff BIOS data page
      
      and
      
      [    0.000000] Kernel panic - not syncing: Overlapping early reservations 12-f011 MP-table mpc to 6000-7fff TRAMPOLINE
      
      and bisected it to b24c2a92 ("x86: Move find_smp_config()
      earlier and avoid bootmem usage").
      
      It turns out the BIOS is using the first 64k for mptable,
      without reserving it.
      
      So try to find good range for the real-mode trampoline instead of
      hard coding it, in case some bios tries to use that range for sth.
      Reported-by: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Tested-by: NJens Axboe <jens.axboe@oracle.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      LKML-Reference: <4B21630A.6000308@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      893f38d1
  7. 24 11月, 2009 1 次提交
  8. 31 8月, 2009 1 次提交
  9. 27 8月, 2009 5 次提交
  10. 26 8月, 2009 1 次提交
  11. 18 5月, 2009 2 次提交
  12. 11 5月, 2009 1 次提交
    • Y
      x86: fix alloc_mptable() · ee214558
      Yinghai Lu 提交于
      Fix the conditions when we stop updating the mptable due to
      running out of slots.
      
      [ Impact: fix memory corruption / non-working update_mptable boot parameter ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <4A01C3BB.1000609@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ee214558
  13. 12 4月, 2009 1 次提交
    • R
      x86: Fix section mismatches in mpparse · 57592224
      Rakib Mullick 提交于
      Impact: fix section mismatch
      
      In arch/x86/kernel/mpparse.c, smp_reserve_bootmem() has been called
      and also refers to a function which is in .init section. Thus causes
      the first warning. And check_irq_src() also requires an __init,
      because it refers to an .init section.
      Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <b9df5fa10904102004g51265d9axc8d07278bfdb6ba0@mail.gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      57592224
  14. 21 3月, 2009 2 次提交
  15. 19 3月, 2009 2 次提交
  16. 13 3月, 2009 1 次提交
  17. 05 3月, 2009 2 次提交
  18. 23 2月, 2009 1 次提交
    • Y
      x86: check mptable physptr with max_low_pfn on 32bit · ecda0628
      Yinghai Lu 提交于
      Impact: fix early crash on LinuxBIOS systems
      
      Kevin O'Connor reported that Coreboot aka LinuxBIOS tries to put
      mptable somewhere very high, well above max_low_pfn (below which
      BIOSes generally put the mptable), causing a panic.
      
      The BIOS will probably be changed to be compatible with older
      Linus versions, but nevertheless the MP-spec does not forbid
      an MP-table in arbitrary system RAM, so make sure it all
      works even if the table is in an unexpected place.
      
      Check physptr with max_low_pfn * PAGE_SIZE.
      Reported-by: NKevin O'Connor <kevin@koconnor.net>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Stefan Reinauer <stepan@coresystems.de>
      Cc: coreboot@coreboot.org
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ecda0628
  19. 18 2月, 2009 1 次提交
  20. 12 2月, 2009 1 次提交
  21. 31 1月, 2009 1 次提交
  22. 30 1月, 2009 1 次提交
  23. 29 1月, 2009 7 次提交
  24. 14 1月, 2009 2 次提交
  25. 13 1月, 2009 1 次提交