Re: netbsd-6 instability - vmem

[Dave B <spam%y2013.dberg.net@localhost>]

On Thu, Jan 31, 2013 at 12:41:00PM -0500, Greg Troxel wrote:
> 
> It's interesting that you have IPSEC in the kernel ("IPSEC" or
> "FAST_IPSEC"?), and are using WAPBL.

  "IPSEC" yes, "FAST_IPSEC" no.  And "INET6" is in my kernels, too;
but I make essentially no use of actual ipv6 traffic.

  Oh, there are two more factors that may be highly relevant which
I forgot about in my original description; on the macppc only:

 o  /tmp is mounted "async" on a file-backed, vnconfig'ed device
 o  an external USB2 drive is one of the devices of the RAID

however, these factors weren't a problem under NetBSD 5.x.

> If you can afford the crashes, it would be interesting to see if:
> 
>   you can provoke lockups with "find / -type f > /dev/null", or
>   perhaps "| xargs ls -l > /dev/null"

  Surprisingly, I couldn't.  The pipeline ran to completion; so I
tried the same thing while also compressing a 300+MiB file with
"lzip -v9e -m 100" at the same time.  That provoked the lockup.
No reboot from swwdog.

>   if disabling WAPBL results in a stable system

  Removing "log" from the fstab mount options, rebooting and
re-trying didn't stop a lockup from happening.

  A GENERIC kernal rendered the system unbootable, due at least to
missing cgd, so I didn't get to try that.

  Trying a kernel with DIAGNOSTIC, LOCKDEBUG and IPSEC_DEBUG added
in didn't stop a lockup from happening, but the system rebooted
itself after it locked--and comparatively quickly--so it may have
panic'ed, rather than having been rebooted by swwdog.

>   if removing IPSEC from the kennel results in a stable system
...

  Unfortunately, it didn't.  I left DEBUG, DIAGNOSTIC, LOCKDEBUG
enabled in the no IPSEC kernel.  I guess I'll make another attempt
with those three commented back out again as well as no IPSEC.

  If that doesn't yield a different result, I'll probably try
commenting WAPBL out of the kernel as opposed to just removing the
"log" options from fstab.

-D