diff options
author | tegge <tegge@FreeBSD.org> | 2000-08-06 00:04:03 +0000 |
---|---|---|
committer | tegge <tegge@FreeBSD.org> | 2000-08-06 00:04:03 +0000 |
commit | a83353f91aca54c41c4c861b026dd2e1c2a95cbe (patch) | |
tree | c658601adae58dd16d10f4d10628de7a07fed3e9 /bin/sh | |
parent | 38baa3d84afacf843e0afcd466775444d5ef58a0 (diff) | |
download | FreeBSD-src-a83353f91aca54c41c4c861b026dd2e1c2a95cbe.zip FreeBSD-src-a83353f91aca54c41c4c861b026dd2e1c2a95cbe.tar.gz |
Be more verbose when changing APIC ID on an IO APIC.
Don't allow cpu entries in the MP table to contain APIC IDs out of range.
Don't write outside array boundaries if an IO APIC entry in the MP table
contains an APIC ID out of range.
Assign APIC IDs for all IO APICs according to section 3.6.6 in the
Intel MP spec:
- If the current APIC ID on an IO APIC doesn't conflict with other
IO APICs or CPUs, that APIC ID should be used. The copy of the MP
table must be updated if the corresponding APIC ID in the MP table
is different.
- If the current APIC ID was in conflict with other units, the
corresponding APIC ID specified in the MP table is checked for conflict.
- If a conflict is still found then fall back to using a new unique ID.
The copy of the MP table must be updated.
- IDs out of range is considered to be in conflict.
During these operations, the IO_TO_ID array cannot be used, since any
conflict would have caused information loss. The array is then corrected,
since all APIC ID conflicts should have been resolved.
PR: 20312, 18919
Diffstat (limited to 'bin/sh')
0 files changed, 0 insertions, 0 deletions