<div dir="ltr"><div>I'll see what I can find.<br><br></div>At the time I created this patch I had it reproducing more often, but not often enough to trace a cause.<br><div class="gmail_extra">The patch seems to help, but [as you've said] the error seems like something else.<br>

</div><div class="gmail_extra"></div><div class="gmail_extra">Seems to be reproducing again, after a while, and in a certain configuration.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I'll check it out.<br>

</div><div class="gmail_extra">This high CPU usage thing got to annoy me enough that I gave it a bit more attention.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks<br>Alex<br></div><div class="gmail_extra">

<br><div class="gmail_quote">On Tue, Jul 29, 2014 at 4:30 PM, Felix Fietkau <span dir="ltr"><<a href="mailto:nbd@openwrt.org" target="_blank">nbd@openwrt.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="">On 2014-07-29 15:23, Alexandru Ardelean wrote:<br>
> Quick info follow-up:  strace-ing on the PIDs (with high CPU usage)<br>
> shows a lot of EAGAIN errors from recvfrom() and a lot of recvfrom() +<br>
> poll() + clock_gettime_monotonic() calls.<br>
><br>
> Thinking about it, would it make more sense to add a short wait instead<br>
> [to reduce the throttle] and let it "infinitely" loop ?  ["infinitely"<br>
> loop == loop until it does not error with EAGAIN]<br>
</div>I think it's much more likely that this is a bug, caused by errors on<br>
the ubus socket not being caught or handled properly.<br>
If that is the case, then both approaches are wrong, and we should just<br>
handle the error correctly.<br>
Can you figure out what triggers this behavior?<br>
<span class="HOEnZb"><font color="#888888"><br>
- Felix<br>
</font></span></blockquote></div><br></div></div>