linux-toradex.git/arch/x86/kernel/irq.c, branch v3.4.94

x86: Eliminate irq_mis_count counted in arch_irq_stat

2013-05-08T02:51:57+00:00

commit f7b0e1055574ce06ab53391263b4e205bf38daf3 upstream.

With the current implementation, kstat_cpu(cpu).irqs_sum is also
increased in case of irq_mis_count increment.

So there is no need to count irq_mis_count in arch_irq_stat,
otherwise irq_mis_count will be counted twice in the sum of
/proc/stat.

Reported-by: Liu Chuansheng 
Signed-off-by: Li Fei 
Acked-by: Liu Chuansheng 
Cc: tomoki.sekiyama.qu@hitachi.com
Cc: joe@perches.com
Link: http://lkml.kernel.org/r/1366980611.32469.7.camel@fli24-HP-Compaq-8100-Elite-CMT-PC
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: Preserve lazy irq disable semantics in fixup_irqs()

2012-03-29T13:28:47+00:00

The default irq_disable() sematics are to mark the interrupt disabled,
but keep it unmasked. If the interrupt is delivered while marked
disabled, the low level interrupt handler masks it and marks it
pending. This is important for detecting wakeup interrupts during
suspend and for edge type interrupts to avoid losing interrupts.

fixup_irqs() moves the interrupts away from an offlined cpu. For
certain interrupt types it needs to mask the interrupt line before
changing the affinity. After affinity has changed the interrupt line
is unmasked again, but only if it is not marked disabled.

This breaks the lazy irq disable semantics and causes problems in
suspend as the interrupt can be lost or wakeup functionality is
broken.

Check irqd_irq_masked() instead of irqd_irq_disabled() because
irqd_irq_masked() is only set, when the core code actually masked the
interrupt line. If it's not set, we unmask the interrupt and let the
lazy irq disable logic deal with an eventually incoming interrupt.

[ tglx: Massaged changelog and added a comment ]

Signed-off-by: liu chuansheng 
Cc: Yanmin Zhang 
Link: http://lkml.kernel.org/r/27240C0AC20F114CBF8149A2696CBE4A05DFB3@SHSMSX101.ccr.corp.intel.com
Signed-off-by: Thomas Gleixner

Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2012-01-06T21:58:21+00:00

* 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86: Skip cpus with apic-ids >= 255 in !x2apic_mode
  x86, x2apic: Allow "nox2apic" to disable x2apic mode setup by BIOS
  x86, x2apic: Fallback to xapic when BIOS doesn't setup interrupt-remapping
  x86, acpi: Skip acpi x2apic entries if the x2apic feature is not present
  x86, apic: Add probe() for apic_flat
  x86: Simplify code by removing a !SMP #ifdefs from 'struct cpuinfo_x86'
  x86: Convert per-cpu counter icr_read_retry_count into a member of irq_stat
  x86: Add per-cpu stat counter for APIC ICR read tries
  pci, x86/io-apic: Allow PCI_IOAPIC to be user configurable on x86
  x86: Fix the !CONFIG_NUMA build of the new CPU ID fixup code support
  x86: Add NumaChip support
  x86: Add x86_init platform override to fix up NUMA core numbering
  x86: Make flat_init_apic_ldr() available

x86: Convert per-cpu counter icr_read_retry_count into a member of irq_stat

2011-12-18T09:46:48+00:00

LAPIC related statistics are grouped inside the per-cpu
structure irq_stat, so there is no need for icr_read_retry_count
to be a standalone per-cpu variable.

This patch moves icr_read_retry_count to where it belongs.

Suggested-y: Thomas Gleixner 
Signed-off-by: Fernando Luis Vazquez Cao 
Cc: Jörn Engel 
Signed-off-by: Ingo Molnar

x86: Add per-cpu stat counter for APIC ICR read tries

2011-12-14T08:32:05+00:00

In the IPI delivery slow path (NMI delivery) we retry the ICR
read to check for delivery completion a limited number of times.

[ The reason for the limited retries is that some of the places
  where it is used (cpu boot, kdump, etc) IPI delivery might not
  succeed (due to a firmware bug or system crash, for example)
  and in such a case it is better to give up and resume
  execution of other code. ]

This patch adds a new entry to /proc/interrupts, RTR, which
tells user space the number of times we retried the ICR read in
the IPI delivery slow path.

This should give some insight into how well the APIC
message delivery hardware is working - if the counts are way
too large then we are hitting a (very-) slow path way too
often.

Signed-off-by: Fernando Luis Vazquez Cao 
Cc: Jörn Engel 
Cc: Suresh Siddha 
Link: http://lkml.kernel.org/n/tip-vzsp20lo2xdzh5f70g0eis2s@git.kernel.org
[ extended the changelog ]
Signed-off-by: Ingo Molnar

