On Tue, Mar 15, 2022 at 10:26:46AM -0700, Sathyanarayanan Kuppuswamy wrote:
On 3/15/22 10:14 AM, Eric Badger wrote:
# Prep injection data for a correctable error.Hmm, this differs from the procedure I described on v1, and I don't
$ cd /sys/kernel/debug/apei/einj
$ echo 0x00000040 > error_type
$ echo 0x4 > flags
$ echo 0x891000 > param4
# Root Error Status is initially clear
$ setpci -s <Dev ID> ECAP0001+0x30.w
0000
# Inject one error
$ echo 1 > error_inject
# Interrupt received
pcieport <Dev ID>: AER: Root Error Status 0001
# Inject another error (within 5 seconds)
$ echo 1 > error_inject
# No interrupt received, but "multiple ERR_COR" is now set
$ setpci -s <Dev ID> ECAP0001+0x30.w
0003
# Wait for a while, then clear ERR_COR. A new interrupt immediately
fires.
$ setpci -s <Dev ID> ECAP0001+0x30.w=0x1
pcieport <Dev ID>: AER: Root Error Status 0002
Currently, the above issue has been only reproduced in the ICL server
platform.
[Eric: proposed reproducing steps]
think will work as described here.
I have attempted to modify the steps to reproduce it without returning
IRQ_NONE for all cases (which will break the functionality). But I
think I did not correct the last few steps.
Well, the thinking in always returning IRQ_NONE was so that only setpci
modified the register and we could clearly see how writes to the
register affect interrupt generation.
How about replacing the last 3 steps with following?
# Inject another error (within 5 seconds)
$ echo 1 > error_inject
# You will get a new IRQ with only multiple ERR_COR bit set
pcieport <Dev ID>: AER: Root Error Status 0002
This seems accurate. Though it does muddy a detail that I think was
clearer in the original procedure: was the second interrupt triggered by
the second error, or by the write of 0x1 to Root Error Status?
Cheers,
Eric