[Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5499)

[Juergen Lock]

On Sat, Oct 11, 2008 at 11:41:48PM +0200, Juergen Lock wrote:
> On Wed, Oct 01, 2008 at 12:33:39AM +0200, Juergen Lock wrote:
> > In article <e71790db0809272104p1b3f383epb753fff72bb6f101 at mail.gmail.com> you write:
> > >On Sat, Sep 27, 2008 at 5:47 PM, Juergen Lock <nox at jelal.kn-bremen.de> wrote:
> > >> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
> > >>>[...]
> > >>>  I'll see if I can prepare another update over the weekend and then go
> > >>> thru more of the patches that have accumulated in the port...
> > >>
> > >> OK, here we go :)  First the update: (at r5331 now)
> > >>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
> > >[...]
> > >
> > >I suggest applying the following patch (on top of yours). It includes
> > >options to build additional sound emulators.
> > >
> > >--- Makefile.orig	2008-09-28 00:11:29.000000000 -0300
> > >+++ Makefile	2008-09-28 00:53:03.000000000 -0300
> > >@@ -38,6 +38,10 @@
> > > 		GNUTLS "gnutls dependency (vnc encryption)" On \
> > > 		PCAP "pcap dependency (networking with bpf)" On \
> > > 		CDROM_DMA "IDE CDROM DMA" On \
> > >+		AC97 "Intel 82801AA AC97 sound card" Off \
> > >+		ADLIB "Adlib card with Yamaha YM3812 (OPL2) chip" Off \
> > >+		CS4231A "CS4231A sound card (Windows Sound System)" Off \
> > >+		GUS "Gravis Ultrasound GF1 sound card" Off \
> > > 		ALL_TARGETS "Also build dyngen targets (requires gcc34)" On
> > >
> > > .include <bsd.port.pre.mk>
> > >@@ -76,6 +80,35 @@
> > > CONFIGURE_ARGS+=	--enable-pcap
> > > .endif
> > >
> > >+.if defined(WITH_AC97)
> > >+AUDIO_CARD_LIST=	ac97
> > >+.endif
> > >+
> > >+.if defined(WITH_ADLIB)
> > >+.if defined(AUDIO_CARD_LIST)
> > >+AUDIO_CARD_LIST+=	,
> > >+.endif
> > >+AUDIO_CARD_LIST+=	adlib
> > >+.endif
> > >+
> > >+.if defined(WITH_CS4231A)
> > >+.if defined(AUDIO_CARD_LIST)
> > >+AUDIO_CARD_LIST+=	,
> > >+.endif
> > >+AUDIO_CARD_LIST+=	cs4231a
> > >+.endif
> > >+
> > >+.if defined(WITH_GUS)
> > >+.if defined(AUDIO_CARD_LIST)
> > >+AUDIO_CARD_LIST+=	,
> > >+.endif
> > >+AUDIO_CARD_LIST+=	gus
> > >+.endif
> > >+
> > >+.if defined(AUDIO_CARD_LIST)
> > >+CONFIGURE_ARGS+=	--audio-card-list="${AUDIO_CARD_LIST}"
> > >+.endif
> > >+
> > > .if defined(WITH_SAMBA)
> > > RUN_DEPENDS+=	${LOCALBASE}/sbin/smbd:${PORTSDIR}/net/samba3
> > > .endif
> > >
> > >Signed-off-by: Carlos Santos <unixmania at gmail.com>
> > 
> > Hmm.  I might just add one knob to compile in all of these instead,
> > they are still to be enabled individually at runtime, right?
> 
> Ok, new update at:
> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20081011.patch
> I have added an ADD_AUDIO knob to enable all of the above, and I have
> also added the aio emulation patch that makes qemu still work when aio
> is not loaded (although usually slower.)
> 
New update at:
	http://people.freebsd.org/~nox/qemu/qemu-devel-20081018.patch
I have removed the cpu-exec.c patch as it seems(!) no longer needed,
and I have added a fix for -m >= 1024 on recent FreeBSD/amd64 hosts,
I'll post about that seperately.

>  I have noticed tho that -soundhw ac97 together with -usb -drive if=scsi,...
> and -net nic,model=rtl8139 causes scsi resets and timeouts at least for my
> sidux-2008-03-ourea-pre1-kde-lite-i386-200809142136.iso livecd guest, can
> anyone reproduce this?  A FreeBSD 7.1-BETA-i386-livefs.iso guest with the
> same parameters also hangs at boot with scsi problems...
> 
 I was unable to reproduce this when trying it like that again, it appears
I had passed both -soundhw es1370 _and_ -soundhw ac97 when I saw this. :(
Sorry for any confusion this might have caused...

>  Oh and the other problems I mentioned also still seem to exist.

 Same.

 I'm beginning to suspect tho that the screen update thing I mentioned
is an xorg intel driver problem not a qemu one... (that box has Intel
965GM graphics, and the non-updated parts on the screen seem to depend on
the vertial height of the other window that I last moused over when it
happens, which would be too weird a bug for qemu to cause it, right? :)

 Regards,
	Juergen