Assistance Needed for Kernel mode driver Soft Lockup Issue

[Tom Mitchell]

--
Tom M


On Sun, Oct 20, 2024 at 08:02 Muni Sekhar <munisekharrms at gmail.com> wrote:

> On Sun, Oct 20, 2024 at 6:18 PM Denis Kirjanov <kirjanov at gmail.com> wrote:
>
> >>
> >> Analysis:
> >> The soft lockup seems to be caused by the continuous while loop in the
> >> empty_rx_fifo() function. The RX FIFO takes a considerable amount of
> >> time to empty, sometimes up to 1000 seconds. As a result, from the
> >> first occurrence of




> >
> >  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)
> Thanks for your response.
>
> Switching to an interrupt model should resolve it, but unfortunately,
> the hardware I am using does not support interrupts for this
> functionality.
> Would adding udelay() in the while loop after every few iterations
> help avoid CPU hogging, allowing other processes to take control of
> the CPU?
>
> >
> >> 2. Do soft lockup issues auto-recover like this? Is this something I
> >> should consider serious, or can it be ignored?
> >
> >
> > The kernel tells you that your cpu resource is stuck instead of doing
> something useful
> >
> >>
> >> I would appreciate any guidance on how to resolve or mitigate this
> problem.
>

Do as little you can to drain the FIFO into a buffer (one of three).
How deep is  the FIFO?
Set a data flow block when the second is full.
Do the math on the data rate the device delivers.
Then add an interruptible thread to process the buffer ( shift and what
ever)

A udelay() can allow other work to proceed and can be a good thing.

A user space driver pinned to a dedicated core can also work.

Interrupts can  be costly.




> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20241020/517bcdb0/attachment.html>