Problem Description:
If DEBUG_AUTOCONF is defined in drivers/serial/8250.c (which has to be done manually) and a serial console is used the kernel seems to hang on the printk()s generated by DEBUG_AUTOCONF

Steps to reproduce:
0) manually edit drivers/serial/8250.c so that DEBUG_AUTOCONF is defined to generate a printk();
1) launch the kernel with a serial console enabled;
2) notice the kernel hang on the first printk() generated by DEBUG_AUTOCONF.

My analysis:
0) What _seems_ to be going is that the kernel deadlocks on any printk() in autoconfig() and autoconfig_16550a(). I can easily reproduce those deadlocks with this simple patch (which doesn't require DEBUG_AUTOCONF):

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c 
index 303272a..3115c16 100644 
--- a/drivers/serial/8250.c 
+++ b/drivers/serial/8250.c 
@@ -1016,6 +1022,8 @@ static void autoconfig(struct uart_8250_port *up, unsigned int probeflags) 
         */ 
        spin_lock_irqsave(&up->port.lock, flags); 
  
+       printk("This will lock with a serial console\n"); 
+ 
        up->capabilities = 0; 
        up->bugs = 0; 
 

1) Apparently one cannot printk() in autoconfig() between the spin_lock_irqsave() and the spin_unlock_irqrestore() calls.

Possible solutions:
0) I managed to avoid the deadlocks by wrapping the printk()s of DEBUG_AUTOCONF (that I happened to run into) with spin_unlock_irqrestore() and spin_lock_irqsave() calls. Since I hardly understand what is actually causing the kernel to deadlock (or whatever is happening) I cannot state whether this actually is a solid solution.

1) Note that a solution might also be just a comment stating that one shouldn't try to use DEBUG_AUTOCONF over a serial line. However, that would still leave one potential deadlock with this printk() in autoconfig():
                printk(KERN_WARNING
                       "ttyS%d: detected caps %08x should be %08x\n",
                       serial_index(&up->port), up->capabilities,
                       uart_config[up->port.type].flags);