On Tue, Jan 15, 2013 at 7:55 AM, Ben Guthro <ben@xxxxxxxxxx> wrote:
I'll continue down the rcu_check_callbacks() path, I guess.
I believe I've found the culprit of the issue, but am unsure of what
the proper solution is.
It looks like after resume, on these newer machines, the ns16550
registers contain all FF's - and so, the timer code was getting stuck
in
__ns16550_poll in the following stack:
__ns16550_poll()
execute_timer()
timer_softirq_action()
__do_softirq()
process_pending_softirqs()
rcu_barrier_action()
rcu_barrier()
enter_state()
The while loop in this function was spinning, calling
serial_rx_interrupt() over, and over again, since the LSR register was
0xFF
A workaround seems to be to check some of the named registers at
resume time, and bail out if they contain 0xFF's:
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index d77042e..b370581 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -342,6 +342,15 @@ static void ns16550_resume(struct serial_port *port)
PCI_COMMAND, uart->cr);
}
+ if ( (((unsigned char)ns_read_reg(uart, LSR)) == 0xff) &&
+ (((unsigned char)ns_read_reg(uart, MCR)) == 0xff) &&
+ (((unsigned char)ns_read_reg(uart, IER)) == 0xff) &&
+ (((unsigned char)ns_read_reg(uart, IIR)) == 0xff) &&
+ (((unsigned char)ns_read_reg(uart, LCR)) == 0xff) ) {
+ printk(KERN_ERR "ns16550 resume has bad register data!\n");
+ return;
+ }
+
ns16550_setup_preirq(port->uart);
ns16550_setup_postirq(port->uart);
}
This, of course means that you don't get any serial data after resume,
which is not ideal.
I'm going to try to figure out if there is any chipset (Panther Point)
specific initialization that should be getting done.
If you (or anyone else) has any other thoughts on this serial
initialization, please let me know.
Ben
