Re: error compiling sys/netinet/tcp_syncache.c on i386

2017-08-12 Thread Mikhail T.

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

2017-08-12 Thread Michael Tuexen
> 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

2017-08-12 Thread Mikhail T.

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)

2017-08-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

Mark Millard  changed:

   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)

2017-08-12 Thread Peter
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

2017-08-12 Thread Bryce Edwards
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

2017-08-12 Thread Paul Kraus

> On Aug 11, 2017, at 2:28 AM, Eugene M. Zheganin  wrote:
> 
> 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)

2017-08-12 Thread bugzilla-noreply
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=0xbfebfbff
Aug 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