All,
We've seen a case where booting Xen on a certain platform configured with a
serial console takes an unreasonably long time to boot (on the order of hours).
Now, on this particular piece of hardware, it was determined that the serial
firmware actually has a bug. That being said, I'm not sure that preventing boot
in the face of buggy serial hardware is a reasonable course of action.
Bare-metal Linux, for instance, boots fine although characters might be dropped
along the way.
The problem seems to be the check in guest_console_write(), which has a
quench-type check at the top of the loop. I assume the check is to prevent the
guest from completely flooding the serial console, but:
1) It seems like a layering violation; a check here can (and does) prevent the
lower level serial code from doing the right thing.
2) It seems redundant since c/s 17851. That c/s added a very similar check
into __serial_putc(), so I don't think we need it here anymore.
This patch just removes the check entirely. With this patch and c/s 17851 in
place, the problematic hardware boots in a normal amount of time (although it
still might drop characters, but I think this is the best we can do).
Signed-off-by: Chris Lalancette <clalance@xxxxxxxxxx>
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -332,13 +332,6 @@ static long guest_console_write(XEN_GUES
while ( count > 0 )
{
- while ( serial_tx_space(sercon_handle) < (serial_txbufsz / 2) )
- {
- if ( hypercall_preempt_check() )
- break;
- cpu_relax();
- }
-
if ( hypercall_preempt_check() )
return hypercall_create_continuation(
__HYPERVISOR_console_io, "iih",
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home