* [Qemu-devel] Audio @ 2009-09-11 23:34 malc 2009-09-13 11:30 ` [Qemu-devel] Audio Jan Kiszka 0 siblings, 1 reply; 23+ messages in thread From: malc @ 2009-09-11 23:34 UTC (permalink / raw) To: qemu-devel The code was just commited that enables "polling" audio mode (oss and alsa), it's also unconditionally enabled now to obtain some testing coverage, so please give it a whirl, feedback is welcome. -- mailto:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-11 23:34 [Qemu-devel] Audio malc @ 2009-09-13 11:30 ` Jan Kiszka 2009-09-13 18:52 ` malc 0 siblings, 1 reply; 23+ messages in thread From: Jan Kiszka @ 2009-09-13 11:30 UTC (permalink / raw) To: malc; +Cc: qemu-devel [-- Attachment #1: Type: text/plain, Size: 1023 bytes --] malc wrote: > The code was just commited that enables "polling" audio mode (oss and > alsa), it's also unconditionally enabled now to obtain some testing > coverage, so please give it a whirl, feedback is welcome. CPU load goes to 100% when starting my Musicpal image. Applying the fix below and disabling polling again cures this effect here. Jan ---------> audio: Fix typo that broke QEMU_AUDIO_ADC_TRY_POLL From: Jan Kiszka <jan.kiszka@web.de> Signed-off-by: Jan Kiszka <jan.kiszka@web.de> --- audio/audio.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/audio/audio.c b/audio/audio.c index e223cf3..d8e5496 100644 --- a/audio/audio.c +++ b/audio/audio.c @@ -1607,7 +1607,7 @@ static struct audio_option audio_options[] = { { .name = "ADC_TRY_POLL", .tag = AUD_OPT_BOOL, - .valp = &conf.try_poll_out, + .valp = &conf.try_poll_in, .descr = "Attempt using poll mode for ADC" }, /* Misc */ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-13 11:30 ` [Qemu-devel] Audio Jan Kiszka @ 2009-09-13 18:52 ` malc 2009-09-13 19:57 ` Jan Kiszka 2009-09-15 11:28 ` Avi Kivity 0 siblings, 2 replies; 23+ messages in thread From: malc @ 2009-09-13 18:52 UTC (permalink / raw) To: qemu-devel On Sun, 13 Sep 2009, Jan Kiszka wrote: > malc wrote: > > The code was just commited that enables "polling" audio mode (oss and > > alsa), it's also unconditionally enabled now to obtain some testing > > coverage, so please give it a whirl, feedback is welcome. > > CPU load goes to 100% when starting my Musicpal image. Applying the fix > below and disabling polling again cures this effect here. Few things: Thanks for the patch, but i was at a loss how to properly apply it with git and retain all the relevant information (Subject/Authorhsip etc), so for the time being it was applied manually. In the past your mail server was bouncing my replies to threads where you paticipated, and since this new CC-ing madness is in place i'm not sure whether the list reply was delivered to you either, hence i emptied CC header and replying to the list alone. The Musicpal image i have here is getting stuck somewhere along the way to the point of monitor not being responsive, so i can not test anything myself. FWIW the command line is this: [...]/arm-softmmu/qemu-system-arm \ -M musicpal \ -pflash flash.image \ -kernel u-boot.bin \ -monitor stdio \ -m 128 \ -redir tcp:8080::80 -redir tcp:2323::23 Is disabling of both DAC/ADC poll mode needed in your case or? Does following help? diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c index 28c245d..9cc1372 100644 --- a/audio/alsaaudio.c +++ b/audio/alsaaudio.c @@ -37,6 +37,7 @@ struct pollhlp { snd_pcm_t *handle; struct pollfd *pfds; int count; + int mask; }; typedef struct ALSAVoiceOut { @@ -178,7 +179,7 @@ static void alsa_poll_handler (void *opaque) return; } - if (!(revents & POLLOUT)) { + if (!(revents & hlp->mask)) { if (conf.verbose) { dolog ("revents = %d\n", revents); } @@ -208,7 +209,7 @@ static void alsa_poll_handler (void *opaque) } } -static int alsa_poll_helper (snd_pcm_t *handle, struct pollhlp *hlp) +static int alsa_poll_helper (snd_pcm_t *handle, struct pollhlp *hlp, int mask) { int i, count, err; struct pollfd *pfds; @@ -265,6 +266,7 @@ static int alsa_poll_helper (snd_pcm_t *handle, struct pollhlp *hlp) hlp->pfds = pfds; hlp->count = count; hlp->handle = handle; + hlp->mask = mask; return 0; } @@ -272,14 +274,14 @@ static int alsa_poll_out (HWVoiceOut *hw) { ALSAVoiceOut *alsa = (ALSAVoiceOut *) hw; - return alsa_poll_helper (alsa->handle, &alsa->pollhlp); + return alsa_poll_helper (alsa->handle, &alsa->pollhlp, POLLOUT); } static int alsa_poll_in (HWVoiceIn *hw) { ALSAVoiceIn *alsa = (ALSAVoiceIn *) hw; - return alsa_poll_helper (alsa->handle, &alsa->pollhlp); + return alsa_poll_helper (alsa->handle, &alsa->pollhlp, POLLIN); } static int alsa_write (SWVoiceOut *sw, void *buf, int len) [..snip..] -- mailto:av1474@comtv.ru ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-13 18:52 ` malc @ 2009-09-13 19:57 ` Jan Kiszka 2009-09-13 20:07 ` Jan Kiszka 2009-09-13 23:31 ` malc 2009-09-15 11:28 ` Avi Kivity 1 sibling, 2 replies; 23+ messages in thread From: Jan Kiszka @ 2009-09-13 19:57 UTC (permalink / raw) To: malc; +Cc: qemu-devel [-- Attachment #1: Type: text/plain, Size: 3650 bytes --] malc wrote: > On Sun, 13 Sep 2009, Jan Kiszka wrote: > >> malc wrote: >>> The code was just commited that enables "polling" audio mode (oss and >>> alsa), it's also unconditionally enabled now to obtain some testing >>> coverage, so please give it a whirl, feedback is welcome. >> CPU load goes to 100% when starting my Musicpal image. Applying the fix >> below and disabling polling again cures this effect here. > > Few things: > > Thanks for the patch, but i was at a loss how to properly apply it > with git and retain all the relevant information (Subject/Authorhsip > etc), so for the time being it was applied manually. Sorry, the patch was so trivial that I became sloppy. > > In the past your mail server was bouncing my replies to threads where > you paticipated, and since this new CC-ing madness is in place i'm not > sure whether the list reply was delivered to you either, hence i > emptied CC header and replying to the list alone. Unless the bounce said "mailbox full": Just forward me a recent bounce message privately (replace web.de with siemens.com). Typically I get wrong black-listings resolved with web.de within a day or less. > > The Musicpal image i have here is getting stuck somewhere along the > way to the point of monitor not being responsive, so i can not test > anything myself. FWIW the command line is this: > > [...]/arm-softmmu/qemu-system-arm \ > -M musicpal \ > -pflash flash.image \ > -kernel u-boot.bin \ > -monitor stdio \ > -m 128 \ > -redir tcp:8080::80 -redir tcp:2323::23 Hmm, this setup works for me (current master). Maybe you can catch what strace reports or which backtrace gdb generates. Does disabling polling or reverting before your changes make it boot again? > > Is disabling of both DAC/ADC poll mode needed in your case or? Yes. > > Does following help? > > diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c > index 28c245d..9cc1372 100644 > --- a/audio/alsaaudio.c > +++ b/audio/alsaaudio.c > @@ -37,6 +37,7 @@ struct pollhlp { > snd_pcm_t *handle; > struct pollfd *pfds; > int count; > + int mask; > }; > > typedef struct ALSAVoiceOut { > @@ -178,7 +179,7 @@ static void alsa_poll_handler (void *opaque) > return; > } > > - if (!(revents & POLLOUT)) { > + if (!(revents & hlp->mask)) { > if (conf.verbose) { > dolog ("revents = %d\n", revents); > } > @@ -208,7 +209,7 @@ static void alsa_poll_handler (void *opaque) > } > } > > -static int alsa_poll_helper (snd_pcm_t *handle, struct pollhlp *hlp) > +static int alsa_poll_helper (snd_pcm_t *handle, struct pollhlp *hlp, int mask) > { > int i, count, err; > struct pollfd *pfds; > @@ -265,6 +266,7 @@ static int alsa_poll_helper (snd_pcm_t *handle, struct pollhlp *hlp) > hlp->pfds = pfds; > hlp->count = count; > hlp->handle = handle; > + hlp->mask = mask; > return 0; > } > > @@ -272,14 +274,14 @@ static int alsa_poll_out (HWVoiceOut *hw) > { > ALSAVoiceOut *alsa = (ALSAVoiceOut *) hw; > > - return alsa_poll_helper (alsa->handle, &alsa->pollhlp); > + return alsa_poll_helper (alsa->handle, &alsa->pollhlp, POLLOUT); > } > > static int alsa_poll_in (HWVoiceIn *hw) > { > ALSAVoiceIn *alsa = (ALSAVoiceIn *) hw; > > - return alsa_poll_helper (alsa->handle, &alsa->pollhlp); > + return alsa_poll_helper (alsa->handle, &alsa->pollhlp, POLLIN); > } > > static int alsa_write (SWVoiceOut *sw, void *buf, int len) > > Nope, still full CPU load. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-13 19:57 ` Jan Kiszka @ 2009-09-13 20:07 ` Jan Kiszka 2009-09-14 0:02 ` malc 2009-09-13 23:31 ` malc 1 sibling, 1 reply; 23+ messages in thread From: Jan Kiszka @ 2009-09-13 20:07 UTC (permalink / raw) To: malc; +Cc: qemu-devel [-- Attachment #1: Type: text/plain, Size: 1998 bytes --] Jan Kiszka wrote: > malc wrote: >> Does following help? >> >> diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c >> index 28c245d..9cc1372 100644 >> --- a/audio/alsaaudio.c >> +++ b/audio/alsaaudio.c >> @@ -37,6 +37,7 @@ struct pollhlp { >> snd_pcm_t *handle; >> struct pollfd *pfds; >> int count; >> + int mask; >> }; >> >> typedef struct ALSAVoiceOut { >> @@ -178,7 +179,7 @@ static void alsa_poll_handler (void *opaque) >> return; >> } >> >> - if (!(revents & POLLOUT)) { >> + if (!(revents & hlp->mask)) { >> if (conf.verbose) { >> dolog ("revents = %d\n", revents); >> } >> @@ -208,7 +209,7 @@ static void alsa_poll_handler (void *opaque) >> } >> } >> >> -static int alsa_poll_helper (snd_pcm_t *handle, struct pollhlp *hlp) >> +static int alsa_poll_helper (snd_pcm_t *handle, struct pollhlp *hlp, int mask) >> { >> int i, count, err; >> struct pollfd *pfds; >> @@ -265,6 +266,7 @@ static int alsa_poll_helper (snd_pcm_t *handle, struct pollhlp *hlp) >> hlp->pfds = pfds; >> hlp->count = count; >> hlp->handle = handle; >> + hlp->mask = mask; >> return 0; >> } >> >> @@ -272,14 +274,14 @@ static int alsa_poll_out (HWVoiceOut *hw) >> { >> ALSAVoiceOut *alsa = (ALSAVoiceOut *) hw; >> >> - return alsa_poll_helper (alsa->handle, &alsa->pollhlp); >> + return alsa_poll_helper (alsa->handle, &alsa->pollhlp, POLLOUT); >> } >> >> static int alsa_poll_in (HWVoiceIn *hw) >> { >> ALSAVoiceIn *alsa = (ALSAVoiceIn *) hw; >> >> - return alsa_poll_helper (alsa->handle, &alsa->pollhlp); >> + return alsa_poll_helper (alsa->handle, &alsa->pollhlp, POLLIN); >> } >> >> static int alsa_write (SWVoiceOut *sw, void *buf, int len) >> >> > > Nope, still full CPU load. Forgot to mention: I also tried OSS before, but it suffered the same way, and polling had to be disabled. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-13 20:07 ` Jan Kiszka @ 2009-09-14 0:02 ` malc 2009-09-14 6:18 ` Jan Kiszka 0 siblings, 1 reply; 23+ messages in thread From: malc @ 2009-09-14 0:02 UTC (permalink / raw) To: qemu-devel On Sun, 13 Sep 2009, Jan Kiszka wrote: > Jan Kiszka wrote: > > malc wrote: > >> Does following help? [..snip.] > > Nope, still full CPU load. > > Forgot to mention: I also tried OSS before, but it suffered the same > way, and polling had to be disabled. > Aha, i've commited this patch and another which correct premature closure of audio device (for both OSS and ALSA), can not notice anything particularly wrong when running with poll enabled now, can you please retest things on your end, once again it would be nice to have both audio systems, tested. Thanks in advance. -- mailto:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-14 0:02 ` malc @ 2009-09-14 6:18 ` Jan Kiszka 2009-09-14 21:13 ` malc 0 siblings, 1 reply; 23+ messages in thread From: Jan Kiszka @ 2009-09-14 6:18 UTC (permalink / raw) To: malc; +Cc: qemu-devel [-- Attachment #1: Type: text/plain, Size: 733 bytes --] malc wrote: > On Sun, 13 Sep 2009, Jan Kiszka wrote: > >> Jan Kiszka wrote: >>> malc wrote: >>>> Does following help? > > [..snip.] > >>> Nope, still full CPU load. >> Forgot to mention: I also tried OSS before, but it suffered the same >> way, and polling had to be disabled. >> > > Aha, i've commited this patch and another which correct premature > closure of audio device (for both OSS and ALSA), can not notice > anything particularly wrong when running with poll enabled now, can > you please retest things on your end, once again it would be nice to > have both audio systems, tested. Thanks in advance. > Sorry, both audio systems still require to disable polling for a normal cpu load. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-14 6:18 ` Jan Kiszka @ 2009-09-14 21:13 ` malc 2009-09-14 21:30 ` [Qemu-devel] Solaris SPARC guest on QEMU Luis Freitas 2009-09-15 20:11 ` [Qemu-devel] Re: Audio Jan Kiszka 0 siblings, 2 replies; 23+ messages in thread From: malc @ 2009-09-14 21:13 UTC (permalink / raw) To: Jan Kiszka; +Cc: qemu-devel On Mon, 14 Sep 2009, Jan Kiszka wrote: > malc wrote: > > On Sun, 13 Sep 2009, Jan Kiszka wrote: > > > >> Jan Kiszka wrote: > >>> malc wrote: > >>>> Does following help? > > > > [..snip.] > > > >>> Nope, still full CPU load. > >> Forgot to mention: I also tried OSS before, but it suffered the same > >> way, and polling had to be disabled. > >> > > > > Aha, i've commited this patch and another which correct premature > > closure of audio device (for both OSS and ALSA), can not notice > > anything particularly wrong when running with poll enabled now, can > > you please retest things on your end, once again it would be nice to > > have both audio systems, tested. Thanks in advance. > > > > Sorry, both audio systems still require to disable polling for a normal > cpu load. I believe the problem is within wm8750(/musicpal combination?) wm8750_set_format creates a bunch of ADC voices and enables them, but no reads are ever performed, so ALSA/OSS quickly fills the buffers and then stops reading into them thus leaving respective fd's in a selectable state. My main machine lacks ADC so i was unable to reproduce the behaviour you've seen on it on another box the issue is indeed very visible. Setting QEMU_OSS_ADC_DEV to /dev/moo or commenting out AUD_set_active_in in wm8750.c cures the problem as does, contrary to your report, setting QEMU_AUDIO_ADC_TRY_POLL to 0. -- mailto:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Qemu-devel] Solaris SPARC guest on QEMU 2009-09-14 21:13 ` malc @ 2009-09-14 21:30 ` Luis Freitas 2009-09-15 6:33 ` Laurent Vivier 2009-09-15 8:55 ` Artyom Tarasenko 2009-09-15 20:11 ` [Qemu-devel] Re: Audio Jan Kiszka 1 sibling, 2 replies; 23+ messages in thread From: Luis Freitas @ 2009-09-14 21:30 UTC (permalink / raw) To: qemu-devel Hi, I would like to use QEMU to run a guest Solaris 8/Sparc machine. Seems that openbios is missing something that Solaris needs to complete the boot process. I posted a entry on the qemu users forum but got no replies. The boot seems to be failing after the initial boot program is loaded from the disk, it seems unable to find the second stage boot program, so it is probably something related to how the second stage should identify the boot device. The Sun OBP (For sun4v...) and bootprog sources are availabe, but they are writen on some language I never heard of before (Forth). I could not find any parameters to debug the openbios boot process or the solaris bootprog. Any sugestions? Best Regards, Luis ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] Solaris SPARC guest on QEMU 2009-09-14 21:30 ` [Qemu-devel] Solaris SPARC guest on QEMU Luis Freitas @ 2009-09-15 6:33 ` Laurent Vivier 2009-09-15 23:31 ` Luis Freitas 2009-09-15 8:55 ` Artyom Tarasenko 1 sibling, 1 reply; 23+ messages in thread From: Laurent Vivier @ 2009-09-15 6:33 UTC (permalink / raw) To: Luis Freitas; +Cc: qemu-devel Le lundi 14 septembre 2009 à 14:30 -0700, Luis Freitas a écrit : > Hi, > > I would like to use QEMU to run a guest Solaris 8/Sparc machine. > > Seems that openbios is missing something that Solaris needs to complete the boot process. I posted a entry on the qemu users forum but got no replies. The boot seems to be failing after the initial boot program is loaded from the disk, it seems unable to find the second stage boot program, so it is probably something related to how the second stage should identify the boot device. > > The Sun OBP (For sun4v...) and bootprog sources are availabe, but they are writen on some language I never heard of before (Forth). > > I could not find any parameters to debug the openbios boot process or the solaris bootprog. > > Any sugestions? Do you have any error messages ? Laurent -- --------------------- laurent@vivier.eu ---------------------- "Tout ce qui est impossible reste à accomplir" Jules Verne "Things are only impossible until they're not" Jean-Luc Picard ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] Solaris SPARC guest on QEMU 2009-09-15 6:33 ` Laurent Vivier @ 2009-09-15 23:31 ` Luis Freitas 0 siblings, 0 replies; 23+ messages in thread From: Luis Freitas @ 2009-09-15 23:31 UTC (permalink / raw) To: Laurent Vivier; +Cc: qemu-devel Laurent, The error message I get is this: [luis@localhost qemu01]$ qemu-system-sparc -debug -nographic -m 256 -hda hd01.img -cdrom /dev/cdrw -boot d Configuration device id QEMU version 1 machine id 32 UUID: 00000000-0000-0000-0000-000000000000 CPUs: 1 x FMI,MB86904 Welcome to OpenBIOS v1.0 built on Mar 1 2009 19:08 Type 'help' for detailed information [sparc] Booting file 'cdrom' with parameters '' Trying cdrom (/iommu/sbus/espdma/esp/sd@2,0) Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Trying cdrom:d (/iommu/sbus/espdma/esp/sd@2,0:d) Not a bootable ELF image Not a Linux kernel image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point... bootblk: can't find the boot program halt, power off [luis@localhost qemu01]$ From this I gather that: Openbios understand the solaris disk label on the cdrom, since it can load the bootblk on cdrom:d and start it. Bootblk is loaded, but cannot read the second stage, that from what I could gather the second stage should be on cdrom:e, inside a ufs filesystem. Bootblk sources are available on OpenSolaris 10, but this version no longer has support for the older 32 bits servers, and it is writen in Forth. (up to now I could not make anything usefull from the sources, sigh). Best Regards, Luis --- On Tue, 9/15/09, Laurent Vivier <Laurent@vivier.eu> wrote: > From: Laurent Vivier <Laurent@vivier.eu> > Subject: Re: [Qemu-devel] Solaris SPARC guest on QEMU > To: "Luis Freitas" <lfreitas34@yahoo.com> > Cc: qemu-devel@nongnu.org > Date: Tuesday, September 15, 2009, 3:33 AM > Le lundi 14 septembre 2009 à 14:30 > -0700, Luis Freitas a écrit : > > Hi, > > > > I would like to use QEMU to run a guest > Solaris 8/Sparc machine. > > > > Seems that openbios is missing something > that Solaris needs to complete the boot process. I posted a > entry on the qemu users forum but got no replies. The boot > seems to be failing after the initial boot program is loaded > from the disk, it seems unable to find the second stage boot > program, so it is probably something related to how the > second stage should identify the boot device. > > > > The Sun OBP (For sun4v...) and bootprog > sources are availabe, but they are writen on some language I > never heard of before (Forth). > > > > I could not find any parameters to debug > the openbios boot process or the solaris bootprog. > > > > Any sugestions? > > Do you have any error messages ? > > Laurent > -- > --------------------- laurent@vivier.eu > ---------------------- > "Tout ce qui est impossible reste à accomplir" > Jules Verne > "Things are only impossible until they're not" Jean-Luc > Picard > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] Solaris SPARC guest on QEMU 2009-09-14 21:30 ` [Qemu-devel] Solaris SPARC guest on QEMU Luis Freitas 2009-09-15 6:33 ` Laurent Vivier @ 2009-09-15 8:55 ` Artyom Tarasenko 2009-09-15 19:19 ` Blue Swirl 1 sibling, 1 reply; 23+ messages in thread From: Artyom Tarasenko @ 2009-09-15 8:55 UTC (permalink / raw) To: Luis Freitas; +Cc: qemu-devel 2009/9/14 Luis Freitas <lfreitas34@yahoo.com>: > Hi, > > I would like to use QEMU to run a guest Solaris 8/Sparc machine. You are not alone. This topic pops every 1-2 years. > Seems that openbios is missing something that Solaris needs to complete the boot process. I posted a entry on the qemu users forum but got no replies. The boot seems to be failing after the initial boot program is loaded from the disk, it seems unable to find the second stage boot program, so it is probably something related to how the second stage should identify the boot device. The real Sun's OBP under qemu has the same problem. I guess it's not the problem of OpenBIOS, but some bugs in SCSI/DMA/(IO)MMU layer. It's not the identification of the boot device though. The first stage reads something from a disk. It just fails to find some magic patterns in what it gets. > Any sugestions? > I would try to approach from the other side. Some years ago Sun was selling Solaris 8 (and 9) with sources. If you manage to obtain them, you could see what the first stage actually does. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] Solaris SPARC guest on QEMU 2009-09-15 8:55 ` Artyom Tarasenko @ 2009-09-15 19:19 ` Blue Swirl 2009-09-15 21:08 ` Stuart Brady 2009-09-16 8:28 ` Artyom Tarasenko 0 siblings, 2 replies; 23+ messages in thread From: Blue Swirl @ 2009-09-15 19:19 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: qemu-devel, Luis Freitas On Tue, Sep 15, 2009 at 11:55 AM, Artyom Tarasenko <atar4qemu@googlemail.com> wrote: > 2009/9/14 Luis Freitas <lfreitas34@yahoo.com>: >> Hi, >> >> I would like to use QEMU to run a guest Solaris 8/Sparc machine. > > You are not alone. This topic pops every 1-2 years. > >> Seems that openbios is missing something that Solaris needs to complete the boot process. I posted a entry on the qemu users forum but got no replies. The boot seems to be failing after the initial boot program is loaded from the disk, it seems unable to find the second stage boot program, so it is probably something related to how the second stage should identify the boot device. Maybe the raw disk access (without partition translation) does not work. There was something on OpenBIOS list recently for PPC: http://www.openfirmware.info/pipermail/openbios/2009-September/003977.html > The real Sun's OBP under qemu has the same problem. I guess it's not > the problem of OpenBIOS, but some bugs in SCSI/DMA/(IO)MMU layer. > It's not the identification of the boot device though. The first stage > reads something from a disk. It just fails to find some magic patterns > in what it gets. IIRC the CD-ROM drives used by Sun were slightly different from standard SCSI models, something like the block size could be 512 bytes instead of 2048 or vice versa. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] Solaris SPARC guest on QEMU 2009-09-15 19:19 ` Blue Swirl @ 2009-09-15 21:08 ` Stuart Brady 2009-09-16 8:28 ` Artyom Tarasenko 1 sibling, 0 replies; 23+ messages in thread From: Stuart Brady @ 2009-09-15 21:08 UTC (permalink / raw) To: qemu-devel On Tue, Sep 15, 2009 at 10:19:41PM +0300, Blue Swirl wrote: > > IIRC the CD-ROM drives used by Sun were slightly different from > standard SCSI models, something like the block size could be 512 bytes > instead of 2048 or vice versa. FWIW, PA-RISC machines and some SGI machines also require CD-ROM drives with 512 byte blocks. Cheers, -- Stuart Brady ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] Solaris SPARC guest on QEMU 2009-09-15 19:19 ` Blue Swirl 2009-09-15 21:08 ` Stuart Brady @ 2009-09-16 8:28 ` Artyom Tarasenko 2009-09-16 15:38 ` Luis Freitas 1 sibling, 1 reply; 23+ messages in thread From: Artyom Tarasenko @ 2009-09-16 8:28 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel, Luis Freitas 2009/9/15 Blue Swirl <blauwirbel@gmail.com>: > On Tue, Sep 15, 2009 at 11:55 AM, Artyom Tarasenko > <atar4qemu@googlemail.com> wrote: >> 2009/9/14 Luis Freitas <lfreitas34@yahoo.com>: >>> Hi, >>> >>> I would like to use QEMU to run a guest Solaris 8/Sparc machine. >> >> You are not alone. This topic pops every 1-2 years. >> >>> Seems that openbios is missing something that Solaris needs to complete the boot process. I posted a entry on the qemu users forum but got no replies. The boot seems to be failing after the initial boot program is loaded from the disk, it seems unable to find the second stage boot program, so it is probably something related to how the second stage should identify the boot device. > > Maybe the raw disk access (without partition translation) does not > work. There was something on OpenBIOS list recently for PPC: > http://www.openfirmware.info/pipermail/openbios/2009-September/003977.html > >> The real Sun's OBP under qemu has the same problem. I guess it's not >> the problem of OpenBIOS, but some bugs in SCSI/DMA/(IO)MMU layer. >> It's not the identification of the boot device though. The first stage >> reads something from a disk. It just fails to find some magic patterns >> in what it gets. > > IIRC the CD-ROM drives used by Sun were slightly different from > standard SCSI models, something like the block size could be 512 bytes > instead of 2048 or vice versa. I don't think it has to do with it. Booting from a hd image produces the same error. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] Solaris SPARC guest on QEMU 2009-09-16 8:28 ` Artyom Tarasenko @ 2009-09-16 15:38 ` Luis Freitas 2009-09-16 16:33 ` Artyom Tarasenko 0 siblings, 1 reply; 23+ messages in thread From: Luis Freitas @ 2009-09-16 15:38 UTC (permalink / raw) To: qemu-devel Tried to use the CDROM for the HD image, to force it to behave with 512 byte sectors, same result. I browsed the sources yesterday and seems that the code between disk and cdrom is shared, the behaviour depends only on how it is initialized, also the CDRom has a geometry translation, either lba or msf (What is msf?). I dont think Sun servers have this kind of translation but I dont know if this could cause problems, will need to look at the bootprg sources for clues on this. (Perhaps the geometry on the Sun disk label needs to match what is defined on the hardware?) I could not find where in the code the CDROM is defined to have 2048 byte sectors or where its geometry is defined. Any pointers? Best Regards, Luis --- On Wed, 9/16/09, Artyom Tarasenko <atar4qemu@googlemail.com> wrote: >> The real Sun's OBP under qemu has the same > problem. I guess it's not > >> the problem of OpenBIOS, but some bugs in > SCSI/DMA/(IO)MMU layer. > >> It's not the identification of the boot device > though. The first stage > >> reads something from a disk. It just fails to find > some magic patterns > >> in what it gets. > > > > IIRC the CD-ROM drives used by Sun were slightly > different from > > standard SCSI models, something like the block size > could be 512 bytes > > instead of 2048 or vice versa. > > I don't think it has to do with it. Booting from a hd image > produces > the same error. > > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] Solaris SPARC guest on QEMU 2009-09-16 15:38 ` Luis Freitas @ 2009-09-16 16:33 ` Artyom Tarasenko 0 siblings, 0 replies; 23+ messages in thread From: Artyom Tarasenko @ 2009-09-16 16:33 UTC (permalink / raw) To: Luis Freitas; +Cc: qemu-devel 2009/9/16 Luis Freitas <lfreitas34@yahoo.com>: > > Tried to use the CDROM for the HD image, to force it to behave with 512 byte sectors, same result. > > I browsed the sources yesterday and seems that the code between disk and cdrom is shared, the behaviour depends only on how it is initialized, also the CDRom has a geometry translation, either lba or msf (What is msf?). I dont think Sun servers have this kind of translation but I dont know if this could cause problems, will need to look at the bootprg sources for clues on this. (Perhaps the geometry on the Sun disk label needs to match what is defined on the hardware?) > > I could not find where in the code the CDROM is defined to have 2048 byte sectors or where its geometry is defined. Any pointers? Again, I think the problem doesn't have to do with the cdrom's sector size. Booting from a real hd (not a cdrom) image throws the same error. ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-14 21:13 ` malc 2009-09-14 21:30 ` [Qemu-devel] Solaris SPARC guest on QEMU Luis Freitas @ 2009-09-15 20:11 ` Jan Kiszka 2009-09-18 18:49 ` Jan Kiszka 1 sibling, 1 reply; 23+ messages in thread From: Jan Kiszka @ 2009-09-15 20:11 UTC (permalink / raw) To: malc; +Cc: qemu-devel [-- Attachment #1: Type: text/plain, Size: 1790 bytes --] malc wrote: > On Mon, 14 Sep 2009, Jan Kiszka wrote: > >> malc wrote: >>> On Sun, 13 Sep 2009, Jan Kiszka wrote: >>> >>>> Jan Kiszka wrote: >>>>> malc wrote: >>>>>> Does following help? >>> [..snip.] >>> >>>>> Nope, still full CPU load. >>>> Forgot to mention: I also tried OSS before, but it suffered the same >>>> way, and polling had to be disabled. >>>> >>> Aha, i've commited this patch and another which correct premature >>> closure of audio device (for both OSS and ALSA), can not notice >>> anything particularly wrong when running with poll enabled now, can >>> you please retest things on your end, once again it would be nice to >>> have both audio systems, tested. Thanks in advance. >>> >> Sorry, both audio systems still require to disable polling for a normal >> cpu load. > > I believe the problem is within wm8750(/musicpal combination?) > wm8750_set_format creates a bunch of ADC voices and enables them, but > no reads are ever performed, so ALSA/OSS quickly fills the buffers > and then stops reading into them thus leaving respective fd's in a > selectable state. My main machine lacks ADC so i was unable to reproduce > the behaviour you've seen on it on another box the issue is indeed very > visible. Setting QEMU_OSS_ADC_DEV to /dev/moo or commenting out > AUD_set_active_in in wm8750.c cures the problem as does, contrary to > your report, setting QEMU_AUDIO_ADC_TRY_POLL to 0. Cannot confirm this: Neither commenting out AUD_set_active_in nor "tuning" QEMU_OSS_ADC_DEV makes any difference here. But what I observed is that once I tune in some station / play some song on the Musicpal, the load goes down and stays in normal range. Will dig a bit in this direction, trying to find out what is different then. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-15 20:11 ` [Qemu-devel] Re: Audio Jan Kiszka @ 2009-09-18 18:49 ` Jan Kiszka 2009-09-18 19:29 ` malc 0 siblings, 1 reply; 23+ messages in thread From: Jan Kiszka @ 2009-09-18 18:49 UTC (permalink / raw) To: malc; +Cc: qemu-devel [-- Attachment #1: Type: text/plain, Size: 2458 bytes --] Jan Kiszka wrote: > malc wrote: >> On Mon, 14 Sep 2009, Jan Kiszka wrote: >> >>> malc wrote: >>>> On Sun, 13 Sep 2009, Jan Kiszka wrote: >>>> >>>>> Jan Kiszka wrote: >>>>>> malc wrote: >>>>>>> Does following help? >>>> [..snip.] >>>> >>>>>> Nope, still full CPU load. >>>>> Forgot to mention: I also tried OSS before, but it suffered the same >>>>> way, and polling had to be disabled. >>>>> >>>> Aha, i've commited this patch and another which correct premature >>>> closure of audio device (for both OSS and ALSA), can not notice >>>> anything particularly wrong when running with poll enabled now, can >>>> you please retest things on your end, once again it would be nice to >>>> have both audio systems, tested. Thanks in advance. >>>> >>> Sorry, both audio systems still require to disable polling for a normal >>> cpu load. >> I believe the problem is within wm8750(/musicpal combination?) >> wm8750_set_format creates a bunch of ADC voices and enables them, but >> no reads are ever performed, so ALSA/OSS quickly fills the buffers >> and then stops reading into them thus leaving respective fd's in a >> selectable state. My main machine lacks ADC so i was unable to reproduce >> the behaviour you've seen on it on another box the issue is indeed very >> visible. Setting QEMU_OSS_ADC_DEV to /dev/moo or commenting out >> AUD_set_active_in in wm8750.c cures the problem as does, contrary to >> your report, setting QEMU_AUDIO_ADC_TRY_POLL to 0. > > Cannot confirm this: Neither commenting out AUD_set_active_in nor > "tuning" QEMU_OSS_ADC_DEV makes any difference here. > > But what I observed is that once I tune in some station / play some song > on the Musicpal, the load goes down and stays in normal range. Will dig > a bit in this direction, trying to find out what is different then. The situation now looks like this: QEMU_AUDIO_DAC_TRY_POLL=0 is required to avoid that Musicpal emulation generates high load after boot-up and before the first sound playback (interestingly not including the startup sound of the Musicpal). ADC subsystem or settings have no effect on this. Moreover, the playback quality under ALSA suffers in polling mode when the guest CPU is under load. Jan PS: Independent of the polling issue, QEMU_ALSA_DAC_BUFFER_SIZE=0 currently gives skip-free playback for me while the default does not. Not sure what changed, but I suspect it's some local package. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-18 18:49 ` Jan Kiszka @ 2009-09-18 19:29 ` malc 0 siblings, 0 replies; 23+ messages in thread From: malc @ 2009-09-18 19:29 UTC (permalink / raw) To: Jan Kiszka; +Cc: qemu-devel On Fri, 18 Sep 2009, Jan Kiszka wrote: > Jan Kiszka wrote: > > malc wrote: > >> On Mon, 14 Sep 2009, Jan Kiszka wrote: > >> > >>> malc wrote: > >>>> On Sun, 13 Sep 2009, Jan Kiszka wrote: > >>>> > >>>>> Jan Kiszka wrote: > >>>>>> malc wrote: > >>>>>>> Does following help? > >>>> [..snip.] > >>>> > >>>>>> Nope, still full CPU load. > >>>>> Forgot to mention: I also tried OSS before, but it suffered the same > >>>>> way, and polling had to be disabled. > >>>>> > >>>> Aha, i've commited this patch and another which correct premature > >>>> closure of audio device (for both OSS and ALSA), can not notice > >>>> anything particularly wrong when running with poll enabled now, can > >>>> you please retest things on your end, once again it would be nice to > >>>> have both audio systems, tested. Thanks in advance. > >>>> > >>> Sorry, both audio systems still require to disable polling for a normal > >>> cpu load. > >> I believe the problem is within wm8750(/musicpal combination?) > >> wm8750_set_format creates a bunch of ADC voices and enables them, but > >> no reads are ever performed, so ALSA/OSS quickly fills the buffers > >> and then stops reading into them thus leaving respective fd's in a > >> selectable state. My main machine lacks ADC so i was unable to reproduce > >> the behaviour you've seen on it on another box the issue is indeed very > >> visible. Setting QEMU_OSS_ADC_DEV to /dev/moo or commenting out > >> AUD_set_active_in in wm8750.c cures the problem as does, contrary to > >> your report, setting QEMU_AUDIO_ADC_TRY_POLL to 0. > > > > Cannot confirm this: Neither commenting out AUD_set_active_in nor > > "tuning" QEMU_OSS_ADC_DEV makes any difference here. > > > > But what I observed is that once I tune in some station / play some song > > on the Musicpal, the load goes down and stays in normal range. Will dig > > a bit in this direction, trying to find out what is different then. > > The situation now looks like this: > > QEMU_AUDIO_DAC_TRY_POLL=0 is required to avoid that Musicpal emulation > generates high load after boot-up and before the first sound playback > (interestingly not including the startup sound of the Musicpal). ADC > subsystem or settings have no effect on this. Just so that i have more information to try and reproduce it, can you send me the output of -audio-help (so that i can see what values are really set), the configure line (so that i can see whether i should myself throw -enable-iothread into the mix) and perhaps the name of the sound card. > > Moreover, the playback quality under ALSA suffers in polling mode when > the guest CPU is under load. > Guest under load? Like when is musicpal under load (apart from startup)? > Jan > > PS: Independent of the polling issue, QEMU_ALSA_DAC_BUFFER_SIZE=0 > currently gives skip-free playback for me while the default does not. > Not sure what changed, but I suspect it's some local package. What's the output when running with QEMU_ALSA_VERBOSE=1? P.S. Please send the things to me directly, let's not polute the list with tons of uninteresting information. -- mailto:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Qemu-devel] Re: Audio 2009-09-13 19:57 ` Jan Kiszka 2009-09-13 20:07 ` Jan Kiszka @ 2009-09-13 23:31 ` malc 1 sibling, 0 replies; 23+ messages in thread From: malc @ 2009-09-13 23:31 UTC (permalink / raw) To: qemu-devel On Sun, 13 Sep 2009, Jan Kiszka wrote: > malc wrote: > > On Sun, 13 Sep 2009, Jan Kiszka wrote: > > > >> malc wrote: > >>> The code was just commited that enables "polling" audio mode (oss and > >>> alsa), it's also unconditionally enabled now to obtain some testing > >>> coverage, so please give it a whirl, feedback is welcome. > >> CPU load goes to 100% when starting my Musicpal image. Applying the fix > >> below and disabling polling again cures this effect here. > > > > Few things: > > > > Thanks for the patch, but i was at a loss how to properly apply it > > with git and retain all the relevant information (Subject/Authorhsip > > etc), so for the time being it was applied manually. > > Sorry, the patch was so trivial that I became sloppy. > > > > > In the past your mail server was bouncing my replies to threads where > > you paticipated, and since this new CC-ing madness is in place i'm not > > sure whether the list reply was delivered to you either, hence i > > emptied CC header and replying to the list alone. > > Unless the bounce said "mailbox full": Just forward me a recent bounce > message privately (replace web.de with siemens.com). Typically I get > wrong black-listings resolved with web.de within a day or less. No it was something else, i'll forward this message to you to try and get the bounce. > > > > > The Musicpal image i have here is getting stuck somewhere along the > > way to the point of monitor not being responsive, so i can not test > > anything myself. FWIW the command line is this: > > > > [...]/arm-softmmu/qemu-system-arm \ > > -M musicpal \ > > -pflash flash.image \ > > -kernel u-boot.bin \ > > -monitor stdio \ > > -m 128 \ > > -redir tcp:8080::80 -redir tcp:2323::23 > > Hmm, this setup works for me (current master). Maybe you can catch what > strace reports or which backtrace gdb generates. Does disabling polling > or reverting before your changes make it boot again? 930c86820e8e0b6dfcf211bda5e835463d72ff42 is what broke it for me, Following "fixes" it: diff --git a/hw/musicpal.c b/hw/musicpal.c index 1c4f17c..0fe9fd3 100644 --- a/hw/musicpal.c +++ b/hw/musicpal.c @@ -238,8 +238,8 @@ static void eth_send(mv88w8618_eth_state *s, int queue_index) uint8_t buf[2048]; int len; - do { + if (!desc_addr) return; eth_tx_desc_get(desc_addr, &desc); if (desc.cmdstat & MP_ETH_TX_OWN) { len = desc.bytes; [..snip..] Now that i have musicpal working, i'll try to investigate things further. -- mailto:av1474@comtv.ru ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] Re: Audio 2009-09-13 18:52 ` malc 2009-09-13 19:57 ` Jan Kiszka @ 2009-09-15 11:28 ` Avi Kivity 2009-09-22 11:24 ` malc 1 sibling, 1 reply; 23+ messages in thread From: Avi Kivity @ 2009-09-15 11:28 UTC (permalink / raw) To: malc; +Cc: qemu-devel On 09/13/2009 09:52 PM, malc wrote: > Thanks for the patch, but i was at a loss how to properly apply it > with git and retain all the relevant information (Subject/Authorhsip > etc), so for the time being it was applied manually. > 1. Save the email 2. 'git am -i --signoff /path/to/email' 3. delete all lines up to and including '------->' (might need to delete From: as well?) 4. save and exit -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] Re: Audio 2009-09-15 11:28 ` Avi Kivity @ 2009-09-22 11:24 ` malc 0 siblings, 0 replies; 23+ messages in thread From: malc @ 2009-09-22 11:24 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel On Tue, 15 Sep 2009, Avi Kivity wrote: > On 09/13/2009 09:52 PM, malc wrote: > > Thanks for the patch, but i was at a loss how to properly apply it > > with git and retain all the relevant information (Subject/Authorhsip > > etc), so for the time being it was applied manually. > > > > 1. Save the email > 2. 'git am -i --signoff /path/to/email' > 3. delete all lines up to and including '------->' (might need to delete From: > as well?) > 4. save and exit Tried and it works, thanks. -- mailto:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2009-09-22 11:24 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-11 23:34 [Qemu-devel] Audio malc 2009-09-13 11:30 ` [Qemu-devel] Audio Jan Kiszka 2009-09-13 18:52 ` malc 2009-09-13 19:57 ` Jan Kiszka 2009-09-13 20:07 ` Jan Kiszka 2009-09-14 0:02 ` malc 2009-09-14 6:18 ` Jan Kiszka 2009-09-14 21:13 ` malc 2009-09-14 21:30 ` [Qemu-devel] Solaris SPARC guest on QEMU Luis Freitas 2009-09-15 6:33 ` Laurent Vivier 2009-09-15 23:31 ` Luis Freitas 2009-09-15 8:55 ` Artyom Tarasenko 2009-09-15 19:19 ` Blue Swirl 2009-09-15 21:08 ` Stuart Brady 2009-09-16 8:28 ` Artyom Tarasenko 2009-09-16 15:38 ` Luis Freitas 2009-09-16 16:33 ` Artyom Tarasenko 2009-09-15 20:11 ` [Qemu-devel] Re: Audio Jan Kiszka 2009-09-18 18:49 ` Jan Kiszka 2009-09-18 19:29 ` malc 2009-09-13 23:31 ` malc 2009-09-15 11:28 ` Avi Kivity 2009-09-22 11:24 ` malc
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.