Darren Reed writes:
> In some mail from Frank van der Linden, sie said:
> > On Thu, Nov 02, 2000 at 12:53:32PM +0100, Anders Magnusson wrote:
> > > The vgonel panic happens very often on a production machine we have here.
> > > Is there anyone that knows more about this area of the kernel that can
> > > give me some hints about what to search for?
> > 
> > Does it give exactly the same traceback? Are you using nullfs or any
> > other layered fs?
> > 
> > - Frank
> 
> FWIW, Frank, the RAM in my laptop which caused this panic is suspect.

At which point, I say we'd pretty much have to ignore your problem
request then.

I started having raidframe flakiness on my (old) server a month ago,
after some software & hardware maintenance (I upgraded the kernel and
plugged in the parallel printer cable into the m/b). The machine also
Sig 11-ed a lot during compilation after that point. I haven't managed
to get any form of raidframe problem on another machine which has been
hammered more, so I decided to suspend my PR because I don't think it's
netbsd's fault at this stage.

Another random h/w flakiness anecdote: my recently purchased server
was flaky (damn pc h/w); I swapped the m/b and cpu for a totally
different model/type, and still the issue. It turned out to be RAM.
On my wife's workstation, which has been flaky under W2K for a few
months. Again, it turned out to be RAM. In both cases I had run a
memory tester called `memtest/x86' (or something like that) which is a
Linux bootdisk with an application to do various memory tests on it,
for over 12 hours each, and not *one* problem was found. Running
NetBSD on the new server and running `bonnie' multiuser would
repeatedly panic the machine when the dodgy simm was in. I have a
feeling that a lot of RAM problems probably don't trigger by doing raw
memory walks; maybe you need to be hitting other things on the machine
at the same time.

Enough ramblings for now...

Luke.