On 2021-09-11 18:46:57 (+0900), Takashi Sakamoto wrote: > 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@xxxxxxxxxxxxx/ > > 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. Thanks at any rate to look into this! It is much appreciated! Is there anything further I can try to debug this using threadirqs? It would be really amazing to be able to use this device on PREEMPT_RT again (especially given that now the ALSA driver has improved so drastically). :) Best, David -- https://sleepmap.de
Attachment:
signature.asc
Description: PGP signature
