The sn console driver was snagged by the use of CONFIG_DEBUG_SHIRQ !
The request_irq() immediate call to the interrupt handler caused
another attempt to lock the port lock - deadlock.
This is a patch to fix that.
Signed-off-by: Patrick Gefre <pfg@sgi.com>
sn_console.c | 52 +++++++++++++++++-----------------------------------
1 file changed, 17 insertions(+), 35 deletions(-)
Index: linux-2.6/drivers/serial/sn_console.c
===================================================================
--- linux-2.6.orig/drivers/serial/sn_console.c 2007-03-07 11:59:57.853775134 -0600
+++ linux-2.6/drivers/serial/sn_console.c 2007-03-07 15:27:37.455224799 -0600
@@ -636,25 +636,6 @@
}
/**
- * sn_sal_connect_interrupt - Request interrupt, handled by sn_sal_interrupt
- * @port: Our sn_cons_port (which contains the uart port)
- *
- * returns the console irq if interrupt is successfully registered, else 0
- *
- */
-static int sn_sal_connect_interrupt(struct sn_cons_port *port)
-{
- if (request_irq(SGI_UART_VECTOR, sn_sal_interrupt,
- IRQF_DISABLED | IRQF_SHARED,
- "SAL console driver", port) >= 0) {
- return SGI_UART_VECTOR;
- }
-
- printk(KERN_INFO "sn_console: console proceeding in polled mode\n");
- return 0;
-}
-
-/**
* sn_sal_timer_poll - this function handles polled console mode
* @data: A pointer to our sn_cons_port (which contains the uart port)
*
@@ -746,30 +727,31 @@
* mode. We were previously in asynch/polling mode (using init_timer).
*
* We attempt to switch to interrupt mode here by calling
- * sn_sal_connect_interrupt. If that works out, we enable receive interrupts.
+ * request_irq. If that works out, we enable receive interrupts.
*/
static void __init sn_sal_switch_to_interrupts(struct sn_cons_port *port)
{
- int irq;
unsigned long flags;
- if (!port)
- return;
-
- DPRINTF("sn_console: switching to interrupt driven console\n");
-
- spin_lock_irqsave(&port->sc_port.lock, flags);
+ if (port) {
+ DPR...
