From owner-freebsd-hackers@freebsd.org Mon Jun 3 20:38:32 2019 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 CF23415BD3E8 for ; Mon, 3 Jun 2019 20:38:32 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6C586E521 for ; Mon, 3 Jun 2019 20:38:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f181.google.com with SMTP id a21so2338448ljh.7 for ; Mon, 03 Jun 2019 13:38:31 -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:from:date:message-id:subject:to; bh=SZ5iHcRx8eSiu0yXadrcAE6iEd2lJUZJbU0Eeph6DJk=; b=NNLZ7gnhw+atNzqA/1xsegJe2PUhSGFdgGe4edQGfs+KYUvkxDYpEUZO0/npJAd78y lyrSECuQ2Vjp42/CLc+liRyqGHAuu45JAnACCDlkgYwdrcjegM0tzoWeNwiVJpSc9Uw0 bAW6PvubncEViZA16QS45pbxRyOXeI6+tsKZ6oV7JWNJGc1mRi/aZFeNzYTOmi8KAdmq 4vxWdIGMyXNV/MFBxf1ZS+jOafDt6oiWXac3nzflfTn5kmqn5FHWNNvG+mLIfvwgRvo+ RdBNW6sZt2KMNIsnSS2FWI0UJqJDGN/YjRv8rH8ATM1D43VJl3JUE54/6E593KZSZJpO iA6g== X-Gm-Message-State: APjAAAWx2QGZAKxTy0rMocQQ3TsR6gkcshTCHV8LVs51WfpkdOoawMUd BOkPdK/n4iulZMAmHuKeNy+GbLLIZjO393616ByXVg== X-Google-Smtp-Source: APXvYqyRJJesnEi5tij7gbrXuOtR6oyktNOLGnUSY0igbMypNjPYX4pElFSyFWF/V8YBKlrQfJQ7dwVaRLRbeFRrfAM= X-Received: by 2002:a2e:5d9c:: with SMTP id v28mr14718651lje.32.1559594302886; Mon, 03 Jun 2019 13:38:22 -0700 (PDT) MIME-Version: 1.0 From: Alan Somers Date: Mon, 3 Jun 2019 14:38:11 -0600 Message-ID: Subject: How to VOP_RECLAIM on demand? To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A6C586E521 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.181 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.91)[-0.911,0]; RCVD_IN_DNSWL_NONE(0.00)[181.208.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.25)[ip: (-0.52), ipnet: 209.85.128.0/17(-3.39), asn: 15169(-2.29), country: US(-0.06)]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 20:38:33 -0000 It would be useful if I could trigger VOP_RECLAIM on demand for a certain file or pathname. There are some edge cases in fusefs that I can't test otherwise. But I don't see any way to do it. Is such a thing possible? Would it be worth adding a special syscall for this purpose? It could be guarded with INVARIANTS so it wouldn't affect production builds. -Alan From owner-freebsd-hackers@freebsd.org Mon Jun 3 20:55:41 2019 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 DC71B15BDD13 for ; Mon, 3 Jun 2019 20:55:40 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 893266F5C8; Mon, 3 Jun 2019 20:55:39 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io1-f52.google.com with SMTP id n5so15519361ioc.7; Mon, 03 Jun 2019 13:55:39 -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:reply-to :from:date:message-id:subject:to:cc; bh=pZFvWHWHRKe4ZnU1uu46KDaQgId/fIcRJpYgZoQ0l+Y=; b=YrFYGidyQm9h9R/6S+gCFGVibGto5DH592Khho/fCn6XCCXdbtGkmDjDPS6x0QRyYC zazh/x69S4d7jNzmupA6pfGRnIMThlfdu1PFq5AyRh6j/U+hkcMoTMn9PZHPZocTwM7S J+FuuVfGTLz1Shj1hbi5Tbxwtt+LnomONwFsjgUuZ8nFT+CGOnGYxw4HSaphQ17Ow21y CRYjUTvQgaBKdPuX7kLHZVygsI7KQbeIbMvOYM2EqWDYgQF/n52t1+eTz3k6aycaHtMu Fbd4s4+ojdNY//VWz9qiwYZTdBDigcVhJaJpTdoSmmRlQyo0h88HbuedXc7GVoYTvrwx t7Uw== X-Gm-Message-State: APjAAAWeW3e0ydgz8z9ZiuAm8cZSbGvfYKdznOAq9G11WEu7fI6y1UAT wKpcunrbF3glTGLS06DlOVWlpvHc X-Google-Smtp-Source: APXvYqwagDo/JcXcqS8pwMrFAZV5sM8/89CCFUHob70wCZXFkQtRY58yCkmteK4FvlgHdOW06cRVmA== X-Received: by 2002:a6b:b593:: with SMTP id e141mr3970330iof.203.1559595338114; Mon, 03 Jun 2019 13:55:38 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id t133sm1717479iof.21.2019.06.03.13.55.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2019 13:55:37 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id k20so15494281ios.10; Mon, 03 Jun 2019 13:55:37 -0700 (PDT) X-Received: by 2002:a5d:88c6:: with SMTP id i6mr3767124iol.107.1559595337706; Mon, 03 Jun 2019 13:55:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Mon, 3 Jun 2019 13:55:27 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: How to VOP_RECLAIM on demand? To: Alan Somers Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 893266F5C8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.36 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.992,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.166.85.209.list.dnswl.org : 127.0.5.0]; SUBJECT_ENDS_QUESTION(1.00)[]; IP_SCORE(-2.35)[ip: (-6.04), ipnet: 209.85.128.0/17(-3.39), asn: 15169(-2.29), country: US(-0.06)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 20:55:41 -0000 It could be done with a sysctl, or even an ioctl on /dev/fuse (although, there is nothing FUSE-specific about the idea for a test utility). So I'd just add a sysctl for that functionality. Best, Conrad On Mon, Jun 3, 2019 at 1:39 PM Alan Somers wrote: > > It would be useful if I could trigger VOP_RECLAIM on demand for a > certain file or pathname. There are some edge cases in fusefs that I > can't test otherwise. But I don't see any way to do it. Is such a > thing possible? Would it be worth adding a special syscall for this > purpose? It could be guarded with INVARIANTS so it wouldn't affect > production builds. > -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 Mon Jun 3 21:15:41 2019 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 A429315BE441 for ; Mon, 3 Jun 2019 21:15:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0A867027B; Mon, 3 Jun 2019 21:15:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x53LFXRJ057765 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 4 Jun 2019 00:15:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x53LFXRJ057765 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x53LFXVq057762; Tue, 4 Jun 2019 00:15:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Jun 2019 00:15:33 +0300 From: Konstantin Belousov To: Alan Somers Cc: FreeBSD Hackers Subject: Re: How to VOP_RECLAIM on demand? Message-ID: <20190603211533.GS75280@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 21:15:41 -0000 On Mon, Jun 03, 2019 at 02:38:11PM -0600, Alan Somers wrote: > It would be useful if I could trigger VOP_RECLAIM on demand for a > certain file or pathname. There are some edge cases in fusefs that I > can't test otherwise. But I don't see any way to do it. Is such a > thing possible? Would it be worth adding a special syscall for this > purpose? It could be guarded with INVARIANTS so it wouldn't affect > production builds. Look at revoke(2) and VOP_REVOKE(). It is only implemented and used for devfs tty nodes. From owner-freebsd-hackers@freebsd.org Mon Jun 3 22:27:41 2019 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 214A515BFC15 for ; Mon, 3 Jun 2019 22:27:41 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 987DF725B5 for ; Mon, 3 Jun 2019 22:27:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f66.google.com with SMTP id b11so14858461lfa.5 for ; Mon, 03 Jun 2019 15:27:40 -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=XggKS49A9PzMPZlTBK+V8JGgLLkF9aJENCw5HGZlMAg=; b=gzgkdAU9rGel1CID2/Bof6V4Hj6pO3cKScIggptresDvC/eDMYbqgIc5/GdK9CUTUl NSxYqpYU60UOvPA/INGPoQ2mUl2QZ+mnxLDnmuUt4ODNGOclZP/xy194kUFSvrwmM/09 ic9IHX8i1w+xMQBXxTdu8K2nYPq93v4Vp8hZfPTH3U7e5Y8AHFwHHNez2lk9+b7l2oQd H3H5n1J93mMf+S/TUu5uDvQgfEaZrIPRr2IsnVrEqAo60E7rqsIN6BykAbr2pDsIL1vH DupIP8lDc8qbvBgqB5MbogoZ2euP2fiCoi6cmOv5Ctc62xWRruex+DQtL7BmHZQ3c4xX H21g== X-Gm-Message-State: APjAAAV14tRS2mphmt8CyxoMw2k0uIVDhXNsVdNFS96G4A9b3emUf733 xml1eedQl5+lHFD4M44APLe5vtnNExF0zjT+fRw= X-Google-Smtp-Source: APXvYqxyk11ExcFiSNqL4fGZNPtZ2ox62qKcptUnD1Euo602feiiqGnuFl9qdNlqanfiZE6ce3Pl+2St3SYZ5NDT/8A= X-Received: by 2002:ac2:4202:: with SMTP id y2mr8585375lfh.178.1559600857982; Mon, 03 Jun 2019 15:27:37 -0700 (PDT) MIME-Version: 1.0 References: <20190603211533.GS75280@kib.kiev.ua> In-Reply-To: <20190603211533.GS75280@kib.kiev.ua> From: Alan Somers Date: Mon, 3 Jun 2019 16:27:26 -0600 Message-ID: Subject: Re: How to VOP_RECLAIM on demand? To: Konstantin Belousov Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 987DF725B5 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.992,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 22:27:41 -0000 On Mon, Jun 3, 2019 at 3:15 PM Konstantin Belousov wrote: > > On Mon, Jun 03, 2019 at 02:38:11PM -0600, Alan Somers wrote: > > It would be useful if I could trigger VOP_RECLAIM on demand for a > > certain file or pathname. There are some edge cases in fusefs that I > > can't test otherwise. But I don't see any way to do it. Is such a > > thing possible? Would it be worth adding a special syscall for this > > purpose? It could be guarded with INVARIANTS so it wouldn't affect > > production builds. > > Look at revoke(2) and VOP_REVOKE(). It is only implemented and used > for devfs tty nodes. I don't understand how that would help. What does VOP_REVOKE have in common with VOP_RECLAIM? From owner-freebsd-hackers@freebsd.org Mon Jun 3 22:54:51 2019 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 EFEA915C0587 for ; Mon, 3 Jun 2019 22:54:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A003732C8; Mon, 3 Jun 2019 22:54:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x53Msgh4077888 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 4 Jun 2019 01:54:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x53Msgh4077888 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x53MsgBj077884; Tue, 4 Jun 2019 01:54:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Jun 2019 01:54:42 +0300 From: Konstantin Belousov To: Alan Somers Cc: FreeBSD Hackers Subject: Re: How to VOP_RECLAIM on demand? Message-ID: <20190603225442.GT75280@kib.kiev.ua> References: <20190603211533.GS75280@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 22:54:51 -0000 On Mon, Jun 03, 2019 at 04:27:26PM -0600, Alan Somers wrote: > On Mon, Jun 3, 2019 at 3:15 PM Konstantin Belousov wrote: > > > > On Mon, Jun 03, 2019 at 02:38:11PM -0600, Alan Somers wrote: > > > It would be useful if I could trigger VOP_RECLAIM on demand for a > > > certain file or pathname. There are some edge cases in fusefs that I > > > can't test otherwise. But I don't see any way to do it. Is such a > > > thing possible? Would it be worth adding a special syscall for this > > > purpose? It could be guarded with INVARIANTS so it wouldn't affect > > > production builds. > > > > Look at revoke(2) and VOP_REVOKE(). It is only implemented and used > > for devfs tty nodes. > > I don't understand how that would help. What does VOP_REVOKE have in > common with VOP_RECLAIM? Sane implementation of VOP_REVOKE for a filesystem that does not do tricks at files level (think devfs) is mostly {vgone(vp);}. From owner-freebsd-hackers@freebsd.org Tue Jun 4 07:04:52 2019 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 87F6815A4A98 for ; Tue, 4 Jun 2019 07:04:52 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from hermod.tmst.com.au (hermod.tmst.com.au [203.14.245.41]) by mx1.freebsd.org (Postfix) with SMTP id B9E178A6DB for ; Tue, 4 Jun 2019 07:04:47 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 20517 invoked by uid 907); 4 Jun 2019 07:04:43 -0000 Received: from p54B73A18.dip0.t-ipconnect.de (HELO [192.168.7.2]) (84.183.58.24) by hermod.tmst.com.au (qpsmtpd/0.96) with ESMTPSA (ECDHE-RSA-AES256-GCM-SHA384 encrypted); Tue, 04 Jun 2019 17:04:43 +1000 From: Jan Martin Mikkelsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: UEFI boot1 vs. GPT bootme/bootonce flags Message-Id: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com> Date: Tue, 4 Jun 2019 09:04:28 +0200 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: B9E178A6DB X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[transactionware.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.00)[country: AU(0.01)]; NEURAL_SPAM_SHORT(0.63)[0.628,0]; MX_GOOD(-0.01)[cached: a.mx.transactionware.com]; NEURAL_SPAM_LONG(0.63)[0.631,0]; NEURAL_SPAM_MEDIUM(0.55)[0.551,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 07:04:52 -0000 Hi, The UEFI boot1 loader does not support the GPT = bootme/bootonce/bootfailed flags for selecting which partition to boot. Is there a reason for this? Thanks, Jan M. From owner-freebsd-hackers@freebsd.org Tue Jun 4 09:04:46 2019 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 DB52B15A94F8 for ; Tue, 4 Jun 2019 09:04:45 +0000 (UTC) (envelope-from bsdunix99@gmail.com) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EC118E7AE for ; Tue, 4 Jun 2019 09:04:44 +0000 (UTC) (envelope-from bsdunix99@gmail.com) Received: by mail-it1-x136.google.com with SMTP id n189so12706015itd.0 for ; Tue, 04 Jun 2019 02:04:44 -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=8H2Fj9q4qKPQxC2Ni4uSSOPiibE/3PXY0rPBLeHJaH8=; b=IFlimg61+jEiPWWQMN1+FmqAgiGHWNq4ju3zie/JOWloriMT4KoJ4SVq8VZ5pSfnel CDkuGi5w1/Ui3Gyexr1OK6/WPJTnLhXUj8erkXoTF9QcPeS1u3Z7rq4rIcDf6FhnXEXx v5HaVMeJJcb7tnpAJ0zlggg5ibXj0DK2NaiPhWTZSQ2sd28k+tp0lzXXFW5aAy1BUItT INlyZl4lmau+ZJlEbxec3uRbRdv1NQ2PKuWAC6btKJGTwKD9hf9Fd5/zXP33IhtMKy/l dYKPIXR7zc/dDW99uLI6LJrzChqPGqYc8QXb8UB8V9ilUaIZl2xHN2IoPUFGT0bL3qTY ABDQ== 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=8H2Fj9q4qKPQxC2Ni4uSSOPiibE/3PXY0rPBLeHJaH8=; b=NYQgthKMWRaLQO3BWFd8lwhPehT/eYrUzRwuBiR8B1v1ve9djtCVi9eBJtMsYswVRQ DdUff7y3fmRHyK0u4HONkag/JbG3yIADQsR3f59/mC+2VsobFaLKDyj2Aem/p54hnOqo mf9sTuSuZxReBVCozwrXDQNubhHJYYwzd125I5DL1SQihwFBvpvTouy+WNr2gHta2Vdo 5RWYtLTA2TFqnE5M0BHB0J0aKfmUNEd9n8GRJloam+GJqNQioQGb83TLt738i9XxbOlZ fdYYqsovowIx3Mmq46MzpeIJgh3dQy91mZQuvW7aV6ZuCp5CGgbkaRp4AMAfcnQj42Nc adHg== X-Gm-Message-State: APjAAAV2vuSIg5HhPiKbTqxnDzlJucbIum0seasxrtW+2KuchIbYn8uD 5WXPSUEBrq5uKus5RLZvbOuFGzUoCfofY0CETHIHbQ== X-Google-Smtp-Source: APXvYqwNwYwNue+TpRhRdsq1aAvYwg/hpR4zsFwRW6kNzP83gZNwFGnGT3vLZojoCUmBK6Y4XI9TrcTPzuhNfHAXhYI= X-Received: by 2002:a24:5285:: with SMTP id d127mr5827375itb.72.1559639083501; Tue, 04 Jun 2019 02:04:43 -0700 (PDT) MIME-Version: 1.0 From: Alexandru Goia Date: Tue, 4 Jun 2019 12:04:31 +0300 Message-ID: Subject: sysctl To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 9EC118E7AE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=IFlimg61; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bsdunix99@gmail.com designates 2607:f8b0:4864:20::136 as permitted sender) smtp.mailfrom=bsdunix99@gmail.com X-Spamd-Result: default: False [-6.72 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[6.3.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; IP_SCORE(-2.77)[ip: (-8.28), ipnet: 2607:f8b0::/32(-3.24), asn: 15169(-2.29), country: US(-0.06)]; NEURAL_HAM_SHORT(-0.94)[-0.937,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 09:04:46 -0000 Greetings! Where can I find the full complete list of those about 5 hundred sysctl tunable variables of FreeBSD? Thank you! From owner-freebsd-hackers@freebsd.org Tue Jun 4 09:29:27 2019 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 D41BB15A9CFE for ; Tue, 4 Jun 2019 09:29:26 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFFAB8F1F4 for ; Tue, 4 Jun 2019 09:29:25 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: by mail-wm1-x32b.google.com with SMTP id 16so9645093wmg.5 for ; Tue, 04 Jun 2019 02:29:25 -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=38QY/IcRnrQmcDtZ0ci8Ig3mnXOYDPplruqovNTLscc=; b=LSKyhTj4J0tU+X/QCUiGems9TZ29VVDFea9uoNVJgH8TJV3DsSErEalc0CobUV3o5W gYA0qGpii6ExD3pWQ4w30m09iniRO83O8p31w2ngTtvIAWrLhDjcG0akkJiGEDzat7pH kEKmFy02RnZ7TrXajxoFM306OpwFeHbo1TV9EEEadLEJh0aGaBQIT57Lonf2hjuQCKEf JrT2amz05FV4WbX+Usk+We4eUqKnOcRY/A3Zso9I6raYyq2N7culH5+Ble2GqJnYOhxF uZcRGL4u4IqUiCrqAnOKhSd2Q6O2zn+cW7fMc2/Os0200AwToicuiO3oNlhjz4qHD8ZH HUmg== 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=38QY/IcRnrQmcDtZ0ci8Ig3mnXOYDPplruqovNTLscc=; b=Q41HKx4utjUAgmW9T50+VzxmhdSqPeAFyCRCuip0XuYpczEvJ1y1AMl3F/I5HInqhy /07bq1Mpjcy5gPJNXXWGAeG2YGSYo9t4f4egKm3dLSeQkJ1ZvuLd3J04NCCFNfgGepLt E3q894jC9SVZPDy1IfV+0CnxpfXZByGVAnJnLAcAPrf1ADoPv5C4+0qzpi9EEoknqj19 tujz5WmPUlEWrpTdjx4JNSNgkMVhfiyeVv/aURP0OJBFnmiQsdogXtvBZE6SAu8G1ImW LGKjxBLig4lwrkxTxO6c6SHcYXyXkWeOxOU25lGPj4gPhLoUGD73SCyWzbLbjhhJLY3N u6RA== X-Gm-Message-State: APjAAAXHUdSaDzAeH080CKqexn0hsplJ1gV2ZKLSrErai1AbJ9JOpk/D i0H4Sdl2kJ6YD/28CEAraomHWt2Cdxd7WMA7VDA= X-Google-Smtp-Source: APXvYqwiFyvUY+cvS79OEBEW/YUO6xS+PDZi00qcTKYXg2po/nA5if9OS4ZrTTPpmD+8W1SlxRSlJhfFLs1LlDdLUQc= X-Received: by 2002:a1c:1947:: with SMTP id 68mr17408888wmz.171.1559640564031; Tue, 04 Jun 2019 02:29:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Zhilin Date: Tue, 4 Jun 2019 12:29:11 +0300 Message-ID: Subject: Re: sysctl To: Alexandru Goia Cc: Freebsd hackers list X-Rspamd-Queue-Id: BFFAB8F1F4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=LSKyhTj4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mizhka@gmail.com designates 2a00:1450:4864:20::32b as permitted sender) smtp.mailfrom=mizhka@gmail.com X-Spamd-Result: default: False [-6.79 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[b.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.78)[ip: (-9.30), ipnet: 2a00:1450::/32(-2.25), asn: 15169(-2.29), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 09:29:27 -0000 Hi, What do you mean under "5 hundred"? On 13-CURRENT with few modules incl ZFS, "sysctl -NTa" shows around 8 hundred variables. Thanks! On Tue, Jun 4, 2019 at 12:07 PM Alexandru Goia wrote: > Greetings! > > Where can I find the full complete list of those about 5 hundred sysctl > tunable variables of FreeBSD? > > Thank you! > _______________________________________________ > 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 Jun 4 10:31:40 2019 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 C1B9615AB320 for ; Tue, 4 Jun 2019 10:31:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBFB4913F4 for ; Tue, 4 Jun 2019 10:31:39 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg1-x542.google.com with SMTP id a3so2710677pgb.3 for ; Tue, 04 Jun 2019 03:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6gircP5/8Gmnep280PL4VkIn+LWFEsTmYpoxE/7xIKk=; b=P/yy2xyfKI7Lu3qjWO1X6NtGuVIXwbzL6bX1sM1Egw36pERXw1AEnVhiierXA+Dzz1 8v+2bM/osBRqrYncAs/IGOgLDWkkTSfuHH92/5dLAp9CyFTKJi+btsJpaRp5isonbcjk yA7Xr/o6dDj7C+vLeD6To+Cp98H5K5YvI/0NUcvZE0YVIkAs3Hsq7fWHhGRoAEYnk2Vj UcmCzoVToP9PQneLv1TIgEhckZH1+6ywIovl1d2C70X1Kjy6WI6V+Q/e3iODa+r//5nl MmpaNwZOZAUy/AIzNfxJ9dSu2Jqa79k7Z1DjG63XDU0OdmxYaMPsKB9zHBc63/7CrtgY wifQ== 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=6gircP5/8Gmnep280PL4VkIn+LWFEsTmYpoxE/7xIKk=; b=GE8Oe8ldw/uLwrhEgwaJhPaLwk4yYVrZI0Uk8nxEoeHX5bUViwHgWFF/sva4Lx+AUQ PpCT4u2AhDmIcz08P9wglBGlSPRG/BOW/68ix0NVvvG3nJD0W1C4m2UJNzAnNuOIJ1Tp pTk5J2LEbtK5uib6YUXZ3Rxj9aAq046+b9KX1nveDqkXCDvK1/SKibtPCPIrmC1wz+TO kV+mC+zjK7FIVc9yuCdTgD+WIX40W9TCy4kayHDVKYY9idq6Hvf8hlWrtA+fOb77qmjb 0f6cPiGF2xNWybcCBE+vDFNEbqgOhrEB0R25Ew3iQ7HaHXOenFcm85RcJ8qDLWYMmm+U 99+g== X-Gm-Message-State: APjAAAUVCTIdYQmLJHeRJj0y+vSjlutyxlZs4DyVl1+gq8Wknaq3gG5v vEkZW+cq3yzgrT7XqJ5XwF6YdEHckq0= X-Google-Smtp-Source: APXvYqzdLV/AG1WEv24L0kfr6L7+AcQ1XeYUM/RDfkl8WrypsGu/j1EepPAHLE76mEPXj5n/+UaSgw== X-Received: by 2002:a62:b503:: with SMTP id y3mr35203577pfe.4.1559644298617; Tue, 04 Jun 2019 03:31:38 -0700 (PDT) Received: from [192.168.20.22] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id a3sm6954744pff.122.2019.06.04.03.31.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 03:31:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: sysctl From: Enji Cooper X-Mailer: iPhone Mail (16F156) In-Reply-To: Date: Tue, 4 Jun 2019 03:31:37 -0700 Cc: Alexandru Goia , Freebsd hackers list Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michael Zhilin X-Rspamd-Queue-Id: BBFB4913F4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=P/yy2xyf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::542 as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com X-Spamd-Result: default: False [-4.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.97)[-0.965,0]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.09)[ip: (0.13), ipnet: 2607:f8b0::/32(-3.24), asn: 15169(-2.29), country: US(-0.06)]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 10:31:41 -0000 > On Jun 4, 2019, at 02:29, Michael Zhilin wrote: >=20 > Hi, >=20 > What do you mean under "5 hundred"? > On 13-CURRENT with few modules incl ZFS, "sysctl -NTa" shows around 8 > hundred variables. As Michael noted, there are a variable number of sysctls, generally ranging i= n the hundreds or thousands, for controlling or querying system components/p= roperties. The user can optionally specify a description for a sysctl, which can be que= ries via =E2=80=9Csysctl -d=E2=80=9D (see =E2=80=9Cman 8 sysctl for more det= ails). There should also be a description of the sysctl in the implementing subsyst= em manpage, e.g., =E2=80=9Cman 4 inet=E2=80=9D briefly describes the IPv4 st= ack and some of its sysctl knobs. However, there are gaps, e.g., Linux compa= t hooks which convert sysfs entries to sysctls.=20 Good luck :). -Enji From owner-freebsd-hackers@freebsd.org Tue Jun 4 14:01:40 2019 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 98E6C15B1723 for ; Tue, 4 Jun 2019 14:01:39 +0000 (UTC) (envelope-from etnapierala@gmail.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 455DA69DD3 for ; Tue, 4 Jun 2019 14:01:38 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0016715B171E; Tue, 4 Jun 2019 14:01:38 +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 8D56915B171C; Tue, 4 Jun 2019 14:01:37 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FC6B69DCB; Tue, 4 Jun 2019 14:01:36 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm1-x32a.google.com with SMTP id 22so189962wmg.2; Tue, 04 Jun 2019 07:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=VnWuZdDsVYUYmBvyON+a9n5IcKTpqHPlN52WdVxhcd4=; b=R1c//OTGzSpvtDAw1h44pkrBWyX+PRB9MG0hxyjAhkdAi8b54iOS25SgVdlGBe3V8V Igs632FWL9enI/pAG4YHpuuGbta9jTECVTi3pz7PyRlkuE9hZ8cgpM+0YyIT+eCpEHeH hiCmC62Lnbo5dokQFbiw/qnBss3UXmHmh4QlKCEs+S1kDCiYDnTnuDfLTXvOh/Ik9k1/ guhAmqS/8zxdVs2vU4e6mb23i1A1aGtrZDkyiumXuIkG0U1DBHGMMfjYf3iH9U1keptS +Gr9eE69bdaFIuPpTutXqkCkWaNuSzixe0E9gkmdhDYMG0VTLUPHclKrT8mp1nGqjOX8 +5bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:mime-version:content-disposition:user-agent; bh=VnWuZdDsVYUYmBvyON+a9n5IcKTpqHPlN52WdVxhcd4=; b=am1N3zLczHKWCwBY1vFR+N+82FzS5XtQjplvjBnOfTcAzXWrr92te9tIKspUE0x5kv gQEhmEOAD3THbqPh2DBkaaIE4jeffiUcvM+bOKWu+/leU7a6/45Q/KoLJp27Ojj15rl6 GKDvikOYh3QkI+hFSazh6mcmfKiihKolCrXmGUVpJsrLb8QnPQJp9isC8eh5XnURjfWb w0WBqVYvaX0Lt+98INtQ5JwHl5JNbTu8lxgGgGBTYrOWu+RbYK46vAlXqnh6y0f65w5b Kq59pD1oU3eaLw1SVlGa6o/2aEZCmLnCjrskpwka0NvRIihFXfAYR7lfEX+OkLzW9m5p GRkw== X-Gm-Message-State: APjAAAV+SFc44cofxZRRNvSzDIFBZ7ZV4YhB4euF6D04OFFFFVKR4Uaw FYgLo4k5H71TmbzNER6iysqE+5gG X-Google-Smtp-Source: APXvYqyMsF+OEbZQVYC5hDhd4ydiGS38An+gd3zL6iCmIaB2CKG0OQp/xN/28mkmWbznpQxDd3EtvQ== X-Received: by 2002:a1c:407:: with SMTP id 7mr6853725wme.113.1559656892863; Tue, 04 Jun 2019 07:01:32 -0700 (PDT) Received: from v2 (c0600.int.cl.cam.ac.uk. [128.232.86.88]) by smtp.gmail.com with ESMTPSA id k10sm11225291wmk.14.2019.06.04.07.01.31 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 04 Jun 2019 07:01:31 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 4 Jun 2019 14:03:40 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: hackers@freebsd.org Cc: current@freebsd.org, stable@freebsd.org Subject: FreeBSD Quarterly Status Report - First Quarter 2019 Message-ID: <20190604130340.GA2359@v2> Mail-Followup-To: hackers@freebsd.org, current@freebsd.org, stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: 0FC6B69DCB X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=R1c//OTG; spf=pass (mx1.freebsd.org: domain of etnapierala@gmail.com designates 2a00:1450:4864:20::32a as permitted sender) smtp.mailfrom=etnapierala@gmail.com X-Spamd-Result: default: False [-7.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.95)[-0.952,0]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[trasz@freebsd.org,etnapierala@gmail.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[trasz@freebsd.org,etnapierala@gmail.com]; FORGED_RECIPIENTS(0.00)[hackers@freebsd.org ..,hackers@freebsd.org ...]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; IP_SCORE(-2.84)[ip: (-9.59), ipnet: 2a00:1450::/32(-2.26), asn: 15169(-2.29), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[a.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MID_RHS_NOT_FQDN(0.50)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 14:01:40 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - 1st Quarter 2019 As spring leads into summer, we reflect back on what the FreeBSD project has accomplished in the first quarter of 2019. Events included FOSDEM and AsiaBSDCon, the FreeBSD Journal is now free to everyone, ASLR is available in -CURRENT and KPTI can be controlled per-process. The run up to 11.3-RELEASE has begun, and a team is applying syzkaller guided fuzzing to the kernel, plus so much more. Catch up on many new and ongoing efforts throughout the project, and find where you can pitch in. __________________________________________________________________ FreeBSD Team Reports * Continuous Integration * FreeBSD Core Team * FreeBSD Foundation * FreeBSD Release Engineering Team * Ports Collection Projects * AXP803 PMIC driver update * Broadcom ARM64 SoC support * C Runtime changes * Capsicum * CFT - Package Base * ENA FreeBSD Driver Update * FreeBSD boot security improvements * FUSE * Kernel ZLIB Update * LLVM's lld as the FreeBSD system linker * mlx5 Drivers Update * PCI Express Resets * Security-Related changes Architectures * FreeBSD/RISC-V Update Ports * FreeBSD GNOME status report * FreeBSD KDE status report Third-Party Projects * FreeBSD Wiki Apple Intel Mac mini update * Fuzzing FreeBSD with syzkaller * sysctlmibinfo API 1.0 * sysctlview 1.0 * University of Waterloo Co-operative Education Students __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. Continuous Integration Links FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org/ FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins freebsd-testing Mailing List URL: https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing freebsd-ci Repository URL: https://github.com/freebsd/freebsd-ci Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI FreeBSD CI weekly report URL: https://hackfoldr.org/freebsd-ci-report/ Contact: Jenkins Admin Contact: Li-Wen Hsu The FreeBSD CI team maintains continuous integration system and related tasks for the FreeBSD project. The CI system regularly checks the changes committed to the project's Subversion repository can be successfully built, and performs various tests and analysis of the results. The results from build jobs are archived in an artifact server, for the further testing and debugging needs. The CI team members examine the failing builds and unstable tests, and work with the experts in that area to fix the code or adjust test infrastructure. Starting from this quarter, we started to publish CI weekly report at freebsd-testing@ mailing list. The archive is available at https://hackfoldr.org/freebsd-ci-report/ We also worked on extending test executing environment to improve the code coverage, temporarily disabling flakey test cases, and opening tickets to work with domain experts. The details are of these efforts are available in the weekly CI reports. We published the draft FCP for CI policy and are ready to accept comments. Please see freebsd-testing@ related tickets for more information. Work in progress: * Fixing the failing test cases and builds * Adding drm ports building test against -CURRENT * Implementing automatic tests on bare metal hardware * Implementing the embedded testbed * Planning for running ztest and network stack tests * Help more 3rd software get CI on FreeBSD through a hosted CI solution __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. Core initiated a Release Engineering Charter Modernization working group. The purpose of the working group is to present (to Core) a modernized version of the Release Engineering Charter and a first version of a new Release Engineering Team Operations Plan. The group hopes to complete its goals and dissolve by 2019-06-30. The Core Team invites all members of the FreeBSD community to complete the 2019 FreeBSD Community Survey. https://www.research.net/r/freebsd2019 The purpose of the survey is to collect quantitative data from the public in order to help guide the project's priorities and efforts. It will remain open for 17 days and close at midnight May 13 UTC (Monday 5pm PDT). (Editor's note: Survey has finished) Core voted to approve source commit bits for Johannes Lundberg (johalun@) and Mitchell Horne (mhorne@) and associate membership for Philip Jocks. Core also voted to revoke Michael Dexter's documentation bit. After a long lapse of not closing idle source commit bits, core has taken in the commit bit for these developers. We thank each for contributing to the project as a source committer. * Alfred Perlstein (alfred@) * Eric Badger (badger@) * Daniel Eischen (deischen@) * Ermal Lu=E7i (eri@) * Tony Finch (fanf@) * Justin T. Gibbs (gibbs@) * Imre Vad=E1sz (ivadasz@) * Julio Merino (jmmv@) * John W. De Boskey (jwd@) * Kai Wang (kaiw@) * Luigi Rizzo (luigi@) * Neel Natu (neel@) * Craig Rodrigues (rodrigc@) * Stanislav Sedov (stas@) * Thomas Quinot (thomas@) * Andrew Thompson (thompsa@) * Pyun YongHyeon (yongari@) * Zbigniew Bodek (zbb@) __________________________________________________________________ FreeBSD Foundation Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: We kicked off the year with an all-day board meeting in Berkeley, where FreeBSD began, to put together high-level plans for 2019. This included prioritizing technologies and features we should support, long-term planning for the next 2-5 years, and philosophical discussions on our purpose and goals. Partnerships and Commercial User Support We began the year by meeting with a few commercial users, to help them navigate working with the Project, and understanding how they are using FreeBSD. We're also in the process of setting up meetings for Q2 and throughout the rest of 2019. Because we're a 501(c)(3) non-profit, we don't directly support commercial users. However, these meetings allow us to focus on facilitating collaboration with the community. Fundraising Efforts Our work is 100% funded by your donations. We kicked off the year with many individual and corporate donations, including donations and commitments from NetApp, Netflix, Intel, Tarsnap, Beckhoff Automation, E-Card, VMware, and Stormshield. We are working hard to get more commercial users to give back to help us continue our work supporting FreeBSD. Please consider making a donation to help us continue and increase our support for FreeBSD at: www.FreeBSDfoundation.org/donate/. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information at https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies! OS Improvements The Foundation improves the FreeBSD operating system by employing our technical staff to maintain and improve critical kernel subsystems, add features and functionality, and fix problems. This also includes funding separate project grants like the arm64 port, porting the blacklistd access control daemon, and the integration of VIMAGE support, to make sure that FreeBSD remains a viable solution for research, education, computing, products and more. Over the quarter there were 241 commits from nine Foundation-sponsored staff members and grant recipients. We kicked off or continued the following projects last quarter: * FUSE file system kernel support (update and bug fixes) * Linuxulator testing and diagnostics improvements * SDIO and WiFi infrastructure improvements * x86-64 scalability and performance improvements * OpenZFS Online RAID-Z Expansion Having software developers on staff has allowed us to jump in and work directly on projects to improve FreeBSD like: * amd64 and i386 pmap improvements and bugfixes * address userland threading library issues * improve i386 support to keep the platform viable * improve FreeBSD on RISC-V * application of the Capsicum sandboxing framework * build system improvements and bug fixes * respond to reports of security issues * implement vulnerability mitigations * tool chain updates and improvements * adding kernel code coverage support for the Syzkaller coverage-guided system call fuzzer * improved Syzkaller support for FreeBSD * improve the usability of freebsd-update * improve network stack stability and address race conditions * ensure FreeBSD provides userland interfaces required by contemporary applications * implement support for machine-dependent optimized subroutines * update and correct documentation and manpages * DTrace bug fixes * update the FreeBSD Valgrind port and try to upstream the changes Continuous Integration and Quality Assurance The Foundation provides a full-time staff member who is working on improving our automated testing, continuous integration, and overall quality assurance efforts. During the first quarter of 2019, Foundation staff continued improving the project's CI infrastructure, working with contributors to fix failing build and test cases, and working with other teams in the project for their testing needs. In this quarter, we started publishing the CI weekly report on the freebsd-testing@ mailing list. See the FreeBSD CI section of this report for more information. Release Engineering The Foundation provides a full-time staff member to oversee the release engineering efforts. This has provided timely and reliable releases over the last five years. During the first quarter of 2019, the FreeBSD Release Engineering team continued providing weekly development snapshots for 13-CURRENT, 12-STABLE, and 11-STABLE. In addition, the Release Engineering team published the schedule for the upcoming 11.3-RELEASE cycle, the fourth release from the stable/11 branch, which builds on the stability and reliability of 11.2-RELEASE. The upcoming 11.3-RELEASE schedule can be found at: https://www.freebsd.org/releases/11.3R/schedule.html FreeBSD 11.3 is currently targeted for final release in early July 2019. Please see the FreeBSD Release Engineering Team section of this quarterly status report for additional details surrounding the above mentioned work. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. Check out some of the advocacy and education work we did last quarter: * Attended FOSDEM 2019 where we: staffed the FreeBSD Stand, sponsored the co-located FreeBSD Developer Summit, and gave the 25 Years of FreeBSD presentation in the BSD Dev room. * Sponsored and presented at SANOG33 in Thimphu, Bhutan * Represented FreeBSD at APRICOT 2019 in Yuseong-gu, Daejeon South Korea * Sponsored the USENIX FAST conference in Boston, MA as an Industry Partner * Ran our first ever FreeBSD track at SCALE 17x, which included an all-day Getting Started with FreeBSD workshop. We were thrilled with the turnout of almost 30 participants and received a lot of positive feedback. Thanks to Roller Angel who taught the class with the help of Deb Goodkin and Gordon Tetlow. We also promoted FreeBSD at the FreeBSD table in the Expo Hall. * Sponsored, presented, and exhibited at FOSSASIA in Singapore * Sponsored AsiaBSDCon 2019 * Committed to sponsoring Rootconf, BSDCan, and EuroBSDcon * Created registration systems for the Aberdeen Hackathon and the upcoming 2019 Vienna FreeBSD Security Hackathon * Provided FreeBSD advocacy material * Provided 3 travel grants to FreeBSD contributors to attend many of the above events. We continued producing FreeBSD advocacy material to help people promote FreeBSD around the world. Read more about our conference adventures in the conference recaps and trip reports in our monthly newsletters. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. We're excited to announce that with the release of the January/February 2019 issue, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at www.FreeBSDfoundation.org/news-and-events/. We also engaged with a new website developer to help us improve our website to make it easier for community members to find information more easily and to make the site more efficient. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to www.FreeBSDfoundation.org to find out how we support FreeBSD and how we can help you! __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 11.3-RELEASE schedule URL: https://www.freebsd.org/releases/11.3R/schedule.html FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. During the first quarter of 2019, the FreeBSD Release Engineering team published the initial schedule for the upcoming the 11.3-RELEASE. FreeBSD 11.3-RELEASE will be the fourth release from the stable/11 branch, building on the stability and reliability of 11.2-RELEASE. FreeBSD 11.3-RELEASE is currently targed for release in early July, 2019. Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches. Much of this work was sponsored by the FreeBSD Foundation. __________________________________________________________________ Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/index.html Ports Management Team URL: https://www.freebsd.org/portmgr/index.html Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team As always, below is a summary of what happened in the Ports Tree during the last quarter. During 2019q1, the number of ports dropped slightly to just over 32,500. At the end of the quarter, we had 2092 open port PRs. The last quarter saw 8205 commits from 167 committers. So more PRs were closed and more commits were made than in 2018q4. During the last quarter, we welcomed Kai Knoblich (kai@) and said goodbye to Matthew Rezny (rezny@). On the infrastructure side, two new USES were introduced (azurepy and sdl) and USES=3Dgecko was removed. The default versions of Lazarus and LLVM were bumped to 2.0.0 and 8.0 respectively. Some big port frameworks that were end-of-life were removed: PHP 5.6, Postgresql 9.3, Qt4, WebKit-Gtk and XPI. Firefox was updated to 66.0.2, Firefox-ESR to 60.6.1, and Chromium was updated to 72.0.3626.121. During the last quarter, antoine@ ran 30 exp-runs for package updates, moving from GNU ld to LLVM ld, and switching clang to DWARF4. __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. AXP803 PMIC driver update Contact: Ganbold Tsagaankhuu The AXP803 is a highly integrated PMIC that targets Li-battery (Li-ion or Li-polymer) applications. It provides flexible power management solution for processors such as the Allwinner A64 SoC. This SoC is used by Pinebook. The following updates were performed on the AXP803 driver: * Enabled necessary bits when activating interrupts. This allows reading some events from the interrupt status registers. These events are reported to devd via system "PMU" and subsystem "Battery", "AC" and "USB" such as plugged/unplugged, battery absent, charged and charging. * Added sensors support for AXP803/AXP813. Sensor values such as battery charging, charge state, voltage, charging current, discharging current, battery capacity can be obtained via sysctl. * Added sysctl for setting battery charging current. The charging current can be set using steps from 0 to 13. These steps correspond to 200mA to 2800mA, with a granularity of 200mA/step. __________________________________________________________________ Broadcom ARM64 SoC support Contact: Michal Stanek Contact: Marcin Wojtas The Semihalf team continued working on FreeBSD support for the Broadcom BCM5871X SoC series BCM5871X are quad-core 64-bit ARMv8 Cortex-A57 communication processors targeted for networking applications such as 10G routers, gateways, control plane processing and NAS. Completed since the last update: * iProc PCIe root complex (internal and external buses) * OTP (One Time Programmable memory) driver In progress: * BNXT Ethernet support * Crypto engine acceleration for IPsec offloading. Todo: * Upstreaming of work. This work is expected to be submitted/merged to HEAD in the second half of 2019. This project was sponsored by Juniper Networks, Inc. __________________________________________________________________ C Runtime changes Contact: Konstantin Belousov Several changes where made to the C runtime which generally improves the environment provided to an application. Fix for libraries with initial exec TLS mode Some libraries, most prominent of which is NVidia-provided and thus binary-only libGL.so.1, use so called initial exec mode for TLS variables access. This is the fastest mode of TLS access, but its drawback is that it only reliably work when the main binary is linked against the library, i.e. dlopen-ing the library to load it at runtime is not guaranteed to work. This mode works by placing the TLS variables for objects in one area allocated during the executable initialization, which somewhat explains the name of the mode. An obvious consequence is that if such library is loaded later, there is no space in the TLS area for an application to put its TLS variables. The FreeBSD dynamic linker is aware of misbehaviour of the app builders, and provides some amount of slack in the TLS area to give space for such libraries. But it appeared that the initial content of the TLS segment from libraries was not distributed among the threads' TLS areas, still breaking libraries which use initial exec mode for TLS. Another issue that somewhat mitigates mis-use of the mode is the DF_STATIC_TLS flag in the dynamic section. This flag allows the linker to check for the space earlier and avoid loading dependencies if there is no total required space. This linker flag was implemented by the BFD ld linker, but not by the LLVM lld linker. The FreeBSD dynamic linker was fixed to properly distribute TLS initialization data to all threads' initial segments, which required reasonably extensive per-architecture changes to libc and libthr. Simultaneously, LLD was improved to mark libraries using initial exec TLS mode with the appropriate flag. These measures should make FreeBSD more resilent to improperly linked libraries. The most interesting fix is to users of the nvidia libgl library, because it cannot be fixed by relinking. Use rtld malloc in libthr The FreeBSD implementation of mutexes in libthr allocates some memory to keep the mutex data needed for mutex initialization. In contrast, the malloc implementation used by FreeBSD, jemalloc(3), requires working pthread mutexes for operation. This creates a chicken-and-egg problem during executable startup, and requires jemalloc to provide fragile hacks to make it possible to initialize mutexes. This has been a constant source of mismatches on imports of new versions of jemalloc. The FreeBSD rtld implementation already contained a very light-weight malloc implementation, suitable for limited use in pre-C-runtime environments. This seemed to be the ideal fit for an allocator for the pthread private mutexes memory. By using this allocator, a method to address the cyclic dependencies between jemalloc and libthr could finally be implemented. The entry points in the rtld malloc.c were renamed to avoid a clash with the libc exported symbols, and now the file is linked statically into libthr, providing an allocator for private mutexes and pthread key storage. The later was already switched to direct use of mmap(2) for similar reasons. Now less memory is wasted when key storage requires less than a page. Destructors order bug Alexander Kabaev (kan@) noted that C++ destructors for the static objects from the linked shared libraries are executed before C++ destructors of the static objects from the main binary. This was verified both for clang++ and g++, but amusingly not for __attribute__(((destructor))). The bug was introduced when init functions and init arrays for main binary startup are called from the rtld instead of csu (C startup code linked to the binary, typically from crt1.o). The cause is due to the somewhat complicated way of how destructors are called both by fini/fini arrays and rtld-registered atexit(3) handler. Solution is to register rtld atexit(3) handler before main binary init functions are called, using new internal ABI __libc_atexit() function. It is amusing that the bug was not noticed for so many years. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Capsicum Links Capsicum Wiki Page URL: https://wiki.FreeBSD.org/Capsicum Contact: Enji Cooper Contact: Mark Johnston Contact: Ed Maste Contact: Mariusz Zaborski Contact: Bora =D6zarslan Three themes for Capsicum work were: * Importing Google's Capsicum test suite into FreeBSD * Porting and sandboxing openrsync for FreeBSD * Applying capsicum to additional base system utilities The Googletest-based Capsicum test cases are now integrated into FreeBSD. After some discussion with David Drysdale - the main maintainer and developer for the Capsicum port on Linux - we decided that from now the FreeBSD will be upstream for Capsicum test cases. The next major step was sandboxing openrsync. In the course of that work we extended our fileargs service with two new functionalities. We modified the fileargs service to allow limiting the operations which can be performed, and can now delegate lstat to the Casper service. Furthermore, openrsync highly depends on the fts API. We spend some time in optimizing fts and making it sandbox friendly by introducing fts_openat function and removing the need to change the working directory to traverse the paths. The changes to the fts API are now in the tests phase. Moreover, we improved bootstrapping for non-FreeBSD machines. Thanks to this work we can now build tools needed to bootstrap FreeBSD which use Casper services. In the base system strings is now sandboxed as a result. We also sandboxed rtsol, rtsold, and savecore. We host biweekly Capsicum calls. The notes from the meetings are published in FreeBSD's Capsium meeting repository on GitHub. If you would like to join the call do not hesitate to send us an email. __________________________________________________________________ CFT - Package Base Links Package Base CFT - FAQ URL: https://trueos.github.io/pkgbase-docs/ Contact: Kris Moore The TrueOS project has been working on a Package Base implementation, and is pleased to issue its first CFT to the FreeBSD community. The TrueOS packaging work has been in development for close to 6 months, and differs from the original FreeBSD package base effort, in that it is an "out of tree" implementation. It allows any version of FreeBSD to be packaged, and only requires a patch to poudriere, as well as some minor ports enhancements, the first which is currently in review. For more information on the current status, please refer to the FAQ page. Additionally there will be a working-group at BSDCan 2019, and we encourage porters to attend and join the discussion. This project was sponsored by iXsystems Inc. __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/R= EADME Contact: Michal Krawczyk Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. ENAv2 has been under development for FreeBSD, similar to Linux and DPDK. Since the last update internal review and improvements of the patches were done, followed by validation on various AWS instances. To do: * Upstream of the ENAv2 patches Recently, AWS released the A1 instances which are arm64 instances. The FreeBSD kernel was fixed, so the ENA can be used on those instances with no issues. There were changes required in resource activation in the ENA driver r345371 and the addition of a missing bus release method to the nexus module for aarch64 r345373. With these changes, the ENA driver can run on A1 instances without any known issues. This project was sponsored by Amazon.com Inc. __________________________________________________________________ FreeBSD boot security improvements Links Veriexec manifest verification in kernel URL: https://svnweb.freebsd.org/changeset/base/345830 TPM as entropy source URL: https://svnweb.freebsd.org/changeset/base/345438 UEFI support in libsecureboot URL: https://svnweb.freebsd.org/changeset/base/344840 Contact: Michal Stanek Contact: Marcin Wojtas Contact: Kornel Duleba FreeBSD gained TPM 2.0 (Trusted Platform Module) support at the end of 2018. A kernel configuration option, TPM_HARVEST, was also added to use the TPM RNG as system entropy source. When used this way, the TPM can be harvested every ten seconds for entropy which is mixed into the OS entropy pool. The kernel option is currently disabled by default in amd64 GENERIC kernel configuration. UEFI Secure Boot support, developed by Semihalf, has been merged with sjg's Veriexec support, resulting in a unified library named libsecureboot. This library is used for verification of kernel and modules by the loader. The library uses BearSSL as the cryptographic backend. The library supports loading trusted and blacklisted certificates from UEFI (DB/DBx databases) and can use them as trust anchors for the verification. The library is also used by Veriexec to verify and parse the authentication database (called 'manifest') in the kernel. Previously the manifest was verified and parsed by a userspace application, then sent to the kernel via /dev/veriexec, which was a significant limitation and a security weakness. To do: * Backport to stable branches. Special thanks to sjg and Juniper for fruitful cooperation around Veriexec and the libsecureboot development. This project was sponsored by Stormshield. __________________________________________________________________ FUSE Contact: Alan Somers FUSE (File system in USErspace) allows a userspace program to implement a file system. It is widely used to support out-of-tree file systems like NTFS, as well as for exotic pseudo file systems like sshfs. FreeBSD's fuse driver was added as a GSoC project in 2012. Since that time, it has been largely neglected. The FUSE software is buggy and out-of-date. Our implementation is about 11 years behind. The FreeBSD Foundation has agreed to fund a project to improve the state of the FreeBSD FUSE driver. So far I've written a test suite for the fusefs(5) module, fixed 1 previously reported bug, discovered and fixed 6 new bugs, fixed all of fusefs's Coverity CIDs, made some minor performance enhancements and done some general cleanup. During the next quarter I plan to continue fixing bugs, and I'll also raise the driver's API level as high as I can before the quarter runs out. We're currently at 7.8; the highest defined level is 7.28. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Kernel ZLIB Update Links Review D19706 URL: https://reviews.freebsd.org/D19706 Contact: Yoshihiro Ota The FreeBSD system still uses an ancient (over 20 year-old) version of zlib (version 1.0.4). The FreeBSD kernel zlib implementation has special enhancements only used by netgraph. There is a separate version of code derived from unzip 5.12 used to inflate gzip files in the kernel which could be replaced with a more modern zlib. More detailed information is written in sys/modules/zlib/README in the review. In order to use the latest zlib, version 1.2.11, work has been done to revisit all existing zlib uses in the system. Most of the code works with the newer version of zlib as is. The unzip code will need some conversion work to use the newer zlib. A few callers will be made simplier by using some newer APIs available in the updated zlib. There are some zombie programs that have been broken and I would like to delete. This will clean up zombie programs and duplicated zlib code. This will also make future zlib version updates easier. These changes touch some very sensitive areas of the system, such as kernel loading, or are architecture specific like armv6/armv7, and also touch some legacy code like kgzip+kgzldr on i386. Testers and active users of these legacy zlib code are welcomed. * armv elf_trampoline Arm up to v5 can boot from gzipped kernel. This code is modified to use newer API for simplicity. Please verify gzipped kernel still boots with new code (Current code has fall back to legacy zlib in case of failure). Please also elaborate how to link such kernel, too. I'm still trying to figure that out. * netgraph compression/decompression Please help testing and/or teach how to test. Netgraph compiles in the FreeBSD zlib version inside. * gzipped a.out Does anyone use gzipped a.out executables, still? If so, does someone have an easy and safe program to run? Is a.out format i386 only? * zfs boot Can we boot from gzipped file system today? * CTF Checking how I can test. __________________________________________________________________ LLVM's lld as the FreeBSD system linker Links LLD on the FreeBSD Wiki URL: https://wiki.freebsd.org/LLD lld exp-run =20 URL: https://bugs.freebsd.org/214864 Contact: Ed Maste In FreeBSD-HEAD and 12.0 the default FreeBSD system linker (i.e., /usr/bin/ld) is LLVM's lld, on amd64, arm64, and armv7. For i386 in 12.0 lld is used as the bootstrap linker (i.e., to build the kernel and base system) but it is not enabled as the system linker because of multiple issues building FreeBSD ports with it enabled. The primary issue affecting i386 with lld is that many ports build position-dependent code (i.e., non-PIC) for use in shared libraries. This either comes from omitting the -fPIC compiler flag, or using hand-written position-dependent assembly. Compared with other CPU architectures i386 position-independent code is rather inefficient, which may be responsible for port authors making an explicit decision to avoid PIC. By default lld does not allow position-dependent code in shared objects (in particular, it does not permit relocations against read-only segments - typically containing the`.text` section). Over the last quarter many commits were made to the ports tree to fix the build when the system linker is lld - either building PIC code, or adding the -znotext linker flag to permit relocations against read-only segments, or just switching the port to link with GNU ld if it is incompatible with lld in some other way. At this point there are only a few dozen open bug reports for issues linking ports with lld as the system linker, and I expect FreeBSD 12.1 to use lld as the system linker on i386 as well. Tasks: * Fix freepascal/Lazarus ports with lld * Triage and address remaining port failures * Holistic review of lld workarounds in the ports tree, to identify changes that are no longer needed, should be addressed in lld, or should be sent upstream This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ mlx5 Drivers Update Links Mellanox OFED for FreeBSD Documentation URL: http://www.mellanox.com/page/products_dyn?product_family=3D193&mta= g=3Dfreebsd_driver Contact: Slava Shwartsman, Hans Petter Selasky, Konstantin Belousov The mlx5 driver provides support for PCI Express adapters based on ConnectX-4(LX), ConnectX-5(EX) and ConnectX-6(DX). The mlx5en driver provides support for Ethernet and the mlx5ib driver provides support for InfiniBand and RDMA over Converged Ethernet, RoCE. Following updates done in mlx5 drivers: * Added support for ConnectX-6 and ConnectX-6dx devices, which support of up to 200Gb/s interface speeds! * Added TLS hardware offload support for ConnectX-6dx devices. TLS Tx crypto offload is a new feature for network devices. It enables the kernel TLS socket to skip encryption and authentication operations on the transmit side of the data path, delegating those to the NIC. In turn, the network adapter encrypts packets that belong to an offloaded TLS socket on the fly. The Mellanox network adapter does not modify any packet headers. It expects to receive fully framed TCP packets with TLS records as payload. The NIC replaces plaintext with ciphertext and fills the authentication tag. The adapter does not hold any state beyond the context needed to encrypt the next expected packet, i.e. expected TCP sequence number and crypto state. * Add support for Dynamic Receive Queue Interrupt Moderation. Dynamic Interrupt Moderation (DIM) refers to any action made by hardware and/or software on run time to control interrupt rate on the system. The moderation action itself should not interfere with the system's operation and should not require any human interaction. In networking, dynamic interrupt moderation is used for controlling the rate of interrupts generated by the hardware for multiple traffic scenarios. * Enhanced support for self-healing mechanism: In a rare occasion when Mellanox network adapters fail, due to a firmware bug for example, the driver will sense the catastrophic error. As a result of this failure detection, the device driver can trigger a firmware reset for the device so it can recover - without the need to reboot the entire host. * Added support for in-driver firmware updating using mlx5tool. This project was sponsored by Mellanox Technologies. __________________________________________________________________ PCI Express Resets Contact: Konstantin Belousov Sometimes the need to reset a device attached to the system presents itself. Preferrably this device reset can be accomplished without causing the whole machine to reboot. It is easy to do with USB devices if the physical access is available -- you can just re-plug the device. For in-chassis devices, built-in, or on add-on cards, it is not possible to reset the device with physical action, unless the device is hot-plugged. Nonetheless, for typical modern PCIe devices, and most built-in PCI-emulation devices, the reset can be initiated using software actions. If device is a real plugged-in PCIe device, then reset can be initiated by disabling and then re-training PCIe-link by the upstream port controls. For most PCI devices, which support the PCI power management specification, the proven way to accomplish the reset is to put the device into state D3 (off) and then return to the previous power state. FreeBSD was missing a way to conveniently request user- or driver-initiated reset of devices. While it was possible to manually fiddle with registers using pciconf, this is impractical for users, and requires a lot of boilerplate code from drivers. A new BUS_RESET_CHILD() method was added to the newbus bus interface, and implementations added for PCIe bridges and PCI devices. The libdevctl(3) library call and devctl(8) command provide convenient userspace accessors for applications and administrators. During the reset, the device driver must stop its operations with the device. One way to achieve this is to detach drivers before reset, and re-attach after the device afterwards. This is mostly fine for network interfaces, but other devices require more coordination to handle properly. For example, an NVMe disk device being detached it means that all mounted volumes abruptly disapper from VFS view. Due to this, the BUS_RESET_CHILD() method allows the caller to select either detach/re-attach or suspend/resume driver actions around the reset. Mellanox uses the infrastructure to perform reset of the mlx(5) card after firmware reset without server reboot. It is believed that 'devctl reset' will be more widely useful. This project was sponsored by Mellanox Technologies. __________________________________________________________________ Security-Related changes Contact: Konstantin Belousov ASLR The ASLR (Address Space Layout Randomization) patch from review D5603 was committed into svn. While debate continues about the current and forward-looking value ASLR provides, having an implementation in the FreeBSD source tree makes it easily available to those who wish to use it. This also moves the conversation past the relative merits to more comprehensive security controls. KPTI per-process control The KPTI (Kernel Page Table Isolation) implementation was structured so that most selections of page isolation mode were local to the current address space. In other words, the global control variable pti was almost unused in the code paths, instead the user/kernel %cr3 values were directly loaded into registers or compared to see if the user page table was trimmed. Some missed bits of code were provided by Isilon, and then bugs were fixed and last places of direct use of pti were removed. Now when the system starts in the pti-enabled mode, proccontrol(1) can be used by root to selectively disable KPTI mode for children of a process. The motivation is that if you trust the program that you run, you can get the speed of non-pti syscalls back, but still run your normal user session in PTI mode. E.g., firefox would be properly isolated. Feature-control bits Every FreeBSD executable now contains a bit mask intended for enabling/disabling security-related features which makes sense for the binary. This mask is part of the executable segments loaded on image activation, and thus is part of any reasonable way to authenticate the binary content. For instance, the ASLR compatibility is de-facto the property of the image and not of the process executing the image. The first (zero) bit in the mask controls ASLR opt-out. Other OSes (e.g. Solaris) used an OS-specific dynamic flag, which has the same runtime properties but leaves less bits to consume in the feature-control mask. The feature-control mask is read both by kernel and by rtld during image activation. It is expected that more features will be added to FreeBSD and the mask can be used for enabling/disabling those features.. It is expected that a tool to manipulate the mask will be provided shortly, see review D19290. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. FreeBSD/RISC-V Update Contact: Ruslan Bukin Contact: Mitchell Horne Contact: Mark Johnston Work has continued on RISC-V port in the past quarter. Support for transparent superpage promotion was added to the RISC-V port, meaning that applications will now automatically use large page mappings when possible. Per-CPU pmap activation tracking was added, reducing the overhead of various pmap operations. This noticeably improves the responsiveness of FreeBSD when running in a multi-CPU virtual machine. A RISC-V implementation of minidumps was completed. Support for debugging RISC-V kernel dumps will land in devel/gdb after the next GDB release. It is now possible to compile the in-tree LLVM's RISC-V target by setting WITH_LLVM_TARGET_RISCV=3DYES in /etc/src.conf. The use of LLVM to compile the RISC-V port is currently experimental and further investigation is ongoing. Work is ongoing to bring up FreeBSD on SiFive's HiFive Unleashed development board now that one has been obtained by a FreeBSD developer. We also expect to work on support for a new version of the SBI specification. This project was sponsored by The FreeBSD Foundation, DARPA, AFRL. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. FreeBSD GNOME status report Links GNOME FreeBSD =20 URL: https://freebsd.org/gnome/ GNOME development Repo URL: https://github.com/freebsd/freebsd-ports-gnome Contact: Koop Mast Contact: Eric Turgeon Ports activity in this quarter were: * The x11-toolkits/gtk30 port updated to 3.24.5 and later to 3.24.7. * The www/webkit2-gtk3 port was updated to 2.24.0. * And the old insecure webkit-gtk2 and webkit-gtk3 where finally removed. Work in progress, the branches are available in the GNOME development repo, see the link above. * Eric Turgeon is working on MATE 1.22 in the mate-1.22 branch. And is almost complete. * Charlie Li (IRC: vishwin) is working on a long overdue update of the cinnamon desktop. This update is almost complete. The only real blocker is that the screensaver can't be unlocked after it activates. The work is in the cinnamon branch. * Koop Mast works on GNOME 3.32. The desktop is usable apart from gdm which is currently non-functional. Due to lack of free time the work is going slowly. This work is available in the gnome-3.32 branch. People who are willing to contribute can find us on #freebsd-gnome on freenode. __________________________________________________________________ FreeBSD KDE status report Links KDE FreeBSD URL: https://freebsd.kde.org/ Contact: Adriaan de Groot Contact: Tobias C. Berner The two biggest accomplishements this quarter were: * Qt4 and all its consumers have been removed from the ports tree. * www/qt5-webengine has been updated from the ancient 5.9.4 to 5.12.x by kai@ Further we have kept the KDE Frameworks, Plasma and Applications ports up to date with upstreams releases, which thanks to upstreams' FreeBSD-CI uses less and less patches. All the kde@ maintained ports (including cmake) have been kept up to date with their releases. The plans for the next quarter are in no particular order * Cleanup PyQt ports and pyqt.mk * Improve qt.mk components * Update sddm to 0.18.x * Implement user management functionality in system settings (write non-logind backend) People who are willing to contribute can find us on #kde-freebsd on freenode, and the kde@FreeBSD.org mailing list. Further we accept pull-requests and contributions on github.com/freebsd/freebsd-ports-kde. __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. FreeBSD Wiki Apple Intel Mac mini update Links FreeBSD Wiki URL: https://wiki.freebsd.org/IntelMacMini Contact: Trevor Roydhouse The FreeBSD Wiki page for the Apple Intel Mac minis has been comprehensively updated over the last quarter to drag it from 2009 into 2019. There are now detailed instructions for installing FreeBSD as the only operating system on models from 2007 through 2014 and itemised model specific information detailing FreeBSD support. If anyone is interested, help is needed to provide more specific information for the macmini 1,1 and 6,1 through 8,1 models and to test patches for the asmc(4) driver for temperature sensor feedback and for setting fan speed. If you would like to help and have access to these Mac minis, please contact me. Future tasks: * Create and test more patches for asmc(4) to cover all Intel Mac minis * Provide more information for 2006, 2012, 2014 and 2018 Mac minis * Instructions for dual boot (macOS/FreeBSD) installations __________________________________________________________________ Fuzzing FreeBSD with syzkaller Links syzkaller URL: https://github.com/google/syzkaller Contact: Mark Johnston Contact: Andrew Turner Contact: Michael Tuexen Contact: Ed Maste Syzkaller is a coverage-guided system call fuzzer. It was originally developed for Linux. It programmatically creates programs consisting of sequences of random system calls and executes them in a VM (virtual machine). Using feedback from a kernel code coverage facility called kcov, syskaller mutates the generated test programs in an attempt to expand the executed coverage of code paths within the kernel. Sometimes exercising a seldom or infrequently used code path will crash the kernel. When syzkaller manages to crash the running kernel in the VM, it attempts to generate a minimal test case which reproduces the crash, simplifying debugging. Syzkaller is very effective at finding kernel bugs and has uncovered hundreds of issues in Linux. Over the past couple of years, syzkaller's author, Dmitry Vyukov, has added support for other operating systems, including FreeBSD. Recently, a number of FreeBSD developers have been using syzkaller to find and fix bugs in the FreeBSD kernel. If interested, one can search the commit logs for "syzkaller" to find examples. Syzkaller can be run on a FreeBSD or Linux host to fuzz FreeBSD running in QEMU instances. It can also fuzz FreeBSD instances running on GCE (Google Compute Engine). Additionally, Google maintains a dedicated cluster of GCE hosts to continuously fuzz the latest builds of several different OS kernels. A FreeBSD target was recently added. Subscribe to the syzkaller-freebsd-bugs Google Group to receive notifications for newly discovered bugs. Work is ongoing to improve syzkaller's coverage of FreeBSD's system calls. In particular, syzkaller needs to be taught about all of the target kernel's entry points and argument types in order to be useful. Many of the standard POSIX system calls are already covered, but most FreeBSD-specific system calls are not. Similarly, many ioctl(2) definitions are missing. Some in-progress work aims to add support for bhyve as a VM backend for syzkaller, making it easier to fuzz FreeBSD VMs hosted on FreeBSD. Currently that can be done using QEMU, but QEMU on FreeBSD lacks support for hardware acceleration. See the PR for the implementation. Finally, a number of bugs identified by syzkaller have yet to be fixed. If you are interested in helping out with any of the above, please mail the contacts listed above. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ sysctlmibinfo API 1.0 Links gitlab.com/alfix/sysctlmibinfo URL: https://gitlab.com/alfix/sysctlmibinfo Contact: Alfonso Sabato Siciliano Port: devel/libsysctlmibinfo The sysctl() system call can get or set the value of a 'property' of the system. A 'property' has others info (description, type, label, etc.), they are necessary to build an utility like /sbin/sysctl, example: % sysctl -d kern.ostype kern.ostype: Operating system type % sysctl -t kern.ostype kern.ostype: string Primarily sysctlmibinfo wraps the undocumented kernel interface and provides an easy C API: sysctlmif_name(), sysctlmif_description(), sysctlmif_info(), sysctlmif_label(), sysctlmif_nextnode() and sysctlmif_nextleaf(), to retrieve the info of a 'property'. Moreover sysctlmibinfo provides a high level API: defines a struct sysctlmif_object and has some function: sysctlmif_filterlist(), sysctlmif_grouplist() and sysctlmif_tree(), to build lists and trees of objects. You can use this library to quickly build a custom sysctl utility. For example, the core of deskutils/sysctlview (a graphical explorer for the sysctl MIB Tree) is just a call to sysctlmif_tree() and a visit to the resulting tree to show its sysctlmif_object nodes. Note, actually a 'property' is an OID of the sysctl MIB, it is implemented by a struct sysctl_oid defined in sys/sysctl.h. __________________________________________________________________ sysctlview 1.0 Links gitlab.com/alfix/sysctlview URL: https://www.gitlab.com/alfix/sysctlview Contact: Alfonso Sabato Siciliano Port: deskutils/sysctlview The FreeBSD's kernel maintains a Management Information Base where the objects are properties to tuning the system using the sysctl() syscall and the /sbin/sysctl utility. The sysctlview utility is a "graphical sysctl MIB explorer", it depends on gtkmm (to build a GUI) and sysctlmibinfo (to retrieve the info from the kernel). The version 1.0 provides two "TreeView": * "Main" to show 'name', 'description', 'type', 'format' and 'value' * "Flags" to show 'name' and a column for each 'flag' defined in sys/sysctl.h The rows are "clickable" to display others info (e.g., 'label'). Currently sysctlview can show numeric and string values, the support for some opaque value will be added in the future. __________________________________________________________________ University of Waterloo Co-operative Education Students Contact: Ed Maste For the January-April 2019 term the FreeBSD Foundation has again brought on two co-operative education (co-op) students from the University of Waterloo. Gerald Aryeetey is a 2nd year Computer Engineering student. Gerald started looking at a FreeBSD tool chain issue - our static library archiver (ar) did not read or write archives in the 64-bit format. Gerald submitted a libarchive change to support 64-bit archives followed by change to FreeBSD's ar to add 64-bit support. Gerald later looked at a number of freebsd-update issues in FreeBSD's bugzilla database, and submitted many fixes. Around a dozen have been committed to FreeBSD, and more are in review. Gerald also worked on the FreeBSD Foundation's hardware continuous integration effort. The prototype installation is building FreeBSD on a commit-by-commit basis and testing on a BeagleBone Black and a Pine64 LTS. The prototype will be converted to a permanent, public installation in the near future, after which additional test devices will be added. For his final project Gerald intends to write a device driver for the Microchip LAN743x PCIe NIC. Bora =D6zarslan is a 3rd year student in Computing and Financial Management. Bora's initial focus was also on tool chain issues in FreeBSD, starting with improvements or bug fixes in FreeBSD's readelf (from the ELF Tool Chain project). Bora developed a tool to modify feature control bits in ELF binaries - for example, allowing binaries incompatible with ASLR to request to opt-out. As part of his readelf work Bora also added support to report the status of the feature control bits. Bora continued investigating security topics, looking at applying Capsicum sandboxing to Kristaps' BSD licensed rsync implementation, openrsync. This work required first implementing fileargs_lstat support in cap_fileargs (which as now been committed) as well as changes to the fts directory hierarchy routines (which have not yet been committed to FreeBSD). For the rest of the work term Bora will investigate and test unmodified Linux Docker containers on FreeBSD, to evaluate the state of Linuxulator support. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ --AhhlLboLdkugWU4S Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGmBAEBCgCQFiEEbvjBe1hu6u1NeinjJCKD+Vwk/7oFAlz2bCxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZF RjhDMTdCNTg2RUVBRUQ0RDdBMjlFMzI0MjI4M0Y5NUMyNEZGQkESHHRyYXN6QGZy ZWVic2Qub3JnAAoJECQig/lcJP+6vQEH/1PyJpCjUnDgEnJbQH1pbfE35cGSVznN ru6aT8XbSYR/qaAUs2aZ/hzaXTm7KqEfnid/UHr25gw4kQq1BBEqJcm7vzrTJmik w/M1ZhH4CbvWmYdz/avH4AJo91ayjPfl9tniAVAoMHVhcO/y2K/6pv4M/7LsY1bp dG7vU9VEe+QOrA/5NURf72E5RwYAn/E7jllqc8FUHuy/54iSMkbYw5bf5lYD2nQP v1VTWjdwp8kIbA23ci4vHyHE1HEggY7Ukrgnh1GprEwIVtKqhxwi5fcSFK+s0v13 FvI54ZSrQLAtQAxFVzXrPrEb4loHcBHtGU37WdbW4nCzC3I7ynZWVI4= =jsrm -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-hackers@freebsd.org Tue Jun 4 14:11:03 2019 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 9469615B1FC3 for ; Tue, 4 Jun 2019 14:11:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 378036AA07 for ; Tue, 4 Jun 2019 14:11:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x729.google.com with SMTP id c11so2887012qkk.8 for ; Tue, 04 Jun 2019 07:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HWd6mdlFVKQU02R192ktO+wr1ULPqtCMG4SCsAgLd0E=; b=ncX5swwWpzEM3h1553gcrSJkgWBfJ2PD6OEGl6LQfNj5qqTlW/4gpZdIR2FXEEVtlC halWdu8TCGgXHDNpdOk3G+XTyCIpL515zM8vaHrq6BCPgM+SzerRWR94LRr7gmPXGKSQ BHMUO+AV5iJ3idkdnEwGNYrBFaTNBJS/HUoyaMdnw0zLeItl4eempM9BxBYpWwihF7zR gjmgotfvcnaYhxaorJ4eeHmQ0JSF9wWt2sRvjNoaY3etX+foImvgyi3pz6b1q7Qc6wkV sDEtppAwEgM53OSSLRKUBjjq6SuPMpDVF+yXK3j3LqRDAUJsYtnFSozJPRNih0b1RGop 9iLw== 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=HWd6mdlFVKQU02R192ktO+wr1ULPqtCMG4SCsAgLd0E=; b=jNSeiZZK1YJEJ337LWxZ6b/AD8gyV1uLcNalOTb9nbMR5biSwcIUNwJrZUlq2e7lGm 7TL5+pcKVfnm+gjZdBaGMXZwP2GIcEg8UooSyAbK3BUdcldYYrXwmwKe2VYCPW+d2JVm fTAD03v+yl1kk9a7/G78uj8N9anqoUEB+1hhmdVoiyzqiedIQcVuwtJo7z0PphbnATwd GvGgY1JfbQbTZ8RIWsq9c1LVF87ruhQbifSwbAocg1mAQtO/78u9eIeExxItv3kKaCVj rCF80YoYc6NLYXJ0+rlEyFnOy+6SDr1Z2IzefS3TiAES2/n9hMr+ippBdd88o++MsrHG MTBw== X-Gm-Message-State: APjAAAVi2mddWb5/jBAn0vY789Kmu/+6qhXgmuKGKgP1IvU3O9gxFSE0 i/tKxO/TdiX5HRI3BttnhpHWklU/DRF1SB+mj7JcBQ4DIyQ= X-Google-Smtp-Source: APXvYqxv07tLw3RGS2hoYKSI9iByfm4IFkQTWvbMxENZX+8ic6pDb+rBvaf49mUCtQOV2Z3vXsjOOcHnxXxAfxYV2/w= X-Received: by 2002:a37:4b48:: with SMTP id y69mr27337561qka.77.1559657461040; Tue, 04 Jun 2019 07:11:01 -0700 (PDT) MIME-Version: 1.0 References: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com> In-Reply-To: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com> From: Warner Losh Date: Tue, 4 Jun 2019 08:10:49 -0600 Message-ID: Subject: Re: UEFI boot1 vs. GPT bootme/bootonce flags To: Jan Martin Mikkelsen Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 378036AA07 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=ncX5swwW X-Spamd-Result: default: False [-5.92 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.916,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[9.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[ALT1.aspmx.l.google.com,aspmx.l.google.com,ALT2.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-3.00)[ip: (-9.40), ipnet: 2607:f8b0::/32(-3.24), asn: 15169(-2.29), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 14:11:03 -0000 On Tue, Jun 4, 2019 at 1:06 AM Jan Martin Mikkelsen < janm@transactionware.com> wrote: > Hi, > > The UEFI boot1 loader does not support the GPT bootme/bootonce/bootfailed > flags for selecting which partition to boot. > > Is there a reason for this? > Yes. There's three. First, UEFI provides no way to get to these flags via their block interfaces. Second, the block interfaces are independent, so there was no easy way to know w/o jumping through a bunch of hoops. Third, the UEFI Boot Manager Protocol was championed as being the one-true way to select a boot partition. It's significantly more flexible and reliable than rewriting the partition table from time to time. However, there's significant drawbacks to the UEFI scheme. Vendors suck at not mucking up the UEFI Boot Manager Protocol (I'm looking at you SuperMicro). And the trend in embedded where UEFI has a foothold has been to move away from writable variables at all... Finally, the UEFI Boot Protocol assumes a host + media. There's no media-agnostic way to produce an image with multiple partitions that you ping-pong between (say a recovery USB stick that moves from system to system). So against my better judgement, I've been working on making gptboot.efi. It's not as terrible as I thought it would be, but it shows another issue: loader.efi and boot1.efi process all the partitions they find, but gptboot just does one disk's worth and stops when it successfully boots something: this has required a restructuring of the boot1 code that I started with to rearrange the loops used to find things. An no, the gptboot.efi will not support ZFS, which has its own way to do this outside of UEFI Boot Manager Protocol. If you don't want to wait, there's now a mechanism for loading loader environment variables from a file called \efi\freebsd\loader.env in the ESP that can accomplish much the same thing. Warner From owner-freebsd-hackers@freebsd.org Tue Jun 4 15:40:31 2019 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 DA5A015B4F84 for ; Tue, 4 Jun 2019 15:40:30 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from hermod.tmst.com.au (hermod.tmst.com.au [203.14.245.41]) by mx1.freebsd.org (Postfix) with SMTP id 434756EFEC for ; Tue, 4 Jun 2019 15:40:24 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 47390 invoked by uid 907); 4 Jun 2019 15:40:14 -0000 Received: from p54B73A18.dip0.t-ipconnect.de (HELO [192.168.7.2]) (84.183.58.24) by hermod.tmst.com.au (qpsmtpd/0.96) with ESMTPSA (ECDHE-RSA-AES256-GCM-SHA384 encrypted); Wed, 05 Jun 2019 01:40:14 +1000 From: Jan Martin Mikkelsen Message-Id: <74732E11-5735-46CB-AA54-2B49F30CB10A@transactionware.com> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: UEFI boot1 vs. GPT bootme/bootonce flags Date: Tue, 4 Jun 2019 17:40:06 +0200 In-Reply-To: Cc: "freebsd-hackers@freebsd.org" To: Warner Losh References: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com> X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: 434756EFEC X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.33 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_SPAM_SHORT(0.45)[0.450,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[transactionware.com]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[a.mx.transactionware.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.68)[0.680,0]; NEURAL_HAM_MEDIUM(-0.29)[-0.294,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[country: AU(0.01)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 15:40:31 -0000 > On 4 Jun 2019, at 16:10, Warner Losh wrote: >=20 >=20 > On Tue, Jun 4, 2019 at 1:06 AM Jan Martin Mikkelsen = > wrote: > Hi, >=20 > The UEFI boot1 loader does not support the GPT = bootme/bootonce/bootfailed flags for selecting which partition to boot. >=20 > Is there a reason for this? >=20 > Yes. There's three. >=20 > First, UEFI provides no way to get to these flags via their block = interfaces. Second, the block interfaces are independent, so there was = no easy way to know w/o jumping through a bunch of hoops. Third, the = UEFI Boot Manager Protocol was championed as being the one-true way to = select a boot partition. It's significantly more flexible and reliable = than rewriting the partition table from time to time. >=20 > However, there's significant drawbacks to the UEFI scheme. Vendors = suck at not mucking up the UEFI Boot Manager Protocol (I'm looking at = you SuperMicro). And the trend in embedded where UEFI has a foothold has = been to move away from writable variables at all... Finally, the UEFI = Boot Protocol assumes a host + media. There's no media-agnostic way to = produce an image with multiple partitions that you ping-pong between = (say a recovery USB stick that moves from system to system). >=20 > So against my better judgement, I've been working on making = gptboot.efi. It's not as terrible as I thought it would be, but it shows = another issue: loader.efi and boot1.efi process all the partitions they = find, but gptboot just does one disk's worth and stops when it = successfully boots something: this has required a restructuring of the = boot1 code that I started with to rearrange the loops used to find = things. An no, the gptboot.efi will not support ZFS, which has its own = way to do this outside of UEFI Boot Manager Protocol. >=20 > If you don't want to wait, there's now a mechanism for loading loader = environment variables from a file called \efi\freebsd\loader.env in the = ESP that can accomplish much the same thing. OK. I am looking at similar situations: Supermicro servers and various = flavours of embedded systems. For some of the newer embedded systems = UEFI is the necessary approach. I am not at all interested in writable = variables in firmware. I=E2=80=99m also not interested in booting from = ZFS. My question was because I have been reading the efi/boot1 source code = and deciding what to do to duplicate the bootme/bootonce functionality. = That there were lots of hoops to jump through was clear. However, I was = coming to the conclusion that boot1.efi needed to duplicate the = functionality of gptboot, and was getting ready to implement. How far have you gone with your gptboot.efi? What=E2=80=99s missing? Regards, Jan M. From owner-freebsd-hackers@freebsd.org Tue Jun 4 21:04:11 2019 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 9517215BD477 for ; Tue, 4 Jun 2019 21:04:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE3BE860BE for ; Tue, 4 Jun 2019 21:04:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x829.google.com with SMTP id u12so15586874qth.3 for ; Tue, 04 Jun 2019 14:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9CypafFYsBX2Rf6KAJweXDD2DW45CpZJKxHTkQ3Y69s=; b=0GF1zMPG0n0VVogt4UZCx61aR4RZ+SYgn07yXo/zpBz0kjE4912HbfQZ5FJhjKbacP X4EsM34uaufnY+M/gkZwaTjRJ5A863eev/DPmUL59oAd4ic2KCGnwcYo0B5p6JXbHk3h lyEi6unL1ZO2VauF6IKbSykRiq5qizc6DlObUMtwsrsWRCa1b9sjMo0XHkLW7RMddDAb 9cackCw4gOLSPx892uYHCWv8l8iHDGrY9uQceITgr4wr+xFQNcGj//q59eTPtIiVkBaP ZCFQVRu/b7uPwpDbmZRS4jSpsLCVfTzTiOi5zhPz7hPo47LrH5UxmZXGHzUvpKYbNZSC 0N2g== 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=9CypafFYsBX2Rf6KAJweXDD2DW45CpZJKxHTkQ3Y69s=; b=jEshWPq0WpVz1cidpmhE7RkFE+vNhTpzFsKEzrPCE/49hDtFimObtk5YXWdjJAQo7X y4SdDKVhR7dhEjbwSqHPN3Kj2s/udGQmf4Y1Tb9Ey9iMSDBQmgjOF95p0xtVvNnJOgbh YrlT/Yo96JHFnrTmj55S5Mb6eScmSh4wrfEV52IKQC4sOAmqqCk8QzLjbSoYm2lG/fGi M3+PKrZz/A+AFKbpTEAu6hAbIXWhIgQTx0HhOiws7YLGB+s3O5IQ92nlzD7KKChAAJDc jQCqaPswqGFXZXCuOkj4/AyO3nsfgYCrt5VfH61T/0BYGRllJidFectTTDw9a52/kX0n RW8g== X-Gm-Message-State: APjAAAWlZZrrTd299fkFhIpC9wZCf1JQgxw2f3bYJhV0lHqjiCvtRDae AgIARf0Rc7Ek4s5DPHZ5oAOyaFeVAihlbeUjUgGIIJebqG8= X-Google-Smtp-Source: APXvYqzCZsA8MYjY+3P0Hab9TWMmlK4Ilwl2V+n2k8yN4y9D90rid3FFmgflzzSnJfOurAtSE9I002Dyxp2h8bNAY9k= X-Received: by 2002:a0c:d604:: with SMTP id c4mr28690934qvj.27.1559682249750; Tue, 04 Jun 2019 14:04:09 -0700 (PDT) MIME-Version: 1.0 References: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com> <74732E11-5735-46CB-AA54-2B49F30CB10A@transactionware.com> In-Reply-To: <74732E11-5735-46CB-AA54-2B49F30CB10A@transactionware.com> From: Warner Losh Date: Tue, 4 Jun 2019 15:03:58 -0600 Message-ID: Subject: Re: UEFI boot1 vs. GPT bootme/bootonce flags To: Jan Martin Mikkelsen Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: AE3BE860BE X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=0GF1zMPG X-Spamd-Result: default: False [-5.98 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[9.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-3.01)[ip: (-9.44), ipnet: 2607:f8b0::/32(-3.24), asn: 15169(-2.30), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 21:04:11 -0000 On Tue, Jun 4, 2019 at 9:40 AM Jan Martin Mikkelsen < janm@transactionware.com> wrote: > > On 4 Jun 2019, at 16:10, Warner Losh wrote: > > > On Tue, Jun 4, 2019 at 1:06 AM Jan Martin Mikkelsen < > janm@transactionware.com> wrote: > >> Hi, >> >> The UEFI boot1 loader does not support the GPT bootme/bootonce/bootfaile= d >> flags for selecting which partition to boot. >> >> Is there a reason for this? >> > > Yes. There's three. > > First, UEFI provides no way to get to these flags via their block > interfaces. Second, the block interfaces are independent, so there was no > easy way to know w/o jumping through a bunch of hoops. Third, the UEFI > Boot Manager Protocol was championed as being the one-true way to select = a > boot partition. It's significantly more flexible and reliable than > rewriting the partition table from time to time. > > However, there's significant drawbacks to the UEFI scheme. Vendors suck a= t > not mucking up the UEFI Boot Manager Protocol (I'm looking at you > SuperMicro). And the trend in embedded where UEFI has a foothold has been > to move away from writable variables at all... Finally, the UEFI Boot > Protocol assumes a host + media. There's no media-agnostic way to produce > an image with multiple partitions that you ping-pong between (say a > recovery USB stick that moves from system to system). > > So against my better judgement, I've been working on making gptboot.efi. > It's not as terrible as I thought it would be, but it shows another issue= : > loader.efi and boot1.efi process all the partitions they find, but gptboo= t > just does one disk's worth and stops when it successfully boots something= : > this has required a restructuring of the boot1 code that I started with t= o > rearrange the loops used to find things. An no, the gptboot.efi will not > support ZFS, which has its own way to do this outside of UEFI Boot Manage= r > Protocol. > > If you don't want to wait, there's now a mechanism for loading loader > environment variables from a file called \efi\freebsd\loader.env in the E= SP > that can accomplish much the same thing. > > > OK. > > I am looking at similar situations: Supermicro servers and various > flavours of embedded systems. For some of the newer embedded systems UEFI > is the necessary approach. I am not at all interested in writable variabl= es > in firmware. I=E2=80=99m also not interested in booting from ZFS. > > My question was because I have been reading the efi/boot1 source code and > deciding what to do to duplicate the bootme/bootonce functionality. That > there were lots of hoops to jump through was clear. However, I was coming > to the conclusion that boot1.efi needed to duplicate the functionality of > gptboot, and was getting ready to implement. > > How far have you gone with your gptboot.efi? What=E2=80=99s missing > I have it mostly written at this point. Nailing down going back and forth between handles and different partition numbers. Warner From owner-freebsd-hackers@freebsd.org Wed Jun 5 06:04:02 2019 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 11DAD15C6770 for ; Wed, 5 Jun 2019 06:04:02 +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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 000DA6D78F for ; Wed, 5 Jun 2019 06:04:00 +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 x5563q0V090654 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 5 Jun 2019 08:03:52 +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 x5563qYl090633 for ; Wed, 5 Jun 2019 08:03:52 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Wed, 5 Jun 2019 08:03:52 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: linux-oracle-jdk18 and futex Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 000DA6D78F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-6.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[puchar.net]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; RCVD_IN_DNSWL_NONE(0.00)[90.144.1.194.list.dnswl.org : 127.0.10.0]; IP_SCORE(-3.51)[ip: (-9.28), ipnet: 194.1.144.0/24(-4.64), asn: 43476(-3.71), country: PL(0.06)]; DMARC_NA(0.00)[puchar.net]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 06:04:02 -0000 i installed linux-oracle-jdk18 all linux subsytems are active (linux,linux64,linprocfs,linsysfs), filesystems mounted when running tomcat7 using linux-oracle-jdk18 java process consumes 100% cpu showing "futex" state constantly. With openjdk that uses linux emulation problem doesn't exist. with any other version of oracje jdk that uses linux emulation - the same problem FreeBSD puchar.net 11.3-PRERELEASE FreeBSD 11.3-PRERELEASE #0 r347617: Sat May 18 19:54:54 CEST 2019 root@puchar.net:/h/backup1/src/sys/amd64/compile/puchar amd64 any idea what's wrong? From owner-freebsd-hackers@freebsd.org Wed Jun 5 09:54:17 2019 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 B028E15A7966 for ; Wed, 5 Jun 2019 09:54:17 +0000 (UTC) (envelope-from farhan@farhan.codes) Received: from mail.farhan.codes (mail.farhan.codes [155.138.165.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87B3974368 for ; Wed, 5 Jun 2019 09:54:16 +0000 (UTC) (envelope-from farhan@farhan.codes) Received: from pc.farhan.codes (pool-100-36-37-117.washdc.fios.verizon.net [100.36.37.117]) by mail.farhan.codes (Postfix) with ESMTPSA id B85FDE975 for ; Wed, 5 Jun 2019 05:54:13 -0400 (EDT) Date: Wed, 5 Jun 2019 05:54:12 -0400 From: Farhan Khan To: freebsd-hackers@freebsd.org Subject: Valgrind memcheck showing question marks Message-ID: <20190605095411.GA8120@pc.farhan.codes> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 87B3974368 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.89 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[farhan.codes:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MX_GOOD(-0.01)[cached: mail.farhan.codes]; DKIM_TRACE(0.00)[farhan.codes:+]; DMARC_POLICY_ALLOW(-0.50)[farhan.codes,reject]; NEURAL_HAM_SHORT(-0.77)[-0.770,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; IP_SCORE(-0.01)[asn: 20473(-0.01), country: US(-0.06)]; ASN(0.00)[asn:20473, ipnet:155.138.160.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[117.37.36.100.zen.spamhaus.org : 127.0.0.10] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 09:54:17 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I am having a Segmentation fault error and trying to use valgrind to help m= e find where the overflow occurs. I run valgrind on the prog.full version o= f the executable. I am running it as follows: $ valgrind --tool=3Dmemcheck ogit.full [arguments omitted] =3D=3D14457=3D=3D Memcheck, a memory error detector =3D=3D14457=3D=3D Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward = et al. =3D=3D14457=3D=3D Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyr= ight info =3D=3D14457=3D=3D Command: ogit.full clone http://git.farhan.codes/farhan/o= pengit =3D=3D14457=3D=3D=20 =3D=3D14457=3D=3D Conditional jump or move depends on uninitialised value(s) =3D=3D14457=3D=3D at 0x49D1867: ??? (in /lib/libc.so.7) =3D=3D14457=3D=3D by 0x7FF00051F: ??? =3D=3D14457=3D=3D by 0x20DE7D: ??? (in /usr/home/farhan/opengit/ogit.ful= l) =3D=3D14457=3D=3D by 0x20ECE1: ??? (in /usr/home/farhan/opengit/ogit.ful= l) =3D=3D14457=3D=3D by 0x2054B5: ??? (in /usr/home/farhan/opengit/ogit.ful= l) =3D=3D14457=3D=3D by 0x20511A: ??? (in /usr/home/farhan/opengit/ogit.ful= l) =3D=3D14457=3D=3D by 0x4826FFF: ??? =3D=3D14457=3D=3D=20 [snippet] Please note that the stack trace does not show the function names, which I = need. How do I enable those symbols? The Makefile is as follows: ------------------ MAN=3D CFLAGS=3D -Wall -lmd -lz -lfetch =20 PROG=3D ogit SRCS=3D ogit.c lib/ini.c lib/index.c lib/common.c lib/pack.c remote.c ini= t.c \ lib/zlib-handler.c lib/buffering.c lib/loose.c \ hash-object.c update-index.c cat-file.c log.c clone.c index-pack.c CLEANFILES+=3D ${PROG}.core =20 =2Einclude =20 ------------------ An example compilation line and the ending is as follows. The first line is= for "index-pack.c", but there are others as the SRCS line shows. ------------------ cc -Wall -lmd -lz -lfetch -g -MD -MF.depend.index-pack.o -MTindex-pack.= o -std=3Dgnu99 -fstack-protector-strong -Qunused-arguments -c index-pac= k.c -o index-pack.o cc -Wall -lmd -lz -lfetch -g -std=3Dgnu99 -fstack-protector-strong -Qunused= -arguments -o ogit.full ogit.o lib/ini.o lib/index.o lib/common.o lib/pac= k.o remote.o init.o lib/zlib-handler.o lib/buffering.o lib/loose.o hash-obj= ect.o update-index.o cat-file.o log.o clone.o index-pack.o =20 objcopy --only-keep-debug ogit.full ogit.debug objcopy --strip-debug --add-gnu-debuglink=3Dogit.debug ogit.full ogit ------------------ Am I missing a necessary compilation flag to have those symbols appear? I h= ave "-g" turned on during compilation. Thanks, --- Farhan Khan PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEG8zEBbZbSkdr8t3eZNYqKtDTorUFAlz3kUMACgkQZNYqKtDT orW/BAwAqMNEN/RO6fnErjKbb3PvwI9TB1xgi0zYgY2tKz01zY7KAqvqR/sA9ldn Yxa5Yaj8hRSvJBHsaUzkbu45JCHfbYmvCLmFb5VLy7Ho26TrePDQS+WXU2Hyd76M SDaEtQ7JR2zWSM9Zq7ZloXBB3Ak1eUUX+xU5Pe137mUi3AGVsqUTELbv4+a7ijV2 RV8PYfPEv+FdXV5OeKUW9rJ1eQ5p4zOAuZuloJvEozmmbuGap8AsmVFLgUpJLvKc yCEfbN3rFRTcPGnETDzldaQslGaW1QM2VFVWdv84j6duPZ6g09lxDvh1jcPaQf29 uLXhgVsPdyeUAHZuMqOo+7NdaUtANfz8IMvqkWchSQ91+N2/gC5AUPRyjH/m24mQ DUyYfy2ndM0Z84NPS8XEg2c5faqH6TCiAKtqKnE5cVOmktHOtxji23aF5hJKtWDW k7f/KNi98O0cPNeXjKMaqs6q1aR7uoCEhGRta7R6g9kZhbUilamDaiEr4zQhrVIC jjGY0Dve =sa2f -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-hackers@freebsd.org Wed Jun 5 11:41:25 2019 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 610AA15AA190 for ; Wed, 5 Jun 2019 11:41:25 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [IPv6:2a01:4f8:d0a:2645::2]) (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 4F07377103 for ; Wed, 5 Jun 2019 11:41:23 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1hYUI3-0001sR-QS for freebsd-hackers@freebsd.org; Wed, 05 Jun 2019 13:41:11 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1hYUI3-0007Oc-KZ for freebsd-hackers@freebsd.org; Wed, 05 Jun 2019 13:41:11 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1B9B82A1611 for ; Wed, 5 Jun 2019 13:41:29 +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 7GOmF9X3IApo for ; Wed, 5 Jun 2019 13:41:28 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id C689B2A165C for ; Wed, 5 Jun 2019 13:41:28 +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 NejHxvqND4Eb for ; Wed, 5 Jun 2019 13:41:28 +0200 (CEST) Received: from linux-diu0.suse (unknown [192.168.96.161]) by mail.embedded-brains.de (Postfix) with ESMTP id 9E7B02A1611 for ; Wed, 5 Jun 2019 13:41:28 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH] if_lagg: Add INVARIANTS condition Date: Wed, 5 Jun 2019 13:41:10 +0200 Message-Id: <20190605114110.30467-1-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.16.4 X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.100.3/25471/Wed Jun 5 10:12:21 2019) X-Rspamd-Queue-Id: 4F07377103 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=softfail (mx1.freebsd.org: 2a01:4f8:d0a:2645::2 is neither permitted nor denied by domain of sebastian.huber@embedded-brains.de) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-2.77 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[mx.embeddedbrains.de,mx.netmuc.net]; NEURAL_HAM_SHORT(-0.92)[-0.917,0]; MID_CONTAINS_FROM(1.00)[]; IP_SCORE(-0.75)[ipnet: 2a01:4f8::/29(-1.99), asn: 24940(-1.75), country: DE(-0.00)]; DMARC_NA(0.00)[embedded-brains.de]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_SEVEN(0.00)[8]; HAS_X_AS(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 11:41:25 -0000 There is no need to call in_epoch() in case INVARIANTS is not defined. --- sys/net/if_lagg.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sys/net/if_lagg.c b/sys/net/if_lagg.c index 1a4d1d302ec..3e1cb2043b0 100644 --- a/sys/net/if_lagg.c +++ b/sys/net/if_lagg.c @@ -1955,12 +1955,14 @@ lagg_link_active(struct lagg_softc *sc, struct lagg_port *lp) * Search a port which reports an active link state. */ +#ifdef INVARIANTS /* * This is called with either LAGG_RLOCK() held or * LAGG_XLOCK(sc) held. */ if (!in_epoch(net_epoch_preempt)) LAGG_XLOCK_ASSERT(sc); +#endif if (lp == NULL) goto search; -- 2.16.4 From owner-freebsd-hackers@freebsd.org Wed Jun 5 12:00:05 2019 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 19AA215AAB78 for ; Wed, 5 Jun 2019 12:00:05 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4492777AC0; Wed, 5 Jun 2019 12:00:03 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f179.google.com with SMTP id v18so1734484ljh.6; Wed, 05 Jun 2019 05:00:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=CFMy5jHdpTNMDuXKlrZuVAO2dLtDDKbR6W0K/76nYUg=; b=lG26qQMIlhPQqWN27KoGqfIY5qKwehgDlhnTWXkrm6aHelRtmFkZ9dh9LkY5vGVL99 75pbzQ+0flSoFbDpsfvk+OOHoeQ8d+fEwCZJ9OF895U110FnBsBKq6a83hHTxRY6BRWI 3QkpAJv/bc2uKtaRcgsRI5bozrMGVYHpr56UnVpKptUQxSR4zYp5Oz3V0jUz97zbGfFM IR/Ta6SByqNLA7IyrgHWupXlgh4tfsGM+hOKrBmT5dkJkleoHGpvkdg005xHXEiHJ47d TEPa8gi+TFC32NCwr/dV/r30mnlu16XY177F1+LW3VEalBG2gPzuciySX4lt8NeX8EEl A2kw== X-Gm-Message-State: APjAAAURq+WYVxXlnx6ksqSq/kfcwaGfIbWWYr72EVxYN7uW11XlJuDZ anu78YQEKRZb6/H0JHIyqdtqt/wq X-Google-Smtp-Source: APXvYqyooLXrlttHzDwb5zDCnE92ngwXa8g1DAf51WTe5bZpWBcBL+tR+5XPtJ9m5vGPE3vv8jjAuw== X-Received: by 2002:a2e:568b:: with SMTP id k11mr21157752lje.124.1559735995774; Wed, 05 Jun 2019 04:59:55 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id a7sm1173693lfo.22.2019.06.05.04.59.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jun 2019 04:59:54 -0700 (PDT) Subject: Re: gpio interrupt on x86 To: Ian Lepore , FreeBSD Hackers References: <2c99a77c-a423-c2ea-1b2c-b2eefbae13c1@FreeBSD.org> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <0544d3b9-7f6a-5626-3ab3-90c262a3f21d@FreeBSD.org> Date: Wed, 5 Jun 2019 14:59:53 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4492777AC0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-4.05 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.27)[ip: (-0.59), ipnet: 209.85.128.0/17(-3.39), asn: 15169(-2.30), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[179.208.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.78)[-0.777,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 12:00:05 -0000 On 30/05/2019 18:35, Ian Lepore wrote: > On Mon, 2019-05-27 at 18:17 +0300, Andriy Gapon wrote: >> I would like to run some code when an input pin changes its state. >> A GPIO controller that handles that pin is capable of generating an interrupt. >> I can configure the type of a signal change that would trigger the interrupt. >> The GPIO controller would generate the interrupt on that change. >> I would be able to query the controller for a specific pin (if interrupts for >> multiple pins are enabled). >> All is good. >> >> Now, the question is how to _properly_ hook my code to the gpiobus hanging off >> the controller. >> I see that embedded (or not so embedded) platforms typically define a "slave" >> interrupt controller. I guess that it defines a new interrupt number (and >> interrupt source, etc) for each interrupt capable pin. And then hooking to that >> pin is a matter of just installing an interrupt handler for a specific interrupt >> and enabling it. >> >> But I am not sure if the same approach would work on x86. >> Is there any other alternative approach? >> Perhaps even a more light-weight one? >> Any code examples? >> >> Thank you. > > The way this works on modern embedded systems is via INTRNG, a > framework that allows any number of interrupt controllers of differing > types and capabilities to coexist. A gpio hardware driver registers > itself as an interrupt controller, then the interrupts it provides > (each gpio pin) are accessible as resources just like interrupts on the > primary controller, and so drivers just use interrupts that originate > from a gpio pin the same as they would any other interrupt. > > Of course, one required piece of magic to make all this work is > metadata: something needs to make the connection between the gpio > controller and pin, and the driver that wants to use changes on that > pin as an interrupt indication. In the embedded world it's FDT data > that describes those connections, so that when a driver asks for > interrupt resource index N it reads the FDT data to find a cross- > reference to which gpio device and pin to use for that. The > connections between the gpiopin interrupt source and the resources > allocated by other drivers are made in nexus. This is because > typically there isn't a parent-child relationship between the device > that manages the gpio pins and the devices that want to use those pins > as a source of interrupts; nexus is the common ancestor of both. > > The x86 world doesn't use INTRNG (but it must have something similar, > since all modern x86 hardware has multiple interrupt controllers). So > I'm not sure how a gpio driver for x86 might be an interrupt source, > but there should be a way for that to happen. The harder part, I > think, will be coming up with the metadata to allow another driver > which is not a [grand]child of the gpio controller to use those > interrupts. Thank you for the detailed explanation, Ian. It's a good to understand how things are before talking / ranting about how I would want them to be :) Ideally, I would like to see more support from gpio bus for pin events. I think that it would be nice to have interfaces to enable events on a pin and types of events to report. To register a callback for a pin event, etc. Just like we have interface to configure a pin to be an output or an input. To set or query its level. That is, I want to say that gpio controller drivers do not have to be interrupt controllers (directly). They must, of course, provide access to interrupt related hardware configuration. But I would prefer it to be on a lower level. Then, there could be a "gpio pic" that would provide interrupt controller functionality on top of gpio controller pin event capabilities. In theory, a single gpio-pic driver could handle common functionality of all interrupt capable gpio controllers. Also, it could be that having an interrupt controller would not always be necessary and a simple callback function for a pin event would be sufficient and easier to work with. But maybe there is not much practical difference between what I want and what we already have. It's certainly not impossible to add another interrupt controller type on x86. But I fear that it may have its rough edges. E.g., until recently x86 interrupt controllers had to be aware of each other. It was not really plug-and-play. Not sure about the latest state of the matters. But if we will need some global changes for each interrupt controller and there will be many x86 gpio controllers with interrupt controller interface, then it may get cumbersome. Certainly, gpio as an interrupt controller would be novel on x86. There is another angle that you mentioned. Nowadays, x86 single-board computers are not a rare thing. I can have a perfect knowledge of what hardware components are present on the board and how they are connected. But there is no good way for me to pass that knowledge to the OS if the firmware does not do it. And quite often it does not. As I understand, on x86 we still use ACPI to describe the hardware (and to interact with it, to some degree). And, as far as I have been able to find out, there is no standard ACPI way to describe, e.g., a GPIO controller. Or LEDs connected to it. Even if there is such a way, then many vendors simply won't do hard ACPI things for a variety of reasons (competence, return on investment, etc). They seem to mostly just re-use some reference ACPI code. It's possible to customize DSDT, but writing correct ASL is far from trivial. Comparing to something like FDT (that does a single job and does it very well), DSDT is much more complex. It's both declarative and imperative and it does so many different things and has so many complex interactions. So, what do we have without FDT and without full device description in ACPI? Only hints. But hints are too simplistic to express proper device relationships. For example, if I have two GPIO controllers and it's up to a chance which one would be gpio0 on this boot, then how can I refer to the right controller in the hints... In the end I feel that I would need sort of a "meta-driver" for a concrete SBC platform that would use explicit "add child" calls to build parts of the device tree that are not described in ACPI. And that's messy as well. Done for now :) -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed Jun 5 12:09:01 2019 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 770EF15ABABD; Wed, 5 Jun 2019 12:09:01 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A4C5804B7; Wed, 5 Jun 2019 12:09:01 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id CE808B80; Wed, 5 Jun 2019 12:09:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:6d39:7af7:f5e8:48b6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 55AFD1B34B; Wed, 5 Jun 2019 15:08:57 +0300 (MSK) Date: Wed, 5 Jun 2019 15:08:56 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <1644469784.20190605150856@serebryakov.spb.ru> To: Slawa Olhovchenkov , Ian Lepore CC: freebsd-fs@freebsd.org, freebsd-hackers@FreeBSD.org, Alexander Motin Subject: Re: Commit r345200 (new ARC reclamation threads) looks suspicious to me. In-Reply-To: <20190531151202.GG47119@zxy.spb.ru> References: <55989579-a228-498e-2842-453cad6f315f@FreeBSD.org> <174f71126ca39907370a8904c07546b712ad91b9.camel@freebsd.org> <20190531151202.GG47119@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1A4C5804B7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.959,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 12:09:01 -0000 Hello Slawa, Friday, May 31, 2019, 6:12:02 PM, you wrote: > What about arc_no_grow, for example? > arc_no_grow set in arc_reap_cb_check(), called from arc_reap_zthr > thread and in arc_lowmem(). > arc_no_grow test in arc_adapt(), called from > arc_read()/arc_get_data_impl() called from many unsynced thread. > How synced visibility of this varibale? I don;t like this one either. It is set under mutex (t->zthr_lock of reap thread/timer), but looks like tit is read by many other threads... And `arc_lowmem()` uses `arc_adjust_lock`... -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-hackers@freebsd.org Wed Jun 5 13:21:30 2019 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 332E415ADBDF for ; Wed, 5 Jun 2019 13:21:30 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F3BA82FDD; Wed, 5 Jun 2019 13:21:29 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f68.google.com with SMTP id a9so17649616lff.7; Wed, 05 Jun 2019 06:21:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UY1CdniDlzkNYAPJKSxbnvBh99BYNVb0WMhSovUNXsU=; b=MsTr9aMTDWAyM7i+x647sOV4Rsenvqlbev7qaVM/vnj4J/dIgufjkjuLGlCfq0ixIe kTv1cEPB1bbEajot+hQexW4YMr/868y7fkTU8913nTY5LEdpWD6rLJoUmsmxJxsrZY5l 24I0o4mZMX6I/s3Y/ueuv2L5RWVnCca0XY2gfTUzAeWc+4FiBqUH3uoIGkX9WYWj1L2e 2dZH7Auy+k0u9/FfxtXBVn+M3b9QqSujkkxJDRUF1EG33FqdRwIjys21nZQwsaQOQu1b Vc7VsG4YRrA9WCnaeBWImMYEr/qyHnO9jizPBd8N9WMsRZlYDiQOFrHxZDd6woltkV1N aYnA== X-Gm-Message-State: APjAAAWJWbx54ETDdTbaoaxPogSu4RdnLKPkuH/j+cr7gVss9jK46M2N 7I1KiZBQTKpBnF3KHdUvjqvF8QzT X-Google-Smtp-Source: APXvYqxm4S0Vv/vB9k7D9iUarbCX9T729sUw5RkNaet9aiUAWXUlI9SEPldDWo5/eLhEsMdQe/teGg== X-Received: by 2002:a19:c142:: with SMTP id r63mr21819073lff.49.1559740880906; Wed, 05 Jun 2019 06:21:20 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id b25sm4195323lff.42.2019.06.05.06.21.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jun 2019 06:21:19 -0700 (PDT) Subject: Re: setting driver properties for a particular device To: Ian Lepore , Michael Zhilin Cc: FreeBSD Hackers References: <201905231115.x4NBFMSu037564@repo.freebsd.org> <523f92fe-c106-db6b-00d9-356913fdca5d@FreeBSD.org> <1a8fe3f8-a4d7-44f9-2b90-8b70e158f661@FreeBSD.org> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <5ac39749-3aca-c4c9-56d2-b17d77ca318b@FreeBSD.org> Date: Wed, 5 Jun 2019 16:21:18 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0F3BA82FDD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.68 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-4.07 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[FreeBSD.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.91)[-0.912,0]; RCVD_IN_DNSWL_NONE(0.00)[68.167.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-1.15)[ipnet: 209.85.128.0/17(-3.39), asn: 15169(-2.30), country: US(-0.06)]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[68.167.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 13:21:30 -0000 On 30/05/2019 00:40, Ian Lepore wrote: > On Wed, 2019-05-29 at 13:31 +0300, Andriy Gapon wrote: >> On 29/05/2019 13:29, Michael Zhilin wrote: >>> Hi, >>> >>> There are kenv and sysctl. Is it far from what you are looking for? >> >> No. When I said programmatically, I meant programmatically from >> within the kernel. >> > > Hmmm. Whatever you do, it's going to amount to a conspiracy of > agreement between the driver that wants to set this info and the driver > that is expected to act on it. So if you don't use the existing hints > mechanism, then you'll have to invent something new, and the gpioled > driver will have to be updated to also check that new mechanism to see > if there is any config info there that affects it. I'm not sure that's > a big win over the slight inelegance of crafting a hint string at > runtime. I think you are right. Probably, I am going to add a helper function to make that job easier. E.g., something like set_dev_hint(device_t dev, const char *name, const char *val); or perhaps set_dev_hint(device_t dev, const char *name, const char *fmt, ...); >>> On Wed, May 29, 2019 at 1:19 PM Andriy Gapon >> > wrote: >>> >>> On 23/05/2019 14:15, Andriy Gapon wrote: >>> > Author: avg >>> > Date: Thu May 23 11:15:22 2019 >>> > New Revision: 348153 >>> > URL: https://svnweb.freebsd.org/changeset/base/348153 >>> > >>> > Log: >>> > gpioled: add a new hint for initial state >>> > >>> > hint.gpioled.%d.state determines the initial state of the >>> LED when the >>> > driver takes control over it: >>> > 0 - the LED is off >>> > 1 - the LED is on >>> > -1 - the LED is kept as it was >>> >>> By the way, can anyone suggest a mechanism to set device >>> properties like this >>> one _programmatically_ ? >>> >>> I am thinking of a case where I know exactly how everything is >>> wired on a >>> platform. And there is no FDT or alike support for it. And >>> hints are not >>> possible to set up correctly (e.g., bus numbers may float). >>> So, I want to >>> create a gpioled child on a specific bus and I want to set some >>> properties for >>> the device. >>> Of course, I can probably do something like >>> kern_setenv("hints.foo.X.bar", ...) >>> using the child's name and unit number. But that feels a bit >>> cumbersome. >>> >>> And this question is not about gpioled specifically. >>> >>> IVARs is definitely not the right mechanism, because it is >>> about bus-specific >>> properties of devices on the bus. So, it is not aware of >>> properties specific to >>> a driver that attaches to a child device. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed Jun 5 15:18:26 2019 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 31A4915B0FBB for ; Wed, 5 Jun 2019 15:18:26 +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 3D52887381 for ; Wed, 5 Jun 2019 15:18:25 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559747896; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=u3XH8EsPeXQZskbsgMyNo8eImlwdRJcqaw/Heb+aeqG90M0d4gf+M8hi22feNfx02xutuSghrEPOc zkynGOaxzr7qrjAWPWok87TIxo7VHx4upQwvvME23U89FmxCGfVJ15Uz9Yn/PN1AE5kuEgT+bKI5Ve GBjadjOrUGCxyuY/DXHYHPIWrSXxI24jrI9YSKHVt7DUcrYdLRVjmd7GUJdfblWSd6kfokSJz6/McN NAi9ErsB2RBwJHWu3Vb1oEMMJsirvjvwtpCeFGnMksTg7ctUF5PwTCA9WDoQSurkFEMtRjwyF+y+zU GIBhKhErwuUFMtYr9Q3s69TpqLJlsgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=A955583kopOD5rC6xvaqKBxUet+XAlusa9lNvsrGaYU=; b=wO4ufBSSBXD0bMCa6pgSz6hmeDsENJ7pg0DemdqW8cMnw7Bid1GB9S2hdhGPiN5HmpJ2R0zvEnPYA tIek2Qn/wtZyM8NOt2MvXG5qTMR6OVWz5aACreYIZKeKDpXUph1cJJjj/pFSVIPPhw9oeAlWHAvDDW sK81hlGx0HXGFC06qmy2ZluhYVdiZFp9HnfgDWlcmVoMJogeJgX3SxS4pqKVZUt1RLGyeOx7Rzb+9Z IvS6vARYk5xXoQ6hc2AEAaJaArn1w0iUpFvK6OwTAKhSn1AMr1sCCeaQ656/WARHeJvQwKmm5Ubwuw VptxYOMz9CtVtnMf0SDHWaVWpqTKhVw== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=A955583kopOD5rC6xvaqKBxUet+XAlusa9lNvsrGaYU=; b=VYyUICLz40+k/nRjW8fkdJkdve46aRV7o+w2W4h8//aq1etK0F/rX9hqSOCf0RSrcrk2602eihPgt eFGVpDaLvKsqahRRYCthmS9pR7IubyF6tI8ySNu5x+XF8XjuAgeCMHdRLXYj0RTx9qnRtPCZm7091v uPsXSAO2YiakJ8A4yYHucCpe3k16QDEmGs7hLgLQKR8jlnla4D3V3urCoXJBg5wdCZuM48/ohVb0sx 88taHn3k99EWHMaD1Y8tO84M8vlxh9CejgvhhwXzqbqdnPoi7lLwjSTKTUQunKJEWxhPlFqvAtPE3J eRN9UKEwbQJqX+jWBRet7BkyOuTRd+A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 22431261-87a5-11e9-85c6-c97e5c048ed3 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.eu.mailhop.org (Halon) with ESMTPSA id 22431261-87a5-11e9-85c6-c97e5c048ed3; Wed, 05 Jun 2019 15:18:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x55FICKf064579; Wed, 5 Jun 2019 09:18:12 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <9b8fd356d0002e60a1beda621730f1d8861d5d91.camel@freebsd.org> Subject: Re: setting driver properties for a particular device From: Ian Lepore To: Andriy Gapon , Michael Zhilin Cc: FreeBSD Hackers Date: Wed, 05 Jun 2019 09:18:12 -0600 In-Reply-To: <5ac39749-3aca-c4c9-56d2-b17d77ca318b@FreeBSD.org> References: <201905231115.x4NBFMSu037564@repo.freebsd.org> <523f92fe-c106-db6b-00d9-356913fdca5d@FreeBSD.org> <1a8fe3f8-a4d7-44f9-2b90-8b70e158f661@FreeBSD.org> <5ac39749-3aca-c4c9-56d2-b17d77ca318b@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 3D52887381 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 15:18:26 -0000 On Wed, 2019-06-05 at 16:21 +0300, Andriy Gapon wrote: > On 30/05/2019 00:40, Ian Lepore wrote: > > On Wed, 2019-05-29 at 13:31 +0300, Andriy Gapon wrote: > > > On 29/05/2019 13:29, Michael Zhilin wrote: > > > > Hi, > > > > > > > > There are kenv and sysctl. Is it far from what you are looking for? > > > > > > No. When I said programmatically, I meant programmatically from > > > within the kernel. > > > > > > > Hmmm. Whatever you do, it's going to amount to a conspiracy of > > agreement between the driver that wants to set this info and the driver > > that is expected to act on it. So if you don't use the existing hints > > mechanism, then you'll have to invent something new, and the gpioled > > driver will have to be updated to also check that new mechanism to see > > if there is any config info there that affects it. I'm not sure that's > > a big win over the slight inelegance of crafting a hint string at > > runtime. > > I think you are right. > Probably, I am going to add a helper function to make that job easier. > E.g., something like > set_dev_hint(device_t dev, const char *name, const char *val); > or perhaps > set_dev_hint(device_t dev, const char *name, const char *fmt, ...); I like the second one. I think it will be pretty likely that the hints people want to set will involve numbers, so if the only interface was to pass a string, that just means snprintf() or sbuf-print stuff in every driver that wants to use it. Might as well just do the printf implementation in the function everyone already has to call. -- Ian From owner-freebsd-hackers@freebsd.org Thu Jun 6 13:56:45 2019 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 A35A815B447E for ; Thu, 6 Jun 2019 13:56:45 +0000 (UTC) (envelope-from arnaud.ysmal@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (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 BFDFB6E309 for ; Thu, 6 Jun 2019 13:56:44 +0000 (UTC) (envelope-from arnaud.ysmal@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 6BA573783BFA for ; Thu, 6 Jun 2019 15:56:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 5CE413783C42 for ; Thu, 6 Jun 2019 15:56:22 +0200 (CEST) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1YxJWYomJC10 for ; Thu, 6 Jun 2019 15:56:22 +0200 (CEST) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 4ACA43783BFA for ; Thu, 6 Jun 2019 15:56:22 +0200 (CEST) Date: Thu, 6 Jun 2019 15:56:22 +0200 (CEST) From: Arnaud YSMAL To: freebsd-hackers Message-ID: <1792534203.3920198.1559829382150.JavaMail.zimbra@stormshield.eu> Subject: hwpmc module does not work on armv6/armv7 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Thread-Index: T46a0jB2CH+GbRNeIrc95WsYdMCP5Q== Thread-Topic: hwpmc module does not work on armv6/armv7 X-Rspamd-Queue-Id: BFDFB6E309 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.25 / 15.00]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.75)[0.747,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[stormshield.eu]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(1.00)[0.997,0]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mx02.cloud.vadesecure.com,mx04.cloud.vadesecure.com,mx01.cloud.vadesecure.com,mx03.cloud.vadesecure.com]; NEURAL_SPAM_LONG(1.00)[0.997,0]; RCVD_IN_DNSWL_NONE(0.00)[1.116.212.91.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.62)[ip: (1.64), ipnet: 91.212.116.0/24(0.82), asn: 49068(0.66), country: FR(-0.01)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 13:56:45 -0000 Hi, On an armv6/armv7 box, trying to load the hwpmc module lead to an error message stating that the pmc_armv7_finalize symbol is undefined. This can be fixed by adding this in sys/modules/hwpmc/Makefile : .if ${MACHINE_ARCH:Marmv[67]*} != "" SRCS+= hwpmc_armv7.c .endif Does anyone see any reason for not having this? Arnaud Ysmal From owner-freebsd-hackers@freebsd.org Thu Jun 6 14:43:39 2019 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 A086D15B580A for ; Thu, 6 Jun 2019 14:43:39 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEA906FA8B for ; Thu, 6 Jun 2019 14:43:38 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-ed1-x541.google.com with SMTP id p15so3687441eds.8 for ; Thu, 06 Jun 2019 07:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=yQ2FqJEfVP+Fva98AB7fGgAaczDZfRYUe1f9dzHq41U=; b=ZDGM0OKNymRGPlN6Q+Sivh6+8qFGK049dfrXZJChNh5MotNEuaEo8P24OJEROBAH8Z kUv2EyuCHX6D0szAACdc1CIqA2JsDBkEBhIIcDEpoDhFtYNucjoHiWQxRTjatE/4SNIP RZHE/mZ06nL+11qcj3y++XIUYi1j2lCyGHxUsymO6Ch8J8xt06NHPfMh9gEXI0wYETvt SkOsL3iMSC4IUJHf1jsLifcazlmgb8NJdSXWz7MniLbzHkkxM/NpgIsr5/auM1Z7r06w 2WgmqUUDmmP/zQZxv9hKD5/NSSRtaA98pGYWU4sP3O8x5JnCQczT/+l/Kvl1lBKAheUn ltlQ== 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=yQ2FqJEfVP+Fva98AB7fGgAaczDZfRYUe1f9dzHq41U=; b=TwmUP+YaAd5GrqD+H2+s20YxpkjKnIc95u8QFKZvfNrUYiFCDX7xJMR363mNwSKzPR RhqS5hJ+jDoi2u7XlhBMxFtpuKEhVaYu/4C61EsZXxhF5GxNbHZsMaTXdCRVGEyg9cFY 4Rty7SKtHImqn+9HJnGiXuQS4+5vTe1s6msj4eEQG4l0l96ZtQ3Xt2cDBfpk8xuVe/hm sQxjj/YhhQMdeXv/J2N6Aj0kTWOlLWNCah3vgRfg3ZOrfHm6CbBolIe/tmGQ6Y+ozfog PLCRzBCpesvX2OEUhDCvEf20gJrjWdW33eoOQuj7rbHEBbwKoUYsG1bFUpmBZwvY/4kr V47g== X-Gm-Message-State: APjAAAU/V0YcSrmyNdniBtQec9dxDtdE96NdxFmRzf/jwIqqWsfNrf2h 9p6jbCFoNSNyUZw20WoZdzjz84PpmWpDRshzJgDAKuwyV04= X-Google-Smtp-Source: APXvYqxF8SQpLvxl3d18PFkExkjqBD/dluCN4QwYKLwW6LVu2wFXUhHIgIMPo4WM8IoBIR+nPnLCbQFoOy8MtRsbuTs= X-Received: by 2002:a50:90af:: with SMTP id c44mr24556147eda.126.1559832217452; Thu, 06 Jun 2019 07:43:37 -0700 (PDT) MIME-Version: 1.0 From: Mark Saad Date: Thu, 6 Jun 2019 10:43:26 -0400 Message-ID: Subject: Kernel panic on 12-STABLE-r348203 amd64 E5-2690v4 with Cluster on die mode enabled To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: CEA906FA8B X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=ZDGM0OKN X-Spamd-Result: default: False [-3.84 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[longcount.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.00)[ip: (-0.30), ipnet: 2a00:1450::/32(-2.32), asn: 15169(-2.30), country: US(-0.06)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[1.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.53)[-0.533,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 14:43:39 -0000 All I posed this yesterday but; I am not sure what happened. Here is the short version. I received two new Dell r630's each with a E5-2690 v4 . The E5-2690 v4 has 14 Cores in two packages on the one chip. I don't remember the exact topology however as a result the BIOS supports the NUMA / Memory mode know as Cluster on Die were each package on the one chip shows up as its own NUMA domain. The issue is this when enabled the box boots 12-RELEASE a-ok. When I rebuilt 12.0-STABLE-r348203 it would panic early in the boot process. Here is a dump of the console =============================== Loading kernel... /boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80 syms=[0x8+0x1778e8+0x8 / +0x194f1d] Loading configured modules... /boot/kernel/ipmi.ko size 0x11e10 at 0x2645000 loading required module 'smbus' /boot/kernel/smbus.ko size 0x2ef0 at 0x2657000 /boot/entropy size=0x1000 /boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000 ---<>---c_hmodule 'smbus' Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-STABLE r348693 GENERIC amd64 FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) panic: UMA zone "UMA Zones": Increase vm.boot_pages cpuid = 0 time = 1 KDB: stack backtrace: #0 0xffffffff80c16df7 at ??+0 #1 0xffffffff80bcaccd at ??+0 #2 0xffffffff80bcab23 at ??+0 #3 0xffffffff80f0b03c at ??+0 #4 0xffffffff80f08d8d at ??+0 #5 0xffffffff80f0bb3d at ??+0 #6 0xffffffff80f0b301 at ??+0 #7 0xffffffff80f0b3d1 at ??+0 #8 0xffffffff80f066c4 at ??+0 #9 0xffffffff80f0543f at ??+0 #10 0xffffffff80f23aef at ??+0 #11 0xffffffff80f1133b at ??+0 #12 0xffffffff80b619c8 at ??+0 #13 0xffffffff8036a02c at ??+0 Uptime: 1s =============================== The only solution was to mess with vm.boot_pages . I got it booted with 128 as the value. Also to be clear if I switched back to Home Snoop, Early Snoop the box is fine. Its only unhappy whit Cluster on Die and 12.0-STABLE . Anyone know whats going on ? -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Thu Jun 6 14:50:23 2019 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 7CFA215B5B6F for ; Thu, 6 Jun 2019 14:50:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 556EF6FE8A for ; Thu, 6 Jun 2019 14:50:22 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it1-x143.google.com with SMTP id a186so396323itg.0 for ; Thu, 06 Jun 2019 07:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fb97PORDr7CiCUeiOIF95ZABhJvWNcrMwP/8/7ODT98=; b=C6xDRhT43mgGi/Wa9cscdAcJZFIu5CfQyFj7cbLRziYtj7Mvw5ZzbbBgeSn+QZmtTt EIWBh8rsq29Mi6QsyWGuWf6pI7n+Y5U+NUKtaaDXIzr/Fgt78tKdm+5eYHe+naIy8LkC aOR6r2JQTlweLZFMhqZJ8+0TWP3VysOTTrR8cS5PAtrhlc5G20go/MMD5GZ2DVC3Ay2y U/V5UaN/ZqLivdKIsVjWv1sKScB9b8O/oOUlBaznZWRr6VlcpKz83FOqbiVBVhqE/i5v TezW6h+La3NqW2PzdFmLSfomEgAdxm82flLcnYZAyBB8vzUoRnipS4dxvBp2SBflsONa N1yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=fb97PORDr7CiCUeiOIF95ZABhJvWNcrMwP/8/7ODT98=; b=Iy9JfdyUwvKhrD5EQUcjUX7HXA4cawlp6OBMTz2VLjoGbLzUMBQ9VZ6GgqOxkdRIP3 BhV3Edgg3DgaX2GaF6W9V0aVSJAcveomGa7x74bj2z5AP4fVSHa2g3iiQmMjXcfWG2T+ e1XxlfBXHzkHcLnA6fKvCqjnkLvfIeyg5NQdDTDT9xdrCpjyVnuDe2MkKmF9BrjxT6iu fSjMcThm7+Epnoyphn5EPOUGTMmqnWGK8zxbtnprfFRRhLeW4WCH1U+JHLRzh+UUXfLq uigm1KM7XuLroEz1xT15E6ZmjVYj3D7a2iy6TBZaWcQJqRO1eWRqkQtLT/TdOlPQHcE8 T1iQ== X-Gm-Message-State: APjAAAUa30irQ/3CnPwJndl+d8HOQ0xji84DOgPCmP5CFTIIHhREBmgq TwwtHhqvh3zuUCmcqGxc7ZZpMcZm X-Google-Smtp-Source: APXvYqw+809++sAort53WZd5r0hGGRLaN9UDX/qLILwmYteWcR2MtOv3QXyaivMi4Dr/Su1ILRKzrg== X-Received: by 2002:a24:ac60:: with SMTP id m32mr372295iti.40.1559832621647; Thu, 06 Jun 2019 07:50:21 -0700 (PDT) Received: from raichu (toroon0560w-lp130-12-70-50-22-99.dsl.bell.ca. [70.50.22.99]) by smtp.gmail.com with ESMTPSA id 138sm1030047itu.26.2019.06.06.07.50.20 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 06 Jun 2019 07:50:20 -0700 (PDT) Sender: Mark Johnston Date: Thu, 6 Jun 2019 10:50:16 -0400 From: Mark Johnston To: Mark Saad Cc: FreeBSD Hackers Subject: Re: Kernel panic on 12-STABLE-r348203 amd64 E5-2690v4 with Cluster on die mode enabled Message-ID: <20190606145016.GA4116@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: 556EF6FE8A X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=C6xDRhT4; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::143 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-3.36 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.954,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.69)[ip: (2.11), ipnet: 2607:f8b0::/32(-3.22), asn: 15169(-2.30), country: US(-0.06)]; MID_RHS_NOT_FQDN(0.50)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 14:50:23 -0000 On Thu, Jun 06, 2019 at 10:43:26AM -0400, Mark Saad wrote: > All > I posed this yesterday but; I am not sure what happened. Here is the > short version. > I received two new Dell r630's each with a E5-2690 v4 . The E5-2690 v4 > has 14 Cores in two packages on the one chip. I don't remember the > exact topology however as a result the BIOS supports the NUMA / Memory > mode know as Cluster on Die were each package on the one chip shows up > as its own NUMA domain. The issue is this when enabled the box boots > 12-RELEASE a-ok. When I rebuilt 12.0-STABLE-r348203 it would panic > early in the boot process. > Here is a dump of the console > =============================== > Loading kernel... > /boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80 > syms=[0x8+0x1778e8+0x8 / > +0x194f1d] > Loading configured modules... > /boot/kernel/ipmi.ko size 0x11e10 at 0x2645000 > loading required module 'smbus' > /boot/kernel/smbus.ko size 0x2ef0 at 0x2657000 > /boot/entropy size=0x1000 > /boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000 > ---<>---c_hmodule 'smbus' > Copyright (c) 1992-2019 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-STABLE r348693 GENERIC amd64 > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on > LLVM 8.0.0) > panic: UMA zone "UMA Zones": Increase vm.boot_pages > cpuid = 0 > time = 1 > KDB: stack backtrace: > #0 0xffffffff80c16df7 at ??+0 > #1 0xffffffff80bcaccd at ??+0 > #2 0xffffffff80bcab23 at ??+0 > #3 0xffffffff80f0b03c at ??+0 > #4 0xffffffff80f08d8d at ??+0 > #5 0xffffffff80f0bb3d at ??+0 > #6 0xffffffff80f0b301 at ??+0 > #7 0xffffffff80f0b3d1 at ??+0 > #8 0xffffffff80f066c4 at ??+0 > #9 0xffffffff80f0543f at ??+0 > #10 0xffffffff80f23aef at ??+0 > #11 0xffffffff80f1133b at ??+0 > #12 0xffffffff80b619c8 at ??+0 > #13 0xffffffff8036a02c at ??+0 > Uptime: 1s > > =============================== > > The only solution was to mess with vm.boot_pages . I got it booted > with 128 as the value. > Also to be clear if I switched back to Home Snoop, Early Snoop the box > is fine. Its only > unhappy whit Cluster on Die and 12.0-STABLE . > > Anyone know whats going on ? Could you build a kernel with "options DIAGNOSTIC" configured and boot in verbose mode? The kernel should print its boot page allocations to the console. Then, compare the output with a boot with cluster on die disabled. From owner-freebsd-hackers@freebsd.org Thu Jun 6 15:22:52 2019 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 D929B15B6C20 for ; Thu, 6 Jun 2019 15:22:51 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (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 266BD71767 for ; Thu, 6 Jun 2019 15:22:50 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559834563; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=TZm05/u9kHzTqmZavlPxwMTr98PR+i9GEuEe/B5a/79bhZysdYs4tRqmNmFmSZC6fz2MIExJAhBlq 5gfmAldRHThkEsH08bE90fWIV6xR4iz78yM0bCIRyamCaNLMRIirApUs+Af5hEbwLqa4RG4qP6kSAR tSvFNwWZsEv49/96k4ohRREHFoTcg+EL+rdaRAF1RRTZboeKxCEPWz7AI/4v8s/mYHvbgaxqZd4vqe 7cI0w4HDJgE6D2ljSkTkDC637jzo2aljaokPQD7UEfWI2D7tfGxnRO2LCZ+6Z70WkEAbh8APGsAnX9 AWIVAdJOZ5NTKc1BIZ79+VdbX/WbuRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=KHqM6HnElQ4S1rSzGHvbclziDPlNanNMe6ei3AQ/4dY=; b=fZYqEFpZ4Vl1lYdKOcBAqLhAdzMBU1Dl7I0T5y/WNIm8tVaTKFvkAtGwZwdfFJVambc6v5x8Mzj/c NuLGO6gRGxZhjwwryAxWvHMvkdrXhWjPezJo81UdGo7WnWRdIegzo7EaKET44Nve4ehDXoorqLXwXt SG0guEmHWr5sgI1Vr4dYQFoRoe79fGsjWNk0Rg8vCA/ebf4YxXUBl3oXBR/0nWX/jW11h32sz1fx+U SrYICazkkXcrjC1NgY6J570jB99u9Lr7qYLFrLA+VoIEthyXFQyY15HJAMczqYzunSRLOGWhGwgVYt F/SCx8hwFFQ5ThJf1lbIL4lr5CS90DQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=KHqM6HnElQ4S1rSzGHvbclziDPlNanNMe6ei3AQ/4dY=; b=OY/Q/NbHafH8OyN1qTpJSZIxFw/itD4hLg1+VFw/uzTHUwGd8bYzS56edJJb2n57xv1WQ5/rAvT4j zFQKPFqf1/uPb/SKrbMYGdEcGfPmPlYO+3APrS+80TJ5dCNUk7pekdz75pS2SqHTCLmt9Xe5C7Rl2o srJFDOAoWRjhxD/gRkPn3cit22uCOpzRsZlzj+wwff5bt9yViMhIg4uO3/THhbbHRz7aU4r8ygHLyL V2J5tHZzj95NRliu4sgEcbeTJBgNN6qH0cgBF1A+fnidit5nfNFcaPplsGE5Vp6NAS4Jd7UTOEUAO5 4MdvDAaE7nIsGIJbR9W/quzsgsid5gw== X-MHO-RoutePath: aGlwcGll X-MHO-User: ed096361-886e-11e9-b39a-9d2c53d3dedb 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 outbound4.ore.mailhop.org (Halon) with ESMTPSA id ed096361-886e-11e9-b39a-9d2c53d3dedb; Thu, 06 Jun 2019 15:22:42 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x56FMfPW068384; Thu, 6 Jun 2019 09:22:41 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <401683db73f04cecf12bd11f995480d7a54e9187.camel@freebsd.org> Subject: Re: hwpmc module does not work on armv6/armv7 From: Ian Lepore To: Arnaud YSMAL , freebsd-hackers Date: Thu, 06 Jun 2019 09:22:41 -0600 In-Reply-To: <1792534203.3920198.1559829382150.JavaMail.zimbra@stormshield.eu> References: <1792534203.3920198.1559829382150.JavaMail.zimbra@stormshield.eu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 266BD71767 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-3.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.995,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 15:22:52 -0000 On Thu, 2019-06-06 at 15:56 +0200, Arnaud YSMAL wrote: > Hi, > > On an armv6/armv7 box, trying to load the hwpmc module lead to an > error message stating that the pmc_armv7_finalize symbol is > undefined. > > This can be fixed by adding this in sys/modules/hwpmc/Makefile : > > .if ${MACHINE_ARCH:Marmv[67]*} != "" > SRCS+= hwpmc_armv7.c > .endif > > Does anyone see any reason for not having this? > > No reason, that was just a bug. I've committed your fix as r348741, thanks! -- Ian From owner-freebsd-hackers@freebsd.org Thu Jun 6 15:33:08 2019 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 0A1B315B72A1 for ; Thu, 6 Jun 2019 15:33:08 +0000 (UTC) (envelope-from arnaud.ysmal@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (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 EDF3271E93; Thu, 6 Jun 2019 15:33:06 +0000 (UTC) (envelope-from arnaud.ysmal@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 36FCA3783A94; Thu, 6 Jun 2019 17:32:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 2765A3783AA5; Thu, 6 Jun 2019 17:32:50 +0200 (CEST) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LDNTaXVJPUIj; Thu, 6 Jun 2019 17:32:50 +0200 (CEST) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 148FF3783A94; Thu, 6 Jun 2019 17:32:50 +0200 (CEST) Date: Thu, 6 Jun 2019 17:32:49 +0200 (CEST) From: Arnaud YSMAL To: Ian Lepore Cc: freebsd-hackers Message-ID: <1084915390.3960836.1559835169854.JavaMail.zimbra@stormshield.eu> In-Reply-To: <401683db73f04cecf12bd11f995480d7a54e9187.camel@freebsd.org> References: <1792534203.3920198.1559829382150.JavaMail.zimbra@stormshield.eu> <401683db73f04cecf12bd11f995480d7a54e9187.camel@freebsd.org> Subject: Re: hwpmc module does not work on armv6/armv7 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thread-Topic: hwpmc module does not work on armv6/armv7 Thread-Index: 3aPLYSgYserlK8ZgkBxj9evKsGTHlA== X-Rspamd-Queue-Id: EDF3271E93 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.46 / 15.00]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.95)[0.953,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[stormshield.eu]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.995,0]; IP_SCORE(0.62)[ip: (1.64), ipnet: 91.212.116.0/24(0.82), asn: 49068(0.65), country: FR(-0.01)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx02.cloud.vadesecure.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.116.212.91.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(1.00)[0.999,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 15:33:08 -0000 ----- Le 6 Juin 19, =C3=A0 17:22, Ian Lepore ian@freebsd.org a =C3=A9crit : > On Thu, 2019-06-06 at 15:56 +0200, Arnaud YSMAL wrote: >> Hi, >>=20 >> On an armv6/armv7 box, trying to load the hwpmc module lead to an >> error message stating that the pmc_armv7_finalize symbol is >> undefined. >>=20 >> This can be fixed by adding this in sys/modules/hwpmc/Makefile : >>=20 >> .if ${MACHINE_ARCH:Marmv[67]*} !=3D "" >> SRCS+=3D hwpmc_armv7.c >> .endif >>=20 >> Does anyone see any reason for not having this? >>=20 >>=20 >=20 > No reason, that was just a bug. I've committed your fix as r348741, > thanks! Thank you. Sorry for not spotting it earlier but, could you please fix the armv7 invar= iant build with this patch? diff --git a/sys/dev/hwpmc/hwpmc_armv7.c b/sys/dev/hwpmc/hwpmc_armv7.c index 0a601145f8d..d89b5ce302f 100644 --- a/sys/dev/hwpmc/hwpmc_armv7.c +++ b/sys/dev/hwpmc/hwpmc_armv7.c @@ -315,11 +315,12 @@ armv7_intr(struct trapframe *tf) int error; int reg, cpu; =20 + cpu =3D curcpu; + KASSERT(cpu >=3D 0 && cpu < pmc_cpu_max(), ("[armv7,%d] CPU %d out of range", __LINE__, cpu)); =20 retval =3D 0; - cpu =3D curcpu; pc =3D armv7_pcpu[cpu]; =20 for (ri =3D 0; ri < armv7_npmcs; ri++) { >=20 > -- Ian From owner-freebsd-hackers@freebsd.org Thu Jun 6 15:36:18 2019 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 7567D15B7460 for ; Thu, 6 Jun 2019 15:36:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (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 B383C72075 for ; Thu, 6 Jun 2019 15:36:17 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559835369; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=T93L7rF8RPtjOXML8pUS4y3z7u+oVJ7ViJLoZP0+HLA73whwqzY5CeSt5RH4qGqiYgaLGjkbiAcze pZBrY7tZlWno5W/reLyArJggQyJt7sN9N+abx6J9ZdRE5/O3Nfnz6HrgEGsxSKP0NVXrrsXbfNs4Z3 tPrRVQuozr6L39RRPk21rWxL73J+TbKNgGSet4MzgX5FLEd9oqkahR22TPvcwZt68+5qaZKyLJindB 2KGDgfIiNaY9kxFQW+xJ/5ty+cdYnIou9UyTyOTmi8DqGdiJ8b8hV8yJtWhgIhQecsIrwHID0UrzrC iy3EXfwBDdshZGNfkE56dKjNz+IQ60g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=SveDESkBDEvI/kjZ/gR9/0bGZ2TMEVGTL/hlxP2hTXo=; b=BNWFH0lkKWCaZFXNoPvFH6mA0hu7b/ocDe3UcRMkj9C5bUO3EiWrvc/XisIuodU3hD7HVdy7wUiyN 15j0GmVgoUZA0tGifJ4VMy9t/yZiu8IbxQ/H5c4ECAw8wZpq6sn40jQyoXkgkAtsrRzPLK053qUO4u i+Xt1r09aww1Jg4KXczEkJ/wEY+5Ss7nDpU1MmW84oAeyGt5tGDCVsrLs78/YAppsnEsCBG2WLXeVx ciM6azH+oCU5SUmWKNQCo+XdmdQOV6g76cqDZwM8ubxh1STnZ9f6Km90y4S219Zxu/b9gwfkKJhRjG fleQU/w+u8h9EDdrl7jUSHnoWavXY9g== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=SveDESkBDEvI/kjZ/gR9/0bGZ2TMEVGTL/hlxP2hTXo=; b=b853SUHD1NxFrLspMkTolS04UHC1jD3peYwzKzp2H186habLavmCE8uZ5r9ue21jIUtGBIw0Y6F/s j9LiLGYtmn4LtL/Cp+PS6LN3aKrPcBLfw/T4hg4/c+BsMLogQAyHdsl2k7+eoCBuP2CqrzfOlOElkz DszUvA+xGCmtzAR5Be7E0N9ecRCp5d0VMNA0UuALypHXqOtc6fQN0Jo24NROVUgxeK4l+cynSEHfZo 8udgNj3t4dGmTyv+/Q9Xq/o+xvVJ0Gv+6IRJVtID8pEKTaIOsn8wsQ4GmFWaFULgr/6ZzIUxRWSoil +sBZJoUT3epDJ5xD3IjDj1qlBKnzKSQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: cc4b9e73-8870-11e9-91aa-b56e4e6b5865 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 outbound3.eu.mailhop.org (Halon) with ESMTPSA id cc4b9e73-8870-11e9-91aa-b56e4e6b5865; Thu, 06 Jun 2019 15:36:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x56Fa5ch068436; Thu, 6 Jun 2019 09:36:05 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: hwpmc module does not work on armv6/armv7 From: Ian Lepore To: Arnaud YSMAL Cc: freebsd-hackers Date: Thu, 06 Jun 2019 09:36:05 -0600 In-Reply-To: <1084915390.3960836.1559835169854.JavaMail.zimbra@stormshield.eu> References: <1792534203.3920198.1559829382150.JavaMail.zimbra@stormshield.eu> <401683db73f04cecf12bd11f995480d7a54e9187.camel@freebsd.org> <1084915390.3960836.1559835169854.JavaMail.zimbra@stormshield.eu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: B383C72075 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 15:36:18 -0000 On Thu, 2019-06-06 at 17:32 +0200, Arnaud YSMAL wrote: > ----- Le 6 Juin 19, à 17:22, Ian Lepore ian@freebsd.org a écrit : > > > On Thu, 2019-06-06 at 15:56 +0200, Arnaud YSMAL wrote: > > > Hi, > > > > > > On an armv6/armv7 box, trying to load the hwpmc module lead to an > > > error message stating that the pmc_armv7_finalize symbol is > > > undefined. > > > > > > This can be fixed by adding this in sys/modules/hwpmc/Makefile : > > > > > > .if ${MACHINE_ARCH:Marmv[67]*} != "" > > > SRCS+= hwpmc_armv7.c > > > .endif > > > > > > Does anyone see any reason for not having this? > > > > > > > > > > No reason, that was just a bug. I've committed your fix as > > r348741, > > thanks! > > Thank you. > > Sorry for not spotting it earlier but, could you please fix the armv7 > invariant build with this patch? > > > diff --git a/sys/dev/hwpmc/hwpmc_armv7.c > b/sys/dev/hwpmc/hwpmc_armv7.c > index 0a601145f8d..d89b5ce302f 100644 > --- a/sys/dev/hwpmc/hwpmc_armv7.c > +++ b/sys/dev/hwpmc/hwpmc_armv7.c > @@ -315,11 +315,12 @@ armv7_intr(struct trapframe *tf) > int error; > int reg, cpu; > > + cpu = curcpu; > + > KASSERT(cpu >= 0 && cpu < pmc_cpu_max(), > ("[armv7,%d] CPU %d out of range", __LINE__, cpu)); > > retval = 0; > - cpu = curcpu; > pc = armv7_pcpu[cpu]; > > for (ri = 0; ri < armv7_npmcs; ri++) { > > Already did, right before I committed your change. :) I've just heard on irc that there may be other trouble lurking in armv* hwpmc, some kind of fallout from the changes in r334827. Manu is looking into it, and will probably post something on the arm@ list when he gets it figured out. -- Ian From owner-freebsd-hackers@freebsd.org Thu Jun 6 15:40:54 2019 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 919D715B78F4 for ; Thu, 6 Jun 2019 15:40:54 +0000 (UTC) (envelope-from chagin.dmitry@gmail.com) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B119F72446 for ; Thu, 6 Jun 2019 15:40:53 +0000 (UTC) (envelope-from chagin.dmitry@gmail.com) Received: by mail-io1-f53.google.com with SMTP id e5so559669iok.4 for ; Thu, 06 Jun 2019 08:40:53 -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=p2ltBF3oUxXkQ9+268Y/1rVodiTyTm1V87Oxs/QhcXs=; b=EdAzaC43ASa9SFAyG5UuyOZX2vRg9AL9KuMH0KNVcRVZoTxXg47gTYmNZ+S+Ccd+Qv 9DpoqIoKOETNLqxqQK5b9d3UQVMN212ckxgbJAgCjPQL76/PKYftfuzyZu5jCBxzTitq 7B5VJ9WhvoSVd6KalKJej+8FsHnGnoyvpDvpavEtG4bcEaYNqpnJJAO5RN923DaAa7mg EjRLWYexkM1fdPtSycF4IGzcs2WrL+7s5Hjn7buS0a3RaTfs6V46SOe70VAl3gvIM++7 eWaGxEFVXfcxS2XLgumFHKBcpixhBB4JmmN4+nsqMaxOnWEOi9DPcGLlswj0sSAGIiw0 GI5Q== X-Gm-Message-State: APjAAAXQy2z5DkD4/5C/jFrDMgwtHTEk/mdQWzfKCdSYcJk8w6nIRGKU 1+iT8MPpbv6Cq98tRx+6G8txovgO0Eb9wlgVLhpezVYh X-Google-Smtp-Source: APXvYqwTsv0LJNB+v4Zv3J33buCn2je0fTdthZagDvKtJd/y20+SQs6ZZKWSXoU3YrTi/wtWxIxkrVVw0tOjiEQc1Ys= X-Received: by 2002:a5e:a712:: with SMTP id b18mr691272iod.220.1559835647200; Thu, 06 Jun 2019 08:40:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dmitry Chagin Date: Thu, 6 Jun 2019 18:40:36 +0300 Message-ID: Subject: Re: linux-oracle-jdk18 and futex To: Wojciech Puchar Cc: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: B119F72446 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of chagindmitry@gmail.com designates 209.85.166.53 as permitted sender) smtp.mailfrom=chagindmitry@gmail.com X-Spamd-Result: default: False [-4.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; IP_SCORE(-2.01)[ip: (-4.32), ipnet: 209.85.128.0/17(-3.39), asn: 15169(-2.29), country: US(-0.06)]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_TRACE(0.00)[0:+,1:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[53.166.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[dchagin@freebsd.org,chagindmitry@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[53.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[dchagin@freebsd.org,chagindmitry@gmail.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 15:40:54 -0000 =D1=81=D1=80, 5 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 09:04, Wojciech Puc= har : > i installed linux-oracle-jdk18 > > all linux subsytems are active (linux,linux64,linprocfs,linsysfs), > filesystems mounted > > when running tomcat7 using linux-oracle-jdk18 java process consumes 100% > cpu showing "futex" state constantly. > > With openjdk that uses linux emulation problem doesn't exist. with any > other version of oracje jdk that uses linux emulation - the same problem > > FreeBSD puchar.net 11.3-PRERELEASE FreeBSD 11.3-PRERELEASE #0 r347617: > Sat > May 18 19:54:54 CEST 2019 > root@puchar.net:/h/backup1/src/sys/amd64/compile/puchar amd64 > > any idea what's wrong? > > > Hi, could you please run tomcat under ktrace aka ktrace -di /pathtotomcat then kdump -HAR -m 32 > tomcat.log and send output to me. thanks From owner-freebsd-hackers@freebsd.org Thu Jun 6 15:54:36 2019 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 DBEBA15B7FF0 for ; Thu, 6 Jun 2019 15:54:35 +0000 (UTC) (envelope-from arnaud.ysmal@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (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 46A6372CCC; Thu, 6 Jun 2019 15:54:35 +0000 (UTC) (envelope-from arnaud.ysmal@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id BC949376B2AB; Thu, 6 Jun 2019 17:54:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id ADD203783D66; Thu, 6 Jun 2019 17:54:18 +0200 (CEST) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UL3w9skHUnZ7; Thu, 6 Jun 2019 17:54:18 +0200 (CEST) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 9AAA3376B2AB; Thu, 6 Jun 2019 17:54:18 +0200 (CEST) Date: Thu, 6 Jun 2019 17:54:18 +0200 (CEST) From: Arnaud YSMAL To: Ian Lepore Cc: freebsd-hackers Message-ID: <1767704859.3973852.1559836458545.JavaMail.zimbra@stormshield.eu> In-Reply-To: References: <1792534203.3920198.1559829382150.JavaMail.zimbra@stormshield.eu> <401683db73f04cecf12bd11f995480d7a54e9187.camel@freebsd.org> <1084915390.3960836.1559835169854.JavaMail.zimbra@stormshield.eu> Subject: Re: hwpmc module does not work on armv6/armv7 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thread-Topic: hwpmc module does not work on armv6/armv7 Thread-Index: r7ATFmFi5AKtDtJtKA5ivUIkHohJFA== X-Rspamd-Queue-Id: 46A6372CCC X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.46 / 15.00]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx02.cloud.vadesecure.com]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.960,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[stormshield.eu]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.996,0]; IP_SCORE(0.62)[ip: (1.63), ipnet: 91.212.116.0/24(0.82), asn: 49068(0.65), country: FR(-0.01)]; NEURAL_SPAM_LONG(1.00)[0.999,0]; RCVD_IN_DNSWL_NONE(0.00)[1.116.212.91.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 15:54:36 -0000 ----- Le 6 Juin 19, =C3=A0 17:36, Ian Lepore ian@freebsd.org a =C3=A9crit : > On Thu, 2019-06-06 at 17:32 +0200, Arnaud YSMAL wrote: >> ----- Le 6 Juin 19, =C3=A0 17:22, Ian Lepore ian@freebsd.org a =C3=A9cri= t : >>=20 >> > On Thu, 2019-06-06 at 15:56 +0200, Arnaud YSMAL wrote: >> > > Hi, >> > >=20 >> > > On an armv6/armv7 box, trying to load the hwpmc module lead to an >> > > error message stating that the pmc_armv7_finalize symbol is >> > > undefined. >> > >=20 >> > > This can be fixed by adding this in sys/modules/hwpmc/Makefile : >> > >=20 >> > > .if ${MACHINE_ARCH:Marmv[67]*} !=3D "" >> > > SRCS+=3D hwpmc_armv7.c >> > > .endif >> > >=20 >> > > Does anyone see any reason for not having this? >> > >=20 >> > >=20 >> >=20 >> > No reason, that was just a bug. I've committed your fix as >> > r348741, >> > thanks! >>=20 >> Thank you. >>=20 >> Sorry for not spotting it earlier but, could you please fix the armv7 >> invariant build with this patch? >>=20 >>=20 >> diff --git a/sys/dev/hwpmc/hwpmc_armv7.c >> b/sys/dev/hwpmc/hwpmc_armv7.c >> index 0a601145f8d..d89b5ce302f 100644 >> --- a/sys/dev/hwpmc/hwpmc_armv7.c >> +++ b/sys/dev/hwpmc/hwpmc_armv7.c >> @@ -315,11 +315,12 @@ armv7_intr(struct trapframe *tf) >> int error; >> int reg, cpu; >> =20 >> + cpu =3D curcpu; >> + >> KASSERT(cpu >=3D 0 && cpu < pmc_cpu_max(), >> ("[armv7,%d] CPU %d out of range", __LINE__, cpu)); >> =20 >> retval =3D 0; >> - cpu =3D curcpu; >> pc =3D armv7_pcpu[cpu]; >> =20 >> for (ri =3D 0; ri < armv7_npmcs; ri++) { >>=20 >>=20 >=20 > Already did, right before I committed your change. :) Thanks. :) =20 > I've just heard on irc that there may be other trouble lurking in armv* > hwpmc, some kind of fallout from the changes in r334827. Manu is > looking into it, and will probably post something on the arm@ list when > he gets it figured out. Thank you for the information. >=20 > -- Ian From owner-freebsd-hackers@freebsd.org Thu Jun 6 16:26:15 2019 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 9F18015B8B67 for ; Thu, 6 Jun 2019 16:26:15 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E93207442A for ; Thu, 6 Jun 2019 16:26:13 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd44.google.com with SMTP id h6so691739ioh.3 for ; Thu, 06 Jun 2019 09:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WAOlqPGeZKLhq/3rz78UtbRjHo65cktuzwrn1//y2b4=; b=kvXSNxEBULJbpXoQulazwvQJ7YNLrNMAT2U4euPdJ0NR7K0vjwb6/ahWkRwlreI4oT 18J/ZpwNZCWV8+YIgfWsBRbJwiAPhVxoSOIh3sEVo+Qr1CSAgRjkkGawZ8UcipQMvkG4 qy1aXJgQLaaIDc9SUm8mts/2K/wbnK4OoWyLItjP7WvWPP8hBfQWDzwVz9aeiFHKZ8nV lbS+epsmekjyVp+LpFw22RvChc8LVRc6aEGeQRGDndqCEjx1sU3PPGNW7V0kiU8pVHay KK+lYtqW6WkPfP6uah5SsRhbZhD+SS/stWXFu/FufQQt88K0HOZlYn8bz9LqTrsKYeqn 2LGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=WAOlqPGeZKLhq/3rz78UtbRjHo65cktuzwrn1//y2b4=; b=bjgfMQxbOkgp1vRZf38rfAF9KA9NISTN8lFFTU+bUE13K804HJ3ktCGq35iLjGqukr l4zvafFQQSp3ecr42EO64tZtFHHZof3DDvq5EDuG9d4WIHkflki2ky9KxxTezWhS0trp spwfU+I8K0fDi7qAULwbuOTbf4m43dGPGNHzwTljCdm3n/U6cVzMcwSSooVsf9WBHxp4 rLfDRiqQ2aVgXEuBFf+FM2GXLYkYs6FA3Ul9gCmDjGgQYGIgevFl0GTY5fw7FRBz+XbO az/xlD+YvA0ViXnNc+sc1RxDCj52JlcCCW9CrrghFywhEYezBJHMkWbDtBrAy9wK/Mfm YDHw== X-Gm-Message-State: APjAAAUobQDaXFE8NeuLzyt++YM6GpHf1b/Ma3rXZ/UAlq+pRqs//KYe aNkoEhDRA+TvuJO/b5M8YVPsPbLm X-Google-Smtp-Source: APXvYqxJ32ZGR89gbAHQWYqBbZvU5rPuYLzPQIWpdXmSifaVGKYjZ/Y2ptJ5zUugTtnDbBu4iN1g1A== X-Received: by 2002:a5d:9e49:: with SMTP id i9mr12197570ioi.290.1559838372983; Thu, 06 Jun 2019 09:26:12 -0700 (PDT) Received: from raichu (toroon0560w-lp130-12-70-50-22-99.dsl.bell.ca. [70.50.22.99]) by smtp.gmail.com with ESMTPSA id d133sm1146077itc.27.2019.06.06.09.26.11 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 06 Jun 2019 09:26:12 -0700 (PDT) Sender: Mark Johnston Date: Thu, 6 Jun 2019 12:26:10 -0400 From: Mark Johnston To: Sebastian Huber Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] if_lagg: Add INVARIANTS condition Message-ID: <20190606162610.GC4116@raichu> References: <20190605114110.30467-1-sebastian.huber@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190605114110.30467-1-sebastian.huber@embedded-brains.de> User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: E93207442A X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=kvXSNxEB; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d44 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-3.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; IP_SCORE(-0.78)[ip: (1.67), ipnet: 2607:f8b0::/32(-3.22), asn: 15169(-2.29), country: US(-0.06)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 16:26:15 -0000 On Wed, Jun 05, 2019 at 01:41:10PM +0200, Sebastian Huber wrote: > There is no need to call in_epoch() in case INVARIANTS is not defined. I committed this in r348745. > --- > sys/net/if_lagg.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/sys/net/if_lagg.c b/sys/net/if_lagg.c > index 1a4d1d302ec..3e1cb2043b0 100644 > --- a/sys/net/if_lagg.c > +++ b/sys/net/if_lagg.c > @@ -1955,12 +1955,14 @@ lagg_link_active(struct lagg_softc *sc, struct lagg_port *lp) > * Search a port which reports an active link state. > */ > > +#ifdef INVARIANTS > /* > * This is called with either LAGG_RLOCK() held or > * LAGG_XLOCK(sc) held. > */ > if (!in_epoch(net_epoch_preempt)) > LAGG_XLOCK_ASSERT(sc); > +#endif > > if (lp == NULL) > goto search; > -- > 2.16.4 > > _______________________________________________ > 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 Thu Jun 6 17:43:16 2019 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 E0DD515BA6F2 for ; Thu, 6 Jun 2019 17:43:15 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80547770C6 for ; Thu, 6 Jun 2019 17:43:15 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 30066DF4E for ; Thu, 6 Jun 2019 17:43:15 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:158d:4e3e:a083:6c9b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id B4AF71B6A6 for ; Thu, 6 Jun 2019 20:43:12 +0300 (MSK) Date: Thu, 6 Jun 2019 20:43:12 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <234087607.20190606204312@serebryakov.spb.ru> To: freebsd-hackers@freebsd.org Subject: =?windows-1251?Q?DTrace_SDT_probes_in_kernel_module_=97_how_to=3F?= MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: 80547770C6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 17:43:16 -0000 SGVsbG8gRnJlZWJzZC1oYWNrZXJzLA0KDQogICBXaGF0IHNob3VsZCBJIGRvIHRvIGFkZCBT RFQgcHJvYmVzIGludG8ga2VybmVsIG1vZHVsZS4gSSd2ZSB0cmllZCB0byBhZGQgc2ltcGxl DQoNCkRUUkFDRV9QUk9CRTEobW9kdWxlX19uYW1lLCB0eXBlLCB2YWx1ZSk7DQoNCiAgdG8g c291cmNlIGNvZGUuIE5vIGVycm9ycywgbm8gcHJvYmVzIGFmdGVyIG1vZHVsZSBsb2FkLiBJ J3ZlIGFkZGVkIFdJVEhfQ1RGPTEgdG8gbWFrZQ0KIGNvbW1hbmQgbGluZS4gV2FybmluZ3Mg ZnJvbSBjdGZtZXJnZSwgbm8gcHJvYmVzIGFmdGVyIG1vZHVsZSBsb2FkLg0KDQogIFdoYXQg aXMgcHJvcGVyIHdheSB0byBhZGQgU0RUIHByb2JlcyB0byBtb2R1bGUgYW5kIGhvdyBzaG91 bGQgSSBidWlsZCBpdD8NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQogTGV2ICAgICAgICAgICAg ICAgICAgICAgICAgICBtYWlsdG86bGV2QEZyZWVCU0Qub3Jn From owner-freebsd-hackers@freebsd.org Thu Jun 6 17:45:58 2019 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 54B6F15BA877 for ; Thu, 6 Jun 2019 17:45:58 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52C2077354; Thu, 6 Jun 2019 17:45:57 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f65.google.com with SMTP id a9so791898lff.7; Thu, 06 Jun 2019 10:45:57 -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=b+Nu4br32jIBNjSQkHFfIOZyloZLB92Y42FexOT8R8U=; b=Az/+jpPg/hb+g7rx1WPqHWCi2YaSLmA6+PeCx4Y+a2VjzgQ3B44MLRU9xcJ3EoygPD prWLY/wgT43qnn86rq9b8/kMZ6SACvLyrPHDzC3DS5i8xb/XP0EHv1KD6fwJStu2PNhA bH15l76PCDqYNML+pdqWZY/jXtR5iFa+YcPS+1zRUqj6saTy+LytKIHTH6Lbrx7RcfS4 IMfgJYZa3r67p9JyC7wD4I0w5z3xJ2QIP7aXFPD7djmK5A0WtD8HAYevS5mbz73hzIZa h4sABkXm68baZwwx2f+SM2XjY0TLPb/fT85WxYOiPa5c2vdxHrPzwKNNcwg3c2FnvDE1 Ibug== X-Gm-Message-State: APjAAAUhpbaNuE6g0ixXfszNO8r7dlUThHU+iZOqToG9cH9t6WOIe0Vr eXPHc1hQzBixeiAY09avYx+4X0YiLD3myZdZeMJdcA== X-Google-Smtp-Source: APXvYqwvQ1JOwKsXZ2NhM2Ki5e8edI+3iGXBU1uXpzmhoybZwmDcuq4uRct1hjHN9+pXaOjwklVHk3Kh2mGL+GGaqBU= X-Received: by 2002:ac2:5609:: with SMTP id v9mr16347423lfd.27.1559843150253; Thu, 06 Jun 2019 10:45:50 -0700 (PDT) MIME-Version: 1.0 References: <234087607.20190606204312@serebryakov.spb.ru> In-Reply-To: <234087607.20190606204312@serebryakov.spb.ru> From: Alan Somers Date: Thu, 6 Jun 2019 11:45:38 -0600 Message-ID: Subject: =?UTF-8?Q?Re=3A_DTrace_SDT_probes_in_kernel_module_=E2=80=94_how_to=3F?= To: Lev Serebryakov Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 52C2077354 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.65 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.19 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; SUBJECT_ENDS_QUESTION(1.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[65.167.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.94)[-0.937,0]; IP_SCORE(-1.25)[ip: (-0.49), ipnet: 209.85.128.0/17(-3.39), asn: 15169(-2.29), country: US(-0.06)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[65.167.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 17:45:58 -0000 On Thu, Jun 6, 2019 at 11:43 AM Lev Serebryakov wrote: > > Hello Freebsd-hackers, > > What should I do to add SDT probes into kernel module. I've tried to add simple > > DTRACE_PROBE1(module__name, type, value); > > to source code. No errors, no probes after module load. I've added WITH_CTF=1 to make > command line. Warnings from ctfmerge, no probes after module load. > > What is proper way to add SDT probes to module and how should I build it? > > -- > Best regards, > Lev mailto:lev@FreeBSD.org How are you building the module? Typing "make" in sys/modules/whatever doesn't build the dtrace probes. Presumably that could be fixed, but I've never tried. However, if you do a full "make buildkernel" then you will get dtrace probes. -Alan From owner-freebsd-hackers@freebsd.org Thu Jun 6 17:48:53 2019 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 3B0BA15BAA57 for ; Thu, 6 Jun 2019 17:48:53 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4D7F775CD; Thu, 6 Jun 2019 17:48:52 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 93CAEDF4F; Thu, 6 Jun 2019 17:48:52 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:158d:4e3e:a083:6c9b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id DA56C1B6AA; Thu, 6 Jun 2019 20:48:49 +0300 (MSK) Date: Thu, 6 Jun 2019 20:48:49 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <156127070.20190606204849@serebryakov.spb.ru> To: Alan Somers CC: "freebsd-hackers@freebsd.org" Subject: =?windows-1250?Q?Re:_DTrace_SDT_probes_in_kernel_module_=97_how_to=3F?= In-Reply-To: References: <234087607.20190606204312@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: D4D7F775CD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 17:48:53 -0000 SGVsbG8gQWxhbiwNCg0KVGh1cnNkYXksIEp1bmUgNiwgMjAxOSwgODo0NTozOCBQTSwgeW91 IHdyb3RlOg0KDQo+IEhvdyBhcmUgeW91IGJ1aWxkaW5nIHRoZSBtb2R1bGU/ICBUeXBpbmcg Im1ha2UiIGluDQo+IHN5cy9tb2R1bGVzL3doYXRldmVyIGRvZXNuJ3QgYnVpbGQgdGhlIGR0 cmFjZSBwcm9iZXMuICBQcmVzdW1hYmx5IHRoYXQNCiBUaGlzIG9uZSwgeWVzLg0KDQo+IGNv dWxkIGJlIGZpeGVkLCBidXQgSSd2ZSBuZXZlciB0cmllZC4gIEhvd2V2ZXIsIGlmIHlvdSBk byBhIGZ1bGwgIm1ha2UNCj4gYnVpbGRrZXJuZWwiIHRoZW4geW91IHdpbGwgZ2V0IGR0cmFj ZSBwcm9iZXMuDQogT2gsIGl0IGlzIHNvb28gc2xvdyA6LSgNCg0KLS0gDQpCZXN0IHJlZ2Fy ZHMsDQogTGV2ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1haWx0bzpsZXZARnJlZUJT RC5vcmc= From owner-freebsd-hackers@freebsd.org Thu Jun 6 17:49:36 2019 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 0834515BAA96 for ; Thu, 6 Jun 2019 17:49:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it1-x144.google.com (mail-it1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3481775FA; Thu, 6 Jun 2019 17:49:34 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it1-x144.google.com with SMTP id a186so1373334itg.0; Thu, 06 Jun 2019 10:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Ep29bOZ09q1UR23qeUdyWodNlQ4xyBOk7CSpTbAtxOU=; b=B0FjAjacM0SWI5cgxZJAKFZpyDmp6NOdyJvkJeuSTcLy7V2HyFNHsF0FLAu3hyAFUB VBjnsK/p53wBnhotSbjI1cHRipweYkIqPTTZzjUXvl5wNjjejkGDr+EzB4rqmRskPMdD YPcA/OVP0ZLNzACxXAUasQQ4zD5WS3UBa3s93qok3FDnaoYomYnTzD8QKP5rDrfswtDa 2+RRiWxWnOxRZf/ZilQMRs78drzRPK1wuPEby8IwKsiQJQMVLJ9wu1EOpWve0pExIKgM fzpIy4khGc3SfWOhxI3GhoLC0fRNXuM4QbFCysZExz4vWzCvf9unD5iz1JrU/IaxEtgd Vc8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=Ep29bOZ09q1UR23qeUdyWodNlQ4xyBOk7CSpTbAtxOU=; b=oO5VMsAX8N0mI66bPJ0l/6xDrgZu+E8S/mPcQWcm+13Gugit8m1WCQe/qGmbmEDpBd igUToaRViYSnxdKEeeDLWUPsC7uU7PTAFXhh1XiHRd3zftdjaSCe9yw313z1UkRz4yjc KrFaR/1z47Wbw29ujq4mzGNyskAslEPj+dT7xFGBNxJGazTvsaPf7BF4glccto1+BBXR 95RdSS8hgYfuTcTvkNgmwwOBvha8Qz37Z1mHZ+Qj59UCyGvHODufh/2g9+sjFuyPENUZ +2vYDVZj1bmycX7aqE3QnK4DrQ+Cp2P4EnmpEKYnTQ1mtfvHtR8OeRQYnRlEXLmQjqqv vdVQ== X-Gm-Message-State: APjAAAXcRI2ivqBT8vkpFqZY6CgLgiNrfMcl65ubmINxDa2PTIBEoHON tJ2C4jdQxOUixEKNqvFJkAHAy4Yz X-Google-Smtp-Source: APXvYqzbqQ06Q2mvJmOlxoifHIHHrkY2nMRIG9GBpjcZdi6CMSMmKLQw5e3doYNLtInUk4We/jrbdQ== X-Received: by 2002:a24:424f:: with SMTP id i76mr1114736itb.119.1559843374081; Thu, 06 Jun 2019 10:49:34 -0700 (PDT) Received: from raichu (toroon0560w-lp130-12-70-50-22-99.dsl.bell.ca. [70.50.22.99]) by smtp.gmail.com with ESMTPSA id z202sm556629itb.2.2019.06.06.10.49.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 06 Jun 2019 10:49:33 -0700 (PDT) Sender: Mark Johnston Date: Thu, 6 Jun 2019 13:49:31 -0400 From: Mark Johnston To: Lev Serebryakov Cc: freebsd-hackers@freebsd.org Subject: Re: DTrace SDT probes in =?utf-8?Q?kernel_?= =?utf-8?Q?module_=E2=80=94?= how to? Message-ID: <20190606174931.GB3015@raichu> References: <234087607.20190606204312@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <234087607.20190606204312@serebryakov.spb.ru> User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: F3481775FA X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=B0FjAjac; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::144 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.94)[-0.940,0]; IP_SCORE(-0.76)[ip: (1.79), ipnet: 2607:f8b0::/32(-3.22), asn: 15169(-2.29), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[4.4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_NOT_FQDN(0.50)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 17:49:36 -0000 On Thu, Jun 06, 2019 at 08:43:12PM +0300, Lev Serebryakov wrote: > Hello Freebsd-hackers, > > What should I do to add SDT probes into kernel module. I've tried to add simple > > DTRACE_PROBE1(module__name, type, value); > > to source code. No errors, no probes after module load. I've added WITH_CTF=1 to make > command line. Warnings from ctfmerge, no probes after module load. > > What is proper way to add SDT probes to module and how should I build it? Are you missing a #include "opt_kdtrace.h"? From owner-freebsd-hackers@freebsd.org Thu Jun 6 17:49:39 2019 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 EAC3715BAAA9 for ; Thu, 6 Jun 2019 17:49:38 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E13FC775FE; Thu, 6 Jun 2019 17:49:37 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pf1-x434.google.com with SMTP id q10so1948676pff.9; Thu, 06 Jun 2019 10:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=9m2cHvGip3OiLUKJ4e4dwXNrsszqtj5BdV7GCnd35oY=; b=ZH2Xen7mkSCx4ed0OBBNggzPouAjZHKxIdSJ+UOymohOb9NnUKfxjunedW2TFMvX3r EevJLjV8M7m0EjI3DyLAtQAwygPV8a4SCGst8iJJMWkO58leW6/ywREf6+JXcbAsG4tT cMr2NR/iEhwzuFzuuN5HW+uOwd4hKRT3UBoPRxJFCu+7jCFj44Kdp5eBYyTjCIwXLcAG uTlf3+Z2IfLGN34w8mBKhi65CQSv1EgjS4Ca2Cpi725Bh3ZpcAiGwnpkEsiXoGXunWHb QUa77BzxJtyBOGnP0J8EopPs30qhg095C7jvv4Wu8Mi7nlZZrkHZgUblMqgHSUoAr1wB Jtqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9m2cHvGip3OiLUKJ4e4dwXNrsszqtj5BdV7GCnd35oY=; b=iQzlaSJive/lsdEKH40XSfsQQ23zKIwwU3XUf0sQGZh1p2yWBCzzmkGGTv020WvPfd lCGfZ85vgC9Ax+cXTK4r84JUTWqR5kwqjn/UTL8oj4bAkF5NLx+kTlsLqM6c5eA4EALS Rrdc9RVQ/IbykMqUtg4LwjHhrDFX6fyE/kE/pvJFRB/ZW3eUlt9gdKKRbEhAmrAvH1YJ pv3EmsEwmEGiSmXTNy/cycdk/OVZWI8J+hz6P8xPAdIhjEPdlYnNGuEbLQx6SrhbYwHe DjvUfLfe/o8M/Zg7cQ03F7irz8mL8GkerfJzCSq4oiNncQmWd5xovaNz7Hp6SvhmQYR8 DaHA== X-Gm-Message-State: APjAAAWhzvBpfwCagzZTB/ALR9QG9ht+osJYqTk8iy/f21dUa1Cismvv VbFqxINSCi85maO8mqDgMo/nvJ1q X-Google-Smtp-Source: APXvYqwQCm9CMxAsEnxd/bdzmFWNrHZmIw0F9Mf+6q/wTKxbp5tqoOsBnPrqhlDooN6Lm2pHSxDj9A== X-Received: by 2002:a63:ee12:: with SMTP id e18mr4483879pgi.412.1559843376384; Thu, 06 Jun 2019 10:49:36 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id 11sm3820959pfu.155.2019.06.06.10.49.35 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jun 2019 10:49:35 -0700 (PDT) Subject: =?UTF-8?Q?Re=3a_DTrace_SDT_probes_in_kernel_module_=e2=80=94_how_to?= =?UTF-8?Q?=3f?= To: lev@FreeBSD.org, freebsd-hackers@freebsd.org References: <234087607.20190606204312@serebryakov.spb.ru> From: Navdeep Parhar Message-ID: <330a2a83-0fe8-e599-5b36-3b347acdd557@gmail.com> Date: Thu, 6 Jun 2019 10:49:34 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <234087607.20190606204312@serebryakov.spb.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E13FC775FE X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ZH2Xen7m; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of nparhar@gmail.com designates 2607:f8b0:4864:20::434 as permitted sender) smtp.mailfrom=nparhar@gmail.com X-Spamd-Result: default: False [-5.91 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.90)[ip: (-8.92), ipnet: 2607:f8b0::/32(-3.22), asn: 15169(-2.29), country: US(-0.06)]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 17:49:39 -0000 On 2019-06-06 10:43, Lev Serebryakov wrote: > Hello Freebsd-hackers, > > What should I do to add SDT probes into kernel module. I've tried to add simple > > DTRACE_PROBE1(module__name, type, value); > > to source code. No errors, no probes after module load. I've added WITH_CTF=1 to make > command line. Warnings from ctfmerge, no probes after module load. > > What is proper way to add SDT probes to module and how should I build it? > Have you seen https://wiki.freebsd.org/DTrace/HowToAddSDTProbes ? Please update it if it's out of date. Regards, Navdeep From owner-freebsd-hackers@freebsd.org Thu Jun 6 18:17:55 2019 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 BE10615BBE30 for ; Thu, 6 Jun 2019 18:17:55 +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 06BA5810DD for ; Thu, 6 Jun 2019 18:17:54 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559845066; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=FSHXTosVbB6ThhfZtXN5cIPx5a5MHuKzM63Xok9+vK6+16TcCIlQnhEZxB4FlxCfNocC/ngkj26lo vZXK3vPCrC8thvrW1xS0sw6RIfhG6d6Hv47fYGhOz5O/uoTaR2P9LbrHX3eWVkDOJ198IYwG6JX4AJ C+heiB+pgroMmKGNsoLgixO+rQCnYRQMtlXWK4cqWAjaoGJFc4FBfKNLbyG+FR/9fTg1oNYhrGvK3p v0dSQlvEDhdQm/Ptd1LkGJ2SDNA+oqV9ItA3SaX96Wlen0KqLRF219RF1zIFQIxdzJWdzppKdd4Y89 /BwDNs/LeccdyO5tHDI40TOUQ8vVePw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=2yHMGr4W160b5Lgt6RSkOzDQS277qAlHTcDCahEo6RU=; b=EPr2Qnl2ECJUWvWeGs/doosJIoGzbxJ9bMBMk0TrJBJtUZIvWZjPf+K3Und7pvJ/Pxdelca1nAbe2 fYEijNXgTxk2LAZEHY0/wmptsKn+y298hkYh9RuQCyf7QkKLjk7SwDKDW5s8wBP+XWS8Rua1C4EVD4 FLugK85W8vGVkdRQiJM8b+Ho4HfrwIC+qCiUwkgNTy7Uw8C1E9GKUPNaJhkg/FQ/GL6xYzVqtbwFb8 2R1U92TwE1ehFdZSEFbire9OiPOKllye0bxZwhNNdKp3RwOoq8sQbIYUzD2o6C3mpAkcvPvSY7joG3 jWCqopHoWB8c1FNUWd6aIybh0vUkzcQ== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=2yHMGr4W160b5Lgt6RSkOzDQS277qAlHTcDCahEo6RU=; b=tPVQbyd1Gwy9Al2YrTvRlPlWOoZDqvEjTj7V/tLEX5AJ+dEs0NfzaRdjZcHTrEa8dXZg0i0W9gfrw WIThkNriy0CkSr/ZL9k/6lXWX33XX0D/2N18wHiGZqV7LKXm7aXX27BEMJBxC8raqbtPtwSeqe+kAv THjG1FJ1tWCEA98y+tMueDYEHDBhHse210/GgdU4UtKfSufOyCZKunMXyhUk6SONdHWEVzjn4YjXRf r1CRpwg8pFhDheBlOktmU2u5FllftAts8OCoSwLDZWYkDkXssrC+lUFLvyyykrM1G43rg31+XvMuYA zzfLdXZfguC1LHCp77jRdbqh/L9SmrA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 6018dc57-8887-11e9-85c6-c97e5c048ed3 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.eu.mailhop.org (Halon) with ESMTPSA id 6018dc57-8887-11e9-85c6-c97e5c048ed3; Thu, 06 Jun 2019 18:17:44 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x56IHg2S068975; Thu, 6 Jun 2019 12:17:42 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: DTrace SDT probes in kernel module =?windows-1251?Q?=97?= how to? From: Ian Lepore To: lev@FreeBSD.org, Alan Somers Cc: "freebsd-hackers@freebsd.org" Date: Thu, 06 Jun 2019 12:17:42 -0600 In-Reply-To: <156127070.20190606204849@serebryakov.spb.ru> References: <234087607.20190606204312@serebryakov.spb.ru> <156127070.20190606204849@serebryakov.spb.ru> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 06BA5810DD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.985,0]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 18:17:56 -0000 On Thu, 2019-06-06 at 20:48 +0300, Lev Serebryakov wrote: > Hello Alan, > > Thursday, June 6, 2019, 8:45:38 PM, you wrote: > > > How are you building the module? Typing "make" in > > sys/modules/whatever doesn't build the dtrace probes. Presumably > > that > > This one, yes. > > > could be fixed, but I've never tried. However, if you do a full > > "make > > buildkernel" then you will get dtrace probes. > > Oh, it is sooo slow :-( > make buildkernel -DNO_CLEAN takes like 9 seconds on my machine. -- Ian From owner-freebsd-hackers@freebsd.org Thu Jun 6 18:40:23 2019 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 5966215BCA5A for ; Thu, 6 Jun 2019 18:40:23 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D6EBF82DEA; Thu, 6 Jun 2019 18:40:21 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id YxGZh33TTo7SQYxGbhciGL; Thu, 06 Jun 2019 12:37:38 -0600 X-Authority-Analysis: v=2.3 cv=Go88BX9C c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=dq6fvYVFJ5YA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=TZ3jIaUWbIl67-U2D-wA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from android-9b917f0ce39da6e6.esitwifi.local (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id BA1AC67F; Thu, 6 Jun 2019 11:37:34 -0700 (PDT) Date: Thu, 06 Jun 2019 11:15:04 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <234087607.20190606204312@serebryakov.spb.ru> References: <234087607.20190606204312@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: =?UTF-8?Q?Re=3A_DTrace_SDT_probes_in_kernel_module_=E2=80=94_how_to=3F?= To: lev@FreeBSD.org, Lev Serebryakov , freebsd-hackers@freebsd.org From: Cy Schubert Message-ID: <55C981A2-A580-4FE5-9CB7-CB47D5705415@cschubert.com> X-CMAE-Envelope: MS4wfH1CrFq8uOU/HQqyc+oXMyO9fhGj7U/YFRfLzjoJNEp8gPgLG3+6gW1vFstV/dHT4nprGX2io/L3NPnJMImZCERuQeNJB9/WNWpylX08dl2rkoOoqjvY IAcjQx4ePOMCOhxx35NaAUHtWxv/ktex/SjV5f6tIYbadoecVgITkrCDa/kNcd5MLXpE79O2mDjoj9xW4cIYNUeJElmKSRg9kSM= X-Rspamd-Queue-Id: D6EBF82DEA X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.58 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11,233.154.66.70.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[139.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.39)[ip: (-6.05), ipnet: 64.59.128.0/20(-3.29), asn: 6327(-2.54), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 18:40:23 -0000 On June 6, 2019 10:43:12 AM PDT, Lev Serebryakov wrote: >Hello Freebsd-hackers, > >What should I do to add SDT probes into kernel module=2E I've tried to >add simple > >DTRACE_PROBE1(module__name, type, value); > >to source code=2E No errors, no probes after module load=2E I've added >WITH_CTF=3D1 to make > command line=2E Warnings from ctfmerge, no probes after module load=2E > >What is proper way to add SDT probes to module and how should I build >it? You'll need to include sdt=2Eh=2E You can see what is done and what I've a= dded to ipfilter, which manages to indirectly include sdt=2Eh through other= headers=2E Juxtaposed to this discussion, I'm hoping to implement USDT into mountd an= d a few other places before next BSDCan=2E amd64 works=2E i386 is borked=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-freebsd-hackers@freebsd.org Thu Jun 6 21:37:37 2019 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 514F515C0F96 for ; Thu, 6 Jun 2019 21:37:37 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B02D78921D for ; Thu, 6 Jun 2019 21:37:34 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-ed1-x544.google.com with SMTP id p26so5412273edr.2 for ; Thu, 06 Jun 2019 14:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8ZsJ8Ed2PrEtoVKYMVSO8CevjX9EPLC3SZHCLD59Fi0=; b=roAF3F9sjJn0iyT8ImJcsyT4XtEbWJXqysnUnR49cQ2l5Ls44c3eWE0Gg1j0lodeuS id/l3xU5OYLwQzNi+4Kg0WCbOSo+rKJToE9XeuMS0ses2YDdpQDfNdXHYFOONcN8ryGj ZFgyiaPVkk6cmzkSiBAb3D4FZlg7gpYoF3kYylRfTB2+6P6DjbNJPckdNP9wlk9AJUwv h2yzlH/Qg4125+uaJXV3XqTeQxm9J4hGsR+BoR3nj7Yqms6J0FkBDhr2m2c8qyhLkdsx vO3PBx3ILNXzQJkxACbvtUWmZik1MzV6zJoV/tZEssLSlHsf4lqCIJor7gWKRqcfzUm8 RTVA== 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=8ZsJ8Ed2PrEtoVKYMVSO8CevjX9EPLC3SZHCLD59Fi0=; b=gjjyBj0ROBbVt3yXb6llGzbxqkxySuFkEUJ7CYo7ftUNVkUOqjOqVs4uloBMep6Bki DuwdLtvPxjMy67fX4063uKBbBpdjdqxy0jRiimIxu/wljsugoOQ35pzdEAp+Rpkfhn4p ytUM7q17kc+vnfIcKXzmFALJ1McUt5FyO8KkysOKH5yRsE0yrApMxQZHIQeipk+b8D/q SINWDanEIfqKpjIWAQCNPz81h26Q6r3MDVZghNZk5y3FBAjuqfzSKe2lRssctMfgtSen +8XFPXu0zegJmE/hRXGmzjhw/YEztr8lFNvQGGFV2zyGXyJhysJn3AIRC2p6Y0by4q/J xYTA== X-Gm-Message-State: APjAAAWpzFkP+J7iG/Jbn2As8eSUhJiJQG89RAFGSiW2oQbv8GZWPBg9 HWi3DcQF+4AvTFaXYvxWhOYwFX6/ZKFyrLbtlKHGjQ== X-Google-Smtp-Source: APXvYqzUl4Jo9uPE47aC1hOfHh2tOK7LYiYYdekQ9E9wiOVgGhi/L7wG/eLJDf3/ldLSwTx370VfNLQqr7EDFtr7pOo= X-Received: by 2002:a50:b665:: with SMTP id c34mr55274743ede.148.1559857053380; Thu, 06 Jun 2019 14:37:33 -0700 (PDT) MIME-Version: 1.0 References: <20190606145016.GA4116@raichu> In-Reply-To: <20190606145016.GA4116@raichu> From: Mark Saad Date: Thu, 6 Jun 2019 17:37:22 -0400 Message-ID: Subject: Re: Kernel panic on 12-STABLE-r348203 amd64 E5-2690v4 with Cluster on die mode enabled To: Mark Johnston Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B02D78921D X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=roAF3F9s X-Spamd-Result: default: False [-4.28 / 15.00]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx5.googlemail.com,aspmx4.googlemail.com,aspmx3.googlemail.com,alt2.aspmx.l.google.com,aspmx2.googlemail.com]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; IP_SCORE(-1.01)[ip: (-0.36), ipnet: 2a00:1450::/32(-2.32), asn: 15169(-2.29), country: US(-0.06)]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[longcount.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 21:37:37 -0000 Mark I am stumped , I realized I had the stock bios settings, and I just applied my standard config and it just worked. I am not 100% sure what issue was. Went back and turned on COD mode after and it booted fine. I even turned on x2apic for fun; it booted but the mfid driver went nuts and would not load correctly. So when I have more time I am going to find a un-touched r630 dump the bios options and reload it and see what happens. On Thu, Jun 6, 2019 at 10:50 AM Mark Johnston wrote: > > On Thu, Jun 06, 2019 at 10:43:26AM -0400, Mark Saad wrote: > > All > > I posed this yesterday but; I am not sure what happened. Here is the > > short version. > > I received two new Dell r630's each with a E5-2690 v4 . The E5-2690 v4 > > has 14 Cores in two packages on the one chip. I don't remember the > > exact topology however as a result the BIOS supports the NUMA / Memory > > mode know as Cluster on Die were each package on the one chip shows up > > as its own NUMA domain. The issue is this when enabled the box boots > > 12-RELEASE a-ok. When I rebuilt 12.0-STABLE-r348203 it would panic > > early in the boot process. > > Here is a dump of the console > > =============================== > > Loading kernel... > > /boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80 > > syms=[0x8+0x1778e8+0x8 / > > +0x194f1d] > > Loading configured modules... > > /boot/kernel/ipmi.ko size 0x11e10 at 0x2645000 > > loading required module 'smbus' > > /boot/kernel/smbus.ko size 0x2ef0 at 0x2657000 > > /boot/entropy size=0x1000 > > /boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000 > > ---<>---c_hmodule 'smbus' > > Copyright (c) 1992-2019 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 12.0-STABLE r348693 GENERIC amd64 > > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on > > LLVM 8.0.0) > > panic: UMA zone "UMA Zones": Increase vm.boot_pages > > cpuid = 0 > > time = 1 > > KDB: stack backtrace: > > #0 0xffffffff80c16df7 at ??+0 > > #1 0xffffffff80bcaccd at ??+0 > > #2 0xffffffff80bcab23 at ??+0 > > #3 0xffffffff80f0b03c at ??+0 > > #4 0xffffffff80f08d8d at ??+0 > > #5 0xffffffff80f0bb3d at ??+0 > > #6 0xffffffff80f0b301 at ??+0 > > #7 0xffffffff80f0b3d1 at ??+0 > > #8 0xffffffff80f066c4 at ??+0 > > #9 0xffffffff80f0543f at ??+0 > > #10 0xffffffff80f23aef at ??+0 > > #11 0xffffffff80f1133b at ??+0 > > #12 0xffffffff80b619c8 at ??+0 > > #13 0xffffffff8036a02c at ??+0 > > Uptime: 1s > > > > =============================== > > > > The only solution was to mess with vm.boot_pages . I got it booted > > with 128 as the value. > > Also to be clear if I switched back to Home Snoop, Early Snoop the box > > is fine. Its only > > unhappy whit Cluster on Die and 12.0-STABLE . > > > > Anyone know whats going on ? > > Could you build a kernel with "options DIAGNOSTIC" configured and boot > in verbose mode? The kernel should print its boot page allocations to > the console. Then, compare the output with a boot with cluster on die > disabled. -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Fri Jun 7 02:30:19 2019 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 75EA615C5FBB for ; Fri, 7 Jun 2019 02:30:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DEFEC9076F for ; Fri, 7 Jun 2019 02:30:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id i34so626829qta.6 for ; Thu, 06 Jun 2019 19:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uLdyiyBlYBekeZawK7rAP3/1Yv1JwHad/ntyCSbP5uI=; b=OiRTY0Pb2PDZ6/9Wjxs7zjfI6CCMWq/OhhGhbC8CpsjSbN538KEwGjYYQTBK6u5q82 w9xyFzy0UT+WCF4t6pmky1u9aOKlI2A4cfnu0by6CwW+RBIseL070xWiW+zVm3nXD3Ln BJvR1eCdgoxFPprM7I71PxAxSp0R0u2iNq8hA3sh+U3iMg7loiXeqC2q4zO0TrK6GPdf HUbNFqy8sbs7Qtzz24yvFrPeibWgKJJ9HlwZY2yIV0OCqAxBAmumByxHILCJAFPK5a3L ZuTwaFpGUgV7AHe0G0/AgDMOBLLaToeT8aUl16PU765R1u9beaWxpRuLh8N05w1LwmJs ffiw== 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=uLdyiyBlYBekeZawK7rAP3/1Yv1JwHad/ntyCSbP5uI=; b=hPLQSBEfqaIvxG84eKbnnz0uIULwluGi60Rc3qHOilEl2UZYdf6N6SGmkbVWpk6PHG NKnqPO7cCntyViPhEpJ/PbWTGz21abqqw2i69XAO1SEIts0coDvayKkA3UJxRifBNgNu EWRCwzJhDl8joSldWA1UqWONcPqbffMLVj0ZvPnBrRKA3JTYK94FOgsjvTAzB+Bh+ZiL kvz1Vp45k3gq77uhpgPmH4OY3FoZgXFItiu2FdBr7ZY6YXZwdEWopLikHK7IAdh19d8j 48unSI8l9HQrFaEF38ZLrtwqscs3Ld+O8FHDlvF8C1Zhvi5G4nmkEWHXI5d+e/11WtJA A6pg== X-Gm-Message-State: APjAAAUBhyFBiIimWCh9qMsC4mwWcNl9hfG9RaXrCIPfsMxa0CUDMsJv eMER7tRQ4TX9YlZWil560AdCWmIwIfc6wgVxXznsVyV2yutoLQ== X-Google-Smtp-Source: APXvYqwY3AGyFq+SOp5ng82q1cnGtdmsXGQ0wW6QxABTSffMtS59pVXY6eg13uaPXzTJminRGdazaaMfkZaFt5GbWaM= X-Received: by 2002:a0c:b66f:: with SMTP id q47mr41933771qvf.102.1559874616955; Thu, 06 Jun 2019 19:30:16 -0700 (PDT) MIME-Version: 1.0 References: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com> <74732E11-5735-46CB-AA54-2B49F30CB10A@transactionware.com> In-Reply-To: From: Warner Losh Date: Thu, 6 Jun 2019 20:30:06 -0600 Message-ID: Subject: Re: UEFI boot1 vs. GPT bootme/bootonce flags To: Jan Martin Mikkelsen Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: DEFEC9076F X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=OiRTY0Pb X-Spamd-Result: default: False [-5.96 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.961,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[ALT1.aspmx.l.google.com,aspmx.l.google.com,ALT2.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.99)[ip: (-9.39), ipnet: 2607:f8b0::/32(-3.22), asn: 15169(-2.30), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 02:30:19 -0000 On Tue, Jun 4, 2019 at 3:03 PM Warner Losh wrote: > > > On Tue, Jun 4, 2019 at 9:40 AM Jan Martin Mikkelsen < > janm@transactionware.com> wrote: > >> >> On 4 Jun 2019, at 16:10, Warner Losh wrote: >> >> >> On Tue, Jun 4, 2019 at 1:06 AM Jan Martin Mikkelsen < >> janm@transactionware.com> wrote: >> >>> Hi, >>> >>> The UEFI boot1 loader does not support the GPT >>> bootme/bootonce/bootfailed flags for selecting which partition to boot. >>> >>> Is there a reason for this? >>> >> >> Yes. There's three. >> >> First, UEFI provides no way to get to these flags via their block >> interfaces. Second, the block interfaces are independent, so there was n= o >> easy way to know w/o jumping through a bunch of hoops. Third, the UEFI >> Boot Manager Protocol was championed as being the one-true way to select= a >> boot partition. It's significantly more flexible and reliable than >> rewriting the partition table from time to time. >> >> However, there's significant drawbacks to the UEFI scheme. Vendors suck >> at not mucking up the UEFI Boot Manager Protocol (I'm looking at you >> SuperMicro). And the trend in embedded where UEFI has a foothold has bee= n >> to move away from writable variables at all... Finally, the UEFI Boot >> Protocol assumes a host + media. There's no media-agnostic way to produc= e >> an image with multiple partitions that you ping-pong between (say a >> recovery USB stick that moves from system to system). >> >> So against my better judgement, I've been working on making gptboot.efi. >> It's not as terrible as I thought it would be, but it shows another issu= e: >> loader.efi and boot1.efi process all the partitions they find, but gptbo= ot >> just does one disk's worth and stops when it successfully boots somethin= g: >> this has required a restructuring of the boot1 code that I started with = to >> rearrange the loops used to find things. An no, the gptboot.efi will not >> support ZFS, which has its own way to do this outside of UEFI Boot Manag= er >> Protocol. >> >> If you don't want to wait, there's now a mechanism for loading loader >> environment variables from a file called \efi\freebsd\loader.env in the = ESP >> that can accomplish much the same thing. >> >> >> OK. >> >> I am looking at similar situations: Supermicro servers and various >> flavours of embedded systems. For some of the newer embedded systems UEF= I >> is the necessary approach. I am not at all interested in writable variab= les >> in firmware. I=E2=80=99m also not interested in booting from ZFS. >> >> My question was because I have been reading the efi/boot1 source code an= d >> deciding what to do to duplicate the bootme/bootonce functionality. That >> there were lots of hoops to jump through was clear. However, I was comin= g >> to the conclusion that boot1.efi needed to duplicate the functionality o= f >> gptboot, and was getting ready to implement. >> >> How far have you gone with your gptboot.efi? What=E2=80=99s missing >> > > I have it mostly written at this point. Nailing down going back and forth > between handles and different partition numbers. > Update to the latest and apply https://reviews.freebsd.org/D20547 and this will create a gptboot.efi you can test. It works for me for the first few cases I've tested. Warner