Re: [Qemu-devel] qemu-system-ppc seems slow today.

[lsorense@csclub.uwaterloo.ca (Lennart Sorensen)]

On Mon, Jan 19, 2009 at 02:42:21PM -0500, Lennart Sorensen wrote:
> On Mon, Jan 19, 2009 at 07:39:02PM +0100, Aurelien Jarno wrote:
> > That works perfectly here.
> 
> So far I have tested 4 checkouts.
> 
> 0.9.1git-5653494a49db20ca6b22b32fa07a73b9e2f26169 slow          Sat Jan 17 20:47:10 2009 +0000
> 0.9.1git-63c75dcd669d011f438421980b4379827da4bb1c slow          Fri Jan 16 22:32:33 2009 +0000
> 0.9.1git-6517ca2a760227b7eb1ded729b0e26f0fa61d73c segfault      Fri Jan 16 07:31:51 2009 +0000
> 0.9.1git-75f765317b0bce0ad250f665c24c844d775ea4da normal        Wed Jan 14 21:42:48 2009 +0000
> 0.9.1git-1eff7fbf116790aaacc8f89def68be11149626cc normal        Tue Jan 13 23:12:34 2009 +0000 (no quik boot though)
> 
> So so far I know something changed between
> 75f765317b0bce0ad250f665c24c844d775ea4da and
> 63c75dcd669d011f438421980b4379827da4bb1c
> 
> All I am doing is running qemu-system-ppc -hda debian-lenny.img (which
> has debian lenny installed with the standard debian 2.6.26 kernel).
> 
> I will do more builds until I find when it "broke".

So after many builds, and eventually selectively applying some patches
to fix segfaults and build failures, I tracked the problem down to
commit 7d957bd8cbcbf56f7916d375e65042d767f544b5 in git (commit 6336 in
svn).  I wish there weren't so many checkins that failed to build or
segfaulted at start.  Oh well.  Too many targets to test I guess.

Now I have been using qemu for a while by doing:

'ssh -X fastserver' and running qemu there.  With the new display code
this has made qemu very slow and hardly useable.

Now if I use vnc to connect to qemu, the performance is great.  I
suppose I could use that, but I am still wondering why the new display
code made the X11 over ssh so awful.  Any ideas?

Oh and vnc doesn't work with xvnc4client, giving an error about rect too
big:
 CConn:       connected to host rceng02 port 5901
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 6 (8bpp) rgb222
 CConn:       Using ZRLE encoding
 CConn:       Throughput 20000 kbit/s - changing to hextile
 encoding
 CConn:       Throughput 20000 kbit/s - changing to full colour
 CConn:       Using pixel format depth 24 (32bpp) little-endian
 rgb888
 CConn:       Using hextile encoding
Rect too big: 5x1536 at 600,0 exceeds 800x600
 main:        Rect too big

vinagre on the other hand seems OK.  Odd.

-- 
Len Sorensen