Patrick Welche wrote:
>or running memtest86+ (http://www.memtest.org/)? (at least a failure here
>proves its memory)

Yes, but that would not explain why faults happen relatively frequently and
quick with /bin/sh, significantly less frequently and later with /bin/ksh,
and apparantly not at all with /usr/pkg/bin/bash (which, OTOH, takes ages
to complete.)

And it would take Memtest86+ several days to test the RAM sufficiently, if
my experience with the 512 MB block can be scaled. Now, after I have done a
few more tests, I have just started the Memtest run, as I will not have
much time to play with the machine over the next few days anyway.

But I have investigated a bit more and found this:
Able (1.3 GHz Celeron M, 1.3 GB RAM, NetBSD 3.0, PATA disk):
bash:  5605.90s real  2666.34s user  2765.02s system
bash:  5671.62s real  2666.94s user  2775.07s system (did it twice!)
sh: 4091.01s real  1343.61s user  1391.10s system
ksh: 4323.78s real  1516.52s user  1551.51s system

Dog: (1.83 GHz Core2Duo, 2 GB RAM, 4.0BETA):
GENERIC.MP_ACPI
PATA, bash: 26364.83s real  8364.41s user 47230.28s system
SATA, bash: 25190.26s real  7773.60s user 44884.46s system
PATA, ksh: 3942.45s real  1192.03s user  1361.32s system
SATA, ksh: 2988.08s real  1190.92s user  1322.87s system
PATA, sh: 3739.43s real  1069.15s user  1208.55s system
SATA, sh: 2840.94s real  1074.28s user  1167.69s system
(Note: ksh and sh times are after a reboot after doing the non-ACPI tests.
They did crash several times each, but I managed to get them to complete
a couple of times.)

GENERIC.MP
PATA, bash: 25610.71s real  8583.62s user 42820.80s system
(I sure as hell won't waste another 7 hours with bash on the SATA again)
PATA, sh: 3964.14s real  1054.54s user  1230.40s system
SATA, sh:  3036.48s real  1049.06s user  1222.08s system
PATA, ksh: 4093.64s real  1157.11s user  1384.34s system
SATA, ksh: 3205.21s real  1149.68s user  1379.90s system

It seems it is fair to conclude that even with a well-behaved
system, bash is notably slower than ksh, which in turn is marginally
slower than sh.

On the 4.0 BETA Core2Duo system, however, something is definitely very
wrong. Bash's performance is abysmal, wheras sh and ksh perform like on
the Celeron, indicating that it is the PATA disk which is the bottleneck for
them. The SATA is a wee bit faster.

What could possibly be the cause of bash's behaviour? I am tempted to
install NetBSD 3 on the machine, and see what that makes of it.

There may be a RAM defect, but it sure doesn't manifest itself very often.
And I doub't that it could explain the rotten times from bash. On the other
hand, the problem that makes bash run slow, just might be related to whatever
makes the ksh and sh versions crash now and then. It is interesting that the
non-ACPI kernel didn't seem to crash as frequently as the ACPI kernel. It
is also interesting that after rebooting the MP_ACPI kernel, I managed to
get the script to complete a few times where it had failed quite consistently
before.

Come to think of it, I have the exact same build of bash (together with the
same version of 4.0BETA) on an old slow K6-2 450 MHz. I think I should boot
that up tomorrow and see how the script works there. It would rule out any
problem related to NetBSD and bash versions.

I'll let you all know how it goes. I just hope I am not boring anyone. Am
I really the only NetBSD user using the ASRock ConRoe945G-DVI motherboard?

-Lasse