<div><br clear="all"><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">  --<br>Tom M</div></div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 20, 2024 at 08:02 Muni Sekhar <<a href="mailto:munisekharrms@gmail.com">munisekharrms@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto">On Sun, Oct 20, 2024 at 6:18 PM Denis Kirjanov <<a href="mailto:kirjanov@gmail.com" target="_blank">kirjanov@gmail.com</a>> wrote:<br><br>
>><br>
>> Analysis:<br>
>> The soft lockup seems to be caused by the continuous while loop in the<br>
>> empty_rx_fifo() function. The RX FIFO takes a considerable amount of<br>
>> time to empty, sometimes up to 1000 seconds. As a result, from the<br>
>> first occurrence of </blockquote><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
><br>
>  I guess that you can switch on interrupt model or run a thread to check the status there (here I mean check RX empty and release cpu)<br>
Thanks for your response.<br>
<br>
Switching to an interrupt model should resolve it, but unfortunately,<br>
the hardware I am using does not support interrupts for this<br>
functionality.<br>
Would adding udelay() in the while loop after every few iterations<br>
help avoid CPU hogging, allowing other processes to take control of<br>
the CPU?<br>
<br>
><br>
>> 2. Do soft lockup issues auto-recover like this? Is this something I<br>
>> should consider serious, or can it be ignored?<br>
><br>
><br>
> The kernel tells you that your cpu resource is stuck instead of doing something useful<br>
><br>
>><br>
>> I would appreciate any guidance on how to resolve or mitigate this problem.<br></blockquote><div dir="auto"><br></div><div dir="auto">Do as little you can to drain the FIFO into a buffer (one of three).</div><div dir="auto">How deep is  the FIFO?</div><div dir="auto">Set a data flow block when the second is full.  </div><div dir="auto">Do the math on the data rate the device delivers.  </div><div dir="auto">Then add an interruptible thread to process the buffer ( shift and what ever) </div><div dir="auto"><br></div><div dir="auto">A udelay() can allow other work to proceed and can be a good thing.</div><div dir="auto"><br></div><div dir="auto">A user space driver pinned to a dedicated core can also work.</div><div dir="auto"><br></div><div dir="auto">Interrupts can  be costly.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div></div>