Michael's patch from 1999-08-18 seems to have solved the IRQ problem I was suffering from previously. I can now do lots of heavy NFS with no problems at all.
But I now have different problems, of course ...
Unfortunately the latest symptoms are very vague and various. I've had spontaneous reboots, I've had the machine just stop, uninterruptible by GDB, I've had various assertions fail in Fiasco, I've had an assertion fail in Linux ("reply_and_wait error", l4_idle.S:564). Some of the failed assertions in Fiasco seem inexplicable except by something scribbling on memory as they involve bits of the scheduling code which seem simple enough not to fail only in rare circumstances. Most of the fatal events are not repeatable and have only happened to me once, but there are three things that I have seen several times:
(1) The Fiasco assertion about stack space (thread.cc:316) has failed several times.
(2) Frequently cc1 segfaults when compiling a large file. Annoyingly, it hasn't done it since I built one with debugging symbols.
(3) The following C code causes massive strafing[1] of the disc which I can terminate only by rebooting as the process seems to ignore all signals.
{ unsigned char a[4096*1024]; int i; unsigned char c;
for (c = 0; ; c++) { for (i = 0; i < sizeof(a); i += 4096) a[i] = c; } }
On one occasion cc1 gave the same behaviour.
Can anyone tell me if this behaviour is a bug? It might just be a "limitation" of L4-Linux, in which I'm in trouble, because it's the only nasty behaviour which I can reproduce in a simple way.
I only have 8 MB of memory, by the way, so the code above is expected to exercise the disc. I just don't expect it to be unkillable. A program that mallocs lots of 4000-byte blocks doesn't become unkillable in the same way.
Edmund
[1] My trusty old 100 MB disc does sound a bit like a machine gun when there is a lot of swapping going on.