1. 27 4月, 2009 2 次提交
  2. 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
  3. 21 4月, 2009 3 次提交
  4. 19 4月, 2009 5 次提交
  5. 17 4月, 2009 1 次提交
    • C
      x86: UV BAU distribution and payload MMRs · 4ea3c51d
      Cliff Wickman 提交于
      This patch correctly sets BAU memory mapped registers to point
      to the sending activation descriptor table and target payload table.
      
      The "Broadcast Assist Unit" is used for TLB shootdown in UV.
      
      The memory mapped registers that point to sending and receiving
      memory structures contain node numbers.
      
      In one case the __pa() function did not provide the node id of
      memory on blade zero in configurations where that id is nonzero.
      In another case, it was assumed that memory was allocated on
      the local node.  That assumption is not true in a configuration
      in which the node has no memory.
      
      Tested on the UV hardware simulator.
      
      [ Impact: fix possible runtime crash due to incorrect TLB logic ]
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      LKML-Reference: <E1LuR5Z-0007An-B8@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4ea3c51d
  6. 16 4月, 2009 1 次提交
    • Y
      x86: use used_vectors in init_IRQ() · 77857dc0
      Yinghai Lu 提交于
      Impact: fix crash with many devices
      
      I found this crash:
      
      [  552.616646] general protection fault: 0403 [#1] SMP
      [  552.620013] last sysfs file:
      /sys/devices/pci0000:00/0000:00:02.0/usb1/1-1/1-1:1.0/host13/target13:0:0/13:0:0:0/block/sr0/size
      [  552.620013] CPU 0
      [  552.620013] Modules linked in:
      [  552.620013] Pid: 0, comm: swapper Not tainted 2.6.30-rc1-tip-01931-g8fcafd8-dirty #28 Sun Fire X4440
      [  552.620013] RIP: 0010:[<ffffffff8023bada>]  [<ffffffff8023bada>] default_idle+0x7d/0xda
      [  552.620013] RSP: 0018:ffffffff81345e68  EFLAGS: 00010246
      [  552.620013] RAX: 0000000000000000 RBX: ffffffff8133d870 RCX: ffffc20000000000
      [  552.620013] RDX: 00000000001d0620 RSI: ffffffff8023bad8 RDI: ffffffff802a3169
      [  552.620013] RBP: ffffffff81345e98 R08: 0000000000000000 R09: ffffffff812244a0
      [  552.620013] R10: ffffffff81345dc8 R11: 7ebe1b6fa0bcac50 R12: 4ec4ec4ec4ec4ec5
      [  552.620013] R13: ffffffff813a54d0 R14: ffffffff813a7a40 R15: 0000000000000000
      [  552.620013] FS:  00000000006d1880(0000) GS:ffffc20000000000(0000) knlGS:0000000000000000
      [  552.620013] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      [  552.620013] CR2: 00007fec9d936a50 CR3: 000000007d1a9000 CR4: 00000000000006e0
      [  552.620013] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  552.620013] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  552.620013] Process swapper (pid: 0, threadinfo ffffffff81344000,task ffffffff812244a0)
      [  552.620013] Stack:
      [  552.620013]  0000000000000000 ffffc20000000000 00000000001d0620 7ebe1b6fa0bcac50
      [  552.620013]  ffffffff8133d870 4ec4ec4ec4ec4ec5 ffffffff81345ec8 ffffffff8023bd84
      [  552.620013]  4ec4ec4ec4ec4ec5 ffffffff813a54d0 7ebe1b6fa0bcac50 ffffffff8133d870
      [  552.620013] Call Trace:
      [  552.620013]  [<ffffffff8023bd84>] c1e_idle+0x109/0x124
      [  552.620013]  [<ffffffff8023314b>] cpu_idle+0xb8/0x101
      [  552.620013]  [<ffffffff80c16d6a>] rest_init+0x7e/0x94
      [  552.620013]  [<ffffffff81357efc>] start_kernel+0x3dc/0x3fd
      [  552.620013]  [<ffffffff813572a9>] x86_64_start_reservations+0xb9/0xd4
      [  552.620013]  [<ffffffff813573b2>] x86_64_start_kernel+0xee/0x109
      [  552.620013] Code: 48 8b 04 25 f8 b4 00 00 83 a0 3c e0 ff ff fb 0f ae f0 65 48 8b 04 25 f8 b4 00 00 f6 80 38 e0 ff ff 08 75 09 e8 71 76 06 00 fb f4 <eb> 06 e8 68 76 06 00 fb 65 48 8b 04 25 f8 b4 00 00 83 88 3c e0
      [  552.620013] RIP  [<ffffffff8023bada>] default_idle+0x7d/0xda
      [  552.620013]  RSP <ffffffff81345e68>
      [  552.828646] ---[ end trace 4cbfc5c01382af7f ]---
      
      Joerg Roedel said
      	"The 0403 error code means that there was an external interrupt with vector
      	0x80. Yinghai, my theory is that the kernel on this machine has no 32bit
      	emulation compiled in, right? In this case the selector points to a zero entry
      	which may cause the #gpf right after the hlt.
      	But I have no idea where the external int 0x80 comes from"
      
      it turns out that we could use 0x80 for external device on 64-bit
      when 32-bit emulation is disabled.
      
      But we forgot to set the gate for it.
      
      try to set gate for it by checking used_vectors.
      
      Also move apic_intr_init() early to avoid setting
      that gate two times.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      LKML-Reference: <49E62DFD.6010904@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      77857dc0
  7. 15 4月, 2009 3 次提交
    • L
      acpi-cpufreq: fix 'smp_call_function_many()' confusion · ea34f43a
      Linus Torvalds 提交于
      It turns out that 'smp_call_function_many()' doesn't work at all like
      'smp_call_function_single()', and my change to Andrew's patch to use it
      rather than a loop over all CPU's acpi-cpufreq doesn't work.
      
      My bad.
      
      'smp_call_function_many()' has two "features" (aka "documented bugs"):
      
       (a) it needs to be called with preemption disabled, because it uses
           smp_processor_id() without guarding the CPU lookup with 'get_cpu()'
           and 'put_cpu()' like the 'single' variant does.
      
       (b) even if the current CPU is part of the CPU mask, it won't do the
           call on that CPU.
      
      Still, we're better off trying to use 'smp_call_function_many()' than
      looping over CPU's, since it at least in theory allows us to use a
      broadcast IPI and do it all in parallel.  So let's just work around the
      silly semantic bugs in that function.
      Reported-and-tested-by: NAli Gholami Rudi <ali@rudi.ir>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andrew Morton <akpm@linux-foundation.org>,
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ea34f43a
    • H
      x86 microcode: revert some work_on_cpu · 6f66cbc6
      Hugh Dickins 提交于
      Revert part of af5c820a ("x86: cpumask:
      use work_on_cpu in arch/x86/kernel/microcode_core.c")
      
      That change is causing only one Intel CPU's microcode to be updated e.g.
      microcode: CPU3 updated from revision 0x9 to 0x17, date = 2005-04-22
      where before it announced that also for CPU0 and CPU1 and CPU2.
      
      We cannot use work_on_cpu() in the CONFIG_MICROCODE_OLD_INTERFACE code,
      because Intel's request_microcode_user() involves a copy_from_user() from
      /sbin/microcode_ctl, which therefore needs to be on that CPU at the time.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6f66cbc6
    • C
      x86: UV: BAU partition-relative distribution map · 94ca8e48
      Cliff Wickman 提交于
      This patch enables each partition's BAU distribution bit map
      to be partition-relative.
      
      The distribution bitmap had been constructed assuming 0 as the base
      node number.  That construct would not have allowed a total system of
      greater than 256 nodes.
      It also corrects an error that occurred when the first blade's nasid
      was not zero.  That nasid was stored as the base node.
      The base node number gets added by hardware to the node numbers implied
      in the distribution bitmap, resulting in invalid target nasids.
      
      Tested on the UV hardware simulator.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      LKML-Reference: <E1Ltl0C-0004Ob-37@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      94ca8e48
  8. 14 4月, 2009 3 次提交
  9. 13 4月, 2009 4 次提交
  10. 12 4月, 2009 2 次提交
  11. 10 4月, 2009 15 次提交