This patch set provides a workaround to avoid the following problem.
It's based on Linux 4.2-rc4 mainstream kernel.
I've tested this patch set on x86-64 machine and KVM.
RFC
--------------------------
During interrupt probing phase, irq affinity of candidate IRQs
can be changed immediately and safely?
I'd like to discuss how irq affinity should be set during
interrupt probing phase without paying attention to the kind of
chip->irq_set_affinity.
[patch v2 2/3] tries to set irq affinity and expects that irq affinity
is set immediately if possible.
I've tested this patch with 4.1-rc3 and 4.2-rc4, but the behavior of
this patch was different between both versions and depends on the
kind of chip->irq_set_affinity although I could test only 2 types
of machines.
I don't know whether these differences are problem or not.
It seems other modules don't call irq_do_set_affinity() directly
before irq setup, so my usage of irq affinity may not be good.
v4.1-rc3 with CONFIG_GENERIC_PENDING_IRQ
+ x86-64(IvyBridge): intel_ioapic_set_affinity()
- irq affinity is changed immediately[No pending]
+ KVM(x86-64): native_ioapic_set_affinity()
- irq affinity is changed immediately [No pending]
- assign_irq_vector() fails with EBUSY because the status
is still "move_in_progress"
when other device calls setup_affinity() with the same irq.
v4.2-rc4 with CONFIG_GENERIC_PENDING_IRQ
+ x86-64(IvyBridge): intel_ir_set_affinity()
- irq affinity is changed immediately [No pending]
+ KVM(x86-64): ioapic_set_affinity()
- irq affinity is NOT changed immediately [Pending]
- The following error was shown when other device calls
setup_affinity() with the same irq
because the status is still "move_in_progress".
"Failed to recover vector for irq 6"
Problem
--------------------------
There're cases where autoconfig_irq() fails during boot.
In these cases, the console doesn't work in interrupt mode
and "input overrun" (which makes operation mistakes) can happen
on some systems. This problem can happen with high rate every boot
once it occurs because the boot sequence is always almost same.
I saw the original problem on RHEL6.6.
Conditions of Reproduction
--------------------------
- Need non-PnP console serial
or PnP console without CONFIG_SERIAL_8250_PNP
- Build with CONFIG_SERIAL_8250_DETECT_IRQ.
- Keep interrupt disabled on the CPU which is used to detect
an interrupt during the timeout of autoconfig_irq().
+ Kick printk() on the CPU which detects interrupt
from a console serial port.
Change Log
--------------------------
v1:
http://www.spinics.net/lists/linux-serial/msg17744.html
v2:
- Updated commit log of v1 patch 1/2 --> v2 1/3
- Removed v1 patch 2/2
- Added v2 2/3 patch to set irq affinity
- Added v2 3/3 patch to resolve other cases of this problem
This is based on Peter's idea.
It depends on v2 2/3 to set irq affinity.
Taichi Kageyama (3):
serial: 8250: Fix autoconfig_irq() to avoid race conditions
genirq: Add a function to set irq affinity of candidate IRQs
serial: 8250: Fix autoconfig_irq() to reduce the risk of failure
drivers/tty/serial/8250/8250_core.c | 15 +++++++++++++++
include/linux/interrupt.h | 4 ++++
kernel/irq/autoprobe.c | 31 +++++++++++++++++++++++++++++++
3 files changed, 50 insertions(+)
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
