malc wrote:
> 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.

Apparently, it works (again).

> 
>> > 
>>> > > 
>>> > > 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.

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