[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90777da90abe02c87d30968bfedc9168@linux.ibm.com>
Date: Wed, 19 Mar 2025 21:58:54 -0500
From: Wen Xiong <wenxiong@...ux.ibm.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org, gjoyce@...ux.ibm.com
Subject: Re: [PATCH 1/1] genirq/msi: Dynamic remove/add stroage adapter hits
EEH
> The real problem has nothing to do with a remove/add operation. The
> problem is solely in the probe function.
Hi Thomas,
Thanks for your suggestion!
I don't think we have problems in probe function since this driver has
been in productions for many many years.
Also we didn't see the issue before the "MSI domain" patchset dropping
into linux interrupt code(no issue in rhel92 release).
Device reset is not called in probe function. We don't see the issue
without dynamically remove/add operation.
There is a small window which irqbalance daemon kicks in during device
reset. So it took about over 6 hours to recreate the issue when doing
remove/add loop operation.
We can't find the good way to fix the issue in both of device drivers.
So we look for some help in interrupt code.
Looks each irq_data has a state(IRQD_AFFINITY_MANAGED), Can we play this
flag during the reset in device driver?
* IRQD_NO_BALANCING - Balancing disabled for this IRQ
* IRQD_AFFINITY_ON_ACTIVATE - Affinity is set on activation. Don't
call irq_chip::irq_set_affinity() when deactivated.
OR
If we registered an affinity notifier in device driver, can this tell us
the msix vector has been clear to 0 when irqbalance daemon kicks in?
Thank you so much, I really appreciate any suggestion/help!
Wendy
Powered by blists - more mailing lists