From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BEKR5-00033U-29 for qemu-devel@nongnu.org; Thu, 15 Apr 2004 23:54:39 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BEKQO-0002Ad-T0 for qemu-devel@nongnu.org; Thu, 15 Apr 2004 23:54:29 -0400 Received: from [81.228.9.108] (helo=av2-2-sn3.vrr.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BEKQM-00026F-Vw for qemu-devel@nongnu.org; Thu, 15 Apr 2004 23:53:55 -0400 Message-ID: <000401c42366$7d2464f0$0401a8c0@putte2k> From: "Mike Nordell" References: <002801c42260$67c56110$0401a8c0@putte2k> <200404151052.55500.jm@poure.com> <20040415113738.B19597@bbland> <001c01c422f0$64ae5aa0$0401a8c0@putte2k> <20040415203109.A23097@bbland> <20040415222123.A24057@bbland> Subject: Re: [Qemu-devel] Win2k mouse Date: Fri, 16 Apr 2004 05:54:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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