[Qemu-devel] sound issue

[Qemu-devel] sound issue

[Rick Vernam]

I've spent quite a lot of time trying to figure out why this keeps happening:

$ export QEMU_AUDIO_DRV=alsa
$ qemu-system-x86_64 -kernel-kqemu -hda /home/rick/docs/.qemu/wxp1.qemu -m 
192 -net nic -net tap,script=/etc/qemu-ifup -localtime -snapshot -usbdevice 
tablet -soundhw es1370
alsa: Could not initialize ADC
alsa: Failed to set period size 1024
alsa: Reason: Invalid argument
alsa: Could not initialize ADC
alsa: Failed to set period size 1024
alsa: Reason: Invalid argument
audio: Failed to create voice `es1370.adc'
alsa: Could not initialize ADC
alsa: Failed to set period size 1024
alsa: Reason: Invalid argument
alsa: Could not initialize ADC
alsa: Failed to set period size 1024
alsa: Reason: Invalid argument
audio: Failed to create voice `es1370.adc'

I get no sound.
If I knew what these things meant, I might be able to figure this out...
Posting here is my last ditch effort - believe me, I have tried to avoid 
posting support questions in a dev. list, but am hoping for a bit of insight 
here...

almost forgot, linux host (gentoo), 2.6.17 kernel.

thanks
-Rick

[Qemu-devel] Re: sound issue

[malc]

Rick Vernam <rickv <at> hobi.com> writes:

> 
> I've spent quite a lot of time trying to figure out why this keeps happening:
> 
> $ export QEMU_AUDIO_DRV=alsa
> $ qemu-system-x86_64 -kernel-kqemu -hda /home/rick/docs/.qemu/wxp1.qemu -m 
> 192 -net nic -net tap,script=/etc/qemu-ifup -localtime -snapshot -usbdevice 
> tablet -soundhw es1370
> alsa: Could not initialize ADC
> alsa: Failed to set period size 1024

[..snip..]

> 
> I get no sound.
> If I knew what these things meant, I might be able to figure this out...
> Posting here is my last ditch effort - believe me, I have tried to avoid 
> posting support questions in a dev. list, but am hoping for a bit of insight 
> here...

The error messages just notify you that qemu can not open "recording" device
due to the problems with setting the period value, you can adjust it via env
variables (consult qemu -audio-help for that). But DAC (i.e. playback) seems
to be functioning so lack of sound (without any further error messages) is
strange.

P.S. Btw. does sound work in plain i386-softmmu qemu?
     You can mail me directly.

Re: [Qemu-devel] Win2k mouse

[Mike Nordell]

Hetz Ben Hamo wrote:

> Mike Nordell has send a keyboard/mouse fix for win2k as a guest,
> but I only see keyboard fix in the CVS.

Actually, the fix wasn't specifically for win2k guest. It was a deadlock
that would most probably have occured in any guest OS having both mouse and
keyboard input.

The problem was that (PS/2) mouse input was given priority when QEMU came to
choose between mouse and keyboard interrupts to report to the CPU, but when
the guest was reading I/O port 0x60 the keyboard queue had priority. Imagine
the deadlock when both mouse and keyboard messages were pending. :-)

The easiest way to see this bug in action was by grabbing the mouse and then
alt-tab (or whatever the kbd shortcut for switching to another window is in
your environment) to another window. Voila. Instant guest input lock.


I've got a feeling, though not yet any strong evidence, that since QEMU PC
emulation is yet so incomplete (it's basically like a 386 PC, with a 686
CPU) NT switches to some safety-mode for a lot of stuff. This could
potentially involve a lot of switching between protected mode and v86 mode,
which would slow down the emulation as seen. It's btw not only mouse - try
starting the Task Manager in the guest and watch the CPU pegged while
running it. Close that one and start PerfMon. Add e.g. interrupts/s or DPC
time or... anything. The numbers are off the chart (probably NT can't even
get them, but it might also be they are so insanely high they can't be
trusted), but it's no longer pegging the CPU (you'll notice it's no longer
using all available host CPU).

I'm right now on my way to add some profiling code to QEMU to see what's
going on in this area. While NT as guest behaves like this, just booting it
is a test of patience why it might take some days before I get any real
numbers.

/Mike

Re: [Qemu-devel] Win2k mouse

