The Linux kernel ipmi panic logger stores panic strings in SEL records
of type 0xf0, with a chunk sequence number in byte 4 and up to 11
characters of the message in bytes 5-15. ipmitool and freeipmi both
recognize this convention; do the same rather than presenting such
records as opaque non-timestamped OEM data.
Some BMCs (e.g. AMI) log events using spec-reserved record types like
0x04 with a standard system event record layout. Previously only type
0x02 was decoded, leaving such entries with no usable data and tripping
the generic OEM handler. Follow ipmitool and treat all types below 0xc0
as standard format. If the body of a reserved type turns out not to
follow the standard layout, fall back to passing it through raw instead
of aborting the whole log retrieval.
Since it turns out we already incurred lxml dependency, use lxml etree instead of xml and mitigate risky xml features beyond blocking the word '!entity'
Do not continue waiting when session is broken.
Do not call _timedout without releasing the lock first.
Properly await on relog with bad rakp4
If an accounting issue pushes logontries too far without touching zero, then still recognize retries were exhausted.
Timeout on missing RAKP2 if retries were already exhausted.
Drop python3-eventlet from the Ubuntu Noble build Dockerfile. Clean up
remaining greenthread/greenlet terminology in comments across aiohmi
IPMI modules, consoleserver, macmap, and the IPMI plugin. Remove a
commented-out GreenPool reference in macmap.
Replace eventlet.greenpool with concurrent.futures.ThreadPoolExecutor
in the BMC discovery script, using as_completed() for proper exception
propagation and main-thread result aggregation to avoid race conditions.
Remove dead eventlet socket compatibility code (.fd attribute checks)
from the IPMI session layer, and clean up stale eventlet references
in comments across the codebase.
Closes: xcat2/confluent#197
Markus Hilger
Jarrod Johnson
gosforthcross
Jarrod Johnson
Vinícius Ferrão