diff options
| author | Eric van Gyzen <vangyzen@FreeBSD.org> | 2021-04-26 15:01:17 +0000 |
|---|---|---|
| committer | Eric van Gyzen <vangyzen@FreeBSD.org> | 2021-04-30 18:32:29 +0000 |
| commit | 2f32a971b7f936170b4d61318238e6cf89f198b5 (patch) | |
| tree | 3f62a17d8816bce7194c88b1ce63a4017a840e77 /sys/arm64 | |
| parent | eda28feb2e070e21db3d50b3fc177f88380b8fb4 (diff) | |
| download | src-2f32a971b7f936170b4d61318238e6cf89f198b5.tar.gz src-2f32a971b7f936170b4d61318238e6cf89f198b5.zip | |
Wait longer for a previous IPI to be sent
When sending an IPI, if a previous IPI is still pending delivery,
native_lapic_ipi_vectored() waits for the previous IPI to be sent.
We've seen a few inexplicable panics with the current timeout of 50 ms.
Increase the timeout to 1 second and make it tunable.
No hardware specification mentions a timeout in this case; I checked
the Intel SDM, Intel MP spec, and Intel x2APIC spec. Linux and illumos
wait forever. In Linux, see __default_send_IPI_shortcut() in
arch/x86/kernel/apic/ipi.c. In illumos, see apic_send_ipi() in
usr/src/uts/i86pc/io/pcplusmp/apic_common.c. However, misbehaving hardware
could hang the system if we wait forever.
Reviewed by: mav kib
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D29942
Diffstat (limited to 'sys/arm64')
0 files changed, 0 insertions, 0 deletions