Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1194935 > unrolled thread

[RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0  for console Taichi Kageyama <t-kageyama@cp.jp.nec.com> - 2015-07-29 10:30 +0200
    [RFC PATCH v2 3/3] serial: 8250: Fix autoconfig_irq() to reduce the  risk of failure Taichi Kageyama <t-kageyama@cp.jp.nec.com> - 2015-07-29 10:30 +0200
    [RFC PATCH v2 2/3] genirq: Add a function to set irq affinity of  candidate IRQs Taichi Kageyama <t-kageyama@cp.jp.nec.com> - 2015-07-29 10:30 +0200
    Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid  irq=0 for console Peter Hurley <peter@hurleysoftware.com> - 2015-07-29 15:20 +0200
      Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid  irq=0 for console Thomas Gleixner <tglx@linutronix.de> - 2015-07-29 15:40 +0200
        Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid  irq=0 for console Taichi Kageyama <t-kageyama@cp.jp.nec.com> - 2015-07-30 03:50 +0200
          Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid  irq=0 for console Thomas Gleixner <tglx@linutronix.de> - 2015-07-30 12:20 +0200
            Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid  irq=0 for console Thomas Gleixner <tglx@linutronix.de> - 2015-08-02 12:00 +0200

#1194935 — [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1194937 — [RFC PATCH v2 3/3] serial: 8250: Fix autoconfig_irq() to reduce the risk of failure

autoconfig_irq() expects a CPU detects an interrupt from a serial
port, but it doesn't work when the CPU has interrupts disabled
during the waiting time.
New one tries to specify own CPU to probe the interrupt
and reduce the risk of the failure as far as possible.

Signed-off-by: Taichi Kageyama <t-kageyama@cp.jp.nec.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Suggested-by: Peter Hurley <peter@hurleysoftware.com>
---
 drivers/tty/serial/8250/8250_core.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git v4.2-rc4.org/drivers/tty/serial/8250/8250_core.c v4.2-rc4.work/drivers/tty/serial/8250/8250_core.c
index ed1e23e..85e8cdf 100644
--- v4.2-rc4.org/drivers/tty/serial/8250/8250_core.c
+++ v4.2-rc4.work/drivers/tty/serial/8250/8250_core.c
@@ -1295,6 +1295,7 @@ static void autoconfig_irq(struct uart_8250_port *up)
 	unsigned int ICP = 0;
 	unsigned long irqs;
 	int irq;
+	cpumask_t this_cpu;
 
 	if (port->flags & UPF_FOURPORT) {
 		ICP = (port->iobase & 0xfe0) | 0x1f;
@@ -1313,6 +1314,13 @@ static void autoconfig_irq(struct uart_8250_port *up)
 	serial_out(up, UART_MCR, UART_MCR_OUT1 | UART_MCR_OUT2);
 
 	irqs = probe_irq_on();
+
+	/* Try to detect irq on the current CPU */
+	cpumask_clear(&this_cpu);
+	preempt_disable();
+	cpumask_set_cpu(smp_processor_id(), &this_cpu);
+	probe_irq_set_affinity(irqs, &this_cpu);
+
 	serial_out(up, UART_MCR, 0);
 	udelay(10);
 	if (port->flags & UPF_FOURPORT) {
@@ -1330,6 +1338,7 @@ static void autoconfig_irq(struct uart_8250_port *up)
 	serial_out(up, UART_TX, 0xFF);
 	udelay(20);
 	irq = probe_irq_off(irqs);
+	preempt_enable();
 
 	serial_out(up, UART_MCR, save_mcr);
 	serial_out(up, UART_IER, save_ier);
-- 
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1194941 — [RFC PATCH v2 2/3] genirq: Add a function to set irq affinity of candidate IRQs

This new function can specify which CPU is used for interrupt probing.

An interrupt probing code expects a CPU detects an interrupt from the
target device, but it doesn't work when the CPU has interrupts disabled
during the waiting time.
The probing code can use this function to specify which CPU detects the
interrupt and reduce the risk of the failure as far as possible.

Signed-off-by: Taichi Kageyama <t-kageyama@cp.jp.nec.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
---
 include/linux/interrupt.h |  4 ++++
 kernel/irq/autoprobe.c    | 31 +++++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+)

diff --git v4.2-rc4.org/include/linux/interrupt.h v4.2-rc4.work/include/linux/interrupt.h
index be7e75c..4f08f6d 100644
--- v4.2-rc4.org/include/linux/interrupt.h
+++ v4.2-rc4.work/include/linux/interrupt.h
@@ -647,10 +647,14 @@ static inline unsigned int probe_irq_mask(unsigned long val)
 {
 	return 0;
 }
+static inline void probe_irq_set_affinity(unsigned long val, cpumask_t *mask)
+{
+}
 #else
 extern unsigned long probe_irq_on(void);	/* returns 0 on failure */
 extern int probe_irq_off(unsigned long);	/* returns 0 or negative on failure */
 extern unsigned int probe_irq_mask(unsigned long);	/* returns mask of ISA interrupts */
+extern void probe_irq_set_affinity(unsigned long, cpumask_t *);
 #endif
 
 #ifdef CONFIG_PROC_FS
diff --git v4.2-rc4.org/kernel/irq/autoprobe.c v4.2-rc4.work/kernel/irq/autoprobe.c
index 0119b9d..24e7647 100644
--- v4.2-rc4.org/kernel/irq/autoprobe.c
+++ v4.2-rc4.work/kernel/irq/autoprobe.c
@@ -183,3 +183,34 @@ int probe_irq_off(unsigned long val)
 }
 EXPORT_SYMBOL(probe_irq_off);
 
+/**
+ *	probe_irq_set_affinity	- change smp_affinity during autodetect
+ *	@val: mask of potential interrupts (unused)
+ *
+ *	Sets smp_affinity of candidate irq lines if possible.
+ *
+ *	An interrupt probing code expects a CPU detects an interrupt
+ *	from the target device, but it doesn't work when the CPU has
+ *	interrupts disabled during the waiting time.
+ *	The code can use this function to specify which CPU detects
+ *	the interrupt and reduce the risk of the failure.
+ */
+void probe_irq_set_affinity(unsigned long val, cpumask_t *mask)
+{
+	int i;
+	struct irq_desc *desc;
+
+	for_each_irq_desc(i, desc) {
+		raw_spin_lock_irq(&desc->lock);
+
+		if (desc->istate & IRQS_AUTODETECT) {
+			struct irq_data *data = &desc->irq_data;
+
+			if (data->chip && data->chip->irq_set_affinity)
+				irq_do_set_affinity(data, mask, false);
+		}
+		raw_spin_unlock_irq(&desc->lock);
+	}
+}
+EXPORT_SYMBOL(probe_irq_set_affinity);
+
-- 
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1195169 — Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console

On 07/29/2015 07:53 AM, Thomas Gleixner wrote:
> On Wed, 29 Jul 2015, Peter Hurley wrote:
>> On 07/29/2015 06:32 AM, Thomas Gleixner wrote:
>>> On Wed, 29 Jul 2015, Taichi Kageyama wrote:
>>>> - 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.
>>>
>>> This is wrong to begin with. How is that supposed to work on an UP
>>> machine? Not at all.
>>>
>>> So no, fix the code which has interrupts disabled accross autoprobing
>>> and do not try to apply bandaids somewhere else.
>>
>> Like printk() from some unrelated driver?
> 
> If that's the cause for the wreckage then yes, we need a way to tell
> the printk code not to call into the driver until that initialization
> step is done. It's that simple.

Like this?

--- >% --
Subject: [PATCH] genirq: Disable printk() during irq probe

printk() disables interrupts for extended periods of time while
outputting to console drivers. This breaks irq probing since the
triggered irq may not be serviced (in time) if scheduled on the
printk() cpu.

Claim the console_lock() which effectively disables console output.

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
---
 kernel/irq/autoprobe.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/kernel/irq/autoprobe.c b/kernel/irq/autoprobe.c
index 0119b9d..47535d2 100644
--- a/kernel/irq/autoprobe.c
+++ b/kernel/irq/autoprobe.c
@@ -39,6 +39,13 @@ unsigned long probe_irq_on(void)
 	 */
 	async_synchronize_full();
 	mutex_lock(&probing_active);
+
+	/*
+	 * printk() breaks irq probing - disable printk output until probe
+	 * completes
+	 */
+	console_lock();
+
 	/*
 	 * something may have generated an irq long ago and we want to
 	 * flush such a longstanding irq before considering it as spurious.
@@ -132,6 +139,7 @@ unsigned int probe_irq_mask(unsigned long val)
 		}
 		raw_spin_unlock_irq(&desc->lock);
 	}
+	console_unlock();
 	mutex_unlock(&probing_active);
 
 	return mask & val;
@@ -174,6 +182,7 @@ int probe_irq_off(unsigned long val)
 		}
 		raw_spin_unlock_irq(&desc->lock);
 	}
+	console_unlock();
 	mutex_unlock(&probing_active);
 
 	if (nr_of_irqs > 1)
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1195189 — Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console

On Wed, 29 Jul 2015, Peter Hurley wrote:
> On 07/29/2015 07:53 AM, Thomas Gleixner wrote:
> > On Wed, 29 Jul 2015, Peter Hurley wrote:
> >> On 07/29/2015 06:32 AM, Thomas Gleixner wrote:
> >>> On Wed, 29 Jul 2015, Taichi Kageyama wrote:
> >>>> - 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.
> >>>
> >>> This is wrong to begin with. How is that supposed to work on an UP
> >>> machine? Not at all.
> >>>
> >>> So no, fix the code which has interrupts disabled accross autoprobing
> >>> and do not try to apply bandaids somewhere else.
> >>
> >> Like printk() from some unrelated driver?
> > 
> > If that's the cause for the wreckage then yes, we need a way to tell
> > the printk code not to call into the driver until that initialization
> > step is done. It's that simple.
> 
> Like this?

Looks about right.
 
> --- >% --
> Subject: [PATCH] genirq: Disable printk() during irq probe
> 
> printk() disables interrupts for extended periods of time while
> outputting to console drivers. This breaks irq probing since the
> triggered irq may not be serviced (in time) if scheduled on the
> printk() cpu.
> 
> Claim the console_lock() which effectively disables console output.
> 
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> ---
>  kernel/irq/autoprobe.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/kernel/irq/autoprobe.c b/kernel/irq/autoprobe.c
> index 0119b9d..47535d2 100644
> --- a/kernel/irq/autoprobe.c
> +++ b/kernel/irq/autoprobe.c
> @@ -39,6 +39,13 @@ unsigned long probe_irq_on(void)
>  	 */
>  	async_synchronize_full();
>  	mutex_lock(&probing_active);
> +
> +	/*
> +	 * printk() breaks irq probing - disable printk output until probe
> +	 * completes
> +	 */
> +	console_lock();
> +
>  	/*
>  	 * something may have generated an irq long ago and we want to
>  	 * flush such a longstanding irq before considering it as spurious.
> @@ -132,6 +139,7 @@ unsigned int probe_irq_mask(unsigned long val)
>  		}
>  		raw_spin_unlock_irq(&desc->lock);
>  	}
> +	console_unlock();
>  	mutex_unlock(&probing_active);
>  
>  	return mask & val;
> @@ -174,6 +182,7 @@ int probe_irq_off(unsigned long val)
>  		}
>  		raw_spin_unlock_irq(&desc->lock);
>  	}
> +	console_unlock();
>  	mutex_unlock(&probing_active);
>  
>  	if (nr_of_irqs > 1)
> -- 
> 2.5.0
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1195680 — Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console

On 2015/07/29 22:35, Thomas Gleixner wrote:
> On Wed, 29 Jul 2015, Peter Hurley wrote:
>> On 07/29/2015 07:53 AM, Thomas Gleixner wrote:
>>> On Wed, 29 Jul 2015, Peter Hurley wrote:
>>>> On 07/29/2015 06:32 AM, Thomas Gleixner wrote:
>>>>> On Wed, 29 Jul 2015, Taichi Kageyama wrote:
>>>>>> - 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.
>>>>>
>>>>> This is wrong to begin with. How is that supposed to work on an UP
>>>>> machine? Not at all.
>>>>>
>>>>> So no, fix the code which has interrupts disabled accross autoprobing
>>>>> and do not try to apply bandaids somewhere else.
>>>>
>>>> Like printk() from some unrelated driver?
>>>
>>> If that's the cause for the wreckage then yes, we need a way to tell
>>> the printk code not to call into the driver until that initialization
>>> step is done. It's that simple.
>>
>> Like this?
> 
> Looks about right.


Thomas,
Thank you for your comments.
The status of interrupt disabled should be short,
but it cannot be controlled from autorpobing side.
That's why I was thinking fixing autoprobing itself was better.

However, I remember Peter also mentioned about your idea first.
OK, I change my mind to fix the real problem simply.
I actually have seen the problem caused only by "printk()" on RHEL.


Peter,
I know your code is sample (console.h is required), 
but it is conflict with [patch v2 1/3].
I think serial8250_console_write should not touch ctrl reg during autoconfig_irq. 
To resolve the real problem, I think keeping only [patch v2 1/3] is best(opt1).
What do you think?

opt1. keep [patch v2 1/3]
    + Don't touch other legacy drivers using autoprobe.
       Each driver can use console_lock to fix this problem if it happens.

opt2. fix probe_irq_on/mask/off for all legacy devices which use them
    + Discard [patch v2 1/3]
    + Fix autoconfig_irq and probe_irq_*
    + Test for all these drivers is required.
      --> Probably, it works but I cannot test them.


Thanks,
Taichi



>  
>> --- >% --
>> Subject: [PATCH] genirq: Disable printk() during irq probe
>>
>> printk() disables interrupts for extended periods of time while
>> outputting to console drivers. This breaks irq probing since the
>> triggered irq may not be serviced (in time) if scheduled on the
>> printk() cpu.
>>
>> Claim the console_lock() which effectively disables console output.
>>
>> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
>> ---
>>  kernel/irq/autoprobe.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/kernel/irq/autoprobe.c b/kernel/irq/autoprobe.c
>> index 0119b9d..47535d2 100644
>> --- a/kernel/irq/autoprobe.c
>> +++ b/kernel/irq/autoprobe.c
>> @@ -39,6 +39,13 @@ unsigned long probe_irq_on(void)
>>  	 */
>>  	async_synchronize_full();
>>  	mutex_lock(&probing_active);
>> +
>> +	/*
>> +	 * printk() breaks irq probing - disable printk output until probe
>> +	 * completes
>> +	 */
>> +	console_lock();
>> +
>>  	/*
>>  	 * something may have generated an irq long ago and we want to
>>  	 * flush such a longstanding irq before considering it as spurious.
>> @@ -132,6 +139,7 @@ unsigned int probe_irq_mask(unsigned long val)
>>  		}
>>  		raw_spin_unlock_irq(&desc->lock);
>>  	}
>> +	console_unlock();
>>  	mutex_unlock(&probing_active);
>>  
>>  	return mask & val;
>> @@ -174,6 +182,7 @@ int probe_irq_off(unsigned long val)
>>  		}
>>  		raw_spin_unlock_irq(&desc->lock);
>>  	}
>> +	console_unlock();
>>  	mutex_unlock(&probing_active);
>>  
>>  	if (nr_of_irqs > 1)
>> -- 
>> 2.5.0
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1195892 — Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console

On Thu, 30 Jul 2015, Taichi Kageyama wrote:
> On 2015/07/29 22:35, Thomas Gleixner wrote:
> I know your code is sample (console.h is required), 
> but it is conflict with [patch v2 1/3].
> I think serial8250_console_write should not touch ctrl reg during autoconfig_irq. 
> To resolve the real problem, I think keeping only [patch v2 1/3] is best(opt1).
> What do you think?
> 
> opt1. keep [patch v2 1/3]
>     + Don't touch other legacy drivers using autoprobe.
>        Each driver can use console_lock to fix this problem if it happens.

No, we already know that autoprobing and console access can cause
this, so we fix it at the core code and be done with it.
 
Can you please test Peters patch and confirm that is solves it.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1198322 — Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console

On Fri, 31 Jul 2015, Taichi Kageyama wrote:
> On 2015/07/31 8:43, Peter Hurley wrote:
> >> If you look at the actual autoprobe users aside of 8250. That's really
> >> all ancient ISA hardware and hardly interesting. So all we really care
> >> about are the 8250 serial ports.
> 
> In this case, I think [patch v2 1/3] is enough.
> console_lock is required in autoconfig_irq() to resolve other race conditions
> before calling probe_irq_on().

Fine with me.
 
> >> So why are you interested in that serial irq autoprobe crap at all?
> > 
> Because RHEL6 uses CONFIG_SERIAL_8250_DETECT_IRQ=y unfortunately.

Doh!
 
> I already got the following console solutions after discussion with Peter.
>  - Force set irq before any APs and getty open /dev/console. 
>    Users have to know valid irq#.
>  - Fix FW to define PNP
>  - CONFIG_SERIAL_8250_DETECT_IRQ=n

Ack!

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web