1. 07 6月, 2009 1 次提交
    • C
      x86, apic: Fix dummy apic read operation together with broken MP handling · 103428e5
      Cyrill Gorcunov 提交于
      Ingo Molnar reported that read_apic is buggy novadays:
      
      [    0.000000] Using APIC driver default
      [    0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs
      [    0.000000] Local APIC disabled by BIOS -- you can enable it with "lapic"
      [    0.000000] APIC: disable apic facility
      [    0.000000] ------------[ cut here ]------------
      [    0.000000] WARNING: at arch/x86/kernel/apic/apic.c:254 native_apic_read_dummy+0x2d/0x3b()
      [    0.000000] Hardware name: HP OmniBook PC
      
      Indeed we still rely on apic->read operation for SMP compiled
      kernel. And instead of disfigure the SMP code with #ifdef we
      allow to call apic->read. To capture any unexpected results
      we check for apic->read being called for sane reason via
      WARN_ON_ONCE but(!) instead of OR we should use AND logical
      operation (thanks Yinghai for spotting the root of the problem).
      
      Along with that we could be have bad MP table and we are
      to fix it that way no SMP started and no complains about
      BIOS bug if apic was just disabled via command line.
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      LKML-Reference: <20090607124840.GD4547@lenovo>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      103428e5
  2. 02 6月, 2009 1 次提交
  3. 12 5月, 2009 1 次提交
    • Y
      x86: read apic ID in the !acpi_lapic case · 4797f6b0
      Yinghai Lu 提交于
      Ed found that on 32-bit, boot_cpu_physical_apicid is not read right,
      when the mptable is broken.
      
      Interestingly, actually three paths use/set it:
      
       1. acpi: at that time that is already read from reg
       2. mptable: only read from mptable
       3. no madt, and no mptable, that use default apic id 0 for 64-bit, -1 for 32-bit
      
      so we could read the apic id for the 2/3 path. We trust the hardware
      register more than we trust a BIOS data structure (the mptable).
      
      We can also avoid the double set_fixmap() when acpi_lapic
      is used, and also need to move cpu_has_apic earlier and
      call apic_disable().
      
      Also when need to update the apic id, we'd better read and
      set the apic version as well - so that quirks are applied precisely.
      
      v2: make path 3 with 64bit, use -1 as apic id, so could read it later.
      v3: fix whitespace problem pointed out by Ed Swierk
      v5: fix boot crash
      
      [ Impact: get correct apic id for bsp other than acpi path ]
      Reported-by: NEd Swierk <eswierk@aristanetworks.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <49FC85A9.2070702@kernel.org>
      [ v4: sanity-check in the ACPI case too ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4797f6b0
  4. 11 5月, 2009 3 次提交
    • C
      x86: apic: Fixmap apic address even if apic disabled · cec6be6d
      Cyrill Gorcunov 提交于
      In case if apic were disabled by boot option
      we still need read_apic operation. So fixmap
      a fake apic area if needed.
      
      [ Impact: fix boot crash ]
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Cc: yinghai@kernel.org
      Cc: eswierk@aristanetworks.com
      LKML-Reference: <20090511134140.GH4624@lenovo>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cec6be6d
    • A
      x86: display extended apic registers with print_local_APIC and cpu_debug code · 97a52714
      Andreas Herrmann 提交于
      Both print_local_APIC (used when apic=debug kernel param is set) and
      cpu_debug code missed support for some extended APIC registers that
      I'd like to see.
      
      This adds support to show:
      
       - extended APIC feature register
       - extended APIC control register
       - extended LVT registers
      
      [ Impact: print more debug info ]
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <20090508162350.GO29045@alberich.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      97a52714
    • Y
      x86: read apic ID in the !acpi_lapic case · 4401da61
      Yinghai Lu 提交于
      Ed found that on 32-bit, boot_cpu_physical_apicid is not read right,
      when the mptable is broken.
      
      Interestingly, actually three paths use/set it:
      
       1. acpi: at that time that is already read from reg
       2. mptable: only read from mptable
       3. no madt, and no mptable, that use default apic id 0 for 64-bit, -1 for 32-bit
      
      so we could read the apic id for the 2/3 path. We trust the hardware
      register more than we trust a BIOS data structure (the mptable).
      
      We can also avoid the double set_fixmap() when acpi_lapic
      is used, and also need to move cpu_has_apic earlier and
      call apic_disable().
      
      Also when need to update the apic id, we'd better read and
      set the apic version as well - so that quirks are applied precisely.
      
      v2: make path 3 with 64bit, use -1 as apic id, so could read it later.
      v3: fix whitespace problem pointed out by Ed Swierk
      
      [ Impact: get correct apic id for bsp other than acpi path ]
      Reported-by: NEd Swierk <eswierk@aristanetworks.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <49FC85A9.2070702@kernel.org>
      [ v4: sanity-check in the ACPI case too ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4401da61
  5. 02 5月, 2009 1 次提交
  6. 27 4月, 2009 1 次提交
  7. 22 4月, 2009 1 次提交
    • S
      x86: x2apic, IR: remove reinit_intr_remapped_IO_APIC() · ff166cb5
      Suresh Siddha 提交于
      When interrupt-remapping is enabled, we are relying on
      setup_IO_APIC_irqs() to configure remapped entries in the
      IO-APIC, which comes little bit later after enabling
      interrupt-remapping.
      
      Meanwhile, restoration of old io-apic entries after enabling
      interrupt-remapping will not make the interrupts through
      io-apic functional anyway.
      
      So remove the unnecessary reinit_intr_remapped_IO_APIC() step.
      
      The longer story:
      
      When interrupt-remapping is enabled, IO-APIC entries need to be
      setup in the re-mappable format (pointing to
      interrupt-remapping table entries setup by the OS). This
      remapping configuration is happening in the same place where we
      traditionally configure IO-APIC (i.e., in
      setup_IO_APIC_irqs()).
      
      So when we enable interrupt-remapping successfully, there is no
      need to restore old io-apic RTE entries before we actually do a
      complete configuration shortly in setup_IO_APIC_irqs(). Old
      IO-APIC RTE's may be in traditional format (non re-mappable) or
      in re-mappable format pointing to interrupt-remapping table
      entries setup by BIOS. Restoring both of these will not make
      IO-APIC functional. We have to rely on setup_IO_APIC_irqs() for
      proper configuration by OS.
      
      So I am removing this unnecessary and broken step.
      
      [ Impact: remove unnecessary/broken IO-APIC setup step ]
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: NWeidong Han <weidong.han@intel.com>
      Cc: dwmw2@infradead.org
      LKML-Reference: <20090420200450.552359000@linux-os.sc.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ff166cb5
  8. 21 4月, 2009 2 次提交
  9. 19 4月, 2009 2 次提交
  10. 14 4月, 2009 1 次提交
  11. 13 4月, 2009 2 次提交
    • C
      x86: apic - introduce dummy apic operations · 08306ce6
      Cyrill Gorcunov 提交于
      Impact: refactor, speed up and robustize code
      
      In case if apic was disabled by kernel option
      or by hardware limits we can use dummy operations
      in apic->write to simplify the ack_APIC_irq() code.
      
      At the lame time the patch fixes the missed EOI in
      do_IRQ function (which has place if kernel is compiled
      as X86-32 and interrupt without handler happens where
      apic was not asked to be disabled via kernel option).
      
      Note that native_apic_write_dummy() consists of
      WARN_ON_ONCE to catch any buggy writes on enabled
      APICs. Could be removed after some time of testing.
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <20090412165058.724788431@openvz.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      08306ce6
    • C
      x86: apic - introduce imcr_ helpers · c0eaa453
      Cyrill Gorcunov 提交于
      Impact: cleanup
      
      Distinguish port writting magic into helpers with comments.
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <20090412165058.535921550@openvz.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c0eaa453
  12. 08 4月, 2009 1 次提交
  13. 04 4月, 2009 1 次提交
  14. 18 3月, 2009 2 次提交
  15. 23 2月, 2009 2 次提交
    • I
      x86: refactor x86_quirks support · 8e6dafd6
      Ingo Molnar 提交于
      Impact: cleanup
      
      Make x86_quirks support more transparent. The highlevel
      methods are now named:
      
        extern void x86_quirk_pre_intr_init(void);
        extern void x86_quirk_intr_init(void);
      
        extern void x86_quirk_trap_init(void);
      
        extern void x86_quirk_pre_time_init(void);
        extern void x86_quirk_time_init(void);
      
      This makes it clear that if some platform extension has to
      do something here that it is considered ... weird, and is
      discouraged.
      
      Also remove arch_hooks.h and move it into setup.h (and other
      header files where appropriate).
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8e6dafd6
    • S
      x86: select x2apic ops in early apic probe only if x2apic mode is enabled · ef1f87aa
      Suresh Siddha 提交于
      If BIOS hands over the control to OS in legacy xapic mode, select
      legacy xapic related ops in the early apic probe and shift to x2apic
      ops later in the boot sequence, only after enabling x2apic mode.
      
      If BIOS hands over the control in x2apic mode, select x2apic related
      ops in the early apic probe.
      
      This fixes the early boot panic, where we were selecting x2apic ops,
      while the cpu is still in legacy xapic mode.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ef1f87aa
  16. 18 2月, 2009 3 次提交
  17. 17 2月, 2009 2 次提交
  18. 16 2月, 2009 1 次提交
  19. 15 2月, 2009 1 次提交
  20. 06 2月, 2009 2 次提交
  21. 04 2月, 2009 1 次提交
  22. 31 1月, 2009 3 次提交
  23. 30 1月, 2009 2 次提交
    • Y
      x86: unify PM-Timer messages · 39ba5d43
      Yasuaki Ishimatsu 提交于
      Impact: Cleans up printk formatting
      
      When LOCAL APIC was calibrated, the debug message is displayed as follows.
      
      	CPU0: Intel(R) Xeon(R) CPU            5110  @ 1.60GHz stepping 06
      	Using local APIC timer interrupts.
      	calibrating APIC timer ...
      	... lapic delta = 3773131
      	... PM timer delta = 812434
      	APIC calibration not consistent with PM Timer: 226ms instead of 100ms
      	APIC delta adjusted to PM-Timer: 1662420 (3773131)
      	TSC delta adjusted to PM-Timer: 159592409 (362220564)
      	..... delta 1662420
      	..... mult: 71411249
      	..... calibration result: 265987
      	..... CPU clock speed is 1595.0924 MHz.
      	..... host bus clock speed is 265.0987 MHz.
      
      There are three type of PM-Timer (PM-Timer, PM Timer, and PM timer),
      in this message. This patch unifies those messages to PM-Timer.
      Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      39ba5d43
    • Y
      x86: fix debug message of CPU clock speed · 754ef0cd
      Yasuaki Ishimatsu 提交于
      Impact: Fixes incorrect printk
      
      LOCAL APIC is corrected by PM-Timer, when SMI occurred while LOCAL APIC is calibrated.
      In this case, LOCAL APIC debug message(Boot with apic=debug) is displayed correctly,
      however, CPU clock speed debug message is displayed wrongly .
      
      When SMI occured on my machine, which has 1.6GHz CPU, CPU clock speed is displayed
      3622.0205 MHz as follow.
      
      	CPU0: Intel(R) Xeon(R) CPU            5110  @ 1.60GHz stepping 06
      	Using local APIC timer interrupts.
      	calibrating APIC timer ...
      	... lapic delta = 3773130
      	... PM timer delta = 812434
      	APIC calibration not consistent with PM Timer: 226ms instead of 100ms
      	APIC delta adjusted to PM-Timer: 1662420 (3773130)
      	..... delta 1662420
      	..... mult: 71411249
      	..... calibration result: 265987
      	..... CPU clock speed is 3622.0205 MHz.  =====>  here
      	..... host bus clock speed is 265.0987 MHz.
      
      This patch fixes to displaying CPU clock speed correctly as follow.
      
      	CPU0: Intel(R) Xeon(R) CPU            5110  @ 1.60GHz stepping 06
      	Using local APIC timer interrupts.
      	calibrating APIC timer ...
      	... lapic delta = 3773131
      	... PM timer delta = 812434
      	APIC calibration not consistent with PM Timer: 226ms instead of 100ms
      	APIC delta adjusted to PM-Timer: 1662420 (3773131)
      	TSC delta adjusted to PM-Timer: 159592409 (362220564)
      	..... delta 1662420
      	..... mult: 71411249
      	..... calibration result: 265987
      	..... CPU clock speed is 1595.0924 MHz.
      	..... host bus clock speed is 265.0987 MHz.
      Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      754ef0cd
  24. 29 1月, 2009 3 次提交