From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mn51A-00049J-LK for qemu-devel@nongnu.org; Mon, 14 Sep 2009 02:26:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mn514-000423-SO for qemu-devel@nongnu.org; Mon, 14 Sep 2009 02:26:28 -0400 Received: from [199.232.76.173] (port=35773 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mn514-00041s-KM for qemu-devel@nongnu.org; Mon, 14 Sep 2009 02:26:22 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:43899) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mn514-0007Fg-1A for qemu-devel@nongnu.org; Mon, 14 Sep 2009 02:26:22 -0400 Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate02.web.de (Postfix) with ESMTP id 08C7611F3803C for ; Mon, 14 Sep 2009 08:26:21 +0200 (CEST) Received: from [88.65.36.68] (helo=[192.168.1.10]) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #314) id 1Mn512-0007Ln-00 for qemu-devel@nongnu.org; Mon, 14 Sep 2009 08:26:20 +0200 Message-ID: <4AADE20B.4010702@web.de> Date: Mon, 14 Sep 2009 08:26:19 +0200 From: Jan Kiszka MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig292750443EF3AABAAAC7D5E0" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: Audio (fwd) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig292750443EF3AABAAAC7D5E0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable malc wrote: > On Sun, 13 Sep 2009, Jan Kiszka wrote: >> > malc wrote: >>> > > On Sun, 13 Sep 2009, Jan Kiszka wrote: >>> > >=20 >>>> > >> malc wrote: >>>>> > >>> The code was just commited that enables "polling" audio mode = (oss and >>>>> > >>> alsa), it's also unconditionally enabled now to obtain some t= esting >>>>> > >>> 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. >>> > >=20 >>> > > Few things: >>> > >=20 >>> > > Thanks for the patch, but i was at a loss how to properly apply i= t >>> > > with git and retain all the relevant information (Subject/Authorh= sip >>> > > etc), so for the time being it was applied manually. >> >=20 >> > Sorry, the patch was so trivial that I became sloppy. >> >=20 >>> > >=20 >>> > > In the past your mail server was bouncing my replies to threads w= here >>> > > 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. >> >=20 >> > Unless the bounce said "mailbox full": Just forward me a recent boun= ce >> > message privately (replace web.de with siemens.com). Typically I get= >> > wrong black-listings resolved with web.de within a day or less. >=20 > No it was something else, i'll forward this message to you to try and > get the bounce. Apparently, it works (again). >=20 >> >=20 >>> > >=20 >>> > > The Musicpal image i have here is getting stuck somewhere along t= he >>> > > way to the point of monitor not being responsive, so i can not te= st >>> > > anything myself. FWIW the command line is this: >>> > >=20 >>> > > [...]/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 >> >=20 >> > Hmm, this setup works for me (current master). Maybe you can catch w= hat >> > strace reports or which backtrace gdb generates. Does disabling poll= ing >> > or reverting before your changes make it boot again? >=20 > 930c86820e8e0b6dfcf211bda5e835463d72ff42 is what broke it for me, > Following "fixes" it: >=20 > 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=20 > queue_index) > uint8_t buf[2048]; > int len; > =20 > - > do { > + if (!desc_addr) return; > eth_tx_desc_get(desc_addr, &desc); > if (desc.cmdstat & MP_ETH_TX_OWN) { > len =3D desc.bytes; >=20 > [..snip..] >=20 > Now that i have musicpal working, i'll try to investigate things furthe= r. Hmm, I have a similar check in eth_receive, likely due to testing results (don't remember). I guess this one makes sense, too, and the issue was only uncovered by the refactoring. Will merge it into my queue.= Thanks, Jan --------------enig292750443EF3AABAAAC7D5E0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkqt4gwACgkQniDOoMHTA+kPCQCeJGU/G5h9X7Xps8MlnjBLEf1p 31oAn30fBqp1M0XfgpaD0H4GakD6B6mq =MtGO -----END PGP SIGNATURE----- --------------enig292750443EF3AABAAAC7D5E0--