All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Lalancette <clalance@redhat.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [PATCH]: Remove "buffer half full" check from guest_console_write
Date: Wed, 16 Sep 2009 08:25:08 +0200	[thread overview]
Message-ID: <4AB084C4.7070003@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

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@redhat.com>

[-- Attachment #2: xen-remote-guest-console-serial-check.patch --]
[-- Type: text/x-patch, Size: 566 bytes --]

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",

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

                 reply	other threads:[~2009-09-16  6:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AB084C4.7070003@redhat.com \
    --to=clalance@redhat.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.