Date: Wed, 11 Sep 2013 18:01:13 +0200 (CEST) From: Jimmy Olgeni <olgeni@olgeni.com> To: Volodymyr Kostyrko <c.kworr@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <alpine.BSF.2.00.1309111738480.37868@localhost.my.domain> In-Reply-To: <52308D30.6020502@gmail.com> References: <alpine.BSF.2.00.1309111705460.89324@olgeni.olgeni> <52308D30.6020502@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? My /etc/src.conf: === PORTS_MODULES=emulators/virtualbox-ose-kmod sysutils/fusefs-kmod sysutils/pefs-kmod x11/nvidia-driver === My /etc/make.conf: === APACHE_PORT=www/apache22 DEFAULT_PGSQL_VER=92 WITH_NEW_XORG=yes PERL_VERSION=5.14.4 .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) .if !defined(NOCCACHE) CC:= /usr/local/libexec/ccache/world/cc CXX:= /usr/local/libexec/ccache/world/c++ .endif .endif === > 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: === include GENERIC ident RELENG_9 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 makeoptions SC_DFLT_FONT=cp437 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 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 options TEKEN_UTF8 === Also, my loader.conf: === autoboot_delay="5" kern.cam.ada.legacy_aliases="0" kern.cam.scsi_delay="1500" net.inet.ip.fw.default_to_accept="1" vm.pmap.pg_ps_enabled="1" ahci_load="YES" ipmi_load="YES" zfs_load="YES" geom_uzip_load="YES" hw.memtest.tests="0" hw.usb.no_pf="1" vm.kmem_size_max="16G" vm.kmem_size="12G" vfs.root.mountfrom="zfs:rpool/zfsroot" vfs.zfs.write_limit_override="1536M" vfs.zfs.txg.synctime_ms="750" vfs.zfs.vdev.min_pending="1" vfs.zfs.vdev.max_pending="1" kern.ipc.semmns="512" kern.ipc.semmnu="256" kern.ipc.shmmni="256" kern.ipc.shmseg="256" nvidia_load="YES" vboxdrv_load="YES" amdtemp_load="YES" snd_hda_load="YES" hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1" === sysctl.conf: === debug.kdb.break_to_debugger=1 hw.snd.default_unit=2 kern.coredump=0 kern.ipc.shm_allow_removed=1 kern.ipc.somaxconn=4096 kern.maxfiles=25000 kern.maxvnodes=250000 kern.ps_arg_cache_limit=10000 kern.sched.preempt_thresh=224 machdep.kdb_on_nmi=0 machdep.panic_on_nmi=0 net.inet.icmp.log_redirect=0 net.inet6.ip6.v6only=0 net.link.ether.inet.log_arp_movements=0 vfs.hirunningspace=5242880 vfs.read_max=128 vfs.ufs.dirhash_maxmem=33554432 vfs.usermount=1 vfs.zfs.prefetch_disable=1 === > 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 system. - 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 make.conf). I'll give it a try as soon as it's done building. -- jimmy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1309111738480.37868>