> Hmm I'm running ipfwadm 2.3 and under 2.0.{8,1[0123]}, my production box
> developes a memory leak after 5 to 8 hours in the kernel.. System goes
> into terminal swap and loadavg goes through the roof. Resulting in a
> forced reboot... It doesn't happen on my other systems and I'm not
> running ipfwadm (and alot of other things) on those either...
>
> Let's start tracking this bit flip down.. it might be the same problem
> with different results.
FWIW I will add my recent experience with a problem that, to me, sounds
similar. I added a 16mB SIMM to my previously 8mB (4+4) system and soon
began having trouble launching X app.s. Some would *always* work, and
some would *always* segfault. Boot the system and a different set
fails. Another time a large make started dying because the compiler had
trouble finding itself.
My first thought was, of course, that the new memory was bad. However,
the kids run Windows on this same box without any trouble (other than the
usual Windows crocks :-), and the memory has passed:
o the POST test (which seems to be pretty thorough since it takes so
long);
o whatever tests HIMEM.SYS does; and
o several passes with DiagSoft's QAPLUS.
During one episode the box logged a number of the following:
Jul 30 19:11:39 woodshed kernel: do_wp_page: bogus page at addresss
bfffdda8 (55057000)
Jul 30 19:35:00 woodshed kernel: do_wp_page: bogus page at address
bfffddb8 (4572c000)
The box is a DECpc LPx 433 (uses 72-pin parity SIMMs). I'm thinking that
if I were getting bad memory data, there would be memory-bus parity
failure logout data accumulating somewhere, but I haven't found it.
Is this relevant to the current discussion? Is there more memory
diagnostic information I can turn on? Anybody know a good memory tester
that just runs until I tell it to stop and logs any failures *thoroughly*?
(QAPLUS stops after each pass.)
Mark H. Wood, Lead System Programmer MWOOD@INDYVAX.IUPUI.EDU
Those who will not learn from history are doomed to reimplement it.