[Jean-Michel POURE]

> While NT as guest behaves like this, just booting it
> is a test of patience why it might take some days before I get any real
> numbers.

Dear Mike,

Actually, under my Pentium4 1.8 Ghz desktop, QEMU is able to boot Win2k in 90 
seconds (until password prompt) and needs another 30 seconds to display the 
desk. This is fairly fast compared to other emulation softwares.

When using Bochs, I can remember installations lasting 48 hours and a one hour 
startup. Using Qemu, I was able to install Win2k in one hour and a half. 

In the case of Win2k, appying the ne2000 patch and solving the mouse issue 
would be perfect. Then people can start using Win2k and sending bug reports, 
patches and improvements. 

Cheers,
Jean-Michel

Re: [Qemu-devel] Win2k mouse

[Lionel Ulmer]

> In the case of Win2k, appying the ne2000 patch and solving the mouse issue 
> would be perfect. Then people can start using Win2k and sending bug reports, 
> patches and improvements. 

In my case, I still have QEMU segfaulting on me during the second stage
installation.

      Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Win2k mouse

[Mike Nordell]

Lionel Ulmer wrote:

> In my case, I still have QEMU segfaulting on me during the second
> stage installation.

I believe the fix is in the pipe. But to get some more input on something
related; could you first make sure you have target-i386/helper.c from CVS.
Then test searching for "XXX: explain me why W2K hangs" and replace "#if 1"
with "#if 0". There is reason to believe the fixed eip when returning to v86
mode has taken care of the problem that cludge was for.

In addition I can report that doing just that, resetting the segment cache,
allows the ToolStar*Test demo floppy to run as expected. Previously it
had... should we say some problems.


There are still bugs in the VGA code that will totally hang for which I've
mailed Fabrice the patches. Should you want to preempt CVS to see if they
make a difference (they stop QEMU from SEGV), at the beginning of
vga_update_display add the following:

    if (!(s->ar_index & 0x20)) { /* output is disabled */
        printf("VGA: vga_update_display not updating due to display
disabled\n");
        return;
    }


Then in vga_draw_text (sorry, no line numbers since my vga.c doesn't match
yours in that respect), around 90 lines into it just before the cy loop
starts, try the following:

    if (height * width >= CH_ATTR_SIZE)
    {
        printf("TMN: Saving VGA from crashing in vga_draw_text()\n");
        return;
    }


/Mike

Re: [Qemu-devel] Win2k mouse

[Lionel Ulmer]

> Then in vga_draw_text (sorry, no line numbers since my vga.c doesn't match
> yours in that respect), around 90 lines into it just before the cy loop
> starts, try the following:
> 
>     if (height * width >= CH_ATTR_SIZE)
>     {
>         printf("TMN: Saving VGA from crashing in vga_draw_text()\n");
>         return;
>     }

This is the one that saves me :

VGA: vga_update_display not updating due to display disabled
VGA: vga_update_display not updating due to display disabled
TMN: Saving VGA from crashing in vga_draw_text()

Now I start to see the rest of the Win2K second-stage installer. So at least
it helps going a bit further than before.

          Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Win2k mouse

[Lionel Ulmer]

> Now I start to see the rest of the Win2K second-stage installer. So at least
> it helps going a bit further than before.

Well, I spoke a bit too fast : it's still segfaulting, but a bit further
than before, just after the 'Setup is detecting and installing devices on
your computer'.

Trying a second time right now (I only have a P2 333, so it's rather slow).
If it's still crashing, I will test with re-putting the '#if 1' in the
helper.c file to see if it helps).

            Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Win2k mouse

[Mike Nordell]

Lionel Ulmer wrote:

> > Now I start to see the rest of the Win2K second-stage installer. So at
> > least it helps going a bit further than before.
>
> Well, I spoke a bit too fast : it's still segfaulting, but a bit further
> than before, just after the 'Setup is detecting and installing devices on
> your computer'.

Just for kicks, you might test the following for hw/sb16:

@@ -426,6 +449,7 @@
             dsp->v2x6 = 0;
         else if ((1 == val) && (0 == dsp->v2x6)) {
             dsp->v2x6 = 1;
+            assert(dsp->out_data_len <
sizeof(dsp->out_data)/sizeof(*dsp->out_data));
             dsp->out_data[dsp->out_data_len++] = 0xaa;
         }
         else
@@ -537,6 +561,7 @@
 static IO_READ_PROTO(mixer_read)
 {
     SB16State *dsp = opaque;
+     assert(dsp->mixer_nreg <
sizeof(dsp->mixer_regs)/sizeof(*dsp->mixer_regs));
     return dsp->mixer_regs[dsp->mixer_nreg];
 }


I'm right now in the debugger after an attempted read from memory the SB16
emulator has no business probing.

Right after this, the gfx got really screwy, starting to display vertical
white lines over the setup dialog, why I think it's a fair bet guest kernel
memory has been overwritten by something. Judging by these accesses, I quite
obviously suspect some other device emulation code. I'll add another bunch
of asserts all over the place, but considering it takes me around 2-3 hours
to reach this point (starting from an image where the first phase of the
setup, copying files to target disk, has already completed), don't expect
any earth-shattering revelations anytime soon.


Does anyone know SB16 h/w enough to say what would be the right behaviour
here:

- To limit mixer_nreg in mixer_write_indexb to ?
- To return 0xff (or anything else) from mixer_read if mixer_nreg is OOB?
- To extend mixer_nreg to 256 bytes?
- To, just for kicks, stream n chunks of m bytes from /dev/random to an
equally random address in the QEMU process' memory? Just to see what
happens. :-)