x86: Call idle notifier after irq_enter()

2011-12-11T18:31:38+00:00

Interrupts notify the idle exit state before calling irq_enter().
But the notifier code calls rcu_read_lock() and this is not
allowed while rcu is in an extended quiescent state. We need
to wait for irq_enter() -> rcu_idle_exit() to be called before
doing so otherwise this results in a grumpy RCU:

[    0.099991] WARNING: at include/linux/rcupdate.h:194 __atomic_notifier_call_chain+0xd2/0x110()
[    0.099991] Hardware name: AMD690VM-FMH
[    0.099991] Modules linked in:
[    0.099991] Pid: 0, comm: swapper Not tainted 3.0.0-rc6+ #255
[    0.099991] Call Trace:
[    0.099991]    [] warn_slowpath_common+0x7a/0xb0
[    0.099991]  [] warn_slowpath_null+0x15/0x20
[    0.099991]  [] __atomic_notifier_call_chain+0xd2/0x110
[    0.099991]  [] atomic_notifier_call_chain+0x11/0x20
[    0.099991]  [] exit_idle+0x43/0x50
[    0.099991]  [] smp_apic_timer_interrupt+0x39/0xa0
[    0.099991]  [] apic_timer_interrupt+0x13/0x20
[    0.099991]    [] ? default_idle+0xa7/0x350
[    0.099991]  [] ? default_idle+0xa5/0x350
[    0.099991]  [] amd_e400_idle+0x8b/0x110
[    0.099991]  [] ? rcu_enter_nohz+0x8f/0x160
[    0.099991]  [] cpu_idle+0xb0/0x110
[    0.099991]  [] rest_init+0xe5/0x140
[    0.099991]  [] ? rest_init+0x48/0x140
[    0.099991]  [] start_kernel+0x3d1/0x3dc
[    0.099991]  [] x86_64_start_reservations+0x131/0x135
[    0.099991]  [] x86_64_start_kernel+0xed/0xf4

Signed-off-by: Frederic Weisbecker 
Cc: Paul E. McKenney 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Andy Henroid 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett

x86: Fix files explicitly requiring export.h for EXPORT_SYMBOL/THIS_MODULE

2011-10-31T23:30:35+00:00

These files were implicitly getting EXPORT_SYMBOL via device.h
which was including module.h, but that will be fixed up shortly.

By fixing these now, we can avoid seeing things like:

arch/x86/kernel/rtc.c:29: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
arch/x86/kernel/pci-dma.c:20: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
arch/x86/kernel/e820.c:69: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL_GPL’

[ with input from Randy Dunlap  and also
  from Stephen Rothwell  ]

Signed-off-by: Paul Gortmaker

x86: Don't unmask disabled irqs when migrating them

2011-05-19T12:51:08+00:00

It doesn't make sense to unconditionally unmask a disabled irq when
migrating it from offlined cpu to another. If the irq triggers then it
will be disabled in the interrupt handler anyway. So we can just avoid
unmasking it.

[ tglx: Made masking unconditional again and fixed the changelog ]

Signed-off-by: Fengzhe Zhang 
Signed-off-by: Kevin Tian 
Cc: Ian Campbell 
Cc: Jan Beulich 
Cc: "xen-devel@lists.xensource.com" 
Link: http://lkml.kernel.org/r/%3C625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3%40shsmsx502.ccr.corp.intel.com%3E
Signed-off-by: Thomas Gleixner

x86: Skip migrating IRQF_PER_CPU irqs in fixup_irqs()

2011-05-19T12:51:08+00:00

IRQF_PER_CPU means that the irq cannot be moved away from a given
cpu. So it must not be migrated when the cpu goes offline.

[ tglx: massaged changelog ]

Signed-off-by: Fengzhe Zhang 
Signed-off-by: Kevin Tian 
Cc: Ian Campbell 
Cc: Jan Beulich 
Cc: "xen-devel@lists.xensource.com" 
Link: http://lkml.kernel.org/r/%3C625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E2%40shsmsx502.ccr.corp.intel.com%3E
Signed-off-by: Thomas Gleixner

x86: Stop including in two asm header files

2011-03-29T07:37:42+00:00

Stop including  in x86 header files which don't
need it. This will let the compiler complain when this header is
not included by source files when it should, so that
contributors can fix the problem before building on other
architectures starts to fail.

Credits go to Geert for the idea.

Signed-off-by: Jean Delvare 
Cc: James E.J. Bottomley 
Cc: Geert Uytterhoeven 
Cc: Stephen Rothwell 
LKML-Reference: <20110325152014.297890ec@endymion.delvare>
[ this also fixes an upstream build bug in drivers/media/rc/ite-cir.c ]
Signed-off-by: Ingo Molnar