Re: error compiling sys/netinet/tcp_syncache.c on i386
On 12.08.2017 19:16, Michael Tuexen wrote: Just my luck -- deciding to update to the latest 10.x today... sys/netinet/tcp_syncache.c:280:50: error: implicit conversion from 'long long' to 'time_t' (aka 'int') changes value from -9223372036854775808 to 0 [-Werror,-Wconstant-conversion] V_tcp_syncache.hashbase[i].sch_last_overflow = INT64_MIN; ~ ^ ./x86/_stdint.h:89:41: note: expanded from macro 'INT64_MIN' #define INT64_MIN (-0x7fffLL-1) Yours, Right... I need to MFC alsohttps://svnweb.freebsd.org/base?view=revision=317244 Will do that tomorrow. Thanks for reminding me... You are welcome, but this means, stable is not currently buildable on i386 -- a Tier1-platform... Is not that monitored for? On the ports side of things, I'd be getting an automated build-failure notice shortly after making a change, that breaks a build... I applied the diff you linked to by hand and the kernel-build moved on, thank you! Yours, -mi -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"
Re: error compiling sys/netinet/tcp_syncache.c on i386
> On 13. Aug 2017, at 01:08, Mikhail T.wrote: > > Just my luck -- deciding to update to the latest 10.x today... > sys/netinet/tcp_syncache.c:280:50: error: implicit conversion from 'long > long' to 'time_t' (aka 'int') changes value from -9223372036854775808 to 0 > [-Werror,-Wconstant-conversion] > V_tcp_syncache.hashbase[i].sch_last_overflow = INT64_MIN; > ~ ^ > ./x86/_stdint.h:89:41: note: expanded from macro 'INT64_MIN' > #define INT64_MIN (-0x7fffLL-1) > Yours, Right... I need to MFC also https://svnweb.freebsd.org/base?view=revision=317244 Will do that tomorrow. Thanks for reminding me... Best regards Michael > > -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"
error compiling sys/netinet/tcp_syncache.c on i386
Just my luck -- deciding to update to the latest 10.x today... sys/netinet/tcp_syncache.c:280:50: error: implicit conversion from 'long long' to 'time_t' (aka 'int') changes value from -9223372036854775808 to 0 [-Werror,-Wconstant-conversion] V_tcp_syncache.hashbase[i].sch_last_overflow = INT64_MIN; ~ ^ ./x86/_stdint.h:89:41: note: expanded from macro 'INT64_MIN' #define INT64_MIN (-0x7fffLL-1) Yours, -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"
[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903 Mark Millardchanged: What|Removed |Added CC||mar...@dsl-only.net --- Comment #55 from Mark Millard --- (In reply to muxx.dev from comment #54)\ Looks to me like ts==0x0 was the starting value given to turnstile_broadcast in each backtrace listed in this buzilla bug (213903), for example: (kgdb) list *0x80b3a89c 0x80b3a89c is in turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837). 832 833 /* 834 * Transfer the blocked list to the pending list. 835 */ 836 mtx_lock_spin(_contested_lock); 837 TAILQ_CONCAT(>ts_pending, >ts_blocked[queue], td_lockq); 838 mtx_unlock_spin(_contested_lock); 839 840 /* 841 * Give a turnstile to each thread. The last thread gets Current language: auto; currently minimal (kgdb) backtrace . . . #8 0x80b3a89c in turnstile_broadcast (ts=0x0, queue=1) at /usr/src/sys/kern/subr_turnstile.c:837 #9 0x80ad48cf in __rw_wunlock_hard (c=0xf800437de858, tid=, file=, line=) at /usr/src/sys/kern/kern_rwlock.c:1027 . . . Note that ts==0x0 would be a problem for: TAILQ_CONCAT(>ts_pending, >ts_blocked[queue], td_lockq); So I wonder if __rw_wunlock_hard is providing a bad ts value. If yes: the problem then occurs before the turnstile_broadcast call is made. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
errors from port make (analyzed: bug in pkg)
For a long time already, I get these strange messages whenever building a port: pkg: Bad argument on pkg_set 2143284626 Today I looked into it, and found it is easily reproducible: # pkg audit whatever pkg: Bad argument on pkg_set 2143284618 0 problem(s) in the installed packages found. # Looking closer, I found this offending call in src/audit.c:exec_audit(): pkg_set(pkg, PKG_UNIQUEID, name); This goes into libpkg/pkg.c:pkg_vset(), but there nobody is interested in an UNIQUEID parameter, so that the parameter does not get fetched from the va_list. It does not do any harm, but it is ugly. Please fix. ___ 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"
Error in /usr/src/release/release.sh
When trying to build a set of RELENG/11.1 release files, I'm getting the following error (tail end of output) in the release.sh run: -- >>> Kernel build for ALLWINNER completed on Fri Aug 11 22:24:02 UTC 2017 -- make -C /usr/src/release obj make -C /usr/src/release ftp `ftp' is up to date. make -C /usr/src/release release-done touch release true mkdir -p /R cp -a ftp /R/ cd /R && sha512 FreeBSD-11.1-RELEASE-p1-arm-armv6* > /R/CHECKSUM.SHA512 sha512: FreeBSD-11.1-RELEASE-p1-arm-armv6*: No such file or directory *** Error code 1 Stop. make: stopped in /usr/src/release Here's the contents of my release.conf: CHROOTDIR="/usr/local/build/chroot" SRCBRANCH="base/releng/11.1" TARGET="arm" TARGET_ARCH="armv6" KERNEL="ALLWINNER" NOSRC=yes NODOC=yes NOPORTS=yes And the contents of the R/ directory after the run: bryce@tahiti /usr/local/build $find chroot/R/ chroot/R/ chroot/R/ftp chroot/R/ftp/kernel-dbg.txz chroot/R/ftp/tests.txz chroot/R/ftp/doc.txz chroot/R/ftp/base.txz chroot/R/ftp/MANIFEST chroot/R/ftp/kernel.txz chroot/R/ftp/base-dbg.txz chroot/R/CHECKSUM.SHA512 Thanks in advance for any insight. I'm not having luck with make distributeworld in /usr/src either - The use of DESTDIR & DISTDIR in the Makefiles seem to alternate between absolute & relative use of those and it isn't cooperating with me (which is why I was trying to just go with /usr/src/release/release.sh) Bryce ___ 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: zfs listing and CPU
> On Aug 11, 2017, at 2:28 AM, Eugene M. Zheganinwrote: > > Why does the zfs listing eat so much of the CPU ? > 47114 root 1 200 40432K 3840K db->db 4 0:05 26.84% zfs > 47099 root 1 200 40432K 3840K zio->i 17 0:05 26.83% zfs > 47106 root 1 200 40432K 3840K db->db 21 0:05 26.81% zfs > 47150 root 1 200 40432K 3428K db->db 13 0:03 26.31% zfs > 47141 root 1 200 40432K 3428K zio->i 28 0:03 26.31% zfs > 47135 root 1 200 40432K 3312K g_wait 9 0:03 25.51% zfs > This is from winter 2017 11-STABLE (r310734), one of the 'zfs'es is cloning, > and all the others are 'zfs list -t all'. I have like 25 gigs of free RAM, do > I have any chance of speeding this up using may be some caching or some > sysctl tuning ? We are using a simple ZFS web API that may issue concurrent > or sequential listing requests, so as you can see they sometimes do stack. How many snapshots do you have ? I have only seen this behavior with LOTS (not hundreds, but thousands) of snapshots. What does your `iostat -x 1` look like ? I expect that you are probably saturating your drives with random I/O. ___ 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"
[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903 muxx@gmail.com changed: What|Removed |Added CC||muxx@gmail.com --- Comment #54 from muxx@gmail.com --- I can confirm the same crash on FreeBSD 11.0-RELEASE-p1 (GENERIC) on the following hardware: Aug 12 11:57:04 gw kernel: CPU: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz (2000.05-MHz K8-class CPU) Aug 12 11:57:04 gw kernel: Origin="GenuineIntel" Id=0x30678 Family=0x6 Model=0x37 Stepping=8 Aug 12 11:57:04 gw kernel: Features=0xbfebfbffAug 12 11:57:04 gw kernel: Features2=0x41d8e3bf Aug 12 11:57:04 gw kernel: AMD Features=0x28100800 Aug 12 11:57:04 gw kernel: AMD Features2=0x101 Aug 12 11:57:04 gw kernel: Structured Extended Features=0x2282 Aug 12 11:57:04 gw kernel: VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID Aug 12 11:57:04 gw kernel: TSC: P-state invariant, performance statistics Aug 12 11:57:04 gw kernel: real memory = 8589934592 (8192 MB) Aug 12 11:57:04 gw kernel: avail memory = 8137785344 (7760 MB) Aug 12 11:57:04 gw kernel: Event timer "LAPIC" quality 600 Aug 12 11:57:04 gw kernel: ACPI APIC Table: Aug 12 11:57:04 gw kernel: WARNING: L1 data cache covers less APIC IDs than a core Aug 12 11:57:04 gw kernel: 0 < 1 Aug 12 11:57:04 gw kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Aug 12 11:57:04 gw kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Aug 12 11:57:04 gw kernel: random: unblocking device. Aug 12 11:57:04 gw kernel: ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/32 (20160527/tbfadt-650) Aug 12 11:57:04 gw kernel: WARNING: Bogus Interrupt Polarity. Assume CONFORMS more information from /var/log/messages and kgdb: Aug 12 11:57:04 gw kernel: Fatal trap 12: page fault while in kernel mode Aug 12 11:57:04 gw kernel: cpuid = 1; apic id = 02 Aug 12 11:57:04 gw kernel: fault virtual address= 0x30 Aug 12 11:57:04 gw kernel: fault code = supervisor read data, page not present Aug 12 11:57:04 gw kernel: instruction pointer = 0x20:0x80b3a89c Aug 12 11:57:04 gw kernel: stack pointer= 0x28:0xfe0232609440 Aug 12 11:57:04 gw kernel: frame pointer= 0x28:0xfe0232609470 Aug 12 11:57:04 gw kernel: code segment = base 0x0, limit 0xf, type 0x1b Aug 12 11:57:04 gw kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Aug 12 11:57:04 gw kernel: processor eflags = resume, IOPL = 0 Aug 12 11:57:04 gw kernel: current process = 18204 (telegraf) Aug 12 11:57:04 gw kernel: trap number = 12 Aug 12 11:57:04 gw kernel: panic: page fault Aug 12 11:57:04 gw kernel: cpuid = 1 Aug 12 11:57:04 gw kernel: KDB: stack backtrace: Aug 12 11:57:04 gw kernel: #0 0x80b24077 at kdb_backtrace+0x67 Aug 12 11:57:04 gw kernel: #1 0x80ad93e2 at vpanic+0x182 Aug 12 11:57:04 gw kernel: #2 0x80ad9253 at panic+0x43 Aug 12 11:57:04 gw kernel: #3 0x80fa0d31 at trap_fatal+0x351 Aug 12 11:57:04 gw kernel: #4 0x80fa0f23 at trap_pfault+0x1e3 Aug 12 11:57:04 gw kernel: #5 0x80fa04cc at trap+0x26c Aug 12 11:57:04 gw kernel: #6 0x80f84141 at calltrap+0x8 Aug 12 11:57:04 gw kernel: #7 0x80ad48cf at __rw_wunlock_hard+0x8f Aug 12 11:57:04 gw kernel: #8 0x80e1a75c at vm_map_delete+0x3dc Aug 12 11:57:04 gw kernel: #9 0x80e1c5f7 at vm_map_remove+0x47 Aug 12 11:57:04 gw kernel: #10 0x80a86c7f at exec_new_vmspace+0x22f Aug 12 11:57:04 gw kernel: #11 0x80a5bfe8 at exec_elf64_imgact+0xa58 Aug 12 11:57:04 gw kernel: #12 0x80a84d4d at kern_execve+0x7dd Aug 12 11:57:04 gw kernel: #13 0x80a841dc at sys_execve+0x4c Aug 12 11:57:04 gw kernel: #14 0x80fa168e at amd64_syscall+0x4ce Aug 12 11:57:04 gw kernel: #15 0x80f8442b at Xfast_syscall+0xfb ... (kgdb) list *0x80b3a89c 0x80b3a89c is in turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837). 832 833 /* 834 * Transfer the blocked list to the pending list. 835 */ 836 mtx_lock_spin(_contested_lock); 837 TAILQ_CONCAT(>ts_pending, >ts_blocked[queue], td_lockq); 838 mtx_unlock_spin(_contested_lock); 839 840 /* 841 * Give a turnstile to each thread. The last thread gets Current language: auto; currently minimal (kgdb) backtrace #0 doadump (textdump=) at pcpu.h:221 #1 0x80ad8e69 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0x80ad941b in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759