Possible kqueue related issue on STABLE/RC.
olgeni at olgeni.com
Wed Sep 11 16:01:24 UTC 2013
On Wed, 11 Sep 2013, Volodymyr Kostyrko wrote:
> 11.09.2013 18:07, Jimmy Olgeni wrote:
>> Perhaps I found something weird while running 9.2-RC3 FreeBSD
>> 9.2-RC3 #0 r255393 (ZFS-only setup).
>> Unfortunately I'm not able to get a minidump for the latest RC, but at this
>> point I suspect that something is going on with glib20 and kqueue on both
>> -STABLE and -RC.
> Can you spare some more info on this?
Sure, here it goes:
> 1. What is your /etc/src.conf and /etc/make.conf files?
PORTS_MODULES=emulators/virtualbox-ose-kmod sysutils/fusefs-kmod sysutils/pefs-kmod x11/nvidia-driver
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
> 2. Does your copy of sources has some third-party patches applied?
No extra patches were applied. For the RC tests I also removed the
whole /usr/src and checked it out from svn from scratch.
Currently I have this kernel config:
device crypto # core crypto support
device cryptodev # /dev/crypto for access to h/w
device enc # IPsec interface.
options DDB # Enable the ddb debugger backend.
options IPSEC # IP security (requires device crypto)
options IPSEC_NAT_T # NAT-T support, UDP encap of ESP
options IPSEC_FILTERTUNNEL # filter ipsec packets from a tunnel
options SC_DFLT_FONT # compile font in
options SC_HISTORY_SIZE=512 # number of history buffer lines
options VGA_WIDTH90 # support 90 column modes
options RACCT # Resource Accounting
options RCTL # Resource Limits
# altq(9). Enable the base part of the hooks with the ALTQ option.
# Individual disciplines must be built into the base system and can not be
# loaded as modules at this point. In order to build a SMP kernel you must
# also have the ALTQ_NOPCC option.
options ALTQ_CBQ # Class Bases Queueing
options ALTQ_RED # Random Early Detection
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical Packet Scheduler
options ALTQ_CDNR # Traffic conditioner
options ALTQ_PRIQ # Priority Queueing
options ALTQ_NOPCC # Required for SMP build
Also, my loader.conf:
> 3. Does this happens on more than one PC i.e. are you sure hardware
> is not involved?
First thing I thought of was either memory or the CPU temperature.
Right now I have only one PC available to test it, but:
- Memory looks ok, at least according to Memtest86/Memtest86+ (tested
from Ultimate Boot CD)
- CPU looks ok, meaning that it can process heavy workloads without a
problem. I tried with dev.cpu.0.freq=2200 to avoid overheating, and
by starting 4 different poudriere builds with -J2. I have CPU
temperature in the prompt and it hovers aroung 50C during the
builds. Without gvfs it works just fine. Running buildworld always
seems to work; also running sysutils/stress (stress -v -t 5m --cpu 8
--io 4 --vm 2 --vm-bytes 128M --hdd 4) did not seem to bother the
- ZFS scrub says that it's all OK on the storage side (initially I
thought about something going wrong with ZFS due to bad tuning).
> Can you try to build world WITH_CLANG_IS_CC? Clang generated code is
> known to produce an instant coredump in situations where gcc
> generated code hits a loop or becomes unresponsive.
I'm rebuilding a r255473 using WITH_CLANG_IS_CC=yes right now (I also
removed ccache which is the only suspicious thing I could see in my
I'll give it a try as soon as it's done building.
More information about the freebsd-stable