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.
