WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: stdvga: slow ioreq

IMO, the diagnostic message should only appear, if it indicates
a bug. If the diagnostic message is really pointless it should be removed.
If the diagnostic messages may indicate bugs but have many false positives,
then the if-condition should be fixed.

An obvious bug I am seeing (but is not indicated by this certain diagnostic
message) is a scrolling bug. It appears when I boot a HVM guest that uses a 
graphic mode (e.g. OpenSuSE 10.2). I am connected via VNC to it.
I don't see the line where the cursor is. I have to blindely guess when the
guest expects me to log in. After a (blind) successful login, I have to type
something like 'ls' several times, until I see what I actually typed and the 
output of what I typed.
The latest changeset I tried is 16317 and the bug is reproducable.
The oldest changeset I tried so far is 16281 and this issue was reproducable
there, too. I hope, that helps.

Christoph


On Monday 05 November 2007 17:38:24 Robert Phillips wrote:
> Hi Christoph,
>
> What you are seeing is (I hope) just an annoying diagnostic.  If you reduce
> your guest log level or eliminate the gdprintk() the problem should go
> away.
>
> The diagnostic is warning that the ioreq could not be placed in the
> buffered iopage so it is being sent synchronously to qemu.
> The ioreq could not be placed in the buffered iopage because it couldn't be
> condensed into the (new) format.
> The new format has no room to store 'count' so ioreqs with count != 1 take
> the slow route.
>
> Our experience is that the few ioreqs handled this way are far out numbered
> by the condensable ioreqs
> and since far more condensable ioreqs now fit in the buffered iopage (than
> would fit with the old format)
> the performance improvement is substantial.
>
> If the diagnostic is pointless and annoying, it should be eliminated.
>
> -- Robert Phillips
>
> On 11/5/07, Christoph Egger <Christoph.Egger@xxxxxxx> wrote:
> > Hello Ropert!
> >
> > Since changeset 16285 (xen-staging), I get the following output when I
> > launch
> > a HVM guest and VGABios is running:
> >
> >
> > -------------------------------------------------------------------------
> >-------------- (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1
> > addr:0xa0000 dir:0 ptr:1
> > df:0 count:16
> > (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0020 dir:0
> > ptr:1
> > df:0 count:16
> > (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0040 dir:0
> > ptr:1
> > df:0 count:16
> > (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0060 dir:0
> > ptr:1
> > df:0 count:16
> > (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0080 dir:0
> > ptr:1
> > df:0 count:16
> > (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa00a0 dir:0
> > ptr:1
> > df:0 count:16
> > [...]
> > (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa1fe0 dir:0
> > ptr:1
> > df:0 count:16
> >
> > -------------------------------------------------------------------------
> >-----------------
> >
> > This is not the full output (to keep this mail readable). The address
> > output
> > starts from 0xa0000 and goes to 0xa1fe0 and it always increases by 0x20.
> > (So you can generate the full output yourself :)
> >
> > The output comes from xen/arch/x86/intercept.c, function
> > hvm_buffered_io_send().
> > It is this code snippet:
> >
> >     /* Return 0 for the cases we can't deal with. */
> >     if ( (p->addr > 0xffffful) || p->data_is_ptr || p->df || (p->count !=
> > 1) )
> >     {
> >         gdprintk(XENLOG_DEBUG, "slow ioreq. type:%d size:%"PRIu64"
> > addr:0x%"
> >                  PRIx64" dir:%d ptr:%d df:%d count:%"PRIu64"\n",
> >                  p->type, p->size, p->addr, !!p->dir,
> >                  !!p->data_is_ptr, !!p->df, p->count);
> >         return 0;
> >     }
> >
> > It looks like the problem was there before changeset 16285 but got
> > uncovered
> > with the addition of the debug output.
> >
> > Christoph
> >
> >
> > --
> > AMD Saxony, Dresden, Germany
> > Operating System Research Center
> >
> > Legal Information:
> > AMD Saxony Limited Liability Company & Co. KG
> > Sitz (Geschäftsanschrift):
> >    Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
> > Registergericht Dresden: HRA 4896
> > vertretungsberechtigter Komplementär:
> >    AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
> > Geschäftsführer der AMD Saxony LLC:
> >    Dr. Hans-R. Deppe, Thomas McCoy



-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy



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

<Prev in Thread] Current Thread [Next in Thread>