My OpenSuSE 10.2 HVM guest is 64bit.
I just found a workaround:
Close the vnc client and re-connect. Then the vnc client uses
a larger window and I can actually see the cursor line.
This behaviour looks very much to me that the vnc server code
does not notify the client about graphic mode changes.
Christoph
On Tuesday 06 November 2007 17:26:45 Dave Lively wrote:
> Hi Christoph -
> I'm trying to reproduce the behavior you're seeing. Is your guest
> 32- or 64-bit?
>
> Dave
>
> On 11/5/07, Christoph Egger <Christoph.Egger@xxxxxxx> wrote:
> > 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home