[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |