FreeBSD_stable_10 - Build #1851 - Still Failing
FreeBSD_stable_10 - Build #1851 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/1851/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/1851/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/1851/console Change summaries: 291456 by mav: MFC r290855: Increase reset assertion time from 10 to 100us. On my own tests I see no effect from this change, but I also can't reproduce the reported problem in general. PR: 127391 PR: 204554 Submitted by: s...@iranger.com The end of the build log: [...truncated 118396 lines...] --- depend_subdir_compile_et --- echo compile_et: /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libc.a /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libroken.a /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/usr.bin/compile_et/../../kerberos5/lib/libvers/libvers.a >> .depend --- tests.depend__D --- (cd /builds/FreeBSD_stable_10/tests/sys/fifo && make -f /builds/FreeBSD_stable_10/tests/sys/fifo/Makefile _RECURSING_PROGS= SUBDIR= PROG=fifo_misc DEPENDFILE=.depend.fifo_misc .MAKE.DEPENDFILE=.depend.fifo_misc depend) --- usr.sbin.depend__D --- --- aslcompiler.y --- m4 -P -I/builds/FreeBSD_stable_10/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler /builds/FreeBSD_stable_10/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y > aslcompiler.y --- dtparserlex.c --- lex -i -s -PDtParser -odtparserlex.c /builds/FreeBSD_stable_10/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/dtparser.l --- tests.depend__D --- --- .depend.fifo_misc --- rm -f .depend.fifo_misc CC='cc ' mkdep -f .depend.fifo_misc -a -std=gnu99 /builds/FreeBSD_stable_10/tests/sys/fifo/fifo_misc.c --- usr.bin.depend__D --- --- depend_subdir_cpio --- ===> usr.bin/cpio (depend) --- usr.sbin.depend__D --- --- dtparserparse.c --- yacc -d -pDtParser -odtparserparse.c /builds/FreeBSD_stable_10/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/dtparser.y --- usr.bin.depend__D --- --- depend_subdir_compress --- echo compress: /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libc.a >> .depend --- etc.depend__D --- --- usr.sbin.depend__D --- --- prparserlex.c --- lex -i -s -PPrParser -oprparserlex.c /builds/FreeBSD_stable_10/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/prparser.l --- etc.depend__D --- ===> etc (depend) --- tests.depend__D --- echo fifo_misc: /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libc.a >> .depend.fifo_misc (cd /builds/FreeBSD_stable_10/tests/sys/fifo && make -f /builds/FreeBSD_stable_10/tests/sys/fifo/Makefile _RECURSING_PROGS= SUBDIR= PROG=fifo_open DEPENDFILE=.depend.fifo_open .MAKE.DEPENDFILE=.depend.fifo_open depend) --- usr.bin.depend__D --- --- depend_subdir_cpio --- --- _sub.depend --- ===> usr.bin/cpio/tests (depend) --- usr.sbin.depend__D --- --- prparserparse.c --- yacc -d -pPrParser -oprparserparse.c /builds/FreeBSD_stable_10/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/prparser.y --- aslcompilerparse.c --- yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y --- tests.depend__D --- --- .depend.fifo_open --- --- etc.depend__D --- --- _sub.depend --- --- tests.depend__D --- rm -f .depend.fifo_open --- etc.depend__D --- ===> etc/newsyslog.conf.d (depend) --- tests.depend__D --- CC='cc ' mkdep -f .depend.fifo_open -a -std=gnu99 /builds/FreeBSD_stable_10/tests/sys/fifo/fifo_open.c --- usr.bin.depend__D --- (cd /builds/FreeBSD_stable_10/usr.bin/cpio/tests && make -f /builds/FreeBSD_stable_10/usr.bin/cpio/tests/Makefile _RECURSING_PROGS= SUBDIR= PROG=bsdcpio_test DEPENDFILE=.depend.bsdcpio_test .MAKE.DEPENDFILE=.depend.bsdcpio_test depend) --- etc.depend__D --- ===> etc/sendmail (depend) --- tests.depend__D --- echo fifo_open: /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libc.a >> .depend.fifo_open ===> tests/sys/file (depend) --- usr.bin.depend__D --- --- list.h --- --- usr.sbin.depend__D --- yacc: 89 shift/reduce conflicts. --- tests.depend__D --- (cd /builds/FreeBSD_stable_10/tests/sys/file && make -f /builds/FreeBSD_stable_10/tests/sys/file/Makefile _RECURSING_PROGS= SUBDIR= PROG=flock_helper DEPENDFILE=.depend.flock_helper .MAKE.DEPENDFILE=.depend.flock_helper depend) --- usr.sbin.depend__D --- --- dtparser.y.h --- ln -f dtparserparse.h dtparser.y.h --- depend_subdir_amd --- ===> usr.sbin/amd (depend) --- tests.depend__D --- --- .depend.flock_helper --- rm -f .depend.flock_helper CC='cc ' mkdep -f .depend.flock_helper -a -std=gnu99 /builds/FreeBSD_stable_10/tests/sys/file/flock_helper.c --- usr.sbin.depend__D --- --- depend_subdir_include --- ===> usr.sbin/amd/include (depend) --- config_local.h --- --- tests.depend__D --- echo flock_helper: /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libc.a /builds/FreeBSD_stable_10/obj/b
PAE Kernel does not boot
I compiled a PAE kernel but it does not boot:it stops in trying to mount the root partitionthese are some info from dmesg:Copyright (c) 1992-2015 The FreeBSD Project.Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.FreeBSD is a registered trademark of The FreeBSD Foundation.FreeBSD 10.2-STABLE #30 r291096: Fri Nov 20 21:09:23 CET 2015 root@sting:/usr/obj/usr/src/sys/STING_VT i386FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512VT(vga): resolution 640x480CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3200.05-MHz 686-class CPU) Origin="GenuineIntel" Id=0xf41 Family=0xf Model=0x4 Stepping=1 Features=0xbfebfbff Features2=0x441d AMD Features=0x10 TSC: P-state invariantreal memory = 4294967296 (4096 MB)avail memory = 3016163328 (2876 MB)Event timer "LAPIC" quality 400ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUsFreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 It looks like that PAE should be supportedsincerelyFilippo ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD_stable_10 - Build #1850 - Failure
FreeBSD_stable_10 - Build #1850 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/1850/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/1850/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/1850/console Change summaries: 291454 by kib: MFC r289895: Reduce the amount of calls to VOP_BMAP() made from the local vnode pager. MFC r291157, r291158: Include the pages before/after the requested page, that fit into the reqblock, into the calculation of the size of run of pages. Tested by: pho The end of the build log: [...truncated 116652 lines...] --- sys.depend__D --- ===> sys/boot/i386/cdboot (depend) --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -I/builds/FreeBSD_stable_10/sys/boot/i386/cdboot/../common -std=gnu99 /builds/FreeBSD_stable_10/sys/boot/i386/cdboot/cdboot.S --- tests.depend__D --- echo fifo_create: /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libc.a >> .depend.fifo_create (cd /builds/FreeBSD_stable_10/tests/sys/fifo && make -f /builds/FreeBSD_stable_10/tests/sys/fifo/Makefile _RECURSING_PROGS= SUBDIR= PROG=fifo_io DEPENDFILE=.depend.fifo_io .MAKE.DEPENDFILE=.depend.fifo_io depend) --- sys.depend__D --- ===> sys/boot/i386/gptboot (depend) --- tests.depend__D --- --- .depend.fifo_io --- rm -f .depend.fifo_io CC='cc ' mkdep -f .depend.fifo_io -a -std=gnu99 /builds/FreeBSD_stable_10/tests/sys/fifo/fifo_io.c --- sys.depend__D --- --- machine --- ln -sf /builds/FreeBSD_stable_10/sys/boot/i386/gptboot/../../../i386/include machine ===> sys/boot/i386/kgzldr (depend) --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a-DKZIP -std=gnu99 /builds/FreeBSD_stable_10/sys/boot/i386/kgzldr/boot.c /builds/FreeBSD_stable_10/sys/boot/i386/kgzldr/../../../kern/inflate.c /builds/FreeBSD_stable_10/sys/boot/i386/kgzldr/lib.c --- tests.depend__D --- echo fifo_io: /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libc.a >> .depend.fifo_io (cd /builds/FreeBSD_stable_10/tests/sys/fifo && make -f /builds/FreeBSD_stable_10/tests/sys/fifo/Makefile _RECURSING_PROGS= SUBDIR= PROG=fifo_misc DEPENDFILE=.depend.fifo_misc .MAKE.DEPENDFILE=.depend.fifo_misc depend) --- usr.bin.depend__D --- echo chpass: /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libc.a /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libcrypt.a /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libutil.a /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libypclnt.a >> .depend --- depend_subdir_cksum --- ===> usr.bin/cksum (depend) --- tests.depend__D --- --- .depend.fifo_misc --- rm -f .depend.fifo_misc CC='cc ' mkdep -f .depend.fifo_misc -a -std=gnu99 /builds/FreeBSD_stable_10/tests/sys/fifo/fifo_misc.c --- sys.depend__D --- ===> sys/boot/i386/libi386 (depend) --- usr.bin.depend__D --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -std=gnu99 /builds/FreeBSD_stable_10/usr.bin/cksum/cksum.c /builds/FreeBSD_stable_10/usr.bin/cksum/crc.c /builds/FreeBSD_stable_10/usr.bin/cksum/print.c /builds/FreeBSD_stable_10/usr.bin/cksum/sum1.c /builds/FreeBSD_stable_10/usr.bin/cksum/sum2.c /builds/FreeBSD_stable_10/usr.bin/cksum/crc32.c --- sys.depend__D --- --- machine --- ln -sf /builds/FreeBSD_stable_10/sys/boot/i386/libi386/../../../i386/include machine --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a-DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DSMBIOS_SERIAL_NUMBERS -DTERM_EMU -Dalloca=__builtin_alloca -I/builds/FreeBSD_stable_10/sys/boot/i386/libi386/../../common -I/builds/FreeBSD_stable_10/sys/boot/i386/libi386/../common -I/builds/FreeBSD_stable_10/sys/boot/i386/libi386/../btx/lib -I/builds/FreeBSD_stable_10/sys/boot/i386/libi386/../../../contrib/dev/acpica/include -I/builds/FreeBSD_stable_10/sys/boot/i386/libi386/../../.. -I. -I/builds/FreeBSD_stable_10/sys/boot/i386/libi386/../../../../lib/libstand/ -std=gnu99 /builds/FreeBSD_stable_10/sys/boot/i386/libi386/biosacpi.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/bioscd.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/biosdisk.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/biosmem.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/biospnp.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/biospci.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/biossmap.c /builds/FreeBSD_stable _10/sys/boot/i386/libi386/bootinfo.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/bootinfo32.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/bootinfo64.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/comconsole.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/devicename.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/elf32_freebsd.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/elf64_freebsd.c /builds/FreeBSD_stable_10/sys/boot/i386/libi386/i386_copy.c /builds/FreeBSD_stable_10/sys/boot/i386
Re: cp from NFS to ZFS hung in "fifoor"
Mikhail T. wrote: > On 28.11.2015 17:41, Jilles Tjoelker wrote: > > Although cp -R will normally copy a fifo by calling mkfifo at the > > destination, it may open one if a regular file is replaced with a fifo > > between the time it reads the directory and it copies that file. > > The sole fifo under /home here was mi/.licq/licq_fifo, created in 2003. > I echoed something into it (on the NFS-client side) and the cp-process > resumed. > > I then performed a simple test: > > 1. Create a fifo in an NFS-exported directory and try to copy it with > the -R flag > mi@narawntapu:/cache/src (792) mkfifo /green/tmp/test > mi@narawntapu:/cache/src (793) cp -Rpn /green/tmp/test /tmp/ > mi@narawntapu:/cache/src (794) ls -l /tmp/test > prw-r--r-- 1 mi wheel 0 29 лис 00:05 /tmp/test > The above worked fine. > 2. Now, when I try to do the same thing via an NFS mount, I get the > same hang in fifoor: > root@aldan:ports/x11/kde4 (475) cp -Rpn /green/tmp/test /tmp/ > load: 0.42 cmd: cp 38299 [fifoor] 1.15r 0.00u 0.00s 0% 1868k > > So, the good news is, this is not ZFS' fault. The bad news is, there is > still a bug... Unless, of course, this is some known "feature" of the > NFS... Compare, for example, how stat(1) describes the same named pipe > from both machines: > > Local FS: > 92 74636334 prw-r--r-- 1 mi wheel 0 0 "Nov 29 00:05:51 2015" "Nov 29 > 00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" 16384 0 > 0 /green/tmp/test > NFS-client: > 973143811 74636334 ?rw-r--r-- 1 mi wheel 4294967295 0 "Nov 29 > 00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" "Dec 31 > 18:59:59 1969" 16384 0 0 /green/tmp/test > The other thing you could do is capture packets for the "ls -l" from the NFS client: tcpdump -s 0 -w fifo.pcap host run on the client while doing the "ls -l" should be sufficient. (Doing it just after mounting will avoid any attribute cache hit.) You could then look at the fifo.pcap in wireshark (or email it to me as an attachment and I can look) and see if the file type attribute is FIFO. (If it isn't, then the NFS server is broken somehow.) rick > That question-mark in the node-type (instead of the "p") is, I guess, > what confuses cp into trying to read from it instead of creating a fifo. > Should I file a PR? Thank you! > > -mi > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: cp from NFS to ZFS hung in "fifoor"
Mikhail T. wrote: > On 28.11.2015 17:41, Jilles Tjoelker wrote: > > Although cp -R will normally copy a fifo by calling mkfifo at the > > destination, it may open one if a regular file is replaced with a fifo > > between the time it reads the directory and it copies that file. > > The sole fifo under /home here was mi/.licq/licq_fifo, created in 2003. > I echoed something into it (on the NFS-client side) and the cp-process > resumed. > > I then performed a simple test: > > 1. Create a fifo in an NFS-exported directory and try to copy it with > the -R flag > mi@narawntapu:/cache/src (792) mkfifo /green/tmp/test > mi@narawntapu:/cache/src (793) cp -Rpn /green/tmp/test /tmp/ > mi@narawntapu:/cache/src (794) ls -l /tmp/test > prw-r--r-- 1 mi wheel 0 29 лис 00:05 /tmp/test > The above worked fine. > 2. Now, when I try to do the same thing via an NFS mount, I get the > same hang in fifoor: > root@aldan:ports/x11/kde4 (475) cp -Rpn /green/tmp/test /tmp/ > load: 0.42 cmd: cp 38299 [fifoor] 1.15r 0.00u 0.00s 0% 1868k > > So, the good news is, this is not ZFS' fault. The bad news is, there is > still a bug... Unless, of course, this is some known "feature" of the > NFS... Compare, for example, how stat(1) describes the same named pipe > from both machines: > > Local FS: > 92 74636334 prw-r--r-- 1 mi wheel 0 0 "Nov 29 00:05:51 2015" "Nov 29 > 00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" 16384 0 > 0 /green/tmp/test > NFS-client: > 973143811 74636334 ?rw-r--r-- 1 mi wheel 4294967295 0 "Nov 29 > 00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" "Dec 31 > 18:59:59 1969" 16384 0 0 /green/tmp/test > I just tried a trivial test (using a fairly old FreeBSD9 and a pretty recent FreeBSD-head) and wasn't able to reproduce the problem. For my tests, "ls -l" in the NFS client showed "p" and the "cp -R" worked. I only have UFS file systems and tested with those. I can only think of a couple of explanations: 1 - ZFS didn't fill the v_type in as FIFO. The NFS server uses the v_type field to determine it is a fifo and not the high order bits of va_mode (the S_IFMT bits). I don't have ZFS to test with. 2 - You somehow used an NFSv2 mount. (NFSv2 didn't have support for FIFOs, if I recall correctly.) You can check your mount options, including which version is in use via "nfsstat -m" unless you have a pretty old system. If you have a UFS file system on the NFS server, maybe you could try exporting that and run a test, to see if it happens for a UFS export? rick > That question-mark in the node-type (instead of the "p") is, I guess, > what confuses cp into trying to read from it instead of creating a fifo. > Should I file a PR? Thank you! > > -mi > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: cp from NFS to ZFS hung in "fifoor"
On Sat, Nov 28, 2015 at 10:42:28AM -0500, Mikhail T. wrote: > I was copying /home from an old server (narawntapu) to a new one > (aldan). The narawntapu:/home is mounted on aldan as /mnt with flags > ro,intr. On narawntapu /home was simply located on an SSD, but on aldan > I created a ZFS filesystem for it. > > The copying was started thus: > > root@aldan:/home (435) cp -Rpn /mnt/* . > > for a while this was proceeding at a decent clip with cp making > newnfsreq-uests: > > load: 0.78 cmd: cp 38711 [newnfsreq] 802.84r 1.57u 140.63s 20% 10768k > > /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S > -> > > ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/sent/cur/1219621413.32392.hd8cl:2,S > 100% > load: 1.23 cmd: cp 38711 [newnfsreq] 874.19r 1.66u 154.74s 17% 4576k > > /mnt/mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S > -> > > ./mi/.kde/share/apps/kmail/dimap/.42838394.directory/ML/cur/1219595347.32392.rMDFf:2,S > 100% > > ZFS on the destination compressing and writing stuff out and the traffic > between the two ranging from 30 to 50Mb/s (according to systat), but > then something happened and the cp-process is now hung: > > load: 0.55 cmd: cp 38711 [fifoor] 1107.67r 2.09u 194.12s 0% 3300k > load: 0.50 cmd: cp 38711 [fifoor] 1112.66r 2.09u 194.12s 0% 3300k > load: 0.22 cmd: cp 38711 [fifoor] 1642.37r 2.09u 194.12s 0% 3300k > # grep -r fifoor /usr/src/ /usr/src/sys/fs/fifofs/fifo_vnops.c: PDROP | PCATCH | PSOCK, "fifoor", 0); May be cp try copy fifo's content, by incorrectly detect special file? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
