Since DEUNA works, I more or less constantly have one or more boards running 2.11BSD. One of these has only been down twice since November 2 – the first time after three months when I accidentally touched the power switch while cleaning, and the other time last week when a transformer exploded across the street – close to 10.000 homes without power. So only two reboots since begin of November – and both because of power problems. I have current systems that do worse…
Not much has happened on new developments. Partly because my boards were all showing increasingly impressive uptimes, partly because I was not sure on what to do next – and, other priorities demanded a lot of time. What I did do was restructure the DEUNA microcode a bit to make it more robust. There were a couple of bugs in there as well – for instance, the bit in the control register that should cause a reset of the controller hardware actually didn’t. But a more major improvement is that it is now no longer fatal if the pmod becomes disconnected. The controller will just reconnect when the chip becomes available to it again, and continue where it left off.
There is one problem remaining in DEUNA that I’m aware of; very occasionally – so far, I’ve seen it happen 3 times in almost 6 months of running – 2.11BSD will start complaining that there are no free buffers. At the same time, activity on the blinkenlights show that there is something going on – more instructions appear to be processed than normal during idle-waiting. However, vmstat shows no unusual activity that I can detect. The solution is to ifconfig the interface down and up – and things will be normal again.
In the meantime, I’ve been thinking on what to do next – if anything. One item on the roadmap that is a bit overdue is the split disk controller – I mean, the change to the disk controller that allows the cpu to run while the sd cards are active. Would be useful to make this change – I expect that 2.11BSD and probably RSTS and RSX would benefit from the cpu being able to run during card activity, and thus become faster. But also interrupt response and clock stability would improve. The downside is that it is relatively boring work…
Another idea I have is to change my mind and implement the Qbus systems after all. The difficult bit there really is only that that would require a DEQNA – which shares surprisingly little with DEUNA, so it would be a lot of work. And there really is only one reason to do it – it would run Xinu.
Anyway. Summer is here, time to go out and play. But maybe it will rain some days.