Re: firewire-ohci fails to initialize Texas Instruments XIO2213A/B/XIO2221 based controller on realtime kernels [5.4.91-rt50, 5.10.8-rt24]

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

Hi,

On Fri, Sep 10, 2021 at 01:55:41PM +0200, Sebastian Andrzej Siewior wrote:
> On 2021-09-08 11:17:18 [+0900], Takashi Sakamoto wrote:
> > Hi,
> Hi,
> 
> > According to the log, the task of 'pipewire-media-:2554' is blocked during
> > 122 seconds by call of 'wait_for_completion()' in code of
> > 'fw_run_transaction()'. This is odd in two points of transaction service
> > programmed in Linux FireWire subsystem:
> > 
> > 1. The process context should be awakened by softIRQ context, which should
> >    be scheduled by hwIRQ context for hardware interrupt of OHCI 1394
> >    controller.
> > 2. Even if the softIRQ context is not invoked, the process context
> >    should be awakened by wheel timer context, which is scheduled to finish
> >    the transaction several jiffies later (originally prepared for the case
> >    of split-transaction). In the case, the result of transaction is
> >    'RCODE_CANCELLED'.
> 
> 
> Side note: David is using PREEMPT_RT and his problem can be reduced to
> plain vanilla with `threadirqs' boot option. Back in February I sent him
> a patch [0] which inlines the tasklet job as I assumed it is not good
> reset the IRQ-event in the tasklet/workqueue. It seemed to improve the
> situtation as it recognized the device attached to the bus but ended
> then in the same timeout behaviour as now.
> 
> [0] https://https://lkml.kernel.org/r/.kernel.org/all/20210218083849.iitcrhdgv2oajfhv@linutronix.de/

Thanks for the side note, and I apologize to follow the thread partially,
not entire.

Furthermore, I'd like to correct my misunderstanding about the 2nd point
since the timer wheel context is scheduled only when the peer of
transaction transfer ack_pending for the request subaction. Without the
hwIRQ context, the task is blocked ever anyway.


Regards

Takashi Sakamoto