qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Win2k mouse


From: malc
Subject: Re: [Qemu-devel] Win2k mouse
Date: Fri, 16 Apr 2004 20:33:51 +0400 (MSD)

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:address@hidden




reply via email to

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