From owner-freebsd-hackers@freebsd.org Sun Aug 26 11:20:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D2F610723AB; Sun, 26 Aug 2018 11:20:15 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 92ABC7BF63; Sun, 26 Aug 2018 11:20:14 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: by mail-oi0-x243.google.com with SMTP id x197-v6so4926177oix.5; Sun, 26 Aug 2018 04:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+6+plC/3fU8Kp1Osd/rb3wCKOICD0IZbAmKqk657Uh0=; b=QciaCnpdonODb0IF57MM49R/oUxCbg+IIqVfGeqKLBgx9GIjvhLwu/VgBupXgEk8wt sP2pZhX5SsEZL3PZdZnxkQtnJNDog8gB/gYOOMGKdn9G+v/O5N8Kvh8gDnFsKqve4lnM ErsFlftL3nSnluLhhHFUjxmVvaWyd4Xu/NDsqLuhpLzkt7scNPBenL9ot9A0t/GVXf9T 5ekHq2lQLuf0hy6yUmq+V5TQ1Cp/qBhi9c0XAnnPFOYnI2JTWNrhJJgG4CL7mhKRDdIQ uxssiLbhBdPPoNWq1hNayFPhk9HrEhL8YPi0AqTZIeW6GtqA8Tx9Z/N3UQDLe5ADhljb 3/2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+6+plC/3fU8Kp1Osd/rb3wCKOICD0IZbAmKqk657Uh0=; b=BmPpVBCZVsn84jjK1F+l76/kDVYM8sAo7OsiN6Dt1RLAxCb8lXZvGsLJR9TGghWAt9 xbyjp44WjBWZGNkzJaiSim8KRv/oqMYOteo5RFXS9oKIY6DL6Hf94F+b3ZSOp7IMYsdC ogll12IjgQX/rtqSwex5jQ3ZcnSKioa0PLgtDTpDWOvgDvpOiAYSf0gjxcLI+6AzBY7s obnelzhGV/4TIM7g6XOMQcCKafUJCelf2r4m+tJuURRIZHCLc1oPFtxikb92qceEEBmh 5MLCM/BfPUIxOb88MAG0HUa7X2YulnSajIXvwMlXZ+ABijjkApzujUvslZSxMS7dLjMM ibTQ== X-Gm-Message-State: APzg51A6gHNRCYayegUO7322LTRW3cVNgceai5OK4Hi4eixhrC16e/34 AFStSkhram+K6zOKSuqZngC83b7K8gCUcJ4XFrqaMzp1 X-Google-Smtp-Source: ANB0VdbkRqzDGobf2fdslj2j+uGsiDmzbekXSadn68lHOadtPPsJWT92MdUAcIingPKeq7mlezRl9swIAIYaSXbYmlI= X-Received: by 2002:aca:4802:: with SMTP id v2-v6mr8802835oia.259.1535282413258; Sun, 26 Aug 2018 04:20:13 -0700 (PDT) MIME-Version: 1.0 From: Meowthink Date: Sun, 26 Aug 2018 19:20:00 +0800 Message-ID: Subject: Help diagnose my Ryzen build problem To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 11:20:15 -0000 Hello all, Recently I tried to build up a Ryzen system and run FreeBSD on it. CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics (0x810f10) Mobo: Asrock Fatal1ty AB350 Gaming-ITX/ac ( with up-to-date BIOS with PinnaclePI-AM4_1.0.0.4, microcode 0x810100b ) Mem: 2x Crucial 16GB DDR4-2400 EUDIMM CL17 ( ECC Unregistered but ECC actually won't work :( ) But the system is unstable - it can't last few days even is nearly idle. System panics even at midnight. It almost panic while or after I built something large. Surprisly I didn't encourage a user program fault, bad binaries built etc., panics only. Then I tried lots of BIOS settings e.g. SMT, C6 idle current, underclock RAM, but none seems effect. It could pass memtest86 V7.5 without error, or various benchmarks under Windows. thus I think the problem is not in the hardware but software. In the mean time, I realized that the rate of irqs from xhci0 are too high - it's about 1998/s. I found [1] and tried to MFC r331665. It didn't fix the problem though, but disabling that bluetooth module stops the irq storm, after all. Then the system lasts much longer before panic. It eventually can compile ports tree, build the world, scrub the zpool, all done without annoying reboots. Then I assume this is [2] related? So I also tried cpuctl, bounding all processes to 2-7. But the problem is still there, only the chance become very low. It still panics occasionally, idling a week or stressing few hours - Stress seems to rise the chance of panic, but differently by types. Things like llvm will always build, but gcc will cause a panic per few passes. The system was 11.2 but then moved on to stable/11 (r337906 currently). I've got last 10 coredumps saved but my kernel isn't compile as debug. So I'll put some backtrace from core.txt.? in the end. Indeed I want to eliminate this problem. Could someone guide me how to figure out the problem? What should I try next? Best regards, Meowthink [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224886 [2] https://reviews.freebsd.org/D11780 Backtraces newer - older: ------------------------------------------------------------------------ Panic while compiling gcc: #0 doadump (textdump=) at pcpu.h:230 230 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:230 #1 0xffffffff80afa5fb in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:383 #2 0xffffffff80afaa21 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:776 #3 0xffffffff80afa863 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:707 #4 0xffffffff80f7c14f in trap_fatal (frame=0xfffffe081e962790, eva=18446735309538549504) at /usr/src/sys/amd64/amd64/trap.c:877 #5 0xffffffff80f7c1a9 in trap_pfault (frame=0xfffffe081e962790, usermode=0) at pcpu.h:230 #6 0xffffffff80f7b984 in trap (frame=0xfffffe081e962790) at /usr/src/sys/amd64/amd64/trap.c:415 #7 0xffffffff80f5bccc in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #8 0xffffffff822950a8 in arc_change_state () at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1800 #9 0xffffffff8229328b in arc_access () at time.h:145 #10 0xffffffff82296232 in arc_write_done (zio=0xfffff8065f886410) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:6169 #11 0xffffffff82334cbe in zio_done (zio=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:4032 #12 0xffffffff8233070c in zio_execute (zio=0xfffff8065f886410) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1768 #13 0xffffffff80b52cc4 in taskqueue_run_locked (queue=0xfffff8000d9e6e00) at /usr/src/sys/kern/subr_taskqueue.c:463 #14 0xffffffff80b53e28 in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:755 #15 0xffffffff80abd813 in fork_exit ( callout=0xffffffff80b53d90 , arg=0xfffff8000d967030, frame=0xfffffe081e962ac0) at /usr/src/sys/kern/kern_fork.c:1072 #16 0xffffffff80f5cc7e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:972 #17 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ backtrace panic when shuting down: #0 doadump (textdump=) at pcpu.h:230 230 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:230 #1 0xffffffff80afa5fb in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:383 #2 0xffffffff80afaa21 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:776 #3 0xffffffff80afa863 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:707 #4 0xffffffff80f7c14f in trap_fatal (frame=0xfffffe081ed30700, eva=0) at /usr/src/sys/amd64/amd64/trap.c:877 #5 0xffffffff80f7c1a9 in trap_pfault (frame=0xfffffe081ed30700, usermode=0) at pcpu.h:230 #6 0xffffffff80f7b984 in trap (frame=0xfffffe081ed30700) at /usr/src/sys/amd64/amd64/trap.c:415 #7 0xffffffff80f5bccc in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #8 0xffffffff80dfe4ad in vm_object_terminate (object=0xfffff805bf66d5a0) at /usr/src/sys/vm/vm_object.c:768 #9 0xffffffff80dfd0f8 in vm_object_deallocate (object=0x0) at /usr/src/sys/vm/vm_object.c:677 #10 0xffffffff80df3189 in _vm_map_unlock (map=, file=, line=) at /usr/src/sys/vm/vm_map.c:2939 #11 0xffffffff80df7be2 in vm_map_remove (map=0xfffff80018673000, start=4096, end=140737488351232) at /usr/src/sys/vm/vm_map.c:3137 #12 0xffffffff80df2e49 in vmspace_exit (td=0xfffff80039ec0620) at /usr/src/sys/vm/vm_map.c:337 #13 0xffffffff80ab72b9 in exit1 (td=0xfffff80039ec0620, rval=, signo=) at /usr/src/sys/kern/kern_exit.c:401 #14 0xffffffff80ab6ced in sys_sys_exit (td=, uap=) at /usr/src/sys/kern/kern_exit.c:180 #15 0xffffffff80f7d1d8 in amd64_syscall (td=0xfffff80039ec0620, traced=0) at subr_syscall.c:132 #16 0xffffffff80f5c5ad in fast_syscall_common () at /usr/src/sys/amd64/amd64/exception.S:494 #17 0x00000008028d034a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ Panic while only running my single thread python script #0 doadump (textdump=) at pcpu.h:230 230 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:230 #1 0xffffffff80afa5fb in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:383 #2 0xffffffff80afaa21 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:776 #3 0xffffffff80afa863 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:707 #4 0xffffffff80f7c14f in trap_fatal (frame=0xfffffe081f635ec0, eva=952) at /usr/src/sys/amd64/amd64/trap.c:877 #5 0xffffffff80f7c1a9 in trap_pfault (frame=0xfffffe081f635ec0, usermode=0) at pcpu.h:230 #6 0xffffffff80f7b984 in trap (frame=0xfffffe081f635ec0) at /usr/src/sys/amd64/amd64/trap.c:415 #7 0xffffffff80f5bccc in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #8 0xffffffff80af57ad in __rw_wlock_hard (c=0xfffff80016f8f798, v=) at /usr/src/sys/kern/kern_rwlock.c:977 #9 0xffffffff80bbca92 in bufobj_invalbuf (bo=, flags=1, slpflag=1017770744, slptimeo=) at /usr/src/sys/kern/vfs_subr.c:1609 #10 0xffffffff80bbf8be in vgonel (vp=0xfffff8053ca9f1d8) at /usr/src/sys/kern/vfs_subr.c:1655 #11 0xffffffff80bbbcc4 in vnlru_free_locked (count=1, mnt_op=0x0) at /usr/src/sys/kern/vfs_subr.c:1227 #12 0xffffffff80bbbe14 in getnewvnode_reserve (count=1) at /usr/src/sys/kern/vfs_subr.c:1287 #13 0xffffffff82327fb4 in zfs_zget (zfsvfs=0xfffff80076574000, obj_num=34941, zpp=0xfffffe081f6362a8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1122 #14 0xffffffff823421ad in zfs_dirent_lookup (dzp=0xfffff804ff94e420, name=0xfffffe081f6363e0 "filename.ext", zpp=0xfffffe081f6362a8, flag=2) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:187 #15 0xffffffff82342267 in zfs_dirlook (dzp=0xfffff804ff94e420, name=, zpp=0xfffffe081f636360) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:238 #16 0xffffffff8235a4ef in zfs_lookup () at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1658 #17 0xffffffff8235ac1e in zfs_freebsd_lookup (ap=0xfffffe081f636548) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4956 #18 0xffffffff810fe89c in VOP_CACHEDLOOKUP_APV (vop=, a=0xfffffe081f636548) at vnode_if.c:195 #19 0xffffffff80ba8d56 in vfs_cache_lookup (ap=) at vnode_if.h:80 #20 0xffffffff810fe77c in VOP_LOOKUP_APV (vop=, a=0xfffffe081f636610) at vnode_if.c:127 #21 0xffffffff80bb2761 in lookup (ndp=0xfffffe081f636748) at vnode_if.h:54 #22 0xffffffff80bb1c29 in namei (ndp=0xfffffe081f636748) at /usr/src/sys/kern/vfs_lookup.c:448 #23 0xffffffff80bc8238 in kern_statat (td=0xfffff8013ba1b620, flag=, fd=-100, path=0x80332c910
, pathseg=UIO_USERSPACE, sbp=0xfffffe081f636900, hook=0) at /usr/src/sys/kern/vfs_syscalls.c:2023 #24 0xffffffff80bc817d in sys_stat (td=, uap=0xfffff8013ba1bb58) at /usr/src/sys/kern/vfs_syscalls.c:1978 #25 0xffffffff80f7d1d8 in amd64_syscall (td=0xfffff8013ba1b620, traced=0) at subr_syscall.c:132 #26 0xffffffff80f5c5ad in fast_syscall_common () at /usr/src/sys/amd64/amd64/exception.S:494 #27 0x0000000801a5b9ca in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ Panic while using mplayer #0 doadump (textdump=) at pcpu.h:230 230 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:230 #1 0xffffffff80af91cb in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:383 #2 0xffffffff80af95f1 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:776 #3 0xffffffff80af9433 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:707 #4 0xffffffff80f7a13f in trap_fatal (frame=0xfffffe081f70d380, eva=0) at /usr/src/sys/amd64/amd64/trap.c:877 #5 0xffffffff80f7a199 in trap_pfault (frame=0xfffffe081f70d380, usermode=0) at pcpu.h:230 #6 0xffffffff80f79974 in trap (frame=0xfffffe081f70d380) at /usr/src/sys/amd64/amd64/trap.c:415 #7 0xffffffff80f5a00c in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #8 0xffffffff8088c030 in hdac_stream_start (dev=, child=, dir=0, stream=1, buf=1889533952, blksz=2048, blkcnt=2) at /usr/src/sys/dev/sound/pci/hda/hdac.c:1927 #9 0xffffffff8088437d in hdaa_channel_start (ch=) at hdac_if.h:84 #10 0xffffffff80887e0d in hdaa_channel_trigger (obj=, data=0xfffff8007102c480, go=1) at /usr/src/sys/dev/sound/pci/hda/hdaa.c:2161 #11 0xffffffff80893b8e in chn_trigger (c=0xfffff80071058400, go=1) at channel_if.h:131 #12 0xffffffff8089751b in chn_notify (c=0xfffff80071058400, flags=) at /usr/src/sys/dev/sound/pcm/channel.c:2281 #13 0xffffffff808b697f in vchan_trigger (obj=, data=, go=1) at /usr/src/sys/dev/sound/pcm/vchan.c:171 #14 0xffffffff80893b8e in chn_trigger (c=0xfffff80071057c00, go=1) at channel_if.h:131 #15 0xffffffff8089de10 in dsp_ioctl (i_dev=, cmd=, arg=0xfffffe081f70d8d0 "\003", mode=, td=) at /usr/src/sys/dev/sound/pcm/dsp.c:1733 #16 0xffffffff809c5b38 in devfs_ioctl_f (fp=0xfffff802c5563c80, com=2147766288, data=0xfffffe081f70d8d0, cred=0xfffff8004c482500, td=0xfffff802f24ac000) at /usr/src/sys/fs/devfs/devfs_vnops.c:791 #17 0xffffffff80b5c00d in kern_ioctl (td=0xfffff802f24ac000, fd=51, com=2147766288, data=) at file.h:323 #18 0xffffffff80b5bd2c in sys_ioctl (td=0xfffff802f24ac000, uap=0xfffff802f24ac538) at /usr/src/sys/kern/sys_generic.c:745 #19 0xffffffff80f7b1c8 in amd64_syscall (td=0xfffff802f24ac000, traced=0) at subr_syscall.c:132 #20 0xffffffff80f5a8ed in fast_syscall_common () at /usr/src/sys/amd64/amd64/exception.S:494 #21 0x0000000801fb94aa in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ Panic while ilde, seems like cronjobs triggered ZFS ARC cleanup. #0 doadump (textdump=) at pcpu.h:230 230 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:230 #1 0xffffffff80af95fb in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:383 #2 0xffffffff80af9a21 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:776 #3 0xffffffff80af9863 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:707 #4 0xffffffff80f7b13f in trap_fatal (frame=0xfffffe081ee186e0, eva=201697507) at /usr/src/sys/amd64/amd64/trap.c:877 #5 0xffffffff80f7b199 in trap_pfault (frame=0xfffffe081ee186e0, usermode=0) at pcpu.h:230 #6 0xffffffff80f7a974 in trap (frame=0xfffffe081ee186e0) at /usr/src/sys/amd64/amd64/trap.c:415 #7 0xffffffff80f5a5bc in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #8 0xffffffff80ad596e in free (addr=0xfffff802472af200, mtp=0xffffffff825bfc00) at /usr/src/sys/kern/kern_malloc.c:583 #9 0xffffffff8232a667 in zfs_inactive (vp=, cr=, ct=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4333 #10 0xffffffff82332a1d in zfs_freebsd_inactive (ap=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5364 #11 0xffffffff810ff6b2 in VOP_INACTIVE_APV (vop=, a=0xfffffe081ee18858) at vnode_if.c:1955 #12 0xffffffff80bbd7bc in vinactive (vp=0xfffff803ae8b3760, td=0xfffff803ae23b620) at vnode_if.h:807 #13 0xffffffff80bbdcc7 in vputx (vp=0xfffff803ae8b3760, func=1) at /usr/src/sys/kern/vfs_subr.c:2688 #14 0xffffffff80bc5180 in sys_fchdir (td=0xfffff803ae23b620, uap=) at /usr/src/sys/kern/vfs_syscalls.c:724 #15 0xffffffff80f7c1c8 in amd64_syscall (td=0xfffff803ae23b620, traced=0) at subr_syscall.c:132 #16 0xffffffff80f5ae9d in fast_syscall_common () at /usr/src/sys/amd64/amd64/exception.S:494 #17 0x00000008008a99aa in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) From owner-freebsd-hackers@freebsd.org Mon Aug 27 06:52:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D8F1108EA57 for ; Mon, 27 Aug 2018 06:52:11 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9C8481505; Mon, 27 Aug 2018 06:52:10 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [78.46.172.2] (helo=sslproxy05.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1fuBNa-00031V-RR; Mon, 27 Aug 2018 08:52:02 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fuBNa-000Xcc-Li; Mon, 27 Aug 2018 08:52:02 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id A99AD2A165C; Mon, 27 Aug 2018 08:52:08 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Rgf0EljfkRGr; Mon, 27 Aug 2018 08:52:08 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 5B9F12A167E; Mon, 27 Aug 2018 08:52:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 76_l3KuxE3Km; Mon, 27 Aug 2018 08:52:08 +0200 (CEST) Received: from [192.168.96.149] (unknown [192.168.96.149]) by mail.embedded-brains.de (Postfix) with ESMTPSA id E4C2B2A165C; Mon, 27 Aug 2018 08:52:07 +0200 (CEST) Subject: Re: epoch(9) background information? To: Matthew Macy , freebsd-hackers@freebsd.org References: <15e3f080-2f82-a243-80e9-f0a916445828@embedded-brains.de> <26445c95-17c5-1a05-d290-0741d91b7721@embedded-brains.de> From: Sebastian Huber Message-ID: Date: Mon, 27 Aug 2018 08:51:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.100.1/24877/Mon Aug 27 06:46:55 2018) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 06:52:11 -0000 On 22/08/18 09:09, Matthew Macy wrote: >>> Yes. Very. It is generally not permitted to hold a mutex across >>> epoch_wait() that's why there's the special flag EPOCH_LOCKED. If you >>> have a very limited number of threads, you might want to have each >>> thread have its own record registered with the epoch. Then you >>> wouldn't need the CPU pinning. The pinning is just away of providing = a >>> limited number of records to an unbounded number of threads. >> Thanks for the prompt answer. >> >> Do I need a record per thread and per epoch? Could I use only one (may= be >> dependent on the nest level?) record per thread? >> >> > A record can only be registered with one epoch. And yes you can have ju= st > one single global epoch. However, then the epoch_wait_preempt time or = time > until the gc task is run is determined be the longest epoch section > globally. I think the thread pinning feature is absolutely necessary for an=20 efficient implementation. You have to avoid any atomic read-modify-write=20 operations in the fast path. For the preempt variants you have to=20 maintain a list of threads and for this you need per-processor list heads= . --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Mon Aug 27 08:13:13 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A60EE1090878; Mon, 27 Aug 2018 08:13:12 +0000 (UTC) (envelope-from philnorm@gmail.com) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D85D83AC5; Mon, 27 Aug 2018 08:13:12 +0000 (UTC) (envelope-from philnorm@gmail.com) Received: by mail-wr1-x444.google.com with SMTP id n2-v6so12714374wrw.7; Mon, 27 Aug 2018 01:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0bgO3GpE1mos18FEev2lRklp1PG1szfc8sn993T2c8M=; b=lcDxkmFq7VtSLIMmiUpofEOsGTk2LraouyCpncdwzy00XyjLZSrxI3nMlYXqQ/t51b yyJ/sdMImsd1DqDFfbNbL5RdL9nNq7r3oKwTuMtfPGrtO49T1GlFqyGHJPqh1jYtq+/x k/ORqOdrM67gyHzVlq21Ym97QSuVSiayHvbEZNcy3iwikA0+5BQK7Gf1KdxAQNOHAH/o Zc2oqimUqcnAaWecGp7DNQF+RoKrTNnXkVU/PZ3y7UgcX150dz3sloUNAvgAbcpKA7fU BiKvRMWoUpIVpvPVRMqB0CdIXv71KSnGV2ShLOsRdzKgCtvWHdBG4Ewla+nTIKhp8OYp 8WwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0bgO3GpE1mos18FEev2lRklp1PG1szfc8sn993T2c8M=; b=WDX/uz7YKz2VArpFlR7rhDBAUmdesYlAAOabKmDheH2ES8aAT7ANrpsI3PfCUEauwO tUN+/SCoyqxYpZ0Xw3CzpoB7OccdO+H4mYqHlu+I5HW2OufZ3vkWfUD3XWZetyFSm7Iv 9woavHGXE5A7iVpsjND2VygyE+6v/x6xAzcMVxGpgtf365l0veFnPF8iaZd1C0kguz8H X21KlxjJgge5NB/+Xr6oOA8P/HZRNPynyXV3Iw9ogSASNt/UkWLEBmxD1F66zxztcoX7 j5Zy8MKwAYjpDiqVN2c4psOAUvrfu3OKsUiUSvW22qzbfQttmAgbe6oiyvGUEmn3G3cO u62w== X-Gm-Message-State: APzg51DBay7eaMZD6FhWAiL8WCBsx2QKHX4Km1nfoBqaRuu7l2HyqWRG ZVGVLAQa9YkwTKknsx9vP4TU0cjm+WqGnnAccUpEXg== X-Google-Smtp-Source: ANB0Vdb2LbJzJiGmTO1dMbGQYWckJxL2k2ftOys/ET49RsoSNNcI6F8Cscstz5iD4jgGJ+gMoTGmDLLJidv5erCYrdY= X-Received: by 2002:adf:db51:: with SMTP id f17-v6mr7494456wrj.212.1535357590931; Mon, 27 Aug 2018 01:13:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:c204:0:0:0:0:0 with HTTP; Mon, 27 Aug 2018 01:13:10 -0700 (PDT) In-Reply-To: References: From: Phil Norman Date: Mon, 27 Aug 2018 10:13:10 +0200 Message-ID: Subject: Re: Help diagnose my Ryzen build problem To: Meowthink Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org X-Mailman-Approved-At: Mon, 27 Aug 2018 10:40:10 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 08:13:13 -0000 Hi. I have a similar setup: Ryzen 3 and Fatal1ty X370 mini-ITX. I had some trouble with instability, although my problems weren't panics, but rather two issues. One was random lockups (with no evidence left in logs), but I *think* this was down to an inadequately cooled graphics card. The other problem I had was with USB. I got quite a spam of log messages about the USB reinitialisation. However, eventually I figured out that the problem didn't occur if I booted the system from a completely powered-down state. That is, use the physical switch on the PSU to cut power entirely, re-enable, then boot from that state. Since then I've had 67 days of uninterrupted uptime, with no USB issues at all. It sounds like your problem is different, but trying a boot-from-cold might be worthwhile, just in case ASRock have a consistent problem in this regard. Cheers, Phil On 26 August 2018 at 13:20, Meowthink wrote: > Hello all, > > Recently I tried to build up a Ryzen system and run FreeBSD on it. > CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics (0x810f10) > Mobo: Asrock Fatal1ty AB350 Gaming-ITX/ac ( with up-to-date BIOS with > PinnaclePI-AM4_1.0.0.4, microcode 0x810100b ) > Mem: 2x Crucial 16GB DDR4-2400 EUDIMM CL17 ( ECC Unregistered but ECC > actually won't work :( ) > > But the system is unstable - it can't last few days even is nearly > idle. System panics even at midnight. It almost panic while or after I > built something large. Surprisly I didn't encourage a user program > fault, bad binaries built etc., panics only. > > Then I tried lots of BIOS settings e.g. SMT, C6 idle current, > underclock RAM, but none seems effect. > It could pass memtest86 V7.5 without error, or various benchmarks > under Windows. thus I think the problem is not in the hardware but > software. > > In the mean time, I realized that the rate of irqs from xhci0 are too > high - it's about 1998/s. I found [1] and tried to MFC r331665. It > didn't fix the problem though, but disabling that bluetooth module > stops the irq storm, after all. > > Then the system lasts much longer before panic. It eventually can > compile ports tree, build the world, scrub the zpool, all done without > annoying reboots. > Then I assume this is [2] related? So I also tried cpuctl, bounding > all processes to 2-7. > But the problem is still there, only the chance become very low. It > still panics occasionally, idling a week or stressing few hours - > Stress seems to rise the chance of panic, but differently by types. > Things like llvm will always build, but gcc will cause a panic per few > passes. > > The system was 11.2 but then moved on to stable/11 (r337906 > currently). I've got last 10 coredumps saved but my kernel isn't > compile as debug. So I'll put some backtrace from core.txt.? in the > end. > > Indeed I want to eliminate this problem. Could someone guide me how to > figure out the problem? What should I try next? > > Best regards, > Meowthink > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224886 > [2] https://reviews.freebsd.org/D11780 > > Backtraces newer - older: > ------------------------------------------------------------------------ > Panic while compiling gcc: > > #0 doadump (textdump=) at pcpu.h:230 > 230 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:230 > #1 0xffffffff80afa5fb in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:383 > #2 0xffffffff80afaa21 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:776 > #3 0xffffffff80afa863 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:707 > #4 0xffffffff80f7c14f in trap_fatal (frame=0xfffffe081e962790, > eva=18446735309538549504) at /usr/src/sys/amd64/amd64/trap.c:877 > #5 0xffffffff80f7c1a9 in trap_pfault (frame=0xfffffe081e962790, > usermode=0) > at pcpu.h:230 > #6 0xffffffff80f7b984 in trap (frame=0xfffffe081e962790) > at /usr/src/sys/amd64/amd64/trap.c:415 > #7 0xffffffff80f5bccc in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:231 > #8 0xffffffff822950a8 in arc_change_state () > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1800 > #9 0xffffffff8229328b in arc_access () at time.h:145 > #10 0xffffffff82296232 in arc_write_done (zio=0xfffff8065f886410) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:6169 > #11 0xffffffff82334cbe in zio_done (zio=) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:4032 > #12 0xffffffff8233070c in zio_execute (zio=0xfffff8065f886410) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1768 > #13 0xffffffff80b52cc4 in taskqueue_run_locked (queue=0xfffff8000d9e6e00) > at /usr/src/sys/kern/subr_taskqueue.c:463 > #14 0xffffffff80b53e28 in taskqueue_thread_loop (arg=) > at /usr/src/sys/kern/subr_taskqueue.c:755 > #15 0xffffffff80abd813 in fork_exit ( > callout=0xffffffff80b53d90 , > arg=0xfffff8000d967030, frame=0xfffffe081e962ac0) > at /usr/src/sys/kern/kern_fork.c:1072 > #16 0xffffffff80f5cc7e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:972 > #17 0x0000000000000000 in ?? () > Current language: auto; currently minimal > (kgdb) > > ------------------------------------------------------------------------ > backtrace panic when shuting down: > > #0 doadump (textdump=) at pcpu.h:230 > 230 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:230 > #1 0xffffffff80afa5fb in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:383 > #2 0xffffffff80afaa21 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:776 > #3 0xffffffff80afa863 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:707 > #4 0xffffffff80f7c14f in trap_fatal (frame=0xfffffe081ed30700, eva=0) > at /usr/src/sys/amd64/amd64/trap.c:877 > #5 0xffffffff80f7c1a9 in trap_pfault (frame=0xfffffe081ed30700, > usermode=0) > at pcpu.h:230 > #6 0xffffffff80f7b984 in trap (frame=0xfffffe081ed30700) > at /usr/src/sys/amd64/amd64/trap.c:415 > #7 0xffffffff80f5bccc in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:231 > #8 0xffffffff80dfe4ad in vm_object_terminate (object=0xfffff805bf66d5a0) > at /usr/src/sys/vm/vm_object.c:768 > #9 0xffffffff80dfd0f8 in vm_object_deallocate (object=0x0) > at /usr/src/sys/vm/vm_object.c:677 > #10 0xffffffff80df3189 in _vm_map_unlock (map=, > file=, line=) > at /usr/src/sys/vm/vm_map.c:2939 > #11 0xffffffff80df7be2 in vm_map_remove (map=0xfffff80018673000, > start=4096, > end=140737488351232) at /usr/src/sys/vm/vm_map.c:3137 > #12 0xffffffff80df2e49 in vmspace_exit (td=0xfffff80039ec0620) > at /usr/src/sys/vm/vm_map.c:337 > #13 0xffffffff80ab72b9 in exit1 (td=0xfffff80039ec0620, > rval=, signo=) > at /usr/src/sys/kern/kern_exit.c:401 > #14 0xffffffff80ab6ced in sys_sys_exit (td=, > uap=) at /usr/src/sys/kern/kern_exit.c:180 > #15 0xffffffff80f7d1d8 in amd64_syscall (td=0xfffff80039ec0620, traced=0) > at subr_syscall.c:132 > #16 0xffffffff80f5c5ad in fast_syscall_common () > at /usr/src/sys/amd64/amd64/exception.S:494 > #17 0x00000008028d034a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > ------------------------------------------------------------------------ > Panic while only running my single thread python script > > #0 doadump (textdump=) at pcpu.h:230 > 230 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:230 > #1 0xffffffff80afa5fb in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:383 > #2 0xffffffff80afaa21 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:776 > #3 0xffffffff80afa863 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:707 > #4 0xffffffff80f7c14f in trap_fatal (frame=0xfffffe081f635ec0, eva=952) > at /usr/src/sys/amd64/amd64/trap.c:877 > #5 0xffffffff80f7c1a9 in trap_pfault (frame=0xfffffe081f635ec0, > usermode=0) > at pcpu.h:230 > #6 0xffffffff80f7b984 in trap (frame=0xfffffe081f635ec0) > at /usr/src/sys/amd64/amd64/trap.c:415 > #7 0xffffffff80f5bccc in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:231 > #8 0xffffffff80af57ad in __rw_wlock_hard (c=0xfffff80016f8f798, > v=) at /usr/src/sys/kern/kern_rwlock.c:977 > #9 0xffffffff80bbca92 in bufobj_invalbuf (bo=, > flags=1, > slpflag=1017770744, slptimeo=) > at /usr/src/sys/kern/vfs_subr.c:1609 > #10 0xffffffff80bbf8be in vgonel (vp=0xfffff8053ca9f1d8) > at /usr/src/sys/kern/vfs_subr.c:1655 > #11 0xffffffff80bbbcc4 in vnlru_free_locked (count=1, mnt_op=0x0) > at /usr/src/sys/kern/vfs_subr.c:1227 > #12 0xffffffff80bbbe14 in getnewvnode_reserve (count=1) > at /usr/src/sys/kern/vfs_subr.c:1287 > #13 0xffffffff82327fb4 in zfs_zget (zfsvfs=0xfffff80076574000, > obj_num=34941, > zpp=0xfffffe081f6362a8) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ > zfs_znode.c:1122 > #14 0xffffffff823421ad in zfs_dirent_lookup (dzp=0xfffff804ff94e420, > name=0xfffffe081f6363e0 "filename.ext", zpp=0xfffffe081f6362a8, flag=2) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ > zfs_dir.c:187 > #15 0xffffffff82342267 in zfs_dirlook (dzp=0xfffff804ff94e420, > name=, zpp=0xfffffe081f636360) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ > zfs_dir.c:238 > #16 0xffffffff8235a4ef in zfs_lookup () > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ > zfs_vnops.c:1658 > #17 0xffffffff8235ac1e in zfs_freebsd_lookup (ap=0xfffffe081f636548) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ > zfs_vnops.c:4956 > #18 0xffffffff810fe89c in VOP_CACHEDLOOKUP_APV (vop=, > a=0xfffffe081f636548) at vnode_if.c:195 > #19 0xffffffff80ba8d56 in vfs_cache_lookup (ap=) > at vnode_if.h:80 > #20 0xffffffff810fe77c in VOP_LOOKUP_APV (vop=, > a=0xfffffe081f636610) at vnode_if.c:127 > #21 0xffffffff80bb2761 in lookup (ndp=0xfffffe081f636748) at vnode_if.h:54 > #22 0xffffffff80bb1c29 in namei (ndp=0xfffffe081f636748) > at /usr/src/sys/kern/vfs_lookup.c:448 > #23 0xffffffff80bc8238 in kern_statat (td=0xfffff8013ba1b620, > flag=, fd=-100, > path=0x80332c910
, > pathseg=UIO_USERSPACE, sbp=0xfffffe081f636900, hook=0) > at /usr/src/sys/kern/vfs_syscalls.c:2023 > #24 0xffffffff80bc817d in sys_stat (td=, > uap=0xfffff8013ba1bb58) at /usr/src/sys/kern/vfs_syscalls.c:1978 > #25 0xffffffff80f7d1d8 in amd64_syscall (td=0xfffff8013ba1b620, traced=0) > at subr_syscall.c:132 > #26 0xffffffff80f5c5ad in fast_syscall_common () > at /usr/src/sys/amd64/amd64/exception.S:494 > #27 0x0000000801a5b9ca in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > ------------------------------------------------------------------------ > Panic while using mplayer > > #0 doadump (textdump=) at pcpu.h:230 > 230 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:230 > #1 0xffffffff80af91cb in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:383 > #2 0xffffffff80af95f1 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:776 > #3 0xffffffff80af9433 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:707 > #4 0xffffffff80f7a13f in trap_fatal (frame=0xfffffe081f70d380, eva=0) > at /usr/src/sys/amd64/amd64/trap.c:877 > #5 0xffffffff80f7a199 in trap_pfault (frame=0xfffffe081f70d380, > usermode=0) > at pcpu.h:230 > #6 0xffffffff80f79974 in trap (frame=0xfffffe081f70d380) > at /usr/src/sys/amd64/amd64/trap.c:415 > #7 0xffffffff80f5a00c in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:231 > #8 0xffffffff8088c030 in hdac_stream_start (dev=, > child=, dir=0, stream=1, buf=1889533952, > blksz=2048, > blkcnt=2) at /usr/src/sys/dev/sound/pci/hda/hdac.c:1927 > #9 0xffffffff8088437d in hdaa_channel_start (ch=) > at hdac_if.h:84 > #10 0xffffffff80887e0d in hdaa_channel_trigger (obj=, > data=0xfffff8007102c480, go=1) > at /usr/src/sys/dev/sound/pci/hda/hdaa.c:2161 > #11 0xffffffff80893b8e in chn_trigger (c=0xfffff80071058400, go=1) > at channel_if.h:131 > #12 0xffffffff8089751b in chn_notify (c=0xfffff80071058400, > flags=) at /usr/src/sys/dev/sound/pcm/ > channel.c:2281 > #13 0xffffffff808b697f in vchan_trigger (obj=, > data=, go=1) > at /usr/src/sys/dev/sound/pcm/vchan.c:171 > #14 0xffffffff80893b8e in chn_trigger (c=0xfffff80071057c00, go=1) > at channel_if.h:131 > #15 0xffffffff8089de10 in dsp_ioctl (i_dev=, > cmd=, arg=0xfffffe081f70d8d0 "\003", > mode=, td=) > at /usr/src/sys/dev/sound/pcm/dsp.c:1733 > #16 0xffffffff809c5b38 in devfs_ioctl_f (fp=0xfffff802c5563c80, > com=2147766288, data=0xfffffe081f70d8d0, cred=0xfffff8004c482500, > td=0xfffff802f24ac000) at /usr/src/sys/fs/devfs/devfs_vnops.c:791 > #17 0xffffffff80b5c00d in kern_ioctl (td=0xfffff802f24ac000, fd=51, > com=2147766288, data=) at file.h:323 > #18 0xffffffff80b5bd2c in sys_ioctl (td=0xfffff802f24ac000, > uap=0xfffff802f24ac538) at /usr/src/sys/kern/sys_generic.c:745 > #19 0xffffffff80f7b1c8 in amd64_syscall (td=0xfffff802f24ac000, traced=0) > at subr_syscall.c:132 > #20 0xffffffff80f5a8ed in fast_syscall_common () > at /usr/src/sys/amd64/amd64/exception.S:494 > #21 0x0000000801fb94aa in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > ------------------------------------------------------------------------ > Panic while ilde, seems like cronjobs triggered ZFS ARC cleanup. > > #0 doadump (textdump=) at pcpu.h:230 > 230 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:230 > #1 0xffffffff80af95fb in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:383 > #2 0xffffffff80af9a21 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:776 > #3 0xffffffff80af9863 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:707 > #4 0xffffffff80f7b13f in trap_fatal (frame=0xfffffe081ee186e0, > eva=201697507) > at /usr/src/sys/amd64/amd64/trap.c:877 > #5 0xffffffff80f7b199 in trap_pfault (frame=0xfffffe081ee186e0, > usermode=0) > at pcpu.h:230 > #6 0xffffffff80f7a974 in trap (frame=0xfffffe081ee186e0) > at /usr/src/sys/amd64/amd64/trap.c:415 > #7 0xffffffff80f5a5bc in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:231 > #8 0xffffffff80ad596e in free (addr=0xfffff802472af200, > mtp=0xffffffff825bfc00) at /usr/src/sys/kern/kern_malloc.c:583 > #9 0xffffffff8232a667 in zfs_inactive (vp=, > cr=, ct=) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ > zfs_vnops.c:4333 > #10 0xffffffff82332a1d in zfs_freebsd_inactive (ap=) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ > zfs_vnops.c:5364 > #11 0xffffffff810ff6b2 in VOP_INACTIVE_APV (vop=, > a=0xfffffe081ee18858) at vnode_if.c:1955 > #12 0xffffffff80bbd7bc in vinactive (vp=0xfffff803ae8b3760, > td=0xfffff803ae23b620) at vnode_if.h:807 > #13 0xffffffff80bbdcc7 in vputx (vp=0xfffff803ae8b3760, func=1) > at /usr/src/sys/kern/vfs_subr.c:2688 > #14 0xffffffff80bc5180 in sys_fchdir (td=0xfffff803ae23b620, > uap=) at /usr/src/sys/kern/vfs_syscalls.c:724 > #15 0xffffffff80f7c1c8 in amd64_syscall (td=0xfffff803ae23b620, traced=0) > at subr_syscall.c:132 > #16 0xffffffff80f5ae9d in fast_syscall_common () > at /usr/src/sys/amd64/amd64/exception.S:494 > #17 0x00000008008a99aa in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Aug 27 11:29:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B45911085376; Mon, 27 Aug 2018 11:29:09 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25CD78B020; Mon, 27 Aug 2018 11:29:09 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x433.google.com with SMTP id g33-v6so13287554wrd.1; Mon, 27 Aug 2018 04:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=hQ77OWRHSl94iINyQOigBQKRUtmzaGVEgeJn+/7HZmk=; b=mrxrvZM+6lbOf2q4G+RIqTksWDLQ8wP281rLkYT9zctjxznbp+a3EnZuEBEy/6SHHZ U9sz4IzCIiyGNqlcio9I9aQjmwhTm7DnHbLDu9DkYG+ByGdFDhqAfRafB+C3pHUnD1nd wuY7/e1VADqotzfkmJT41a71FkXwYrABKqoGy6vVMo5v6af5TGyFNOnmAUMO6+fBR7Hk KyPF4niFDlAxifu5cN5scQ38iItybiRH7Da4iqMQoqjFE8xCNYprxR0ryVqWn4TPsGkH 0Q5XApG67O/uAXBpbgXHasYDm062kGFHHO6c0Jb8T8vFCsCM9ybbCW7jlcDya+xnYoP9 3k4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=hQ77OWRHSl94iINyQOigBQKRUtmzaGVEgeJn+/7HZmk=; b=H5g56M42ELSywSkYpfDCsXIhvP5NwQUq/9S4WmKR5L/b7M1nafrADZcHYV5SnD56Af NLuRsUePeXU8g8+NRK3lvijiK4vNX1pYM0rexEmFlNhTkb1u94o3tMMn4SRaV3any/H0 17+iu8IamncfPQcoK+Sq3SsGhaWAjKpRR7GXjTHj7jgnseIZaLa8ZdQGUllu0C44uyxk FvqtQqdWrxy1v+2TcXMnzxzMiVRTPL8jyhg9uQXgnQw3KwqxIQfCG5HLZxaMosS5kzPo b1xK1rQ30hqqd0okaA8f7Txyjh1bS82H6nM3zYbD0lHP63NTK26CE2VbaD49XS8YT2/C aFkA== X-Gm-Message-State: APzg51B4Ez1L+GYNouAaysQxaS5XZHlFbCw6CNHFUGz0AdqNEt1DP427 4nfmIi3tGO8B8LUVdKKE/qk= X-Google-Smtp-Source: ANB0VdY4pH0ivcU1OkD9S5J+9U/L4CAgLyvASaqU0WyYuaTEFg2vjeyb02DEoYwWvFx+bUJPMlb32w== X-Received: by 2002:adf:f906:: with SMTP id b6-v6mr7974552wrr.28.1535369348131; Mon, 27 Aug 2018 04:29:08 -0700 (PDT) Received: from ernst.home (pD9E23C49.dip0.t-ipconnect.de. [217.226.60.73]) by smtp.gmail.com with ESMTPSA id h82-v6sm7932892wme.11.2018.08.27.04.29.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 27 Aug 2018 04:29:07 -0700 (PDT) Date: Mon, 27 Aug 2018 13:29:05 +0200 From: Gary Jennejohn To: Phil Norman Cc: Meowthink , freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Help diagnose my Ryzen build problem Message-ID: <20180827132905.191dbd8c@ernst.home> In-Reply-To: References: Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 11:29:10 -0000 On Mon, 27 Aug 2018 10:13:10 +0200 Phil Norman wrote: > Hi. > > I have a similar setup: Ryzen 3 and Fatal1ty X370 mini-ITX. I had some > trouble with instability, although my problems weren't panics, but rather > two issues. One was random lockups (with no evidence left in logs), but I > *think* this was down to an inadequately cooled graphics card. > I had instability problems with my Ryzen 5 - lockups for no apparent reason. The only recourse waas a hard reset. It turned out that there were two causes 1) old CPU microcode 2) unhandled errate in the CPU I installed the /usr/ports/sysutils/devcpu-data port, which allowed me to install the latest microcode using cpucontrol(8). I also used a shell script called amd_errata.sh provided by one of the FreeBSD committers. To my shame I can't remember exactly who. Note that the errata fixups are now part of the kernel in FreeBSD 12. After taking these steps about two months ago I have had no more lockups and the machine runs very stabily. [big snip] -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Mon Aug 27 12:18:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3B9510877EA; Mon, 27 Aug 2018 12:18:48 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42A198D409; Mon, 27 Aug 2018 12:18:48 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: by mail-oi0-x22f.google.com with SMTP id p84-v6so26849230oic.4; Mon, 27 Aug 2018 05:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VZ5Gi/lOxPRe7k2qxPxDchYAPQ6GxDP3w/jNHlovBdI=; b=m1LN+GPP1rimYfXSnxJIMAmSI01quK7V8WANQJlZaNA8r4k1cXjfiXWoa8whJ7Ug/r qy8MU5OslbTYpXBxlNSN9Z14NyI/JtSeSmXx8HBMNXB58cwdfJJt953LqJOYcivJbPzn QqC066bLudpzZLZQONN/9a5zTSn7FEpVmdngDpzqWn1V5VsMINhv5MhkBhjWFiS386X9 MSH4FAY6ibzj2y5JH9dhpVxXGtFicnd01mGR403NXciNIhJzhITGlVV1/Fv55sftNkGH kg9gIb5KCcspPa15ol8zmhte8zr2Bs6pOU8pGKaAZ0pioC81MJk9i4ybPi3YekQKPl9N /LHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VZ5Gi/lOxPRe7k2qxPxDchYAPQ6GxDP3w/jNHlovBdI=; b=BEGRqr4/Y3Fgs2stxBsqWGAQDLyTpUrEAKEWMjo+PGxx/3W2T5PKnjwI1aLyAz4L8Q B7h5BYU/u6dASil1dzMRSnB1ZVU5/XpWm3GWhfyq8+Zyql/Tg/l9t9cuGP3jQ+BG6Jn9 RrBa5TdG6S19bX+Cow1driQ168ooC3u5J+RF8YUbTtud3a96zckdC5wO5yaLH1fS+Eo5 NMlsRVj9fR+YzNRtzc/Vay4rIhtvbMf+IFxt+SkSKrr6q0f0wX20doYz99vKepiSq7du 6FDWP638pYD6oRNGQZr8/ejq3ncE15qxt86zM4gZmBOoksMZGcPU+yV8PAZNzBxxaSlo zBvA== X-Gm-Message-State: APzg51BGXGJybYr7qlbo2sV+68O7f1w/yzFSvLvW+jJqH064mb/+3ANg EDtEioV3KBe81wOJhtorWza+ZMnZDi+TWknObRI= X-Google-Smtp-Source: ANB0VdbxEhAccjQjMEIQt27Vf43BtYaeSN1LeJUZ8QDPsP/VrjhNLhQO9WZQNsdE2R/9mz1UgBJfWD+q9kcsESLBG98= X-Received: by 2002:aca:c2c1:: with SMTP id s184-v6mr11554339oif.117.1535372327455; Mon, 27 Aug 2018 05:18:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:5ac4:0:0:0:0:0 with HTTP; Mon, 27 Aug 2018 05:18:46 -0700 (PDT) In-Reply-To: <20180827132905.191dbd8c@ernst.home> References: <20180827132905.191dbd8c@ernst.home> From: Meowthink Date: Mon, 27 Aug 2018 20:18:46 +0800 Message-ID: Subject: Re: Help diagnose my Ryzen build problem To: gljennjohn@gmail.com Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 12:18:48 -0000 Hi Gary, On 8/27/18, Gary Jennejohn wrote: > On Mon, 27 Aug 2018 10:13:10 +0200 > Phil Norman wrote: > >> Hi. >> >> I have a similar setup: Ryzen 3 and Fatal1ty X370 mini-ITX. I had some >> trouble with instability, although my problems weren't panics, but rather >> two issues. One was random lockups (with no evidence left in logs), but I >> *think* this was down to an inadequately cooled graphics card. >> > > I had instability problems with my Ryzen 5 - lockups for no > apparent reason. The only recourse waas a hard reset. > > It turned out that there were two causes > 1) old CPU microcode > 2) unhandled errate in the CPU > > I installed the /usr/ports/sysutils/devcpu-data port, which > allowed me to install the latest microcode using cpucontrol(8). > > I also used a shell script called amd_errata.sh provided by one of > the FreeBSD committers. To my shame I can't remember exactly > who. Note that the errata fixups are now part of the kernel in > FreeBSD 12. That's kib, who has committed things in that script to both 12 [1] and stable/11 [2]. Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my Ryzen 5 2400G's model is 11h. On the microcode. It shall be updated through UEFI/BIOS updates. I think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel 0x810100b. Seems like ... the only thing I can do is sit down and wait? > > After taking these steps about two months ago I have had no more > lockups and the machine runs very stabily. > > [big snip] > > -- > Gary Jennejohn > [1] https://svnweb.freebsd.org/base?view=revision&revision=336763 [2] https://svnweb.freebsd.org/base?view=revision&revision=337235 From owner-freebsd-hackers@freebsd.org Mon Aug 27 12:37:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6212910883A3 for ; Mon, 27 Aug 2018 12:37:00 +0000 (UTC) (envelope-from mitchell@wyatt672earp.force9.co.uk) Received: from avasout06.plus.net (avasout06.plus.net [212.159.14.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEC678E152 for ; Mon, 27 Aug 2018 12:36:59 +0000 (UTC) (envelope-from mitchell@wyatt672earp.force9.co.uk) Received: from [192.168.1.64] ([146.90.233.111]) by smtp with ESMTPA id uGdxfTGNYWLW2uGdyfacK7; Mon, 27 Aug 2018 13:29:19 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.3 cv=fJUXI6Se c=1 sm=1 tr=0 a=DmGL1Jmrymuc02ZlcP2exw==:117 a=DmGL1Jmrymuc02ZlcP2exw==:17 a=IkcTkHD0fZMA:10 a=pGLkceISAAAA:8 a=waDbaBDWxNZZftWFd3gA:9 a=QEXdDO2ut3YA:10 X-AUTH: wyatt672earp@:2501 Subject: Ryzen Build Problem To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org References: From: Mitchell Message-ID: <32e008cf-93d3-944d-9b11-e56f1bb425ef@wyatt672earp.force9.co.uk> Date: Mon, 27 Aug 2018 13:28:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfPKOm9vFqyk4eCNNBpC8gkfvEmgRsRb0+kkEFGKHRv8QciQLb223GOzgbXXmDu7Pq2GgeiC/qXDCq/6DdenNIjUHqCARgPkuNSRiJXTG/4iCxroZPA2+ s8U5r1QatzsLoo/Ml4C4oVI5x1/sDXba7/KVxIGEhr6sF4rVfQ12S2e/r79sgaCxVo0deGk80ST9ig== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 12:37:00 -0000 Hi Meowthink: I'm planning a Home Build, and I came across an issue which might apply to your design. Some AMD CPUs are designed for Over-Clocking automatically. But when I investigated Memory Compatibility I saw that some Memory wasn't. The "AMD Ryzen 5 2400G" looks like it can Over-Clock itself when it feels safe to do so. But the "Crucial 16GB DDR4-2400 EUDIMM CL17" seems to be classified as Server Memory, which could mean it's designed for a single speed. I couldn't find more details about Crucial Memory Over-Clocking. The Crucial Web Pages do feature a Help Facility which might enable you to check further if you input all your system details. I'm no expert here. This will be my first Home Build attempt and I haven't even started yet. You probably need a 2nd and 3rd opinion on this topic. I'm just hoping my contribution will prompt further comments from FreeBSD people with more know-how than I've got. Yours truly: Frank Mitchell On 27/08/18 09:13, Phil Norman wrote: > Hi. > > I have a similar setup: Ryzen 3 and Fatal1ty X370 mini-ITX. I had some > trouble with instability, although my problems weren't panics, but rather > two issues. One was random lockups (with no evidence left in logs), but I > *think* this was down to an inadequately cooled graphics card. > > The other problem I had was with USB. I got quite a spam of log messages > about the USB reinitialisation. However, eventually I figured out that the > problem didn't occur if I booted the system from a completely powered-down > state. That is, use the physical switch on the PSU to cut power entirely, > re-enable, then boot from that state. Since then I've had 67 days of > uninterrupted uptime, with no USB issues at all. > > It sounds like your problem is different, but trying a boot-from-cold might > be worthwhile, just in case ASRock have a consistent problem in this regard. > > Cheers, > Phil > > On 26 August 2018 at 13:20, Meowthink wrote: > >> Hello all, >> >> Recently I tried to build up a Ryzen system and run FreeBSD on it. >> CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics (0x810f10) >> Mobo: Asrock Fatal1ty AB350 Gaming-ITX/ac ( with up-to-date BIOS with >> PinnaclePI-AM4_1.0.0.4, microcode 0x810100b ) >> Mem: 2x Crucial 16GB DDR4-2400 EUDIMM CL17 ( ECC Unregistered but ECC >> actually won't work :( ) >> >> But the system is unstable - it can't last few days even is nearly >> idle. System panics even at midnight. It almost panic while or after I >> built something large. Surprisly I didn't encourage a user program >> fault, bad binaries built etc., panics only. >> >> Then I tried lots of BIOS settings e.g. SMT, C6 idle current, >> underclock RAM, but none seems effect. >> It could pass memtest86 V7.5 without error, or various benchmarks >> under Windows. thus I think the problem is not in the hardware but >> software. >> >> In the mean time, I realized that the rate of irqs from xhci0 are too >> high - it's about 1998/s. I found [1] and tried to MFC r331665. It >> didn't fix the problem though, but disabling that bluetooth module >> stops the irq storm, after all. >> >> Then the system lasts much longer before panic. It eventually can >> compile ports tree, build the world, scrub the zpool, all done without >> annoying reboots. >> Then I assume this is [2] related? So I also tried cpuctl, bounding >> all processes to 2-7. >> But the problem is still there, only the chance become very low. It >> still panics occasionally, idling a week or stressing few hours - >> Stress seems to rise the chance of panic, but differently by types. >> Things like llvm will always build, but gcc will cause a panic per few >> passes. >> >> The system was 11.2 but then moved on to stable/11 (r337906 >> currently). I've got last 10 coredumps saved but my kernel isn't >> compile as debug. So I'll put some backtrace from core.txt.? in the >> end. >> >> Indeed I want to eliminate this problem. Could someone guide me how to >> figure out the problem? What should I try next? >> >> Best regards, >> Meowthink >> From owner-freebsd-hackers@freebsd.org Mon Aug 27 12:57:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1673D1088A19; Mon, 27 Aug 2018 12:57:25 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2752D8EB42; Mon, 27 Aug 2018 12:57:24 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id b19-v6so8012716wme.3; Mon, 27 Aug 2018 05:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PrB/yn1UqKp2E6EZS/zCu2T/S8JDKrmCSLBA3n32Sns=; b=SKiaKjLpqCMj3HcMY52afiClwCMj60qCEoCw0AxzorMp/uROIkTUduOPCB725PCf8m WaBoNe5OoFaamb8M/uOyI+mwk1+4JjayIrPZyl6uih+0QtIaU+QFH5yHehlaCi3dhl0z VBJjliQ0+XIkbWrjcijR5TxUL7GxdWIytO0BRhQQ67l2VD/NesXtpTMiW9yt3DAon943 ldWx9hYvAoyfa4BInTnPqsZh6EWOB83Zd0/OD9L5FOVnK7bDZkhiZE00C+98oXBqkmP0 KLYVziatCwXXUSEmm+mht/I4ePAVGQG2Elwyb4lNkVBqkxqGDkr2WQI28etZlyKLHK7V Q6Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PrB/yn1UqKp2E6EZS/zCu2T/S8JDKrmCSLBA3n32Sns=; b=ihd5AbJjKdRDW8GSAPwvpc7sirNrsa8lpbGhzrgIH7nh7AAYc8kKVO/Y/83KiXR2jP XSrdlpwxzciPRwrjxJtahrrQNNo0KnmqXLlLXG4b6KJZWInmMfL2zb4GMIQWv0V3Xlju kPX2RFNPPvITaAg6rSg4yvbTr2UBN+RyICtwf5DYze/GF849uiINfjS02X3W0bRstQUe yZ1YXf4REwRaYIlvjcKL6MPlfPfBNvmc57ijlRZ4JReNhxHxH64VpOAeWUE6gX/SPHTe U7P1tTPqt4AbV8TYuoDTwi9hsjgvpTSLgeRqhzsDXvIts8WoN/PIPXEB55RAV+PIbDaC c8ig== X-Gm-Message-State: APzg51CezcaEEmGA8tEpG4hrkL7C7Ajz1WbEwHC+G0pCS9DX8Oxbux8q foyNdjn5zz7JqJwZtNyYOjadjSezSwd09Ga4EXU= X-Google-Smtp-Source: ANB0VdZP18u5mCq+g54E4amPFmo0/4UxbwihtP3Wr6G8TxvWIEI/sFxW798mSy3meTKG14pFtBRmaYl9j8XCQd9lLKY= X-Received: by 2002:a1c:2351:: with SMTP id j78-v6mr5672606wmj.68.1535374642535; Mon, 27 Aug 2018 05:57:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Johannes Lundberg Date: Mon, 27 Aug 2018 14:56:45 +0200 Message-ID: Subject: Re: Help diagnose my Ryzen build problem To: Meowthink Cc: Freebsd hackers list , freebsd-stable@freebsd.org X-Mailman-Approved-At: Mon, 27 Aug 2018 13:00:20 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 12:57:26 -0000 On Sun, Aug 26, 2018 at 1:27 PM Meowthink wrote: > Hello all, > > Recently I tried to build up a Ryzen system and run FreeBSD on it. > CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics (0x810f10) > Mobo: Asrock Fatal1ty AB350 Gaming-ITX/ac ( with up-to-date BIOS with > PinnaclePI-AM4_1.0.0.4, microcode 0x810100b ) > Mem: 2x Crucial 16GB DDR4-2400 EUDIMM CL17 ( ECC Unregistered but ECC > actually won't work :( ) > > But the system is unstable - it can't last few days even is nearly > idle. System panics even at midnight. It almost panic while or after I > built something large. Surprisly I didn't encourage a user program > fault, bad binaries built etc., panics only. > > Then I tried lots of BIOS settings e.g. SMT, C6 idle current, > underclock RAM, but none seems effect. > It could pass memtest86 V7.5 without error, or various benchmarks > under Windows. thus I think the problem is not in the hardware but > software. > > In the mean time, I realized that the rate of irqs from xhci0 are too > high - it's about 1998/s. I found [1] and tried to MFC r331665. It > didn't fix the problem though, but disabling that bluetooth module > stops the irq storm, after all. > > Then the system lasts much longer before panic. It eventually can > compile ports tree, build the world, scrub the zpool, all done without > annoying reboots. > Then I assume this is [2] related? So I also tried cpuctl, bounding > all processes to 2-7. > But the problem is still there, only the chance become very low. It > still panics occasionally, idling a week or stressing few hours - > Stress seems to rise the chance of panic, but differently by types. > Things like llvm will always build, but gcc will cause a panic per few > passes. > > The system was 11.2 but then moved on to stable/11 (r337906 > currently). I've got last 10 coredumps saved but my kernel isn't > compile as debug. So I'll put some backtrace from core.txt.? in the > end. > > Indeed I want to eliminate this problem. Could someone guide me how to > figure out the problem? What should I try next? > > Best regards, > Meowthink > Hi I have a similar setup and also experience random hard resets without a kernel dump. FreeBSD usually can run days, Windows 10 (fresh install I think) doesn=E2=80=99t last more than a few minutes before BSOD. Windows 10 came with the thing when I bought it. I can't run windows update or anything since it hangs so soon. The box came with an earlier mobo+cpu that I replaced with a ASRock+Ryzen. The earlier AMD Kaveri was stable in both Windows (I think) and FreeBSD. On occasion I get kernel panic directly in early boot. See attached image. I am running cpu microcode update in rc.conf. > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224886 > [2] https://reviews.freebsd.org/D11780 > > Backtraces newer - older: > ------------------------------------------------------------------------ > Panic while compiling gcc: > > #0 doadump (textdump=3D) at pcpu.h:230 > 230 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=3D) at pcpu.h:230 > #1 0xffffffff80afa5fb in kern_reboot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:383 > #2 0xffffffff80afaa21 in vpanic (fmt=3D, > ap=3D) at /usr/src/sys/kern/kern_shutdown.c:776 > #3 0xffffffff80afa863 in panic (fmt=3D) > at /usr/src/sys/kern/kern_shutdown.c:707 > #4 0xffffffff80f7c14f in trap_fatal (frame=3D0xfffffe081e962790, > eva=3D18446735309538549504) at /usr/src/sys/amd64/amd64/trap.c:877 > #5 0xffffffff80f7c1a9 in trap_pfault (frame=3D0xfffffe081e962790, > usermode=3D0) > at pcpu.h:230 > #6 0xffffffff80f7b984 in trap (frame=3D0xfffffe081e962790) > at /usr/src/sys/amd64/amd64/trap.c:415 > #7 0xffffffff80f5bccc in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:231 > #8 0xffffffff822950a8 in arc_change_state () > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1800 > #9 0xffffffff8229328b in arc_access () at time.h:145 > #10 0xffffffff82296232 in arc_write_done (zio=3D0xfffff8065f886410) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:6169 > #11 0xffffffff82334cbe in zio_done (zio=3D) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:4032 > #12 0xffffffff8233070c in zio_execute (zio=3D0xfffff8065f886410) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1768 > #13 0xffffffff80b52cc4 in taskqueue_run_locked (queue=3D0xfffff8000d9e6e0= 0) > at /usr/src/sys/kern/subr_taskqueue.c:463 > #14 0xffffffff80b53e28 in taskqueue_thread_loop (arg=3D) > at /usr/src/sys/kern/subr_taskqueue.c:755 > #15 0xffffffff80abd813 in fork_exit ( > callout=3D0xffffffff80b53d90 , > arg=3D0xfffff8000d967030, frame=3D0xfffffe081e962ac0) > at /usr/src/sys/kern/kern_fork.c:1072 > #16 0xffffffff80f5cc7e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:972 > #17 0x0000000000000000 in ?? () > Current language: auto; currently minimal > (kgdb) > > ------------------------------------------------------------------------ > backtrace panic when shuting down: > > #0 doadump (textdump=3D) at pcpu.h:230 > 230 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=3D) at pcpu.h:230 > #1 0xffffffff80afa5fb in kern_reboot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:383 > #2 0xffffffff80afaa21 in vpanic (fmt=3D, > ap=3D) at /usr/src/sys/kern/kern_shutdown.c:776 > #3 0xffffffff80afa863 in panic (fmt=3D) > at /usr/src/sys/kern/kern_shutdown.c:707 > #4 0xffffffff80f7c14f in trap_fatal (frame=3D0xfffffe081ed30700, eva=3D0= ) > at /usr/src/sys/amd64/amd64/trap.c:877 > #5 0xffffffff80f7c1a9 in trap_pfault (frame=3D0xfffffe081ed30700, > usermode=3D0) > at pcpu.h:230 > #6 0xffffffff80f7b984 in trap (frame=3D0xfffffe081ed30700) > at /usr/src/sys/amd64/amd64/trap.c:415 > #7 0xffffffff80f5bccc in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:231 > #8 0xffffffff80dfe4ad in vm_object_terminate (object=3D0xfffff805bf66d5a= 0) > at /usr/src/sys/vm/vm_object.c:768 > #9 0xffffffff80dfd0f8 in vm_object_deallocate (object=3D0x0) > at /usr/src/sys/vm/vm_object.c:677 > #10 0xffffffff80df3189 in _vm_map_unlock (map=3D, > file=3D, line=3D) > at /usr/src/sys/vm/vm_map.c:2939 > #11 0xffffffff80df7be2 in vm_map_remove (map=3D0xfffff80018673000, > start=3D4096, > end=3D140737488351232) at /usr/src/sys/vm/vm_map.c:3137 > #12 0xffffffff80df2e49 in vmspace_exit (td=3D0xfffff80039ec0620) > at /usr/src/sys/vm/vm_map.c:337 > #13 0xffffffff80ab72b9 in exit1 (td=3D0xfffff80039ec0620, > rval=3D, signo=3D) > at /usr/src/sys/kern/kern_exit.c:401 > #14 0xffffffff80ab6ced in sys_sys_exit (td=3D, > uap=3D) at /usr/src/sys/kern/kern_exit.c:180 > #15 0xffffffff80f7d1d8 in amd64_syscall (td=3D0xfffff80039ec0620, traced= =3D0) > at subr_syscall.c:132 > #16 0xffffffff80f5c5ad in fast_syscall_common () > at /usr/src/sys/amd64/amd64/exception.S:494 > #17 0x00000008028d034a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > ------------------------------------------------------------------------ > Panic while only running my single thread python script > > #0 doadump (textdump=3D) at pcpu.h:230 > 230 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=3D) at pcpu.h:230 > #1 0xffffffff80afa5fb in kern_reboot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:383 > #2 0xffffffff80afaa21 in vpanic (fmt=3D, > ap=3D) at /usr/src/sys/kern/kern_shutdown.c:776 > #3 0xffffffff80afa863 in panic (fmt=3D) > at /usr/src/sys/kern/kern_shutdown.c:707 > #4 0xffffffff80f7c14f in trap_fatal (frame=3D0xfffffe081f635ec0, eva=3D9= 52) > at /usr/src/sys/amd64/amd64/trap.c:877 > #5 0xffffffff80f7c1a9 in trap_pfault (frame=3D0xfffffe081f635ec0, > usermode=3D0) > at pcpu.h:230 > #6 0xffffffff80f7b984 in trap (frame=3D0xfffffe081f635ec0) > at /usr/src/sys/amd64/amd64/trap.c:415 > #7 0xffffffff80f5bccc in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:231 > #8 0xffffffff80af57ad in __rw_wlock_hard (c=3D0xfffff80016f8f798, > v=3D) at /usr/src/sys/kern/kern_rwlock.c:977 > #9 0xffffffff80bbca92 in bufobj_invalbuf (bo=3D, > flags=3D1, > slpflag=3D1017770744, slptimeo=3D) > at /usr/src/sys/kern/vfs_subr.c:1609 > #10 0xffffffff80bbf8be in vgonel (vp=3D0xfffff8053ca9f1d8) > at /usr/src/sys/kern/vfs_subr.c:1655 > #11 0xffffffff80bbbcc4 in vnlru_free_locked (count=3D1, mnt_op=3D0x0) > at /usr/src/sys/kern/vfs_subr.c:1227 > #12 0xffffffff80bbbe14 in getnewvnode_reserve (count=3D1) > at /usr/src/sys/kern/vfs_subr.c:1287 > #13 0xffffffff82327fb4 in zfs_zget (zfsvfs=3D0xfffff80076574000, > obj_num=3D34941, > zpp=3D0xfffffe081f6362a8) > at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1122 > #14 0xffffffff823421ad in zfs_dirent_lookup (dzp=3D0xfffff804ff94e420, > name=3D0xfffffe081f6363e0 "filename.ext", zpp=3D0xfffffe081f6362a8, f= lag=3D2) > at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:187 > #15 0xffffffff82342267 in zfs_dirlook (dzp=3D0xfffff804ff94e420, > name=3D, zpp=3D0xfffffe081f636360) > at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:238 > #16 0xffffffff8235a4ef in zfs_lookup () > at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1658 > #17 0xffffffff8235ac1e in zfs_freebsd_lookup (ap=3D0xfffffe081f636548) > at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4956 > #18 0xffffffff810fe89c in VOP_CACHEDLOOKUP_APV (vop=3D, > a=3D0xfffffe081f636548) at vnode_if.c:195 > #19 0xffffffff80ba8d56 in vfs_cache_lookup (ap=3D) > at vnode_if.h:80 > #20 0xffffffff810fe77c in VOP_LOOKUP_APV (vop=3D, > a=3D0xfffffe081f636610) at vnode_if.c:127 > #21 0xffffffff80bb2761 in lookup (ndp=3D0xfffffe081f636748) at vnode_if.h= :54 > #22 0xffffffff80bb1c29 in namei (ndp=3D0xfffffe081f636748) > at /usr/src/sys/kern/vfs_lookup.c:448 > #23 0xffffffff80bc8238 in kern_statat (td=3D0xfffff8013ba1b620, > flag=3D, fd=3D-100, > path=3D0x80332c910
, > pathseg=3DUIO_USERSPACE, sbp=3D0xfffffe081f636900, hook=3D0) > at /usr/src/sys/kern/vfs_syscalls.c:2023 > #24 0xffffffff80bc817d in sys_stat (td=3D, > uap=3D0xfffff8013ba1bb58) at /usr/src/sys/kern/vfs_syscalls.c:1978 > #25 0xffffffff80f7d1d8 in amd64_syscall (td=3D0xfffff8013ba1b620, traced= =3D0) > at subr_syscall.c:132 > #26 0xffffffff80f5c5ad in fast_syscall_common () > at /usr/src/sys/amd64/amd64/exception.S:494 > #27 0x0000000801a5b9ca in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > ------------------------------------------------------------------------ > Panic while using mplayer > > #0 doadump (textdump=3D) at pcpu.h:230 > 230 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=3D) at pcpu.h:230 > #1 0xffffffff80af91cb in kern_reboot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:383 > #2 0xffffffff80af95f1 in vpanic (fmt=3D, > ap=3D) at /usr/src/sys/kern/kern_shutdown.c:776 > #3 0xffffffff80af9433 in panic (fmt=3D) > at /usr/src/sys/kern/kern_shutdown.c:707 > #4 0xffffffff80f7a13f in trap_fatal (frame=3D0xfffffe081f70d380, eva=3D0= ) > at /usr/src/sys/amd64/amd64/trap.c:877 > #5 0xffffffff80f7a199 in trap_pfault (frame=3D0xfffffe081f70d380, > usermode=3D0) > at pcpu.h:230 > #6 0xffffffff80f79974 in trap (frame=3D0xfffffe081f70d380) > at /usr/src/sys/amd64/amd64/trap.c:415 > #7 0xffffffff80f5a00c in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:231 > #8 0xffffffff8088c030 in hdac_stream_start (dev=3D, > child=3D, dir=3D0, stream=3D1, buf=3D1889533952, > blksz=3D2048, > blkcnt=3D2) at /usr/src/sys/dev/sound/pci/hda/hdac.c:1927 > #9 0xffffffff8088437d in hdaa_channel_start (ch=3D) > at hdac_if.h:84 > #10 0xffffffff80887e0d in hdaa_channel_trigger (obj=3D, > data=3D0xfffff8007102c480, go=3D1) > at /usr/src/sys/dev/sound/pci/hda/hdaa.c:2161 > #11 0xffffffff80893b8e in chn_trigger (c=3D0xfffff80071058400, go=3D1) > at channel_if.h:131 > #12 0xffffffff8089751b in chn_notify (c=3D0xfffff80071058400, > flags=3D) at > /usr/src/sys/dev/sound/pcm/channel.c:2281 > #13 0xffffffff808b697f in vchan_trigger (obj=3D, > data=3D, go=3D1) > at /usr/src/sys/dev/sound/pcm/vchan.c:171 > #14 0xffffffff80893b8e in chn_trigger (c=3D0xfffff80071057c00, go=3D1) > at channel_if.h:131 > #15 0xffffffff8089de10 in dsp_ioctl (i_dev=3D, > cmd=3D, arg=3D0xfffffe081f70d8d0 "\003", > mode=3D, td=3D) > at /usr/src/sys/dev/sound/pcm/dsp.c:1733 > #16 0xffffffff809c5b38 in devfs_ioctl_f (fp=3D0xfffff802c5563c80, > com=3D2147766288, data=3D0xfffffe081f70d8d0, cred=3D0xfffff8004c48250= 0, > td=3D0xfffff802f24ac000) at /usr/src/sys/fs/devfs/devfs_vnops.c:791 > #17 0xffffffff80b5c00d in kern_ioctl (td=3D0xfffff802f24ac000, fd=3D51, > com=3D2147766288, data=3D) at file.h:323 > #18 0xffffffff80b5bd2c in sys_ioctl (td=3D0xfffff802f24ac000, > uap=3D0xfffff802f24ac538) at /usr/src/sys/kern/sys_generic.c:745 > #19 0xffffffff80f7b1c8 in amd64_syscall (td=3D0xfffff802f24ac000, traced= =3D0) > at subr_syscall.c:132 > #20 0xffffffff80f5a8ed in fast_syscall_common () > at /usr/src/sys/amd64/amd64/exception.S:494 > #21 0x0000000801fb94aa in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > ------------------------------------------------------------------------ > Panic while ilde, seems like cronjobs triggered ZFS ARC cleanup. > > #0 doadump (textdump=3D) at pcpu.h:230 > 230 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=3D) at pcpu.h:230 > #1 0xffffffff80af95fb in kern_reboot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:383 > #2 0xffffffff80af9a21 in vpanic (fmt=3D, > ap=3D) at /usr/src/sys/kern/kern_shutdown.c:776 > #3 0xffffffff80af9863 in panic (fmt=3D) > at /usr/src/sys/kern/kern_shutdown.c:707 > #4 0xffffffff80f7b13f in trap_fatal (frame=3D0xfffffe081ee186e0, > eva=3D201697507) > at /usr/src/sys/amd64/amd64/trap.c:877 > #5 0xffffffff80f7b199 in trap_pfault (frame=3D0xfffffe081ee186e0, > usermode=3D0) > at pcpu.h:230 > #6 0xffffffff80f7a974 in trap (frame=3D0xfffffe081ee186e0) > at /usr/src/sys/amd64/amd64/trap.c:415 > #7 0xffffffff80f5a5bc in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:231 > #8 0xffffffff80ad596e in free (addr=3D0xfffff802472af200, > mtp=3D0xffffffff825bfc00) at /usr/src/sys/kern/kern_malloc.c:583 > #9 0xffffffff8232a667 in zfs_inactive (vp=3D, > cr=3D, ct=3D) > at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4333 > #10 0xffffffff82332a1d in zfs_freebsd_inactive (ap=3D) > at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5364 > #11 0xffffffff810ff6b2 in VOP_INACTIVE_APV (vop=3D, > a=3D0xfffffe081ee18858) at vnode_if.c:1955 > #12 0xffffffff80bbd7bc in vinactive (vp=3D0xfffff803ae8b3760, > td=3D0xfffff803ae23b620) at vnode_if.h:807 > #13 0xffffffff80bbdcc7 in vputx (vp=3D0xfffff803ae8b3760, func=3D1) > at /usr/src/sys/kern/vfs_subr.c:2688 > #14 0xffffffff80bc5180 in sys_fchdir (td=3D0xfffff803ae23b620, > uap=3D) at /usr/src/sys/kern/vfs_syscalls.c:724 > #15 0xffffffff80f7c1c8 in amd64_syscall (td=3D0xfffff803ae23b620, traced= =3D0) > at subr_syscall.c:132 > #16 0xffffffff80f5ae9d in fast_syscall_common () > at /usr/src/sys/amd64/amd64/exception.S:494 > #17 0x00000008008a99aa in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Mon Aug 27 13:07:36 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 942AB108902C for ; Mon, 27 Aug 2018 13:07:36 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 266918F5C1 for ; Mon, 27 Aug 2018 13:07:36 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id r69-v6so26484229oie.3 for ; Mon, 27 Aug 2018 06:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ws0UqhetKzfSmN5rtD+NVka32AFswU7HhgYBp5rkrHE=; b=IBek+LNFV24M+naKu+ZgA8Mn58uXex/hSu3p1phKCv2dQlRFyUIeUh3vxRgtgou4X6 IBC4Z8nXmAQyFrTOGKte/FHmchDIK22nYKUIanRSs9pBEyvUfz+SlJcc9Eo/h148XxBa r/wKgbo81+4cZ8KOhwXnSVs8mbTzIhppyKqzCttVsrsmmcDbWzqmLPy+rbiS98pkMg3/ nsG9MntQMn9L3mNS3KL1k6t1Cc0LL2eeBJA/QRzcQxgpbPSK8Iv2UBsyns3ONZAKPro9 Hc7a6VpPURw2UmxvRd2xovbvdvil+piDSQYuUnbkkYjqi5aY+UYN/mNcQH/42lfkd5eA tqlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ws0UqhetKzfSmN5rtD+NVka32AFswU7HhgYBp5rkrHE=; b=A+tW6BpD2avRGJMUtm6heCqWxUGenJPmfLQaXqtAMbJGqsgcVgpRjbX560WJycEFFA BKmQQv7L64zKdYHzwV2GjDRKYMZw510c2dU3KKyd9OnQjeJZoICEiwarybCQQbgfszXM A8jR0a7Se/NRTzxijLDL5fKH1HJsrTBToIPZcztL2Gx0/epJt27bVfo3v1Q6oof6NmEJ NeboCbtHanFwVidEkdaTLfVFT2tDw/ht1ZCdlHbxG2EGzMHwDR/7zPPBreIQfvQ0hpJi WR3arZL8OdzWBeHaa4hgSB4NI4CHlGY/MrTBhMn1rgiJp6pIxRyLb40jniVaAyAeXJLh nElg== X-Gm-Message-State: APzg51DckIeB9QSNLX6v9f7dKXvovcRkKytOZ1umMY0SK1QcxLe/0xBr AEtXVHGBhd6Q1EcZHkgh7be1Ku8Fr4Le/2Na8pk= X-Google-Smtp-Source: ANB0VdbJJJY5ioczeLx/9IRbfBdFjrElwz94DFVzYQhJsMXwQKwJSyDFSFGNSQ/VlRcT1qGonXFmmG/6OekK0Zj7sVs= X-Received: by 2002:aca:e510:: with SMTP id c16-v6mr13201223oih.44.1535375255088; Mon, 27 Aug 2018 06:07:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:a54:0:0:0:0:0 with HTTP; Mon, 27 Aug 2018 06:07:34 -0700 (PDT) In-Reply-To: <32e008cf-93d3-944d-9b11-e56f1bb425ef@wyatt672earp.force9.co.uk> References: <32e008cf-93d3-944d-9b11-e56f1bb425ef@wyatt672earp.force9.co.uk> From: Meowthink Date: Mon, 27 Aug 2018 21:07:34 +0800 Message-ID: Subject: Re: Ryzen Build Problem To: Mitchell Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 13:07:36 -0000 Hi frank, On 8/27/18, Mitchell wrote: > > Hi Meowthink: > > I'm planning a Home Build, and I came across an issue which might apply > to your design. > > Some AMD CPUs are designed for Over-Clocking automatically. But when I > investigated Memory Compatibility I saw that some Memory wasn't. Many Intel CPUs are turbo boost enabled, also. I think It's safe to trust these designs. They'll communicate to memory at a steady clock rate, which will provide by SPD chips on DIMMs. Ryzens are known to have compatible issues with memories. An easier way is to choose a module which is in the qualified list, "QVL". > > The "AMD Ryzen 5 2400G" looks like it can Over-Clock itself when it > feels safe to do so. > > But the "Crucial 16GB DDR4-2400 EUDIMM CL17" seems to be classified as > Server Memory, which could mean it's designed for a single speed. I > couldn't find more details about Crucial Memory Over-Clocking. > > The Crucial Web Pages do feature a Help Facility which might enable you > to check further if you input all your system details. > That's a mistake months ago. What I'd care about is ECC. I knew Ryzens (1x00) are ECC enabled. Then I was mistaken checking out mobo's specification as Asrock didn't mention Raven Ridges (2x00G) at that time. I thought my build with 2400G will got ECC, but sadly not. Now Asrock say these on their website: - AMD Ryzen series CPUs (Raven Ridge) support DDR4 3200+(OC)/2933(OC)/2667/2400/2133 non-ECC, un-buffered memory* *For Ryzen Series CPUs (Raven Ridge), ECC is only supported with PRO CPUs. In the end I got my system run, but without ECC enabled. > I'm no expert here. This will be my first Home Build attempt and I > haven't even started yet. You probably need a 2nd and 3rd opinion on > this topic. I'm just hoping my contribution will prompt further comments > from FreeBSD people with more know-how than I've got. > > Yours truly: Frank Mitchell > You are welcome. Cheers, meowthink > On 27/08/18 09:13, Phil Norman wrote: >> Hi. >> >> I have a similar setup: Ryzen 3 and Fatal1ty X370 mini-ITX. I had some >> trouble with instability, although my problems weren't panics, but rather >> two issues. One was random lockups (with no evidence left in logs), but I >> *think* this was down to an inadequately cooled graphics card. >> >> The other problem I had was with USB. I got quite a spam of log messages >> about the USB reinitialisation. However, eventually I figured out that >> the >> problem didn't occur if I booted the system from a completely >> powered-down >> state. That is, use the physical switch on the PSU to cut power entirely, >> re-enable, then boot from that state. Since then I've had 67 days of >> uninterrupted uptime, with no USB issues at all. >> >> It sounds like your problem is different, but trying a boot-from-cold >> might >> be worthwhile, just in case ASRock have a consistent problem in this >> regard. >> >> Cheers, >> Phil >> >> On 26 August 2018 at 13:20, Meowthink wrote: >> >>> Hello all, >>> >>> Recently I tried to build up a Ryzen system and run FreeBSD on it. >>> CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics (0x810f10) >>> Mobo: Asrock Fatal1ty AB350 Gaming-ITX/ac ( with up-to-date BIOS with >>> PinnaclePI-AM4_1.0.0.4, microcode 0x810100b ) >>> Mem: 2x Crucial 16GB DDR4-2400 EUDIMM CL17 ( ECC Unregistered but ECC >>> actually won't work :( ) >>> >>> But the system is unstable - it can't last few days even is nearly >>> idle. System panics even at midnight. It almost panic while or after I >>> built something large. Surprisly I didn't encourage a user program >>> fault, bad binaries built etc., panics only. >>> >>> Then I tried lots of BIOS settings e.g. SMT, C6 idle current, >>> underclock RAM, but none seems effect. >>> It could pass memtest86 V7.5 without error, or various benchmarks >>> under Windows. thus I think the problem is not in the hardware but >>> software. >>> >>> In the mean time, I realized that the rate of irqs from xhci0 are too >>> high - it's about 1998/s. I found [1] and tried to MFC r331665. It >>> didn't fix the problem though, but disabling that bluetooth module >>> stops the irq storm, after all. >>> >>> Then the system lasts much longer before panic. It eventually can >>> compile ports tree, build the world, scrub the zpool, all done without >>> annoying reboots. >>> Then I assume this is [2] related? So I also tried cpuctl, bounding >>> all processes to 2-7. >>> But the problem is still there, only the chance become very low. It >>> still panics occasionally, idling a week or stressing few hours - >>> Stress seems to rise the chance of panic, but differently by types. >>> Things like llvm will always build, but gcc will cause a panic per few >>> passes. >>> >>> The system was 11.2 but then moved on to stable/11 (r337906 >>> currently). I've got last 10 coredumps saved but my kernel isn't >>> compile as debug. So I'll put some backtrace from core.txt.? in the >>> end. >>> >>> Indeed I want to eliminate this problem. Could someone guide me how to >>> figure out the problem? What should I try next? >>> >>> Best regards, >>> Meowthink >>> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Aug 27 13:17:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4972A108947F; Mon, 27 Aug 2018 13:17:00 +0000 (UTC) (envelope-from karu.pruun@gmail.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1AB88FB4A; Mon, 27 Aug 2018 13:16:59 +0000 (UTC) (envelope-from karu.pruun@gmail.com) Received: by mail-oi0-x22c.google.com with SMTP id b15-v6so27128750oib.10; Mon, 27 Aug 2018 06:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kCE+z+wA0AQ6kkp7Mvfiz76YsFwiWyfUDPHk8NVPNq8=; b=KI8RCpruxuvoezNKLI20dcmqvNc2dFKuXB9SxEo8/Zx1ToL3+FuQbd1H3y6VxvzMeQ F80uEqO7z4b6SV4KaNEjJlF/TIqgaf9q4SzxS7ZuXJn4nybfRNGvssK61gAN6XWN4vnp 4ackoWQpEHfE1hISa5+pvGYxHjGVrjT0vIre3D3hsbEXyR0nr08HWYT/OSzwaGJEe4E/ MXEdnULQvHShalHN/bbZQfKR/UnG9AM8G3/svJuOvHpx/JpsI1BDH4+BxZpdUiZYDJYC sHvZCASTlUQVouKONZPf2v7nKuO6bPGR/RwBnQ0f9dzpNE2Xo/HZ0Is10FsHd00LjMca QNOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kCE+z+wA0AQ6kkp7Mvfiz76YsFwiWyfUDPHk8NVPNq8=; b=Iff+3uflCqORgDJb3eLQgYoQgRT2GQtnOH82DkmhR6CImohpCcBU6dtvvKyuFkk/ZE 50y/acAPzJglkIWok6ZqLObA4Lrzr9K1Ki5jmROpK52OB3/WctG3LpBVKJbUZ0/YX+jH wFPmDAOY53FFjvFPecxi3wH6Cj8a4skhZWROhh8y/I9fELfCafWieSp+p/XUYIHkHu2/ L3ReYvzU6Wo7tuSmfzZpiNDyPXNyfabu2yrQIESxgvyMvd3dbaivk34XOlM7+I+AuBam H7dZFhWbS8POI6o1K7atoIXZbs74ygGbz/ruVzE5Bg1B/dOuohN3o7s7TQwxzxC5hKQ3 un3g== X-Gm-Message-State: APzg51Dqr9EP5VTYer5kTx0Ni5FbLaA1K6MxFFBg/tkaZOKH7dxePssm oFQpz+gBkumbsKbQN0nPIW+GE2cK4hCNHv+0LRSA0Sfi X-Google-Smtp-Source: ANB0VdZgpkiC8Wg3qiobUuI/cJ+V23h3arfrBA60BAx+zlDoMSF8zQ+nheeSGBa/jaXGrWqbpiOzwk/kCjd0tf9KxgA= X-Received: by 2002:aca:d098:: with SMTP id j24-v6mr12814944oiy.72.1535375819193; Mon, 27 Aug 2018 06:16:59 -0700 (PDT) MIME-Version: 1.0 References: <20180827132905.191dbd8c@ernst.home> In-Reply-To: From: "karu.pruun" Date: Mon, 27 Aug 2018 16:16:47 +0300 Message-ID: Subject: Re: Help diagnose my Ryzen build problem To: meowthink@gmail.com Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 13:17:00 -0000 On Mon, Aug 27, 2018 at 3:21 PM Meowthink wrote: > That's kib, who has committed things in that script to both 12 [1] and > stable/11 [2]. > > Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my > Ryzen 5 2400G's model is 11h. > > On the microcode. It shall be updated through UEFI/BIOS updates. I > think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel > 0x810100b. > > Seems like ... the only thing I can do is sit down and wait? The revision https://svnweb.freebsd.org/base/head/sys/x86/x86/cpu_machdep.c?r1=336763&r2=336762&pathrev=336763 works around the mwait issue, i.e. it sets sysctl machdep.idle_mwait=0 sysctl machdep.idle=hlt Now it may or may not relate to your problem, but it appears that Ryzen 2400G also has another issue with HLT, see the DragonFly bug report https://bugs.dragonflybsd.org/issues/3131 which AMD is aware of and is possibly working on, but it may not have appeared in the errata yet. The bug report says that until this is fixed, the workaround is to also disable HLT in cpu_idle. I am not sure what is the correct value for the sysctl on FreeBSD, perhaps sysctl machdep.idle=0 or some other value? Cheers Peeter -- From owner-freebsd-hackers@freebsd.org Mon Aug 27 14:13:17 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 672FB108B1FD; Mon, 27 Aug 2018 14:13:17 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4456720F4; Mon, 27 Aug 2018 14:13:16 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id i134-v6so10100217wmf.0; Mon, 27 Aug 2018 07:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=6FYv7XY/tmWnAIQOwTLCG09MRYbGUysfCqS0rp7gq90=; b=dEtHicpkN8UqzTLDj3o+zUrYbHYE0y8uKK3+gIRPnYxRGWTYfHEvUBOH5ZrpMhV0eE 85iJdCzlnJ8Ft1HlSqjQz3T0IaLUBgC38MyvR6YFLW5FQ+po1+9+L9jBduY8Z7rpX0O4 Kat4ggo/LywCLCN2oqp/cuWp0FWpaOKHASZHqhlo6S5/kt+pitt7Atvd7jKbiuKbBREt JAInK/KPUATyhyqo1WgitN2lYEDbKR39ecmtVF6HSwWsm+Nal7h0MRykoRd5jEf3P7Nu uGLA4ublll753qFelVs6hjGP+k4qCEx4W0xRJA3xmvVrS6UByFSRePsgL9fWevkWbggw +ADA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=6FYv7XY/tmWnAIQOwTLCG09MRYbGUysfCqS0rp7gq90=; b=D0LFkRttp/SfruDQUvmF/prENA/pVi+UrT2fEWCgdBFCMbp8GYxskQorWsYH2Z9r+S jMa3fH/BHCRZ9O3h3YQTXZv8WSHt7WE+LNFeHHY9b1n4O7blagueN9UJr4VMZF8JW/Sl LNUgwBOJprkAyDzcYqlqlWHBSjoNHHDAfrqoxX2J01eJY6XILcRkC8NYswSTrDWAfa4M x1/tA40qnSf7YJB5wo9AnRRCyia/sm0c5ZIEFVnkF8UmCj1ld00Nk/yN1gCo3zWQc4GX wOrqkAM3VBoQaLdjAHwCdskE4PsNQuYFAz3Amhq3qDZ1MyhuKj2qeTD0Y9WVeRWQXZcB +S9w== X-Gm-Message-State: APzg51DNzWNKMWOTKxM4T51JlN0cpSzlHZkPQQXvfxpH5mKSy/kJZ+wP MyEthaS2I7JllDYnueyGLOWGEUj6 X-Google-Smtp-Source: ANB0VdbIZOKNMq6LR4kyCz/VVwbRsbdLYlOTNs+pxLVrpw/xXmT5GtyV8l+cX63/EaXBoQgiN058lQ== X-Received: by 2002:a1c:4887:: with SMTP id v129-v6mr5415044wma.129.1535379195877; Mon, 27 Aug 2018 07:13:15 -0700 (PDT) Received: from ernst.home (pD9E23C49.dip0.t-ipconnect.de. [217.226.60.73]) by smtp.gmail.com with ESMTPSA id p89-v6sm30962597wrc.97.2018.08.27.07.13.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 27 Aug 2018 07:13:14 -0700 (PDT) Date: Mon, 27 Aug 2018 16:13:13 +0200 From: Gary Jennejohn To: Meowthink Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Help diagnose my Ryzen build problem Message-ID: <20180827161313.291d24b7@ernst.home> In-Reply-To: References: <20180827132905.191dbd8c@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 14:13:17 -0000 On Mon, 27 Aug 2018 20:18:46 +0800 Meowthink wrote: > Hi Gary, > > On 8/27/18, Gary Jennejohn wrote: > > On Mon, 27 Aug 2018 10:13:10 +0200 > > Phil Norman wrote: > > > >> Hi. > >> > >> I have a similar setup: Ryzen 3 and Fatal1ty X370 mini-ITX. I had some > >> trouble with instability, although my problems weren't panics, but rather > >> two issues. One was random lockups (with no evidence left in logs), but I > >> *think* this was down to an inadequately cooled graphics card. > >> > > > > I had instability problems with my Ryzen 5 - lockups for no > > apparent reason. The only recourse waas a hard reset. > > > > It turned out that there were two causes > > 1) old CPU microcode > > 2) unhandled errate in the CPU > > > > I installed the /usr/ports/sysutils/devcpu-data port, which > > allowed me to install the latest microcode using cpucontrol(8). > > > > I also used a shell script called amd_errata.sh provided by one of > > the FreeBSD committers. To my shame I can't remember exactly > > who. Note that the errata fixups are now part of the kernel in > > FreeBSD 12. > > That's kib, who has committed things in that script to both 12 [1] and > stable/11 [2]. > > Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my > Ryzen 5 2400G's model is 11h. > AMD has also relased a Revision Guide for Family 11h. Lots of errata listed there, but I didn't look at it closely enough to say whether any are relevant to lockups. > On the microcode. It shall be updated through UEFI/BIOS updates. I > think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel > 0x810100b. > Well, I installed the latest BIOS for my ASUS B350M-A also, but it was no help. The lockups disappear only after I installed the latest microde using the port. > Seems like ... the only thing I can do is sit down and wait? > > > > > After taking these steps about two months ago I have had no more > > lockups and the machine runs very stabily. > > > > [big snip] > > > > -- > > Gary Jennejohn > > > > [1] https://svnweb.freebsd.org/base?view=revision&revision=336763 > [2] https://svnweb.freebsd.org/base?view=revision&revision=337235 -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Mon Aug 27 14:25:41 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 665E3108BB8C; Mon, 27 Aug 2018 14:25:41 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D215572DCA; Mon, 27 Aug 2018 14:25:40 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id c14-v6so8295594wmb.4; Mon, 27 Aug 2018 07:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=gUAwE9OkPs4raYQQb/+DcgilMSgaOFRqz73uFgYKp+s=; b=tSE6AG7bOAt98N7Mal8yoZFna0uXsYgOuel6n3e9EKAdpszGHwP7HRlto+IgLLsaPb sUrgJeuYKvZ5sIqE1pP222LQ4ECY1zkjkoSzYD5SlYk20BkgO9JpyAp+xvVzQ1qT6oZk BGvWwNNJ2wO0RmGS9L7I5Ii8yFLTL1sKG5TEt9Ussav9kKOf+8tYA+AB10QkC61eEX7J oKTMVkbOB2XzBjd+WkRDyZrkTM1p0yj/rwWeE7WEukBU/RgcT0bY7tDB/z3mmvLKrBvu rLcFhScWf1rELt+eWDaofieq378rhBAXgwRtTiSBXN19nOIEeEvQZhy7LZlB7Ze2pYtV iHJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=gUAwE9OkPs4raYQQb/+DcgilMSgaOFRqz73uFgYKp+s=; b=OoR9D5+WY/uBltgFu/WLkY6CcbFGI3HeeA1LvcVucjoVuknmp+lGNF1omhfVJmyLSw JXtgbdcF+mWYMbDgkmWpxRG0DxObyoElXjYZ0WdxImNPkf/XxH3NDsmJD6YJ8m0US6HE Mghi8Q+GFDZ72Y0r7O2JGmKfBhGxBSXn7CFyPWu5aHpndeaJRAOwVEaRORZad8kqllbX AOrWH5Setw3lfStbhPffW9vHBDKcqxbPPG/Eg17hO793T50/RCVJpJR6Npe3fR9G3bNz BLE8L/4uS/zlluPx3feOVJ97kAyzWLXZcKgTBXjkYE2XfcCePlC83h0awOcvNaVxMPjj qe1A== X-Gm-Message-State: APzg51Di1b0zD5ZpaGOTxTTxAyAy+D6mqCtGQzn6HsxBEYrQGn0zc4si QFI/gBYJIRCwANSnFQzv8GI= X-Google-Smtp-Source: ANB0VdZBgxRFMy8Pv97mnox9UuR0cbOH8JhMK8fZZZMbHFj2T8AdKBVKK3arfkVKldlBZFity+0c6Q== X-Received: by 2002:a1c:87c9:: with SMTP id j192-v6mr5413177wmd.71.1535379939877; Mon, 27 Aug 2018 07:25:39 -0700 (PDT) Received: from ernst.home (pD9E23C49.dip0.t-ipconnect.de. [217.226.60.73]) by smtp.gmail.com with ESMTPSA id v6-v6sm10953787wro.66.2018.08.27.07.25.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 27 Aug 2018 07:25:39 -0700 (PDT) Date: Mon, 27 Aug 2018 16:25:37 +0200 From: Gary Jennejohn To: "karu.pruun" Cc: meowthink@gmail.com, freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Help diagnose my Ryzen build problem Message-ID: <20180827162537.05f9b576@ernst.home> In-Reply-To: References: <20180827132905.191dbd8c@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 14:25:41 -0000 On Mon, 27 Aug 2018 16:16:47 +0300 "karu.pruun" wrote: > On Mon, Aug 27, 2018 at 3:21 PM Meowthink wrote: > > That's kib, who has committed things in that script to both 12 [1] and > > stable/11 [2]. > > > > Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my > > Ryzen 5 2400G's model is 11h. > > > > On the microcode. It shall be updated through UEFI/BIOS updates. I > > think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel > > 0x810100b. > > > > Seems like ... the only thing I can do is sit down and wait? > > The revision > > https://svnweb.freebsd.org/base/head/sys/x86/x86/cpu_machdep.c?r1=336763&r2=336762&pathrev=336763 > > works around the mwait issue, i.e. it sets > > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt > > Now it may or may not relate to your problem, but it appears that > Ryzen 2400G also has another issue with HLT, see the DragonFly bug > report > > https://bugs.dragonflybsd.org/issues/3131 > > which AMD is aware of and is possibly working on, but it may not have > appeared in the errata yet. The bug report says that until this is > fixed, the workaround is to also disable HLT in cpu_idle. I am not > sure what is the correct value for the sysctl on FreeBSD, perhaps > > sysctl machdep.idle=0 > > or some other value? > It is in the latest errata and there are no plans to fix it. Based on the detailed description, this is a problem only in a hypervisor. AMD has a suggested workaround for it. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Mon Aug 27 15:07:30 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9E44108D32D; Mon, 27 Aug 2018 15:07:29 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A4C374ABD; Mon, 27 Aug 2018 15:07:29 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: by mail-oi0-x22c.google.com with SMTP id m11-v6so27879763oic.2; Mon, 27 Aug 2018 08:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ppoamd3JBEGM1cHjn7e6F/AhHW1rzyopnaokDm1OZdo=; b=ICBGAR9g/s4IIz4QqLLgJaagulC2N3GcsYoicCeTkXMAypMAcLStN7NJ3qciiTZUnI boxJYu16zTuLUvVBcb3MEl3HUL28UKx6/3gXlLy32REqGfbCpg57kadsOI1jEBl+zMPI lm/75aK5J1WE0G3eSVkosfmHP+YKXtoj47UG3AZ/TB7jz43m1B54jzDIkRzj5fl0wEi9 8JYouPT1a3g6WVlGRjZVjLUTareLcx60J31S+xhibx5jOLaLvCb5mc7hx3Rk3+ohrcqn Buk+mJ/Hp4wwhovJW+z9wWDOB1W1w+x97zP5cIl3XbTdnDe5jJXYm2WJXGLbh5maYdq2 5GAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ppoamd3JBEGM1cHjn7e6F/AhHW1rzyopnaokDm1OZdo=; b=CoC7be+6BbzQThz1EbBz1+/RV3vHgxpYTRTtfHZs7FypL1WHPju5AfGmOz1nR893Rf VA/zNfdiNJTmqBTD0CQoQLT6UtI7Xr0q2YFGdeWSs9wh7tYbQvpTF1Xb3Qm8vg0URMid SRTEYePoRavPV5z/jYkhx5ElRWnh4DbHV9S/wIFbaa60HyQ1fRihvPVlRoejFhEE+ZeF VI0d6rYXnNk5c0Ral16pdDXOG+poRS/EGeJWNUvP1pjm521DoTQhpv+eGNHz1LkQ9RC1 oZJ244rfSh3VCleIAKr9cxluNoc0A0+Tw+XY8FZ7s4V8C8wHKpyrrk4p/Ls2CsuvLvTT 8EtQ== X-Gm-Message-State: APzg51CoQXf4vx2AlJDVT1QZXb6idpMBK6f7xqRnLIp+dkH7FME0q3Ip BVbxpK0dsR4xfkVzx8JP97qkKbC8j8lOWf879gI= X-Google-Smtp-Source: ANB0VdYnKXI4HHN+ZR+WnHE8cuYAHDyzEJlwbN0xfNW62c6A9HSecBKcaiD7r4qq41IRfmMncXKQyKPBdLIfInB/ORU= X-Received: by 2002:aca:4802:: with SMTP id v2-v6mr13339208oia.259.1535382448704; Mon, 27 Aug 2018 08:07:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:a54:0:0:0:0:0 with HTTP; Mon, 27 Aug 2018 08:07:28 -0700 (PDT) In-Reply-To: References: <20180827132905.191dbd8c@ernst.home> From: Meowthink Date: Mon, 27 Aug 2018 23:07:28 +0800 Message-ID: Subject: Re: Help diagnose my Ryzen build problem To: "karu.pruun" Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 15:07:30 -0000 Hi peeter, On 8/27/18, karu.pruun wrote: > On Mon, Aug 27, 2018 at 3:21 PM Meowthink wrote: >> That's kib, who has committed things in that script to both 12 [1] and >> stable/11 [2]. >> >> Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my >> Ryzen 5 2400G's model is 11h. >> >> On the microcode. It shall be updated through UEFI/BIOS updates. I >> think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel >> 0x810100b. >> >> Seems like ... the only thing I can do is sit down and wait? > > The revision > > https://svnweb.freebsd.org/base/head/sys/x86/x86/cpu_machdep.c?r1=336763&r2=336762&pathrev=336763 > > works around the mwait issue, i.e. it sets > > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt > I think that shall not apply to 2400G, which is model 11h not 1h. Here're what I have now: machdep.idle: acpi machdep.idle_available: spin, mwait, hlt, acpi machdep.idle_apl31: 0 machdep.idle_mwait: 1 > Now it may or may not relate to your problem, but it appears that > Ryzen 2400G also has another issue with HLT, see the DragonFly bug > report > > https://bugs.dragonflybsd.org/issues/3131 > Thanks a lot for that info. It's much easier to prove your problem, since it's reproducible. But mine was so random to catch... Anyway, it seems like the IRET issue [1] is still not fixed? I'm highly doubt that my issue is this related because my system became significantly more stable since I stop that irq storm from bluetooth module - Though it still panics occasionally. So could anybody tell, what's the difference between FreeBSD workaround [2] and the DragonflyBSD one? > which AMD is aware of and is possibly working on, but it may not have > appeared in the errata yet. The bug report says that until this is > fixed, the workaround is to also disable HLT in cpu_idle. I am not > sure what is the correct value for the sysctl on FreeBSD, perhaps > > sysctl machdep.idle=0 > > or some other value? In the meantime, I have this microcode # cpucontrol -m 0x8b /dev/cpuctl0 MSR 0x8b: 0x00000000 0x0810100b Hence I should use mwait? Still don't know what should I set. Any idea? > > Cheers > > Peeter > > -- > Thank you for your direction. Cheers, meowthink [1] http://lists.dragonflybsd.org/pipermail/commits/2017-August/626190.html [2] https://reviews.freebsd.org/D11780 From owner-freebsd-hackers@freebsd.org Mon Aug 27 15:40:02 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52FF9108E1D3 for ; Mon, 27 Aug 2018 15:40:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CC5B75F88; Mon, 27 Aug 2018 15:40:01 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (c-24-18-193-141.hsd1.wa.comcast.net [24.18.193.141]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w7RFdjSw088805 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 27 Aug 2018 08:39:46 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: epoch(9) background information? To: Matthew Macy , sebastian.huber@embedded-brains.de Cc: freebsd-hackers@freebsd.org References: <15e3f080-2f82-a243-80e9-f0a916445828@embedded-brains.de> From: Julian Elischer Message-ID: <11062f46-aa32-8c90-ab8b-acdf880a1502@freebsd.org> Date: Mon, 27 Aug 2018 08:39:45 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 15:40:02 -0000 On 21/8/18 11:49 pm, Matthew Macy wrote: > On Tue, Aug 21, 2018 at 11:42 PM Sebastian Huber < > sebastian.huber@embedded-brains.de> wrote: > >> On 22/08/18 08:34, Sebastian Huber wrote: >>> On 21/08/18 15:38, Jacques Fourie wrote: >>>> >>>> On Tue, Aug 21, 2018 at 8:33 AM, Sebastian Huber >>>> >>> > wrote: >>>> >>>> Hello, >>>> >>>> I update currently a port of the FreeBSD network stack, etc. to >>>> the real-time operating system RTEMS from the head version at >>>> 2017-04-04 to the head version of today. I noticed that some >>>> read-write locks are replaced by a relatively new stuff called >>>> EPOCH(9). Is there some background information available for this? >>>> The man page is a bit vague and searching for something named >>>> epoch on the internet is not really great. For example, what is >>>> the motivation for this change? How is this related to >>>> read-copy-update (RCU)? >>>> >>>> -- Sebastian Huber, embedded brains GmbH >>>> >>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany >>>> < >> https://maps.google.com/?q=Dornierstr.+4,+D-82178+Puchheim,+Germany&entry=gmail&source=g >>>> Phone : +49 89 189 47 41-16 >>>> Fax : +49 89 189 47 41-09 >>>> E-Mail : sebastian.huber@embedded-brains.de >>>> >>>> PGP : Public key available on request. >>>> >>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des >>>> EHUG. >>>> >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org >>>> mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> >>>> To unsubscribe, send any mail to >>>> "freebsd-hackers-unsubscribe@freebsd.org >>>> " >>>> >>>> >>>> Additional information is available here : >>>> http://concurrencykit.org/presentations/ebr.pdf >>>> . The way I >>>> understand it is that it is mostly used in place of read locks to >>>> provide liveness guarantees without using atomics. Additional detail >>>> is available in the commit messages. As an example see r333813 for >>>> some performance data. >>>> >>> Thanks, for the reference. The "epoch reclamation" are good keywords >>> to find more information. >>> >>> What is the right mailing list to ask questions about the epoch >>> implementation of the FreeBSD kernel? >>> >>> To support this machinery in RTEMS is a bit difficult (in particular >>> EPOCH_LOCKED). Since RTEMS is supposed to be a real-time operating >>> system it supports only fixed-priority and job-level fixed priority >>> (EDF) schedulers. To allow some scaling to larger SMP systems it >>> supports clustered scheduling together with the mutual exclusion >>> locking protocols MrsP >>> (http://www-users.cs.york.ac.uk/~burns/MRSPpaper.pdf) and OMIP >>> (http://www.mpi-sws.org/~bbb/papers/pdf/ecrts13b.pdf). This makes the >>> thread pinning hard to implement (which is very easy to support in >>> FreeBSD). The locking protocols may temporarily move a thread which >>> owns a mutex to a foreign scheduler instance, e.g. a thread which >>> wants to obtain the mutex helps the owner to make progress if it was >>> pre-empted in its home scheduler instance. Due to a timeout of the >>> helper the owner may loose the right to execute in the foreign >>> scheduler instance. This would make it impossible to fulfil the >>> processor pinning constraint (e.g. the thread priority in the foreign >>> scheduler instance is undefined). >>> >>> It would save me a lot of trouble if I could assume that EPOCH_LOCKED >>> is an exotic feature which is unlikely to get used in FreeBSD. >>> >> Another question, is it a common use case to call epoch_enter_preempt() >> and epoch_exit_preempt() while owning a mutex? >> > Yes. Very. It is generally not permitted to hold a mutex across > epoch_wait() that's why there's the special flag EPOCH_LOCKED. If you have > a very limited number of threads, you might want to have each thread have > its own record registered with the epoch. Then you wouldn't need the CPU > pinning. The pinning is just away of providing a limited number of records > to an unbounded number of threads. Matt, could you add information about this in locking(9)? it holds information on the interaction between various locking types and it woudl apear this needs to be added to the mix. Julian > > -M > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Mon Aug 27 16:30:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00E1A108FA01 for ; Mon, 27 Aug 2018 16:30:52 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96BB278514 for ; Mon, 27 Aug 2018 16:30:51 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f170.google.com with SMTP id q4-v6so13308686iob.8 for ; Mon, 27 Aug 2018 09:30:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=sl+f/8IruCIcBM5t/V0nwf4UBUX2RZnTwOq9XS91d6I=; b=Z7j9vNe315C6+hObUAn2vvvSIB6xxAAAxIBew6jU+WIxAGUKtxhNLO7JBPjZt17Iag QJq6/4LROVXa++iT8TB+ieOSOTpPH3A0WTGxQoi0efkeA2Fcux+9iMDu1fW8N1mQEtH1 7XgTlU7/hWjUKOR9W7NzuaoNE8+MWSl+mZrgLyed1tB0R+adWEgyRZ+i7tSQDkV+Y+HK zmHFg+6zYqrMXTh7P9ZccbLjYTvpyJkN8iXzcVf0JqMGyGKEAFypsav8AnEc+ZUKa84+ K4evctTdHxyUAMMeAJo3h8xUO4WElW/YjyFURcg658ko5qpYD9tG2aWQahWR6uVPiM1P axhw== X-Gm-Message-State: APzg51BZD38dPn0pJbhSv9po+HjuZcyNGmbr5iVGt321V0MDzIvWdnMU V2Nhhd4tvg23Vj5xGpsPG1DQA6S7 X-Google-Smtp-Source: ANB0VdZkGCiXsAYqibyjRZT58FLoAESiCzRnWyEoCnFLqz0jLnBGB5G4xzaaG7ozBbBqiKOObe9Kjg== X-Received: by 2002:a5e:c817:: with SMTP id y23-v6mr11358991iol.268.1535387444662; Mon, 27 Aug 2018 09:30:44 -0700 (PDT) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com. [209.85.214.47]) by smtp.gmail.com with ESMTPSA id u5-v6sm5493982ioc.85.2018.08.27.09.30.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 09:30:44 -0700 (PDT) Received: by mail-it0-f47.google.com with SMTP id h23-v6so11226215ita.5 for ; Mon, 27 Aug 2018 09:30:44 -0700 (PDT) X-Received: by 2002:a24:17c2:: with SMTP id 185-v6mr3937045ith.6.1535387444414; Mon, 27 Aug 2018 09:30:44 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:b472:0:0:0:0:0 with HTTP; Mon, 27 Aug 2018 09:30:43 -0700 (PDT) In-Reply-To: References: <20180827132905.191dbd8c@ernst.home> From: Conrad Meyer Date: Mon, 27 Aug 2018 09:30:43 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Help diagnose my Ryzen build problem To: Meowthink Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 16:30:52 -0000 On Mon, Aug 27, 2018 at 5:18 AM, Meowthink wrote: > That's kib, who has committed things in that script to both 12 [1] and > stable/11 [2]. > > Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my > Ryzen 5 2400G's model is 11h. > > On the microcode. It shall be updated through UEFI/BIOS updates. I > think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel > 0x810100b. > > [1] https://svnweb.freebsd.org/base?view=revision&revision=336763 It seems AMD has only published an errata document for Ryzen 1, models 00h-0fh, unfortunately. Best, Conrad From owner-freebsd-hackers@freebsd.org Mon Aug 27 17:54:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FD64109206D for ; Mon, 27 Aug 2018 17:54:43 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4D3C7C706 for ; Mon, 27 Aug 2018 17:54:42 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: by mail-oi0-x230.google.com with SMTP id r69-v6so28249812oie.3 for ; Mon, 27 Aug 2018 10:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WM3enjz3u4IB2LorXD0zPrZG437mJbqxVwPnBl6DpzU=; b=g86keLiFm4Lfk4aGcMbcsEpIsWcAdeodEsR0nviGiHcq5ckm9D8lFWIyfoYJKQOD7+ xLotij+Robr2N+zulac0hZv5xBZXGqxzOfy0QI/BDOvEOJr7oFkBvdvVYXwkrWsMX+8M CduZRHKJfuJdFOXoaKIMK+RgZXTH8s21Cmfh3qb8S8qHwWR727uqkMTXhoqZj06Cc0po SSzvK48HShJx7t4HmJlM4q5Va3DCXKFZWXxie0zCuW+n8DKJEomzRk9NX0+FNnn80kyC 4FBNm2zvkub7X/yM6Hlh3XuAJzBhz/Eof62Vp/+4S5oljuKXOjvpUCov1Io6HUKXtr4P j/7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WM3enjz3u4IB2LorXD0zPrZG437mJbqxVwPnBl6DpzU=; b=pDUdGW9y80rbPV5efy9i/j87+O79PFW8ln7nZhKkWdglnyN9sFs3s7Ll+BZ8GAChuq S6BqnfslMQu681Dp4OBJMKzfWRdyKSp8EGefna0cMkUW+7sKacS2CK1G55HIKyaiva6C 7PdrECp8P/vkXhD47tyoVR6hT25MD4tVpYjCUA2iECWaWPGPdtDrSvVYWJEqZqsT1xKm JdiD3EQ/59RVFLORIX9EaGarligmsJq/PgmDTsHVcP5KrBe8RjVh+WWdZZb5qsf+XcRG Mm3nv23IpiEyvg6NGMvifi7I8f01vNQiM25HSA3f5XEG8+d4nTeCMcSgMOVjDpibLbiJ EUFA== X-Gm-Message-State: APzg51BUFp3q5gPslv2ROXNZ2lI8HJci0yhioCj0U85IYrGRCRRIjcpb hUZrzFzZQcjRpP0z8BEVfyayOYEa/t30tfuHJ536iQ== X-Google-Smtp-Source: ANB0VdZGEP6eLIq//pNXHOwPDDrReNEFUhszDWe73klIn15VMBsKKJXiOiihMUiDeblorcx7EsVFe2xJrPTSpS+9SvE= X-Received: by 2002:aca:4c14:: with SMTP id z20-v6mr12442535oia.164.1535392481976; Mon, 27 Aug 2018 10:54:41 -0700 (PDT) MIME-Version: 1.0 References: <20180825010023.GD45503@funkthat.com> <20180825052330.GE45503@funkthat.com> In-Reply-To: From: David Cross Date: Mon, 27 Aug 2018 13:54:30 -0400 Message-ID: Subject: Re: Weird USB DA behavior (was: Re: weird geli behavior) To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 17:54:43 -0000 On Sat, Aug 25, 2018 at 4:22 PM David Cross wrote: > Top-posting because this just took a radical change in direction > > Ok, I need to take some of this back; I do still believe that there is > some weird GELI-ness going on (or perhaps GEOM itself), in terms of hangs, > but it may be being tripped over by some weird USB-DA behavior I noticed in > trying to track this down. > > Ok... I think I found the smoking gun, I think between all of the multiple layers of GEOM (geli->mirror->intermediate physical->physical) and something that postgres is doing its filling up the 'transient arena'; I even found a few pause()s in geom_io.c that seem to correspond to what I am witnessing. Also there's: kern.geom.transient_map_soft_failures: 356796 kern.geom.transient_map_hard_failures: 35650 My *guess* as to what is going on is that there is a MASSIVE spike of IO operations triggered by postgres doing 'something' with the the data on disk to close out a transaction, this causes a spike in mappings to ELI... which cannot pass things off to mirror because the transient area is full.. the system then sleeps for a second seeing if something has cleared (which it cannot because it cannot get to disk).. it then fails the request. Eventually this bleeds down to where the queue can flow (and is where I see the spike in operations and everything clearing up at once). The default transient arena seems to be just 1024 pages (4M?) and is hard-coded. It also looks like there aren't any kernel messages at the default level when you hit this (or if they are they seem to get eaten by the fact that nothing can log... because, well... IO is deadlocked). I won't be able to test this until this evening when I can bump this up... any reason to not set this to 10240 or higher? its a 64bit machine with 72G of RAM. Longer term, if this is the cause, and with the inherent nesting nature of GEOM I think we need a way to handle this better. Next up: figure out why random 20480 byte reads are choking on this machine.. I tried the earlier mentioned pread test on a different machine with the EXACT same model external array, and it worked perfectly. so its either the machine or the drives... more experimenting to do! > I turned debugging ALL the way up on geli (3) and noticed the hangs always > happened when geli handed off a 20480 length read to the layer below (in > this case mirror).. I used the rebugging output to create a dummy program > called 'pread' to try to simulate these failures, and I was quite > successful. Attached is 'pread.c' which takes on stdin a offset and a > length to read. In that version I overwrote it to always ask for 32k., and > that works every time. If I eliminate that line and let the input data > control it, on some of the 20480 (and a different set each time) it hangs, > after the hang the pread returns _0_ (and obviously no errno), no kernel > logs. "pread" is run directly against /dev/da0, so no mirror or geli > layers at this point. > > > Kernel attach messages of relevance: > da0 at umass-sim0 bus 0 scbus7 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number 574343344532485548465239 > da0: 40.000MB/s transfers > da0: 3815415MB (976746240 4096 byte sectors) > da0: quirks=0x2 > > Relevant output of a pread run: > ~ # ./pread /dev/da0 < requestdata.txt > 117535768576(20480)=0(0) > 189095018496(20480)=0(0) > > (last 0 is a trivial patch to include errno output) > > On Sat, Aug 25, 2018 at 1:23 AM John-Mark Gurney wrote: > >> David Cross wrote this message on Fri, Aug 24, 2018 at 22:42 -0400: >> > >> > >> > > On Aug 24, 2018, at 21:00, John-Mark Gurney wrote: >> > > >> > > David Cross wrote this message on Fri, Aug 24, 2018 at 17:54 -0400: >> > >> Ok, I am seeing something truely bizzare, I am sending this out as a >> shot >> > >> across the bow since I am not even sure where or how to begin >> debugging >> > >> this. >> > >> >> > >> Some background. This in on an Intel Xeon 5520 based machine, 72G >> ECC >> > >> memory, 11.2, fully patched. Though this has been a problem since >> at least >> > >> 11.1, probably 11.0, and maybe earlier. ~4G of eli encrypted swap, >> which it >> > >> basically never even touches, even when problems are occuring) >> > > >> > > I assume you've applied the lazyfpu SA patch? >> > > >> > > If so, there's another patch you need to apply, see: >> > > >> https://docs.freebsd.org/cgi/mid.cgi?20180821081150.GU2340@kib.kiev.ua >> > > >> > I will definitely apply this, but I don???t think it applies to the >> problem in question. This system doesn???t have AESNI, this problem well >> preceded the lazyfpu patch, and i am not seeing any corruption on disk. >> >> Hmm, k... >> >> > >> The first symptom was (and I think these are all aspects of the same >> root >> > >> underlying cause) that fsck on a geli encrypted d stripe of 2 USB >> drives >> > >> would *randomly* error out on a corrupt entry. Upon investigating >> this I >> > >> discovered by watching gstat that as this happened the IO on the >> drives >> > >> would STOP. the L(q) would hover at 1 for a number of seconds, and >> then >> > >> when it returned fsck was complaining about various corrupt >> structures. a >> > >> ktrace of fsck shows that it got back data from the pread() that was >> > >> partially corrupted (I am guessing, but I cannot confirm that 'some >> part' >> > >> of the stack handed back a zeroed page, or otherwise 'not the right >> data' >> > >> that geli dutifully 'decrypted'. No errors are ever logged in the >> kernel >> > >> about da0 or da1 (the respective underlying USB disks). It *seems* >> this is >> > >> *always* on phase 2 of fsck (files and paths), and its never the same >> > >> inode. no data is *ever* corrupted when in the filesystem, no >> matter how >> > >> hard I hit the disks (all data on these devices is fully checksummed) >> > >> Devices have passed multiple SMART full diag checks, full read/write >> tests >> > >> with no issues. Under heavy FS IO it does occasionally lock.. but >> > >> recovers, and again data and filesystem are fully consistent. >> > >> >> > >> I was willing to live with that.. weird as it was (these are backup >> disks, >> > >> data is fully checksummed, and I was only fscking out of extreme >> paranoia >> > >> every reboot) Then I added an internal drive, configured with >> gmirror >> > >> (broken mirror currently, second disk hasn't been added) and geli. >> On this >> > >> disk I have a postgres 10 database in WAL replication. This was >> working >> > >> fine and then the other day the system just locked for a few hours. >> During >> > >> that time I saw the L(q) of the _internal_ disk in the 10,000+ >> range, and >> > >> it doing _1_ operation a second to the underlying disk... all the >> while >> > >> geli is logging 'error 11' to the console (nothing about the >> underlying >> > >> disk) After this happened a static file on the disk (a zip file) >> had bad >> > >> data in the middle of a page (after reboot the file was ok.. so it >> was >> > >> just in cache). Again, this disk fully checks ok, no corruption on >> the >> > >> disk, no errors from the disk itself. >> > >> >> > >> >> > >> Halp? where do I even begin with this? It really feels like there >> is >> > >> some massive locking going on in geli in some way? Where should I >> even >> > >> begin looking? I run geli on most of my systems and don't have any >> issues. >> >> Can you post actual log lines? geli has lots of error log lines, so w/o >> more info, pretty hard to say WHAT in geli is returning EAGAIN. I do see >> that _read_done and _write_done may not handle an EAGAIN error, which >> could >> cause this problem, but to confirm, I need the actual log lines... >> >> -- >> John-Mark Gurney Voice: +1 415 225 5579 >> >> "All that I will do, has been done, All that I have, has not." >> > From owner-freebsd-hackers@freebsd.org Mon Aug 27 21:30:27 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CC8E1096A58 for ; Mon, 27 Aug 2018 21:30:27 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EEE5683FF2 for ; Mon, 27 Aug 2018 21:30:26 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id 8-v6so884273oip.0 for ; Mon, 27 Aug 2018 14:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j1Y2vvZIQ6NxQc4Dvvs4m9AeyNSgfRIdEvUACdkWYoM=; b=bPeQhNa1QNLSD7ZHQzFSzzEFB7pz4BYGf4VTngAs4yOdcvo+3AgDzV8zMWooRK8EGd 2Nn4CJqTUE+YEYWHqyQ21CDJRTuhYAdU79+128TagBv0SqbqQElWu3rIZNmdGnEIveVD IxJcRDKdhpLWfpPJFzHbLGALiDMonpzJoKGu3/SEvYEb7bEHWJxVQH+T+zxLJYCl3JFv 5wPy33und38/0gKTFLSTyANc7+G0UmQMEWZ05/sGnI1UJwAZytp1vyDxHY+LieRyvKvI WeV1F864bVKCwLQR1vUY2u8o08yYX6qU8jURV6smXD3u0fX5vIbbvp+7ZB+SK7BXRGK+ 1qnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j1Y2vvZIQ6NxQc4Dvvs4m9AeyNSgfRIdEvUACdkWYoM=; b=V+BeYzjYzBoPOf8RPuDJwrqTTqgRFpIMhCEUqBJsKZjGZrKtdwyVntkjQQT1fomvkr 3kOK2vAamOCRnPYdQEdm+uO+XxN0VAYQKJX+qodszznExL1489QwIN2DwouWeQpxGOOf M/JbkobX5RKQa0lqw3SyNOTRXp5B6jSPuzcz3XPhB5qjsIG0rkFUB3imSRUkfCLHaWmO XFb6ZS1K2lTm2DElU5cyH5pq2trR/F8qeIVhGtdEu/DtZfdgkIJF+7ZXvpc5TWSbO0tk cruyVjKxlYAH0u9ytkzJi+UqVespXqjMn4ohDA4jM6Y63/l2TSpOYO+3U/qVO7XU+1Xw sWdQ== X-Gm-Message-State: APzg51BzjLSGkGXtzmAhLwcMcsHtgy1UPa2VjzI87Jk2BQt83z5WSS6s 6e488IkYXTAIAZa7p04aoi7wp8VOfCGGpbqdwIbhCg== X-Google-Smtp-Source: ANB0VdboyG+8ym5VRnSGG3HsYG+CMghrj4GQ1+fFJEinMA1KFSltSn7GWKvy6IiRki2uYmElHMoQxZXyPasyP7nfAFE= X-Received: by 2002:aca:b904:: with SMTP id j4-v6mr379639oif.89.1535405426195; Mon, 27 Aug 2018 14:30:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:2b9c:0:0:0:0:0 with HTTP; Mon, 27 Aug 2018 14:30:25 -0700 (PDT) In-Reply-To: References: <32e008cf-93d3-944d-9b11-e56f1bb425ef@wyatt672earp.force9.co.uk> From: Stefan Blachmann Date: Mon, 27 Aug 2018 23:30:25 +0200 Message-ID: Subject: Re: Ryzen Build Problem To: Meowthink Cc: Mitchell , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 21:30:27 -0000 It is remarkable that AMD's list only contains "brands" like Crucial and the like, but not a single first-party-manufacturer. Why? Because the first-party-manufacturers do not sell bad memories, for simple reputation reasons. The question where all these masses of B-grade selection chips remain, which the memory manufacturers reject for use under their own brand, is an old taboo in the industry. My personal impression is that these are dumped via these third party memory module manufacturers. The typical gamer/overclocker customer unaware of this will readily explain away problems on her non-ECC systems equipped with memory chips rejected by the original manufacturer as "the usual Windows crashes". The consumers will even happily take the fancy "coolers" on the modules as "sign of quality and worthiness", whose actual function is to hide the crap inside. Thus my personal advice: Do not use memory modules from third-party-manufacturers. The time and data you lose does not justify the savings when buying stuff from B-grade-stuff remarketers. Only buy first-party-memory modules, i.e. Samsung, Hynix, Micron etc. (If you really insist on using third-party-modules, take Kingston, who have a comparatively small history of using unreliable chips compared to other "brands".) On 8/27/18, Meowthink wrote: > Hi frank, > > On 8/27/18, Mitchell wrote: >> >> Hi Meowthink: >> >> I'm planning a Home Build, and I came across an issue which might apply >> to your design. >> >> Some AMD CPUs are designed for Over-Clocking automatically. But when I >> investigated Memory Compatibility I saw that some Memory wasn't. > > Many Intel CPUs are turbo boost enabled, also. I think It's safe to > trust these designs. They'll communicate to memory at a steady clock > rate, which will provide by SPD chips on DIMMs. > > Ryzens are known to have compatible issues with memories. An easier > way is to choose a module which is in the qualified list, "QVL". > >> >> The "AMD Ryzen 5 2400G" looks like it can Over-Clock itself when it >> feels safe to do so. >> >> But the "Crucial 16GB DDR4-2400 EUDIMM CL17" seems to be classified as >> Server Memory, which could mean it's designed for a single speed. I >> couldn't find more details about Crucial Memory Over-Clocking. >> >> The Crucial Web Pages do feature a Help Facility which might enable you >> to check further if you input all your system details. >> > > That's a mistake months ago. What I'd care about is ECC. > I knew Ryzens (1x00) are ECC enabled. Then I was mistaken checking out > mobo's specification as Asrock didn't mention Raven Ridges (2x00G) at > that time. I thought my build with 2400G will got ECC, but sadly not. > Now Asrock say these on their website: > > - AMD Ryzen series CPUs (Raven Ridge) support DDR4 > 3200+(OC)/2933(OC)/2667/2400/2133 non-ECC, un-buffered memory* > > *For Ryzen Series CPUs (Raven Ridge), ECC is only supported with PRO CPUs. > > In the end I got my system run, but without ECC enabled. > >> I'm no expert here. This will be my first Home Build attempt and I >> haven't even started yet. You probably need a 2nd and 3rd opinion on >> this topic. I'm just hoping my contribution will prompt further comments >> from FreeBSD people with more know-how than I've got. >> >> Yours truly: Frank Mitchell >> > > You are welcome. > > Cheers, > meowthink > >> On 27/08/18 09:13, Phil Norman wrote: >>> Hi. >>> >>> I have a similar setup: Ryzen 3 and Fatal1ty X370 mini-ITX. I had some >>> trouble with instability, although my problems weren't panics, but >>> rather >>> two issues. One was random lockups (with no evidence left in logs), but >>> I >>> *think* this was down to an inadequately cooled graphics card. >>> >>> The other problem I had was with USB. I got quite a spam of log messages >>> about the USB reinitialisation. However, eventually I figured out that >>> the >>> problem didn't occur if I booted the system from a completely >>> powered-down >>> state. That is, use the physical switch on the PSU to cut power >>> entirely, >>> re-enable, then boot from that state. Since then I've had 67 days of >>> uninterrupted uptime, with no USB issues at all. >>> >>> It sounds like your problem is different, but trying a boot-from-cold >>> might >>> be worthwhile, just in case ASRock have a consistent problem in this >>> regard. >>> >>> Cheers, >>> Phil >>> >>> On 26 August 2018 at 13:20, Meowthink wrote: >>> >>>> Hello all, >>>> >>>> Recently I tried to build up a Ryzen system and run FreeBSD on it. >>>> CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics (0x810f10) >>>> Mobo: Asrock Fatal1ty AB350 Gaming-ITX/ac ( with up-to-date BIOS with >>>> PinnaclePI-AM4_1.0.0.4, microcode 0x810100b ) >>>> Mem: 2x Crucial 16GB DDR4-2400 EUDIMM CL17 ( ECC Unregistered but ECC >>>> actually won't work :( ) >>>> >>>> But the system is unstable - it can't last few days even is nearly >>>> idle. System panics even at midnight. It almost panic while or after I >>>> built something large. Surprisly I didn't encourage a user program >>>> fault, bad binaries built etc., panics only. >>>> >>>> Then I tried lots of BIOS settings e.g. SMT, C6 idle current, >>>> underclock RAM, but none seems effect. >>>> It could pass memtest86 V7.5 without error, or various benchmarks >>>> under Windows. thus I think the problem is not in the hardware but >>>> software. >>>> >>>> In the mean time, I realized that the rate of irqs from xhci0 are too >>>> high - it's about 1998/s. I found [1] and tried to MFC r331665. It >>>> didn't fix the problem though, but disabling that bluetooth module >>>> stops the irq storm, after all. >>>> >>>> Then the system lasts much longer before panic. It eventually can >>>> compile ports tree, build the world, scrub the zpool, all done without >>>> annoying reboots. >>>> Then I assume this is [2] related? So I also tried cpuctl, bounding >>>> all processes to 2-7. >>>> But the problem is still there, only the chance become very low. It >>>> still panics occasionally, idling a week or stressing few hours - >>>> Stress seems to rise the chance of panic, but differently by types. >>>> Things like llvm will always build, but gcc will cause a panic per few >>>> passes. >>>> >>>> The system was 11.2 but then moved on to stable/11 (r337906 >>>> currently). I've got last 10 coredumps saved but my kernel isn't >>>> compile as debug. So I'll put some backtrace from core.txt.? in the >>>> end. >>>> >>>> Indeed I want to eliminate this problem. Could someone guide me how to >>>> figure out the problem? What should I try next? >>>> >>>> Best regards, >>>> Meowthink >>>> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Tue Aug 28 00:44:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01524109ABBF for ; Tue, 28 Aug 2018 00:44:08 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A58F38AC02; Tue, 28 Aug 2018 00:44:07 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id E05F5266EF; Tue, 28 Aug 2018 00:44:06 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Mon, 27 Aug 2018 17:44:04 -0700 (PDT) From: Don Lewis Subject: Re: Ryzen Build Problem To: Stefan Blachmann cc: Meowthink , freebsd-hackers@freebsd.org, Mitchell In-Reply-To: Message-ID: References: <32e008cf-93d3-944d-9b11-e56f1bb425ef@wyatt672earp.force9.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 00:44:08 -0000 On 27 Aug, Stefan Blachmann wrote: > It is remarkable that AMD's list only contains "brands" like Crucial > and the like, but not a single first-party-manufacturer. > Why? Because the first-party-manufacturers do not sell bad memories, > for simple reputation reasons. > > The question where all these masses of B-grade selection chips remain, > which the memory manufacturers reject for use under their own brand, > is an old taboo in the industry. > > My personal impression is that these are dumped via these third party > memory module manufacturers. > The typical gamer/overclocker customer unaware of this will readily > explain away problems on her non-ECC systems equipped with memory > chips rejected by the original manufacturer as "the usual Windows > crashes". > The consumers will even happily take the fancy "coolers" on the > modules as "sign of quality and worthiness", whose actual function is > to hide the crap inside. > > Thus my personal advice: > Do not use memory modules from third-party-manufacturers. > The time and data you lose does not justify the savings when buying > stuff from B-grade-stuff remarketers. > Only buy first-party-memory modules, i.e. Samsung, Hynix, Micron etc. > (If you really insist on using third-party-modules, take Kingston, who > have a comparatively small history of using unreliable chips compared > to other "brands".) Crucial == Micron. There is a Micron copyright notice at the bottom of the Crucial home page, and a link to Crucial at the bottom of the Micron home page. When I put together my Ryzen machine last year, I purchased the Crucial DDR4-2400 ECC RAM that was listed on the motherboard vendor's qualified list. I also looked up the part number for the Micron-branded equivalent, but didn't find any available for retail sale. I've used a fair amount of Kingston RAM in the past, but at the time they didn't have DDR4 ECC RAM in that speed grade. From owner-freebsd-hackers@freebsd.org Tue Aug 28 07:54:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B70AF1083182; Tue, 28 Aug 2018 07:54:29 +0000 (UTC) (envelope-from karu.pruun@gmail.com) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49C9D77E03; Tue, 28 Aug 2018 07:54:29 +0000 (UTC) (envelope-from karu.pruun@gmail.com) Received: by mail-oi0-x230.google.com with SMTP id m11-v6so1243326oic.2; Tue, 28 Aug 2018 00:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eAcgzY1NIaxtckyR7cbFcoGaCaI+5moTYcJs2FjUVuo=; b=mdatqCzHN8VNUWWXrqyEE6bj5OEpRiX0Fy1C8X5oWZ+BYXe+kYAcy3F+iSghmwAMjk PKHr1SUNtBGaThvcJijXGyRJi9Hfz4AtcHfoKrtVHA7XBj/WFFUer+vlmI4CiJNvucyd /Ovvfi70TFt4A7VNz2dEovlvfmSsLsVIOIA9/K6QFfRpaK31Rtu4qrKeqywQVMf3wb0N sCXlalwqXJzNaYTD5sHVQDgdjrOORFb+TEw/LrDtXwuhRFAHYt6kYVlQyhyqR6eTobsB 9DHOimYu/Yd+AAqh5D/GqX3hm85SCpJYp/whxosY3CM/PDidRIYUxfZRGi/gxpU0dsgA EHhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eAcgzY1NIaxtckyR7cbFcoGaCaI+5moTYcJs2FjUVuo=; b=oPMA6TcG3m65SzzcMqZvZm08KoAUPf8w+12jxpln44dNq+V6uAJKxYw+oh7l+Q9oMX JGB+3ej3no3V08fOFupQWP9VPQK9zcaUJF3wEAIr5FDuYuT9IWjkO8GULtpB0bJ9Z5Rs a7yYGFDMZ92HPvhQ9ZbQvNQaWhuaKVI4YAFgOlaZP+o4FApKsgLjJaVIyuTAJ4OVcdyG DMIlxvxw/yMokem9z+SozmOc9qgOeVnMCn4Gs0+zuCcUxGjLg7yaEutxOnkXe5N8ikM6 UZkGQ7U+4pC7QeF61amesotRMnuvDUi/Zk2JHlx+kAn6MyTfFFlOBvJ5Q9CSGJHIK/cN 6tFw== X-Gm-Message-State: APzg51CWmVgimPdlypOM34IWkLRWRFB31XY2NcoVt4dJhSFWw6Xv5niW kYfOmsn3Qs1KZOY2/BfxrNAKNkO4N6m4Lj7aPVUZNTUT X-Google-Smtp-Source: ANB0VdZM9jQ+0ivEdpETv6TMBivVynQBhrl1W2Zl71o2k3f+bKFIs6Dhd6s7xNrGqsB0tNbxaHcusAabGDNQRIuvDKM= X-Received: by 2002:aca:5c85:: with SMTP id q127-v6mr333957oib.127.1535442868629; Tue, 28 Aug 2018 00:54:28 -0700 (PDT) MIME-Version: 1.0 References: <20180827132905.191dbd8c@ernst.home> In-Reply-To: From: "karu.pruun" Date: Tue, 28 Aug 2018 10:54:17 +0300 Message-ID: Subject: Re: Help diagnose my Ryzen build problem To: Si Miao Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 07:54:30 -0000 On Mon, Aug 27, 2018 at 6:07 PM Meowthink wrote: > >> Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my > >> Ryzen 5 2400G's model is 11h. > >> > >> On the microcode. It shall be updated through UEFI/BIOS updates. I > >> think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel > >> 0x810100b. > >> > >> Seems like ... the only thing I can do is sit down and wait? > > > > The revision > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/cpu_machdep.c?r1=336763&r2=336762&pathrev=336763 > > > > works around the mwait issue, i.e. it sets > > > > sysctl machdep.idle_mwait=0 > > sysctl machdep.idle=hlt > > > > I think that shall not apply to 2400G, which is model 11h not 1h. > Here're what I have now: > > machdep.idle: acpi > machdep.idle_available: spin, mwait, hlt, acpi > machdep.idle_apl31: 0 > machdep.idle_mwait: 1 > > > Now it may or may not relate to your problem, but it appears that > > Ryzen 2400G also has another issue with HLT, see the DragonFly bug > > report > > > > https://bugs.dragonflybsd.org/issues/3131 > > > > Thanks a lot for that info. > It's much easier to prove your problem, since it's reproducible. But > mine was so random to catch... > Anyway, it seems like the IRET issue [1] is still not fixed? I'm > highly doubt that my issue is this related because my system became > significantly more stable since I stop that irq storm from bluetooth > module - Though it still panics occasionally. > So could anybody tell, what's the difference between FreeBSD > workaround [2] and the DragonflyBSD one? > > > which AMD is aware of and is possibly working on, but it may not have > > appeared in the errata yet. The bug report says that until this is > > fixed, the workaround is to also disable HLT in cpu_idle. I am not > > sure what is the correct value for the sysctl on FreeBSD, perhaps > > > > sysctl machdep.idle=0 > > > > or some other value? > > In the meantime, I have this microcode > > # cpucontrol -m 0x8b /dev/cpuctl0 > MSR 0x8b: 0x00000000 0x0810100b > > Hence I should use mwait? > Still don't know what should I set. Any idea? If I was you, I'd play around with the sysctls mentioned above and see if it helps. Start with disabling both mwait and hlt, perhaps machdep.idle=spin machdep.idle_mwait=0 (assuming that 'spin' means hlt will not used) and then if that does not lead to a panic, try enabling mwait. I can't test 2400G since I don't have it any more. I booted FreeBSD a couple of times but did not run it over long periods of time. Cheers Peeter -- From owner-freebsd-hackers@freebsd.org Tue Aug 28 08:58:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 666BE1084F10 for ; Tue, 28 Aug 2018 08:58:28 +0000 (UTC) (envelope-from warmwhitewolf@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A605E7A4C9 for ; Tue, 28 Aug 2018 08:58:27 +0000 (UTC) (envelope-from warmwhitewolf@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id v17-v6so783504wrr.9 for ; Tue, 28 Aug 2018 01:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EpbQp5+XlgE1zn7RU7Mos3hGmyrNPICNlkFNzjBRCtk=; b=IylCcS3Eho+lfAf6zg+dI+V39GjxOqCJad6+6gmtytVy1LKkB8xx+7WNm4JJOlNQ0x bY32x6AQ4m3VmtShyHytThtWCpX8CIBAd7zP2rA2asdbwBv6z8aPbftiKN6Ce/sepE9Y kVPlQgD3+G4do/ohBzMCOM0BHlZUihp/BUPVQ2qMfGkHJNGeUcHPYaz61Qa/KhTntcf/ QrJPyuw2YYJcjila2WXiQ7kuBHqlRbtv/Ze1bomRvdbG5AjVxbrHbOs/VxwbeLTDnf2J ktGrdP0Dn6Z+dMLxtv5rHis7bty5oSOaYpW/DkCmEt31SF1I5Nbd2MjBEW48BR7NeYzt nJaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EpbQp5+XlgE1zn7RU7Mos3hGmyrNPICNlkFNzjBRCtk=; b=IGlWVyvFTR/ATfcZSQIIn8jK3wkXw6QoLWSQYrcGUT/Fd/TBfe6dz9uencPXpWRNt1 +Vx1ZwHCLRqSXrcW6xIq1EWjLYZrKVFJ0gjXOqdrHcBu8bMa2deqSsghGnWDsBazTFg0 KCLovN+s6OtYGY9evTCTB7WhxM/OMR4XphK/sRg4ti45ZK1Zdgd91a+UAbVnGDF8j0Kd 765dErv0M23RczgZpxywn08FxieFIIOIzDNu0+ZuNi4VeivdfOnvc5RLM8EyTyAhh4eg THtZ8t8gwPiGcTY4I+yLWN7d0uEyeZuYsWjQ1Eaoo/+GPT3iGN62fEpTyOa/hPVMVlfe qXNQ== X-Gm-Message-State: APzg51Bh39fqJI8H9NFaP5GYFD8S+rgCIFa6D8nfZGGkA3KNG1JNLuCg MCN+lm4bGMpSbGg02/Y2+uFWwI4LVD4pftMdh0m4yaDGbu8= X-Google-Smtp-Source: ANB0VdaahqynKuaalz0XYYrGB3/mbpupZ98vN90nCFsC83CmBKZKb/gnzl6GLfd38txzCY+tZGms4WHvRobWrPfWXGM= X-Received: by 2002:adf:e846:: with SMTP id d6-v6mr427018wrn.269.1535446703480; Tue, 28 Aug 2018 01:58:23 -0700 (PDT) MIME-Version: 1.0 From: Warm White Wolf Date: Tue, 28 Aug 2018 11:56:31 +0300 Message-ID: Subject: angel(2) system call, the quest for immortality, aka kill(2) with SIGSTOP/SIGKILL will *not* work To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="000000000000554ea105747b0b71" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 08:58:29 -0000 --000000000000554ea105747b0b71 Content-Type: text/plain; charset="UTF-8" Greetings ! I have developed a new system call, be it named angel(2), on Linux operating system (this is what I know), which makes a program invulnerable to kill(2) calls, including SIGKILL and SIGSTOP. The uses may involve fork() + angel(), daemon() + angel(), setsid() + angel(), exec*() + angel(). Use the intellectual property I give you, as a gift to the BSD operating system, using 4- 3- 2- BSD licence. That's it, name me in the sources. Thank you, FreeBSD ! You are a great Unix operating system ! --000000000000554ea105747b0b71 Content-Type: text/plain; charset="US-ASCII"; name="rack.01.06.txt" Content-Disposition: attachment; filename="rack.01.06.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jldh95cv1 CgkwNi4gU3lzY2FsbHMgaW4gdGhlIGxpbnV4IGtlcm5lbCwgYW5kIGluIHRoZSBnbGliYyBsaWJy YXJ5CgoJV2Ugd3JpdGUgYW5nZWwoKSBzeXN0ZW0gY2FsbCwgb24gYSA0LjE0IGtlcm5lbC4gV2Ug d2FudCBpbW1vcnRhbGl0eQoJZm9yIG91ciBwcm9jZXNzIChTSUdLSUxMIGFuZCBTSUdTVE9QIGln bm9yZWQpLCBhbmQgaWYgd2UgYXJlIGEgZGFlbW9uKCkKCXdlIGNhbiBvYnRhaW4gc3lzdGVtLWxp ZmUtdGltZSBwcm9jZXNzZXMvZGFlbW9ucy4gTm90ZSB0aGF0IHRoZSBhbmdlbCgpCglzeXNjYWxs IGNhbiBiZSB1c2VyIGFsc28gYnkgdXNlci1jb25zY2lvdXMgcHJvY2Vzc2VzLCB3aGljaCByZXR1 cm4gMDsKCgoJSG93IEkndmUgZG9uZSBpdCA6CgkKCTEuIENoYW5nZWQgc3RydWN0IHRhc2tfc3Ry dWN0LCBmb3VuZCBpbi91c3Ivc3JjL2xpbnV4L2luY2x1ZGUvc2NoZWQuaAoJYnkgYWRkaW5nIGEg aW50IHVuaXhfZGVhZGx5X3NpZ25hbHM7IGZpZWxkLiBXZSB3YW50IHRoaXMgdG8gYmUgMCwgYW5k Cgl0byBiZSAxLCBvbmx5IHdoZW4gY2FsbGVkIGJ5IHN5c19hbmdlbCgpID09IGFuZ2VsKCkuCglJ biBpbmNsdWRlL3NjaGVkLmgKCQoJMi4gRm9yIHRoaXMsIHdlIG11c3QgbW9kaWZ5IGRvX2Zvcmso KSAvIF9kb19mb3JrKCksIHNvIHdoZW4gd2Ugb2J0YWluCglwID0gY29weV9wcm9jZXNzKCksIHJp Z2h0IGFmdGVyIGl0IHAtPnVuaXhfZGVhZGx5X3NpZ25hbHMgPSAwOwoJSW4ga2VybmVsL2Zvcmsu YwoKCTMuIFJlbWVtYmVyIGZvciB3aGF0IHdlIGhhdmUgY3JlYXRlZCBzeXNfYW5nZWwoKSA6IGlm IHNvbWVvbmUgc2VuZHMsCgl1c2luZyBraWxsKDIpIHN5c3RlbSBjYWxsLCBTSUdTVE9QIG9yIFNJ R0tJTEwgc2lnbmFsIHRvIG91ciBwcm9jZXNzLAoJaGUgbXVzdCBmYWlsLiBMb29rIGluIGtlcm5l bC9zaWduYWwuYywgdGhlcmUgaXMgYSBmdW5jdGlvbgoJZG9fc2lnYWN0aW9uKCksIGFuZCB3ZSBt b2RpZnkgOgoJCWlmIChpbmZvID09IFNFTkRfU0lHX0ZPUkNFRCAmJiB0LT51bml4X2RlYWRseV9z aWduYWxzID09IDEpCgkJCXJldHVybiAocmV0ID0gMCk7CgoJNC4gSW4ga2VybmVsL3N5cy5jLCBv ciBhbm90aGVyIGZpbGUsIHdlIFNZU0NBTExfREVGSU5FMChhbmdlbCkgewoJCWN1cnJlbnQgLT4g dW5peF9kZWFkbHlfc2lnbmFscyA9IDE7CgkJcmV0dXJuIDA7Cgl9CgoJNS4gSW4gc3lzY2FsbF82 NC50YmwsIHRoZSAzMzMtdGggc3lzdGVtIGNhbGwgZm9yIDMzMi1zeXN0ZW0gY2FsbHMKCW9yaWdp bmFsIDQuMTQuMTEgTGludXgga2VybmVsLCBpcyA6CgkJMzMzCWNvbW1vbgkJYW5nZWwJCXN5c19h bmdlbAoKCTYuIEluIGluY2x1ZGUvbGludXgvc3lzY2FsbHMuaCwgYWRkIHRvIHRoZSBlbmQgb2Yg dGhlIGZpbGUsIHJpZ2h0CgliZWZvcmUgI2VuZGlmLAoJCWFzbWxpbmthZ2UgbG9uZyBzeXNfYW5n ZWwodm9pZCk7CgoJNy4gSW4gdXNlcnNwYWNlLCB0aGUgZm9sbG93aW5nIHRlc3QgcHJvZ3JhbSwg YWdhaW5zdCBTSUdLSUxMID09IDkKCWFuZCBTSUdTVE9QID09IDE5IChhbmQgb3RoZXIgc2lnbmFs cyBJIGd1ZXNzLCBidXQgd2h5IEkgZG8gbm90IGtub3cKCXdoeSk6CgkJI2luY2x1ZGUgPHVuaXN0 ZC5oPgoJCSNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgoKCQlpbnQgbWFpbigpCgkJewoJCQlzeXNj YWxsKDMzMyk7CgkJCXNsZWVwKDY2KTsKCQkJcmV0dXJuIDA7CgkJfQoKCUNvbXBpbGUgaXQgOiAk IGdjYyBhbmdlbC5jIC1vIGFuZ2VsCglSdW4gaXQgICAgIDogJCAuL2FuZ2VsICYKICAgICAgICBU ZXN0IGl0ICAgIDogJCBraWxsYWxsIGFuZ2VsCglJdCBleGlzdHMgIDogJCBqb2JzCgkJWzFdKyBS dW5uaW5nIAkJLi9hbmdlbCAmCgoJOC4gQ29uY2x1c2lvbiA6IElUIFdPUktTLgoJOS4gV2hhdCBy ZW1haW5zIHRvIGRvIDogdG8gd3JpdGUgYSB3cmFwcGVyIGluIGdsaWJjLCBhbmQgY29tcGlsZSB0 aGUKCWdsaWJjLCBieSB0aGUgcnVsZXMgb2YgZ2xpYmMsIGFzIHdlCgkxMC4gQ29tcGlsZWQgb3Vy IExpbnV4IGtlcm5lbC4KCgoJd2hpdGV3b2xmLCAyMDE3LzIwMTgKCQoJb3RoZXIgc291cmNlcyA6 IAoJICAgIGh0dHA6Ly9hbGV4YW5kcmlhLWtld2wtdGhpbmdzLmJsb2dzcG90LnJvLzIwMTcvCgkg ICAgMDgvb3BlcmF0aW5nLXN5c3RlbXMtdW5peC1teXRoLWJ5cGFzc2VkLmh0bWwK --000000000000554ea105747b0b71-- From owner-freebsd-hackers@freebsd.org Tue Aug 28 14:52:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBD18108EDAE for ; Tue, 28 Aug 2018 14:52:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3736E88357 for ; Tue, 28 Aug 2018 14:52:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f175.google.com with SMTP id 203-v6so1647471ljj.13 for ; Tue, 28 Aug 2018 07:52:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aOUfGcYuDyWyNURwJXYuQf5+FDeDiCuTeGo36Ob33z8=; b=jDMR+e3zSlV0DlxDBID5dcYxC9N2xCHh63CiLXBQCfzTHS7wsyZH6K5exxpcLaBE8k FvgBIvPZ56Zwcz3k++RfHR8QGeBjIOUP5dONFaBkEchCuImp26yuFF6ZicwsaFio2kHr d1W6BfNUNIUhmjuCzz9NgCCmsQJ1rtE7icY91hsaYGolRvbjtTSwnYXH/J274l+6fTha qoBVeSVFAOjV8Vu1uUeilEUHbUFmsTEJzVg6GT3+WWYrrmzwQ+V2ul57UPZohDW2MC30 cQK0KQJgUm2zHcYzJK8zJtgoNWgEyvnWpxWUl7FbqnTd8HpjWt541eiAdhu6dHK3NIUc b7Fg== X-Gm-Message-State: APzg51BX2aXWf6roJiQHq/Y9ijrM4of3mco2gEufS0OadkajMorzzYck jc4XQqF4KFCiRG65+Kf84Bw7IPMhvGF/3948uJY= X-Google-Smtp-Source: ANB0VdblOxFno4cvAO+Ni4bbnOXnfcK3lXy6AIjXyYskhKf2jp49m9BMuXBXx96sgy5/8d0il0LL89Mh72kh0yYKNZ4= X-Received: by 2002:a2e:4401:: with SMTP id r1-v6mr1577642lja.21.1535467587583; Tue, 28 Aug 2018 07:46:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Tue, 28 Aug 2018 08:46:15 -0600 Message-ID: Subject: Re: angel(2) system call, the quest for immortality, aka kill(2) with SIGSTOP/SIGKILL will *not* work To: warmwhitewolf@gmail.com Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 14:52:16 -0000 On Tue, Aug 28, 2018 at 2:59 AM Warm White Wolf wrote: > Greetings ! > > I have developed a new system call, be it named angel(2), > on Linux operating system (this is what I know), which makes > a program invulnerable to kill(2) calls, including SIGKILL and > SIGSTOP. > > The uses may involve fork() + angel(), daemon() + angel(), > setsid() + angel(), exec*() + angel(). > > Use the intellectual property I give you, as a gift to the BSD > operating system, using 4- 3- 2- BSD licence. That's it, name > me in the sources. > > Thank you, FreeBSD ! > You are a great Unix operating system ! > What are the applications? Blocking SIGKILL is pretty extreme. -Alan From owner-freebsd-hackers@freebsd.org Tue Aug 28 15:47:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C76F108FEF5; Tue, 28 Aug 2018 15:47:22 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E25A8A7DC; Tue, 28 Aug 2018 15:47:22 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: by mail-oi0-x241.google.com with SMTP id m11-v6so3707949oic.2; Tue, 28 Aug 2018 08:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=qXyAvNjumhujN3WX0qEB6idGe6QmP0AiZO0Bkfb0+Gg=; b=uB8Xfrf0TW3b60TdeXe9W+MR44PCoNT7PvmnVozjh24mxFpZhYHmHnqx5+8fPaU5I0 CzDBYrWuTmOOq7ZarZruSyNT3Qu8vg18DAQvH7q1PchEt8cd8GGOaY3CfzrWf34p/D6p hcuappI2CqlbA9RtwK5fG+z/ihJzW/bWCDRpR2JSDFuPPILTjCbSmparxsBZU29wHGA1 VgYSEsKpeQYm9EFBO8jIX5iOrw+uym3v3wEMMKQLsq0qX9oFKLXJpBkldaOKMqglZkA+ WO7KBA7N5ISut5XdTb9iRaiMhOLjUb9Gi8JwXgb6WQo7ilM4ahA5Xbvh55QbfK7/2UCa kFTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qXyAvNjumhujN3WX0qEB6idGe6QmP0AiZO0Bkfb0+Gg=; b=ez+wStvih7XCPuxdoN9rRwC657l8ClD0W5+fdW4hepgduHvHGqlMASE8sXL9KcAKk+ q4oNrXqIngwT0CZJXmRmxHXiYZdJllncxCNzH/pgptdvCFjh3X7EX7nuIXw1HItkaIXF 19Tf4BIL7dqSenjJttozI8cmao5MmJhaIt+2RrsupeD/fHEq7kDHgMOyWzLQ9uKm9ftO l5i76dqeeDVIoqTLppSWnJ50UER+wrsQYVyKCz+2WfEHG5a6jP4KNHGXJbo1p47ESj6x 3yoa7tlZXUhpeYovPdaZzMREyfafLWc+ppqa8aur2lx7g9QwiZXoCTrx+Cuwhkj+eGo+ qc+g== X-Gm-Message-State: APzg51DHeOkSH5DGUUlKF5rWHbZuNeWiLuLdvxm/T0OxatemTDSi9PBa yn6IrvsdpU/ETyruQ25ML1VLKORm6RnCUZrBtZA= X-Google-Smtp-Source: ANB0VdZEGQXLFqeWgykXke6mXTZ1kQ7wLpdovAqm3jYSzN4p9/w84RW3HRz3Y0HFyconwrGM+7ZcMLcuef4NTYBSWuU= X-Received: by 2002:aca:4802:: with SMTP id v2-v6mr1841203oia.259.1535471241321; Tue, 28 Aug 2018 08:47:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:a54:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 08:47:20 -0700 (PDT) From: Meowthink Date: Tue, 28 Aug 2018 23:47:20 +0800 Message-ID: Subject: Re: Help diagnose my Ryzen build problem (in progress) To: "karu.pruun" Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 15:47:22 -0000 Hi Peeter, On 8/28/18, karu.pruun wrote: > On Mon, Aug 27, 2018 at 6:07 PM Meowthink wrote: > >> >> Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my >> >> Ryzen 5 2400G's model is 11h. >> >> >> >> On the microcode. It shall be updated through UEFI/BIOS updates. I >> >> think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel >> >> 0x810100b. >> >> >> >> Seems like ... the only thing I can do is sit down and wait? >> > >> > The revision >> > >> > https://svnweb.freebsd.org/base/head/sys/x86/x86/cpu_machdep.c?r1=336763&r2=336762&pathrev=336763 >> > >> > works around the mwait issue, i.e. it sets >> > >> > sysctl machdep.idle_mwait=0 >> > sysctl machdep.idle=hlt >> > >> >> I think that shall not apply to 2400G, which is model 11h not 1h. >> Here're what I have now: >> >> machdep.idle: acpi >> machdep.idle_available: spin, mwait, hlt, acpi >> machdep.idle_apl31: 0 >> machdep.idle_mwait: 1 >> >> > Now it may or may not relate to your problem, but it appears that >> > Ryzen 2400G also has another issue with HLT, see the DragonFly bug >> > report >> > >> > https://bugs.dragonflybsd.org/issues/3131 >> > >> >> Thanks a lot for that info. >> It's much easier to prove your problem, since it's reproducible. But >> mine was so random to catch... >> Anyway, it seems like the IRET issue [1] is still not fixed? I'm >> highly doubt that my issue is this related because my system became >> significantly more stable since I stop that irq storm from bluetooth >> module - Though it still panics occasionally. >> So could anybody tell, what's the difference between FreeBSD >> workaround [2] and the DragonflyBSD one? >> >> > which AMD is aware of and is possibly working on, but it may not have >> > appeared in the errata yet. The bug report says that until this is >> > fixed, the workaround is to also disable HLT in cpu_idle. I am not >> > sure what is the correct value for the sysctl on FreeBSD, perhaps >> > >> > sysctl machdep.idle=0 >> > >> > or some other value? >> >> In the meantime, I have this microcode >> >> # cpucontrol -m 0x8b /dev/cpuctl0 >> MSR 0x8b: 0x00000000 0x0810100b >> >> Hence I should use mwait? >> Still don't know what should I set. Any idea? > > > If I was you, I'd play around with the sysctls mentioned above and see > if it helps. Start with disabling both mwait and hlt, perhaps > > machdep.idle=spin > machdep.idle_mwait=0 > > (assuming that 'spin' means hlt will not used) and then if that does > not lead to a panic, try enabling mwait. I can't test 2400G since I > don't have it any more. I booted FreeBSD a couple of times but did not > run it over long periods of time. It works! After hours and hours of different stressing. I got 8 copies of gcc built without any problem. But it costs lots of power and the fan will become very annoying. As so, I don't think I'll test long term stability with this state. machdep.idle: acpi -> spin - will add ~5W, maybe some deeper C states disabled? machdep.idle_mwait: 1 -> 0 - will add another ~50W, CPUs are working insomniac. I tried to set machdep.idle_mwait to 1, or machdep.idle to mwait. Both failed with panics when I start building gcc pass by pass. I'm pretty sure mwait will cause problem, as once I experienced a panic immediately after I issued the sysctl command (the 2nd dump info followed) So my next step will be hlt. Still need some time, though. > > Cheers > > Peeter > > -- > Cheers, meowthink ------------------------------------------------------------------------ machdep.idle=mwait panic: ffs_syncvnode: syncing truncated data. cpuid = 7 KDB: stack backtrace: #0 0xffffffff80b414b7 at kdb_backtrace+0x67 #1 0xffffffff80afa9e7 at vpanic+0x177 #2 0xffffffff80afa863 at panic+0x43 #3 0xffffffff80dcddc4 at ffs_syncvnode+0x5a4 #4 0xffffffff80dcc915 at ffs_fsync+0x25 #5 0xffffffff810ffcb2 at VOP_FSYNC_APV+0x82 #6 0xffffffff80bc3a62 at sched_sync+0x412 #7 0xffffffff80abd813 at fork_exit+0x83 #8 0xffffffff80f5cc7e at fork_trampoline+0xe ------------------------------------------------------------------------ machdep.idle_mwait=1 Fatal trap 9: general protection fault while in kernel mode cpuid = 7; apic id = 07 instruction pointer = 0x20:0xffffffff80e094fe stack pointer = 0x0:0xfffffe081e5df9e0 frame pointer = 0x0:0xfffffe081e5dfa50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 17 (dom0) trap number = 9 panic: general protection fault cpuid = 7 KDB: stack backtrace: #0 0xffffffff80b414b7 at kdb_backtrace+0x67 #1 0xffffffff80afa9e7 at vpanic+0x177 #2 0xffffffff80afa863 at panic+0x43 #3 0xffffffff80f7c14f at trap_fatal+0x35f #4 0xffffffff80f7b70e at trap+0x5e #5 0xffffffff80f5bccc at calltrap+0x8 #6 0xffffffff80e07a17 at vm_pageout+0x87 #7 0xffffffff80abd813 at fork_exit+0x83 #8 0xffffffff80f5cc7e at fork_trampoline+0xe From owner-freebsd-hackers@freebsd.org Tue Aug 28 16:37:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9640410910C3 for ; Tue, 28 Aug 2018 16:37:59 +0000 (UTC) (envelope-from warmwhitewolf@gmail.com) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08CB98C112; Tue, 28 Aug 2018 16:37:59 +0000 (UTC) (envelope-from warmwhitewolf@gmail.com) Received: by mail-wr1-x435.google.com with SMTP id z96-v6so2188807wrb.8; Tue, 28 Aug 2018 09:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dVsLlF/jeo98QydQC1BIGQ/PhqwCU8Vn9nvw2Rx9kC4=; b=HhflTW9pacHrJ8L6DTyIIXtV47VLBMDDNFbFfl0JCtv+ad69cb+lyyT8YrDebNqgVc 7g7zZS29yoG2RFLs/oz8lCSRpAKcXBm1WDaLoOPkcaOALghBw6YaOdPAb+MWOYn65kSO 17bEVJBLf4q1622zlYbdyaDbsyg0BmDSsjJArSwF5uPJ5Aauv/y8+8181Hwhm2doaFIT lNiDhb5Mu+yPlu1DZ4p//a8ziztfsCuWITVHsiZ8kJQ6Nijz/UCVt5IE5OPwT+llWfOe GVcJDSaKuQiBqW68eU/7VjPFPKseDT2UA1R33n4QT22XgrHVHTFdCNvuKoLR5XleR2nw HNBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dVsLlF/jeo98QydQC1BIGQ/PhqwCU8Vn9nvw2Rx9kC4=; b=qqLpG9hC40nplut6Xz94syUvktGxDXjQqER/ymaXOERBqmtXYbiV7q5nzDjdJFgkWT PSvIBunOIyZ7uaYse5mU+DkJPoLqBa7IfyoXDMMi9YrPguI8rOw9t6rZ/jtvBcEuK69L 4W0QhHyLrOvRShK4t+l2UMsLbrPM7FUq/Fy0yJQjjYao0eQuMry7t9ZHkA8citlDWExw omNWqEGC7PE2o7jKLMoqcBvx08WIsPZEZYrFd9u9tpIaZBOoo8hkff6cmjBz8QsKrsCY zVf/Q3xyc77rypxTJg2B5c5P4bMAXtTAGNZBmH86bb9HM44VfRHda4bRUAtLejM/aqXF ROAA== X-Gm-Message-State: APzg51CecobiZhdmdzv9kSm0GxZJciLu/GRdiOnVJ8qFlbtnwbGg99/G WEuANG1uvCq0OdAEXPJ+KaV6MfKF6v9OXC9k7JuBGbai X-Google-Smtp-Source: ANB0VdbZQ6SXx5XEjoL+/LznO9sveJa21ovbyiEbvMxY4o2zwDUsPTNJd7XowuI91qiMKLLGmEmuMgPIVKiKDSSkhqA= X-Received: by 2002:adf:9227:: with SMTP id 36-v6mr1746242wrj.275.1535474277206; Tue, 28 Aug 2018 09:37:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warm White Wolf Date: Tue, 28 Aug 2018 19:36:05 +0300 Message-ID: Subject: Re: angel(2) system call, the quest for immortality, aka kill(2) with SIGSTOP/SIGKILL will *not* work To: asomers@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 16:37:59 -0000 Seriously : suppose your well crafted, eventually audited program, is more important than your whole informatic system, perhaps the raison d'etre of your business. You want to live, more than the 1% errors of your sysadmins. Ludic : you have an account in the Unix machines at your university. You wrote your small HTTPD, and you want that your sysadmins won't kill your power-httpd. fork(void) was pretty extremy at it's time... As a power Unix-user, a config option for the kernel, at compile-time, can be provided... On Tue, Aug 28, 2018 at 5:46 PM Alan Somers wrote: > On Tue, Aug 28, 2018 at 2:59 AM Warm White Wolf > wrote: > >> Greetings ! >> >> I have developed a new system call, be it named angel(2), >> on Linux operating system (this is what I know), which makes >> a program invulnerable to kill(2) calls, including SIGKILL and >> SIGSTOP. >> >> The uses may involve fork() + angel(), daemon() + angel(), >> setsid() + angel(), exec*() + angel(). >> >> Use the intellectual property I give you, as a gift to the BSD >> operating system, using 4- 3- 2- BSD licence. That's it, name >> me in the sources. >> >> Thank you, FreeBSD ! >> You are a great Unix operating system ! >> > > What are the applications? Blocking SIGKILL is pretty extreme. > -Alan > From owner-freebsd-hackers@freebsd.org Tue Aug 28 17:20:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EFF710921C1 for ; Tue, 28 Aug 2018 17:20:10 +0000 (UTC) (envelope-from warmwhitewolf@gmail.com) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1A758DAB4; Tue, 28 Aug 2018 17:20:09 +0000 (UTC) (envelope-from warmwhitewolf@gmail.com) Received: by mail-wr1-x42f.google.com with SMTP id v90-v6so2313411wrc.0; Tue, 28 Aug 2018 10:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D1G58IfDQ9tF6irG3yUiQfBppcRsM00/RztlUJoZOt0=; b=kgY/8JoYioaTDnFgQapsZUsQPpn+3hZfjLo7MnPlra3JQZxo5pqiuS7eoHP8ojeGWm xfGYYg08OBYQr5ZwtNZrwNpws+dGFDpjdgn+lbHM/RyE/gDixnqymfnnXP4aQI5XIWEN PfDs6DDEZUWFl5jd34NqFz0h+6OB1dDyutNSTDLUuFwnL+PCV3cIeXuqmeF1pAXBOqJX ajlkGlMwJT64gfHCNYMuvC8Aw0fTnc1oydk+bW9mMr+lFleJxQgBR7322cmPC8Kwuj7Q 7brOE0UjF5PrAlGRLEcB4Vq6cv5oufHUaD4ZEsSSlblUqpWBjq7T3DNLUB7skUlRyVJv 4IDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D1G58IfDQ9tF6irG3yUiQfBppcRsM00/RztlUJoZOt0=; b=K9sM6YdJKIBEs8ukk+dgl4cbY16ua3owYrhEAycSkbYiZMFrBCCidcPpU0FgpmaMJA CHHewFhX+2OSMRRlKtO5SO1XxQV3dqb8jhfmXLEUoDIs3f7oX/MUoj5F6siBm5K0dXxy 3q7/05ULXRqq644jjxUNit03pQPkrkRC0Z7E3kb2iVoIQ8bmo6czN0rgcmgNyGMWgpMM bdAlLSzcGEQRwDusKTBS6YfQj8KtLeQsn+gJKIdekD5whgFXRPgVSDeOy4JwqNyBpqJL eNJ+lCgzodbDSdp2L2AjUU7l7YHZiMBl3qFnnsH8MXE3yT4ouhW3cUpCwKAWUdsfs/oH 5vbA== X-Gm-Message-State: APzg51CTPKxsGvMYHmjTXXmWomgKD8I5gsz+quR81IKorYWTZL8s814H pP389HbJbxX6lCIw5+7yfc6OmM2G8oOo5f/3RXo= X-Google-Smtp-Source: ANB0VdaHjiFJhx/qenxYnsie8/crbxdBsIsC+406ry2KY0PqngfVsMp/hFiSsaj2bQbfxbhxFbOITuBQ15zzZNLdeh8= X-Received: by 2002:adf:91e5:: with SMTP id 92-v6mr1823436wri.124.1535476808368; Tue, 28 Aug 2018 10:20:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:61d0:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 10:20:07 -0700 (PDT) Received: by 2002:a5d:61d0:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 10:20:07 -0700 (PDT) In-Reply-To: References: From: Warm White Wolf Date: Tue, 28 Aug 2018 20:20:07 +0300 Message-ID: Subject: Re: angel(2) system call, the quest for immortality, aka kill(2) with SIGSTOP/SIGKILL will *not* work To: =?UTF-8?Q?Danilo_Eg=C3=AAa_Gondolfo?= Cc: asomers@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 17:20:10 -0000 You know what ? It is *my* work. I do not accept negative comments, may it be practical my work, or not. Like Einstein's theory on E=3Dmc^2, the bad guys developed bombs, not wonderful purposes. Take a timeout, and come with positive uses. Bye. On Aug 28, 2018 19:47, "Danilo Eg=C3=AAa Gondolfo" wrote: > Interesting, next time someone inject a bitcoin miner in a jail running a= n > untrusted php system you'll need a reboot to stop it... > > On Tue, 28 Aug 2018, 13:38 Warm White Wolf, > wrote: > >> Seriously : suppose your well crafted, eventually audited program, is mo= re >> important than >> your whole informatic system, perhaps the raison d'etre of your business= . >> You want to live, >> more than the 1% errors of your sysadmins. >> >> Ludic : you have an account in the Unix machines at your university. You >> wrote your small >> HTTPD, and you want that your sysadmins won't kill your power-httpd. >> >> fork(void) was pretty extremy at it's time... >> >> As a power Unix-user, a config option for the kernel, at compile-time, c= an >> be provided... >> >> >> On Tue, Aug 28, 2018 at 5:46 PM Alan Somers wrote: >> >> > On Tue, Aug 28, 2018 at 2:59 AM Warm White Wolf < >> warmwhitewolf@gmail.com> >> > wrote: >> > >> >> Greetings ! >> >> >> >> I have developed a new system call, be it named angel(2), >> >> on Linux operating system (this is what I know), which makes >> >> a program invulnerable to kill(2) calls, including SIGKILL and >> >> SIGSTOP. >> >> >> >> The uses may involve fork() + angel(), daemon() + angel(), >> >> setsid() + angel(), exec*() + angel(). >> >> >> >> Use the intellectual property I give you, as a gift to the BSD >> >> operating system, using 4- 3- 2- BSD licence. That's it, name >> >> me in the sources. >> >> >> >> Thank you, FreeBSD ! >> >> You are a great Unix operating system ! >> >> >> > >> > What are the applications? Blocking SIGKILL is pretty extreme. >> > -Alan >> > >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g >> " >> > From owner-freebsd-hackers@freebsd.org Tue Aug 28 17:27:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6454010924BE for ; Tue, 28 Aug 2018 17:27:25 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DB1038DF88; Tue, 28 Aug 2018 17:27:24 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7SHRHhI006294 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Aug 2018 19:27:17 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: warmwhitewolf@gmail.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7SHR6Pg089329 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Aug 2018 00:27:06 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: angel(2) system call, the quest for immortality, aka kill(2) with SIGSTOP/SIGKILL will *not* work To: Warm White Wolf , asomers@freebsd.org, freebsd-hackers@freebsd.org References: From: Eugene Grosbein Message-ID: Date: Wed, 29 Aug 2018 00:27:00 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 17:27:25 -0000 28.08.2018 23:36, Warm White Wolf wrote: > Seriously : suppose your well crafted, eventually audited program, is more > important than > your whole informatic system, perhaps the raison d'etre of your business. > You want to live, > more than the 1% errors of your sysadmins. > > Ludic : you have an account in the Unix machines at your university. You > wrote your small > HTTPD, and you want that your sysadmins won't kill your power-httpd. > > fork(void) was pretty extremy at it's time... > > As a power Unix-user, a config option for the kernel, at compile-time, can > be provided... This does not protect a process from power outage. And this does not (and should not) protect a process from system shutdown/reboot to install critical updates, for example. Well crafted programm must be designed to be ready to such events, be able to recover and continue execution after restart. And well crafted operating systems do not kill processes with SIGKILL easily, they use other means to inform processes to terminate execution, so is FreeBSD. From owner-freebsd-hackers@freebsd.org Tue Aug 28 18:04:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8A13109308F for ; Tue, 28 Aug 2018 18:04:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 374BA8F183 for ; Tue, 28 Aug 2018 18:04:38 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: cc1015fc-aaec-11e8-a747-09a40681ccbf X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id cc1015fc-aaec-11e8-a747-09a40681ccbf; Tue, 28 Aug 2018 18:04:27 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7SI4On2012200; Tue, 28 Aug 2018 12:04:24 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535479464.10172.123.camel@freebsd.org> Subject: Re: angel(2) system call, the quest for immortality, aka kill(2) with SIGSTOP/SIGKILL will *not* work From: Ian Lepore To: Eugene Grosbein , Warm White Wolf , asomers@freebsd.org, freebsd-hackers@freebsd.org Date: Tue, 28 Aug 2018 12:04:24 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 18:04:38 -0000 On Wed, 2018-08-29 at 00:27 +0700, Eugene Grosbein wrote: > 28.08.2018 23:36, Warm White Wolf wrote: > > > > > Seriously : suppose your well crafted, eventually audited program, > > is more > > important than > > your whole informatic system, perhaps the raison d'etre of your > > business. > > You want to live, > > more than the 1% errors of your sysadmins. > > > > Ludic : you have an account in the Unix machines at your > > university. You > > wrote your small > > HTTPD, and you want that your sysadmins won't kill your power- > > httpd. > > > > fork(void) was pretty extremy at it's time... > > > > As a power Unix-user, a config option for the kernel, at compile- > > time, can > > be provided... > This does not protect a process from power outage. And this does not > (and should not) > protect a process from system shutdown/reboot to install critical > updates, for example. > > Well crafted programm must be designed to be ready to such events, > be able to recover and continue execution after restart. > > And well crafted operating systems do not kill processes with SIGKILL > easily, > they use other means to inform processes to terminate execution, so > is FreeBSD. Why are you feeding this obvious troll? -- Ian From owner-freebsd-hackers@freebsd.org Tue Aug 28 16:47:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FAEE1091597 for ; Tue, 28 Aug 2018 16:47:11 +0000 (UTC) (envelope-from danilogondolfo@gmail.com) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 665238C76D; Tue, 28 Aug 2018 16:47:10 +0000 (UTC) (envelope-from danilogondolfo@gmail.com) Received: by mail-ua1-x935.google.com with SMTP id y10-v6so1428597uao.4; Tue, 28 Aug 2018 09:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gUSf3kvkSHIlnfow5xv9X9RnJeeTL/vZV73E83dqub0=; b=TxM6XZvsIYm4DisfXVYnlRZj5bHZ56nPM5fuuB3vibst4i9NEF8rYH3VyVBhWADEbv mO+8+wCDI3x0/awRdh/QcNAx6JIl5OAk0S6P2ezQcRHHH5zwGHem+tjFbXYxLXo+Lnp6 rWkre7lWWchUGCZcL2+IoPikDSWq+ZY7G7vnww0S7vhWPeKlS31UdB0/wbLJRUxPfOpU jw1wzcMICNKWFpd3QY+PYfTQmJrKnR/zwASGC6Gp9+82G0xwk9itJqvGAJx0BBJPMaI1 SyNv6+VJ10DxY/X9KPHh/dYHsEubRnLYyvcMrL6dgYcg/4KeQlr2LxBqlP0Tq9m0nhrD B1Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gUSf3kvkSHIlnfow5xv9X9RnJeeTL/vZV73E83dqub0=; b=DSCVfbDutmCe2tPBdhqpRWwqGbso5zLtufeBeaVIK1dQNnZ9xPsgtbNEJEUFLxdOD0 QfCtADqCFcyQ9MnSJ1h5QX8GlElfWw9WD168gFYNPNqH2xGgW2E5o6eRaUagFMJzl79d 5gcLFUPUDnBFcqYeq+ZKsXYPhZxQJSov82JCeMWeQJ8rg/JdAEaj2DXG9e+OeMR4kmWd 35PHqsixv2pa3cnb6mbXefqUEohTCbZsljcUfyKdj+n2TNpd5RzAFrmbbd6GAlLeaYhC /LARoXS4kZn4sMhiWd5OgEwhN7MDeWeogtj0Wgh0YNe0G/CWCWbrR78kKkOpPAFMtBJR G/sg== X-Gm-Message-State: APzg51BTz6LFzD/QLGxvYmteBVqh6/zmcVYIJjZ2OBb+/DU1IMRlK0F+ wq8kifLEvIhYGuN0kzSzeqY9ABmvY4QOPH4wMpo= X-Google-Smtp-Source: ANB0VdbwnW7jS07PF9/RyTU2Togf1PAk6KX5Rgo0y/zTnvUz04WEZNes9gnrL1B+Y1UE4OAzjIwOABjegZ908L3clJ4= X-Received: by 2002:a9f:3f8c:: with SMTP id k12-v6mr1598717uaj.38.1535474829443; Tue, 28 Aug 2018 09:47:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Danilo_Eg=C3=AAa_Gondolfo?= Date: Tue, 28 Aug 2018 13:46:57 -0300 Message-ID: Subject: Re: angel(2) system call, the quest for immortality, aka kill(2) with SIGSTOP/SIGKILL will *not* work To: Warm White Wolf Cc: asomers@freebsd.org, freebsd-hackers@freebsd.org X-Mailman-Approved-At: Tue, 28 Aug 2018 18:28:04 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 16:47:11 -0000 Interesting, next time someone inject a bitcoin miner in a jail running an untrusted php system you'll need a reboot to stop it... On Tue, 28 Aug 2018, 13:38 Warm White Wolf, wrote: > Seriously : suppose your well crafted, eventually audited program, is more > important than > your whole informatic system, perhaps the raison d'etre of your business. > You want to live, > more than the 1% errors of your sysadmins. > > Ludic : you have an account in the Unix machines at your university. You > wrote your small > HTTPD, and you want that your sysadmins won't kill your power-httpd. > > fork(void) was pretty extremy at it's time... > > As a power Unix-user, a config option for the kernel, at compile-time, can > be provided... > > > On Tue, Aug 28, 2018 at 5:46 PM Alan Somers wrote: > > > On Tue, Aug 28, 2018 at 2:59 AM Warm White Wolf > > > wrote: > > > >> Greetings ! > >> > >> I have developed a new system call, be it named angel(2), > >> on Linux operating system (this is what I know), which makes > >> a program invulnerable to kill(2) calls, including SIGKILL and > >> SIGSTOP. > >> > >> The uses may involve fork() + angel(), daemon() + angel(), > >> setsid() + angel(), exec*() + angel(). > >> > >> Use the intellectual property I give you, as a gift to the BSD > >> operating system, using 4- 3- 2- BSD licence. That's it, name > >> me in the sources. > >> > >> Thank you, FreeBSD ! > >> You are a great Unix operating system ! > >> > > > > What are the applications? Blocking SIGKILL is pretty extreme. > > -Alan > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Tue Aug 28 17:33:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 623AA1092739 for ; Tue, 28 Aug 2018 17:33:03 +0000 (UTC) (envelope-from noses@noses.com) Received: from mailomat.net (mailomat.net [81.20.89.254]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailomat.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D73048E3B7 for ; Tue, 28 Aug 2018 17:33:02 +0000 (UTC) (envelope-from noses@noses.com) X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] X-Cloudmark-Analysis: v=2.1 cv=crWizTIi c=1 sm=1 tr=0 a=/nRDZZJyYxTE/j0HnTmKXw==:117 a=/nRDZZJyYxTE/j0HnTmKXw==:17 a=IkcTkHD0fZMA:10 a=dapMudl6Dx4A:10 a=pGLkceISAAAA:8 a=xv0ZfEE3q3l7p2QpulAA:9 a=QEXdDO2ut3YA:10 Received: from [194.39.192.125] (account bnc-mail@mailrelay.mailomat.net HELO bnc.net) by mailomat.net (CommuniGate Pro SMTP 6.2.0) with ESMTPSA id 95122161 for freebsd-hackers@freebsd.org; Tue, 28 Aug 2018 19:33:00 +0200 X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] X-BNC-Spam-Marker: [[X]] Received: from [192.168.200.134] (account ap@bnc.net HELO [192.168.200.134]) by bnc.net (CommuniGate Pro SMTP 6.2.4) with ESMTPSA id 8047846 for freebsd-hackers@freebsd.org; Tue, 28 Aug 2018 19:32:58 +0200 From: "Achim Patzner" To: freebsd-hackers@freebsd.org Subject: Re[2]: angel(2) system call, the quest for immortality, aka kill(2) with SIGSTOP/SIGKILL will *not* work Date: Tue, 28 Aug 2018 17:32:56 +0000 Message-Id: In-Reply-To: References: Reply-To: "Achim Patzner" User-Agent: eM_Client/7.1.33101.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 28 Aug 2018 19:26:19 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 17:33:03 -0000 On 28.08.2018 18:36:05, "Warm White Wolf" =20 wrote: >Ludic : you have an account in the Unix machines at your university.=20 >You >wrote your small HTTPD, and you want that your sysadmins won't kill=20 >your power-httpd. That's exactly their job. If I found soome user on one of my system=20 running software I cannot stop if I need to the next thing that would be=20 gone after the reboot was their account... Achim From owner-freebsd-hackers@freebsd.org Wed Aug 29 00:32:21 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CD85109C033 for ; Wed, 29 Aug 2018 00:32:21 +0000 (UTC) (envelope-from warmwhitewolf@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE0C9749EB for ; Wed, 29 Aug 2018 00:32:20 +0000 (UTC) (envelope-from warmwhitewolf@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id q8-v6so3703746wmq.4 for ; Tue, 28 Aug 2018 17:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/7gWpCezHuAg7Y9ej6ywW+0b2gUpEOwuxduJjd+mnNI=; b=dFMzT6ZdGz8GubOofMQYk5mUj8sk3TUwyQRy0XpseysSplgvGRJcEJDPncRvIPCVn/ bOYulw/c9FBl+r1++H8rQ6552FmaSC7ytf/0xXTm4M40otP51YzFwqmyylFvsXAXkjPH RKApTmkodx/mtiYAV86n6i+NHcVYCBHr2F1jP7SxzLFAJS1vOVz96t0M5IbUzIjclpBE gWglMD1soKGPUdNiE4CsL2F+pf00bn0b+Ocvl0k3y90qe26kwWQKOrUgCzTNtQvZUAiF e4R3RudpyxHwt5Vpg5h4Ck+j4KwhIGJvNKmqZsb3zQJNYqmeFQcg4YwqceDWnOiIwjHv CRxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/7gWpCezHuAg7Y9ej6ywW+0b2gUpEOwuxduJjd+mnNI=; b=iB9iSIUCc4KXsOPcUG7ufHh5Nlc7yV9J+Vx9b48dN/rV9TtdxPlHMQQt/UAvXL+NNa 5svxFTCX8ifTYsJ2jxb0Osx2p6DNq8jlIZykamp3Ns9RDz6WKcndxI4JXvQrHK1BAUca KXPRWVytQUuJE6yiI8D512yCNRvAE9sV/y50ynh5QQdmwfGvxeXqCHj86cueCsi4lz9L e1xdQKg3Cf9vSfr68sl4/t9Jb18XVp+USnGE2aSuPUYkqZCvqn7T0Dev2ey0InR4yes+ lK22tsXWq2RAqP9dZR7vb8/SX3FKJ1wEqzZhJk1+gvs3Fr2UVOUwTDuk974rJy6Oj101 xv3A== X-Gm-Message-State: APzg51CT/HBHokuxwIdpcuzcOgzDySHPf+1U3Od8Qbeznv9GNP+h9Sj5 SfMiAVA2V7KQWrF4cnm4HPbrmWJIBPECvwHvwRcoDwKN X-Google-Smtp-Source: ANB0VdZBMTyw66KN0Q/72TXJNVxhqr0dBkTzocOpiDRjTF6bqAF4d1fP5IrCdlUzOHGJqGqlBPBPbK5QTwkn8yJVDZk= X-Received: by 2002:a1c:7915:: with SMTP id l21-v6mr2919210wme.136.1535502739798; Tue, 28 Aug 2018 17:32:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warm White Wolf Date: Wed, 29 Aug 2018 03:30:27 +0300 Message-ID: Subject: Re: Re[2]: angel(2) system call, the quest for immortality, aka kill(2) with SIGSTOP/SIGKILL will *not* work To: noses@noses.com Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 00:32:21 -0000 I was thinking more in the style of Stevens' UNP servers and clients, that were configurable to run on every > 1024 / < 1024 port. Exempli gratia : 8888, 8080, etc. On Tue, Aug 28, 2018 at 10:28 PM Achim Patzner wrote: > On 28.08.2018 18:36:05, "Warm White Wolf" > wrote: > >Ludic : you have an account in the Unix machines at your university. > >You > >wrote your small HTTPD, and you want that your sysadmins won't kill > >your power-httpd. > > That's exactly their job. If I found soome user on one of my system > running software I cannot stop if I need to the next thing that would be > gone after the reboot was their account... > > > Achim > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Wed Aug 29 02:28:53 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2445E109E65D; Wed, 29 Aug 2018 02:28:53 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95C9D778DC; Wed, 29 Aug 2018 02:28:52 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: by mail-oi0-x241.google.com with SMTP id l202-v6so6498663oig.7; Tue, 28 Aug 2018 19:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lWmdyp8DhnDp22oaEuQ0u67p+c1T3HQRt6arR6PMxlg=; b=eQsWrGMA94Gww9M8JeJTNt4gAJ0r/Hyg154PTe+x9zVwytS94HMshb7wpmwspyQttK CWYlQkXMGsf+XLN9goOYfm8isbwpOJ+z/VTMINov6XFz1lKM5TluriocNB64IsQYgf3t uMiE3k25Fine9+Q4YIkc+Y5n5jjt92fqJ//LznBEWhy4q8eQP0TMb/rCoXpyLKYEd8o5 TOyEPR6rUqg+wkskIW42mkLG4eLl/plBRnqHe13B+7mBZJg2tle+/skkEFtoMknzlLtx FFaNUpYrQnx5HHqkp7GLqyj5kXkqbmu2Av2cHAXz0UutKUooq7a4hcIltDLDkrLCgWjP 12jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lWmdyp8DhnDp22oaEuQ0u67p+c1T3HQRt6arR6PMxlg=; b=gTAWuYivSB3lHw6TTqwchh0YMfqO4Ec7gzgNU+n9jD299M2do2+07t8pQz8vUGEcSn RqyKgvX9QR7hciUWW5lBhZrdjFt4AaQwsJsAxfH1Bo0oQEuBBzSoBCW0tl3sRMt0zZ2b f/923Quo8Ex4QhwToCNjY43CchCQpaj4INPuqMx9dl31i6n96GuZw812Rp/xezyJoGTR XBMieuhtwX4OTkJcw3grql1FT4d2d/32n1ZpenUKKW4fkkrQJgRn+vAjjs388ILXXuzg 1vCgm052nJESoo+VDsR2hkMA+nOVW/MqJ3CTC5DoXw1TUKyJ3qNMc0ePv+XlzIAXXTV1 RaIg== X-Gm-Message-State: APzg51CvO2SV/frbn+fS0D3UXSBS8mRfQzod7xp3ImiYWa2cq4sTODml oLytol6Etjn2P576hvyS1RGg3BSUMa9O0giPtAQ= X-Google-Smtp-Source: ANB0VdZJK3iZOJd1qAcWuqS2ciqb88xgGuEIDGUYs2h2okSQcu3UIIEGHBGhDnZVtSRg/DGnLgxHysj/Nlo7gSuXepU= X-Received: by 2002:aca:4802:: with SMTP id v2-v6mr805832oia.259.1535509731816; Tue, 28 Aug 2018 19:28:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Meowthink Date: Wed, 29 Aug 2018 10:28:40 +0800 Message-ID: Subject: Re: Help diagnose my Ryzen build problem (in progress) To: "karu.pruun" Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 02:28:53 -0000 Update: machdep.idle = hlt and machdep.idle_mwait = 0 failed also. It can't last even longer than machdep.idle = mwait, which could normally panic after a few passes of building gcc. I tried hlt twice, both not longer than half hour. Now, as another round of building 4 gccs in parallel is going to finish, with machdep.idle = spin and machdep.idle_mwait = 0. Can I say Ryzen 2400G probably have issues with both mwait and hlt? Regards, meowthink Fatal trap 12: page fault while in user mode cpuid = 6; apic id = 06 fault virtual address = 0x819cd0000 fault code = user write data, reserved bits in PTE instruction pointer = 0x43:0x80195de26 stack pointer = 0x3b:0x7fffffffb0b8 frame pointer = 0x3b:0x7fffffffb100 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 3, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 17888 (ld) trap number = 12 panic: page fault cpuid = 6 KDB: stack backtrace: #0 0xffffffff80b414b7 at kdb_backtrace+0x67 #1 0xffffffff80afa9e7 at vpanic+0x177 #2 0xffffffff80afa863 at panic+0x43 #3 0xffffffff80f7c14f at trap_fatal+0x35f #4 0xffffffff80f7c1a9 at trap_pfault+0x49 #5 0xffffffff80f7ba10 at trap+0x360 #6 0xffffffff80f5bccc at calltrap+0x8 On Tue, Aug 28, 2018 at 11:47 PM Meowthink wrote: > > Hi Peeter, > > On 8/28/18, karu.pruun wrote: > > On Mon, Aug 27, 2018 at 6:07 PM Meowthink wrote: > > > >> >> Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my > >> >> Ryzen 5 2400G's model is 11h. > >> >> > >> >> On the microcode. It shall be updated through UEFI/BIOS updates. I > >> >> think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel > >> >> 0x810100b. > >> >> > >> >> Seems like ... the only thing I can do is sit down and wait? > >> > > >> > The revision > >> > > >> > https://svnweb.freebsd.org/base/head/sys/x86/x86/cpu_machdep.c?r1=336763&r2=336762&pathrev=336763 > >> > > >> > works around the mwait issue, i.e. it sets > >> > > >> > sysctl machdep.idle_mwait=0 > >> > sysctl machdep.idle=hlt > >> > > >> > >> I think that shall not apply to 2400G, which is model 11h not 1h. > >> Here're what I have now: > >> > >> machdep.idle: acpi > >> machdep.idle_available: spin, mwait, hlt, acpi > >> machdep.idle_apl31: 0 > >> machdep.idle_mwait: 1 > >> > >> > Now it may or may not relate to your problem, but it appears that > >> > Ryzen 2400G also has another issue with HLT, see the DragonFly bug > >> > report > >> > > >> > https://bugs.dragonflybsd.org/issues/3131 > >> > > >> > >> Thanks a lot for that info. > >> It's much easier to prove your problem, since it's reproducible. But > >> mine was so random to catch... > >> Anyway, it seems like the IRET issue [1] is still not fixed? I'm > >> highly doubt that my issue is this related because my system became > >> significantly more stable since I stop that irq storm from bluetooth > >> module - Though it still panics occasionally. > >> So could anybody tell, what's the difference between FreeBSD > >> workaround [2] and the DragonflyBSD one? > >> > >> > which AMD is aware of and is possibly working on, but it may not have > >> > appeared in the errata yet. The bug report says that until this is > >> > fixed, the workaround is to also disable HLT in cpu_idle. I am not > >> > sure what is the correct value for the sysctl on FreeBSD, perhaps > >> > > >> > sysctl machdep.idle=0 > >> > > >> > or some other value? > >> > >> In the meantime, I have this microcode > >> > >> # cpucontrol -m 0x8b /dev/cpuctl0 > >> MSR 0x8b: 0x00000000 0x0810100b > >> > >> Hence I should use mwait? > >> Still don't know what should I set. Any idea? > > > > > > If I was you, I'd play around with the sysctls mentioned above and see > > if it helps. Start with disabling both mwait and hlt, perhaps > > > > machdep.idle=spin > > machdep.idle_mwait=0 > > > > (assuming that 'spin' means hlt will not used) and then if that does > > not lead to a panic, try enabling mwait. I can't test 2400G since I > > don't have it any more. I booted FreeBSD a couple of times but did not > > run it over long periods of time. > > It works! > After hours and hours of different stressing. I got 8 copies of gcc > built without any problem. > > But it costs lots of power and the fan will become very annoying. As > so, I don't think I'll test long term stability with this state. > > machdep.idle: acpi -> spin > - will add ~5W, maybe some deeper C states disabled? > machdep.idle_mwait: 1 -> 0 > - will add another ~50W, CPUs are working insomniac. > > I tried to set machdep.idle_mwait to 1, or machdep.idle to mwait. Both > failed with panics when I start building gcc pass by pass. > > I'm pretty sure mwait will cause problem, as once I experienced a > panic immediately after I issued the sysctl command (the 2nd dump info > followed) > > So my next step will be hlt. Still need some time, though. > > > > > Cheers > > > > Peeter > > > > -- > > > > Cheers, > meowthink > > ------------------------------------------------------------------------ > machdep.idle=mwait > > panic: ffs_syncvnode: syncing truncated data. > cpuid = 7 > KDB: stack backtrace: > #0 0xffffffff80b414b7 at kdb_backtrace+0x67 > #1 0xffffffff80afa9e7 at vpanic+0x177 > #2 0xffffffff80afa863 at panic+0x43 > #3 0xffffffff80dcddc4 at ffs_syncvnode+0x5a4 > #4 0xffffffff80dcc915 at ffs_fsync+0x25 > #5 0xffffffff810ffcb2 at VOP_FSYNC_APV+0x82 > #6 0xffffffff80bc3a62 at sched_sync+0x412 > #7 0xffffffff80abd813 at fork_exit+0x83 > #8 0xffffffff80f5cc7e at fork_trampoline+0xe > > ------------------------------------------------------------------------ > machdep.idle_mwait=1 > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 7; apic id = 07 > instruction pointer = 0x20:0xffffffff80e094fe > stack pointer = 0x0:0xfffffe081e5df9e0 > frame pointer = 0x0:0xfffffe081e5dfa50 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 17 (dom0) > trap number = 9 > panic: general protection fault > cpuid = 7 > KDB: stack backtrace: > #0 0xffffffff80b414b7 at kdb_backtrace+0x67 > #1 0xffffffff80afa9e7 at vpanic+0x177 > #2 0xffffffff80afa863 at panic+0x43 > #3 0xffffffff80f7c14f at trap_fatal+0x35f > #4 0xffffffff80f7b70e at trap+0x5e > #5 0xffffffff80f5bccc at calltrap+0x8 > #6 0xffffffff80e07a17 at vm_pageout+0x87 > #7 0xffffffff80abd813 at fork_exit+0x83 > #8 0xffffffff80f5cc7e at fork_trampoline+0xe From owner-freebsd-hackers@freebsd.org Wed Aug 29 08:11:36 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82FBD1080DE7; Wed, 29 Aug 2018 08:11:36 +0000 (UTC) (envelope-from karu.pruun@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F7E681B27; Wed, 29 Aug 2018 08:11:36 +0000 (UTC) (envelope-from karu.pruun@gmail.com) Received: by mail-oi0-x22e.google.com with SMTP id k12-v6so7622763oiw.8; Wed, 29 Aug 2018 01:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5nbQfoZPfL3RocRjqN2W0Hs9Tah2+3TNWtWblMla8QY=; b=MWioYp1b57fCfy4WVAUj9HgxG9Aptmah23PJ2EdZf8FO/npv+/s5KHtXQAj8PkVwvv 40iK/NiPYL16jpN47YsNgYQ19i4+Nv9VbGK9C8YSKrxVEo4NmZFFtcTWSNjG0v3naA7p KaadQnJMNV02pg8W7VY+c0G2xIDsbA0t5qW3b5C9K8PLjm+RGuO8nY6vxsZ28WwJfg/O yJVIUiIP0LFhX21d9vZ76sWlvWuRLiLYrqtAT81miX6M1DCXdIjJrJ1ZiRLqSLDYyIH8 Wq+EfCuxFcsDeoCHOpqx0eqpZrLEkMXEoL1Nbo/npGrMW0zttsngJqwcqt9dtGtpa0gL F+GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5nbQfoZPfL3RocRjqN2W0Hs9Tah2+3TNWtWblMla8QY=; b=AzJUOYbje3LhRv2ixB96xzUQLApbL2VjtgJfRuMwuavsBt4bqUkhAk/TQVnIG3YUAS jdpmH9oLPDKkPxmjHPBBhoFNQCRnt3hd9rVUqeCMaes3cgtZvGBEDf4bePjXmt+nWmru 9nOmLvjCZHpo/YOoC2TPqUjUmyXlY3HoyM7rU5jTN6EX4srQmLl3rEefFCbFZmO0CsDx mn9fqGuLHAxp3Zzqey+xOv0T+gQlz3rfmq8KJfL55DrDF/ComJ12ZklVdvVIz1VfH/XI aqw5AXOaL7UKneH7MKuh8ov9HXWnBClxEaUdVenYbVtd5oEzWgat3xEytHt4I8kI1v0t 4wBg== X-Gm-Message-State: APzg51BMckyEQexHtEhHPsCYM671ZJCstQLfZ2bKzrTWGe8G3H29n6hz 1zH3e17DHC8QtV5wHN0c/JAP8APcb2K7MOHCjCM= X-Google-Smtp-Source: ANB0VdaZPdnDT3zX8vf24tG1jU7z+epH8FJ4JNjAqcGQJAJ5/ht/EwHShVzrssFnoUminYpdmp5aucsXb93/oEK5XKI= X-Received: by 2002:aca:b1c1:: with SMTP id a184-v6mr1549838oif.182.1535530295134; Wed, 29 Aug 2018 01:11:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "karu.pruun" Date: Wed, 29 Aug 2018 11:11:24 +0300 Message-ID: Subject: Re: Help diagnose my Ryzen build problem (in progress) To: Si Miao Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 08:11:36 -0000 On Wed, Aug 29, 2018 at 5:28 AM Meowthink wrote: > > Update: > > machdep.idle = hlt and machdep.idle_mwait = 0 failed also. It can't > last even longer than machdep.idle = mwait, which could normally panic > after a few passes of building gcc. I tried hlt twice, both not longer > than half hour. > > Now, as another round of building 4 gccs in parallel is going to finish, with > machdep.idle = spin and machdep.idle_mwait = 0. > Can I say Ryzen 2400G probably have issues with both mwait and hlt? I suppose we can conclude that HLT is a culprit as it causes issues both on FreeBSD and DragonFly. On DragonFly it occurs in an isolated case where I had to run java. Otherwise the desktop would last for 3 - 4 weeks with no problems (and I only had to reboot since I built a new kernel). Also, when I finished running java, I switched on HLT again to get better power saving. But that said, yes, Ryzen 2400G has an issue with HLT in general. This has not been mentioned in the Revision guide for family 17h, and the latter does not explicitly include 2400G, which is model 11h as you said. https://support.amd.com/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf Regarding MWAIT, the DragonFly bug report says that the microcode update 0x0810100B fixes this. But I can't comment since I did not touch that at all. Cheers Peeter -- From owner-freebsd-hackers@freebsd.org Thu Aug 30 00:07:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5E74108A23E for ; Thu, 30 Aug 2018 00:07:24 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A9AA884FA for ; Thu, 30 Aug 2018 00:07:24 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.alameda.xse.com; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.alameda.xse.com (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w7U07M3D096439 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 29 Aug 2018 17:07:22 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.alameda.xse.com To: FreeBSD Hackers From: Craig Leres Subject: Is it possible to disable da0? Message-ID: <87cc687a-29f0-08d0-91a7-ff82c09f4938@freebsd.org> Date: Wed, 29 Aug 2018 17:07:22 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.1 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-2875-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 00:07:25 -0000 I have a couple of foxconn netboxes that have SD slots that the system configures as da0. Starting with FreeBSD 11 we see a wad of syslog messages from devd every few seconds: Aug 29 16:57:39 xxx.lbl.gov devd: Processing event '!system=CAM subsystem=periph type=error device=da0 serial="20090516388200000" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 3a 00" CDB="00 00 00 00 00 00 " ' Aug 29 16:57:39 xxx.lbl.gov devd: Pushing table Aug 29 16:57:39 xxx.lbl.gov devd: Processing notify event Aug 29 16:57:39 xxx.lbl.gov devd: Popping table This is apparently because the slot doesn't not contain media. We don't use SD cards with these systems so I tried adding: hint.da.0.disabled="1" to /boot/device.hints but /dev/da0 is still present after a reboot. Where am I going wrong? Craig % uname -a FreeBSD xxx.lbl.gov 11.2-RELEASE-p2 FreeBSD 11.2-RELEASE-p2 #2 r10: Wed Aug 15 09:23:29 PDT 2018 leres@steel.lbl.gov:/usr/src/sys/amd64/compile/LBLNET amd64 From owner-freebsd-hackers@freebsd.org Thu Aug 30 13:17:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7077D109E333 for ; Thu, 30 Aug 2018 13:17:58 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C523B7FCF8 for ; Thu, 30 Aug 2018 13:17:57 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w7UCoO1W026687 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Aug 2018 14:50:24 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w7UCoJN6026684 for ; Thu, 30 Aug 2018 14:50:19 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Thu, 30 Aug 2018 14:50:19 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: how to use ftp(1) in batch mode Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 13:17:58 -0000 i want to delete all say *.foo files on remote ftp server while it's clear how to download file using ftp(1) in batch mode, i cannot figure how to delete files in batch mode without any keyboard interaction. Could you help From owner-freebsd-hackers@freebsd.org Thu Aug 30 13:26:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 004D5109E658 for ; Thu, 30 Aug 2018 13:26:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D4E480198 for ; Thu, 30 Aug 2018 13:26:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7UDQaw5024899 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Aug 2018 15:26:36 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id w7UDQRoK018144; Thu, 30 Aug 2018 20:26:28 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: how to use ftp(1) in batch mode To: Wojciech Puchar , freebsd-hackers@freebsd.org References: From: Eugene Grosbein Message-ID: <5B87F083.6080804@grosbein.net> Date: Thu, 30 Aug 2018 20:26:27 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 13:26:44 -0000 On 30.08.2018 19:50, Wojciech Puchar wrote: > i want to delete all say *.foo files on remote ftp server > > while it's clear how to download file using ftp(1) in batch mode, i cannot > figure how to delete files in batch mode without any keyboard interaction. > > Could you help $ echo "machine localhost login ftp password user@" >> ~/.netrc $ printf "cd incoming\nprompt off\nmdel *.foo\nquit\n" | ftp localhost Connected to localhost. 220 host.xxx FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230- Your welcome message here. 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. 250 CWD command successful. Interactive mode off. 250 DELE command successful. 250 DELE command successful. 250 DELE command successful. 221 Goodbye. But, you better use ncftp3 port/package for such jobs. From owner-freebsd-hackers@freebsd.org Thu Aug 30 22:18:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3925EEFA4E4 for ; Thu, 30 Aug 2018 22:18:34 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA0CF74E22 for ; Thu, 30 Aug 2018 22:18:33 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qk1-x72b.google.com with SMTP id d131-v6so237625qke.11 for ; Thu, 30 Aug 2018 15:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XofbZbJlvLHGHbQKZJLd2Gc8EY3S4Cw6EAUYSexB1hY=; b=sXRTs+NKENiKypZ3lbiUsdD3v2SEdxa5g3x+qyftNmNrCnI1W/SrPgls6uj77/iT3p raiiPeQrT6gUjNjHFU3qQHuD/xA+0n2Wn783hxHPhOyk4LHy9KyPPO2syKJaR1jA/aD7 SwIqQ3TtTxjIiFKG0s/XMcDhuNK1TKsnt7CzlJWCXehKBR3O7VMqovMNqREa+IRKLwgC 7f3dpg9OtGNJKgin1QvfEUd1VgwTXRSZLs85dZeOYwsYovm56hfmIbPparhLeSWEAhOl 9yMFwJid8wxNCSpjLRmFIykzqf475UKzd7vBXBGiYfXamFWZ/cjVtwODGJc2NOuRlriR Gzgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XofbZbJlvLHGHbQKZJLd2Gc8EY3S4Cw6EAUYSexB1hY=; b=kKpJFUlVoxadVecq3QY8olbTbigeVeOVZje49mfnj/QbwXYr9i/WnTNQwOaSN5kmhE kNJPF6+RopYBk+nGaoeYNBE9vZcawo0yN9E7yo/6YNjzfn0zSoCVGOn4Wma28wmwhKQw kceLrgHDNm+WO79uXxyso4w9KuqiQw8RQ1VBv94Ku6Z5PZG7qs3pznZ866YTTospg4U8 oZ4lvVpQOLI3z84CWV03XdMRFcmung6R9flX+UdYKugSGohhEIEODlKbHlCrLGttLVy7 QgZkPeA3RvsluZI61nYcO0JEVb1CPFZGd6svfBb9Zkja/oRn1eBEjXxIIxiTqTJ9kPLr /wjg== X-Gm-Message-State: APzg51DEFwwTNUcG42YP4Q/MEJN26mWikBEsBBs/LTFFKPZVhQO0NdhV 3fdc8KjElKmmQlE4zNrb3fQwjJXK5PU= X-Google-Smtp-Source: ANB0VdZ3AnrH1ErVQ+Pev77rBAyyOFz8MrTicHQpIsERolGEkHujFERnXSNnrv9b9fuL0oADqEsTZg== X-Received: by 2002:a37:8b02:: with SMTP id n2-v6mr13261044qkd.157.1535667513231; Thu, 30 Aug 2018 15:18:33 -0700 (PDT) Received: from ?IPv6:2600:1017:b814:2174:a1d4:4a3e:7fbd:ae15? ([2600:1017:b814:2174:a1d4:4a3e:7fbd:ae15]) by smtp.gmail.com with ESMTPSA id n24-v6sm5285848qtf.0.2018.08.30.15.18.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 15:18:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Is it possible to disable da0? From: Mark Saad X-Mailer: iPhone Mail (15G77) In-Reply-To: <87cc687a-29f0-08d0-91a7-ff82c09f4938@freebsd.org> Date: Thu, 30 Aug 2018 18:18:30 -0400 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <818DD503-10CA-472F-A437-A1BB6A26CFBE@longcount.org> References: <87cc687a-29f0-08d0-91a7-ff82c09f4938@freebsd.org> To: Craig Leres X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 22:18:34 -0000 Craig If the kernel hint may not work due to no media . You can try three other o= ptions . Tweak devd to stop checking the device . It=E2=80=99s doable but I c= an=E2=80=99t recall the details . Set a hint to stop loading the device that= the mmc / sd card reader hangs off . Check pciconf to pin down its address .= There are examples how to do this in the dpdk docs , they show how to do th= is in the case of a nic . It should apply to all devices. Lastly most vendor= s support turning the device off in bios or Uefi . =20 --- Mark Saad | nonesuch@longcount.org > On Aug 29, 2018, at 8:07 PM, Craig Leres wrote: >=20 > I have a couple of foxconn netboxes that have SD slots that the system con= figures as da0. Starting with FreeBSD 11 we see a wad of syslog messages fro= m devd every few seconds: >=20 > Aug 29 16:57:39 xxx.lbl.gov devd: Processing event '!system=3DCAM subsy= stem=3Dperiph type=3Derror device=3Dda0 serial=3D"20090516388200000" cam_sta= tus=3D"0xcc" scsi_status=3D2 scsi_sense=3D"70 02 3a 00" CDB=3D"00 00 00 00 0= 0 00 " ' > Aug 29 16:57:39 xxx.lbl.gov devd: Pushing table > Aug 29 16:57:39 xxx.lbl.gov devd: Processing notify event > Aug 29 16:57:39 xxx.lbl.gov devd: Popping table >=20 > This is apparently because the slot doesn't not contain media. We don't us= e SD cards with these systems so I tried adding: >=20 > hint.da.0.disabled=3D"1" >=20 > to /boot/device.hints but /dev/da0 is still present after a reboot. Where a= m I going wrong? >=20 > Craig > % uname -a > FreeBSD xxx.lbl.gov 11.2-RELEASE-p2 FreeBSD 11.2-RELEASE-p2 #2 r10: Wed Au= g 15 09:23:29 PDT 2018 leres@steel.lbl.gov:/usr/src/sys/amd64/compile/LBLNET= amd64 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Fri Aug 31 00:58:45 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21CEBEFDA48 for ; Fri, 31 Aug 2018 00:58:45 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF8A87A2F6 for ; Fri, 31 Aug 2018 00:58:44 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2620:83:8000:102::cb; helo=hot.ee.lbl.gov; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from hot.ee.lbl.gov (hot.ee.lbl.gov [IPv6:2620:83:8000:102:0:0:0:cb]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w7V0wfMq094787 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 30 Aug 2018 17:58:42 -0700 (PDT) (envelope-from leres@freebsd.org) Subject: Re: Is it possible to disable da0? To: Mark Saad References: <87cc687a-29f0-08d0-91a7-ff82c09f4938@freebsd.org> <818DD503-10CA-472F-A437-A1BB6A26CFBE@longcount.org> Cc: FreeBSD Hackers From: Craig Leres Message-ID: Date: Thu, 30 Aug 2018 17:58:41 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <818DD503-10CA-472F-A437-A1BB6A26CFBE@longcount.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.1 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-2533-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 00:58:45 -0000 On 8/30/18 1:18 PM, Mark Saad wrote: > If the kernel hint may not work due to no media . You can try three other options . Tweak devd to stop checking the device . It’s doable but I can’t recall the details . Set a hint to stop loading the device that the mmc / sd card reader hangs off . Check pciconf to pin down its address . There are examples how to do this in the dpdk docs , they show how to do this in the case of a nic . It should apply to all devices. Lastly most vendors support turning the device off in bios or Uefi . Thanks; turns out adding -q to devd_flags solves this for me. I didn't try it before because a found an old post that said it *didn't* work. But it does. Craig From owner-freebsd-hackers@freebsd.org Fri Aug 31 13:53:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 848F8FCC168 for ; Fri, 31 Aug 2018 13:53:10 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DDC3732A7 for ; Fri, 31 Aug 2018 13:53:09 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w7VDqpBP007334 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 31 Aug 2018 15:52:51 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w7VDqjWS007325; Fri, 31 Aug 2018 15:52:46 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Fri, 31 Aug 2018 15:52:45 +0200 (CEST) From: Wojciech Puchar To: Eugene Grosbein cc: Wojciech Puchar , freebsd-hackers@freebsd.org Subject: Re: how to use ftp(1) in batch mode In-Reply-To: <5B87F083.6080804@grosbein.net> Message-ID: References: <5B87F083.6080804@grosbein.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 13:53:10 -0000 thank you. it works. actually even without netrc (echo command1;echo command2)|ftp ftp://user:password@server/ On Thu, 30 Aug 2018, Eugene Grosbein wrote: > On 30.08.2018 19:50, Wojciech Puchar wrote: >> i want to delete all say *.foo files on remote ftp server >> >> while it's clear how to download file using ftp(1) in batch mode, i cannot >> figure how to delete files in batch mode without any keyboard interaction. >> >> Could you help > > $ echo "machine localhost login ftp password user@" >> ~/.netrc > $ printf "cd incoming\nprompt off\nmdel *.foo\nquit\n" | ftp localhost > Connected to localhost. > 220 host.xxx FTP server (Version 6.00LS) ready. > 331 Guest login ok, send your email address as password. > 230- Your welcome message here. > 230 Guest login ok, access restrictions apply. > Remote system type is UNIX. > Using binary mode to transfer files. > 250 CWD command successful. > Interactive mode off. > 250 DELE command successful. > 250 DELE command successful. > 250 DELE command successful. > 221 Goodbye. > > But, you better use ncftp3 port/package for such jobs. > > From owner-freebsd-hackers@freebsd.org Fri Aug 31 14:01:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4C54FCC58A for ; Fri, 31 Aug 2018 14:01:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EA6573A3E for ; Fri, 31 Aug 2018 14:01:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7VE1ZTe035613 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Aug 2018 16:01:36 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7VE1SDV031493 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Aug 2018 21:01:28 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: how to use ftp(1) in batch mode To: Wojciech Puchar References: <5B87F083.6080804@grosbein.net> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> Date: Fri, 31 Aug 2018 21:01:24 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 14:01:44 -0000 31.08.2018 20:52, Wojciech Puchar write: > thank you. it works. actually even without netrc > > (echo command1;echo command2)|ftp ftp://user:password@server/ You better not develop a habit typing passwords in command line or URLs, this is quite insecure. From owner-freebsd-hackers@freebsd.org Fri Aug 31 17:55:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4955BFD3675 for ; Fri, 31 Aug 2018 17:55:23 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD33F7E1EC for ; Fri, 31 Aug 2018 17:55:22 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by mail-oi0-x22d.google.com with SMTP id t68-v6so23111625oie.12 for ; Fri, 31 Aug 2018 10:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gM4dnj7ABq1lpD5A+EEawk2540I2tAss+fK4+acPFig=; b=C5S1SLPCrFdUF3zuUwSLOEIpUzIrZ9XTjd86+izJKYEPoNeSEor5Zr2hAneFrEfDnM ZBEl532tQPLJPhKCk+GTtCNsNmIG+2q9lhlMGtNttTCIWbdfNAzS0fypACHsAxgFw0v7 MH2I0xKPK3w9DXiKgakSTJ3gMJ00UDT4FfmMk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gM4dnj7ABq1lpD5A+EEawk2540I2tAss+fK4+acPFig=; b=DUBkVlz6cebp2ufj9/wPJi3YCC7H/ediegjyI0y/91L1S2F7D6BSTCDFjuy0tZMt0P I3wSq4Nqi5BlIg+H7mf+CxRS7IMTsjTiSSHxHSnVqizdPAoUWKGpmQVb+rlgMkKdh7SN la8Ts5MChhsnVMFMBTxrz1rgAcyGoj+DouPKqXW9KmxhBdzBDzBqIZOyLAQ43SQ8BMFd fYXpT7+RYLR7g37dTt1tsuHxDLws8a4TJuDmuKWZgtCJL8ODTwWVFieqHfY4FgMGzLCZ rlx8Ss+wrkh0wRb6SChSPM/xGxa2RWiHNMj7Qfba2Vr32xENUuqszj3tv5e/7sKDX4yN WY/g== X-Gm-Message-State: APzg51AfMAD4CDLUJgGA63W4roSoI2xy7pE6ABNKOAe6E4agNTIlFpMz kRbZpaKDFg5mTKqCr39ifzeNv18B1Ym5RiJnevsfrSf/A3I= X-Google-Smtp-Source: ANB0VdatjGVN8B69P5tNWlZTeNqnrLkgRZIA19o4SfFElqimlI/6YEvoCcqLkEPX2U9qcm4kWb0sKHb/TI+yebg2Biw= X-Received: by 2002:aca:e155:: with SMTP id y82-v6mr8797961oig.90.1535738121328; Fri, 31 Aug 2018 10:55:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:1654:0:0:0:0:0 with HTTP; Fri, 31 Aug 2018 10:55:20 -0700 (PDT) In-Reply-To: <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> From: Mario Lobo Date: Fri, 31 Aug 2018 14:55:20 -0300 Message-ID: Subject: Re: how to use ftp(1) in batch mode To: freebsd-hackers@freebsd.org Cc: Wojciech Puchar Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 17:55:23 -0000 2018-08-31 11:01 GMT-03:00 Eugene Grosbein : > 31.08.2018 20:52, Wojciech Puchar write: > > > thank you. it works. actually even without netrc > > > > (echo command1;echo command2)|ftp ftp://user:password@server/ > > You better not develop a habit typing passwords in command line or URLs, > this is quite insecure. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > I believe that using sftp with authorized keys in batch mode is safer. The batch file would only need to have the actual commands. The only drawback for this method to be fully non-interactive is that you have to take out the passphrase from the private key. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] From owner-freebsd-hackers@freebsd.org Fri Aug 31 18:36:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00FE3FD454C for ; Fri, 31 Aug 2018 18:36:49 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C7947FD40 for ; Fri, 31 Aug 2018 18:36:47 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w7VIaXsm046199 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 31 Aug 2018 20:36:33 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w7VIaSlZ046196; Fri, 31 Aug 2018 20:36:28 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Fri, 31 Aug 2018 20:36:28 +0200 (CEST) From: Wojciech Puchar To: Mario Lobo cc: freebsd-hackers@freebsd.org, Wojciech Puchar Subject: Re: how to use ftp(1) in batch mode In-Reply-To: Message-ID: References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 18:36:49 -0000 > I believe that using sftp with authorized keys in batch mode is safer. The batch file would only need to have the actual commands. with ssh available on remote server i would simply use ssh. but i don't administer remote server > > The only drawback for this method to be fully non-interactive is that you have to take out the passphrase from the private key. > > -- > Mario Lobo > http://www.mallavoodoo.com.br > FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] > > From owner-freebsd-hackers@freebsd.org Fri Aug 31 18:38:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E99DFD45C3 for ; Fri, 31 Aug 2018 18:38:05 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 268AD7FE14 for ; Fri, 31 Aug 2018 18:38:05 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w7VIbrBV046395 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 31 Aug 2018 20:37:53 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w7VIbmpR046392; Fri, 31 Aug 2018 20:37:48 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Fri, 31 Aug 2018 20:37:48 +0200 (CEST) From: Wojciech Puchar To: Eugene Grosbein cc: Wojciech Puchar , freebsd-hackers@freebsd.org Subject: Re: how to use ftp(1) in batch mode In-Reply-To: <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> Message-ID: References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 18:38:05 -0000 >> thank you. it works. actually even without netrc >> >> (echo command1;echo command2)|ftp ftp://user:password@server/ > > You better not develop a habit typing passwords in command line or URLs, this is quite insecure. > > why it is less secure as long as it is my account with security.bsd.see_other_uids=0 set on server or even my own computer. From owner-freebsd-hackers@freebsd.org Fri Aug 31 18:46:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E173FD4C44 for ; Fri, 31 Aug 2018 18:46:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FEC9804F8 for ; Fri, 31 Aug 2018 18:46:38 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 2b192847-ad4e-11e8-a747-09a40681ccbf X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 2b192847-ad4e-11e8-a747-09a40681ccbf; Fri, 31 Aug 2018 18:46:29 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7VIkRJN020321; Fri, 31 Aug 2018 12:46:27 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535741187.33841.80.camel@freebsd.org> Subject: Re: how to use ftp(1) in batch mode From: Ian Lepore To: Wojciech Puchar , Eugene Grosbein Cc: freebsd-hackers@freebsd.org Date: Fri, 31 Aug 2018 12:46:27 -0600 In-Reply-To: References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 18:46:39 -0000 On Fri, 2018-08-31 at 20:37 +0200, Wojciech Puchar wrote: > > > > > > > > thank you. it works. actually even without netrc > > > > > > (echo command1;echo command2)|ftp ftp://user:password@server/ > > You better not develop a habit typing passwords in command line or > > URLs, this is quite insecure. > > > > > why it is less secure as long as it is my account with  > security.bsd.see_other_uids=0 set on server or even my own computer. > My advice: Just ignore them. A certain type of person simply cannot resist lecturing about security, even when they know absolutely nothing about your application or context. -- Ian From owner-freebsd-hackers@freebsd.org Fri Aug 31 18:46:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 780B1FD4C56 for ; Fri, 31 Aug 2018 18:46:49 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F261B8050D for ; Fri, 31 Aug 2018 18:46:48 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7VIkfdE037782 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Aug 2018 20:46:41 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7VIkaAR033916 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 1 Sep 2018 01:46:36 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: how to use ftp(1) in batch mode To: Wojciech Puchar References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <3e37fa38-4836-154a-4cf5-64d90ac5875e@grosbein.net> Date: Sat, 1 Sep 2018 01:46:31 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 18:46:49 -0000 01.09.2018 1:37, Wojciech Puchar wrote: >>> thank you. it works. actually even without netrc >>> (echo command1;echo command2)|ftp ftp://user:password@server/ >> You better not develop a habit typing passwords in command line or URLs, this is quite insecure. > why it is less secure as long as it is my account with security.bsd.see_other_uids=0 set on server or even my own computer. I'm talking not about ftp protocol or your installation here but about developing bad habits in general. From owner-freebsd-hackers@freebsd.org Fri Aug 31 19:13:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFF92FD5860 for ; Fri, 31 Aug 2018 19:13:24 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4914A8135F; Fri, 31 Aug 2018 19:13:24 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7VJDH5S038132 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Aug 2018 21:13:18 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ian@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7VJDE3P034501 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 1 Sep 2018 02:13:14 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: how to use ftp(1) in batch mode To: Ian Lepore , Wojciech Puchar References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> <1535741187.33841.80.camel@freebsd.org> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <099312d3-cda1-b8a6-b97d-b6e02d46e50e@grosbein.net> Date: Sat, 1 Sep 2018 02:13:09 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1535741187.33841.80.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 19:13:25 -0000 01.09.2018 1:46, Ian Lepore wrote: >> why it is less secure as long as it is my account with >> security.bsd.see_other_uids=0 set on server or even my own computer. >> > > My advice: Just ignore them. A certain type of person simply cannot > resist lecturing about security, even when they know absolutely nothing > about your application or context. That's not about a protocol, installation or context but about bad habits it general. Yes, I know ftp can be pretty secure if runs over IPSEC etc. and I sometimes do so. That does not make a habit to include a password into URLs a good habit. From owner-freebsd-hackers@freebsd.org Fri Aug 31 19:22:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F553FD5C8D for ; Fri, 31 Aug 2018 19:22:49 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A8868191D for ; Fri, 31 Aug 2018 19:22:49 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 38fa4a8a-ad53-11e8-9234-0d515945242e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 38fa4a8a-ad53-11e8-9234-0d515945242e; Fri, 31 Aug 2018 19:22:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7VJMcYh020399; Fri, 31 Aug 2018 13:22:38 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535743358.33841.81.camel@freebsd.org> Subject: Re: how to use ftp(1) in batch mode From: Ian Lepore To: Eugene Grosbein , Wojciech Puchar Cc: freebsd-hackers@freebsd.org Date: Fri, 31 Aug 2018 13:22:38 -0600 In-Reply-To: <099312d3-cda1-b8a6-b97d-b6e02d46e50e@grosbein.net> References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> <1535741187.33841.80.camel@freebsd.org> <099312d3-cda1-b8a6-b97d-b6e02d46e50e@grosbein.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 19:22:49 -0000 On Sat, 2018-09-01 at 02:13 +0700, Eugene Grosbein wrote: > 01.09.2018 1:46, Ian Lepore wrote: > > > > > > > > > why it is less secure as long as it is my account with  > > > security.bsd.see_other_uids=0 set on server or even my own > > > computer. > > > > > My advice: Just ignore them. A certain type of person simply cannot > > resist lecturing about security, even when they know absolutely > > nothing > > about your application or context. > That's not about a protocol, installation or context but about bad > habits it general. > Yes, I know ftp can be pretty secure if runs over IPSEC etc. and I > sometimes do so. > That does not make a habit to include a password into URLs a good > habit. > LOL, thank you for making my point most eloquently.  Y'all just REALLY can't resist lecturing, can you? -- Ian From owner-freebsd-hackers@freebsd.org Fri Aug 31 20:18:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CDA1FDB500 for ; Fri, 31 Aug 2018 20:18:57 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 11F3483833; Fri, 31 Aug 2018 20:18:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7VKIn3b038920 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Aug 2018 22:18:50 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ian@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7VKIjw5035232 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 1 Sep 2018 03:18:45 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: how to use ftp(1) in batch mode To: Ian Lepore , Wojciech Puchar References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> <1535741187.33841.80.camel@freebsd.org> <099312d3-cda1-b8a6-b97d-b6e02d46e50e@grosbein.net> <1535743358.33841.81.camel@freebsd.org> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <0f06f90d-957e-4f05-35d6-4bca868306b1@grosbein.net> Date: Sat, 1 Sep 2018 03:18:41 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1535743358.33841.81.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 20:18:57 -0000 01.09.2018 2:22, Ian Lepore wrote: >>> My advice: Just ignore them. A certain type of person simply cannot >>> resist lecturing about security, even when they know absolutely >>> nothing >>> about your application or context. >> That's not about a protocol, installation or context but about bad >> habits it general. >> Yes, I know ftp can be pretty secure if runs over IPSEC etc. and I >> sometimes do so. >> That does not make a habit to include a password into URLs a good >> habit. > > LOL, thank you for making my point most eloquently. Y'all just REALLY > can't resist lecturing, can you? You are saying "lecturing" like that's something wrong with free lecture :-) From owner-freebsd-hackers@freebsd.org Sat Sep 1 01:28:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C292FD421C for ; Sat, 1 Sep 2018 01:28:08 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C2B628F91E for ; Sat, 1 Sep 2018 01:28:07 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: by mailman.ysv.freebsd.org (Postfix) id 82511FD4218; Sat, 1 Sep 2018 01:28:07 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70F49FD4216 for ; Sat, 1 Sep 2018 01:28:07 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15EFC8F91D for ; Sat, 1 Sep 2018 01:28:06 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1fvuhn-0000RJ-SN for hackers@freebsd.org; Fri, 31 Aug 2018 18:28:04 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id w811S2N4001692 for hackers@freebsd.org; Fri, 31 Aug 2018 18:28:02 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Fri, 31 Aug 2018 18:28:02 -0700 From: Oleksandr Tymoshenko To: hackers@freebsd.org Subject: Bugzilla CLI tool Message-ID: <20180901012802.GA1537@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hello, I would like to announce the first release of scarab[1], a CLI tool for FreeBSD's Bugzilla system. The idea was to create a tool that reduces the number of steps for some workflows, e.g., downloading [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2018 01:28:08 -0000 Hello, I would like to announce the first release of scarab[1], a CLI tool for FreeBSD's Bugzilla system. The idea was to create a tool that reduces the number of steps for some workflows, e.g., downloading and copying submitted patches between the desktop system and the dev box. This release implements the bare minimum of the features to make it useful: attachments operations (list, fetch single, fetch all in PR, attach) and submitting new PRs. Users who submit the same type of bugs regularly can define a template (set of field/value pairs) and use a short-hand to provide all of them by a single command line switch. It's possible to combine templates or override certain fields from command line. More information and examples are available in a sample config file[2] [1] https://github.com/gonzoua/scarab [2] https://github.com/gonzoua/scarab/blob/master/examples/scarabrc -- gonzo From owner-freebsd-hackers@freebsd.org Sat Sep 1 11:24:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDA22FEC226 for ; Sat, 1 Sep 2018 11:24:49 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 737F9868F0 for ; Sat, 1 Sep 2018 11:24:49 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w81BOaMN045080 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 1 Sep 2018 13:24:36 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w81BOU3a045077; Sat, 1 Sep 2018 13:24:31 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Sat, 1 Sep 2018 13:24:30 +0200 (CEST) From: Wojciech Puchar To: Eugene Grosbein cc: Wojciech Puchar , freebsd-hackers@freebsd.org Subject: Re: how to use ftp(1) in batch mode In-Reply-To: <3e37fa38-4836-154a-4cf5-64d90ac5875e@grosbein.net> Message-ID: References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> <3e37fa38-4836-154a-4cf5-64d90ac5875e@grosbein.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2018 11:24:50 -0000 >>>> (echo command1;echo command2)|ftp ftp://user:password@server/ >>> You better not develop a habit typing passwords in command line or URLs, this is quite insecure. >> why it is less secure as long as it is my account with security.bsd.see_other_uids=0 set on server or even my own computer. > > I'm talking not about ftp protocol or your installation here > but about developing bad habits in general. > there are no "bad habits in general". Everything depends on situation. From owner-freebsd-hackers@freebsd.org Sat Sep 1 11:26:04 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C85CFEC2E9 for ; Sat, 1 Sep 2018 11:26:04 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A6195869CC; Sat, 1 Sep 2018 11:26:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w81BPpdc045229 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 1 Sep 2018 13:25:51 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w81BPkPn045226; Sat, 1 Sep 2018 13:25:46 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Sat, 1 Sep 2018 13:25:46 +0200 (CEST) From: Wojciech Puchar To: Ian Lepore cc: Wojciech Puchar , Eugene Grosbein , freebsd-hackers@freebsd.org Subject: Re: how to use ftp(1) in batch mode In-Reply-To: <1535741187.33841.80.camel@freebsd.org> Message-ID: References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> <1535741187.33841.80.camel@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2018 11:26:04 -0000 >> why it is less secure as long as it is my account with  >> security.bsd.see_other_uids=0 set on server or even my own computer. >> > > My advice: Just ignore them. A certain type of person simply cannot > resist lecturing about security, even when they know absolutely nothing > about your application or context. > Seems like. It's like linux fanatics that don't use rsh/rlogin (it's often not even available in their distros) "because it's insecure". I regularny use rsh, rcp and rlogin on my LAN and over my VPN's because it's fast and simple. From owner-freebsd-hackers@freebsd.org Sat Sep 1 11:26:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C5BFFEC342 for ; Sat, 1 Sep 2018 11:26:47 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 10EAC86A79; Sat, 1 Sep 2018 11:26:46 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w81BQZKn045309 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 1 Sep 2018 13:26:35 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w81BQULC045306; Sat, 1 Sep 2018 13:26:30 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Sat, 1 Sep 2018 13:26:30 +0200 (CEST) From: Wojciech Puchar To: Eugene Grosbein cc: Ian Lepore , Wojciech Puchar , freebsd-hackers@freebsd.org Subject: Re: how to use ftp(1) in batch mode In-Reply-To: <0f06f90d-957e-4f05-35d6-4bca868306b1@grosbein.net> Message-ID: References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> <1535741187.33841.80.camel@freebsd.org> <099312d3-cda1-b8a6-b97d-b6e02d46e50e@grosbein.net> <1535743358.33841.81.camel@freebsd.org> <0f06f90d-957e-4f05-35d6-4bca868306b1@grosbein.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2018 11:26:47 -0000 >>> That does not make a habit to include a password into URLs a good >>> habit. >> >> LOL, thank you for making my point most eloquently. Y'all just REALLY >> can't resist lecturing, can you? > > You are saying "lecturing" like that's something wrong with free lecture :-) > yes - if nobody ask for it. From owner-freebsd-hackers@freebsd.org Sat Sep 1 12:26:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD8BEFEE1B5 for ; Sat, 1 Sep 2018 12:26:19 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61D8489519 for ; Sat, 1 Sep 2018 12:26:19 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w81CQHEE016066; Sat, 1 Sep 2018 13:26:17 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w81CQDD8016065; Sat, 1 Sep 2018 13:26:13 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201809011226.w81CQDD8016065@donotpassgo.dyslexicfish.net> Date: Sat, 01 Sep 2018 13:26:12 +0100 Organization: Dyslexic Fish To: wojtek@puchar.net, eugen@grosbein.net Cc: wojtek@puchar.net, freebsd-hackers@freebsd.org Subject: Re: how to use ftp(1) in batch mode References: <5B87F083.6080804@grosbein.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sat, 01 Sep 2018 13:26:18 +0100 (BST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2018 12:26:19 -0000 Wojciech Puchar wrote: > thank you. it works. actually even without netrc > > (echo command1;echo command2)|ftp ftp://user:password@server/ If you need something slightly more robust, you may want to look at lang/expect, which uses send/expect sequences similar to kermit and uucp, but with more powerful options: man expect(1): | Expect is a program that "talks" to other interactive programs according to a | script. Following the script, Expect knows what can be expected from a program and | what the correct response should be. An interpreted language provides branching and | high-level control structures to direct the dialogue. In addition, the user can | take control and interact directly when desired, afterward returning control to the | script. cheers, Jamie From owner-freebsd-hackers@freebsd.org Sat Sep 1 14:45:30 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E375FF185B for ; Sat, 1 Sep 2018 14:45:30 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CB9CB8E91C for ; Sat, 1 Sep 2018 14:45:29 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w81EjLUJ049898 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 1 Sep 2018 16:45:22 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w81EjGDK044866 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 1 Sep 2018 21:45:16 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: how to use ftp(1) in batch mode To: Wojciech Puchar References: <5B87F083.6080804@grosbein.net> <99dde87e-1ddf-e1bc-a1a1-081718100f51@grosbein.net> <3e37fa38-4836-154a-4cf5-64d90ac5875e@grosbein.net> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: Date: Sat, 1 Sep 2018 21:45:12 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2018 14:45:30 -0000 01.09.2018 18:24, Wojciech Puchar wrote: >>>>> (echo command1;echo command2)|ftp ftp://user:password@server/ >>>> You better not develop a habit typing passwords in command line or URLs, this is quite insecure. >>> why it is less secure as long as it is my account with security.bsd.see_other_uids=0 set on server or even my own computer. >> >> I'm talking not about ftp protocol or your installation here >> but about developing bad habits in general. >> > there are no "bad habits in general". Everything depends on situation. There are bad habits in general and a password in an URL is just an example. From owner-freebsd-hackers@freebsd.org Sat Sep 1 17:02:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA2B8FF4EE5 for ; Sat, 1 Sep 2018 17:02:11 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A0A873923 for ; Sat, 1 Sep 2018 17:02:10 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w81H1WXm080334 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 1 Sep 2018 19:01:32 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w81H1RQU080331; Sat, 1 Sep 2018 19:01:27 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Sat, 1 Sep 2018 19:01:27 +0200 (CEST) From: Wojciech Puchar To: Jamie Landeg-Jones cc: wojtek@puchar.net, eugen@grosbein.net, freebsd-hackers@freebsd.org Subject: Re: how to use ftp(1) in batch mode In-Reply-To: <201809011226.w81CQDD8016065@donotpassgo.dyslexicfish.net> Message-ID: References: <5B87F083.6080804@grosbein.net> <201809011226.w81CQDD8016065@donotpassgo.dyslexicfish.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2018 17:02:12 -0000 >> thank you. it works. actually even without netrc >> >> (echo command1;echo command2)|ftp ftp://user:password@server/ > > If you need something slightly more robust, you may want to look > at lang/expect, which uses send/expect sequences similar to kermit > and uucp, but with more powerful options: yes i've used it few times. thanks > > man expect(1): > > | Expect is a program that "talks" to other interactive programs according to a > | script. Following the script, Expect knows what can be expected from a program and > | what the correct response should be. An interpreted language provides branching and > | high-level control structures to direct the dialogue. In addition, the user can > | take control and interact directly when desired, afterward returning control to the > | script. > > cheers, Jamie > >