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 4 次提交
    • J
      x86, apic: Restore irqs on fail paths · 3d58829b
      Jiri Slaby 提交于
      lapic_resume forgets to restore interrupts on fail paths.
      Fix that.
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Acked-by: NCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <1243497289-18591-1-git-send-email-jirislaby@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: H. Peter Anvin <hpa@zytor.com>
      3d58829b
    • N
      x86: Print real IOAPIC version for x86-64 · 58f892e0
      Naga Chumbalkar 提交于
      Fix the fact that the IOAPIC version number in the x86_64 code path always
      gets assigned to 0, instead of the correct value.
      
      Before the patch: (from "dmesg" output):
      
       ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
       IOAPIC[0]: apic_id 8, version 0, address 0xfec00000, GSI 0-23     <---
      
       After the patch:
       ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
       IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23    <---
      
      History:
      
      io_apic_get_version() was compiled out of the x86_64 code path in the commit
      f2c2cca3:
      
      Author: Andi Kleen <ak@suse.de>
      Date:   Tue Sep 26 10:52:37 2006 +0200
      
          [PATCH] Remove APIC version/cpu capability mpparse checking/printing
      
          ACPI went to great trouble to get the APIC version and CPU capabilities
          of different CPUs before passing them to the mpparser. But all
          that data was used was to print it out.  Actually it even faked some data
          based on the boot cpu, not on the actual CPU being booted.
      
          Remove all this code because it's not needed.
      
          Cc: len.brown@intel.com
      
      At the time, the IOAPIC version number was deliberately not printed
      in the x86_64 code path. However, after the x86 and x86_64 files were
      merged, the net result is that the IOAPIC version is printed incorrectly
      in the x86_64 code path.
      
      The patch below provides a fix. I have tested it with acpi, and with
      acpi=off, and did not see any problems.
      Signed-off-by: NNaga Chumbalkar <nagananda.chumbalkar@hp.com>
      Acked-by: NYinghai Lu <yhlu.kernel@gmail.com>
      LKML-Reference: <20090416014230.4885.94926.sendpatchset@localhost.localdomain>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      *************************
      58f892e0
    • I
      Merge branch 'x86/cpufeature' into irq/numa · ee4c24a5
      Ingo Molnar 提交于
      Merge reason: irq/numa didnt build because this commit:
      
        2759c328: x86: don't call read_apic_id if !cpu_has_apic
      
      Had a dependency on x86/cpufeature changes. Pull in that
      (small) branch to fix the dependency.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ee4c24a5
    • I
      Merge branch 'linus' into irq/numa · 3d58f48b
      Ingo Molnar 提交于
      Conflicts:
      	arch/mips/sibyte/bcm1480/irq.c
      	arch/mips/sibyte/sb1250/irq.c
      
      Merge reason: we gathered a few conflicts plus update to latest upstream fixes.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3d58f48b
  3. 01 6月, 2009 10 次提交
  4. 31 5月, 2009 2 次提交
  5. 30 5月, 2009 19 次提交
  6. 29 5月, 2009 4 次提交