[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: netbsd-6 instability - vmem
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.
Main Index |
Thread Index |