r459 THE mid-boot degradation root cause: the 8-slot VA-space table filled with dead clients' registrations and every new client after the 8th got no slotHEADmaster

Evidence (r466 boot, one battery): 23 distinct 'VA space 0x... page directory
... entries=4' registrations and ZERO 'VA space ... dropped' lines. The
guest driver does not always tear a client's VA space down (client exit,
crash, or a switch the RM emulation does not forward), so after eight
registrations svc.vas[] had no free slot: gsp_sema_service_vaspace_add
silently refused the new directory (the 'if (vs)' guard), svc_walk_vaspaces
kept walking only the dead clients' directories, and every walk of the new
client's VAs failed -> its CE copies returned rc=-2 forever ('sema-optrace
... rc=-2' x8151 in the r466 log; the 10th+ client of the boot: streams2
bad=32737, streams_events no output, smiley hung, and the same class on
r463/r465). This is the 'no launch stalls / no mid-boot degradation'
blocker.

Fix:
 - svc_vaspace_add evicts the least-recently-registered entry when the
   table is full instead of refusing (logged), and stamps every
   registration;
 - svc_walk_vaspaces orders the snapshot by registration stamp, newest
   first, so a live client's directory is the authority and a stale one
   (whose guest memory the driver has since reused) can only answer when
   the live directory cannot.

0 files changed, 0 insertions, 0 deletions