On Wed, Mar 5, 2025 at 2:35 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
> I guess the problem is that future patches rate limit the e1000e
> messages, and we really need to rate limit the pcieport message using
> the same e1000e ratelimit_state. We do know the Requester ID of the
> device, so maybe we could look up that ratelimit_state?
Yeah, the intent behind the patch is to simplify the ratelimiting logic.
If I accessed the ratelimit via aer_err_info, then the ratelimit would need
to be doubled.
> On Tue, Mar 04, 2025 at 05:04:21PM -0800, Jon Pan-Doh wrote:
> > Would a log suffice in that case (i.e. when aer_get_device_error()
> > returns 0)? Something along the lines of "{device} is not accessible
> > while processing (un)correctable error"
What are your thoughts on this? It adds the pcie port log in the
edge case described (with no loss of info) and doesn't require
changes to current ratelimit logic. Something like this (with more
fields filled in of course):
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 21cdf590b25e..bdfc7e8d6f0f 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1253,6 +1253,8 @@ static inline void
aer_process_err_devices(struct aer_err_info *e_info)
for (i = 0; i < e_info->error_dev_num && e_info->dev[i]; i++) {
if (aer_get_device_error_info(e_info->dev[i], e_info))
aer_print_error(e_info->dev[i], e_info);
+ else
+ pci_error(e_info->dev[i], "{device} is not
accessible while processing (un)correctable error");
}
for (i = 0; i < e_info->error_dev_num && e_info->dev[i]; i++) {
if (aer_get_device_error_info(e_info->dev[i], e_info))
Thanks,
Jon
