Closed pkoning2 closed 11 months ago
It turned out that the task monitor was not given much space to store task info (it collects all the task info for a given CPU at once before displaying it, and the NTP client requires quite a few tasks overall), so it was crashing because it was overwriting the task structure (which generally causes Bad Things to happen that may involve wedging the system hard enough that control-C/Reboot will not reboot it). My solution was to give the task monitor more space to store task info in (2048 bytes rather than the 320 bytes previously, which may be adjusted prior to starting the task monitor with monitor::monitor-dict-space!
.
I am making a new release, 1.3.3.3, to address this and some other bugs I found in task::dump-tasks
, which is used by the task monitor, right now.
I've put out release 1.3.3.3, which should fix this issue.
It does, thanks!
I tried out the SNTP client and it works fine. But then I decided to see how it shows up in the task monitor. The answer is: it breaks the task monitor. Test procedure: load the ntp module and the ntp test program. Start the monitor. Confirm it's working by sending attention-t. Start the NTP client, which works. (I slightly tweaked it by setting its repeat interval to 10 seconds, and subtracting
ntp-internal::secs-between-1900-and-1970
from the reported time to make it a Unix time.) I then entered attention-t again. That produced the monitor header but nothing further, and things are hung. When I run that test in zeptocom, it is sufficiently stuck that the "Reboot" signal has no effect.