Re: Fwd: Adding timeouts to device access?

Hi,

On Mon, Jun 30, 2025 at 12:10:15AM +1000, ‍小太 wrote:
> On Mon, 30 Jun 2025 at 00:01, Takashi Sakamoto <[email protected]>
> wrote:
> 
> >
> > Two kernel messages are in your first post. The first one records that
> > the system does not execute interrupt service routine for hardIRQ which
> > should be triggered against any command request to transfer asynchronous
> > packet
> > when retrieving the detected node device. The second one records that the
> > reference count of fw_card instance could not reach zero even if waiting so
> > long when modprobe(8) executes the delete_module system call.
> >
> 
> Would it make sense to convert the wait_for_completion()
> to wait_for_completion_timeout() in either case?
> Potentially could leak a reference count, but it's better than a hung task
> that prevents system shutdown...
> 
> 
> >
> > I guess the cause of later message is the lost of hardIRQ in the first
> > message, however, I would like you to compare timestamps for these
> > messages.
> 
> 
> IIRC the two backtraces came from two completely different boots of the
> kernel with different failure symptoms.
> So probably unrelated to each other (except for the non-responsive hardware)

Hm, these are independent...

If that's the case, the issue might be partly due to how the userspace
application is written. Typically, it is written not to call close(2) to
the file descriptor of FireWire character device even if either any
operations to it returns -ENODEV or it never receives the response of
asynchronous transaction.

The replacement by the kernel API to wait for any event with timeout is
a simple solution, if we can ignore the apparent leak of system resources.
Indeed, it is not preferable, you know.

I think what we should do now is to identify/estimate the cause of
the issue, especially for the incomplete transaction. At present, the
transaction service of Linux kernel relies on the corresponding
functionality on 1394 OHCI hardware. We assume that the hardware
notifies the completion of transaction (including both transmission
errors and timeout) by triggering IRQ (precisely the corresponding
software driver operates the hardware to work so).

If we need any software timeout to finish the transaction, it means that
the combination of hardware (I mean the 1394 OHCI hardware, AMD PCIe Root
Complex, AMD IO Hub, and so on) is enough lazy in the point. For
example, I know an issue related to the critical quirk of PCIe AMD Ryzen
PCIe functionality and the extention card with ASM108x/VT630x. AMD Ryzen
machine has a concern to handle old hardware. I guess that your issue is
similar to this kind of issue, somehow.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/firewire/ohci.c?id=ac9184fbb847


Regards

Takashi Sakamoto


_______________________________________________
mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/linux1394-devel