/Mike - looking for devices that need some TLC with a 2x4

Re: [Qemu-devel] Win2k mouse

[malc]

On Fri, 16 Apr 2004, Mike Nordell wrote:

> Lionel Ulmer wrote:
>
> > > Now I start to see the rest of the Win2K second-stage installer. So at
> > > least it helps going a bit further than before.
> >
> > Well, I spoke a bit too fast : it's still segfaulting, but a bit further
> > than before, just after the 'Setup is detecting and installing devices on
> > your computer'.
>
> Just for kicks, you might test the following for hw/sb16:
>
> @@ -426,6 +449,7 @@
>              dsp->v2x6 = 0;
>          else if ((1 == val) && (0 == dsp->v2x6)) {
>              dsp->v2x6 = 1;
> +            assert(dsp->out_data_len <
> sizeof(dsp->out_data)/sizeof(*dsp->out_data));
>              dsp->out_data[dsp->out_data_len++] = 0xaa;
>          }
>          else
> @@ -537,6 +561,7 @@
>  static IO_READ_PROTO(mixer_read)
>  {
>      SB16State *dsp = opaque;
> +     assert(dsp->mixer_nreg <
> sizeof(dsp->mixer_regs)/sizeof(*dsp->mixer_regs));
>      return dsp->mixer_regs[dsp->mixer_nreg];
>  }
>
>
> I'm right now in the debugger after an attempted read from memory the SB16
> emulator has no business probing.
>
> Right after this, the gfx got really screwy, starting to display vertical
> white lines over the setup dialog, why I think it's a fair bet guest kernel
> memory has been overwritten by something. Judging by these accesses, I quite
> obviously suspect some other device emulation code. I'll add another bunch
> of asserts all over the place, but considering it takes me around 2-3 hours
> to reach this point (starting from an image where the first phase of the
> setup, copying files to target disk, has already completed), don't expect
> any earth-shattering revelations anytime soon.
>
>
> Does anyone know SB16 h/w enough to say what would be the right behaviour
> here:

I have used http://www.doc.ic.ac.uk/~ih/doc/sound/sblast09/ as a
reference. Only 131 mixer registers are documented there.

>
> - To limit mixer_nreg in mixer_write_indexb to ?
> - To return 0xff (or anything else) from mixer_read if mixer_nreg is OOB?
> - To extend mixer_nreg to 256 bytes?
> - To, just for kicks, stream n chunks of m bytes from /dev/random to an
> equally random address in the QEMU process' memory? Just to see what
> happens. :-)

My vote goes for the latter.

-- 
mailto:malc@pulsesoft.com

[Qemu-devel] sound issue

[Hetz Ben Hamo]

Hi,

Any chance you could "port" the SB16 code from Bochs? 

Thanks,
Hetz

> I have used http://www.doc.ic.ac.uk/~ih/doc/sound/sblast09/ as a
> reference. Only 131 mixer registers are documented there.