On Wed, Jun 21, 2023 at 2:33 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > More importantly, the busy timeout work never gets to run, which > > indicates that we are no longer hanging and waiting for an IRQ to be > > raised. Is that correct? > > Ehh, I should have looked more closely at the log. Indeed there is one > case where the timeout work kicks in. Yeah... It wasn't until I added the timeout that I could get the whole thing to work, both are needed: handling lost IRQs and then an occasional timeout. > Maybe we should log the information about the current ->busy_state at > that point too, so understand under what condition we are hanging? I > think we should also log the actual used timeout in this case. Sure thing, please merge this patch as-is (solves a problem!) and I try to make a debug improvement patch on top with what I have (like printing the command) and add in the busy state as well. Yours, Linus Walleij
