[Bug 204426] Processes terminating cannot access memory

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Mon Feb 1 13:34:33 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204426

--- Comment #24 from rblayzor at inoc.net ---
(In reply to Konstantin Belousov from comment #23)

These VM's boot diskless and mount their root file system as RO. 

Trying to mount root from nfs: []...
NFS ROOT: 10.0.0.211:/vol/bsdroot/v0f


Where "v0f" is nothing more than subdir for a new rootfs.  "bsdroot" is just a
NetApp volume RO volume from these hosts.


There is a VMDK (virtual disk) that is mounted at boot time; which is a thin
provision disk 10GB in size.  2GB a 2Gbps swap partition and a 8Gb scratch disk
for things like /var or /var/tmp


da0 at mpt0 bus 0 scbus0 target 0 lun 0
da0: <VMware Virtual disk 1.0> Fixed Direct Access SCSI-2 device
bootpc_init: wired to interface 'vmx0'
da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit)
da0: Command Queueing enabled
da0: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C)
da0: quirks=0x40<RETRY_BUSY>


The port binaries are built on a another FreeBSD 10.2 platform (same VM config)
and then we rsync /usr/local to be part of the rootfs.

We always keep the port builds and the base system fresh and in sync. Typically
when we want roll out a new version of FreeBSD we'll upgrade the build VM
first, then create a new subdir for rootfs and install there. Followed by a
complete port rebuild and resync. This has always worked for us since FreeBSD
8.x just fine...


Only recently we've seen these random, strange, unexplainable core dumps.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-threads mailing list