-- Tom M
On Sun, Oct 20, 2024 at 08:02 Muni Sekhar <munisekhar...@gmail.com> wrote: > On Sun, Oct 20, 2024 at 6:18 PM Denis Kirjanov <kirja...@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@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
