qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, sc


From: Juergen Lock
Subject: Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5499)
Date: Sat, 18 Oct 2008 22:46:48 +0200
User-agent: Mutt/1.5.17 (2007-11-01)

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 <address@hidden> you write:
> > >On Sat, Sep 27, 2008 at 5:47 PM, Juergen Lock <address@hidden> 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 <address@hidden>
> > 
> > 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]