From owner-freebsd-hackers@freebsd.org Sun Jul 12 10:22:25 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D1FA835EE22 for ; Sun, 12 Jul 2020 10:22:25 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B4NBS5f4Vz4NKm for ; Sun, 12 Jul 2020 10:22:24 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: by mail-il1-x136.google.com with SMTP id h16so8745327ilj.11 for ; Sun, 12 Jul 2020 03:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=udt2co6tmE6FYSHCixrqVImzqrVJfzRHgZwIF3KLmm0=; b=Ka1OtuCESbD0GPtlIgnL4ktxh0zBV1KtcQsgTxDVhWKF4T+AEc2EvkWn0jFUJk5XSk wdOR5ixRSexhpqQb7afLsWyl4sCtlsgDwL8YgFwowVC/Q5CVLn4RybtJOQ/tAoPq4Y8G yhslcUCKEunNfXmZz+thg9Y9KJZB7scKwxfzErQ1UvK2G/UqSjtmUZYYUlfAXxYSOakT U9k4p60hEdHmqBWco7SYPaws5yxPT2rxtrY2pnqTa2UF/I/WApNicVIVQDJEagB2lxEh NtGMOK9Ra+nIZCFwkU0txf0nzjLmUz8ypfCG7Rf8UW5nKcFOz2QnGccXKMqpvdmDQVdN G+TQ== 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=udt2co6tmE6FYSHCixrqVImzqrVJfzRHgZwIF3KLmm0=; b=QUEbTNP5UxAcpZNI/+6FyBn9FpjjgkLJA0/fXBKC/qv5NU9AWqEhLGn8epBTMQOgUW yCNxFMKNve2/DBswnYXvn5LTXGjl7gO9gu0mm3zXEBizWDzSnqQ/aZ0MRS7wcBNetglP FQnjKjij3wo7T3dX7WfqgZuFzvBQwuuBVciBG/qtRPNixPwiLaNbLQWOExtRMC1un+AT 2v3/Ryx0MwRBkng5crlE0InhCReX51YzaCU++7K/IXKASJvteG2Zo+FLe1Rs8uUe4Pma KDdcfgOGozsoBnQOsgsAKaYYX61aLtxROMxOtH60H7oFLshI6pHAHMeKkDXhebOz4s1f XRlg== X-Gm-Message-State: AOAM530D+3oLi2kBAs0fGTx7brH5HTXnWvCnW1u96FLtCku+Z3s5W2GF BeIt1tFRjMYhLWJj0JySb7+2aocax63O/b0veDdeRU0t X-Google-Smtp-Source: ABdhPJxb/lQHtxDNpIZEGFvrS/avU8Hy++8lapXK7PEaugzrRC53+wBqk1VN+R+BJUlYgmserJPM+j6fJAuapHjEB5s= X-Received: by 2002:a92:dc0f:: with SMTP id t15mr53891350iln.218.1594549343065; Sun, 12 Jul 2020 03:22:23 -0700 (PDT) MIME-Version: 1.0 References: <906D4A4A-95E1-4AB3-9D64-44DBC3987E51@longcount.org> In-Reply-To: <906D4A4A-95E1-4AB3-9D64-44DBC3987E51@longcount.org> From: Sujit K M Date: Sun, 12 Jul 2020 15:52:11 +0530 Message-ID: Subject: Re: [talk] LACP debug question To: Mark Saad Cc: Hackers freeBSD , NYCBUG Talk X-Rspamd-Queue-Id: 4B4NBS5f4Vz4NKm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Ka1OtuCE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kmsujit@gmail.com designates 2607:f8b0:4864:20::136 as permitted sender) smtp.mailfrom=kmsujit@gmail.com X-Spamd-Result: default: False [-3.02 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.001]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.01)[-1.012]; URI_COUNT_ODD(1.00)[1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::136:from]; NEURAL_HAM_SHORT(-1.00)[-1.002]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 10:22:25 -0000 On Sat, Jul 11, 2020, 10:03 PM Mark Saad wrote: > All > This is a repost from net . I am looking for someone who can help me > better understand this LACP disconnect that I am seeing on 12-stable . Th= e > server is a router with Solarflare nics attached to a Pair of arista 7050= =E2=80=99s > . > > Can you help me understand what I am looking at here. I enabled the lacp > debug until I finally saw the issue I noted before. Due to some log > rotation part of the message is clipped. > Here is a part the full thing is on patebin https://pastebin.com/BGtbxcBf > > > 30 2020-07-09T15:47:04.145885+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: > lacp_sm_rx_timer: CURRENT -> EXPIRED > 31 2020-07-09T15:47:04.145895+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: > Interface stopped DISTRIBUTING, possible flapping > 32 2020-07-09T15:47:04.145895+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: > collecting enabled > https://en.m.wikipedia.org/wiki/Link_aggregation#:~:text=3DWithin%20the%20I= EEE%20specification%2C%20the,form%20a%20single%20logical%20channel . The expired and stopped distribution might beat the purpose of LACP. > > 33 2020-07-09T15:47:04.145896+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: > disable distributing on aggregator > [(8000,00-0F-53-69-7C-20,00F2,0000,0000),(8000,46-4C-A8-68-13-47,006A,000= 0,0000)], > nports 2 -> 1 > 34 2020-07-09T15:47:04.145911+00:00 ch1-c104-sdn02-mgmt kernel: sfxge1: > lacp_select_tx_port: waiting transit > 35 2020-07-09T15:47:04.145912+00:00 ch1-c104-sdn02-mgmt kernel: marker > transmit, port=3D6, sys=3D00:0f:53:69:7c:20, id=3D487 > 36 2020-07-09T15:47:04.145912+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: > sfxge1: lacp_select_tx_port: waiting transit > 37 2020-07-09T15:47:04.145913+00:00 ch1-c104-sdn02-mgmt kernel: marker > transmit, port=3D5, sys=3D00:0f:53:69:7c:20, id=3D487 > 38 2020-07-09T15:47:04.145914+00:00 ch1-c104-sdn02-mgmt kernel: marker > response, port=3D6, sys=3D00:0f:53:69:7c:20, id=3D487 > 39 2020-07-09T15:47:04.145914+00:00 ch1-c104-sdn02-mgmt kernel: > [(8000,00-0F-53-69-7C-20,00F2,0000,0000),(8000,46-4C-A8-68-13-47,006A,000= 0,0000)], > speed=3D10000000000, nports=3D1 > 40 2020-07-09T15:47:04.145922+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: > lacp_select_tx_port: waiting transit > 41 2020-07-09T15:47:04.145923+00:00 ch1-c104-sdn02-mgmt kernel: > lacp_select_tx_port: waiting transit > 42 2020-07-09T15:47:04.145923+00:00 ch1-c104-sdn02-mgmt kernel: active > aggregator not changed > 43 2020-07-09T15:47:04.145924+00:00 ch1-c104-sdn02-mgmt kernel: > lacp_select_tx_port: waiting transit > 44 2020-07-09T15:47:04.145925+00:00 ch1-c104-sdn02-mgmt kernel: marker > response, port=3D5, sys=3D00:0f:53:69:7c:20, id=3D487 > 45 2020-07-09T15:47:04.145925+00:00 ch1-c104-sdn02-mgmt kernel: > lacp_select_tx_port: waiting transit > 46 2020-07-09T15:47:04.145926+00:00 ch1-c104-sdn02-mgmt kernel: new > [(8000,00-0F-53-69-7C-20,00F2,0000,0000),(8000,46-4C-A8-68-13-47,006A,000= 0,0000)] > 47 2020-07-09T15:47:04.145926+00:00 ch1-c104-sdn02-mgmt kernel: Set table > 1 with 1 ports > 48 2020-07-09T15:47:04.145927+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: > mux_state 4 -> 3 > 49 2020-07-09T15:47:04.145928+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: > collecting disabled > 50 2020-07-09T15:47:04.145930+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: > mux_state 3 -> 2 > 51 2020-07-09T15:47:04.145931+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: > lacpdu transmit > 52 2020-07-09T15:47:04.145931+00:00 ch1-c104-sdn02-mgmt kernel: > actor=3D(8000,00-0F-53-69-7C-20,00F2,8000,0005) > 53 2020-07-09T15:47:04.145932+00:00 ch1-c104-sdn02-mgmt kernel: > actor.state=3D8d > 54 2020-07-09T15:47:04.145932+00:00 ch1-c104-sdn02-mgmt kernel: > partner=3D(8000,46-4C-A8-68-13-47,006A,8000,0006) > 55 2020-07-09T15:47:04.145933+00:00 ch1-c104-sdn02-mgmt kernel: > partner.state=3D37 > 56 2020-07-09T15:47:04.145935+00:00 ch1-c104-sdn02-mgmt kernel: maxdelay= =3D0 > 57 2020-07-09T15:47:04.145937+00:00 ch1-c104-sdn02-mgmt kernel: queue > flush complete > --- > Mark Saad | nonesuch@longcount.org > _______________________________________________ > talk mailing list > talk@lists.nycbug.org > http://lists.nycbug.org:8080/mailman/listinfo/talk > From owner-freebsd-hackers@freebsd.org Sun Jul 12 13:49:36 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DE60C364024 for ; Sun, 12 Jul 2020 13:49:36 +0000 (UTC) (envelope-from ekraju@gmail.com) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B4SnW6XVDz4Yn7 for ; Sun, 12 Jul 2020 13:49:35 +0000 (UTC) (envelope-from ekraju@gmail.com) Received: by mail-yb1-xb2e.google.com with SMTP id l19so5139486ybl.1 for ; Sun, 12 Jul 2020 06:49:35 -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=UQZxCTyY0M5dPqw1rcztyS7Pj+YGzrjHnjweb9Kof/k=; b=I01PsEqNPyfo+Eg9I4FczGs5zs1RnaV3BMCihiOtjdyz2lP2ctcQ8Oj7DL8KE2mXmU 9Stkqpzxn1eeKoVxoYRFA2iN1z2CcH9DfzhfSDcE2k9IGSUUvpv3/LNU9p1N5WqD2u1i SuGnfjkeexjr9oJgD90rLF4z9kgHXRLIBLE9sNRXwGFS+Fz3DsQF93bpZr6EFxNdpQNN lJZLr5biL6WuIsMJfyHsmnHxqJH6lpbIFjPPUsmh2GwOSO+bajFfeSqxKZf+5I4P87yq CPasrplDjTZ7OT9oAzixODMvNZFR8hE5M0RQnOYUlEkUVoDuLE5Pp1OnQckgwcIKkYMI /1KA== 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=UQZxCTyY0M5dPqw1rcztyS7Pj+YGzrjHnjweb9Kof/k=; b=kX6VCzlUyer2nShLgaOwx+XUMzrk/L4rwmZfF7ULHsyylq3xDyVlk1mMw3UjvHVcDi u4V3IVorVp5z0k9E4Gm9tGS2yviErBvB61+OpAygrZU03NPzeW20bMy++zBRYObQNshH M7oMe+TxQoQuudX9LDOJpcMXCrrAsYEF3i3udN5xEMuoOdtR3ZO24tvr0oyIXw1yvqOw +QVO6jNEj7j7jdRVC0e8L2RhnvlCkoEFA7rJgc++r8Mzsq3I/Mn+N6GQLX9PBpRCkuN5 a4RL9pXX7q55UlUXXOFZ9tinVWh0jeJmjCON6G5cI+HoYIquAvHEOaNYLC3k7OC6dS5U lInw== X-Gm-Message-State: AOAM533rRcSU9Zmyl0hMNe3oREXf418JQ1IlwHRlE3j/uXQkafntTRMk WYt5LI++GpdhDrR1rq4gyeGSZehnGwnf8gKh/vGoSUL/5YQ= X-Google-Smtp-Source: ABdhPJyJz8SP1pBvqhRR25LGZq8aV8PmxnwEKYpkdmeV2O7jP0lgo1WqgTftUdxcddGefM5bi2VAzo4nv1CHltwxNXo= X-Received: by 2002:a25:8205:: with SMTP id q5mr18625544ybk.228.1594561774566; Sun, 12 Jul 2020 06:49:34 -0700 (PDT) MIME-Version: 1.0 From: Krishnamraju Eraparaju Date: Sun, 12 Jul 2020 19:19:23 +0530 Message-ID: Subject: multi queueing in FreeBSD block layer To: FreeBSD Hackers X-Rspamd-Queue-Id: 4B4SnW6XVDz4Yn7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=I01PsEqN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ekraju@gmail.com designates 2607:f8b0:4864:20::b2e as permitted sender) smtp.mailfrom=ekraju@gmail.com X-Spamd-Result: default: False [-3.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.949]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.01)[-1.007]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2e:from]; NEURAL_HAM_SHORT(-0.21)[-0.215]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 13:49:36 -0000 Hi, Does the FreeBSD block layer has support for multi-queue(or similar to exploit parallelism in software), like blk_mq in Linux? Thanks. ekraju. From owner-freebsd-hackers@freebsd.org Sun Jul 12 15:58:27 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B8E14366BD4 for ; Sun, 12 Jul 2020 15:58:27 +0000 (UTC) (envelope-from nonesuch@longcount.org) 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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B4WfB4Fd4z3Rc0 for ; Sun, 12 Jul 2020 15:58:26 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qt1-x831.google.com with SMTP id x62so8222364qtd.3 for ; Sun, 12 Jul 2020 08:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=MfuI6TRieYmMZsyYMPDh6t9jZ9QRD20xPkmY79C1FTI=; b=eNsk5otijU2bY8ucw6JcDEdXZUqrXevHmQ26iSnpIazXejvdqHhnglng9rTOmgphZY ixAvQQGsxdy5Nti+Dpp/dCR8kr9r/3pI1etklOasaejTJVY6yqZQAPmv2sf7z0gUbBLe Hys9FFvvVP3zkD0fWvICVr2HYHVNegKG6WP6M3bNrQ4Gs9CL9m8DT4wmE3ZoGmfyozNl GbXpRTqJxTfa3vMggKpaZTcEOq2wyjetf9iYiFAGCIIPsIT2BwTWeUI34EqiMg4fDxVc kzdbKNj+alqa8qN+swQkO6wUjxvXSaBsUYIcBr2qdwguJRdJ5ij8FyKNx/KnPSpxePub 8hWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=MfuI6TRieYmMZsyYMPDh6t9jZ9QRD20xPkmY79C1FTI=; b=JG+xoulY0YltyrzJfOZQFJwFGRttKcEdq/APT+rBfj5pHI6mOZjB+aQ5yjRIpJ0WVm cMKtRSa0St1ePEThIaqQ/BvxgYJZyU4mn3ya8LtINmthq7/PiJV6YS+Owoyc0dA/gXTD RuULVRlT4+Nl73rzk61YoOm6g5lDJtskOtjTW8QREeBLgwle6FH1dnb9xlZdqNQ1ASJS 7pjnDAufg16jEl9FXRsJRbUKuRVMif65gK38x643lpSsOQCTmGFN7UzN+/6wCvex9MMg aNFgywp5HUqL20UGA6n9kSVW6C3GmQnOTIjXVc99OcYAqD4l1CWMHgfXVqjo/A7j5Aip lp7Q== X-Gm-Message-State: AOAM533Iv8YsL2W98mt/1PXO5JNGM3qHCyfOZktkIv+m6yJYp9/2CHWx cN6BDXcnUUtRvNO908x+DPLoVw== X-Google-Smtp-Source: ABdhPJzNcFoFeWNWpPNAktmlHUBrYYu1vHmW7gPXFg7eKPjsnQ64r6XLsp3jFy8O/k5cLDRbSpXUKg== X-Received: by 2002:ac8:c7:: with SMTP id d7mr52197304qtg.235.1594569505384; Sun, 12 Jul 2020 08:58:25 -0700 (PDT) Received: from [192.168.1.31] (ool-457b63be.dyn.optonline.net. [69.123.99.190]) by smtp.gmail.com with ESMTPSA id o15sm15536918qko.67.2020.07.12.08.58.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jul 2020 08:58:24 -0700 (PDT) From: Mark Saad Mime-Version: 1.0 (1.0) Subject: Re: [talk] LACP debug question Date: Sun, 12 Jul 2020 11:58:23 -0400 Message-Id: References: Cc: Hackers freeBSD , NYCBUG Talk In-Reply-To: To: Sujit K M X-Mailer: iPhone Mail (17F80) X-Rspamd-Queue-Id: 4B4WfB4Fd4z3Rc0 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=eNsk5oti; dmarc=none; spf=none (mx1.freebsd.org: domain of nonesuch@longcount.org has no SPF policy when checking 2607:f8b0:4864:20::831) smtp.mailfrom=nonesuch@longcount.org X-Spamd-Result: default: False [-1.58 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; URI_COUNT_ODD(1.00)[7]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.03)[-1.032]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[69.123.99.190:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.811]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.94)[-0.939]; MIME_GOOD(-0.10)[multipart/alternative,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)[2607:f8b0:4864:20::831:from]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 15:58:27 -0000 Sujit I know that this is LACP debug . I am trying to understand the specific co= nditions that this LACP disconnect sequence is occurring. It=E2=80=99s a od= d thing, it=E2=80=99s happening during times of relatively low was tcp traff= ic . The router and is not highly loaded and I can=E2=80=99t find a reason w= hy this is occurring .=20 --- Mark Saad | nonesuch@longcount.org On Jul 12, 2020, at 6:22 AM, Sujit K M wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Sat, Jul 11, 2020, 10:03 PM Mark Saad wrote: >> All >> This is a repost from net . I am looking for someone who can help me be= tter understand this LACP disconnect that I am seeing on 12-stable . The ser= ver is a router with Solarflare nics attached to a Pair of arista 7050=E2=80= =99s .=20 >>=20 >> Can you help me understand what I am looking at here. I enabled the lacp d= ebug until I finally saw the issue I noted before. Due to some log rotation p= art of the message is clipped. >> Here is a part the full thing is on patebin https://pastebin.com/BGtbxcBf= >>=20 >>=20 >> 30 2020-07-09T15:47:04.145885+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: l= acp_sm_rx_timer: CURRENT -> EXPIRED >> 31 2020-07-09T15:47:04.145895+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: I= nterface stopped DISTRIBUTING, possible flapping >> 32 2020-07-09T15:47:04.145895+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: c= ollecting enabled >=20 >=20 > https://en.m.wikipedia.org/wiki/Link_aggregation#:~:text=3DWithin%20the%20= IEEE%20specification%2C%20the,form%20a%20single%20logical%20channel. >=20 > The expired and stopped distribution might beat the purpose of LACP. >>=20 >> 33 2020-07-09T15:47:04.145896+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: d= isable distributing on aggregator [(8000,00-0F-53-69-7C-20,00F2,0000,0000),(= 8000,46-4C-A8-68-13-47,006A,0000,0000)], nports 2 -> 1 >> 34 2020-07-09T15:47:04.145911+00:00 ch1-c104-sdn02-mgmt kernel: sfxge1: l= acp_select_tx_port: waiting transit >> 35 2020-07-09T15:47:04.145912+00:00 ch1-c104-sdn02-mgmt kernel: marker tr= ansmit, port=3D6, sys=3D00:0f:53:69:7c:20, id=3D487 >> 36 2020-07-09T15:47:04.145912+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: s= fxge1: lacp_select_tx_port: waiting transit >> 37 2020-07-09T15:47:04.145913+00:00 ch1-c104-sdn02-mgmt kernel: marker tr= ansmit, port=3D5, sys=3D00:0f:53:69:7c:20, id=3D487 >> 38 2020-07-09T15:47:04.145914+00:00 ch1-c104-sdn02-mgmt kernel: marker re= sponse, port=3D6, sys=3D00:0f:53:69:7c:20, id=3D487 >> 39 2020-07-09T15:47:04.145914+00:00 ch1-c104-sdn02-mgmt kernel: [(8000,00= -0F-53-69-7C-20,00F2,0000,0000),(8000,46-4C-A8-68-13-47,006A,0000,0000)], sp= eed=3D10000000000, nports=3D1 >> 40 2020-07-09T15:47:04.145922+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: l= acp_select_tx_port: waiting transit >> 41 2020-07-09T15:47:04.145923+00:00 ch1-c104-sdn02-mgmt kernel: lacp_sele= ct_tx_port: waiting transit >> 42 2020-07-09T15:47:04.145923+00:00 ch1-c104-sdn02-mgmt kernel: active ag= gregator not changed >> 43 2020-07-09T15:47:04.145924+00:00 ch1-c104-sdn02-mgmt kernel: lacp_sele= ct_tx_port: waiting transit >> 44 2020-07-09T15:47:04.145925+00:00 ch1-c104-sdn02-mgmt kernel: marker re= sponse, port=3D5, sys=3D00:0f:53:69:7c:20, id=3D487 >> 45 2020-07-09T15:47:04.145925+00:00 ch1-c104-sdn02-mgmt kernel: lacp_sele= ct_tx_port: waiting transit >> 46 2020-07-09T15:47:04.145926+00:00 ch1-c104-sdn02-mgmt kernel: new [(800= 0,00-0F-53-69-7C-20,00F2,0000,0000),(8000,46-4C-A8-68-13-47,006A,0000,0000)]= >> 47 2020-07-09T15:47:04.145926+00:00 ch1-c104-sdn02-mgmt kernel: Set table= 1 with 1 ports >> 48 2020-07-09T15:47:04.145927+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: m= ux_state 4 -> 3 >> 49 2020-07-09T15:47:04.145928+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: c= ollecting disabled >> 50 2020-07-09T15:47:04.145930+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: m= ux_state 3 -> 2 >> 51 2020-07-09T15:47:04.145931+00:00 ch1-c104-sdn02-mgmt kernel: sfxge0: l= acpdu transmit >> 52 2020-07-09T15:47:04.145931+00:00 ch1-c104-sdn02-mgmt kernel: actor=3D(= 8000,00-0F-53-69-7C-20,00F2,8000,0005) >> 53 2020-07-09T15:47:04.145932+00:00 ch1-c104-sdn02-mgmt kernel: actor.sta= te=3D8d >> 54 2020-07-09T15:47:04.145932+00:00 ch1-c104-sdn02-mgmt kernel: partner=3D= (8000,46-4C-A8-68-13-47,006A,8000,0006) >> 55 2020-07-09T15:47:04.145933+00:00 ch1-c104-sdn02-mgmt kernel: partner.s= tate=3D37 >> 56 2020-07-09T15:47:04.145935+00:00 ch1-c104-sdn02-mgmt kernel: maxdelay=3D= 0 >> 57 2020-07-09T15:47:04.145937+00:00 ch1-c104-sdn02-mgmt kernel: queue flu= sh complete >> --- >> Mark Saad | nonesuch@longcount.org >> _______________________________________________ >> talk mailing list >> talk@lists.nycbug.org >> http://lists.nycbug.org:8080/mailman/listinfo/talk From owner-freebsd-hackers@freebsd.org Sun Jul 12 18:49:58 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2ED4436B04F for ; Sun, 12 Jul 2020 18:49:58 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4bS50t0qz3cM7 for ; Sun, 12 Jul 2020 18:49:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 06CIneWS047061 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 12 Jul 2020 18:49:44 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 06CInZoT035645 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 13 Jul 2020 01:49:35 +0700 (+07) (envelope-from eugen@grosbein.net) To: Freebsd hackers list From: Eugene Grosbein Subject: fsync(2) Message-ID: <0cdc3315-0213-8522-c8d6-695c2ee02923@grosbein.net> Date: Mon, 13 Jul 2020 01:49:22 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4B4bS50t0qz3cM7 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [1.50 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.90)[0.896]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_MEDIUM(0.31)[0.310]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[empty SPF record]; NEURAL_SPAM_LONG(0.39)[0.394]; 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_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 18:49:58 -0000 Hi! Assume we have parent process that created a file and keeps it open not writing anything there. The parent spawns a child passing file name and the child opens it, fills it with data and exits without fsync()'ing the file. In case of UFS there is upto 30 seconds time gap when file size is not updated, so if crash occurs, the file ends up empty. The question: will fsync() in parent work for such still open file descriptor? From owner-freebsd-hackers@freebsd.org Sun Jul 12 19:05:27 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A49936B9A4 for ; Sun, 12 Jul 2020 19:05:27 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4bnx6kwkz3dMT for ; Sun, 12 Jul 2020 19:05:25 +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 06CJ5HhF025028 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 12 Jul 2020 22:05:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 06CJ5HhF025028 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 06CJ5Hpe025026; Sun, 12 Jul 2020 22:05:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 12 Jul 2020 22:05:17 +0300 From: Konstantin Belousov To: Eugene Grosbein Cc: Freebsd hackers list Subject: Re: fsync(2) Message-ID: <20200712190517.GA44314@kib.kiev.ua> References: <0cdc3315-0213-8522-c8d6-695c2ee02923@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0cdc3315-0213-8522-c8d6-695c2ee02923@grosbein.net> 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4B4bnx6kwkz3dMT X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [1.28 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.29)[0.295]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(0.53)[0.525]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.46)[0.460]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 19:05:27 -0000 On Mon, Jul 13, 2020 at 01:49:22AM +0700, Eugene Grosbein wrote: > Hi! > > Assume we have parent process that created a file and keeps it open not writing anything there. > The parent spawns a child passing file name and the child opens it, > fills it with data and exits without fsync()'ing the file. > > In case of UFS there is upto 30 seconds time gap when file size is not updated, > so if crash occurs, the file ends up empty. > > The question: will fsync() in parent work for such still open file descriptor? fsync() syncs the vnode, not the file or file descriptor. So fsync() on any file descriptor referencing the same vnode, is enough to ensure that the data is written to the underlying volume. From owner-freebsd-hackers@freebsd.org Sun Jul 12 19:55:58 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EFD6636CAB7 for ; Sun, 12 Jul 2020 19:55:58 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4cwG11qWz3y1H for ; Sun, 12 Jul 2020 19:55:57 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 06CJtp42048131 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Jul 2020 19:55:53 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: kostikbel@gmail.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 06CJtioR036077 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Jul 2020 02:55:45 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: fsync(2) To: Konstantin Belousov References: <0cdc3315-0213-8522-c8d6-695c2ee02923@grosbein.net> <20200712190517.GA44314@kib.kiev.ua> Cc: Freebsd hackers list From: Eugene Grosbein Message-ID: <12fb648f-8c37-be9b-f18a-5dc2ec9a09c9@grosbein.net> Date: Mon, 13 Jul 2020 02:55:32 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20200712190517.GA44314@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains * 0.0 NICE_REPLY_A Looks like a legit reply (A) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4B4cwG11qWz3y1H X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [0.31 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.12)[0.120]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_MEDIUM(0.17)[0.171]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[empty SPF record]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.12)[0.121]; FREEMAIL_TO(0.00)[gmail.com]; 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_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 19:55:59 -0000 13.07.2020 2:05, Konstantin Belousov wrote: > On Mon, Jul 13, 2020 at 01:49:22AM +0700, Eugene Grosbein wrote: >> Hi! >> >> Assume we have parent process that created a file and keeps it open not writing anything there. >> The parent spawns a child passing file name and the child opens it, >> fills it with data and exits without fsync()'ing the file. >> >> In case of UFS there is upto 30 seconds time gap when file size is not updated, >> so if crash occurs, the file ends up empty. >> >> The question: will fsync() in parent work for such still open file descriptor? > > fsync() syncs the vnode, not the file or file descriptor. So fsync() on > any file descriptor referencing the same vnode, is enough to ensure that > the data is written to the underlying volume. Thanks! This seems to be undocumented. https://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html does not mention implementation details (and could not) but our manual page could be improved, could it? From owner-freebsd-hackers@freebsd.org Sun Jul 12 20:13:00 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 17F8436D5A4 for ; Sun, 12 Jul 2020 20:13:00 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4dHv04ZHz40p2 for ; Sun, 12 Jul 2020 20:12:58 +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 06CKCoJp040985 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 12 Jul 2020 23:12:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 06CKCoJp040985 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 06CKCo3j040984; Sun, 12 Jul 2020 23:12:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 12 Jul 2020 23:12:50 +0300 From: Konstantin Belousov To: Eugene Grosbein Cc: Freebsd hackers list Subject: Re: fsync(2) Message-ID: <20200712201250.GC44314@kib.kiev.ua> References: <0cdc3315-0213-8522-c8d6-695c2ee02923@grosbein.net> <20200712190517.GA44314@kib.kiev.ua> <12fb648f-8c37-be9b-f18a-5dc2ec9a09c9@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12fb648f-8c37-be9b-f18a-5dc2ec9a09c9@grosbein.net> 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4B4dHv04ZHz40p2 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [0.92 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.31)[0.306]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(0.44)[0.444]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.17)[0.172]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 20:13:00 -0000 On Mon, Jul 13, 2020 at 02:55:32AM +0700, Eugene Grosbein wrote: > 13.07.2020 2:05, Konstantin Belousov wrote: > > > On Mon, Jul 13, 2020 at 01:49:22AM +0700, Eugene Grosbein wrote: > >> Hi! > >> > >> Assume we have parent process that created a file and keeps it open not writing anything there. > >> The parent spawns a child passing file name and the child opens it, > >> fills it with data and exits without fsync()'ing the file. > >> > >> In case of UFS there is upto 30 seconds time gap when file size is not updated, > >> so if crash occurs, the file ends up empty. > >> > >> The question: will fsync() in parent work for such still open file descriptor? > > > > fsync() syncs the vnode, not the file or file descriptor. So fsync() on > > any file descriptor referencing the same vnode, is enough to ensure that > > the data is written to the underlying volume. > > Thanks! This seems to be undocumented. > > https://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html does not mention > implementation details (and could not) but our manual page could be improved, could it? Our manual page for fsync(2) is already good enough IMO. It talks about modified data of file. 'With the kernel-colored glasses', it means the vnode there, but describing the fine difference between file and (vnode, inode) is perhaps too much of useless details for normal application writer. From owner-freebsd-hackers@freebsd.org Sun Jul 12 20:54:10 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5E95336DF6D for ; Sun, 12 Jul 2020 20:54:10 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from forward1-smtp.messagingengine.com (forward1-smtp.messagingengine.com [66.111.4.223]) (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 4B4fCQ0Jbdz42fR for ; Sun, 12 Jul 2020 20:54:09 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailforward.nyi.internal (Postfix) with ESMTP id 74E131940C15 for ; Sun, 12 Jul 2020 16:54:09 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 12 Jul 2020 16:54:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=KC6xP9henewhPEpWzCxjn9rHBx41d wOjXjPluOJXUZ0=; b=ffbqSh5qttGz7SDros9q0Ew1yMDj2jLzjG/1O9b8ZpnOb OQEnHasKHsO8vyFQlbbjAwLAnnrdWJMGPYlI4IkSc7N/8kt064we12hzOQhBUeR2 6w/mczNu2QndE0ICIh/pvSoVwiTr292n6S69RdKqL5Q78uA+XyeudL0JrnAQJqy2 Z//cCUHQCCfw8cAl9kL/ZmqZadW+eU+4uH2Bcof5DYiCTFHf1hV2rF7NQi8+f6Mq 4HG4dI08KPQIXLkJCDTSgLiTtXDe3/YLb7UCC3v77aDXi1NnTchkqswefN1x+fuO JctL5rrGlccsBcqv75yO/4ZfKXyQoPG6HS8qpieNg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdeigdduheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvfhomhculfhonhgvshcuoehthhhjsehfrhgvvggsshgurdhorhhg qeenucggtffrrghtthgvrhhnpedvleegtdehhefhgefhjefhkeegffeftddutdfhgedtge fhhfefueetieehvddvgfenucffohhmrghinhepfhhrvggvsghsugdrohhrghdpfhhrvghs hhgsshgurdhorhhgnecukfhppedufeejrdehtddrudejrdduvdenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhjsehfrhgvvggsshgurdho rhhg X-ME-Proxy: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [137.50.17.12]) by mail.messagingengine.com (Postfix) with ESMTPA id BD3C8306005F for ; Sun, 12 Jul 2020 16:54:08 -0400 (EDT) Date: Sun, 12 Jul 2020 21:51:38 +0100 From: Tom Jones To: freebsd-hackers@freebsd.org Subject: Bugathon July 2020 Follow Up Message-ID: <20200712205138.GA79207@tom-desk.erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4B4fCQ0Jbdz42fR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 20:54:10 -0000 Hello Developers, On Saturday 11th July 2020[1] we held a Bug Squash (or Bugathon, the term we should use consistently). The Bugathon was in the form of an introduction to bugs.freebsd.org and the web and commandline tooling, hosted on google meet, streamed publicly and coordinated in the #freebsd-bugs irc channel on freenode. We planned an 8 hour window from 1400UTC-2100UTC with the intention of having a long enough block of time that most of the world could take part. We spoke for about an hour and a half and then settled into dealing with bugs. There were 15 or so people in the google meet and several more on the stream. In total we modified roughly 139 bugs[2] and have generated roughly 30 commits[3] so far (most of these commits are tagged with 'Event: July 2020 Bugathon'). I would like to thank everyone that attended and helped close bugs, triage issues and added form to the discussion. I hope that more of these events happen in the future, this is our first Bugathon since 2010 and I think it has been a resounding success. To make sure we don't have another long pause between Bugathons, I am going to host a second Bugathon on Saturday 19th of September 2020 from 1400UTC-1200UTC. I will follow up nearer to that date with specific details and plans for the day. I hope that you will join us to process bugs. - Tom [1]: https://wiki.freebsd.org/Bugathons/202007 [2]: https://bugs.freebsd.org/bugzilla/buglist.cgi?chfieldfrom=2020-07-11%2014%3A00&chfieldto=2020-07-11%2021%3A00&email1=%28allanjude%7Cthj%7Cmarkj%7Clinimon%7Cpizzamig%7Czeising%7Cmr%7Csbz%7Crene%7Cbrnrd%7Cdbaio%7Cbhd%7Ccarlavilla%7Cpauamma%29%40&emailassigned_to1=1&emailcc1=1&emaillongdesc1=1&emailreporter1=1&emailtype1=regexp&list_id=365496&order=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced [3]: https://freshbsd.org/search?q=July+2020+Bugathon&project%5B%5D=freebsd&sort=commit_date From owner-freebsd-hackers@freebsd.org Mon Jul 13 10:35:15 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3D0B935F995 for ; Mon, 13 Jul 2020 10:35:15 +0000 (UTC) (envelope-from se@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B50Qq0sCwz3Tmm; Mon, 13 Jul 2020 10:35:15 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f0bb900a4f426240105a23e.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:b900:a4f4:2624:105:a23e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id AAFA22CC00; Mon, 13 Jul 2020 10:35:14 +0000 (UTC) (envelope-from se@freebsd.org) To: FreeBSD Hackers From: =?UTF-8?Q?Stefan_E=c3=9fer?= Subject: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Message-ID: <61362d77-b283-b00e-c7cd-9f93ea937728@freebsd.org> Date: Mon, 13 Jul 2020 12:35:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 10:35:15 -0000 Many AMD B550 mainboards have been released with RTL8125 Ethernet chips, which are not yet supported in -CURRENT, AFAIK. Is anybody working on extending the RTL8111 driver to support that chip? I'm in the process of building a system that comes with said Ethernet controller and while I can just install an additional PCI-E card, I'd ultimately of course want to use the on-board Ethernet. I just found a driver on the realtek.com web-site that is based on an older version of RE from Bill Paul. That should be a good source of information for an updated RE driver, which uses the evolved data structures of our current version. For a start, I'd be happy if it just worked as a 1000baseTX device (and I do not expect to have a 2.5 Gbit/s capable switch anytime soon. If nobody else is going to work on this, I'll start this project, but my system will not be ready for testing before the end of July. Regards, STefan From owner-freebsd-hackers@freebsd.org Mon Jul 13 14:19:10 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DA24E3652DF for ; Mon, 13 Jul 2020 14:19:10 +0000 (UTC) (envelope-from stephen.wall@redcom.com) Received: from smtp1.redcom.com (smtp1.redcom.com [192.86.3.143]) by mx1.freebsd.org (Postfix) with ESMTP id 4B55P96Ty7z40Sv for ; Mon, 13 Jul 2020 14:19:09 +0000 (UTC) (envelope-from stephen.wall@redcom.com) Received: from localhost (localhost [127.0.0.1]) by smtp1.redcom.com (Postfix) with ESMTP id 6C5B0A1C6 for ; Mon, 13 Jul 2020 10:19:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at redcom.com Received: from smtp1.redcom.com ([127.0.0.1]) by localhost (smtp1.redcom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv2dFabpYncx for ; Mon, 13 Jul 2020 10:19:01 -0400 (EDT) Received: from pie.redcom.com (pie [192.168.33.15]) by smtp1.redcom.com (Postfix) with ESMTP id 84365A1C7 for ; Mon, 13 Jul 2020 10:19:01 -0400 (EDT) Received: from exch-03.redcom.com (exch-03.redcom.com [192.168.32.32]) by pie.redcom.com (8.11.7p1+Sun/8.10.2) with ESMTP id 06DEJ1l25138 for ; Mon, 13 Jul 2020 10:19:01 -0400 (EDT) Received: from exch-03.redcom.com (fd00::8549:68c0:3d5f:ee62) by exch-03.redcom.com (fd00::8549:68c0:3d5f:ee62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.330.5; Mon, 13 Jul 2020 10:19:01 -0400 Received: from exch-03.redcom.com ([fe80::a442:ce34:c9c8:268f]) by exch-03.redcom.com ([fe80::a442:ce34:c9c8:268f%3]) with mapi id 15.02.0330.010; Mon, 13 Jul 2020 10:19:01 -0400 From: "Wall, Stephen" To: "freebsd-hackers@freebsd.org" Subject: mutex locking on file descriptors? Thread-Topic: mutex locking on file descriptors? Thread-Index: AQHWWRoXEPt2d/knTkKX89CPrcZPAQ== Date: Mon, 13 Jul 2020 14:19:01 +0000 Message-ID: <0ae4590637e54a479228b38a823535a8@redcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.224.136] MIME-Version: 1.0 X-Rspamd-Queue-Id: 4B55P96Ty7z40Sv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 192.86.3.143 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com X-Spamd-Result: default: False [-0.81 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:192.86.3.143/32]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[redcom.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.63)[-0.633]; NEURAL_HAM_MEDIUM(-0.75)[-0.747]; NEURAL_HAM_SHORT(-0.23)[-0.228]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:46679, ipnet:192.86.3.0/24, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_SEVEN(0.00)[7] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 14:19:10 -0000 I've been told by a co-worker that a freebsd developer once told him that m= utex locking on socket descriptors was not necessary to avoid issues with m= ultiple threads reading and writing. I would like to confirm this is true = of file descriptors as well, and in particular of device driver file descri= ptors, before I abandon them in my code. The driver in question is a simpl= e `usb_fifo_methods` type driver. Thanks. - Steve Wall From owner-freebsd-hackers@freebsd.org Mon Jul 13 14:40:59 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 73F06365E73 for ; Mon, 13 Jul 2020 14:40:59 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B55tL2PVgz41js for ; Mon, 13 Jul 2020 14:40:57 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 06DEepXU063164 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jul 2020 14:40:53 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: stephen.wall@redcom.com Received: from [10.58.0.10] (dadv@dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 06DEekE6048197 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Jul 2020 21:40:46 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: mutex locking on file descriptors? To: "Wall, Stephen" , "freebsd-hackers@freebsd.org" References: <0ae4590637e54a479228b38a823535a8@redcom.com> From: Eugene Grosbein Message-ID: Date: Mon, 13 Jul 2020 21:40:38 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0ae4590637e54a479228b38a823535a8@redcom.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains * -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4B55tL2PVgz41js X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.34 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.900]; NEURAL_HAM_LONG(-0.35)[-0.348]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_SHORT(0.01)[0.010]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[empty SPF record]; 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:24940, ipnet:2a01:4f8::/29, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 14:40:59 -0000 13.07.2020 21:19, Wall, Stephen wrote: > I've been told by a co-worker that a freebsd developer once told him that mutex locking > on socket descriptors was not necessary to avoid issues with multiple threads reading and writing. > I would like to confirm this is true of file descriptors as well, > and in particular of device driver file descriptors, before I abandon them in my code. > The driver in question is a simple `usb_fifo_methods` type driver. This heavily depends on exact "issues" you are try to avoid, amount of data wrote or read, used protocol and driver. In some cases, for some types of descriptors there is atomicy for small writes. But in general you need some kind of locking. Else you may get unexpected results, f.e. some part of data read by one thread and another part by another thread. From owner-freebsd-hackers@freebsd.org Mon Jul 13 16:31:17 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B5F86368F26 for ; Mon, 13 Jul 2020 16:31:17 +0000 (UTC) (envelope-from stephen.wall@redcom.com) Received: from smtp1.redcom.com (smtp1.redcom.com [192.86.3.143]) by mx1.freebsd.org (Postfix) with ESMTP id 4B58Kc6qrfz4991 for ; Mon, 13 Jul 2020 16:31:16 +0000 (UTC) (envelope-from stephen.wall@redcom.com) Received: from localhost (localhost [127.0.0.1]) by smtp1.redcom.com (Postfix) with ESMTP id 4888AA1C7 for ; Mon, 13 Jul 2020 12:31:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at redcom.com Received: from smtp1.redcom.com ([127.0.0.1]) by localhost (smtp1.redcom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR6RaYkfjvaA for ; Mon, 13 Jul 2020 12:31:10 -0400 (EDT) Received: from pie.redcom.com (pie [192.168.33.15]) by smtp1.redcom.com (Postfix) with ESMTP id 66B3FA1B5 for ; Mon, 13 Jul 2020 12:31:10 -0400 (EDT) Received: from exch-03.redcom.com (exch-03.redcom.com [192.168.32.32]) by pie.redcom.com (8.11.7p1+Sun/8.10.2) with ESMTP id 06DGVAl02590 for ; Mon, 13 Jul 2020 12:31:10 -0400 (EDT) Received: from exch-03.redcom.com (fd00::8549:68c0:3d5f:ee62) by exch-03.redcom.com (fd00::8549:68c0:3d5f:ee62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.330.5; Mon, 13 Jul 2020 12:31:10 -0400 Received: from exch-03.redcom.com ([fe80::a442:ce34:c9c8:268f]) by exch-03.redcom.com ([fe80::a442:ce34:c9c8:268f%3]) with mapi id 15.02.0330.010; Mon, 13 Jul 2020 12:31:10 -0400 From: "Wall, Stephen" To: "freebsd-hackers@freebsd.org" Subject: Re: mutex locking on file descriptors? Thread-Topic: mutex locking on file descriptors? Thread-Index: AQHWWRoXEPt2d/knTkKX89CPrcZPAakF2AAA///Ls9E= Date: Mon, 13 Jul 2020 16:31:09 +0000 Message-ID: <4bc963c9dd944c74a7d2419c3e3d2bcf@redcom.com> References: <0ae4590637e54a479228b38a823535a8@redcom.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.224.136] MIME-Version: 1.0 X-Rspamd-Queue-Id: 4B58Kc6qrfz4991 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 192.86.3.143 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com X-Spamd-Result: default: False [-0.54 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:192.86.3.143/32]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[redcom.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.53)[-0.530]; NEURAL_HAM_MEDIUM(-0.71)[-0.706]; NEURAL_HAM_SHORT(-0.10)[-0.103]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:46679, ipnet:192.86.3.0/24, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_SEVEN(0.00)[7] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 16:31:17 -0000 > This heavily depends on exact "issues" you are try to avoid, amount of da= ta wrote or read, > used protocol and driver. > > In some cases, for some types of descriptors there is atomicy for small w= rites. > But in general you need some kind of locking. Else you may get unexpected= results, > f.e. some part of data read by one thread and another part by another thr= ead. OK, more details. The device driver is providing unfiltered access to a bu= lk endpoint on a Silicon Labs device, which speaks a protocol defined by SI= Labs supporting packets of up to 64 bytes in length. Most are much shorter= that that, 10-20 bytes. The device's datasheet doesn't state it, but in t= esting I've never seen one of these packets fragmented. I will have a thread that writes queries on a timed basis, and reads replie= s to those queries, as well as hardware-triggered messages, using kqueue to= receive notification that data is available. It will process the messages= and store relevant data in class variables for consumption as needed. Where I have a concern is that I'm also providing functions to bypass this = mechanism, and give consumers a way to send custom messages to the device, = which means a write can also happen outside the thread discussed above. I = thought that I needed a mutex to protect against a context switch happening= in the middle of one or the other of the accesses, until my co-worker's co= mments. This comment from usbdi.h seems to support that read and write a= re already protected: /* * Locking note for the following functions. All the * "usb_fifo_cmd_t" and "usb_fifo_filter_t" functions are called * locked. The others are called unlocked. */ I guess I will assume the mutex is needed, unless someone can definitively = say it's not. Thank you, Eugene. - Steve Wall ________________________________ From owner-freebsd-hackers@freebsd.org Mon Jul 13 17:27:20 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2E90C36B038; Mon, 13 Jul 2020 17:27:20 +0000 (UTC) (envelope-from mmacy@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B59ZJ0TtSz4G6Z; Mon, 13 Jul 2020 17:27:20 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id E14BB2FC09; Mon, 13 Jul 2020 17:27:19 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lf1-f41.google.com with SMTP id g139so9540624lfd.10; Mon, 13 Jul 2020 10:27:19 -0700 (PDT) X-Gm-Message-State: AOAM530CBzn5362d8ZkxsvvELYsKWsBX50PZOGery4Z1yoPOYy3iPums r8PZV4bAbh+nVKWCVFSIc5Gxd/2qIfFZmtxim7g= X-Google-Smtp-Source: ABdhPJx27xPiexmBFm2IppULhgxJHDxbmT+4h4zYmbzee1ZEKh1k00d4Va3rPc4oxES60biSZQaQlJa/0PKLXz5muvM= X-Received: by 2002:a19:a8c:: with SMTP id 134mr139172lfk.128.1594661238368; Mon, 13 Jul 2020 10:27:18 -0700 (PDT) MIME-Version: 1.0 From: Matthew Macy Date: Mon, 13 Jul 2020 10:27:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: CFT for vendor openzfs - week 2 reminder To: freebsd-current , freebsd-fs , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 17:27:20 -0000 On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The current *tentative* merge date is August 10th. I hope it's not terribly controversial to point out that it really rests with users of non amd64 platforms to test to avoid any unpleasant surprises the next time they update their trees following the merge. ========================================================== NB: Do NOT zpool upgrade unless you are willing to live without the ability to ever rollback to the legacy zfs kmod. Checkout updated HEAD: % git clone https://github.com/mattmacy/networking.git -b projects/openzfs_vendor freebsd Checkout updated openzfs in to sys/contrib: % git clone https://github.com/zfsonfreebsd/ZoF.git -b projects/openzfs_vendor freebsd/sys/contrib/openzfs Build world and kernel with whatever your usual configuration is. Where possible the openzfs kmod is backward compatible with the cmd utils in HEAD so common operations work with existing tools and the new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries are backward compatible with the zfs kmod in HEAD. Although ideally one would test this in a separate boot environment, the interoperability should allow one to rollback without too much difficulty. Thanks in advance for your time. -M From owner-freebsd-hackers@freebsd.org Mon Jul 13 17:33:24 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 992F736B8DE; Mon, 13 Jul 2020 17:33:24 +0000 (UTC) (envelope-from kevans@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B59jJ3cfSz4Gtp; Mon, 13 Jul 2020 17:33:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 5A2D52FC9B; Mon, 13 Jul 2020 17:33:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-vs1-f44.google.com with SMTP id q15so7025564vso.9; Mon, 13 Jul 2020 10:33:24 -0700 (PDT) X-Gm-Message-State: AOAM5306R1o2NxPKOb91irwSUY966oxcqPWslD1LZMpN04EmTXZjlaCp YD/FHKAVYlqhov/cjbR+7yHF6HoLeNmrv9oWSuE= X-Google-Smtp-Source: ABdhPJxLP+ZFemGV2UDvUVqZph6aaR1h0y2+4eQBMZda/iTy0C7aXY85dvUWuPef+Co/tB6BIKkmK6n0QeQRd+VSg+g= X-Received: by 2002:a67:8a4a:: with SMTP id m71mr376954vsd.59.1594661603722; Mon, 13 Jul 2020 10:33:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Mon, 13 Jul 2020 12:33:11 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CFT for vendor openzfs - week 2 reminder To: Matthew Macy Cc: freebsd-current , freebsd-fs , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 17:33:24 -0000 On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy wrote: > > On Wednesday, July 8th I issued the initial call for testing for the > update to HEAD to vendored openzfs. We'd like to give users roughly a > month to test before merging. The current *tentative* merge date is > August 10th. I hope it's not terribly controversial to point out that > it really rests with users of non amd64 platforms to test to avoid any > unpleasant surprises the next time they update their trees following > the merge. > I've had no problems with this on a couple amd64 systems; I did note that my loader.conf's needed a good s/vfs.zfs.arc_max/vfs.zfs.arc.max/ but I'm told a compat sysctl is on the TODO list to ease the transition. Thanks, Kyle Evans From owner-freebsd-hackers@freebsd.org Tue Jul 14 04:59:57 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0E87B354FF5; Tue, 14 Jul 2020 04:59:57 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5SxR2KtZz4Km6; Tue, 14 Jul 2020 04:59:55 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 06E4xmGs062844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2020 05:59:48 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 06E4xm79062842; Tue, 14 Jul 2020 05:59:48 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202007140459.06E4xm79062842@donotpassgo.dyslexicfish.net> Date: Tue, 14 Jul 2020 05:59:48 +0100 Organization: Dyslexic Fish To: mmacy@freebsd.org, freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: CFT for vendor openzfs - week 2 reminder References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Tue, 14 Jul 2020 05:59:48 +0100 (BST) X-Rspamd-Queue-Id: 4B5SxR2KtZz4Km6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.983]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.24)[-0.243]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 04:59:57 -0000 Can anyone using the new vendor openzfs let us know if it fixes the "mmp_thread_enter" bug recently MFC'ed to STABLE? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247829 Cheers From owner-freebsd-hackers@freebsd.org Tue Jul 14 06:20:47 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1C316357A92 for ; Tue, 14 Jul 2020 06:20:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5Vkk6N3Sz4bDq for ; Tue, 14 Jul 2020 06:20:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id D85CB35735A; Tue, 14 Jul 2020 06:20:46 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D7F5135796E; Tue, 14 Jul 2020 06:20:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B5Vkj6Vh7z4bNN; Tue, 14 Jul 2020 06:20:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qk1-f174.google.com with SMTP id k18so14616047qke.4; Mon, 13 Jul 2020 23:20:45 -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=LH9kK4F8k74vIEGczlX1Sp/15vlM79tZ9OCipNcrO98=; b=lWKfdM+XsgrBWA/RPAnljQ//3hMlxBt0AQABFVOxpH6WWho1NiL5fGMHZh9mnbWrEN /qBhXorXhHWAZ6c6p0G/x2F1F6k6cPeQsCmqI0mm0+3EqVXu845uvySFSCoYlekV13Ug rtIR1fe1Ij58i42Dck+IMuUqZjtAREIDYz2PjIs8bmS1LUAws7H/36oaD6b3F1oV5J0i QDecov/FDySWOHY8XWCszTYc9UL4pjidGdT6rUsMNhW+xu9+j3aUYusofVkn8hHHPiLb yqMiwfMECKTbeBHNXSKKSTxeQyShI305ZAssFoYkUuiJYfckbxqCcYEiwFM3OaLWG5UI xYnA== X-Gm-Message-State: AOAM53209eJOpYhEmIWf6KsFc4WdmpQ3oDovxssktlV2DG9fszXrxpud 7OzJzeB085j12Ekg8hHpt2PsKDnL36xKc9bTI983WA== X-Google-Smtp-Source: ABdhPJz7yqEJlPL+Ixhdc2FaJ0j5txwHcmphicqKi3ESSXwXjUB8xjEkxk0CpMYeVW4o3LW4urdyAJYaxc/h53qF6FM= X-Received: by 2002:a37:aa03:: with SMTP id t3mr3157523qke.152.1594707644618; Mon, 13 Jul 2020 23:20:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Chadd Date: Mon, 13 Jul 2020 23:20:32 -0700 Message-ID: Subject: Re: driver for cp2112 (USB GPIO and I2C gadget) To: Andriy Gapon Cc: usb@freebsd.org, FreeBSD Hackers , FreeBSD Current X-Rspamd-Queue-Id: 4B5Vkj6Vh7z4bNN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of adrianchadd@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=adrianchadd@gmail.com X-Spamd-Result: default: False [-1.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.871]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.84)[-0.845]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.25)[0.254]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.174:from]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.174:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 06:20:47 -0000 hi! On Wed, 8 Jul 2020 at 02:39, Andriy Gapon wrote: > On 19/06/2020 17:14, Andriy Gapon wrote: > > > > If anyone interested in reviewing a new driver please help yourself to: > > https://reviews.freebsd.org/D25359 > > https://reviews.freebsd.org/D25360 > > What might be curious about it is that there are usb, i2c and gpio mixed > together. > Any interest at all? > I am still torn about which of the approaches to take. > I prefer the non monolithic one. i left comments on that one. :-) -adrian > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Tue Jul 14 08:22:46 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A41335A52F for ; Tue, 14 Jul 2020 08:22:46 +0000 (UTC) (envelope-from se@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B5YRV2Szdz4bKh; Tue, 14 Jul 2020 08:22:46 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f0bb900a4f426240105a23e.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:b900:a4f4:2624:105:a23e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C35061688B; Tue, 14 Jul 2020 08:22:45 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? From: =?UTF-8?Q?Stefan_E=c3=9fer?= To: FreeBSD Hackers References: <61362d77-b283-b00e-c7cd-9f93ea937728@freebsd.org> Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Message-ID: Date: Tue, 14 Jul 2020 10:22:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <61362d77-b283-b00e-c7cd-9f93ea937728@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 08:22:46 -0000 Following up to my own mail: I have created an updated version of if_rlreg.h (based on information from if_rereg.h from the driver provided by Realtek) and I'll test it for regressions when used to build and use the re driver in -CURRENT. If it works (does not break re used with an RTL8111) I'll proceed to add RTL8125 specific code to if_re.c, again based on information from the driver provided by Realtek. I want to omit duplicate work and if anybody else is interested in this driver or already working on it, I'd like to combine efforts (or might wait for a nearly ready driver to be published). Regards, STefan Am 13.07.20 um 12:35 schrieb Stefan Eßer: > Many AMD B550 mainboards have been released with RTL8125 Ethernet chips, > which are not yet supported in -CURRENT, AFAIK. > > Is anybody working on extending the RTL8111 driver to support that chip? > > > I'm in the process of building a system that comes with said Ethernet > controller and while I can just install an additional PCI-E card, I'd > ultimately of course want to use the on-board Ethernet. > > > I just found a driver on the realtek.com web-site that is based on an > older version of RE from Bill Paul. > > That should be a good source of information for an updated RE driver, > which uses the evolved data structures of our current version. For a > start, I'd be happy if it just worked as a 1000baseTX device (and I do > not expect to have a 2.5 Gbit/s capable switch anytime soon. > > > If nobody else is going to work on this, I'll start this project, but > my system will not be ready for testing before the end of July. > > Regards, STefan > _______________________________________________ > 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 Jul 14 16:37:12 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 471E6368387 for ; Tue, 14 Jul 2020 16:37:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B5mPy38Ncz49wn for ; Tue, 14 Jul 2020 16:37:10 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f172.google.com with SMTP id k22so14455634oib.0 for ; Tue, 14 Jul 2020 09:37:10 -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:cc; bh=8lHQGKmLQ9ler0bDOlfv/jO4faB9/zdtg0TU+75udRQ=; b=N42OI40D2PvIkg6uz5MUz/QSTx5lXH4u9XUU00RkTvClqCYTW3mA9dKbe5yQXJDAxe j9KKBvTyXpKEUI8pqw1AjM57Fc8TIcfmGKaIUX7/KAatYJArzMVYQkd537JtlBMyHJO/ bFxkUbkkN6ivER5deqyeEBf8YiEa7IOkiLqDk504a4IO5GkxeBiDdhAoWvhLoS0iJuYb IULdusxt1Zl+JPXifl4LnCZxRrJSLvKFt4VbNKcVCoib5fa9MmT3kjK1ph/9U1CBuBZw IHskfbg3/NKrEKGu02vD+O0O0hk4IRmwxSv4qSvz6r0YHNLXdJuTEGhrhhmdW7wT/zxw wvag== X-Gm-Message-State: AOAM532YhVOh57lfcQxWxnZhBZoRs4tZBt0Oydp62dUEP2JgZAWcc0FN 90OgFY46bugHdtllTvjSemqBglINrWNInXKqHic= X-Received: by 2002:aca:b6c3:: with SMTP id g186mt4887102oif.55.1594744629083; Tue, 14 Jul 2020 09:37:09 -0700 (PDT) MIME-Version: 1.0 References: <20200710175452.GA9380@raichu> In-Reply-To: From: Alan Somers Date: Tue, 14 Jul 2020 10:36:56 -0600 Message-ID: Subject: Re: Right-sizing the geli thread pool Cc: Mark Johnston , Mateusz Guzik , FreeBSD Hackers X-Rspamd-Queue-Id: 4B5mPy38Ncz49wn X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.172 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-0.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.70)[-0.698]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.78)[-0.777]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.54)[-0.536]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.172:from]; MISSING_TO(2.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.172:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 16:37:12 -0000 On Fri, Jul 10, 2020 at 5:13 PM Alan Somers wrote: > On Fri, Jul 10, 2020 at 11:55 AM Mark Johnston wrote: > >> On Fri, Jul 10, 2020 at 05:55:50AM +0200, Mateusz Guzik wrote: >> > On 7/9/20, Alan Somers wrote: >> > > Currently, geli creates a separate thread pool for each provider, and >> by >> > > default each thread pool contains one thread per cpu. On a large >> server >> > > with many encrypted disks, that can balloon into a very large number >> of >> > > threads! I have a patch in progress that switches from per-provider >> thread >> > > pools to a single thread pool for the entire module. Happily, I see >> read >> > > IOPs increase by up to 60%. But to my surprise, write IOPs >> _decreases_ by >> > > up to 25%. dtrace suggests that the CPU usage is dominated by the >> > > vmem_free call in biodone, as in the below stack. >> > > >> > > kernel`lock_delay+0x32 >> > > kernel`biodone+0x88 >> > > kernel`g_io_deliver+0x214 >> > > geom_eli.ko`g_eli_write_done+0xf6 >> > > kernel`g_io_deliver+0x214 >> > > kernel`md_kthread+0x275 >> > > kernel`fork_exit+0x7e >> > > kernel`0xffffffff8104784e >> > > >> > > I only have one idea for how to improve things from here. The geli >> thread >> > > pool is still fed by a single global bio queue. That could cause >> cache >> > > thrashing, if bios get moved between cores too often. I think a >> superior >> > > design would be to use a separate bio queue for each geli thread, and >> use >> > > work-stealing to balance them. However, >> > > >> > > 1) That doesn't explain why this change benefits reads more than >> writes, >> > > and >> > > 2) work-stealing is hard to get right, and I can't find any examples >> in the >> > > kernel. >> > > >> > > Can anybody offer tips or code for implementing work stealing? Or any >> > > other suggestions about why my write performance is suffering? I >> would >> > > like to get this change committed, but not without resolving that >> issue. >> > > >> > >> > I can't comment on revamping the design, but: >> > >> > void >> > vmem_free(vmem_t *vm, vmem_addr_t addr, vmem_size_t size) >> > { >> > qcache_t *qc; >> > MPASS(size > 0); >> > >> > if (size <= vm->vm_qcache_max && >> > __predict_true(addr >= VMEM_ADDR_QCACHE_MIN)) { >> > qc = &vm->vm_qcache[(size - 1) >> vm->vm_quantum_shift]; >> > uma_zfree(qc->qc_cache, (void *)addr); >> > } else >> > vmem_xfree(vm, addr, size); >> > } >> > >> > What sizes are being passed here? Or more to the point, is it feasible >> > to bump qcache to stick to uma in this call? If lock contention is >> > indeed coming from vmem_xfree this change would get rid of the problem >> > without having to rework anything. >> >> We would have to enable the quantum cache in the transient KVA arena. >> This itself should not have many downsides on platforms with plenty of >> KVA, but it only solves the immediate problem: before freeing the KVA >> biodone() has to perform a global TLB shootdown, and the quantum cache >> doesn't help at all with that. >> >> kib's suggestion of using sf_buf(9) to transiently map crypto(9) >> payloads in software crypto drivers that require a mapping, and using >> unmapped cryptop requests for hardware drivers that do not, sounds like >> the right solution. cryptop structures can already handle multiple data >> container types, like uios and mbufs, so it should be possible to also >> support vm_page arrays in OCF like we do for unmapped BIOs, and let >> crypto(9) drivers create transient mappings when necessary. >> >> > For read performance, while it is nice there is a win, it may still be >> > less than it should. I think it is prudent to get a flamegraph from >> > both cases. >> > > And, it works! Using sf_buf was a good suggestion, because the write path > only needs to access the user data for a short amount of time, in a > CPU-pinned thread. So I can create my sf_buf and immediately free it. I > didn't even need to change crypto(9). Writes are much faster now. I > haven't incorporated sf_buf into the read path yet, though. > > Preliminary benchmarks: > > Write IOPs READ IOPs > baseline 66908 60351 > kern.geom.eli.threads=1 156719 144117 > kern.geom.eli.threads=1, direct dispatch 205326 201867 > direct dispatch, shared thread pool 156631 226874 > direct dispatch, shared thread pool, sf_buf 432573 247275 > > -Alan > Ok, I got ahead of myself. Actually, it _doesn't_ work. I was initially elated by how much extra speed I got by using sf_bufs. But even so, writes are still slower (and reads faster) when I use a shared thread pool. I'll work on committing the sf_buf changes, then try to debug the shared thread pool performance degradation again. -Alan From owner-freebsd-hackers@freebsd.org Wed Jul 15 00:31:08 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AA7933545DE for ; Wed, 15 Jul 2020 00:31:08 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [208.111.40.118]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5ywp3Bp4z4BZD; Wed, 15 Jul 2020 00:31:06 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from chombo.houseloki.net (unknown [IPv6:2602:41:642b:600::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "chombo.houseloki.net", Issuer "brtsvcs.net CA" (verified OK)) by echo.brtsvcs.net (Postfix) with ESMTPS id B874438D16; Wed, 15 Jul 2020 00:30:59 +0000 (UTC) Received: from [IPv6:2602:41:642b:630:e061:8fd1:7f5e:38d5] (unknown [IPv6:2602:41:642b:630:e061:8fd1:7f5e:38d5]) by chombo.houseloki.net (Postfix) with ESMTPSA id BE195DBA4; Tue, 14 Jul 2020 17:30:58 -0700 (PDT) Subject: Re: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? To: =?UTF-8?Q?Stefan_E=c3=9fer?= , FreeBSD Hackers References: <61362d77-b283-b00e-c7cd-9f93ea937728@freebsd.org> From: Mel Pilgrim Message-ID: <9a3c9521-c229-2542-70ec-fc2a2bf6f8f3@bluerosetech.com> Date: Tue, 14 Jul 2020 17:30:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4B5ywp3Bp4z4BZD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list_freebsd@bluerosetech.com designates 208.111.40.118 as permitted sender) smtp.mailfrom=list_freebsd@bluerosetech.com X-Spamd-Result: default: False [-1.36 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bluerosetech.com]; NEURAL_HAM_LONG(-0.99)[-0.991]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.09)[-0.086]; 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:36236, ipnet:208.111.40.0/24, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 00:31:08 -0000 On 2020-07-14 1:22, Stefan Eßer wrote: > I want to omit duplicate work and if anybody else is interested in this > driver or already working on it, I'd like to combine efforts (or might > wait for a nearly ready driver to be published). I don't think anyone is. I asked about RTL8125 support a while back and got crickets. From owner-freebsd-hackers@freebsd.org Wed Jul 15 06:17:39 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1B9E935ADCF for ; Wed, 15 Jul 2020 06:17:39 +0000 (UTC) (envelope-from se@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B66cf71wSz4KhQ; Wed, 15 Jul 2020 06:17:38 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MacBook-Pro-449.local (p200300cd5f0bb900587458d1006411d1.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:b900:5874:58d1:64:11d1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 6E6C82015E; Wed, 15 Jul 2020 06:17:38 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? To: Mel Pilgrim , FreeBSD Hackers References: <61362d77-b283-b00e-c7cd-9f93ea937728@freebsd.org> <9a3c9521-c229-2542-70ec-fc2a2bf6f8f3@bluerosetech.com> From: =?UTF-8?Q?Stefan_E=c3=9fer?= Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Message-ID: <6c8fdae0-4fd5-142c-87f8-1f4026bbd8a1@freebsd.org> Date: Wed, 15 Jul 2020 08:17:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9a3c9521-c229-2542-70ec-fc2a2bf6f8f3@bluerosetech.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 06:17:39 -0000 Am 15.07.20 um 02:30 schrieb Mel Pilgrim: > On 2020-07-14 1:22, Stefan Eßer wrote: >> I want to omit duplicate work and if anybody else is interested in this >> driver or already working on it, I'd like to combine efforts (or might >> wait for a nearly ready driver to be published). > > I don't think anyone is.  I asked about RTL8125 support a while back and > got crickets. I have merged the relevant register definitions etc. into if_rlreg.h and can still build the re driver for the 1000baseTX devices (but will need to perform some testing to be sure that I did not break anything, since there were a few conflicting defines). It will take me a few weeks (due to being abroad without access to the hardware for some time), but I'm definitely trying to get this chip supported. Regards, STefan From owner-freebsd-hackers@freebsd.org Wed Jul 15 06:22:20 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4A69A35B0BF for ; Wed, 15 Jul 2020 06:22:20 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [93.151.207.39]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B66k34jkXz4MRr for ; Wed, 15 Jul 2020 06:22:19 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 82785 invoked from network); 15 Jul 2020 06:22:16 -0000 Received: from carbon.alexdupre.com (HELO ?192.168.178.18?) (sysadmin@alexdupre.com@192.168.178.18) by lab.alexdupre.com with ESMTPSA; 15 Jul 2020 06:22:16 -0000 Subject: Re: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? To: =?UTF-8?Q?Stefan_E=c3=9fer?= , Mel Pilgrim , FreeBSD Hackers References: <61362d77-b283-b00e-c7cd-9f93ea937728@freebsd.org> <9a3c9521-c229-2542-70ec-fc2a2bf6f8f3@bluerosetech.com> <6c8fdae0-4fd5-142c-87f8-1f4026bbd8a1@freebsd.org> From: Alex Dupre Message-ID: <6382c967-b7fa-0581-f16e-504a909809f2@FreeBSD.org> Date: Wed, 15 Jul 2020 08:22:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.2 MIME-Version: 1.0 In-Reply-To: <6c8fdae0-4fd5-142c-87f8-1f4026bbd8a1@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4B66k34jkXz4MRr X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; ASN(0.00)[asn:30722, ipnet:93.151.128.0/17, country:IT] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 06:22:20 -0000 Stefan E=DFer wrote: > Am 15.07.20 um 02:30 schrieb Mel Pilgrim: >> On 2020-07-14 1:22, Stefan E=DFer wrote: >>> I want to omit duplicate work and if anybody else is interested in th= is >>> driver or already working on it, I'd like to combine efforts (or migh= t >>> wait for a nearly ready driver to be published). >> >> I don't think anyone is.=A0 I asked about RTL8125 support a while back= and >> got crickets. I've just started working on creating a port of the official Realtek driver. Latest release should support the 8125 chipset and WOL. It should be ready very soon (likely today or tomorrow). --=20 Alex Dupre From owner-freebsd-hackers@freebsd.org Wed Jul 15 06:39:17 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 844E635BB94 for ; Wed, 15 Jul 2020 06:39:17 +0000 (UTC) (envelope-from se@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B675d3030z4VWg; Wed, 15 Jul 2020 06:39:17 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MacBook-Pro-449.local (p200300cd5f0bb900587458d1006411d1.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:b900:5874:58d1:64:11d1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C12BE2091B; Wed, 15 Jul 2020 06:39:16 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? To: Alex Dupre , Mel Pilgrim , FreeBSD Hackers References: <61362d77-b283-b00e-c7cd-9f93ea937728@freebsd.org> <9a3c9521-c229-2542-70ec-fc2a2bf6f8f3@bluerosetech.com> <6c8fdae0-4fd5-142c-87f8-1f4026bbd8a1@freebsd.org> <6382c967-b7fa-0581-f16e-504a909809f2@FreeBSD.org> From: =?UTF-8?Q?Stefan_E=c3=9fer?= Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Message-ID: <10310e5c-538d-12f9-e504-bca8f75f1aa3@freebsd.org> Date: Wed, 15 Jul 2020 08:39:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <6382c967-b7fa-0581-f16e-504a909809f2@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 06:39:17 -0000 Am 15.07.20 um 08:22 schrieb Alex Dupre: > Stefan Eßer wrote: >> Am 15.07.20 um 02:30 schrieb Mel Pilgrim: >>> On 2020-07-14 1:22, Stefan Eßer wrote: >>>> I want to omit duplicate work and if anybody else is interested in this >>>> driver or already working on it, I'd like to combine efforts (or might >>>> wait for a nearly ready driver to be published). >>> >>> I don't think anyone is.  I asked about RTL8125 support a while back and >>> got crickets. > > I've just started working on creating a port of the official Realtek > driver. Latest release should support the 8125 chipset and WOL. It > should be ready very soon (likely today or tomorrow). Ok, that will be much sooner than I'll be able to complete the same task. As written before, I have merged the relevant content from if_rereg.h into out re_rlreg.h and verified that I did not break anything for our if_re. My AMD B550 based system has been completed yesterday and is now up and running (with an additional Ethernet card until the on-board RTL8125 is working). I'd be happy to test your version on that system (but can only test with 1000baseTX). Regards, STefan From owner-freebsd-hackers@freebsd.org Wed Jul 15 15:43:39 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C4EBA3698B8 for ; Wed, 15 Jul 2020 15:43:39 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6M9j2QBZz4gGg for ; Wed, 15 Jul 2020 15:43:36 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 06FFhZJF072819 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Jul 2020 08:43:35 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76] claimed to be yv.noip.me Subject: Re: Is it possible to determine the open file path based on the file descriptor? To: Mateusz Guzik Cc: Freebsd hackers list References: <21b0280d-c290-f27f-98a9-0c2242380718@rawbw.com> From: Yuri Message-ID: <0d3069f1-9460-f06d-3e1b-a67b3b1d94ea@rawbw.com> Date: Wed, 15 Jul 2020 08:43:34 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4B6M9j2QBZz4gGg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuri@rawbw.com designates 198.144.192.42 as permitted sender) smtp.mailfrom=yuri@rawbw.com X-Spamd-Result: default: False [-1.06 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.144.192.32/27]; NEURAL_HAM_LONG(-0.78)[-0.779]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[rawbw.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.16)[-0.158]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[198.144.192.42:from]; NEURAL_HAM_MEDIUM(-0.93)[-0.927]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[73.189.35.76:received] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 15:43:39 -0000 On 2020-07-10 00:22, Mateusz Guzik wrote: > That said, for this program on FreeBSD, the right thing to do is to > convert it to actual realpath(3). In head this will be performant just > fine as it is implemented as a syscall. I can MFC it for stable/12. Please MFC it to stable/12. Thank you, Yuri From owner-freebsd-hackers@freebsd.org Wed Jul 15 16:30:46 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1098736A671 for ; Wed, 15 Jul 2020 16:30:46 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6ND44Rs0z4XFk; Wed, 15 Jul 2020 16:30:44 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 06FGVALD034437 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Jul 2020 09:31:16 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: =?UTF-8?B?U3RlZmFuIEXDn2Vy?= , Mel Pilgrim , FreeBSD Hackers In-Reply-To: <6382c967-b7fa-0581-f16e-504a909809f2@FreeBSD.org> From: Chris Reply-To: bsd-lists@BSDforge.com To: Alex Dupre Subject: Re: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? Date: Wed, 15 Jul 2020 09:31:16 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4B6ND44Rs0z4XFk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 16:30:46 -0000 On Wed, 15 Jul 2020 08:22:13 +0200 Alex Dupre ale@FreeBSD=2Eorg said > Stefan E=C3=9Fer wrote: > > Am 15=2E07=2E20 um 02:30 schrieb Mel Pilgrim: > >> On 2020-07-14 1:22, Stefan E=C3=9Fer wrote: > >>> I want to omit duplicate work and if anybody else is interested in th= is > >>> driver or already working on it, I'd like to combine efforts (or migh= t > >>> wait for a nearly ready driver to be published)=2E > >> > >> I don't think anyone is=2E=C2=A0 I asked about RTL8125 support a while b= ack and > >> got crickets=2E >=20 > I've just started working on creating a port of the official Realtek > driver=2E Latest release should support the 8125 chipset and WOL=2E It > should be ready very soon (likely today or tomorrow)=2E Not trying to derail this thread, or anything=2E But my initial search on this chip indicated: https://realtek-download=2Ecom/05-08-2019-realtek-pcie-fe-gbe-2-5gbe-family-c= ontroller-updated/ ( realtek pcie fe gbe 2=2E5gbe family controller updated ) In the article it is indicated that (among other drivers): FreeBSD 7=2Ex and 8=2E0 Updated to version 1=2E95 were updated=2E I only mention this=2E In case them already providing drivers might be of help in this (your) work=2E :-) --Chris >=20 > --=20 > Alex Dupre >=20 > _______________________________________________ > freebsd-hackers@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd=2Eorg= " From owner-freebsd-hackers@freebsd.org Wed Jul 15 22:14:21 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 801893705D3 for ; Wed, 15 Jul 2020 22:14:21 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6WrX1BzNz40Vg; Wed, 15 Jul 2020 22:14:19 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 06FMEjQT089713 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Jul 2020 15:14:52 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: Alex Dupre , =?UTF-8?B?U3RlZmFuIEXDn2Vy?= , Mel Pilgrim , FreeBSD Hackers In-Reply-To: <32ae27cb-2fd8-bbe8-bbda-57fc60f0ef89@t-online.de> From: Chris Reply-To: bsd-lists@BSDforge.com To: =?UTF-8?B?U3RlZmFuIEXDn2Vy?= Subject: Re: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? Date: Wed, 15 Jul 2020 15:14:51 -0700 Message-Id: <31a5001f9da0e7b89c49cc14ff1fe78b@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4B6WrX1BzNz40Vg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 22:14:21 -0000 On Wed, 15 Jul 2020 19:42:17 +0200 Stefan E=C3=9Fer st_esser@t-online=2Ede sa= id > Am 15=2E07=2E20 um 18:31 schrieb Chris: > > On Wed, 15 Jul 2020 08:22:13 +0200 Alex Dupre ale@FreeBSD=2Eorg said > >=20 > >> Stefan E=C3=9Fer wrote: > >> > Am 15=2E07=2E20 um 02:30 schrieb Mel Pilgrim: > >> >> On 2020-07-14 1:22, Stefan E=C3=9Fer wrote: > >> >>> I want to omit duplicate work and if anybody else is interested in > >> this > >> >>> driver or already working on it, I'd like to combine efforts (or > >> might > >> >>> wait for a nearly ready driver to be published)=2E > >> >> > >> >> I don't think anyone is=2E=C2=A0 I asked about RTL8125 support a whil= e > >> back and > >> >> got crickets=2E > >> > >> I've just started working on creating a port of the official Realtek > >> driver=2E Latest release should support the 8125 chipset and WOL=2E It > >> should be ready very soon (likely today or tomorrow)=2E > > Not trying to derail this thread, or anything=2E But my initial search on > > this chip indicated: > > > > https://realtek-download=2Ecom/05-08-2019-realtek-pcie-fe-gbe-2-5gbe-fami= ly-controller-updated/ > >=20 > > ( realtek pcie fe gbe 2=2E5gbe family controller updated ) > > In the article it is indicated that (among other drivers): > > FreeBSD 7=2Ex and 8=2E0 Updated to version 1=2E95 > > were updated=2E I only mention this=2E In case them already providing drive= rs > > might be of help in this (your) work=2E :-) >=20 > Yes, and I have used that exact driver to merge the missing defines > into the header file currently in FreeBSD-CURRENT=2E This is a first > step towards a unified driver =2E=2E=2E >=20 > As the compatibility with FreeBSD-7 and -8 indicates, the driver > offered by Realtek does not implement changes that have been applied > to our if_re=2Ec=2E >=20 > Alex has created a port for a kernel module, which works quite well, in > fact I've received your message on a PC with that chip and driver=2E ;-) Cool! :-) >=20 > The Realtek code must be merged into our driver, to get a version that > does not fall back behind our current state (e=2Eg=2E with regard to the > statistics counters)=2E >=20 > If Alex is doing that work, that would be fine with me=2E Else I'll try > to get the re driver in base updated to support the new chips in > addition to the already supported ones=2E Looks like it's time for me to go shopping=2E :-) Thanks! >=20 > Regards, STefan --Chris From owner-freebsd-hackers@freebsd.org Wed Jul 15 22:25:16 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C9E723705F9; Wed, 15 Jul 2020 22:25:16 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6X580J4tz4JJX; Wed, 15 Jul 2020 22:25:16 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id BA40A1561C; Wed, 15 Jul 2020 22:25:15 +0000 (UTC) Date: Thu, 16 Jul 2020 00:25:13 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2020 Message-ID: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zpkl3mlsiuohrpr7" Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 22:25:17 -0000 --zpkl3mlsiuohrpr7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="report-2020-04-2020-06.txt" Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - Second Quarter 2020 Introduction This report will be covering FreeBSD related projects between April and June, and covers a diverse set of topics ranging from kernel updates over userland and ports, as well to third-party work. Some hilights picked with the roll of a d100 include, but are not limited to, the ability to forcibly unmounting UFS when the underlying media becomes inaccessible, added preliminary support for Bluetooth Low Energy, a introduction to the FreeBSD Office Hours, and a repository of software collections called potluck to be installed with the pot utility, as well as many many more things. As a little treat, readers can also get a rare report from the quarterly team. Finally, on behalf of the quarterly team, I would like to extend my deepest appreciation and thank you to salvadore@, who decided to take down his shingle. His contributions not just the quarterly reports themselves, but also the surrounding tooling to many-fold ease the work, are immeassurable. We hope you find the report as interesting as we have, Daniel Ebdrup Jensen (debdrup@), on behalf of the quarterly team. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Foundation * FreeBSD Core Team * FreeBSD Release Engineering Team * Cluster Administration Team * Continuous Integration * Ports Collection * FreeBSD Office Hours * Quarterly Status Reports Team Projects * FreeBSD on Microsoft HyperV and Azure * Git Migration Working Group * Lua Usage in FreeBSD * Linux compatibility layer update * NFS over TLS implementation Kernel * SoC audio framework and more audio drivers * bhyve - NVMe emulation improvements * Bluetooth Support * DRM Drivers Update * DTS Update * ENA FreeBSD Driver Update * Forcible Unmount of UFS/FFS Filesystems on Disk Failure * i.MX 8M support * Intel wireless and 11ac update * amd64 5-Level Paging Structures support * Not-transparent superpages * NXP ARM64 SoC support * amd64 pmap Fine-grained pv lists locking * Lockless routing lookups and scalable multipath * ZSTD Compression in ZFS * CheriBSD 2020 Q2 Architectures * Continuous Integration on !x86 * FreeBSD/RISC-V Project Userland Programs * Import of new implementation of bc and dc * Binutils Retirement * Run-Time Dynamic Linker improvements * VHDX support in mkimg(1) Ports * Bastille * KDE on FreeBSD * Haskell on FreeBSD * rtsx - Porting driver for Realtek SD card reader from OpenBSD * Valgrind updates Documentation * FreeBSD Translations on Weblate Miscellaneous * FreshPorts * PCI passthrough with bhyve on Intel and for OpenBSD guests * SageMath Third-Party Projects * chaifi - a tool to simplify joining public WiFi networks * MixerTUI * Potluck - Flavour & Image Repository for pot __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. 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: COVID-19 Impact to the Foundation Like other organizations, we put policies in place for all of our staff members to work from home. We also put a temporary ban on travel for staff members. We are continuing our work supporting the community and Project, but some of our work and responses may be delayed because of changes in some of our priorities and the impact of limited childcare for a few of our staff members. Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. Not surprisingly, the stay at home orders, combined with our company ban on travel during Q2 made in-person meetings non-existent. However, the team was able to continue meeting with our partners and commercial users virtually. These meetings help us understand some of the applications where FreeBSD is used. Fundraising Efforts Last quarter we raised $268,400! Thank you to the individuals and organizations that stepped in to help fund our efforts. We'd like to thank Netflix, employees of Nginx, Beckhoff Automation, and Mozilla Foundation for their large contributions last quarter, which helped bring our 2020 fundraising effort to $339k. We hope other organizations will follow their lead and give back to help us continue supporting FreeBSD. These are trying times, and we deeply appreciate every donation that has come in from $5 to $150,000. We're still here giving 110% to supporting FreeBSD! We are 100% funded by donations, and those funds go towards software development work to improve FreeBSD, FreeBSD advocacy around the world, keeping FreeBSD secure, continuous integration improvements, sponsoring BSD-related and computing conferences (even the virtual events!), legal support for the Project, and many other areas. Please consider making a donation to help us continue and increase our support for FreeBSD. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information about the partnership program and share with your companies! OS Improvements A number of FreeBSD Foundation grant recipients started, continued working on, or completed projects during the second quarter. These include: * WiFi improvements * Linuxulator application compatibility * DRM / Graphics driver updates * Zstd compression for OpenZFS * Online RAID-Z expansion * if_bridge performance improvements You can find more details about most of these projects in other quarterly reports. Staff members also worked on a number of larger projects, including: * Run-Time Dynamic Linker (rtld) improvements * Improved FreeBSD support on Microsoft HyperV and Azure * Fine-grained locking for amd64 pmap * 5-level paging structures for amd64 * Non-transparent superpages * Migration to a Git repository * Tool chain modernization Many of these projects also have detailed entries in other quarterly report entries. Staff members also put in significant effort in many ways other than larger, individual projects. These include assisting with code reviews, bug report triage, security report triage and advisory handling, addressing syzkaller reports, and ongoing maintenance and bug fixes in functional areas such as the tool chain, developer tools, virtual memory kernel subsystem, low-level x86 infrastructure, sockets and protocols, and others. University of Waterloo Co-op Foundation co-op students Colin, Tiger, and Yang completed their winter 2020 work term during the second quarter, and continued on with the next school term in their respective programs. Although COVID-19 presented a unique challenge and prompted an abrupt transition to remote work just over half way through the term, all three learned a lot and provided positive contributions to the FreeBSD Project and to the Foundation. A few projects that were in progress or completed during the work term were committed to the FreeBSD tree in the second quarter. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member who is working on improving continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. During the second quarter of 2020, Foundation staff continued improving the Project's CI infrastructure, monitoring regressions and working with contributors to fix the failing build and test cases. The setting up of VM host for CI jobs and staging environment is in progress. We are also working with other teams in the Project for their testing needs. For example, we added jobs for running full tests on non-x86 architectures. We are also working with many external projects and companies to improve their support of FreeBSD. See the FreeBSD CI section of this report for completed work items and detailed information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. We started working on getting the new NYI Chicago colocation facility prepared for some of the new FreeBSD hardware we are planning on purchasing. NYI generously provides this for free to the Project. 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. As is the case for most of us in this industry, COVID-19 has put our in-person events on hold. In addition to attending virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: * Silver sponsor of BSDCan 2020. The event was held virtually, June 2-6, 2020 * Community Sponsor of Rootconf 2020. The event was held virtually, June 19-20, 2020 * Annual FreeBSD Day, June 19. This year's celebration was postponed in support of Juneteeth. However the activities surrounding FreeBSD Day have been transformed into an ongoing series of online sessions. See FreeBSD Fridays below for more information. * Presented 27 Years of FreeBSD and Why You Should Get Involved as part of a Linux Professional Institute series of webinars on June 24, 2020. * Attended and presented at the virtual Open Source Summit 2020. * Announced FreeBSD Fridays: A series of 101 classes designed to get you started with FreeBSD. Find out more in the announcement * Participated as an Admin for Google Summer of Code 2020 * Participated in the new FreeBSD Office Hours series including holding our own Foundation led office hours. Videos from the one hour sessions can be found on the Project's YouTube Channel. You can watch ours here. In addition to the information found in the Development Projects update section of this report, take a minute to check out the latest update blogs: * 5x if_bridge Performance Improvement * My Experience as a FreeBSD Foundation Co-Op Student Keep up to date with our latest work in our Bi-Monthly newsletters. Mellanox provided an update on how and why they use FreeBSD in our latest Contributor Case Study. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues on the Journal site. You can find out more about events we attended and upcoming events. We have continued our work with a new website developer to help us improve our website. Work is nearly complete to make it easier for community members to find information more easily and to make the site more efficient. We look forward to unveiling the refreshed site in Q3. Foundation Board Meeting Our annual board meeting was held on Tuesday June 2, 2020. We normally hold this meeting the Tuesday before BSDCan, in Ottawa, Ontario, Canada, but with the company travel ban, and the conference going virtual, our meeting went virtual for the first time. The purpose of the annual board meeting is to hold our board director and officer elections, review work accomplished over the past year, and put together strategic goals for the upcoming 12 months. The board generally has two all-day board meetings each year, this one, and a more informal one in January, typically held in Berkeley. Both meetings allow us to connect, reevaluate and discuss new ideas, while assessing what we should do to help the Project. Some of our longer-term goals include Growing User and Developer Communities, Developing Training and OS Course Content, Improving desktop/laptop experience, Promoting FreeBSD (as you can see in all the advocacy work listed above), and Improving Testing Capabilities. Results of the director and officer elections were: * Justin Gibbs (President) * Benedict Reuschling (Vice President) * Kirk McKusick (Treasurer) * Philip Paeps (Secretary) * Deb Goodkin (Assistant Secretary) * Robert Watson (Director) * Hiroki Sato (Director) * George Neville-Neil (Director) Find out more about the FreeBSD Foundation Board of Directors on our website. 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 the FreeBSD Foundation's web site to find out how we support FreeBSD and how we can help you! __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. The Core Team held 10 meetings during the second quarter of 2020, including a 2020-05-21 joint meeting with members of the FreeBSD Foundation. Here are some highlights from that meeting: * Deb requested guidance on how the Foundation can support the community. Core and Foundation members believe that more developer support is necessary to fill gaps in areas where commercial customers do not provide backing. The clearest example of such a gap is the desktop experience, including graphics and wireless support. What makes this request different from past requests is that rather than support for one-time projects, ongoing positions are necessary for a consistently high-quality desktop experience. "FreeBSD not being able to run on your laptop is the first step to irrelevance." Ed Maste * Both teams discussed topics for upcoming sessions of FreeBSD Office Hours, informal FreeBSD video conferences that anyone can attend. Everyone agreed that the Office Hours have been a useful way for different parts of the Project to engage with each other and with the wider community. Kudos to Allan Jude for initiating the Office Hours and for everyone who has helped make them a success by hosting or attending sessions. * Both teams agreed that they should meet once per quarter. The second annual community survey closed on 2020-06-16. The purpose of the survey is to collect data from the public to help guide the Project's efforts and priorities. As an example, last year's survey results helped initiate the Project's conversion to Git. Thank you to all who took the time to respond. The results will be released soon. The Core-initiated Git Working Group continued to make progress, but there are still some remaining issues to be worked out with the translation from Subversion. Hopefully the new Git src repository will be ready for use this summer. A beta version has been published for people to test and a preliminary version of a Using Git for FreeBSD Development primer will soon be ready to share. Core, the Git Working Group, and Release Engineering are working towards the goal of releasing 12.2 from the new Git repository. Following the results of a Core-initiated developer survey, The FreeBSD Project has adopted a new LLVM-derived [code of conduct](https://www.freebsd.org/internal/code-of-conduct.html). The eleventh FreeBSD Core Team was elected by active developers. From a pool of 23, the 9 successful candidates for core.11 are: * Sean Chittenden (seanc, incumbent) * Baptiste Daroussin (bapt) * Kyle Evans (kevans) * Mark Johnston (markj) * Scott Long (scottl) * Warner Losh (imp, incumbent) * Ed Maste (emaste) * George V. Neville-Neil (gnn) * Hiroki Sato (hrs, incumbent) A new Core Team secretary, Muhammad Moinur Rahman (bofh), was unanimously approved by core.11. The outgoing core team met three times with the new core team to help with the transition. Core.10 wishes core.11 a successful term. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 11.4-RELEASE announcement=20 URL: https://www.freebsd.org/releases/11.4R/announce.html FreeBSD 11.4-RELEASE schedule=20 URL: https://www.freebsd.org/releases/11.4R/schedule.html FreeBSD development snapshots=20 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 slushes, and maintaining the respective branches, among other things. During the second quarter of 2020, the Release Engineering Team started work on the 11.4-RELEASE cycle, the fifth release from the stable/11 branch. The release cycle went quite smoothly, with both BETA3 and RC3 removed from the schedule. This allowed the final release to occur one week earlier than originally scheduled, which was announced June 16. FreeBSD 11.4-RELEASE is expected to be the final 11.x release. The FreeBSD Release Engineering Team would like to thank everyone involved in this cycle for their hard work. 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 Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation. __________________________________________________________________ Cluster Administration Team Links Cluster Administration Team members=20 URL: https://www.freebsd.org/administration.html#t-clusteradm Contact: Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Upgrade all x86 ref- and universe-machines * Setup Amsterdam (PKT) mirror * Solve hardware issue for bugzilla and svnweb backend * Setup public beta git server * Decommission CyberOne Data (CYB) mirror * Ongoing systems administration work: + Accounts management for committers. + Backups of critical infrastructure. + Keeping up with security updates in 3rd party software. Work in progress: * Setup Malaysia (KUL) mirror * Setup Brazil (BRA) mirror * Review the service jails and service administrators operation. * Infrastructure of building aarch64 and powerpc64 packages + NVME issues on PowerPC64 Power9 blocking dual socket machine from being used as pkg builder. + Drive upgrade test for pkg builders (SSDs) courtesy of the FreeBSD Foundation. + Boot issues with Aarch64 reference machines. * New NYI.net sponsored colocation space in Chicago-land area. * Work with git working group * Check new hardware requirement from other teams * Searching for more providers that can fit the requirements for a generic mirrored layout or a tiny mirror __________________________________________________________________ Continuous Integration Links FreeBSD Jenkins Instance=20 URL: https://ci.FreeBSD.org FreeBSD Hardware Testing Lab=20 URL: https://ci.FreeBSD.org/hwlab FreeBSD CI artifact archive=20 URL: https://artifact.ci.FreeBSD.org FreeBSD CI weekly report=20 URL: https://hackmd.io/@FreeBSD-CI FreeBSD Jenkins wiki=20 URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki=20 URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI=20 URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@=20 URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository=20 URL: https://github.com/freebsd/freebsd-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system for the FreeBSD project. The CI system firstly checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from the build jobs are archived in the artifact server for 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 codes or adjust test infrastructure. The details of these efforts are available in the weekly CI reports. During the second quarter of 2020, we continue working with the contributors and developers in the project for their testing needs and also keep working with external projects and companies to improve their support of FreeBSD. Important changes: * All -test jobs will run tests under /usr/tests, previously only x86 architectures doing this. See the Continuous Integration on !x86 section in this report for more information. * Compression algorithm of disk images on the artifact server has been changed to zstd to speed up compression and decompression. * The build and test results will be sent to the dev-ci mailing list soon. Feedback and help with analysis is very appreciated! New jobs added: * https://ci.freebsd.org/job/FreeBSD-head-armv7-test/ * https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/ * https://ci.freebsd.org/job/FreeBSD-head-mips64-test/ * https://ci.freebsd.org/job/FreeBSD-head-powerpc64-test/ Work in progress: * Collecting and sorting CI tasks and ideas here * Testing and merging pull requests in the the FreeBSD-ci repo * Setting up a builder dedicated to run jobs using provisioned VMs. * Setting up the CI stage environment and putting the experimental jobs on it * Implementing automatic tests on bare metal hardware * Adding drm ports building tests against -CURRENT * Planning to run ztest and network stack tests * Adding external toolchain related jobs * Improving the hardware lab to be more mature and adding more hardware * Helping more 3rd software get CI on FreeBSD through a hosted CI solution * Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and don't hesistate to join the effort! Sponsor: The FreeBSD Foundation __________________________________________________________________ Ports Collection Links About FreeBSD Ports=20 URL: https://www.FreeBSD.org/ports/ Contributing to Ports=20 URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring=20 URL: http://portsmon.freebsd.org/index.html Ports Management Team=20 URL: https://www.freebsd.org/portmgr/index.html Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. There are currently 2,373 open ports PRs of which 526 are unassigned, for a total of 39,628 ports. In the last quarter there were 10,315 commits to HEAD and 476 to the quarterly branch by respectively 178 and 65 committers. Compared to the quarter before, this means a significant increase in commits and also a slight decrease in open PRs. During the last quarter, we welcomed Hiroki Tagato (tagattie@). We said goodbye to seanc@, zleslie@, gnn@ and salvadore@. A few default versions got bumped: * Java (new) at 8 * Lazarus to 2.0.8 It is now possible to write pkg scripts in Lua instead of sh. They have two advantages over their sh versions: * they run in a Capsicum sandbox * they respect rootdir, the directory which pkg will use as the starting point to install all packages under. Some user-facing packages were also updated: * pkg to 1.14.6 * Firefox to 78.0.1 * Thunderbird to 68.10.0 * Chromium to 83.0.4103.116 * Ruby to 2.5.8, 2.6.6, and 2.7.1 * Qt5 to 5.14.2 During the last quarter, antoine@ ran 55 exp-runs to test port version updates, make liblzma use libmd, flavor devel/scons and Lua ports, add and update library functions in the base system, make malloc.h usable again, remove as(1) from the base system, and augment sed(1) with -f. __________________________________________________________________ FreeBSD Office Hours Links Office Hours on the FreeBSD Wiki=20 URL: https://wiki.freebsd.org/OfficeHours Poll: What time would you prefer Office Hours be at=20 URL: https://forms.gle/3HjjRx9KMcM3SL4H7 live.FreeBSD.org: Aggregation of Live streams=20 URL: https://live.freebsd.org/ Contact: Allan Jude Starting on the first of April 2020, the FreeBSD project has started hosting regular video streams to foster greater communication within the wider FreeBSD community. The first of these sessions took the form of a public question and answer session, which drew over 60 participants. A second session was held two weeks later at a time more appropriate for those in Asia, but only drew 20 participants. With the help of the FreeBSD Foundation, we ran a poll to discover what times worked best for the greatest number of people. On May 13th the FreeBSD Foundation hosted a session where the community could ask questions of or about the foundation. On May 27th many of the candidates for the new FreeBSD Core Team joined an office hours session to answer questions from the community. Finally on June 24th another general question and answer office hours was held. Each office hours session consists of a video meeting of some FreeBSD developers or other subject matter experts, live streamed along with an IRC chat room for viewers to pose questions to the panel. The stream is recorded and posted to the official FreeBSD youtube channel. If you would like to host an office hours session, please contact: * Allan Jude * Anne Dickison Sponsor: ScaleEngine Inc. (video streaming) __________________________________________________________________ Quarterly Status Reports Team Links Quarterly status reports=20 URL: https://www.freebsd.org/news/status/ Git repository =20 URL: https://github.com/freebsd/freebsd-quarterly Contact: Quarterly Status Reports Contact: Daniel Ebdrup Jensen The Quarterly Status Reports Team collects and publish the reports that you are reading right now. Many improvements have been done recently and thus we believe it is useful that the Quarterly Status Reports Team submits a report. Not all the changes below are specific to the last quarter, but we list them here anyway since we did not write an entry for earlier reports. * Reports are now built using Makefiles. Among the many advantages, this allows us to easily sort reports logically. Indeed, starting with 2019Q4, all reports are sorted logically, while before they were sorted alphabetically within each category. * The conversion from markdown to docbook was performed using a python script, with some known bugs. Salvadore has rewritten the script using perl fixing most of the bugs. Some features are missing and many improvements are possible, but the script is very unlikely to receive any change since it will become obsolete as soon as the conversion to Hugo/AsciiDoctor is completed. * Another perl script to ease the preparation of the mail version of the reports was written. * One more perl script has been written to allow the quarterly team to send quarterly calls automatically using a cron job. We used it this quarter for the first time. * As you might have noticed, last quarterly calls have been sent to freebsd-quarterly-calls@: this is a new mailing list to which you can subscribe to receive calls for quarterly reports. Please note this is a moderated list, with very low traffic and a high signal to noise ratio. * If you read carefully the last quarterly calls, you should have noticed that we now ask you to send reports to quarterly-submissions@ instead of quarterly@. This was done to help the quarterly team distinguishing internal discussions from submissions. Please keep in mind however that the quarterly team prefers receiving pull requests, as they ease the administrative work. We would like to thank philip@, from the postmaster team, for having created the freebsd-quarterly-calls@ mailing list and the quarterly-submissions@ address for us. __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. FreeBSD on Microsoft HyperV and Azure Links FreeBSD on MicrosoftAzure wiki=20 URL: https://wiki.freebsd.org/MicrosoftAzure FreeBSD on Microsoft HyperV =20 URL: https://wiki.freebsd.org/HyperV Contact: FreeBSD Integration Services Team Contact: Wei Hu Contact: Li-Wen Hsu HyperV socket for FreeBSD implemented by Wei was checked into FreeBSD head branch on May 20th as r361275. It supports guest/host communications without the need for networking. Some HyperV and Azure features rely on this to be available in guests. Details of HyperV Socket is available here. This project is sponsored by Microsoft. Li-Wen is working on the FreeBSD release code related to Azure for the -CURRENT, 12-STABLE and 11-STABLE branches. The work-in-progress is available here. The 12.1-RELEASE image on Azure Marketplace is published. The work on the 11.4-RELEASE image on Azure Marketplace is in progress. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Git Migration Working Group Links Git conversion tooling repo=20 URL: https://github.com/freebsd/git_conv FreeBSD-git mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-git Beta doc git repo=20 URL: https://cgit-beta.FreeBSD.org/doc Beta ports git repo=20 URL: https://cgit-beta.FreeBSD.org/ports Beta src git repo=20 URL: https://cgit-beta.FreeBSD.org/src Contact: Ed Maste Contact: Warner Losh Contact: Ulrich Sp=F6rlein Work continues on FreeBSD's migration from Subversion to Git. Ulrich has iterated on updates to svn2git in order to improve the fidelity of the conversion, particularly in regards to vendor (contrib) code updates. We believe the conversion is now at an acceptable state, but may make minor adjustments if additional issues are found. We expect to push modifications to the converter every two weeks (first and third Sunday of the month). This means that commit hashes in the beta repo will remain stable for at least two weeks at a time, to allow others to test and experiment with the beta repo. We are now working on updating FreeBSD processes and documentation. This includes: * Writing a Git Primer, akin to the existing Subversion primer * Updates to the Security Team's tools and processes * Release engineering updates * Ports and packages process updates Those with an interest in the migration to Git are encouraged to subscribe to the FreeBSD-git mailing list and test out the beta src, ports, and/or doc repositories. You are also welcome check out the wiki, issues, README and other documentation at the Git conversion tooling repo. We expect to be ready for the migration in the next quarter. Sponsor: The FreeBSD Foundation (in part) __________________________________________________________________ Lua Usage in FreeBSD Contact: Ed Maste Contact: Kyle Evans Contact: Ryan Moeller Lua is a small, efficient scripting language that FreeBSD imported before FreeBSD 12.0 for use in the bootloader. Since then, several projects outside of the bootloader have gained some amount of traction with Lua usage: * /usr/libexec/flua is now installed for internal usage * makesyscalls.sh was rewritten in Lua * pkg has gained support for lua scripts * lldb in the base system now supports lua scripting FreeBSD Lua ("flua") is a version of the lua interpreter that has several modules built-in for convenient usage within the base system. flua is installed with a non-standard name and in a location not included in $PATH so that it is not accidentally found by third-party software or configure scripts. The FreeBSD project makes no guarantees about upgrade cadence or module stability. That said, it is available for use by downstream projects and FreeBSD users aware of those limitations. Previous work with flua includes, for example, adding libucl support and future work includes libifconfig support for scripting usage. People interested in working with Lua in FreeBSD are welcome to get in contact to discuss other project ideas. To name a couple of potential projects, some interesting modules that have not been started but could prove useful (listed in no particular order): * libcrypt * libexpat * libjail * libnv * libxo __________________________________________________________________ Linux compatibility layer update Contact: Edward Tomasz Napierala Earlier Linuxulator work focused on code cleanups and improving diagnostic tools. Work has now shifted from cleanups to fixing actual applications. Current status is being tracked at Linux app status Wiki page. Initial focus is on applications that don't involve X11, mostly because they tend to be easier to test and debug, and the bug fixes are not application-specific. Example problems fixed include buggy madvise(2) handling, which could break applications linked against jemalloc; uname(2) returning wrong results for 32 bit apps, which caused problems for Steam; recvmsg(2) and accept(2) being broken in some circumstances, which was breaking Redis; and missing support for SO_REUSEPORT, SO_SNDBUFFORCE, SO_RCVBUFFORCE, and SO_PROTOCOL, which spammed the log files when running the Python regression test suite. The default soft open files limit is now automatically adjusted to 1024, as several Linux apps iterate over all the file descriptors up to that limit instead of using closefrom(2). There's ongoing work on cleanups and the debugging framework for Linux compatibility, such as logging warnings for unrecognized system call parameters, or adding the compat.linux.debug sysctl to turn the warnings off. The Linux Test Project tests that are being run as part of the the FreeBSD Continuous Integration infrastructure has been upgraded to 20200605 snapshot. This raised the number of test cases from 3670 to 3749, and, predictably, also the number of failures, from 583 to 647. There's still a lot to do: * There are pending reviews for patches that add extended attributes support, and fexecve(2) syscall, and they require wrapping up and committing * There are over 500 failing LTP tests. Some of them are false positives, some are easy to fix bugs, and some require adding new system calls. Any help is welcome. Sponsor: The FreeBSD Foundation __________________________________________________________________ NFS over TLS implementation Contact: Rick Macklem In an effort to improve NFS security, an internet draft which I expect will become an RFC soon specifies the use of TLS 1.3 to encrypt all data traffic on a Sun RPC connection used for NFS. Although NFS has been able to use sec=3Dkrb5p to encrypt data on the wire, this requires a Kerberos environment and, as such, has not been widely adopted. It also required that encryption/decryption be done in software, since only the RPC message NFS arguments are encrypted. Since Kernel TLS is capable of using hardware assist to improve performance and does not require Kerberos, NFS over TLS may be more widely adopted, once implementations are available. The project to implement this has largely been completed. The code will slowly be merged into head/current and at least the kernel portion should be in FreeBSD-13. To support clients such as laptops, the daemons that perform the TLS handshake may optionally handle client X.509 certificates from a site local CA. There are now exports(5) options to require client(s) to provide a valid X.509 certificate. The code is now available for testing. See: https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt Setting up system(s) for testing is still a little awkward, as explained by the above rough document. The main limitation in the current implementation is that it uses TLS1.2 and not TLS1.3. This should change once the KERN_TLS rx patch includes TLS1.3 support. Also, testing of pNFS configurations has not yet been done, but will be tested soon. Third party testing would be appreciated. __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. SoC audio framework and more audio drivers Links rk3399_audio=20 URL: https://github.com/gonzoua/freebsd/tree/rk3399_audio Contact: Oleksandr Tymoshenko SoC audio framework made a good progress since last report. Support for AUX devices was added (devices like auxiliary amplifiers that are not part of main CODEC chip). To verify the framework design following audio drivers were added: recording support for RT5640 CODEC(Firefly-RK3399), Allwinner I2S, Alwinners sun8i and A64 CODECs (Pine A64+), both recording and playback. Current work in progress is RK3328 CODEC (Rock64) and ES8316 CODEC (RockPro64 and Pinebook Pro). __________________________________________________________________ bhyve - NVMe emulation improvements Links bhyve NVMe reviews=20 URL: https://reviews.freebsd.org/search/query/xvbcF20W__Km/ Contact: Chuck Tuffli The University of New Hampshire InterOperability Laboratory (a.k.a. UNH IOL) develops a suite of tests to determine if an NVMe device conforms to the specification and is interoperable with other NVMe products. This quarter, I undertook getting bhyve's emulated NVMe device to pass the mandatory tests. Changes include: * implement Flush command * implement Format NVM command * implement AER support * implement Namespace Identification Descriptor * fix Active Namespace list * fix queue creation and deletion * validate Deallocate range values * handle zero length DSM ranges * fix Get Log Page command * implement SMART data I/O statistics * validate the LBA start and count * add basic Firmware Commit support * add more compliant Get/Set Features * add Feature, Interrupt Vector Config * fix Get Features, Predictable Latency This was also a good opportunity to restructure parts of the code to make it more modular and easier to enhance. This includes * convert logging statements to parameterized macros * refactor I/O command handling * add locks around queue accesses * consolidate CQ update * base pci_nvme_ioreq size on advertised MDTS You can help by testing and/or commenting on the code reviews. __________________________________________________________________ Bluetooth Support Contact: Marc Veldman Bluetooth is a wireless technology for creating personal networks, connecting peripherals like keyboards and mice but also speakers and heart rate monitors. FreeBSD has limited Bluetooth Basic Rate (BR) support and no functional Bluetooth Low Energy (LE) support. During this quarter many small improvements have been made to help the development of Bluetooth LE support. A number of commands have been added to hccontrol(8), mainly to do LE functions. It is now possible to scan for LE devices within range using hccontrol. A panic that occurred when enabling LE support has also been fixed. Work is still needed to add Attribute Protocol (ATT) and Generic Attribute Profile (GATT) support. __________________________________________________________________ DRM Drivers Update Links drm-kmod=20 URL: https://github.com/freebsd/drm-kmod/ Contact: Emmanuel Vadot The drm drivers for FreeBSD 13-CURRENT have been updated to match Linux 5.3 This brings us a little bit closer to the last LTS release of Linux (5.4). The current plan is to first update the driver to match 5.4 and then look at making it work on FreeBSD-12-STABLE to have it ready for the 12.2 release. Sponsor: The FreeBSD Foundation __________________________________________________________________ DTS Update Contact: Emmanuel Vadot DTS files (Device Tree Sources) were updated to be on par with Linux 5.7 for HEAD and 5.6 for the 12-STABLE branch. __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README=20 URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/R= EADME Contact: Michal Krawczyk Contact: Artur Rojek 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. Completed since the last update: * Fixes for Rx refill to improve stability on low memory conditions (also released as an errata notice for FreeBSD-12.1) * Upstream of the v2.2.0 driver, introducing: + Add driver support for the upcoming HW features (reporting Tx drops, disabling meta caching) + Add sysctl tuneables for IO queue number + Create IO queues with optional size backoff + Rework the way of configration of drbr and Rx ring size to be more robust and stable + New HAL version + Driver is now marked as epoch ready + Default RSS key is created using RNG to improve security + Other minor fixes and improvements * MFC of the ENA v2.2.0 driver to the FreeBSD 11.4 Sponsor: Amazon.com Inc __________________________________________________________________ Forcible Unmount of UFS/FFS Filesystems on Disk Failure Links Phabricator Details=20 URL: https://reviews.freebsd.org/D24088 Contact: Chuck Silvers Contact: Kirk McKusick Commit -r361491 on May 25, 2020 enables a UFS file system to do a forcible unmount when the underlying media fails or becomes inaccessible. For example when a USB flash memory card hosting a UFS file system is unplugged. The rest of this report describes in more detail how forcible unmounts are done. Suprisingly, less than 500 lines of file system code were added or changed. The strategy for handling disk I/O errors when soft updates are enabled is to stop writing to the disk of the affected file system but continue to accept I/O requests and report that all future writes by the file system to that disk actually succeed. Then initiate an asynchronous forced unmount of the affected file system. There are two cases for disk I/O errors: * ENXIO, which means that this disk is gone and the lower layers of the storage stack already guarantee that no future I/O to this disk will succeed. * EIO (or most other errors), which means that this particular I/O request has failed but subsequent I/O requests to this disk might still succeed. For ENXIO, we can just clear the error and continue, because we know that the file system cannot affect the on-disk state after we see this error. For EIO or other errors, we arrange for the geom_vfs layer to reject all future I/O requests with ENXIO just like is done when the geom_vfs is orphaned. In both cases, the file system code can just clear the error and proceed with the forcible unmount. This new treatment of I/O errors is needed for writes of any buffer that is involved in a dependency. Most dependencies are described by a structure attached to the buffer's b_dep field, but some are created and processed as a result of the completion of the dependencies attached to the buffer. Clearing of some dependencies require a read. For example if there is a dependency that requires an inode to be written, the disk block containing that inode must be read, the updated inode copied into place in that buffer, and the buffer then written back to disk. Often the needed buffer is already in memory and can be used. But if it needs to be read from the disk, the read will fail, so we fabricate a buffer full of zeroes and pretend that the read succeeded. This zero'ed buffer can be updated and "written" back to disk. The only case where a buffer full of zeros causes the code to do the wrong thing is when reading an inode buffer containing an inode that still has an inode dependency in memory that will reinitialize the effective link count (i_effnlink) based on the actual link count (i_nlink) that we read. To handle this case we now store the i_nlink value that we wrote in the inode dependency so that it can be restored into the zero'ed buffer thus keeping the tracking of the inode link count consistent. Because applications depend on knowing when an attempt to write their data to stable storage has failed, the fsync(2) and msync(2) system calls need to return errors if data fails to be written to stable storage. So these operations return ENXIO for every call made on files in a file system where we have otherwise been ignoring I/O errors. Sponsor: Netflix __________________________________________________________________ i.MX 8M support Links D25274=20 URL: https://reviews.freebsd.org/D25274 Contact: Oleksandr Tymoshenko i.MX 8M is the family of application processors from NXP based on Arm=AE Cortex=AE-A53 and Cortex-M4 cores. The initial code drop for the platform support includes CCM driver and clock implementation, GPC driver, clock tree for i.MX 8M Quad. Most of the drivers from i.MX 6 can be reused for i.MX 8M systems with relatively minor modifications. Common changes include adding clock support and extending list of FDT compat strings. With the linked patch FreeBSD successfully booted to multiuser with NFS root on Nitrogen8M SBC. __________________________________________________________________ Intel wireless and 11ac update Links Initial project announcement=20 URL: https://lists.freebsd.org/pipermail/freebsd-wireless/2020-April/00= 9055.html The freebsd-wireless mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-wireless Contact: Bjoern A. Zeeb The Intel Wireless cards are one of the most commonly used and ask for in FreeBSD notebooks. This project has three main goals: * newer Intel Wireless device support, * newer WiFi standards support for Intel Wireless, * integration of 802.11ac client support and infrastructure in FreeBSD. The first one is needed as iwm(4) currently does not support the latest generations of Intel Wireless cards at all. The second is needed as in FreeBSD iwm(4) does not even support 802.11n. The third one we want to catch up and use the improvements the new Wifi standard offers, e.g., speed. One of the decisions made was: rather than improving iwm(4) this work uses the dual-licensed native Linux driver under BSD license and the linuxkpi framework to stay as close to upstream as possible as a first step. This will give us several advantages, such as, the full support for all cards, quick support for new chipsets, vendor bug fixes, but also the ability to contribute back. At this point the lower level hardware attachments and the firmware loading and initialisation works. I plan to release a patchset for testing before mid-July, you can see if your currently supported or unsupported hardware will be detected. This first cut will not support any wireless operation yet, which will follow later in the year. If you want to help testing, please watch the freebsd-wireless list. Sponsor: The FreeBSD Foundation __________________________________________________________________ amd64 5-Level Paging Structures support Links Patch=20 URL: https://reviews.freebsd.org/D25273 Intel SDM=20 URL: https://software.intel.com/content/www/us/en/develop/articles/inte= l-sdm.html Intel whitepaper=20 URL: https://software.intel.com/content/www/us/en/develop/download/5-le= vel-paging-and-5-level-ept-white-paper.html Contact: Konstantin Belousov Since its introduction, x86 Long Mode (AKA 64bit execution mode, amd64 in FreeBSD terminology) uses 4-level paging structures, which provides 48 bits of virtual address space (LA48). FreeBSD evenly divides the space between userspace and kernel, giving both 47 virtual address bits. In near future Intel CPUs will start providing 5-level paging structures, i.e. giving 57 bits for virtual addresses (LA57). This means, with preservation of the existing divide between KVA and UVA, 56 bit for UVA, or 2^9 =3D 512 times more virtual memory. The amd64 pmap was modified to support both LA48 and LA57, defaulting to LA57 if hardware supports it. The tunable is provided to force using LA48 even if hardware can do LA57. The most interesting part of the patch is the switch from boot paging mode to LA57. Loaders, either legacy or UEFI, pass control to the kernel in Long Mode, which implies that the paging is turned on. This neccessarily means that it is LA48 mode. SDM states that paging mode cannot be switched while Long Mode is active, so kernel has to create new page table structures, turn Long Mode off, then load new %cr3 and finally re-enable Long Mode. I decided to only provide the larger virtual address space to usermode for the initial step, leaving KVA layout intact. The main motivation is that changing KVA arrangements requires changing the auto-tuning settings, which deserve separate work. Another argument for it is that most of the kernel memory is non-swappable, so cannot be over-commited. We have 2:1 ratio of useful KVA to physical memory (due to direct map), and until machines get more physical address lines, increasing KVA is not useful. After this was decided, creating a 5-level paging structure for kernel pmap from existing 4-level one is quite straightforward; we need to add one page for top level, create one PML5 entry to point to existing PML4 page, and create the famous self-referential entry for vtopte()/vtopde(). Care was taken to provide binary compatible layout of UVA for binaries that cannot be executed correctly with larger address space. For instance, programs could have knowledge about used bits in the addresses and used upper bits for other data, or implemented compressed pointers. Even if system runs in LA57 mode, specific binary can request LA48-compatible UVA by procctl(2) or by the flag in the FreeBSD features ELF note. Since I do not have access to a machine with LA57, development was done using QEMU. It would be interesting to try it on the real hardware. Sponsor: The FreeBSD Foundation __________________________________________________________________ Not-transparent superpages Links Patch=20 URL: https://reviews.freebsd.org/D24652 Contact: Konstantin Belousov FreeBSD already provides excellent support for superpages, in a manner completely transparent to applications. It tries to proactively prevent fragmentation, reserves contigous runs of the physical pages for linear allocations in managed objects, and auto-promote runs of small pages when they form complete superpage. The shortcomings of this approach directly follows from its strength: some applications want to get guaranteed superpage mappings, typically because the underlying physical memory is also offloaded into a hardware which also has memory mapping unit. For instance, Infiniband RMDA adapters do memory registration and remapping, which is more efficient with large pages. In such cases transparent (non-guaranteed) support cannot be used. The extension was developed for POSIX shared memory subsystem to allow the creator request that the shared memory object was backed by physically contiguous pages, with runs of specified size. The mmap(2) syscall is aware of such objects, and if the requested mapping is properly aligned, it will be served by superpages. The new type of the shared memory objects are backed by modified a physical pager, which only allocates contigous physical memory. The VM ensures that mappings of the objects are never split (clipped) on a non-superpage boundary. The fault handler is specially optimized to be very fast by quickly installing the superpage PTE, and to avoid touching all small pages constituing it. Currently the required pmap support is provided for amd64 with 2M and 1G superpage sizes. Sponsor: The FreeBSD Foundation __________________________________________________________________ NXP ARM64 SoC support Contact: Marcin Wojtas Contact: Artur Rojek Contact: Dawid Gorecki The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications. Completed since the last update: * Improve code in a couple of review cycles and merge following new features to the FreeBSD-HEAD (r361458 - r361464): + QorIQ platform clockgen driver + LS1046A clockgen driver + GPIO support for QorIQ boards + QorIQ LS10xx AHCI driver + VF610 I2C controller support + TCA6416 GPIO expander + Epson RX-8803 RTC Todo: * Upstreaming of the QorIQ SDHCI driver - it is expected to be submitted/merged to HEAD in the Q3 of 2020. Sponsor: Alstom Group __________________________________________________________________ amd64 pmap Fine-grained pv lists locking Links Patch=20 URL: https://reviews.freebsd.org/D24217 Contact: Konstantin Belousov FreeBSD kernel Virtual Memory subsystem handles 'normal' application memory, i.e. anonymous or file-backed shared and private mappings, with so called managed pages. Managed page is fully controlled by VM, which tracks it status. In particular, managed page can be made read-only for write-back to the file, or unmapped for reuse (paging). The machine-dependent VM layer, pmap, must support managed pages, for instance it must provide operations such as pmap_remove_write() to downgrade all mappings to read-only, or pmap_remove_all() to unmap the page from all address spaces. To implement this kind of operations, while not causing the overhead of scanning all page tables, pmap must track existing mappings of the page. The tracking is done by allocating a small data structure 'pv entry' per mapping, and linking all pv entries for the given page into pv list. Since pv entries come from context of different address spaces, pmap must provide synchronization to guarantee correctness of the list structures. Current pmap allocates one mutex per one 2M physical superpage in NUMA configurations, and MAXCPU =3D=3D 256 locks hashed by = the page physical address for non-NUMA. The end result is often undeserved lock aliasing causing pv list locks contention, since all 4k pages in the 2M superpage share the same lock, and reservations typically cause adjasted pages to come from the same superpage. The proposed patch creates a new kernel synchronization primitive called one byte mutex, which is embedded into the currently unused padding in machine-dependent portion of the struct vm_page. This way each page gets dedicated pv list lock without using any more memory. In the ever-important buildkernel benchmark on non-NUMA config, this change provides 2x reduction of the system time. One complication is that old locking distribution scheme made a natural fit for superpages promotion and demotion, since all embedded small pages shared the same pv list lock, and the operations basically fold/unfold corresponding pv entries. Now the promotion and demotion operations require taking all locks for constituent small pages, which provides small but measurable impact on them. It is possible to optimize it further by providing the 'superlock' on the first page from the superpage run, but the affected operations are relatively rare so that it is not even obvious that implementing the optimization would not slow down other pathes. Another important nuance of the pv entries handling is that sometimes pv entries allocator must not fail. Typically this is required when kernel makes a call to pmap_enter() which must establish new mapping, and for managed page this includes allocating the pv entry if existing cannot be reused. If allocator cannot get a fresh page from the vm_page_alloc(9), it opts to destroy some other managed mapping to either get a reusable pv entry from current pmap, or destroy enough managed mappings from some other pmap to free whole page. To do the reclamation, currently all pages from which with pv entries are allocated, are linked in the global pv chunk list, which is protected by global (per-NUMA domain) mutex. Any allocation or free of pv entry has to lock the mutex, which is apparently a contention point for large machines. Patch removes the global list of chunks, instead linking all pmaps in the global list like it is done on i386 (but for different reason). Now the global lock is only taken for pmap creation and free, which corresponds to fork/exec and exit of a process, and when pv allocator starts reclaiming from other pmaps (which is normally does not happen). Sponsor: The FreeBSD Foundation __________________________________________________________________ Lockless routing lookups and scalable multipath Links Implementation of scalable multipath=20 URL: https://reviews.freebsd.org/D24141#change-ZOjdMqgDgUr7 Contact: Alexander Chernikov The primary goal of this work is to bring scalable routing multipath implementation, enabled by default. Another goal is enabling high-performance routing lookups. Multipath will close long-standing feature gap that modern networking OS must have. Lockless routing lookups will remove lookup bottlenecks, improve both dataplane and control plane performance for the setups with large number of routes. Background The initial routing kpi was introduced back in 1980. It was a nice generic approach back then, as no one knew how the protocols would evolve. It has been enormously successful as it was able to survive for 20+ years. Unfortunately, this kpi does not try to protect subsystem internals from the outside users, resulting in tight coupling with other subsystems. As a result, making changes is hard, leading to compromises and piling technical debt. Implementation overview Most changes are based on introduction of the concept of nexthops. Nexthops are separate datastructures, containing all necessary information to perform packet forwarding such as gateway, interface and mtu. They are shared among the routes, providing more pre-computed cache-efficient data while requiring less memory. Interested reader can find more detailed description in D24141. Another overview can be found in Nexthop object talk describing Linux implementation. Multipath implementation extends nexthop concept further by introducing nexthop groups. Each route has a pointer to either nexthops or a nexthop group, decoupling lookup algorithm from the routing stack internals. Both nexthops and nexthop groups are immutable and use epoch(9)-backed reclamation. A pre-requisite for lockless routing lookup is the introduction of modular lookup framework, allowing to attach any longes-prefix-match algorithm implementation to any IPv4/IPv6 fib. Currently there are plans to use modified DIR-24-8 algorithm from DPDK for both IPv4 and IPv6 families as an example of base lockless implementation. Status * Nexthop objects [ DONE ] * Introduction of nexthop objects [ DONE ] * Conversion of old KPI users to the new one [ DONE ] * Conversion of route caching to nexthop caching [ DONE ] * Conversion of struct rtentry field access to nhop field access [ DONE ] * Eliminating old lookup KPI and hiding struct rtentry [ DONE ] Multipath [ IN PROGRESS ] * Switch control plane consumers to use (rtentry, nhop) pairs instead of rtentry to allow multipath changes happen transparently [ 90% DONE ] * Introduce nexthop group objects * Add mutipath support for the rib (routing information base) manipulation functions * Add flowid generation for outbound traffic to enable load balancing Modular longest-prefix-match lookup algorithm [ IN PROGRESS ] * Design control plane framework for attaching algorithms [ 90% DONE ] * Port IPv6 lockless lookup algorithm [ DONE ] * Port IPv4 lockless lookup algorithm __________________________________________________________________ ZSTD Compression in ZFS Contact: Allan Jude Zstandard (ZSTD) is a modern high-performance compression algorithm designed to provide the compression ratios of gzip while offering much better performance. ZSTD has been adopted in FreeBSD for a number of other uses, including compressing kernel crash dumps, as a replacement for gzip or bzip for compressing log files, and for future versions of pkg(8). This effort to complete the integration of ZSTD into ZFS is sponsored by the FreeBSD Foundation. Integrating ZSTD into ZFS will further extend the transparent compression feature of ZFS by offering higher compression ratios without the performance penalty associated with gzip. ZSTD offers compression levels ranging from 1 (low compression) to 22 (maximum compression), plus ZSTD-Fast levels that offer less compression but even greater speed. This will allow the storage administrator to select the performance-vs-compression tradeoff that best suits their needs. Tasks remaining to be completed: * Extend ZFS to support compression algorithms with large numbers of levels * Solve issues around the inheritence of compression settings * Restore compression level when reading blocks from disk * Create a future-proofing scheme to handle changing versions of ZSTD * Extend ZFS replication to handle backwards compatibility with pools that do not yet support ZSTD * Resolve issues around backwards compatibility when ZSTD is configured but not used Sponsor: The FreeBSD Foundation __________________________________________________________________ CheriBSD 2020 Q2 Links CHERI-CPU =20 URL: http://www.cheri-cpu.org DARPA FETT Bug Bounty Program=20 URL: https://fett.darpa.mil Contact: Alex Richardson Contact: Andrew Turner Contact: Brooks Davis Contact: Edward Tomasz Napierala Contact: Jessica Clarke Contact: John Baldwin Contact: Robert Watson Contact: Ruslan Bukin CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction set extensions. Support for CHERI-RISC-V in CheriBSD has continued to mature this quarter in tandem with refinements to the CHERI-RISC-V architecture. We have recently made CheriBSD's "pure capability" (CheriABI) process environment the default ABI rather than a compatibility layer. It has grown support for: * dynamically linked binaries (previously only statically-linked binaries were supported) * C++ including exceptions * sealed return address and function pointer capabilities ("sentries") which provide additional CFI protection * initial MMU protections for loading and storing tags At this point, CHERI-RISC-V support in CheriBSD is generally on par with support for CHERI-MIPS. Much of this effort has been focused on preparing CheriBSD on CHERI-RISC-V for inclusion as a demonstrator system in DARPA's Finding Exploits to Thwart Tampering (FETT Bug Bounty program). In addition, work has begun this quarter on porting CheriBSD to Arm's Morello SoC. Morello is a prototype demonstrator board which adds CHERI extensions to ARMv8-A. We've recently switched to a dev-branch model where active work takes place on the dev branch and we periodically merge to master with synchronization between CheriBSD and dependencies like CHERI-LLVM. For those interested in what it's like to program for CHERI, we've recently released a CHERI C/C++ Programming Guide. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. Continuous Integration on !x86 Contact: Edward Tomasz Napierala For quite a while the FreeBSD CI infrastructure has been running FreeBSD builds and regression tests, making it easy to spot regressions. While CI was building images for all architectures, the regression tests were only run on amd64 and i386, which means they couldn't detect architecture-specific runtime breakage on non-x86 architectures. This poses a problem not only for FreeBSD itself, but also for people working on FreeBSD forks for !x86, such as the CHERI project at University of Cambridge and SRI International. The goal of this project is to run regression tests on the remaining architectures supported by FreeBSD: ARM, ARM64, MIPS, POWER, and RISC-V. The tests are being run using common, mostly machine-independent scripts. Those required some changes to make it possible to use QEMU in addition to Bhyve, the hypervisor used for x86 tests. The sysutils/u-boot-qemu-arm and sysutils/u-boot-qemu-arm64 ports were added to the Ports Collection. Finally, each of the architectures required some tweaks, to account for different configuration requirements - for example the MIPS kernel doesn't support VirtIO disks, or even AHCI, whereas on ARM64 the U-Boot gets confused with more than one VirtIO disk. On ARM, we're currently at 52 failures and 590 skipped tests, of 5925 tests ran (https://ci.freebsd.org/job/FreeBSD-head-armv7-test/lastCompletedBuild/t= estReport/). On ARM64 it's 19 failures and 160 skipped (https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/lastCompletedBuild= /testReport/). On MIPS it's 172 failures and 734 skipped (https://ci.freebsd.org/job/FreeBSD-head-mips64-test/lastCompletedBuild/= testReport/). For POWER, and RISC-V the results are not available yet. Remaining work: * Failing regression tests need to be fixed. * The tests are quite slow on QEMU, for example the ARM64 run takes about five hours. Running them automatically after each commit would quickly overload the CI cluster. A solution would be to e.g. run them daily. * Some of the jobs still fail to produce results: powerpc64 deadlocks at the end of regression test suite due to an unkillable process, riscv64 panics randomly, and on mips64 kyua(1) often crashes on jemalloc assertion. Those might be fixed by an upcoming QEMU port update. Sponsor: DARPA __________________________________________________________________ FreeBSD/RISC-V Project Links Wiki=20 URL: https://wiki.freebsd.org/riscv Contact: Mitchell Horne Contact: freebsd-riscv Mailing List Contact: IRC #freebsd-riscv channel on freenode The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. Since RISC-V is still a young and evolving platform, one of our goals is to have FreeBSD be a well-supported option for users as RISC-V hardware increases in availability. This quarter saw a number of improvements to the boot process. The physmem interface used by arm and arm64 to enumerate physical memory resources was moved to machine-independent code and adopted on RISC-V. As a result, the kernel is now able to detect and exclude physical memory reserved by devices or firmware. A bug that prevented the kernel from using physical memory below its load address was fixed. This typically did not manifest in much waste, as the kernel is loaded 2MB after the start of physical memory by default. In future boot configurations, the impact would have been much larger. Our port for OpenSBI was updated to v0.8, bringing several new features and fixes. In particular, it brought the Hardware State Management (HSM) extension, which can be used to start and stop CPUs. FreeBSD will now use this extension whenever it detects that it is available. There has also been a lot of work done to port FreeBSD's standard bootloader, loader(8), to RISC-V. This has big advantages in terms of boot flexibility, and brings us closer to what's needed to produce official FreeBSD/RISC-V release images. By leveraging UEFI support from u-boot, loader.efi can be used in a manner similar to arm and arm64. Next quarter will likely bring u-boot ports for RISC-V targets, pending the v2020.07 release. Booting the kernel directly via SBI firmware will continue to be supported. __________________________________________________________________ Userland Programs Changes affecting the base system and programs in it. Import of new implementation of bc and dc Links Official repository =20 URL: https://git.yzena.com/gavin/bc Repository mirror on GitHub=20 URL: https://github.com/gavinhoward/bc/ Contact: Stefan Esser Contact: Gavin D. Howard A new version of bc and dc has been imported into FreeBSD-CURRENT and enabled by default. An import into 12-STABLE is planned before the end of July, but it will not be enabled by default (will require "WITH_GH_BC=3Dyes" to be set in /etc/src.conf). This version has been developed by Gavin D. Howard with the goal to provide a highly portable and POSIX compatible implementation. It offers GNU bc compatibility and should be a drop-in replacement for the bc in FreeBSD, except for standard-violating behavior of the bc currently in FreeBSD (e.g., the modulo operator). Additional features: * High performance (up to more than a factor of 100 faster than the current FreeBSD implementation in some tests) * support of message catalogs with a large number of languages supported in the current release (contributions of further translations are welcome). * Extra built-in functions and operators. * Extended library of advanced math functions * Detailed man-page explaining standard conformant and extended features * One shared binary for bc and dc (bc is not just a pre-processor that relies on dc for the actual computations) The only dc feature not supported by the dc is the execution of sub-processes, since the author considers it a security hazard for a calculator to have. This code is also available as a port and package (math/gh-bc or gh-bc), e.g. for use with a FreeBSD binary release. __________________________________________________________________ Binutils Retirement Links GPL in Base wiki page=20 URL: https://wiki.freebsd.org/GPLinBase Contact: Ed Maste We have been working on migrating to a modern and copyfree or permissively licensed toolchain for quite some time. In the last quarter we retired two obsolete GNU bintuils: objdump, and as. Many uses of objdump can be replaced with readelf, and llvm-objdump is also available in the base system. Ports that depend on objdump have been updated to rely on the GNU binutils port or package. The GNU as utility was used by both the base system and by ports. As with objdump, ports that require GNU as have generally been updated to depend on binutils. One file in the base system (skein_block_asm.s) proved troublesome during earlier attempts to migrate to using Clang's integrated assembler (IAS). However, after the update to Clang 10 (and with some trivial modifications to the source) IAS can assemble the file. Both GNU as and objdump have been removed from FreeBSD-CURRENT and will be absent from FreeBSD 13.0. TODO The final task in the binutils retirement project is to remove GNU GDB 6.1. It is currently retained for crashinfo(8). Sponsor: The FreeBSD Foundation __________________________________________________________________ Run-Time Dynamic Linker improvements Contact: Konstantin Belousov Rtld gets some number of small bug fixes and improvements. RTLD_DEEPBIND dlopen(3) flag was implemented, despite being a strange and even unsafe idea, for compatibility with glibc. Several improvements to the direct execution mode were made. Most interesting are perhaps the '-v' switch to report some configuration parameters for rtld, the ability to specify argv0 different from the executed binary name, and fixes to properly set osrel/ABI for the directly executed binary. The link_map structure that is used by tools that need to know the list of loaded shared objects (like gdb and wine) was made more compatible with glibc, while keeping existing FreeBSD ABI intact. In the course of the link_map work, it become apparent that rtld sometimes needs to report presence of features that cannot be deduced by just a runtime test for symbol presence or for function behavior. For that, a scheme of reporting features with uniformingly named symbols was designed - see the rtld(1) man-page (in CURRENT) for an explanation. Position-independent (PIE) binaries on FreeBSD are now marked with the DF_1_PIE DT_FLAG1 flag. Otherwise, such binaries are just ET_DYN objects and it is quite hard to distinguish proper dynamically shared object (DSO) from PIE binary. The problem is that for binaries, the static linker strips some information which is required for proper loading as a DSO, and additonally, binaries contains relocations like copy-relocations that cannot be handled for non-main binaries at all. With the flag addition, rtld properly detects binaries and refuses to load them with dlopen() or as DT_NEEDED dependency. ldd(1) also misdetected PIE vs. DSO, and required a fix to parse dynamic segments to not try to dlopen() them. Sponsor: The FreeBSD Foundation __________________________________________________________________ VHDX support in mkimg(1) Contact: Oleksandr Tymoshenko VHDX is the successor of Microsoft's VHD virtual drive file format. It increases maximum capacity of the virtual drive to 64TB and introduces features to better handle power/system failures. VHDX is the required format for 2nd generation Hyper-V VMs. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Bastille Links Bastille GitHub =20 URL: https://github.com/bastillebsd/bastille Bastille Templates=20 URL: https://gitlab.com/bastillebsd-templates Bastille Website =20 URL: https://bastillebsd.org Contact: Christer Edwards Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD. Bastille Templates automate container setup allowing you to easily reproduce containers as needed. Bastille is available in ports at sysutils/bastille. Q2 2020 Status In Q2 2020 Bastille merged some exciting new features into GitHub. Changes include: * experimental support for new Bastillefile template syntax * added mount and umount sub-commands * added a default Vagrantfile for simple testing * experimental support for empty containers * improvements to VNET DHCP support * cosmetic bugfixes in error output * extended config file documentation * updated bastille help output * option to (-f) force destroy container sysutils/bastille was updated to 0.6.20200414 (latest). New Bastille templates added this quarter include: * Percona database server * Asterisk SIP server * dnsmasq DNS/DHCP server (VNET required) * nginx pkg server for poudriere Everything mentioned here was done under COVID-19 quarantine. Special thanks to everyone that contributed during this time. __________________________________________________________________ KDE on FreeBSD Links KDE FreeBSD =20 URL: https://freebsd.kde.org/ KDE Community FreeBSD=20 URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software produced by the KDE Community for FreeBSD. The software includes a full desktop environment KDE Plasma, IDE KDevelop, a PIM suite Kontact and hundreds of other applications that can be used on any FreeBSD desktop machine. This quarter has been an ever-so-peculiar one. While we are used to working remotely, collaborating over the internet to update the ports tree, it's qualitatively different when the whole world locks down. Meanwhile, software continues to be released, so this quarter the kde@ team: * Restored a patch that closes down a remote TCP held by X11 applications that use the ICE library. Thanks to Colin Percival for reporting it. It went missing in one of the port updates. To prevent this in the future, the patch has been upstreamed. PR 229772. * Chased KDE-adjacent software like CMake, Cutelyst, Latte-dock and Nheko through new releases. In particular CMake takes a lot of effort every time because it is a build-time dependency of over 2000 ports. * graphics/poppler was updated to the latest upstream release. This is a low-level dependency for many document-viewing applications, and like CMake requires chasing a lot of other software. Poppler is one of the components shared between various software stacks (and "desktop environments") under the desktop@ group, in which kde@ participates. * KDE Frameworks release like clockwork, reaching KDE Frameworks 5.70 mid-may. * KDE Applications -- the KDE release service, really, which delivers libraries, applications, and add-ons -- had one large release, with 20.04.1 landing in the ports tree also mid-may and its monthly update 20.04.2 in mid-june. * Some new Wayland support for KDE Plasma -- we have not tested this on FreeBSD -- has appeared and has been duly packaged. * A great deal of preparation has gone into Qt 5.15. Many ports have been pre-emptively patched for this new -- and last -- LTS release of Qt 5. The update itself has not yet landed, pending a few last bits of fallout. The kde@ team would like to thank Antoine for many exp-runs, mikael@ for useful tips, swills@ for patience and kai@ for dealing with WebEngine. The next big round of updates for the KDE stack is slated: CMake 3.18, Qt 5.15 LTS, and KDE Frameworks 5.71. __________________________________________________________________ Haskell on FreeBSD Links Haskell language homepage=20 URL: http://www.haskell.org/ Ports development repo =20 URL: https://github.com/freebsd/freebsd-ports-haskell Contact: Gleb Popov Haskell is a general-purpose strictly-typed pure functional language. The Haskell on FreeBSD projects strives to provide the up-to-date Haskell toolchain as well as various application written in this language. This quarter brought the long-awaited GHC update, which is now at version 8.8.3. Along the compiler, the Haskell build system frontend, cabal-install, was also upgraded to 3.0.2.0. During this update, numerous Haskell ports were updated too. All existing ports of Haskell applications were migrated to USES=3Dcabal, which implements Go-style build proccess - all dependencies are compiled as part of the build. As a consequence, ports for Haskell libraries have been deprecated and removed. Upgrading GHC became a tedious task for a single person, so a new GitHub repository was created under the FreeBSD organization - freebsd-ports-haskell. Right now, work is being done on preparing another GHC upgrade in the ghc-upgrade-810 branch. Any contributions are welcome. __________________________________________________________________ rtsx - Porting driver for Realtek SD card reader from OpenBSD Links rtsx =20 URL: https://github.com/hlh-restart/rtsx PR204521=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204521 Contact: Henri Hennebert The rtsx driver for Realtek SD card reader has been ported from OpenBSD. Its development snapshot is available via the sysutils/rtsx-kmod port. From March to May 2020, the code has been completed with the help of Gary Jennejohn (gj@) and Jesper Schmitz Mouridsen (jsm@). Some tweaks have been imported from the Linux counterpart. The driver has been successfully tested with: * RTS5209 under head (Lenovo ThinkPad L520) * RTS5227 under stable/11 and releng/12.1 (HP ProBook 430 g2, Lenovo ThinkPad T450/T450s) * RTS5229 under releng/12.1 (Lenovo IdeaPad 120S-14IAP) * RTS522A under releng/12.1 and head (Intel NUC8i5BE, Lenovo ThinkPad P50s) * RTS525A under releng/12.1 (Dell Latitude E5570) * RTL8411B under stable/12 (Acer Aspire E 15 E5-576-77W6) The driver should also work for Realtek RTS5249, RTL8402 and RTL8411. More tests are welcome, especially for the devices not yet tested. These devices may require more tweaks. PR204521 contains the bulk of exchanges for completion of the code. __________________________________________________________________ Valgrind updates Links Patch for valgrind=20 URL: https://reviews.freebsd.org/D25452 Contact: Paul Floyd Contact: Kyle Evans A large amount of work has been done to rebase FreeBSD support on top of Valgrind 3.17.0, and to address numerous test suite failures. Currently, almost all of the regression tests pass on amd64. This is a major improvement over the current state of affairs, in which the Valgrind is quite out of date and is missing important functionality. Some follow-up work aims to make FreeBSD an officially supported target platform for Valgrind. The devel/valgrind-devel port is in the process of being updated to point at the new work. __________________________________________________________________ Documentation Noteworthy changes in the documentation tree, in manpages, or in external books/documents. FreeBSD Translations on Weblate Links Translate FreeBSD on Weblate wiki=20 URL: https://wiki.freebsd.org/DocTranslationOnWeblate FreeBSD Weblate Instance=20 URL: https://translate-dev.freebsd.org/ Contact: Danilo G. Baio Contact: Edson Brandi This quarter was improved the renderization of RTL (Right-to-left) languages on the FreeBSD Documentation. We faced this issue after the first RTL language joined the translations effort (fa_IR). We are looking forward to receive more languages and translators to the project as well. Q2 2020 Status * 10 languages (No new languages) * 80 registered users (33 new users since last quarter) Languages * Chinese (Simplified) (zh_CN) * Chinese (Traditional) (zh_TW) * French (fr_FR) * German (de_DE) * Italian (it_IT) * Norwegian (nb_NO) * Persian (fa_IR) * Portuguese (pt_BR) * Spanish (es_ES) * Turkish (tr-TR) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. __________________________________________________________________ Miscellaneous Objects that defy categorization. FreshPorts Links FreshPorts =20 URL: http://freshports.org/ FreshPorts blog=20 URL: http://news.freshports.org/ Contact: Dan Langille FreshPorts, and its sister site, FreshSource, have reported upon FreeBSD commits for 20 years. They cover all commits, not just ports. FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port developers and port users. For example, https://www.freshports.org/security/acme.sh/ shows the history of this port, back to its creation in May 2017. git Work on git started back in September. It was ignored for a while and started back in mid-June with the creation of new git-specific jails for commit ingress (commit processing gitdev) and for the website. Serhii (Sergey) Kozlov created a script to transform GIT commit entries into XML digestible by FreshPorts. This was a huge step foward for the effort. The next step include: * incorporate a that script the automated processes of FreshPorts * migrate to new test & stage versions of FreshPorts * test * get ready for prod Help wanted git is not far away now. I could use helpers to * review code * watch the commits on the devgit websites * catch missing stuff Thank you Packages FreshPorts now displays the packages version available from the repo sources. This covers all primary tiers (e.g. FreeBSD:12:amd64) and all secondary tiers (e.g. FreeBSD:13:powerpc64). This helps uses know what versions they can expect and when then repo was last built. Dependency lines Some things are easiest done via copy/paste. If you are working on a port Makefile and need to add a new dependency, FreshPorts shows the dependency line for that port. For example: acme.sh>0:security/acme.sh Libraries are also covered by this feature. Python ports were recently adjusted to display ${PYTHON_PKGNAMEPREFIX}virtualenv>0:devel/py-virtualenv instead of py37-virtualenv>0:devel/py-virtualenv You can read more about this change in [issue #73](https://github.com/FreshPorts/freshports/issues/73). Watch ports I maintain The search page has long had the "Ports I Maintain" button (if you are logged in). This feature recently branched out to a new automated watch list option: Watch ports I maintain. This report subscription will notify you of any commits to the ports you maintain. Your email address on FreshPorts must match the value in the MAINTAINER field of the port. This is always a daily report. From time to time, an infrastructure change will occur which touches your port. This feature ensures you know about that change. Repology links Repology links were requested. This allows you to see what versions of that port are in the repositories of other systems. A link to repology.org appears on every port page. Further reading Based upon things you didn't know FreshPorts can do There are many things FreshPorts can do, including search Makefile's and pkg-plist. This is from a recent blog post: * provides example dependency line. e.g. p5-XML-RSS>0:textproc/p5-XML-RSS * list of dependencies for a port * list of ports depending upon this port * see default configuration options * what packages install a given file (e.g. bin/unzip) * find out what ports a person maintains * find Makefiles which contain references to bunzip * search results can be plain-text consisting of a list of foo/bar ports * the Maximum Effort checkbox on the search page does nothing * committers can be notified of sanity test failures after the commit * find a commit, any commit, based on SVN revision number, e.g. : https://www.freshports.org/commit.php?revision=3D352332 Javascript help wanted We recently upgraded some outdated Javascript modules. This broke our [JavaScript based graphs](https://www.freshports.org/graphs2.php). We could use some help on fixing that please. The starting points are listed on that URL. If you need a working website to play with, please contact me with a ssh public-key. Sponsor: hardware provided by iXsystems __________________________________________________________________ PCI passthrough with bhyve on Intel and for OpenBSD guests Links bhyve Intel bug report=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229852 bhyve OpenBSD bug report=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245392 PCI passthrough with bhyve (FreeBSD wiki article)=20 URL: https://wiki.freebsd.org/bhyve/pci_passthru Contact: Anatoli Contact: Callum Contact: Peter Grehan bhyve(8) is a hypervisor that supports running a variety of guest operating systems in virtual machines. bhyve(8) includes support for PCI devices passthru, a technique to pass host PCI devices to a virtual machine for its exclusive control and use. For some years, PCI passthrough (ppt) in bhyve was not working on some Intel systems and for OpenBSD guests due to two bugs. The first one was crashing FreeBSD host when bhyve was started with ppt on Intel processors with two VT-d translation units (IOMMU), included in most Skylake and newer Intel processors. The second bug was preventing correct interrupts handling for OpenBSD guests. As a result, OpenBSD guests running on bhyve were not able to use any PCI devices passed through to them from the host. During the last 2 months the second bug was identified and fixed and they both were backported to 12.1-RELEASE (p7). So now it's possible to fully take advantage of PCI passthrough (ppt) with bhyve in a production-ready RELEASE version. The most typical case for ppt is to pass to the guest network adapters for its complete control, but you can also pass through USB devices (including external HDDs). Note though, passthrough of VGA and GPU devices is not supported yet (for more details see the 3rd link). A particularly interesting case for ppt is to use OpenBSD guest as a firewall and a router for a FreeBSD server. With ppt you can achieve this all inside a single server. You could pass to the OpenBSD guest a network adapter connected to the internet and it would take a complete control of it. After filtering the traffic, it could pass good packets via virtual network interfaces to other guests or to the host. Once a network adapter is passed through, a FreeBSD host not only doesn't see it and hence doesn't handle the network traffic, it doesn't even have to initialize the adapter (e.g. in case of a WiFi card, it's the guest that loads the firmware). In simple terms the host only passes the device interrupts to the guest as they come from the hardware. Everything related to the device management happens inside the guest so there's no danger that some network traffic exploits some issue in the host's network stack and causes the host to crash or misbehave in other ways. __________________________________________________________________ SageMath Links SageMath site=20 URL: https://www.sagemath.org/ Contact: Thierry Thomas SageMath is a free open-source mathematics software system licensed under the GPL. It builds on top of many existing open-source packages: NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more. Thanks to SageMath it is possible to access their combined power through a common, Python-based language or directly via interfaces or wrappers. The goal is creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab. This is a complex port, with a lot of dependencies, and it has been broken for some time. Upstream is working on easing its packaging, and many previously bundled applications can now be replaced by external packages. If you are interested, it would be nice to create a team of maintainers * to maintain some of the dependencies; * to maintain SageMath itself and prepare the next release (9.2 is coming!). __________________________________________________________________ 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. chaifi - a tool to simplify joining public WiFi networks Links chaifi=20 URL: https://github.com/gonzoua/chaifi Contact: Oleksandr Tymoshenko chaifi is a TUI (text UI) utility aimed at simplifying the process of joining public WiFi networks in places like coffee shops or libraries. It replaces the process of scanning and manually editing wpa_supplicant.conf with an interactive dialog. The utility is in no way a replacement for full-featured network managers in major desktop environments. Still, if you're working from a console or using a tiling window manager, it may save you some seconds (or in worst case minutes) of your time. __________________________________________________________________ MixerTUI Links mixertui=20 URL: https://gitlab.com/alfix/mixertui Contact: Alfonso Sabato Siciliano MixerTUI is a volume mixer with a Terminal User Interface built on the FreeBSD sound system. It can show the current Sound Driver configuration and select an audio device: to get its information, to change the volume or to set it as default, the last feature allows to switch easily audio from/to laptop and hdmi, headphones and speakers, and so on. MixerTUI can be installed via the audio/mixertui port. I would like to thank the FreeBSD community for the tips, feedbacks and patches to improve this project. __________________________________________________________________ Potluck - Flavour & Image Repository for pot Links Potluck Repository & Project=20 URL: https://potluck.honeyguide.net/ Potluck on github =20 URL: https://github.com/hny-gd/potluck pot project =20 URL: https://pot.pizzamig.dev Contact: Stephan Lichtenauer pot is a jail management tool that also supports orchestration through nomad. Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: A repository of pot flavours and complete images for usage with pot. This should simplify setting up complex software with many packages and ports in comparison to manual configuration: Potluck aims to provide a content library as an additional layer of abstraction, on top of existing infrastructure like pkg, that pot has to offer. Pot "flavour" files are provided on [Github]((https://github.com/hny-gd/potluck)) and fed into a Jenkins instance. On the Potluck Repository, for each flavour, detailed descriptions as well as ready-made images to be imported by pot are provided. The initial project has been set up, and three simple flavours, along with a complete Jitsi Meet instance in a jail has been created as a Proof of Concept that should allow running a fully-fledged video conference system with just a few easy commands within a few minutes. As only the initial versions have been set up and implemented so far, general feedback, tests, as well as additional, useful flavours are very welcome! __________________________________________________________________ News Home | Status Home Site Map | Legal Notices | =A9 1995-2020 The FreeBSD Project. All rights reserved. --zpkl3mlsiuohrpr7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl8PgklfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87qDswf/W+zBAaGAkCuf/c3/TG+HE5hCCt6Qyth9BNn+rih+lNGDMwW7UtXD+DU4 0RTm4Hzmn0y4scqZPr1JloLAarGUhsoEd6GGSUqyv52cMoz1RyZ8lkSeu0HaIbkX mUJdNFwEwVLWtk8kzLWXaIuiV9ROMOojT1ZwRzChKCULx7jj5vLvKtntks1WVe8r mK5DMTlihnbaGSh8o5UnCFVUv9W+kQRWrKqZa+demd1zaMfKeeKQ5njw5wsb6aq9 iZs8tkSjeqmB6Cp2Nk+ZN4HjCr/IMeoFOKzgXgl64uRe6PKhXPtCXSKfm/XgoSND eHGaKVdjP6Y3VqZX6pW47ncFbwHUcw== =jEeX -----END PGP SIGNATURE----- --zpkl3mlsiuohrpr7-- From owner-freebsd-hackers@freebsd.org Wed Jul 15 22:29:14 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BEA10370BEC; Wed, 15 Jul 2020 22:29:14 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (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 4B6X9j13Ddz4P8d; Wed, 15 Jul 2020 22:29:12 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 59EA258100C; Wed, 15 Jul 2020 18:29:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 15 Jul 2020 18:29:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.dev; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=E LGUs4n/WBH16Kw7woKSGvBg1VFX+D/v3+yQNeUAHX0=; b=buA8iYHjMGI7pGenB pcBN2UBXHx0De3HARkbpUaS+7BTZSmLDZwBZpEPrhxXuSNyf49EZyVE1RFdvhWHA v30l3X0WtxIrPV1NXZYrHqzzL0OH8b7HEFSngf/zYkhJN9gN+krxARk3lZSqhvWI IdCxRsp56EqWawN1Z41R2rFfAWUngNz0bJ9Wx4KfB+g9ybQBYUfaBiPBtRv5phV/ 3VsYfCQwVWYUwT5phfMddz1QqklfkKGPqVt2qrGbnYOKEz5PwA2Y+Zga7o5rIAUg +j1rEwkR9rKF+rtSt1WnqjFpCPT7vag9P/SSaZ1WLwrg64k2Y1fDFJomcAMFP3jW p3RRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ELGUs4n/WBH16Kw7woKSGvBg1VFX+D/v3+yQNeUAH X0=; b=UjTQtEqF8jv6abjN24I+nXNOoPGWOBHTXh13zB/sv5F3xnObfyks4mJEq VXnY4bUGbkwMlTMIl6nqnvwh7TgTjHbew6dPH0pc9hSIquqwoy2OZ17BQ/5VcH1b E5tyMPaM/cGVglfP+g8wGs5KsAHq/RQxxOY4yqhwaqGa5nl/wOqnnkX1T5Wyes2Z NdHtbG3i6jV63ci5QhfDFxa9T7e3TeiRXJULkDPRVl4bwzhuCjAdAmljo+TpfkGK kXp8cnjhfLJYC8IiiXTdVwZZY/HoUJzeXi6QmCwWW8u/FJtpSklc1ZV+U54MNiE4 s0waLLpNl/Jn0KkRzsT/uzqH9khUw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeefgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeehnecuhfhrohhmpegjuhhrihcu rfgrnhhkohhvuceohihurhhiphhvseihuhhrihhpvhdruggvvheqnecuggftrfgrthhtvg hrnhepffdvudffheegffejjeekieduffffgefgjefftedugeeiudfhheetfffhvefgtefg necukfhppeeluddrvdegtddruddvgedrudefjeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpeihuhhrihhpvheshihurhhiphhvrdguvghv X-ME-Proxy: Received: from [192.168.1.6] (unknown [91.240.124.137]) by mail.messagingengine.com (Postfix) with ESMTPA id 2CCD33060067; Wed, 15 Jul 2020 18:29:10 -0400 (EDT) Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2020 To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> From: Yuri Pankov Message-ID: <7025a36e-52bf-ca18-185f-3c9adebdf26b@yuripv.dev> Date: Thu, 16 Jul 2020 01:29:09 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B6X9j13Ddz4P8d X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 22:29:14 -0000 Daniel Ebdrup Jensen wrote: [nothing] At least in Thunderbird the text is not inline, and rather shows as attachment. From owner-freebsd-hackers@freebsd.org Wed Jul 15 22:33:27 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 06339371683; Wed, 15 Jul 2020 22:33:27 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6XGZ2SFLz4VXn; Wed, 15 Jul 2020 22:33:26 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 73DCC1E1DF; Wed, 15 Jul 2020 22:33:25 +0000 (UTC) Date: Thu, 16 Jul 2020 00:33:23 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2020 [Inlined] Message-ID: <20200715223323.6cx65wzodfpmrfh5@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="psc724i6dgwcog6o" Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 22:33:27 -0000 --psc724i6dgwcog6o Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - Second Quarter 2020 Introduction This report will be covering FreeBSD related projects between April and June, and covers a diverse set of topics ranging from kernel updates over userland and ports, as well to third-party work. Some hilights picked with the roll of a d100 include, but are not limited to, the ability to forcibly unmounting UFS when the underlying media becomes inaccessible, added preliminary support for Bluetooth Low Energy, a introduction to the FreeBSD Office Hours, and a repository of software collections called potluck to be installed with the pot utility, as well as many many more things. As a little treat, readers can also get a rare report from the quarterly team. Finally, on behalf of the quarterly team, I would like to extend my deepest appreciation and thank you to salvadore@, who decided to take down his shingle. His contributions not just the quarterly reports themselves, but also the surrounding tooling to many-fold ease the work, are immeassurable. We hope you find the report as interesting as we have, Daniel Ebdrup Jensen (debdrup@), on behalf of the quarterly team. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Foundation * FreeBSD Core Team * FreeBSD Release Engineering Team * Cluster Administration Team * Continuous Integration * Ports Collection * FreeBSD Office Hours * Quarterly Status Reports Team Projects * FreeBSD on Microsoft HyperV and Azure * Git Migration Working Group * Lua Usage in FreeBSD * Linux compatibility layer update * NFS over TLS implementation Kernel * SoC audio framework and more audio drivers * bhyve - NVMe emulation improvements * Bluetooth Support * DRM Drivers Update * DTS Update * ENA FreeBSD Driver Update * Forcible Unmount of UFS/FFS Filesystems on Disk Failure * i.MX 8M support * Intel wireless and 11ac update * amd64 5-Level Paging Structures support * Not-transparent superpages * NXP ARM64 SoC support * amd64 pmap Fine-grained pv lists locking * Lockless routing lookups and scalable multipath * ZSTD Compression in ZFS * CheriBSD 2020 Q2 Architectures * Continuous Integration on !x86 * FreeBSD/RISC-V Project Userland Programs * Import of new implementation of bc and dc * Binutils Retirement * Run-Time Dynamic Linker improvements * VHDX support in mkimg(1) Ports * Bastille * KDE on FreeBSD * Haskell on FreeBSD * rtsx - Porting driver for Realtek SD card reader from OpenBSD * Valgrind updates Documentation * FreeBSD Translations on Weblate Miscellaneous * FreshPorts * PCI passthrough with bhyve on Intel and for OpenBSD guests * SageMath Third-Party Projects * chaifi - a tool to simplify joining public WiFi networks * MixerTUI * Potluck - Flavour & Image Repository for pot __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. 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: COVID-19 Impact to the Foundation Like other organizations, we put policies in place for all of our staff members to work from home. We also put a temporary ban on travel for staff members. We are continuing our work supporting the community and Project, but some of our work and responses may be delayed because of changes in some of our priorities and the impact of limited childcare for a few of our staff members. Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. Not surprisingly, the stay at home orders, combined with our company ban on travel during Q2 made in-person meetings non-existent. However, the team was able to continue meeting with our partners and commercial users virtually. These meetings help us understand some of the applications where FreeBSD is used. Fundraising Efforts Last quarter we raised $268,400! Thank you to the individuals and organizations that stepped in to help fund our efforts. We'd like to thank Netflix, employees of Nginx, Beckhoff Automation, and Mozilla Foundation for their large contributions last quarter, which helped bring our 2020 fundraising effort to $339k. We hope other organizations will follow their lead and give back to help us continue supporting FreeBSD. These are trying times, and we deeply appreciate every donation that has come in from $5 to $150,000. We're still here giving 110% to supporting FreeBSD! We are 100% funded by donations, and those funds go towards software development work to improve FreeBSD, FreeBSD advocacy around the world, keeping FreeBSD secure, continuous integration improvements, sponsoring BSD-related and computing conferences (even the virtual events!), legal support for the Project, and many other areas. Please consider making a donation to help us continue and increase our support for FreeBSD. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information about the partnership program and share with your companies! OS Improvements A number of FreeBSD Foundation grant recipients started, continued working on, or completed projects during the second quarter. These include: * WiFi improvements * Linuxulator application compatibility * DRM / Graphics driver updates * Zstd compression for OpenZFS * Online RAID-Z expansion * if_bridge performance improvements You can find more details about most of these projects in other quarterly reports. Staff members also worked on a number of larger projects, including: * Run-Time Dynamic Linker (rtld) improvements * Improved FreeBSD support on Microsoft HyperV and Azure * Fine-grained locking for amd64 pmap * 5-level paging structures for amd64 * Non-transparent superpages * Migration to a Git repository * Tool chain modernization Many of these projects also have detailed entries in other quarterly report entries. Staff members also put in significant effort in many ways other than larger, individual projects. These include assisting with code reviews, bug report triage, security report triage and advisory handling, addressing syzkaller reports, and ongoing maintenance and bug fixes in functional areas such as the tool chain, developer tools, virtual memory kernel subsystem, low-level x86 infrastructure, sockets and protocols, and others. University of Waterloo Co-op Foundation co-op students Colin, Tiger, and Yang completed their winter 2020 work term during the second quarter, and continued on with the next school term in their respective programs. Although COVID-19 presented a unique challenge and prompted an abrupt transition to remote work just over half way through the term, all three learned a lot and provided positive contributions to the FreeBSD Project and to the Foundation. A few projects that were in progress or completed during the work term were committed to the FreeBSD tree in the second quarter. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member who is working on improving continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. During the second quarter of 2020, Foundation staff continued improving the Project's CI infrastructure, monitoring regressions and working with contributors to fix the failing build and test cases. The setting up of VM host for CI jobs and staging environment is in progress. We are also working with other teams in the Project for their testing needs. For example, we added jobs for running full tests on non-x86 architectures. We are also working with many external projects and companies to improve their support of FreeBSD. See the FreeBSD CI section of this report for completed work items and detailed information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. We started working on getting the new NYI Chicago colocation facility prepared for some of the new FreeBSD hardware we are planning on purchasing. NYI generously provides this for free to the Project. 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. As is the case for most of us in this industry, COVID-19 has put our in-person events on hold. In addition to attending virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: * Silver sponsor of BSDCan 2020. The event was held virtually, June 2-6, 2020 * Community Sponsor of Rootconf 2020. The event was held virtually, June 19-20, 2020 * Annual FreeBSD Day, June 19. This year's celebration was postponed in support of Juneteeth. However the activities surrounding FreeBSD Day have been transformed into an ongoing series of online sessions. See FreeBSD Fridays below for more information. * Presented 27 Years of FreeBSD and Why You Should Get Involved as part of a Linux Professional Institute series of webinars on June 24, 2020. * Attended and presented at the virtual Open Source Summit 2020. * Announced FreeBSD Fridays: A series of 101 classes designed to get you started with FreeBSD. Find out more in the announcement * Participated as an Admin for Google Summer of Code 2020 * Participated in the new FreeBSD Office Hours series including holding our own Foundation led office hours. Videos from the one hour sessions can be found on the Project's YouTube Channel. You can watch ours here. In addition to the information found in the Development Projects update section of this report, take a minute to check out the latest update blogs: * 5x if_bridge Performance Improvement * My Experience as a FreeBSD Foundation Co-Op Student Keep up to date with our latest work in our Bi-Monthly newsletters. Mellanox provided an update on how and why they use FreeBSD in our latest Contributor Case Study. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues on the Journal site. You can find out more about events we attended and upcoming events. We have continued our work with a new website developer to help us improve our website. Work is nearly complete to make it easier for community members to find information more easily and to make the site more efficient. We look forward to unveiling the refreshed site in Q3. Foundation Board Meeting Our annual board meeting was held on Tuesday June 2, 2020. We normally hold this meeting the Tuesday before BSDCan, in Ottawa, Ontario, Canada, but with the company travel ban, and the conference going virtual, our meeting went virtual for the first time. The purpose of the annual board meeting is to hold our board director and officer elections, review work accomplished over the past year, and put together strategic goals for the upcoming 12 months. The board generally has two all-day board meetings each year, this one, and a more informal one in January, typically held in Berkeley. Both meetings allow us to connect, reevaluate and discuss new ideas, while assessing what we should do to help the Project. Some of our longer-term goals include Growing User and Developer Communities, Developing Training and OS Course Content, Improving desktop/laptop experience, Promoting FreeBSD (as you can see in all the advocacy work listed above), and Improving Testing Capabilities. Results of the director and officer elections were: * Justin Gibbs (President) * Benedict Reuschling (Vice President) * Kirk McKusick (Treasurer) * Philip Paeps (Secretary) * Deb Goodkin (Assistant Secretary) * Robert Watson (Director) * Hiroki Sato (Director) * George Neville-Neil (Director) Find out more about the FreeBSD Foundation Board of Directors on our website. 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 the FreeBSD Foundation's web site to find out how we support FreeBSD and how we can help you! __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. The Core Team held 10 meetings during the second quarter of 2020, including a 2020-05-21 joint meeting with members of the FreeBSD Foundation. Here are some highlights from that meeting: * Deb requested guidance on how the Foundation can support the community. Core and Foundation members believe that more developer support is necessary to fill gaps in areas where commercial customers do not provide backing. The clearest example of such a gap is the desktop experience, including graphics and wireless support. What makes this request different from past requests is that rather than support for one-time projects, ongoing positions are necessary for a consistently high-quality desktop experience. "FreeBSD not being able to run on your laptop is the first step to irrelevance." Ed Maste * Both teams discussed topics for upcoming sessions of FreeBSD Office Hours, informal FreeBSD video conferences that anyone can attend. Everyone agreed that the Office Hours have been a useful way for different parts of the Project to engage with each other and with the wider community. Kudos to Allan Jude for initiating the Office Hours and for everyone who has helped make them a success by hosting or attending sessions. * Both teams agreed that they should meet once per quarter. The second annual community survey closed on 2020-06-16. The purpose of the survey is to collect data from the public to help guide the Project's efforts and priorities. As an example, last year's survey results helped initiate the Project's conversion to Git. Thank you to all who took the time to respond. The results will be released soon. The Core-initiated Git Working Group continued to make progress, but there are still some remaining issues to be worked out with the translation from Subversion. Hopefully the new Git src repository will be ready for use this summer. A beta version has been published for people to test and a preliminary version of a Using Git for FreeBSD Development primer will soon be ready to share. Core, the Git Working Group, and Release Engineering are working towards the goal of releasing 12.2 from the new Git repository. Following the results of a Core-initiated developer survey, The FreeBSD Project has adopted a new LLVM-derived [code of conduct](https://www.freebsd.org/internal/code-of-conduct.html). The eleventh FreeBSD Core Team was elected by active developers. From a pool of 23, the 9 successful candidates for core.11 are: * Sean Chittenden (seanc, incumbent) * Baptiste Daroussin (bapt) * Kyle Evans (kevans) * Mark Johnston (markj) * Scott Long (scottl) * Warner Losh (imp, incumbent) * Ed Maste (emaste) * George V. Neville-Neil (gnn) * Hiroki Sato (hrs, incumbent) A new Core Team secretary, Muhammad Moinur Rahman (bofh), was unanimously approved by core.11. The outgoing core team met three times with the new core team to help with the transition. Core.10 wishes core.11 a successful term. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 11.4-RELEASE announcement=20 URL: https://www.freebsd.org/releases/11.4R/announce.html FreeBSD 11.4-RELEASE schedule=20 URL: https://www.freebsd.org/releases/11.4R/schedule.html FreeBSD development snapshots=20 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 slushes, and maintaining the respective branches, among other things. During the second quarter of 2020, the Release Engineering Team started work on the 11.4-RELEASE cycle, the fifth release from the stable/11 branch. The release cycle went quite smoothly, with both BETA3 and RC3 removed from the schedule. This allowed the final release to occur one week earlier than originally scheduled, which was announced June 16. FreeBSD 11.4-RELEASE is expected to be the final 11.x release. The FreeBSD Release Engineering Team would like to thank everyone involved in this cycle for their hard work. 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 Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation. __________________________________________________________________ Cluster Administration Team Links Cluster Administration Team members=20 URL: https://www.freebsd.org/administration.html#t-clusteradm Contact: Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Upgrade all x86 ref- and universe-machines * Setup Amsterdam (PKT) mirror * Solve hardware issue for bugzilla and svnweb backend * Setup public beta git server * Decommission CyberOne Data (CYB) mirror * Ongoing systems administration work: + Accounts management for committers. + Backups of critical infrastructure. + Keeping up with security updates in 3rd party software. Work in progress: * Setup Malaysia (KUL) mirror * Setup Brazil (BRA) mirror * Review the service jails and service administrators operation. * Infrastructure of building aarch64 and powerpc64 packages + NVME issues on PowerPC64 Power9 blocking dual socket machine from being used as pkg builder. + Drive upgrade test for pkg builders (SSDs) courtesy of the FreeBSD Foundation. + Boot issues with Aarch64 reference machines. * New NYI.net sponsored colocation space in Chicago-land area. * Work with git working group * Check new hardware requirement from other teams * Searching for more providers that can fit the requirements for a generic mirrored layout or a tiny mirror __________________________________________________________________ Continuous Integration Links FreeBSD Jenkins Instance=20 URL: https://ci.FreeBSD.org FreeBSD Hardware Testing Lab=20 URL: https://ci.FreeBSD.org/hwlab FreeBSD CI artifact archive=20 URL: https://artifact.ci.FreeBSD.org FreeBSD CI weekly report=20 URL: https://hackmd.io/@FreeBSD-CI FreeBSD Jenkins wiki=20 URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki=20 URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI=20 URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@=20 URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository=20 URL: https://github.com/freebsd/freebsd-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system for the FreeBSD project. The CI system firstly checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from the build jobs are archived in the artifact server for 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 codes or adjust test infrastructure. The details of these efforts are available in the weekly CI reports. During the second quarter of 2020, we continue working with the contributors and developers in the project for their testing needs and also keep working with external projects and companies to improve their support of FreeBSD. Important changes: * All -test jobs will run tests under /usr/tests, previously only x86 architectures doing this. See the Continuous Integration on !x86 section in this report for more information. * Compression algorithm of disk images on the artifact server has been changed to zstd to speed up compression and decompression. * The build and test results will be sent to the dev-ci mailing list soon. Feedback and help with analysis is very appreciated! New jobs added: * https://ci.freebsd.org/job/FreeBSD-head-armv7-test/ * https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/ * https://ci.freebsd.org/job/FreeBSD-head-mips64-test/ * https://ci.freebsd.org/job/FreeBSD-head-powerpc64-test/ Work in progress: * Collecting and sorting CI tasks and ideas here * Testing and merging pull requests in the the FreeBSD-ci repo * Setting up a builder dedicated to run jobs using provisioned VMs. * Setting up the CI stage environment and putting the experimental jobs on it * Implementing automatic tests on bare metal hardware * Adding drm ports building tests against -CURRENT * Planning to run ztest and network stack tests * Adding external toolchain related jobs * Improving the hardware lab to be more mature and adding more hardware * Helping more 3rd software get CI on FreeBSD through a hosted CI solution * Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and don't hesistate to join the effort! Sponsor: The FreeBSD Foundation __________________________________________________________________ Ports Collection Links About FreeBSD Ports=20 URL: https://www.FreeBSD.org/ports/ Contributing to Ports=20 URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring=20 URL: http://portsmon.freebsd.org/index.html Ports Management Team=20 URL: https://www.freebsd.org/portmgr/index.html Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. There are currently 2,373 open ports PRs of which 526 are unassigned, for a total of 39,628 ports. In the last quarter there were 10,315 commits to HEAD and 476 to the quarterly branch by respectively 178 and 65 committers. Compared to the quarter before, this means a significant increase in commits and also a slight decrease in open PRs. During the last quarter, we welcomed Hiroki Tagato (tagattie@). We said goodbye to seanc@, zleslie@, gnn@ and salvadore@. A few default versions got bumped: * Java (new) at 8 * Lazarus to 2.0.8 It is now possible to write pkg scripts in Lua instead of sh. They have two advantages over their sh versions: * they run in a Capsicum sandbox * they respect rootdir, the directory which pkg will use as the starting point to install all packages under. Some user-facing packages were also updated: * pkg to 1.14.6 * Firefox to 78.0.1 * Thunderbird to 68.10.0 * Chromium to 83.0.4103.116 * Ruby to 2.5.8, 2.6.6, and 2.7.1 * Qt5 to 5.14.2 During the last quarter, antoine@ ran 55 exp-runs to test port version updates, make liblzma use libmd, flavor devel/scons and Lua ports, add and update library functions in the base system, make malloc.h usable again, remove as(1) from the base system, and augment sed(1) with -f. __________________________________________________________________ FreeBSD Office Hours Links Office Hours on the FreeBSD Wiki=20 URL: https://wiki.freebsd.org/OfficeHours Poll: What time would you prefer Office Hours be at=20 URL: https://forms.gle/3HjjRx9KMcM3SL4H7 live.FreeBSD.org: Aggregation of Live streams=20 URL: https://live.freebsd.org/ Contact: Allan Jude Starting on the first of April 2020, the FreeBSD project has started hosting regular video streams to foster greater communication within the wider FreeBSD community. The first of these sessions took the form of a public question and answer session, which drew over 60 participants. A second session was held two weeks later at a time more appropriate for those in Asia, but only drew 20 participants. With the help of the FreeBSD Foundation, we ran a poll to discover what times worked best for the greatest number of people. On May 13th the FreeBSD Foundation hosted a session where the community could ask questions of or about the foundation. On May 27th many of the candidates for the new FreeBSD Core Team joined an office hours session to answer questions from the community. Finally on June 24th another general question and answer office hours was held. Each office hours session consists of a video meeting of some FreeBSD developers or other subject matter experts, live streamed along with an IRC chat room for viewers to pose questions to the panel. The stream is recorded and posted to the official FreeBSD youtube channel. If you would like to host an office hours session, please contact: * Allan Jude * Anne Dickison Sponsor: ScaleEngine Inc. (video streaming) __________________________________________________________________ Quarterly Status Reports Team Links Quarterly status reports=20 URL: https://www.freebsd.org/news/status/ Git repository =20 URL: https://github.com/freebsd/freebsd-quarterly Contact: Quarterly Status Reports Contact: Daniel Ebdrup Jensen The Quarterly Status Reports Team collects and publish the reports that you are reading right now. Many improvements have been done recently and thus we believe it is useful that the Quarterly Status Reports Team submits a report. Not all the changes below are specific to the last quarter, but we list them here anyway since we did not write an entry for earlier reports. * Reports are now built using Makefiles. Among the many advantages, this allows us to easily sort reports logically. Indeed, starting with 2019Q4, all reports are sorted logically, while before they were sorted alphabetically within each category. * The conversion from markdown to docbook was performed using a python script, with some known bugs. Salvadore has rewritten the script using perl fixing most of the bugs. Some features are missing and many improvements are possible, but the script is very unlikely to receive any change since it will become obsolete as soon as the conversion to Hugo/AsciiDoctor is completed. * Another perl script to ease the preparation of the mail version of the reports was written. * One more perl script has been written to allow the quarterly team to send quarterly calls automatically using a cron job. We used it this quarter for the first time. * As you might have noticed, last quarterly calls have been sent to freebsd-quarterly-calls@: this is a new mailing list to which you can subscribe to receive calls for quarterly reports. Please note this is a moderated list, with very low traffic and a high signal to noise ratio. * If you read carefully the last quarterly calls, you should have noticed that we now ask you to send reports to quarterly-submissions@ instead of quarterly@. This was done to help the quarterly team distinguishing internal discussions from submissions. Please keep in mind however that the quarterly team prefers receiving pull requests, as they ease the administrative work. We would like to thank philip@, from the postmaster team, for having created the freebsd-quarterly-calls@ mailing list and the quarterly-submissions@ address for us. __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. FreeBSD on Microsoft HyperV and Azure Links FreeBSD on MicrosoftAzure wiki=20 URL: https://wiki.freebsd.org/MicrosoftAzure FreeBSD on Microsoft HyperV =20 URL: https://wiki.freebsd.org/HyperV Contact: FreeBSD Integration Services Team Contact: Wei Hu Contact: Li-Wen Hsu HyperV socket for FreeBSD implemented by Wei was checked into FreeBSD head branch on May 20th as r361275. It supports guest/host communications without the need for networking. Some HyperV and Azure features rely on this to be available in guests. Details of HyperV Socket is available here. This project is sponsored by Microsoft. Li-Wen is working on the FreeBSD release code related to Azure for the -CURRENT, 12-STABLE and 11-STABLE branches. The work-in-progress is available here. The 12.1-RELEASE image on Azure Marketplace is published. The work on the 11.4-RELEASE image on Azure Marketplace is in progress. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Git Migration Working Group Links Git conversion tooling repo=20 URL: https://github.com/freebsd/git_conv FreeBSD-git mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-git Beta doc git repo=20 URL: https://cgit-beta.FreeBSD.org/doc Beta ports git repo=20 URL: https://cgit-beta.FreeBSD.org/ports Beta src git repo=20 URL: https://cgit-beta.FreeBSD.org/src Contact: Ed Maste Contact: Warner Losh Contact: Ulrich Sp=F6rlein Work continues on FreeBSD's migration from Subversion to Git. Ulrich has iterated on updates to svn2git in order to improve the fidelity of the conversion, particularly in regards to vendor (contrib) code updates. We believe the conversion is now at an acceptable state, but may make minor adjustments if additional issues are found. We expect to push modifications to the converter every two weeks (first and third Sunday of the month). This means that commit hashes in the beta repo will remain stable for at least two weeks at a time, to allow others to test and experiment with the beta repo. We are now working on updating FreeBSD processes and documentation. This includes: * Writing a Git Primer, akin to the existing Subversion primer * Updates to the Security Team's tools and processes * Release engineering updates * Ports and packages process updates Those with an interest in the migration to Git are encouraged to subscribe to the FreeBSD-git mailing list and test out the beta src, ports, and/or doc repositories. You are also welcome check out the wiki, issues, README and other documentation at the Git conversion tooling repo. We expect to be ready for the migration in the next quarter. Sponsor: The FreeBSD Foundation (in part) __________________________________________________________________ Lua Usage in FreeBSD Contact: Ed Maste Contact: Kyle Evans Contact: Ryan Moeller Lua is a small, efficient scripting language that FreeBSD imported before FreeBSD 12.0 for use in the bootloader. Since then, several projects outside of the bootloader have gained some amount of traction with Lua usage: * /usr/libexec/flua is now installed for internal usage * makesyscalls.sh was rewritten in Lua * pkg has gained support for lua scripts * lldb in the base system now supports lua scripting FreeBSD Lua ("flua") is a version of the lua interpreter that has several modules built-in for convenient usage within the base system. flua is installed with a non-standard name and in a location not included in $PATH so that it is not accidentally found by third-party software or configure scripts. The FreeBSD project makes no guarantees about upgrade cadence or module stability. That said, it is available for use by downstream projects and FreeBSD users aware of those limitations. Previous work with flua includes, for example, adding libucl support and future work includes libifconfig support for scripting usage. People interested in working with Lua in FreeBSD are welcome to get in contact to discuss other project ideas. To name a couple of potential projects, some interesting modules that have not been started but could prove useful (listed in no particular order): * libcrypt * libexpat * libjail * libnv * libxo __________________________________________________________________ Linux compatibility layer update Contact: Edward Tomasz Napierala Earlier Linuxulator work focused on code cleanups and improving diagnostic tools. Work has now shifted from cleanups to fixing actual applications. Current status is being tracked at Linux app status Wiki page. Initial focus is on applications that don't involve X11, mostly because they tend to be easier to test and debug, and the bug fixes are not application-specific. Example problems fixed include buggy madvise(2) handling, which could break applications linked against jemalloc; uname(2) returning wrong results for 32 bit apps, which caused problems for Steam; recvmsg(2) and accept(2) being broken in some circumstances, which was breaking Redis; and missing support for SO_REUSEPORT, SO_SNDBUFFORCE, SO_RCVBUFFORCE, and SO_PROTOCOL, which spammed the log files when running the Python regression test suite. The default soft open files limit is now automatically adjusted to 1024, as several Linux apps iterate over all the file descriptors up to that limit instead of using closefrom(2). There's ongoing work on cleanups and the debugging framework for Linux compatibility, such as logging warnings for unrecognized system call parameters, or adding the compat.linux.debug sysctl to turn the warnings off. The Linux Test Project tests that are being run as part of the the FreeBSD Continuous Integration infrastructure has been upgraded to 20200605 snapshot. This raised the number of test cases from 3670 to 3749, and, predictably, also the number of failures, from 583 to 647. There's still a lot to do: * There are pending reviews for patches that add extended attributes support, and fexecve(2) syscall, and they require wrapping up and committing * There are over 500 failing LTP tests. Some of them are false positives, some are easy to fix bugs, and some require adding new system calls. Any help is welcome. Sponsor: The FreeBSD Foundation __________________________________________________________________ NFS over TLS implementation Contact: Rick Macklem In an effort to improve NFS security, an internet draft which I expect will become an RFC soon specifies the use of TLS 1.3 to encrypt all data traffic on a Sun RPC connection used for NFS. Although NFS has been able to use sec=3Dkrb5p to encrypt data on the wire, this requires a Kerberos environment and, as such, has not been widely adopted. It also required that encryption/decryption be done in software, since only the RPC message NFS arguments are encrypted. Since Kernel TLS is capable of using hardware assist to improve performance and does not require Kerberos, NFS over TLS may be more widely adopted, once implementations are available. The project to implement this has largely been completed. The code will slowly be merged into head/current and at least the kernel portion should be in FreeBSD-13. To support clients such as laptops, the daemons that perform the TLS handshake may optionally handle client X.509 certificates from a site local CA. There are now exports(5) options to require client(s) to provide a valid X.509 certificate. The code is now available for testing. See: https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt Setting up system(s) for testing is still a little awkward, as explained by the above rough document. The main limitation in the current implementation is that it uses TLS1.2 and not TLS1.3. This should change once the KERN_TLS rx patch includes TLS1.3 support. Also, testing of pNFS configurations has not yet been done, but will be tested soon. Third party testing would be appreciated. __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. SoC audio framework and more audio drivers Links rk3399_audio=20 URL: https://github.com/gonzoua/freebsd/tree/rk3399_audio Contact: Oleksandr Tymoshenko SoC audio framework made a good progress since last report. Support for AUX devices was added (devices like auxiliary amplifiers that are not part of main CODEC chip). To verify the framework design following audio drivers were added: recording support for RT5640 CODEC(Firefly-RK3399), Allwinner I2S, Alwinners sun8i and A64 CODECs (Pine A64+), both recording and playback. Current work in progress is RK3328 CODEC (Rock64) and ES8316 CODEC (RockPro64 and Pinebook Pro). __________________________________________________________________ bhyve - NVMe emulation improvements Links bhyve NVMe reviews=20 URL: https://reviews.freebsd.org/search/query/xvbcF20W__Km/ Contact: Chuck Tuffli The University of New Hampshire InterOperability Laboratory (a.k.a. UNH IOL) develops a suite of tests to determine if an NVMe device conforms to the specification and is interoperable with other NVMe products. This quarter, I undertook getting bhyve's emulated NVMe device to pass the mandatory tests. Changes include: * implement Flush command * implement Format NVM command * implement AER support * implement Namespace Identification Descriptor * fix Active Namespace list * fix queue creation and deletion * validate Deallocate range values * handle zero length DSM ranges * fix Get Log Page command * implement SMART data I/O statistics * validate the LBA start and count * add basic Firmware Commit support * add more compliant Get/Set Features * add Feature, Interrupt Vector Config * fix Get Features, Predictable Latency This was also a good opportunity to restructure parts of the code to make it more modular and easier to enhance. This includes * convert logging statements to parameterized macros * refactor I/O command handling * add locks around queue accesses * consolidate CQ update * base pci_nvme_ioreq size on advertised MDTS You can help by testing and/or commenting on the code reviews. __________________________________________________________________ Bluetooth Support Contact: Marc Veldman Bluetooth is a wireless technology for creating personal networks, connecting peripherals like keyboards and mice but also speakers and heart rate monitors. FreeBSD has limited Bluetooth Basic Rate (BR) support and no functional Bluetooth Low Energy (LE) support. During this quarter many small improvements have been made to help the development of Bluetooth LE support. A number of commands have been added to hccontrol(8), mainly to do LE functions. It is now possible to scan for LE devices within range using hccontrol. A panic that occurred when enabling LE support has also been fixed. Work is still needed to add Attribute Protocol (ATT) and Generic Attribute Profile (GATT) support. __________________________________________________________________ DRM Drivers Update Links drm-kmod=20 URL: https://github.com/freebsd/drm-kmod/ Contact: Emmanuel Vadot The drm drivers for FreeBSD 13-CURRENT have been updated to match Linux 5.3 This brings us a little bit closer to the last LTS release of Linux (5.4). The current plan is to first update the driver to match 5.4 and then look at making it work on FreeBSD-12-STABLE to have it ready for the 12.2 release. Sponsor: The FreeBSD Foundation __________________________________________________________________ DTS Update Contact: Emmanuel Vadot DTS files (Device Tree Sources) were updated to be on par with Linux 5.7 for HEAD and 5.6 for the 12-STABLE branch. __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README=20 URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/R= EADME Contact: Michal Krawczyk Contact: Artur Rojek 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. Completed since the last update: * Fixes for Rx refill to improve stability on low memory conditions (also released as an errata notice for FreeBSD-12.1) * Upstream of the v2.2.0 driver, introducing: + Add driver support for the upcoming HW features (reporting Tx drops, disabling meta caching) + Add sysctl tuneables for IO queue number + Create IO queues with optional size backoff + Rework the way of configration of drbr and Rx ring size to be more robust and stable + New HAL version + Driver is now marked as epoch ready + Default RSS key is created using RNG to improve security + Other minor fixes and improvements * MFC of the ENA v2.2.0 driver to the FreeBSD 11.4 Sponsor: Amazon.com Inc __________________________________________________________________ Forcible Unmount of UFS/FFS Filesystems on Disk Failure Links Phabricator Details=20 URL: https://reviews.freebsd.org/D24088 Contact: Chuck Silvers Contact: Kirk McKusick Commit -r361491 on May 25, 2020 enables a UFS file system to do a forcible unmount when the underlying media fails or becomes inaccessible. For example when a USB flash memory card hosting a UFS file system is unplugged. The rest of this report describes in more detail how forcible unmounts are done. Suprisingly, less than 500 lines of file system code were added or changed. The strategy for handling disk I/O errors when soft updates are enabled is to stop writing to the disk of the affected file system but continue to accept I/O requests and report that all future writes by the file system to that disk actually succeed. Then initiate an asynchronous forced unmount of the affected file system. There are two cases for disk I/O errors: * ENXIO, which means that this disk is gone and the lower layers of the storage stack already guarantee that no future I/O to this disk will succeed. * EIO (or most other errors), which means that this particular I/O request has failed but subsequent I/O requests to this disk might still succeed. For ENXIO, we can just clear the error and continue, because we know that the file system cannot affect the on-disk state after we see this error. For EIO or other errors, we arrange for the geom_vfs layer to reject all future I/O requests with ENXIO just like is done when the geom_vfs is orphaned. In both cases, the file system code can just clear the error and proceed with the forcible unmount. This new treatment of I/O errors is needed for writes of any buffer that is involved in a dependency. Most dependencies are described by a structure attached to the buffer's b_dep field, but some are created and processed as a result of the completion of the dependencies attached to the buffer. Clearing of some dependencies require a read. For example if there is a dependency that requires an inode to be written, the disk block containing that inode must be read, the updated inode copied into place in that buffer, and the buffer then written back to disk. Often the needed buffer is already in memory and can be used. But if it needs to be read from the disk, the read will fail, so we fabricate a buffer full of zeroes and pretend that the read succeeded. This zero'ed buffer can be updated and "written" back to disk. The only case where a buffer full of zeros causes the code to do the wrong thing is when reading an inode buffer containing an inode that still has an inode dependency in memory that will reinitialize the effective link count (i_effnlink) based on the actual link count (i_nlink) that we read. To handle this case we now store the i_nlink value that we wrote in the inode dependency so that it can be restored into the zero'ed buffer thus keeping the tracking of the inode link count consistent. Because applications depend on knowing when an attempt to write their data to stable storage has failed, the fsync(2) and msync(2) system calls need to return errors if data fails to be written to stable storage. So these operations return ENXIO for every call made on files in a file system where we have otherwise been ignoring I/O errors. Sponsor: Netflix __________________________________________________________________ i.MX 8M support Links D25274=20 URL: https://reviews.freebsd.org/D25274 Contact: Oleksandr Tymoshenko i.MX 8M is the family of application processors from NXP based on Arm=AE Cortex=AE-A53 and Cortex-M4 cores. The initial code drop for the platform support includes CCM driver and clock implementation, GPC driver, clock tree for i.MX 8M Quad. Most of the drivers from i.MX 6 can be reused for i.MX 8M systems with relatively minor modifications. Common changes include adding clock support and extending list of FDT compat strings. With the linked patch FreeBSD successfully booted to multiuser with NFS root on Nitrogen8M SBC. __________________________________________________________________ Intel wireless and 11ac update Links Initial project announcement=20 URL: https://lists.freebsd.org/pipermail/freebsd-wireless/2020-April/00= 9055.html The freebsd-wireless mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-wireless Contact: Bjoern A. Zeeb The Intel Wireless cards are one of the most commonly used and ask for in FreeBSD notebooks. This project has three main goals: * newer Intel Wireless device support, * newer WiFi standards support for Intel Wireless, * integration of 802.11ac client support and infrastructure in FreeBSD. The first one is needed as iwm(4) currently does not support the latest generations of Intel Wireless cards at all. The second is needed as in FreeBSD iwm(4) does not even support 802.11n. The third one we want to catch up and use the improvements the new Wifi standard offers, e.g., speed. One of the decisions made was: rather than improving iwm(4) this work uses the dual-licensed native Linux driver under BSD license and the linuxkpi framework to stay as close to upstream as possible as a first step. This will give us several advantages, such as, the full support for all cards, quick support for new chipsets, vendor bug fixes, but also the ability to contribute back. At this point the lower level hardware attachments and the firmware loading and initialisation works. I plan to release a patchset for testing before mid-July, you can see if your currently supported or unsupported hardware will be detected. This first cut will not support any wireless operation yet, which will follow later in the year. If you want to help testing, please watch the freebsd-wireless list. Sponsor: The FreeBSD Foundation __________________________________________________________________ amd64 5-Level Paging Structures support Links Patch=20 URL: https://reviews.freebsd.org/D25273 Intel SDM=20 URL: https://software.intel.com/content/www/us/en/develop/articles/inte= l-sdm.html Intel whitepaper=20 URL: https://software.intel.com/content/www/us/en/develop/download/5-le= vel-paging-and-5-level-ept-white-paper.html Contact: Konstantin Belousov Since its introduction, x86 Long Mode (AKA 64bit execution mode, amd64 in FreeBSD terminology) uses 4-level paging structures, which provides 48 bits of virtual address space (LA48). FreeBSD evenly divides the space between userspace and kernel, giving both 47 virtual address bits. In near future Intel CPUs will start providing 5-level paging structures, i.e. giving 57 bits for virtual addresses (LA57). This means, with preservation of the existing divide between KVA and UVA, 56 bit for UVA, or 2^9 =3D 512 times more virtual memory. The amd64 pmap was modified to support both LA48 and LA57, defaulting to LA57 if hardware supports it. The tunable is provided to force using LA48 even if hardware can do LA57. The most interesting part of the patch is the switch from boot paging mode to LA57. Loaders, either legacy or UEFI, pass control to the kernel in Long Mode, which implies that the paging is turned on. This neccessarily means that it is LA48 mode. SDM states that paging mode cannot be switched while Long Mode is active, so kernel has to create new page table structures, turn Long Mode off, then load new %cr3 and finally re-enable Long Mode. I decided to only provide the larger virtual address space to usermode for the initial step, leaving KVA layout intact. The main motivation is that changing KVA arrangements requires changing the auto-tuning settings, which deserve separate work. Another argument for it is that most of the kernel memory is non-swappable, so cannot be over-commited. We have 2:1 ratio of useful KVA to physical memory (due to direct map), and until machines get more physical address lines, increasing KVA is not useful. After this was decided, creating a 5-level paging structure for kernel pmap from existing 4-level one is quite straightforward; we need to add one page for top level, create one PML5 entry to point to existing PML4 page, and create the famous self-referential entry for vtopte()/vtopde(). Care was taken to provide binary compatible layout of UVA for binaries that cannot be executed correctly with larger address space. For instance, programs could have knowledge about used bits in the addresses and used upper bits for other data, or implemented compressed pointers. Even if system runs in LA57 mode, specific binary can request LA48-compatible UVA by procctl(2) or by the flag in the FreeBSD features ELF note. Since I do not have access to a machine with LA57, development was done using QEMU. It would be interesting to try it on the real hardware. Sponsor: The FreeBSD Foundation __________________________________________________________________ Not-transparent superpages Links Patch=20 URL: https://reviews.freebsd.org/D24652 Contact: Konstantin Belousov FreeBSD already provides excellent support for superpages, in a manner completely transparent to applications. It tries to proactively prevent fragmentation, reserves contigous runs of the physical pages for linear allocations in managed objects, and auto-promote runs of small pages when they form complete superpage. The shortcomings of this approach directly follows from its strength: some applications want to get guaranteed superpage mappings, typically because the underlying physical memory is also offloaded into a hardware which also has memory mapping unit. For instance, Infiniband RMDA adapters do memory registration and remapping, which is more efficient with large pages. In such cases transparent (non-guaranteed) support cannot be used. The extension was developed for POSIX shared memory subsystem to allow the creator request that the shared memory object was backed by physically contiguous pages, with runs of specified size. The mmap(2) syscall is aware of such objects, and if the requested mapping is properly aligned, it will be served by superpages. The new type of the shared memory objects are backed by modified a physical pager, which only allocates contigous physical memory. The VM ensures that mappings of the objects are never split (clipped) on a non-superpage boundary. The fault handler is specially optimized to be very fast by quickly installing the superpage PTE, and to avoid touching all small pages constituing it. Currently the required pmap support is provided for amd64 with 2M and 1G superpage sizes. Sponsor: The FreeBSD Foundation __________________________________________________________________ NXP ARM64 SoC support Contact: Marcin Wojtas Contact: Artur Rojek Contact: Dawid Gorecki The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications. Completed since the last update: * Improve code in a couple of review cycles and merge following new features to the FreeBSD-HEAD (r361458 - r361464): + QorIQ platform clockgen driver + LS1046A clockgen driver + GPIO support for QorIQ boards + QorIQ LS10xx AHCI driver + VF610 I2C controller support + TCA6416 GPIO expander + Epson RX-8803 RTC Todo: * Upstreaming of the QorIQ SDHCI driver - it is expected to be submitted/merged to HEAD in the Q3 of 2020. Sponsor: Alstom Group __________________________________________________________________ amd64 pmap Fine-grained pv lists locking Links Patch=20 URL: https://reviews.freebsd.org/D24217 Contact: Konstantin Belousov FreeBSD kernel Virtual Memory subsystem handles 'normal' application memory, i.e. anonymous or file-backed shared and private mappings, with so called managed pages. Managed page is fully controlled by VM, which tracks it status. In particular, managed page can be made read-only for write-back to the file, or unmapped for reuse (paging). The machine-dependent VM layer, pmap, must support managed pages, for instance it must provide operations such as pmap_remove_write() to downgrade all mappings to read-only, or pmap_remove_all() to unmap the page from all address spaces. To implement this kind of operations, while not causing the overhead of scanning all page tables, pmap must track existing mappings of the page. The tracking is done by allocating a small data structure 'pv entry' per mapping, and linking all pv entries for the given page into pv list. Since pv entries come from context of different address spaces, pmap must provide synchronization to guarantee correctness of the list structures. Current pmap allocates one mutex per one 2M physical superpage in NUMA configurations, and MAXCPU =3D=3D 256 locks hashed by = the page physical address for non-NUMA. The end result is often undeserved lock aliasing causing pv list locks contention, since all 4k pages in the 2M superpage share the same lock, and reservations typically cause adjasted pages to come from the same superpage. The proposed patch creates a new kernel synchronization primitive called one byte mutex, which is embedded into the currently unused padding in machine-dependent portion of the struct vm_page. This way each page gets dedicated pv list lock without using any more memory. In the ever-important buildkernel benchmark on non-NUMA config, this change provides 2x reduction of the system time. One complication is that old locking distribution scheme made a natural fit for superpages promotion and demotion, since all embedded small pages shared the same pv list lock, and the operations basically fold/unfold corresponding pv entries. Now the promotion and demotion operations require taking all locks for constituent small pages, which provides small but measurable impact on them. It is possible to optimize it further by providing the 'superlock' on the first page from the superpage run, but the affected operations are relatively rare so that it is not even obvious that implementing the optimization would not slow down other pathes. Another important nuance of the pv entries handling is that sometimes pv entries allocator must not fail. Typically this is required when kernel makes a call to pmap_enter() which must establish new mapping, and for managed page this includes allocating the pv entry if existing cannot be reused. If allocator cannot get a fresh page from the vm_page_alloc(9), it opts to destroy some other managed mapping to either get a reusable pv entry from current pmap, or destroy enough managed mappings from some other pmap to free whole page. To do the reclamation, currently all pages from which with pv entries are allocated, are linked in the global pv chunk list, which is protected by global (per-NUMA domain) mutex. Any allocation or free of pv entry has to lock the mutex, which is apparently a contention point for large machines. Patch removes the global list of chunks, instead linking all pmaps in the global list like it is done on i386 (but for different reason). Now the global lock is only taken for pmap creation and free, which corresponds to fork/exec and exit of a process, and when pv allocator starts reclaiming from other pmaps (which is normally does not happen). Sponsor: The FreeBSD Foundation __________________________________________________________________ Lockless routing lookups and scalable multipath Links Implementation of scalable multipath=20 URL: https://reviews.freebsd.org/D24141#change-ZOjdMqgDgUr7 Contact: Alexander Chernikov The primary goal of this work is to bring scalable routing multipath implementation, enabled by default. Another goal is enabling high-performance routing lookups. Multipath will close long-standing feature gap that modern networking OS must have. Lockless routing lookups will remove lookup bottlenecks, improve both dataplane and control plane performance for the setups with large number of routes. Background The initial routing kpi was introduced back in 1980. It was a nice generic approach back then, as no one knew how the protocols would evolve. It has been enormously successful as it was able to survive for 20+ years. Unfortunately, this kpi does not try to protect subsystem internals from the outside users, resulting in tight coupling with other subsystems. As a result, making changes is hard, leading to compromises and piling technical debt. Implementation overview Most changes are based on introduction of the concept of nexthops. Nexthops are separate datastructures, containing all necessary information to perform packet forwarding such as gateway, interface and mtu. They are shared among the routes, providing more pre-computed cache-efficient data while requiring less memory. Interested reader can find more detailed description in D24141. Another overview can be found in Nexthop object talk describing Linux implementation. Multipath implementation extends nexthop concept further by introducing nexthop groups. Each route has a pointer to either nexthops or a nexthop group, decoupling lookup algorithm from the routing stack internals. Both nexthops and nexthop groups are immutable and use epoch(9)-backed reclamation. A pre-requisite for lockless routing lookup is the introduction of modular lookup framework, allowing to attach any longes-prefix-match algorithm implementation to any IPv4/IPv6 fib. Currently there are plans to use modified DIR-24-8 algorithm from DPDK for both IPv4 and IPv6 families as an example of base lockless implementation. Status * Nexthop objects [ DONE ] * Introduction of nexthop objects [ DONE ] * Conversion of old KPI users to the new one [ DONE ] * Conversion of route caching to nexthop caching [ DONE ] * Conversion of struct rtentry field access to nhop field access [ DONE ] * Eliminating old lookup KPI and hiding struct rtentry [ DONE ] Multipath [ IN PROGRESS ] * Switch control plane consumers to use (rtentry, nhop) pairs instead of rtentry to allow multipath changes happen transparently [ 90% DONE ] * Introduce nexthop group objects * Add mutipath support for the rib (routing information base) manipulation functions * Add flowid generation for outbound traffic to enable load balancing Modular longest-prefix-match lookup algorithm [ IN PROGRESS ] * Design control plane framework for attaching algorithms [ 90% DONE ] * Port IPv6 lockless lookup algorithm [ DONE ] * Port IPv4 lockless lookup algorithm __________________________________________________________________ ZSTD Compression in ZFS Contact: Allan Jude Zstandard (ZSTD) is a modern high-performance compression algorithm designed to provide the compression ratios of gzip while offering much better performance. ZSTD has been adopted in FreeBSD for a number of other uses, including compressing kernel crash dumps, as a replacement for gzip or bzip for compressing log files, and for future versions of pkg(8). This effort to complete the integration of ZSTD into ZFS is sponsored by the FreeBSD Foundation. Integrating ZSTD into ZFS will further extend the transparent compression feature of ZFS by offering higher compression ratios without the performance penalty associated with gzip. ZSTD offers compression levels ranging from 1 (low compression) to 22 (maximum compression), plus ZSTD-Fast levels that offer less compression but even greater speed. This will allow the storage administrator to select the performance-vs-compression tradeoff that best suits their needs. Tasks remaining to be completed: * Extend ZFS to support compression algorithms with large numbers of levels * Solve issues around the inheritence of compression settings * Restore compression level when reading blocks from disk * Create a future-proofing scheme to handle changing versions of ZSTD * Extend ZFS replication to handle backwards compatibility with pools that do not yet support ZSTD * Resolve issues around backwards compatibility when ZSTD is configured but not used Sponsor: The FreeBSD Foundation __________________________________________________________________ CheriBSD 2020 Q2 Links CHERI-CPU =20 URL: http://www.cheri-cpu.org DARPA FETT Bug Bounty Program=20 URL: https://fett.darpa.mil Contact: Alex Richardson Contact: Andrew Turner Contact: Brooks Davis Contact: Edward Tomasz Napierala Contact: Jessica Clarke Contact: John Baldwin Contact: Robert Watson Contact: Ruslan Bukin CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction set extensions. Support for CHERI-RISC-V in CheriBSD has continued to mature this quarter in tandem with refinements to the CHERI-RISC-V architecture. We have recently made CheriBSD's "pure capability" (CheriABI) process environment the default ABI rather than a compatibility layer. It has grown support for: * dynamically linked binaries (previously only statically-linked binaries were supported) * C++ including exceptions * sealed return address and function pointer capabilities ("sentries") which provide additional CFI protection * initial MMU protections for loading and storing tags At this point, CHERI-RISC-V support in CheriBSD is generally on par with support for CHERI-MIPS. Much of this effort has been focused on preparing CheriBSD on CHERI-RISC-V for inclusion as a demonstrator system in DARPA's Finding Exploits to Thwart Tampering (FETT Bug Bounty program). In addition, work has begun this quarter on porting CheriBSD to Arm's Morello SoC. Morello is a prototype demonstrator board which adds CHERI extensions to ARMv8-A. We've recently switched to a dev-branch model where active work takes place on the dev branch and we periodically merge to master with synchronization between CheriBSD and dependencies like CHERI-LLVM. For those interested in what it's like to program for CHERI, we've recently released a CHERI C/C++ Programming Guide. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. Continuous Integration on !x86 Contact: Edward Tomasz Napierala For quite a while the FreeBSD CI infrastructure has been running FreeBSD builds and regression tests, making it easy to spot regressions. While CI was building images for all architectures, the regression tests were only run on amd64 and i386, which means they couldn't detect architecture-specific runtime breakage on non-x86 architectures. This poses a problem not only for FreeBSD itself, but also for people working on FreeBSD forks for !x86, such as the CHERI project at University of Cambridge and SRI International. The goal of this project is to run regression tests on the remaining architectures supported by FreeBSD: ARM, ARM64, MIPS, POWER, and RISC-V. The tests are being run using common, mostly machine-independent scripts. Those required some changes to make it possible to use QEMU in addition to Bhyve, the hypervisor used for x86 tests. The sysutils/u-boot-qemu-arm and sysutils/u-boot-qemu-arm64 ports were added to the Ports Collection. Finally, each of the architectures required some tweaks, to account for different configuration requirements - for example the MIPS kernel doesn't support VirtIO disks, or even AHCI, whereas on ARM64 the U-Boot gets confused with more than one VirtIO disk. On ARM, we're currently at 52 failures and 590 skipped tests, of 5925 tests ran (https://ci.freebsd.org/job/FreeBSD-head-armv7-test/lastCompletedBuild/t= estReport/). On ARM64 it's 19 failures and 160 skipped (https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/lastCompletedBuild= /testReport/). On MIPS it's 172 failures and 734 skipped (https://ci.freebsd.org/job/FreeBSD-head-mips64-test/lastCompletedBuild/= testReport/). For POWER, and RISC-V the results are not available yet. Remaining work: * Failing regression tests need to be fixed. * The tests are quite slow on QEMU, for example the ARM64 run takes about five hours. Running them automatically after each commit would quickly overload the CI cluster. A solution would be to e.g. run them daily. * Some of the jobs still fail to produce results: powerpc64 deadlocks at the end of regression test suite due to an unkillable process, riscv64 panics randomly, and on mips64 kyua(1) often crashes on jemalloc assertion. Those might be fixed by an upcoming QEMU port update. Sponsor: DARPA __________________________________________________________________ FreeBSD/RISC-V Project Links Wiki=20 URL: https://wiki.freebsd.org/riscv Contact: Mitchell Horne Contact: freebsd-riscv Mailing List Contact: IRC #freebsd-riscv channel on freenode The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. Since RISC-V is still a young and evolving platform, one of our goals is to have FreeBSD be a well-supported option for users as RISC-V hardware increases in availability. This quarter saw a number of improvements to the boot process. The physmem interface used by arm and arm64 to enumerate physical memory resources was moved to machine-independent code and adopted on RISC-V. As a result, the kernel is now able to detect and exclude physical memory reserved by devices or firmware. A bug that prevented the kernel from using physical memory below its load address was fixed. This typically did not manifest in much waste, as the kernel is loaded 2MB after the start of physical memory by default. In future boot configurations, the impact would have been much larger. Our port for OpenSBI was updated to v0.8, bringing several new features and fixes. In particular, it brought the Hardware State Management (HSM) extension, which can be used to start and stop CPUs. FreeBSD will now use this extension whenever it detects that it is available. There has also been a lot of work done to port FreeBSD's standard bootloader, loader(8), to RISC-V. This has big advantages in terms of boot flexibility, and brings us closer to what's needed to produce official FreeBSD/RISC-V release images. By leveraging UEFI support from u-boot, loader.efi can be used in a manner similar to arm and arm64. Next quarter will likely bring u-boot ports for RISC-V targets, pending the v2020.07 release. Booting the kernel directly via SBI firmware will continue to be supported. __________________________________________________________________ Userland Programs Changes affecting the base system and programs in it. Import of new implementation of bc and dc Links Official repository =20 URL: https://git.yzena.com/gavin/bc Repository mirror on GitHub=20 URL: https://github.com/gavinhoward/bc/ Contact: Stefan Esser Contact: Gavin D. Howard A new version of bc and dc has been imported into FreeBSD-CURRENT and enabled by default. An import into 12-STABLE is planned before the end of July, but it will not be enabled by default (will require "WITH_GH_BC=3Dyes" to be set in /etc/src.conf). This version has been developed by Gavin D. Howard with the goal to provide a highly portable and POSIX compatible implementation. It offers GNU bc compatibility and should be a drop-in replacement for the bc in FreeBSD, except for standard-violating behavior of the bc currently in FreeBSD (e.g., the modulo operator). Additional features: * High performance (up to more than a factor of 100 faster than the current FreeBSD implementation in some tests) * support of message catalogs with a large number of languages supported in the current release (contributions of further translations are welcome). * Extra built-in functions and operators. * Extended library of advanced math functions * Detailed man-page explaining standard conformant and extended features * One shared binary for bc and dc (bc is not just a pre-processor that relies on dc for the actual computations) The only dc feature not supported by the dc is the execution of sub-processes, since the author considers it a security hazard for a calculator to have. This code is also available as a port and package (math/gh-bc or gh-bc), e.g. for use with a FreeBSD binary release. __________________________________________________________________ Binutils Retirement Links GPL in Base wiki page=20 URL: https://wiki.freebsd.org/GPLinBase Contact: Ed Maste We have been working on migrating to a modern and copyfree or permissively licensed toolchain for quite some time. In the last quarter we retired two obsolete GNU bintuils: objdump, and as. Many uses of objdump can be replaced with readelf, and llvm-objdump is also available in the base system. Ports that depend on objdump have been updated to rely on the GNU binutils port or package. The GNU as utility was used by both the base system and by ports. As with objdump, ports that require GNU as have generally been updated to depend on binutils. One file in the base system (skein_block_asm.s) proved troublesome during earlier attempts to migrate to using Clang's integrated assembler (IAS). However, after the update to Clang 10 (and with some trivial modifications to the source) IAS can assemble the file. Both GNU as and objdump have been removed from FreeBSD-CURRENT and will be absent from FreeBSD 13.0. TODO The final task in the binutils retirement project is to remove GNU GDB 6.1. It is currently retained for crashinfo(8). Sponsor: The FreeBSD Foundation __________________________________________________________________ Run-Time Dynamic Linker improvements Contact: Konstantin Belousov Rtld gets some number of small bug fixes and improvements. RTLD_DEEPBIND dlopen(3) flag was implemented, despite being a strange and even unsafe idea, for compatibility with glibc. Several improvements to the direct execution mode were made. Most interesting are perhaps the '-v' switch to report some configuration parameters for rtld, the ability to specify argv0 different from the executed binary name, and fixes to properly set osrel/ABI for the directly executed binary. The link_map structure that is used by tools that need to know the list of loaded shared objects (like gdb and wine) was made more compatible with glibc, while keeping existing FreeBSD ABI intact. In the course of the link_map work, it become apparent that rtld sometimes needs to report presence of features that cannot be deduced by just a runtime test for symbol presence or for function behavior. For that, a scheme of reporting features with uniformingly named symbols was designed - see the rtld(1) man-page (in CURRENT) for an explanation. Position-independent (PIE) binaries on FreeBSD are now marked with the DF_1_PIE DT_FLAG1 flag. Otherwise, such binaries are just ET_DYN objects and it is quite hard to distinguish proper dynamically shared object (DSO) from PIE binary. The problem is that for binaries, the static linker strips some information which is required for proper loading as a DSO, and additonally, binaries contains relocations like copy-relocations that cannot be handled for non-main binaries at all. With the flag addition, rtld properly detects binaries and refuses to load them with dlopen() or as DT_NEEDED dependency. ldd(1) also misdetected PIE vs. DSO, and required a fix to parse dynamic segments to not try to dlopen() them. Sponsor: The FreeBSD Foundation __________________________________________________________________ VHDX support in mkimg(1) Contact: Oleksandr Tymoshenko VHDX is the successor of Microsoft's VHD virtual drive file format. It increases maximum capacity of the virtual drive to 64TB and introduces features to better handle power/system failures. VHDX is the required format for 2nd generation Hyper-V VMs. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Bastille Links Bastille GitHub =20 URL: https://github.com/bastillebsd/bastille Bastille Templates=20 URL: https://gitlab.com/bastillebsd-templates Bastille Website =20 URL: https://bastillebsd.org Contact: Christer Edwards Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD. Bastille Templates automate container setup allowing you to easily reproduce containers as needed. Bastille is available in ports at sysutils/bastille. Q2 2020 Status In Q2 2020 Bastille merged some exciting new features into GitHub. Changes include: * experimental support for new Bastillefile template syntax * added mount and umount sub-commands * added a default Vagrantfile for simple testing * experimental support for empty containers * improvements to VNET DHCP support * cosmetic bugfixes in error output * extended config file documentation * updated bastille help output * option to (-f) force destroy container sysutils/bastille was updated to 0.6.20200414 (latest). New Bastille templates added this quarter include: * Percona database server * Asterisk SIP server * dnsmasq DNS/DHCP server (VNET required) * nginx pkg server for poudriere Everything mentioned here was done under COVID-19 quarantine. Special thanks to everyone that contributed during this time. __________________________________________________________________ KDE on FreeBSD Links KDE FreeBSD =20 URL: https://freebsd.kde.org/ KDE Community FreeBSD=20 URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software produced by the KDE Community for FreeBSD. The software includes a full desktop environment KDE Plasma, IDE KDevelop, a PIM suite Kontact and hundreds of other applications that can be used on any FreeBSD desktop machine. This quarter has been an ever-so-peculiar one. While we are used to working remotely, collaborating over the internet to update the ports tree, it's qualitatively different when the whole world locks down. Meanwhile, software continues to be released, so this quarter the kde@ team: * Restored a patch that closes down a remote TCP held by X11 applications that use the ICE library. Thanks to Colin Percival for reporting it. It went missing in one of the port updates. To prevent this in the future, the patch has been upstreamed. PR 229772. * Chased KDE-adjacent software like CMake, Cutelyst, Latte-dock and Nheko through new releases. In particular CMake takes a lot of effort every time because it is a build-time dependency of over 2000 ports. * graphics/poppler was updated to the latest upstream release. This is a low-level dependency for many document-viewing applications, and like CMake requires chasing a lot of other software. Poppler is one of the components shared between various software stacks (and "desktop environments") under the desktop@ group, in which kde@ participates. * KDE Frameworks release like clockwork, reaching KDE Frameworks 5.70 mid-may. * KDE Applications -- the KDE release service, really, which delivers libraries, applications, and add-ons -- had one large release, with 20.04.1 landing in the ports tree also mid-may and its monthly update 20.04.2 in mid-june. * Some new Wayland support for KDE Plasma -- we have not tested this on FreeBSD -- has appeared and has been duly packaged. * A great deal of preparation has gone into Qt 5.15. Many ports have been pre-emptively patched for this new -- and last -- LTS release of Qt 5. The update itself has not yet landed, pending a few last bits of fallout. The kde@ team would like to thank Antoine for many exp-runs, mikael@ for useful tips, swills@ for patience and kai@ for dealing with WebEngine. The next big round of updates for the KDE stack is slated: CMake 3.18, Qt 5.15 LTS, and KDE Frameworks 5.71. __________________________________________________________________ Haskell on FreeBSD Links Haskell language homepage=20 URL: http://www.haskell.org/ Ports development repo =20 URL: https://github.com/freebsd/freebsd-ports-haskell Contact: Gleb Popov Haskell is a general-purpose strictly-typed pure functional language. The Haskell on FreeBSD projects strives to provide the up-to-date Haskell toolchain as well as various application written in this language. This quarter brought the long-awaited GHC update, which is now at version 8.8.3. Along the compiler, the Haskell build system frontend, cabal-install, was also upgraded to 3.0.2.0. During this update, numerous Haskell ports were updated too. All existing ports of Haskell applications were migrated to USES=3Dcabal, which implements Go-style build proccess - all dependencies are compiled as part of the build. As a consequence, ports for Haskell libraries have been deprecated and removed. Upgrading GHC became a tedious task for a single person, so a new GitHub repository was created under the FreeBSD organization - freebsd-ports-haskell. Right now, work is being done on preparing another GHC upgrade in the ghc-upgrade-810 branch. Any contributions are welcome. __________________________________________________________________ rtsx - Porting driver for Realtek SD card reader from OpenBSD Links rtsx =20 URL: https://github.com/hlh-restart/rtsx PR204521=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204521 Contact: Henri Hennebert The rtsx driver for Realtek SD card reader has been ported from OpenBSD. Its development snapshot is available via the sysutils/rtsx-kmod port. From March to May 2020, the code has been completed with the help of Gary Jennejohn (gj@) and Jesper Schmitz Mouridsen (jsm@). Some tweaks have been imported from the Linux counterpart. The driver has been successfully tested with: * RTS5209 under head (Lenovo ThinkPad L520) * RTS5227 under stable/11 and releng/12.1 (HP ProBook 430 g2, Lenovo ThinkPad T450/T450s) * RTS5229 under releng/12.1 (Lenovo IdeaPad 120S-14IAP) * RTS522A under releng/12.1 and head (Intel NUC8i5BE, Lenovo ThinkPad P50s) * RTS525A under releng/12.1 (Dell Latitude E5570) * RTL8411B under stable/12 (Acer Aspire E 15 E5-576-77W6) The driver should also work for Realtek RTS5249, RTL8402 and RTL8411. More tests are welcome, especially for the devices not yet tested. These devices may require more tweaks. PR204521 contains the bulk of exchanges for completion of the code. __________________________________________________________________ Valgrind updates Links Patch for valgrind=20 URL: https://reviews.freebsd.org/D25452 Contact: Paul Floyd Contact: Kyle Evans A large amount of work has been done to rebase FreeBSD support on top of Valgrind 3.17.0, and to address numerous test suite failures. Currently, almost all of the regression tests pass on amd64. This is a major improvement over the current state of affairs, in which the Valgrind is quite out of date and is missing important functionality. Some follow-up work aims to make FreeBSD an officially supported target platform for Valgrind. The devel/valgrind-devel port is in the process of being updated to point at the new work. __________________________________________________________________ Documentation Noteworthy changes in the documentation tree, in manpages, or in external books/documents. FreeBSD Translations on Weblate Links Translate FreeBSD on Weblate wiki=20 URL: https://wiki.freebsd.org/DocTranslationOnWeblate FreeBSD Weblate Instance=20 URL: https://translate-dev.freebsd.org/ Contact: Danilo G. Baio Contact: Edson Brandi This quarter was improved the renderization of RTL (Right-to-left) languages on the FreeBSD Documentation. We faced this issue after the first RTL language joined the translations effort (fa_IR). We are looking forward to receive more languages and translators to the project as well. Q2 2020 Status * 10 languages (No new languages) * 80 registered users (33 new users since last quarter) Languages * Chinese (Simplified) (zh_CN) * Chinese (Traditional) (zh_TW) * French (fr_FR) * German (de_DE) * Italian (it_IT) * Norwegian (nb_NO) * Persian (fa_IR) * Portuguese (pt_BR) * Spanish (es_ES) * Turkish (tr-TR) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. __________________________________________________________________ Miscellaneous Objects that defy categorization. FreshPorts Links FreshPorts =20 URL: http://freshports.org/ FreshPorts blog=20 URL: http://news.freshports.org/ Contact: Dan Langille FreshPorts, and its sister site, FreshSource, have reported upon FreeBSD commits for 20 years. They cover all commits, not just ports. FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port developers and port users. For example, https://www.freshports.org/security/acme.sh/ shows the history of this port, back to its creation in May 2017. git Work on git started back in September. It was ignored for a while and started back in mid-June with the creation of new git-specific jails for commit ingress (commit processing gitdev) and for the website. Serhii (Sergey) Kozlov created a script to transform GIT commit entries into XML digestible by FreshPorts. This was a huge step foward for the effort. The next step include: * incorporate a that script the automated processes of FreshPorts * migrate to new test & stage versions of FreshPorts * test * get ready for prod Help wanted git is not far away now. I could use helpers to * review code * watch the commits on the devgit websites * catch missing stuff Thank you Packages FreshPorts now displays the packages version available from the repo sources. This covers all primary tiers (e.g. FreeBSD:12:amd64) and all secondary tiers (e.g. FreeBSD:13:powerpc64). This helps uses know what versions they can expect and when then repo was last built. Dependency lines Some things are easiest done via copy/paste. If you are working on a port Makefile and need to add a new dependency, FreshPorts shows the dependency line for that port. For example: acme.sh>0:security/acme.sh Libraries are also covered by this feature. Python ports were recently adjusted to display ${PYTHON_PKGNAMEPREFIX}virtualenv>0:devel/py-virtualenv instead of py37-virtualenv>0:devel/py-virtualenv You can read more about this change in [issue #73](https://github.com/FreshPorts/freshports/issues/73). Watch ports I maintain The search page has long had the "Ports I Maintain" button (if you are logged in). This feature recently branched out to a new automated watch list option: Watch ports I maintain. This report subscription will notify you of any commits to the ports you maintain. Your email address on FreshPorts must match the value in the MAINTAINER field of the port. This is always a daily report. From time to time, an infrastructure change will occur which touches your port. This feature ensures you know about that change. Repology links Repology links were requested. This allows you to see what versions of that port are in the repositories of other systems. A link to repology.org appears on every port page. Further reading Based upon things you didn't know FreshPorts can do There are many things FreshPorts can do, including search Makefile's and pkg-plist. This is from a recent blog post: * provides example dependency line. e.g. p5-XML-RSS>0:textproc/p5-XML-RSS * list of dependencies for a port * list of ports depending upon this port * see default configuration options * what packages install a given file (e.g. bin/unzip) * find out what ports a person maintains * find Makefiles which contain references to bunzip * search results can be plain-text consisting of a list of foo/bar ports * the Maximum Effort checkbox on the search page does nothing * committers can be notified of sanity test failures after the commit * find a commit, any commit, based on SVN revision number, e.g. : https://www.freshports.org/commit.php?revision=3D352332 Javascript help wanted We recently upgraded some outdated Javascript modules. This broke our [JavaScript based graphs](https://www.freshports.org/graphs2.php). We could use some help on fixing that please. The starting points are listed on that URL. If you need a working website to play with, please contact me with a ssh public-key. Sponsor: hardware provided by iXsystems __________________________________________________________________ PCI passthrough with bhyve on Intel and for OpenBSD guests Links bhyve Intel bug report=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229852 bhyve OpenBSD bug report=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245392 PCI passthrough with bhyve (FreeBSD wiki article)=20 URL: https://wiki.freebsd.org/bhyve/pci_passthru Contact: Anatoli Contact: Callum Contact: Peter Grehan bhyve(8) is a hypervisor that supports running a variety of guest operating systems in virtual machines. bhyve(8) includes support for PCI devices passthru, a technique to pass host PCI devices to a virtual machine for its exclusive control and use. For some years, PCI passthrough (ppt) in bhyve was not working on some Intel systems and for OpenBSD guests due to two bugs. The first one was crashing FreeBSD host when bhyve was started with ppt on Intel processors with two VT-d translation units (IOMMU), included in most Skylake and newer Intel processors. The second bug was preventing correct interrupts handling for OpenBSD guests. As a result, OpenBSD guests running on bhyve were not able to use any PCI devices passed through to them from the host. During the last 2 months the second bug was identified and fixed and they both were backported to 12.1-RELEASE (p7). So now it's possible to fully take advantage of PCI passthrough (ppt) with bhyve in a production-ready RELEASE version. The most typical case for ppt is to pass to the guest network adapters for its complete control, but you can also pass through USB devices (including external HDDs). Note though, passthrough of VGA and GPU devices is not supported yet (for more details see the 3rd link). A particularly interesting case for ppt is to use OpenBSD guest as a firewall and a router for a FreeBSD server. With ppt you can achieve this all inside a single server. You could pass to the OpenBSD guest a network adapter connected to the internet and it would take a complete control of it. After filtering the traffic, it could pass good packets via virtual network interfaces to other guests or to the host. Once a network adapter is passed through, a FreeBSD host not only doesn't see it and hence doesn't handle the network traffic, it doesn't even have to initialize the adapter (e.g. in case of a WiFi card, it's the guest that loads the firmware). In simple terms the host only passes the device interrupts to the guest as they come from the hardware. Everything related to the device management happens inside the guest so there's no danger that some network traffic exploits some issue in the host's network stack and causes the host to crash or misbehave in other ways. __________________________________________________________________ SageMath Links SageMath site=20 URL: https://www.sagemath.org/ Contact: Thierry Thomas SageMath is a free open-source mathematics software system licensed under the GPL. It builds on top of many existing open-source packages: NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more. Thanks to SageMath it is possible to access their combined power through a common, Python-based language or directly via interfaces or wrappers. The goal is creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab. This is a complex port, with a lot of dependencies, and it has been broken for some time. Upstream is working on easing its packaging, and many previously bundled applications can now be replaced by external packages. If you are interested, it would be nice to create a team of maintainers * to maintain some of the dependencies; * to maintain SageMath itself and prepare the next release (9.2 is coming!). __________________________________________________________________ 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. chaifi - a tool to simplify joining public WiFi networks Links chaifi=20 URL: https://github.com/gonzoua/chaifi Contact: Oleksandr Tymoshenko chaifi is a TUI (text UI) utility aimed at simplifying the process of joining public WiFi networks in places like coffee shops or libraries. It replaces the process of scanning and manually editing wpa_supplicant.conf with an interactive dialog. The utility is in no way a replacement for full-featured network managers in major desktop environments. Still, if you're working from a console or using a tiling window manager, it may save you some seconds (or in worst case minutes) of your time. __________________________________________________________________ MixerTUI Links mixertui=20 URL: https://gitlab.com/alfix/mixertui Contact: Alfonso Sabato Siciliano MixerTUI is a volume mixer with a Terminal User Interface built on the FreeBSD sound system. It can show the current Sound Driver configuration and select an audio device: to get its information, to change the volume or to set it as default, the last feature allows to switch easily audio from/to laptop and hdmi, headphones and speakers, and so on. MixerTUI can be installed via the audio/mixertui port. I would like to thank the FreeBSD community for the tips, feedbacks and patches to improve this project. __________________________________________________________________ Potluck - Flavour & Image Repository for pot Links Potluck Repository & Project=20 URL: https://potluck.honeyguide.net/ Potluck on github =20 URL: https://github.com/hny-gd/potluck pot project =20 URL: https://pot.pizzamig.dev Contact: Stephan Lichtenauer pot is a jail management tool that also supports orchestration through nomad. Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: A repository of pot flavours and complete images for usage with pot. This should simplify setting up complex software with many packages and ports in comparison to manual configuration: Potluck aims to provide a content library as an additional layer of abstraction, on top of existing infrastructure like pkg, that pot has to offer. Pot "flavour" files are provided on [Github]((https://github.com/hny-gd/potluck)) and fed into a Jenkins instance. On the Potluck Repository, for each flavour, detailed descriptions as well as ready-made images to be imported by pot are provided. The initial project has been set up, and three simple flavours, along with a complete Jitsi Meet instance in a jail has been created as a Proof of Concept that should allow running a fully-fledged video conference system with just a few easy commands within a few minutes. As only the initial versions have been set up and implemented so far, general feedback, tests, as well as additional, useful flavours are very welcome! __________________________________________________________________ News Home | Status Home Site Map | Legal Notices | =A9 1995-2020 The FreeBSD Project. All rights reserved. --psc724i6dgwcog6o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl8PhDNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87q0pgf+ORZtgQTDGH9iCasAtK/BAm+eFWE2eNcsZzRPMa5+Ixki4udFJYbMyYDc gxFVN5yjXtHZchSAM77IARAKCQqrNylokXcy7mFpqLWJybIdmUaXpdoMgawQq78e sUuB/trl/DOBXHCZxx9RiN5r0QZ0Rx0UtE/Gg0b0GNylYC7ul0JDrZPJVmH0IvkZ fD9KcBeo3S/uPzfb/6QsDzYbZkv7hHXcxTTgXwKk7lfwDT+2CoDN34AgrJz/JZSx 3yxHClupkYkiq3JrgT4ySk3x+l626PpGjaccGJgHlW2fbvB7wEXikwiBApzQKQxu jBnucUx4HJBQ4Qqrynod69SJea2tYg== =Kiys -----END PGP SIGNATURE----- --psc724i6dgwcog6o-- From owner-freebsd-hackers@freebsd.org Wed Jul 15 22:34:39 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1A6D4371798 for ; Wed, 15 Jul 2020 22:34:39 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6XHy4lpGz4Wcm for ; Wed, 15 Jul 2020 22:34:38 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 0CE231F183; Wed, 15 Jul 2020 22:34:38 +0000 (UTC) Date: Thu, 16 Jul 2020 00:34:36 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2020 Message-ID: <20200715223436.ndvr7yzibbbk3k3i@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> <7025a36e-52bf-ca18-185f-3c9adebdf26b@yuripv.dev> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5rayffq2d2y4yfyn" Content-Disposition: inline In-Reply-To: <7025a36e-52bf-ca18-185f-3c9adebdf26b@yuripv.dev> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 22:34:39 -0000 --5rayffq2d2y4yfyn Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 16, 2020 at 01:29:09AM +0300, Yuri Pankov wrote: >Daniel Ebdrup Jensen wrote: >[nothing] > >At least in Thunderbird the text is not inline, and rather shows as=20 >attachment. Hi Yuri, Yes, I forgot to toggle the file between inline and attachment. I could blame my MUA, but I won't. :) Yours, Daniel Ebdrup Jensen. --5rayffq2d2y4yfyn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl8PhHxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87qOaQgArye4KYbfyFrLpKJ9Nb0MC0UQk6oiLu6AzwMgPA0mtT/XZCH3WBKhckbX e+Hv6jv6kleWyTngg3coJB+I2bW1PvtpgRMaT8LDA1teqtNvpZb8x2rrB/JJaPO7 ecLZXVrBwobjFI4/IQNE1CrXxiWlZw9slji2YeFpFu3Oh6CFJMwqj2pXuv/PBQ83 AYz1NAmKbPzpB5IMeOr1oBob9Bh44ZXHVPnm1+IatDTCpxnMwiBIQKDOaGScZmPt HQ1XFGugs+WhakDMN78rnEd0Og+JOLd0I83q5R5C1zarlHGRK1B2g1fvGvhSNhGg 6XpAPRCYK6gh7c5A1Cz0U5PD21DvKA== =NgEP -----END PGP SIGNATURE----- --5rayffq2d2y4yfyn-- From owner-freebsd-hackers@freebsd.org Thu Jul 16 06:13:49 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1AE73356C88 for ; Thu, 16 Jul 2020 06:13:49 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [93.151.207.39]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6kTl3zS5z453k for ; Thu, 16 Jul 2020 06:13:47 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 5220 invoked from network); 16 Jul 2020 06:13:44 -0000 Received: from carbon.alexdupre.com (HELO ?192.168.178.18?) (sysadmin@alexdupre.com@192.168.178.18) by lab.alexdupre.com with ESMTPSA; 16 Jul 2020 06:13:44 -0000 Subject: Re: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? To: bsd-lists@BSDforge.com, =?UTF-8?Q?Stefan_E=c3=9fer?= Cc: FreeBSD Hackers , Mel Pilgrim References: <31a5001f9da0e7b89c49cc14ff1fe78b@udns.ultimatedns.net> From: Alex Dupre Message-ID: <343350b9-5f9d-405e-4f04-9ae1309d58ae@FreeBSD.org> Date: Thu, 16 Jul 2020 08:13:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.2 MIME-Version: 1.0 In-Reply-To: <31a5001f9da0e7b89c49cc14ff1fe78b@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4B6kTl3zS5z453k X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; ASN(0.00)[asn:30722, ipnet:93.151.128.0/17, country:IT] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 06:13:49 -0000 Chris wrote: >> >> I've just started working on creating a port of the official Realte= k >> >> driver. Latest release should support the 8125 chipset and WOL. It >> >> should be ready very soon (likely today or tomorrow). Just committed, thanks for support in testing it: https://svnweb.freebsd.org/ports?view=3Drevision&revision=3D542324 --=20 Alex Dupre From owner-freebsd-hackers@freebsd.org Thu Jul 16 18:08:18 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BC8DC36943E for ; Thu, 16 Jul 2020 18:08:18 +0000 (UTC) (envelope-from se@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B72LB4VNtz3cjl; Thu, 16 Jul 2020 18:08:18 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f0bb900586834142334a5fa.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:b900:5868:3414:2334:a5fa]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 1448510167; Thu, 16 Jul 2020 18:08:17 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? To: Alex Dupre References: <61362d77-b283-b00e-c7cd-9f93ea937728@freebsd.org> <9a3c9521-c229-2542-70ec-fc2a2bf6f8f3@bluerosetech.com> <6c8fdae0-4fd5-142c-87f8-1f4026bbd8a1@freebsd.org> <6382c967-b7fa-0581-f16e-504a909809f2@FreeBSD.org> <10310e5c-538d-12f9-e504-bca8f75f1aa3@freebsd.org> <956a1f83-7210-df80-8ba1-a239bf06471b@freebsd.org> <4fe0da81-941a-2a89-241b-290ee4ba8457@FreeBSD.org> <262b5b96-5193-abde-91de-f4a6cafec210@freebsd.org> From: =?UTF-8?Q?Stefan_E=c3=9fer?= Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Cc: FreeBSD Hackers Message-ID: <9eac4973-f026-874c-84da-e6892e3935d1@freebsd.org> Date: Thu, 16 Jul 2020 20:08:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 18:08:18 -0000 Am 15.07.20 um 21:00 schrieb Alex Dupre: > Stefan Eßer wrote: >> But I really want to have this code merged into the kernel module. > > I'm absolutely not against it, but I'm not going to do it. The primary > reason that many of us are using the realtek driver is that the FreeBSD > one is buggy, and nobody knows why and where. The code diverged probably > more than 10 years ago, with new features (and bugs) added and now they > are almost two completely different drivers, hard to compare, so porting > the code to support new chipset is welcome and doable, but it won't fix > the issue most of us are experiencing, so the port is still really needed. The driver provided by Realtek contains a list of some 50 supported chip versions, to deal with specific hardware issues of several of them. And it contains microcode to replace or patch the (probably also somewhat buggy) code embedded in the hardware. But the driver lacks a number of features present in the FreeBSD version, e.g. NETMAP, interrupt moderation/polling and it seems to contain bugs that are ignored when building with the less strict warning level used for ports. (E.g., see the return value and the actual exit from re_intr() in the Realtek version ...) It does not take advantage of features Ethernet drivers in FreeBSD typically use, e.g. the MII PHY code, and it does even define the PCI config space register offsets instead of using the FreeBSD header to get them. I have not compared it to versions for other operating systems, but I guess that some of the redundancy is a result of only using the LCD of what these operating systems provide (and rather relying on embedded definitions than system header files which might have been moved or might exist only in particular OS releases). Anyway, it will be quite an effort, but I have started to merge the actual driver code (after a merged if_rlreg.h has been finished and allows to build the FreeBSD re driver while containing the defines for the RTL8125). Since I'm away from my test system for most of the next week, I'll not be able to test any of my code before end of July, but I intend to continue this project with the goal of a stable driver for all Realtek chips that uses the microcode and other information from the Realtek driver and adds RTL8125 support. Regards, STefan From owner-freebsd-hackers@freebsd.org Thu Jul 16 20:20:57 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7D8F836CB1C for ; Thu, 16 Jul 2020 20:20:57 +0000 (UTC) (envelope-from bmcgover@cisco.com) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (Client CN "iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B75HD4QZVz42sn for ; Thu, 16 Jul 2020 20:20:56 +0000 (UTC) (envelope-from bmcgover@cisco.com) IronPort-PHdr: =?us-ascii?q?9a23=3AFQXq6hLFO82VzHw/ANmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKU/gkXEUI/A57RDkeWF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGFtzzalfJrju19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWCAA5tRBf/4cNJK1ggQmBSoEjL1E?= =?us-ascii?q?HgUcvLId5A6E4hGyCUwNVCwEBAQwBAS0CBAEBhEwCghMCJDcGDgIDAQELAQE?= =?us-ascii?q?FAQEBAgEGBG2FWwELhggVGQEBOBEBDHQnBBsahQNNAy4BoE8CgTmIYXSBATO?= =?us-ascii?q?DAQEBBYUkGIIOCYE4gmqKCBqBQT+BEUOHAEqDR4ItmR6BO5pgCoJdBJl9n0G?= =?us-ascii?q?RfJ59AgQCBAUCDgEBBYFpJIFXcBWDJFAXAg2OKheDTopWdDcCBggBAQMJfIx?= =?us-ascii?q?3gjUBAQ?= X-IronPort-AV: E=Sophos;i="5.75,360,1589241600"; d="scan'208,217";a="798433692" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jul 2020 20:20:54 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 06GKKsaE020711 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Jul 2020 20:20:54 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jul 2020 15:20:54 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jul 2020 16:20:53 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 16 Jul 2020 15:20:53 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I2ARgXSTDIqXAfQyrIqDEbHfyX/iPhtIZe4hC4aHHFkuLtAjMYw4lVwB0s7awfhjBIEMRxtsjJAhnl+Wl3moKLJB4+gabBBdIl7xMdQTGjcYJa84WSFyQI/Tuo1mmYtuMMq0UBGVrXQrRDTWTRNc2ykDzjJxf9EVsgVFH2j3/rtcsdLt1f9jDsonYFiaCbrwiswmMjT7C3710pYDJcNcnRRFn9N5O0LD0IwKvDScAPiavr15KR2TIWE6Li5BOPjHcSsV4wmP8G+jjUNvItzineZUQopPEVB9k3w+xs/FZ3eLNLkb4WdeAbYlvkwu2ETngDfIAEltknEAzDW+DNcnIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YxH3Bkt3sGJIBLG4nP95KarVj65GblD3MRKd6S+8BEc=; b=Rj1FohuseqyfBkslrbLYeYVJY4aGMPhOYnEl7fp79y2R/t1VleyKpRLGw50tZopnAoN1haufcMx6qntwllDzS+oORBlxbGoTgG+PZJLqMLRNK22PuFNzkeRxGr8I0oPy6GZCv+xnbyOcCT8sFKW0gw6epjI1O95qPeUegpYmWwh9nmN8M+Z/wO9gZL3/AeV5YhVZpmzO5D1JwU/KoJHafLAERkKH/zvBjDjoFhqzt53tMdDXQ9qkDrKCTHjMiEaTmwgD/cSkclPZoG9Ni7onwDaoMiT0XE7F9uAI4B8p66AbSL3AYMrAbPl1GcZ730zGor74gwUKJX9jVv50aD6wBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none Received: from BL0PR11MB3442.namprd11.prod.outlook.com (2603:10b6:208:68::19) by MN2PR11MB4317.namprd11.prod.outlook.com (2603:10b6:208:179::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.23; Thu, 16 Jul 2020 20:20:52 +0000 Received: from BL0PR11MB3442.namprd11.prod.outlook.com ([fe80::844f:50d2:7986:e539]) by BL0PR11MB3442.namprd11.prod.outlook.com ([fe80::844f:50d2:7986:e539%7]) with mapi id 15.20.3174.026; Thu, 16 Jul 2020 20:20:52 +0000 From: "Brian Mcgovern (bmcgover)" To: "freebsd-hackers@freebsd.org" Subject: Question on structure of USB (specifically USB Serial) stack Thread-Topic: Question on structure of USB (specifically USB Serial) stack Thread-Index: AQHWW66ajFBPEQF6REi43/I0wUQCzA== Date: Thu, 16 Jul 2020 20:20:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:18c:d07f:d140:547b:bff9:d6a8:7b19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 75423e68-441f-447c-1e53-08d829c5bcaa x-ms-traffictypediagnostic: MN2PR11MB4317: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iGw+Xf++h7NW9VKipB1KXaDsqPBCfUdbeixNY4NJnSk0glz0DYBAcTEKRrxorv8Pn3Q1xTw8GV8isxQCipG5ZalPC6M4PWQVmp7WOwWoZD0xmK0AfmANPsKNv/vJPaqwzB9SrHcmrudeZPSSuqysvyTbjFCjAraIStbAJLfo4HDGJy/Bkk7uxoclCRpmk6ng3WY5x4Bx7F+qBX+ZGFoY8TKpN2NDboleVQTK/TO0KpQmEpTS1plWmosc8rQDyBDCTj8rfLAVOfmOsbcp9xghc62owH8AVmJYyJ7S5FygEeGF7GBGWMkADhtcn8VeexOO x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3442.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(366004)(396003)(346002)(136003)(66556008)(5660300002)(64756008)(8936002)(316002)(86362001)(83380400001)(66946007)(66446008)(8676002)(6916009)(19627405001)(76116006)(7696005)(71200400001)(52536014)(66476007)(9686003)(33656002)(6506007)(478600001)(55016002)(2906002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: TOMaMRzMjrmqHhQf3b0juMkBbKN8UdOSPPeGXvhheg3J9V6PzHt25P4BmuMCixxAEFf0mdaRvt/QzEdtGbQ55wLqMasr1Byaz+j4LL3GChiSUPIdunSQIcwV+3sxDaihnuVfIcybnJ0AtwB8rLMyBNoGyOueOdMb8KENTarX7zoofPlC2ZbVuhxdaOObteqv2DRcJ1aJkFgIiPFOZNiwIumMnMT997Fs+SnTUI77jLn0xtZcdd5ny/V1WUOapj/eIBhTdSCOR5FkXdox0aeMILbXB6TmeRlsZh4UkM9irFa7P5w5ShMqMYerrDXXmlNcEdBEIz4P6UA94KmiLqdGnb1Y5cWm5YoPgAbC77s//Tbu3ci77PplgASo66JQ4SdoE9v5kCYQwoevzkwRxMxMU5bAWBsAgTSKZzso2tU4Ee1yMAMGu2PDi+LCnm8v6FVTg5BuTlI9wchqgg6NjRgvKxkxzH28NVSS4a8GFKG1KrB0X56fwDGUCF+Wtg07wn5QftVtAqv3AUHKrF+1X6bM2nqXRPdrE7BEr2quQtbe03Wdy1ozvgz96h4jg7cAkheL x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3442.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 75423e68-441f-447c-1e53-08d829c5bcaa X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2020 20:20:52.1814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mHnrNAOdiD2PIZnQLdNtSqUTrg1Rt0i85qqoIdHRCdJbxcifos5voyaxTmrxwS16mSb5ZeqRhcoAxmi9FcDQkw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4317 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-2.cisco.com X-Rspamd-Queue-Id: 4B75HD4QZVz42sn X-Spamd-Bar: ----------- X-Spamd-Result: default: False [-11.59 / 15.00]; NEURAL_HAM_MEDIUM(-1.01)[-1.014]; R_DKIM_ALLOW(-0.20)[cisco.com:s=iport,cisco.onmicrosoft.com:s=selector2-cisco-onmicrosoft-com]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[cisco.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:173.37.86.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.02)[-1.017]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; RCVD_DKIM_ARC_DNSWL_HI(-1.00)[]; WHITELIST_SPF_DKIM(-3.00)[cisco.com:d:+,cisco.com:s:+]; DKIM_TRACE(0.00)[cisco.com:+,cisco.onmicrosoft.com:+]; DMARC_POLICY_ALLOW(-0.50)[cisco.com,quarantine]; NEURAL_HAM_SHORT(-1.06)[-1.059]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:109, ipnet:173.37.64.0/18, country:US]; RCVD_COUNT_SEVEN(0.00)[8]; RWL_MAILSPIKE_VERYGOOD(0.00)[173.37.86.79:from]; RCVD_IN_DNSWL_HI(-0.50)[173.37.86.79:from] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 20:20:57 -0000 All, I'm doing some playing with the ucom code, and I'm down to a link in the = data that I'm just not confident I've parsed the code correctly. In sys/dev= /usb/serial/usb_serial.c, specifically in ucom_attach_tty, I'm trying to g= et a reference to the usb_device structure for the device used elsewhere in= the USB code. The specific devices I'm working with are USB->RJ 45 cables = with a built in FTDI chip, in case this matters It appears that the ucom_super_softc and ucom_softc structures are availa= ble. From looking around the code, it appears the sc_parent field of ucom_s= oftc is pointing back to the uftdi_softc structure in uftdi.c (for the uftd= i case), so the path would be ucom_softc->sc_parent->sc_udev, but my concer= n is going through the void *, as it appears each of the devices that use u= com as the base have sc_udev in a different part of their structure, meanin= g I'm likely going to crash the system if I plan on it being an FTDI device= , and its not. Is there a callback or a canonical mechanism for accessing t= his part of the structure given a starting point of the ucom_softc? Alterna= tively, are there any well defined attributes I can use to figure out what = that void* is pointing to, or at least conditionalizing the code so I can d= ereference it correctly? -Brian From owner-freebsd-hackers@freebsd.org Thu Jul 16 21:22:05 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6257A36E3B9 for ; Thu, 16 Jul 2020 21:22:05 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B76dm3Zvpz473y for ; Thu, 16 Jul 2020 21:22:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5E4D52603CC; Thu, 16 Jul 2020 23:21:57 +0200 (CEST) Subject: Re: Question on structure of USB (specifically USB Serial) stack To: "Brian Mcgovern (bmcgover)" , "freebsd-hackers@freebsd.org" References: From: Hans Petter Selasky Message-ID: Date: Thu, 16 Jul 2020 23:21:33 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B76dm3Zvpz473y X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.44 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.03)[-1.029]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.13)[-0.128]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 21:22:05 -0000 On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers wrote: > All, > I'm doing some playing with the ucom code, and I'm down to a link in the data that I'm just not confident I've parsed the code correctly. In sys/dev/usb/serial/usb_serial.c, specifically in ucom_attach_tty, I'm trying to get a reference to the usb_device structure for the device used elsewhere in the USB code. The specific devices I'm working with are USB->RJ 45 cables with a built in FTDI chip, in case this matters > > It appears that the ucom_super_softc and ucom_softc structures are available. From looking around the code, it appears the sc_parent field of ucom_softc is pointing back to the uftdi_softc structure in uftdi.c (for the uftdi case), so the path would be ucom_softc->sc_parent->sc_udev, but my concern is going through the void *, as it appears each of the devices that use ucom as the base have sc_udev in a different part of their structure, meaning I'm likely going to crash the system if I plan on it being an FTDI device, and its not. Is there a callback or a canonical mechanism for accessing this part of the structure given a starting point of the ucom_softc? Alternatively, are there any well defined attributes I can use to figure out what that void* is pointing to, or at least conditionalizing the code so I can dereference it correctly? Hi, Usually using void pointers this way works fine, as long as you are careful. There is also something called __containerof() which can be used to get the pointer to a structure based on the pointer to a structure inside that structure, thinking of the struct ucom_softc, which is type-safe. --HPS From owner-freebsd-hackers@freebsd.org Thu Jul 16 22:32:45 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9BC6336F7F4 for ; Thu, 16 Jul 2020 22:32:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B78CK18HNz4Bkw for ; Thu, 16 Jul 2020 22:32:44 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1594938764; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=mvFfsO6Nf51kzVEFNviDkKWoJqAKjbAYbeyAeRSIKaRfd745GsW/0l7u+KKgl/muBTcNGYSGhuSCL 3rC7u0C+iACrRDwZFUJ3VeEoG+uc6EJseKwgE2++TbCM0N/blQeUJAswQUGraLIytOBOSpQiR+lHPt IgCLHNeVSYYzExHIR0XGH+qf3WOIh6/MVm21xFzJxukOvzGmfks/S4qs5pnFhHVsEBJSm2R7jH1Mm/ wWp/CLGdAKBsIASQTuhBsfGdee2mabG5qsxbjdXsrwQYxSrAhRRPF7V57Oghl171Y7GaPTnou10qUi DkogUTvpyzbj7v00WTdIzQVSdbH9dkQ== 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=CEWIRLp2dVs8yU3O14vhSg8B6yxTEP59QNchPkUCQy4=; b=P+zTsJcwRyx4W1FVmUCCcHvsyHcbwWqrUa804X/g9/L0zopfRfPGzIev8JMSjGq8XwhXoTnUqrH/l brZXJmWVuCc7izJ4iKyrA7hPhbG3LDXAbSf0BBo70O67KljNHgR8XRkZtQoxABr8lSSoG/nQAzpsjt quVJZsPHDlvZpU3pxvyCTaXkAkVw7UZBm5ygWfgUmJaMz9cSqkKxFk6phXOIRFjTTtV0M7JUHXk5Ua iN+2+b+h/jyI4zW5zsg8M6oiy8YZtsUA7ZzlKZCpcUVDBfO+qrnwnq1TvwLSVT/K26Z8YQQYYFtDBb /3yNc7QcnrX99VevuooJx6E0ZMUOoTQ== 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=CEWIRLp2dVs8yU3O14vhSg8B6yxTEP59QNchPkUCQy4=; b=oP8VNChPlHXpz+37WXher1/3cHcvlz98VHoj++HcPgw9sJ9wdZpMTPvziV4x4s6AALbS36goApjew iXI/C0K3K13Q9Von4O3u7ghu9ngumKhdgc0WRlJnxt310+gDP71uRF5w3n0qeqdRfXQqof/2yJBekh ws0dJScCt6rQtvft//ehrpJ2vD9yF+SRGFhWw12KS3jlSL13Jt9/jobV7ZBK1NIWAkfamUYhLH0nEh C92bfYGuXMBtL0bHuiQju3KQiGI3Z6Ml8aloyg1i2Nua/yAjHIZCJYWCDuymDYI8rZjq6BTpiYWBHr v5UVhHfstcX1w45lNtzX+nBSxvG062A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 419635b2-c7b4-11ea-b630-6b8aa7872eb8 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 (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 419635b2-c7b4-11ea-b630-6b8aa7872eb8; Thu, 16 Jul 2020 22:32:42 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 06GMWdbY056815; Thu, 16 Jul 2020 16:32:39 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> Subject: Re: Question on structure of USB (specifically USB Serial) stack From: Ian Lepore To: Hans Petter Selasky , "Brian Mcgovern (bmcgover)" , "freebsd-hackers@freebsd.org" Date: Thu, 16 Jul 2020 16:32:39 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B78CK18HNz4Bkw X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 22:32:45 -0000 On Thu, 2020-07-16 at 23:21 +0200, Hans Petter Selasky wrote: > On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers > wrote: > > All, > > I'm doing some playing with the ucom code, and I'm down to a > > link in the data that I'm just not confident I've parsed the code > > correctly. In sys/dev/usb/serial/usb_serial.c, specifically in > > ucom_attach_tty, I'm trying to get a reference to the usb_device > > structure for the device used elsewhere in the USB code. The > > specific devices I'm working with are USB->RJ 45 cables with a > > built in FTDI chip, in case this matters > > > > It appears that the ucom_super_softc and ucom_softc structures > > are available. From looking around the code, it appears the > > sc_parent field of ucom_softc is pointing back to the uftdi_softc > > structure in uftdi.c (for the uftdi case), so the path would be > > ucom_softc->sc_parent->sc_udev, but my concern is going through the > > void *, as it appears each of the devices that use ucom as the base > > have sc_udev in a different part of their structure, meaning I'm > > likely going to crash the system if I plan on it being an FTDI > > device, and its not. Is there a callback or a canonical mechanism > > for accessing this part of the structure given a starting point of > > the ucom_softc? Alternatively, are there any well defined > > attributes I can use to figure out what that void* is pointing to, > > or at least conditionalizing the code so I can dereference it > > correctly? > > Hi, > > Usually using void pointers this way works fine, as long as you are > careful. There is also something called __containerof() which can be > used to get the pointer to a structure based on the pointer to a > structure inside that structure, thinking of the struct ucom_softc, > which is type-safe. > > You still can't just blindly cast ucom_softc->sc_parent back to a struct uftdi_softc in ucom_tty_attach() because it will crash and burn if any non-ftdi serial device is attached. Using __container_of() doesn't change that in any way -- you must already know for certain that the type pointed to by the pointer is the type you name in the container_of() invocation. This seems to me to be one of those situations where answering the exact question that was asked isn't the right thing to do. Instead it needs to be answered with another question: What it is you're really trying to accomplish, and why do you think doing this crazy-unsafe casting is the only way to get it done? -- Ian From owner-freebsd-hackers@freebsd.org Thu Jul 16 23:18:57 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 971A837044C for ; Thu, 16 Jul 2020 23:18:57 +0000 (UTC) (envelope-from bmcgover@cisco.com) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (Client CN "iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B79Dc28xNz4D9N; Thu, 16 Jul 2020 23:18:56 +0000 (UTC) (envelope-from bmcgover@cisco.com) IronPort-PHdr: =?us-ascii?q?9a23=3ACapZYxMn6/6Ww1VghGwl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw93lHTUIjR8P4CjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8jkalDYuXH06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAABT3xBf/4YNJK1gGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIE5AgEBAQELAYEiAS4jLgeBRy8sh3kDjUa?= =?us-ascii?q?TcoRsglMDVQsBAQEMAQEtAgQBAYRMAoITAiQ3Bg4CAwEBCwEBBQEBAQIBBgR?= =?us-ascii?q?thVsMhW8BAQEBAxIVGQEBOA8CAQgRBAEBAS4yHQgCBAESCBqFA00DLgGgRwK?= =?us-ascii?q?BOYhhdIEBM4MBAQEFhUUYgg4JgTgBgmmGBIQEGoFBP4ERQ4JNPoN1KiCDR4I?= =?us-ascii?q?tmR4mm3UKgl2PCYp4n0GRfJ59AgQCBAUCDgEBBYFpJIFXcBWDJFAXAg2OHgw?= =?us-ascii?q?Xg06KVnQ3AgYIAQEDCXyMdII1AQE?= X-IronPort-AV: E=Sophos;i="5.75,360,1589241600"; d="scan'208,217";a="513039200" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jul 2020 23:18:54 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 06GNIsvd021272 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Jul 2020 23:18:54 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jul 2020 18:18:54 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jul 2020 19:18:52 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 16 Jul 2020 18:18:52 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f/51Cs8Ly8Ke5Wf3IOsVoVv2tsNda0tKmjgLGrD1N/ub8IODexmKsg4yLzDgrQbkBS7B5KNqWlucBjZhmowhLUqCUXARxaWIFHq8ARn4tXLXxZ+868XX5gRse+yew3IoIttKAxAY1laZdKGM4D0xMU9xm2kwzncV4GWKku4enLN7i/ShoD/Vbf143s/SK6J3niSQfSfI8MHqJWVXDlbjIfCAzU9O2lqihUUK5kE6QL92+RI4mNAosLpydWFbw4u56toADhb/L6qUiWXZe3yXsY4LcuNO9qL7Mu4IL7iiCYmZszYqqaukY4SLN4RSfZboNy6KckuJAW1aUzTDGYGImQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qBy+orJ62vUT/4zWGT35LZ1hbJsPuvSXzFR4f5sbfH4=; b=nPStCt2pLFKKULUm4nPCQ/U/7We7M7n/BGaX3qbiYNlOSQ6GEDMvvQHeiD3unXk3mnUvV42AutXXjre7NPOE7fPRSy6ZAKSDn/K521ItIb3BNl+yUitsQnFopkHhSmFg2DNC8PqWa07zvi04L/mCjef0jmTn7kl9chz1CDXPnbaT2Qlwt0wsufaOKdBpd8tfsR6F2LOnwNNcFsR9WeWfg/j+Dj4TeFV6AM0heZ2mdf0EquYiK9V3yIAxcBQNCcLpguTIYq/2gAVoTV0p1YyJ2OBLEimqKMW1qn+N2EDmnxWgEuuwjnsqPw9ypa7y5Xv6IlojY5TTw/eAAF7eVNXZLA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none Received: from BL0PR11MB3442.namprd11.prod.outlook.com (2603:10b6:208:68::19) by BL0PR11MB3124.namprd11.prod.outlook.com (2603:10b6:208:30::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.17; Thu, 16 Jul 2020 23:18:51 +0000 Received: from BL0PR11MB3442.namprd11.prod.outlook.com ([fe80::844f:50d2:7986:e539]) by BL0PR11MB3442.namprd11.prod.outlook.com ([fe80::844f:50d2:7986:e539%7]) with mapi id 15.20.3174.026; Thu, 16 Jul 2020 23:18:51 +0000 From: "Brian Mcgovern (bmcgover)" To: Ian Lepore , Hans Petter Selasky , "freebsd-hackers@freebsd.org" Subject: Re: Question on structure of USB (specifically USB Serial) stack Thread-Topic: Question on structure of USB (specifically USB Serial) stack Thread-Index: AQHWW66ajFBPEQF6REi43/I0wUQCzKkKtsuAgAAT3YCAAAGJvw== Date: Thu, 16 Jul 2020 23:18:51 +0000 Message-ID: References: , <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> In-Reply-To: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:18c:d07f:d140:547b:bff9:d6a8:7b19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4006a12b-e38a-496d-f8da-08d829de99e5 x-ms-traffictypediagnostic: BL0PR11MB3124: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CBdnCklatAH1e0o8fljl4jOF6eHpSfBbQYBaELNqIl8u9RxZBIVnFl60wqGAUF1Mqk/bAh9m0U/OqoBEk05HcEKk7CAXbQJsOVFTntRzogMeYvhXZm+sF2AqcCCSuB8dIhUWaguChMeK3hQWKlMuFYEVYXFOQH6bP7IPSGlt/tzp/LXZFsZV7I8CEyDF3PIREeepocU7jvHJxinGLUbkjL9JVOgT9N/RDwIPlNqJARYs7Z8XRZZoGn52QWmPgRyDirCF/6c1oJgIv4ODIMYGR30zFANB1cx5rD9QtlHJl6UO57YF8vEYzzh6NAgzvHQ4PUkvKl4qFMyXB/EzuCXD3Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3442.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(366004)(396003)(346002)(9686003)(86362001)(55016002)(83380400001)(8676002)(5660300002)(71200400001)(52536014)(8936002)(7696005)(6506007)(478600001)(53546011)(186003)(19627405001)(66446008)(66476007)(2906002)(64756008)(316002)(66556008)(110136005)(33656002)(76116006)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 29khqv+tqCWSMtZb+36o/iNUi0Ifo/Qf9J/rpOhniFcOKWwuQRAHQxLIYNuS8V2I2NPL5izzNxiiOxJ101W6yIXEPZUq4Np1Pp/HSlzmuhhhjIHFzLESyszQFoJwspKiDv7BYi9YsC5vX9auJwEjuG0P8oLi3rx4oYifSVG1hCMt22yH0c9DSBV8uLb2JgE+CZZdlcGzP/5D6+shr3h9m6qLe5ozibBTswlBWkfwYbVvdpRHG1RuLxWMPTp0orB5DtjMWyDQa67GPgkdyK9oXDtlBUiHJJ/AmppbNKtUU1zji+7kV9bv+hdCg7pVpgKfWrF6tBtRhMavDeYfyxdIpizGFnIya8dDapgMjwfZtwHvkGEuqDUGdGyYDp1e7C+kaNo0mr1+MoWSeSeUvkvBVjllOHQ+A6ViyS+I6yRG8RWjQxJl6ev3j3+1hkmRURwqfAhX/o75EejYrYK9Gf18kOLV8AFPZEJtAD5MbkNabq1X9HcIVKFzyCeUXZYOQBjQN/gvGaN7lSSj99UPj76wHixbFrLeA8kmJxdSRxdtOTCZzPT/B2n0gD2hDFSZfBBl x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3442.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4006a12b-e38a-496d-f8da-08d829de99e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2020 23:18:51.3740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: deN32NNT3rMdG1Ke2wjjuTl7CNzocwBMpg4kBdQ/ceXXxjJ3d11KUl6I0vMiZvvdGPZuW+zHfWpeXUJexVvWHg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3124 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com X-Rspamd-Queue-Id: 4B79Dc28xNz4D9N X-Spamd-Bar: ----------- X-Spamd-Result: default: False [-11.90 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.021]; R_DKIM_ALLOW(-0.20)[cisco.com:s=iport,cisco.onmicrosoft.com:s=selector2-cisco-onmicrosoft-com]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:173.37.142.64/26]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_DKIM_ARC_DNSWL_HI(-1.00)[]; NEURAL_HAM_LONG(-1.02)[-1.022]; DWL_DNSWL_MED(-2.00)[cisco.com:dkim]; WHITELIST_SPF_DKIM(-3.00)[cisco.com:d:+,cisco.com:s:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cisco.com:+,cisco.onmicrosoft.com:+]; DMARC_POLICY_ALLOW(-0.50)[cisco.com,quarantine]; NEURAL_HAM_SHORT(-1.36)[-1.359]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:109, ipnet:173.37.128.0/19, country:US]; RCVD_COUNT_SEVEN(0.00)[8]; RWL_MAILSPIKE_VERYGOOD(0.00)[173.37.142.88:from]; RCVD_IN_DNSWL_HI(-0.50)[173.37.142.88:from] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 23:18:57 -0000 Ian Lepore said: This seems to me to be one of those situations where answering the exact question that was asked isn't the right thing to do. Instead it needs to be answered with another question: What it is you're really trying to accomplish, and why do you think doing this crazy-unsafe casting is the only way to get it done? I get its crazy unsafe for the non-specific case. That is why I'm asking th= e question - to see if there is a good way to get the info. What I'm hoping to do is pin some USB devices with FTDI interfaces to more = consistent name, similar to /dev/usb, based on the tree of struct usb_devic= e entries and their respective addresses. What I see with the cuaUXX format= ting is that if one gets rebooted or someone hits the power cord, it'll bou= nce fast enough that it'll come back with a different name. As a result, ev= en though we can get a consistent layout on power up, if you come back a we= ek or two later, everything is out of order. I was hoping that if I could a= t least get an alias that mapped to the port the device was in, that would = be sufficient to find the "right one", regardless of what the cuaUX names w= ere doing. The reason for picking this particular section of the code is that it appea= rs I can get most of the work done locally and have similar behavior with a= ll of the devices that share ucom. However, if what I'm seeing as a hurdle = is really a wall, I'm open to better ideas. -B ________________________________ From: Ian Lepore Sent: Thursday, July 16, 2020 6:32 PM To: Hans Petter Selasky ; Brian Mcgovern (bmcgover) ; freebsd-hackers@freebsd.org Subject: Re: Question on structure of USB (specifically USB Serial) stack On Thu, 2020-07-16 at 23:21 +0200, Hans Petter Selasky wrote: > On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers > wrote: > > All, > > I'm doing some playing with the ucom code, and I'm down to a > > link in the data that I'm just not confident I've parsed the code > > correctly. In sys/dev/usb/serial/usb_serial.c, specifically in > > ucom_attach_tty, I'm trying to get a reference to the usb_device > > structure for the device used elsewhere in the USB code. The > > specific devices I'm working with are USB->RJ 45 cables with a > > built in FTDI chip, in case this matters > > > > It appears that the ucom_super_softc and ucom_softc structures > > are available. From looking around the code, it appears the > > sc_parent field of ucom_softc is pointing back to the uftdi_softc > > structure in uftdi.c (for the uftdi case), so the path would be > > ucom_softc->sc_parent->sc_udev, but my concern is going through the > > void *, as it appears each of the devices that use ucom as the base > > have sc_udev in a different part of their structure, meaning I'm > > likely going to crash the system if I plan on it being an FTDI > > device, and its not. Is there a callback or a canonical mechanism > > for accessing this part of the structure given a starting point of > > the ucom_softc? Alternatively, are there any well defined > > attributes I can use to figure out what that void* is pointing to, > > or at least conditionalizing the code so I can dereference it > > correctly? > > Hi, > > Usually using void pointers this way works fine, as long as you are > careful. There is also something called __containerof() which can be > used to get the pointer to a structure based on the pointer to a > structure inside that structure, thinking of the struct ucom_softc, > which is type-safe. > > You still can't just blindly cast ucom_softc->sc_parent back to a struct uftdi_softc in ucom_tty_attach() because it will crash and burn if any non-ftdi serial device is attached. Using __container_of() doesn't change that in any way -- you must already know for certain that the type pointed to by the pointer is the type you name in the container_of() invocation. This seems to me to be one of those situations where answering the exact question that was asked isn't the right thing to do. Instead it needs to be answered with another question: What it is you're really trying to accomplish, and why do you think doing this crazy-unsafe casting is the only way to get it done? -- Ian From owner-freebsd-hackers@freebsd.org Fri Jul 17 00:28:53 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5156A372AFB for ; Fri, 17 Jul 2020 00:28:53 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7BnJ17jCz4JvY; Fri, 17 Jul 2020 00:28:51 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 06H0IYiw024359 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Jul 2020 17:18:34 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 06H0IY5h024358; Thu, 16 Jul 2020 17:18:34 -0700 (PDT) (envelope-from jmg) Date: Thu, 16 Jul 2020 17:18:34 -0700 From: John-Mark Gurney To: "Brian Mcgovern (bmcgover)" Cc: Ian Lepore , Hans Petter Selasky , "freebsd-hackers@freebsd.org" Subject: Re: Question on structure of USB (specifically USB Serial) stack Message-ID: <20200717001834.GU4213@funkthat.com> Mail-Followup-To: "Brian Mcgovern (bmcgover)" , Ian Lepore , Hans Petter Selasky , "freebsd-hackers@freebsd.org" References: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 16 Jul 2020 17:18:34 -0700 (PDT) X-Rspamd-Queue-Id: 4B7BnJ17jCz4JvY X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [1.87 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.67)[0.673]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.06)[-0.059]; NEURAL_SPAM_LONG(0.05)[0.055]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 00:28:53 -0000 FreeBSD Hackers wrote this message on Thu, Jul 16, 2020 at 23:18 +0000: > Ian Lepore said: > > This seems to me to be one of those situations where answering the > exact question that was asked isn't the right thing to do. Instead it > needs to be answered with another question: What it is you're really > trying to accomplish, and why do you think doing this crazy-unsafe > casting is the only way to get it done? > > I get its crazy unsafe for the non-specific case. That is why I'm asking the question - to see if there is a good way to get the info. > > What I'm hoping to do is pin some USB devices with FTDI interfaces to more consistent name, similar to /dev/usb, based on the tree of struct usb_device entries and their respective addresses. What I see with the cuaUXX formatting is that if one gets rebooted or someone hits the power cord, it'll bounce fast enough that it'll come back with a different name. As a result, even though we can get a consistent layout on power up, if you come back a week or two later, everything is out of order. I was hoping that if I could at least get an alias that mapped to the port the device was in, that would be sufficient to find the "right one", regardless of what the cuaUX names were doing. > > The reason for picking this particular section of the code is that it appears I can get most of the work done locally and have similar behavior with all of the devices that share ucom. However, if what I'm seeing as a hurdle is really a wall, I'm open to better ideas. Look here: https://reviews.freebsd.org/D21886 I've added a script, linked here: https://www.funkthat.com/~jmg/FreeBSD/usbserialsn There are two modes, if the device has a serial number, that will be used. If the device has an empty serial number, it's usb bus and port number path will be used. > Sent: Thursday, July 16, 2020 6:32 PM > To: Hans Petter Selasky ; Brian Mcgovern (bmcgover) ; freebsd-hackers@freebsd.org > Subject: Re: Question on structure of USB (specifically USB Serial) stack > > On Thu, 2020-07-16 at 23:21 +0200, Hans Petter Selasky wrote: > > On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers > > wrote: > > > All, > > > I'm doing some playing with the ucom code, and I'm down to a > > > link in the data that I'm just not confident I've parsed the code > > > correctly. In sys/dev/usb/serial/usb_serial.c, specifically in > > > ucom_attach_tty, I'm trying to get a reference to the usb_device > > > structure for the device used elsewhere in the USB code. The > > > specific devices I'm working with are USB->RJ 45 cables with a > > > built in FTDI chip, in case this matters > > > > > > It appears that the ucom_super_softc and ucom_softc structures > > > are available. From looking around the code, it appears the > > > sc_parent field of ucom_softc is pointing back to the uftdi_softc > > > structure in uftdi.c (for the uftdi case), so the path would be > > > ucom_softc->sc_parent->sc_udev, but my concern is going through the > > > void *, as it appears each of the devices that use ucom as the base > > > have sc_udev in a different part of their structure, meaning I'm > > > likely going to crash the system if I plan on it being an FTDI > > > device, and its not. Is there a callback or a canonical mechanism > > > for accessing this part of the structure given a starting point of > > > the ucom_softc? Alternatively, are there any well defined > > > attributes I can use to figure out what that void* is pointing to, > > > or at least conditionalizing the code so I can dereference it > > > correctly? > > > > Hi, > > > > Usually using void pointers this way works fine, as long as you are > > careful. There is also something called __containerof() which can be > > used to get the pointer to a structure based on the pointer to a > > structure inside that structure, thinking of the struct ucom_softc, > > which is type-safe. > > > > > > You still can't just blindly cast ucom_softc->sc_parent back to a > struct uftdi_softc in ucom_tty_attach() because it will crash and burn > if any non-ftdi serial device is attached. Using __container_of() > doesn't change that in any way -- you must already know for certain > that the type pointed to by the pointer is the type you name in the > container_of() invocation. > > This seems to me to be one of those situations where answering the > exact question that was asked isn't the right thing to do. Instead it > needs to be answered with another question: What it is you're really > trying to accomplish, and why do you think doing this crazy-unsafe > casting is the only way to get it done? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@freebsd.org Fri Jul 17 07:24:07 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5CBA835AEE9 for ; Fri, 17 Jul 2020 07:24:07 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [93.151.207.39]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7N0Q3W1Lz4fk2 for ; Fri, 17 Jul 2020 07:24:06 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 40074 invoked from network); 17 Jul 2020 07:23:58 -0000 Received: from carbon.alexdupre.com (HELO ?192.168.178.18?) (sysadmin@alexdupre.com@192.168.178.18) by lab.alexdupre.com with ESMTPSA; 17 Jul 2020 07:23:58 -0000 Subject: Re: Anybody working on RTL8125 (2.5 Gbit/s Ethernet) support? To: =?UTF-8?Q?Stefan_E=c3=9fer?= Cc: FreeBSD Hackers References: <61362d77-b283-b00e-c7cd-9f93ea937728@freebsd.org> <9a3c9521-c229-2542-70ec-fc2a2bf6f8f3@bluerosetech.com> <6c8fdae0-4fd5-142c-87f8-1f4026bbd8a1@freebsd.org> <6382c967-b7fa-0581-f16e-504a909809f2@FreeBSD.org> <10310e5c-538d-12f9-e504-bca8f75f1aa3@freebsd.org> <956a1f83-7210-df80-8ba1-a239bf06471b@freebsd.org> <4fe0da81-941a-2a89-241b-290ee4ba8457@FreeBSD.org> <262b5b96-5193-abde-91de-f4a6cafec210@freebsd.org> <9eac4973-f026-874c-84da-e6892e3935d1@freebsd.org> From: Alex Dupre Message-ID: <57bfe53c-f210-04df-8762-5bb60220df5c@FreeBSD.org> Date: Fri, 17 Jul 2020 09:23:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.2 MIME-Version: 1.0 In-Reply-To: <9eac4973-f026-874c-84da-e6892e3935d1@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4B7N0Q3W1Lz4fk2 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; ASN(0.00)[asn:30722, ipnet:93.151.128.0/17, country:IT] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 07:24:07 -0000 Stefan E=DFer wrote: > Since I'm away from my test system for most of the next week, I'll > not be able to test any of my code before end of July, but I intend > to continue this project with the goal of a stable driver for all > Realtek chips that uses the microcode and other information from > the Realtek driver and adds RTL8125 support. My best wishes. If you'll be able to make the re driver stable for all FreeBSD machines I'm sure you'll make many users very happy. --=20 Alex Dupre From owner-freebsd-hackers@freebsd.org Fri Jul 17 13:08:17 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4311A364D7D for ; Fri, 17 Jul 2020 13:08:17 +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 4B7WdX0g0Qz436g for ; Fri, 17 Jul 2020 13:08:15 +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 06HD8Bgk063963 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 17 Jul 2020 15:08:12 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1594991292; bh=8St5dUaUG22kmvkcX229GeNl1D1ycWq0RRUarEu1buI=; h=Date:From:To:Subject; b=uuoDYZ3kCF/G2Pz48MnZLQUATWBBEIhkhscjVkoR6xqJnyXcyF32T6lDmIZf+nNzO 6S688C7C47vzP1I88EJE0OiM89XVy64iPDBElCzTp1L1vd2cacgpa1ea5VpNMaDg/1 tKhWEF70sDwTd8UqcK25mPQsZ4Q0HZXkcji6Bac8= Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id 06HD8BNg063956 for ; Fri, 17 Jul 2020 15:08:11 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Fri, 17 Jul 2020 15:08:11 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: gettext_xs.c: loadable library and perl binaries are mismatched (got handshake key 0xbf00080, needed 0xc580080) 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: 4B7WdX0g0Qz436g X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=fail (headers rsa verify failed) header.d=puchar.net header.s=default header.b=uuoDYZ3k; dmarc=none; 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 [-0.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.934]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.89)[-0.888]; DMARC_NA(0.00)[puchar.net]; R_DKIM_REJECT(1.00)[puchar.net:s=default]; DKIM_TRACE(0.00)[puchar.net:-]; RCVD_IN_DNSWL_NONE(0.00)[194.1.144.90:from]; NEURAL_SPAM_SHORT(0.16)[0.164]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 13:08:17 -0000 can anyone point me what is exactly mismatched - what library. i tried reinstalling perl from ports, as well as gettext-runtime and gettext-tools. i found this message in libperl.so From owner-freebsd-hackers@freebsd.org Fri Jul 17 14:06:11 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8CB20365DBE for ; Fri, 17 Jul 2020 14:06:11 +0000 (UTC) (envelope-from bmcgover@cisco.com) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (Client CN "iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7XwK5kTGz46RZ; Fri, 17 Jul 2020 14:06:09 +0000 (UTC) (envelope-from bmcgover@cisco.com) IronPort-PHdr: =?us-ascii?q?9a23=3AeNOpNBErrVgJAZvUZvtGyZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gebU5jd6O5EgvaQuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFPPpH6u7TcOXB?= =?us-ascii?q?74MFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAACarxFf/4MNJK1dAxYEAQEBAQE?= =?us-ascii?q?BAQEBAQMBAQEBEgEBAQECAgEBAQFAgUqBIwEuIy4Hb1gvLId5A41Gk3KEbIJ?= =?us-ascii?q?TA1ULAQEBDAEBIwoCBAEBhEwCghkCJDgTAgMBAQsBAQUBAQECAQYEbYVbDIV?= =?us-ascii?q?vAQEBAwESFRkBATcBBAsCAQgRBAEBAS4yHQgCBA4FCBqDBYF+TQMOIAEOn0Q?= =?us-ascii?q?CgTmIYXSBATODAQEBBYEyAYNQGIIOAwaBOAGCaYNIhkAagUE/gRFDgk0+g3U?= =?us-ascii?q?qIB8MGoMCgi2Paok4Jpt1CoJdiFaGNIp4n0OcJJRWAgQCBAUCDgEBBYFqI4F?= =?us-ascii?q?XcBWDJFAXAg2OHgwXg06FFIVCdDcCBggBAQMJfIxBgjUBAQ?= X-IronPort-AV: E=Sophos;i="5.75,362,1589241600"; d="scan'208,217";a="789667469" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jul 2020 14:06:07 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 06HE67KI016245 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jul 2020 14:06:07 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jul 2020 09:06:07 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jul 2020 09:06:06 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 17 Jul 2020 09:06:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=heD93iyrt+6A7yx3gPw2alvQ50bJbRyE8j7oP4VXHvdKp6HhfaYWT2FPj6UcDFLf3u12ioIpwxUnbItbk/XfRWvBaOzCdL9VRDZ9D2/WO6aVE0BMRwMNu0JwGaYHfiHDKswJSLy4uK5OvZgBNAuGA0mpFlyGXvWB9dJDIP2qz1Grq8GuMvuz+RLIBGCjvMkTq/2TuRSlLeiHn0qimWfFv3GH9RFR6Xx5l758MjRC5VR8cZw3CPrC2ZcmCS6MLSDnMM5HKgkbXer36bwo7jgqXhdDoXwZebS/WESY+TK7/lMS66FA84/yKl3bdvTwXrbQ2qNJb01ilKM8IXcDX8ocFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nB2AMed5HKyIxwdFsD8BcHW1qhvTw7Jlj7Ho8vl9JL4=; b=N+hrAvnSr66bLwqXnmlll+yQrzFQhL+MT+BhyiPGpHaBSxXnXwyCtcEmN0unjpFi3U9Mtgk9aJBZvDbR0Z5ZKUpHUQ7z+La2de0gkA7nD0dLUfr/3++LYynIJlWS+2Pj5LnrEAlbqf/KkBW+nh0vOVPyJGCc01f32hsBPdm0l5KTsrzOF4crA63b6EHqdy1B8bNAFIztkbuAhp8xYe/WWKnn7pzQj6MpH5vioOiE5uSAoVgHkPY+h8DCoACqIea4MK2LLEnq6Gaf2EIhFBkD/YVssPEcQyXMjRSbHAeJnDmFxdzBDnSkCcVmp+qS30QIMxxqvDIJJ/A1yLCgr+0l+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none Received: from BL0PR11MB3442.namprd11.prod.outlook.com (2603:10b6:208:68::19) by MN2PR11MB4480.namprd11.prod.outlook.com (2603:10b6:208:191::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.23; Fri, 17 Jul 2020 14:06:05 +0000 Received: from BL0PR11MB3442.namprd11.prod.outlook.com ([fe80::844f:50d2:7986:e539]) by BL0PR11MB3442.namprd11.prod.outlook.com ([fe80::844f:50d2:7986:e539%7]) with mapi id 15.20.3174.026; Fri, 17 Jul 2020 14:06:05 +0000 From: "Brian Mcgovern (bmcgover)" To: John-Mark Gurney CC: Ian Lepore , Hans Petter Selasky , "freebsd-hackers@freebsd.org" Subject: Re: Question on structure of USB (specifically USB Serial) stack Thread-Topic: Question on structure of USB (specifically USB Serial) stack Thread-Index: AQHWW66ajFBPEQF6REi43/I0wUQCzKkKtsuAgAAT3YCAAAGJv4AAHA8AgADjcso= Date: Fri, 17 Jul 2020 14:06:05 +0000 Message-ID: References: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> , <20200717001834.GU4213@funkthat.com> In-Reply-To: <20200717001834.GU4213@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:18c:d07f:d140:547b:bff9:d6a8:7b19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2ab72d3a-c6c2-4082-89ef-08d82a5a8bc3 x-ms-traffictypediagnostic: MN2PR11MB4480: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mFs1MQywqt+rHwbjGpmdinDkkQyleIoUd6mUC94Oebd5Jt+HZXdfk5pn5QJNFanHk4Rjre99nIctAWBeN7LrzLheWxb7eLAlYMgKMdrh2ok7Lgn7QEKux1onxXOIHq4iek7J/qGSuk5zezPPvfHSEi5POIX00Ou1a/zU+VCcJhoTUMh6HpAU4H5jWvtwrYgOKEW5cunXSwdvIHfeHmV3DESNRM38NKtOE5OH9dw4POvwtH3lSxiVlNyxCQxJPzNkf7Innhufr0Fz0qV1zfNBYiiG8bLmyfhosKdOYuNu+4rVUTFQsDaf6x4SIRojMWqt/0n4gFATBJvoZ6znwEB8Q9Os9WWS9YVy70HDhakqqAjCVfU4E5E+z/GFhhERh60LeIqLs8EHcy6iTzFOsVZ0Ag== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3442.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(376002)(346002)(39860400002)(396003)(83380400001)(2906002)(86362001)(7696005)(6506007)(53546011)(478600001)(966005)(186003)(9686003)(55016002)(4326008)(19627405001)(8676002)(52536014)(8936002)(5660300002)(66946007)(166002)(66446008)(33656002)(76116006)(316002)(71200400001)(66556008)(54906003)(64756008)(6916009)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: XiHOEpVCgl6Lw+sukdLg21XRTJ9rSCg/j7Fg5IkO/AQ8v2uallxCsp7HnRGQH5KYe+gZ6LZfDM7+DderAE4+/gn+ZZyHdX/JZIw0VWyd80JGPpTiosgjkA09TUVNFxUNy9LaIL1ioUbuuhg6roBTGu4555buit2KAKQ8Ptl/1WC89Otm1hXB/aeAztitV/qZIyPV93YuqF/IhSm4YlvqIp866PQzyywOPly4Tpi+prluFI4z4Xl2jW636bBYbV8XkJHca3kcOZOxqWdbS08frI6oQqlhNAfUE2iX8eb2dTcbluCq/XfcGGf9RwrAf43yMKJMim39UqnzdN/GH2ni/khyhs15npBESCmeNqRah/LC8K+GDWwtNv846avqSlcEPtCNLYChpo+5hmGMTPpTvAZTKXfEsv6W9h/a3P3eq8rSEPxXEqEhRVvPuRtn+OxfX73zgS44wGD/DO3ZHJtHYpqIhRqh5ssVc+8HQFaA9RVvg9Q+eulUO8pP1Ew5VshV+gPGcyV5kodePmKdguLHutq3VxhEjCHuqZ3mjijTPmVAOFCryljTU3EV33gEefJv x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3442.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ab72d3a-c6c2-4082-89ef-08d82a5a8bc3 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2020 14:06:05.2412 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U/aiG/CB881ERNIpb206fDExlfHweK5MXIX4rE+uKr2NzpqMRyoc1/R9xeEcOZ/encnJM5FpuBtbTEq59w2sCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4480 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-1.cisco.com X-Rspamd-Queue-Id: 4B7XwK5kTGz46RZ X-Spamd-Bar: ------------ X-Spamd-Result: default: False [-12.23 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.007]; R_DKIM_ALLOW(-0.20)[cisco.com:s=iport,cisco.onmicrosoft.com:s=selector2-cisco-onmicrosoft-com]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:173.37.86.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_DKIM_ARC_DNSWL_HI(-1.00)[]; NEURAL_HAM_LONG(-1.01)[-1.009]; RWL_MAILSPIKE_GOOD(0.00)[173.37.86.78:from]; WHITELIST_SPF_DKIM(-3.00)[cisco.com:d:+,cisco.com:s:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cisco.com:+,cisco.onmicrosoft.com:+]; DMARC_POLICY_ALLOW(-0.50)[cisco.com,quarantine]; DWL_DNSWL_MED(-2.00)[cisco.com:dkim]; NEURAL_HAM_SHORT(-1.71)[-1.714]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:109, ipnet:173.37.64.0/18, country:US]; RCVD_COUNT_SEVEN(0.00)[8]; RCVD_IN_DNSWL_HI(-0.50)[173.37.86.78:from] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 14:06:11 -0000 John-Mark Gurney said Look here: https://reviews.freebsd.org/D21886 I've added a script, linked here: https://www.funkthat.com/~jmg/FreeBSD/usbserialsn There are two modes, if the device has a serial number, that will be used. If the device has an empty serial number, it's usb bus and port number path will be used. Thank you. I'll take a look at the patch and script today. From a quick onc= e over, it looks like it'll meet my needs - pretty much keeping the device = names unique and identifiable during reboots and detach/reattach events. If= I see any issues, I'll let you know. -Brian ________________________________ From: John-Mark Gurney Sent: Thursday, July 16, 2020 8:18 PM To: Brian Mcgovern (bmcgover) Cc: Ian Lepore ; Hans Petter Selasky ; fr= eebsd-hackers@freebsd.org Subject: Re: Question on structure of USB (specifically USB Serial) stack FreeBSD Hackers wrote this message on Thu, Jul 16, 2020 at 23:18 +0000: > Ian Lepore said: > > This seems to me to be one of those situations where answering the > exact question that was asked isn't the right thing to do. Instead it > needs to be answered with another question: What it is you're really > trying to accomplish, and why do you think doing this crazy-unsafe > casting is the only way to get it done? > > I get its crazy unsafe for the non-specific case. That is why I'm asking = the question - to see if there is a good way to get the info. > > What I'm hoping to do is pin some USB devices with FTDI interfaces to mor= e consistent name, similar to /dev/usb, based on the tree of struct usb_dev= ice entries and their respective addresses. What I see with the cuaUXX form= atting is that if one gets rebooted or someone hits the power cord, it'll b= ounce fast enough that it'll come back with a different name. As a result, = even though we can get a consistent layout on power up, if you come back a = week or two later, everything is out of order. I was hoping that if I could= at least get an alias that mapped to the port the device was in, that woul= d be sufficient to find the "right one", regardless of what the cuaUX names= were doing. > > The reason for picking this particular section of the code is that it app= ears I can get most of the work done locally and have similar behavior with= all of the devices that share ucom. However, if what I'm seeing as a hurdl= e is really a wall, I'm open to better ideas. Look here: https://reviews.freebsd.org/D21886 I've added a script, linked here: https://www.funkthat.com/~jmg/FreeBSD/usbserialsn There are two modes, if the device has a serial number, that will be used. If the device has an empty serial number, it's usb bus and port number path will be used. > Sent: Thursday, July 16, 2020 6:32 PM > To: Hans Petter Selasky ; Brian Mcgovern (bmcgover) ; freebsd-hackers@freebsd.org > Subject: Re: Question on structure of USB (specifically USB Serial) stack > > On Thu, 2020-07-16 at 23:21 +0200, Hans Petter Selasky wrote: > > On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers > > wrote: > > > All, > > > I'm doing some playing with the ucom code, and I'm down to a > > > link in the data that I'm just not confident I've parsed the code > > > correctly. In sys/dev/usb/serial/usb_serial.c, specifically in > > > ucom_attach_tty, I'm trying to get a reference to the usb_device > > > structure for the device used elsewhere in the USB code. The > > > specific devices I'm working with are USB->RJ 45 cables with a > > > built in FTDI chip, in case this matters > > > > > > It appears that the ucom_super_softc and ucom_softc structures > > > are available. From looking around the code, it appears the > > > sc_parent field of ucom_softc is pointing back to the uftdi_softc > > > structure in uftdi.c (for the uftdi case), so the path would be > > > ucom_softc->sc_parent->sc_udev, but my concern is going through the > > > void *, as it appears each of the devices that use ucom as the base > > > have sc_udev in a different part of their structure, meaning I'm > > > likely going to crash the system if I plan on it being an FTDI > > > device, and its not. Is there a callback or a canonical mechanism > > > for accessing this part of the structure given a starting point of > > > the ucom_softc? Alternatively, are there any well defined > > > attributes I can use to figure out what that void* is pointing to, > > > or at least conditionalizing the code so I can dereference it > > > correctly? > > > > Hi, > > > > Usually using void pointers this way works fine, as long as you are > > careful. There is also something called __containerof() which can be > > used to get the pointer to a structure based on the pointer to a > > structure inside that structure, thinking of the struct ucom_softc, > > which is type-safe. > > > > > > You still can't just blindly cast ucom_softc->sc_parent back to a > struct uftdi_softc in ucom_tty_attach() because it will crash and burn > if any non-ftdi serial device is attached. Using __container_of() > doesn't change that in any way -- you must already know for certain > that the type pointed to by the pointer is the type you name in the > container_of() invocation. > > This seems to me to be one of those situations where answering the > exact question that was asked isn't the right thing to do. Instead it > needs to be answered with another question: What it is you're really > trying to accomplish, and why do you think doing this crazy-unsafe > casting is the only way to get it done? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@freebsd.org Fri Jul 17 18:40:49 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6284F36B6BF for ; Fri, 17 Jul 2020 18:40:49 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7g1D2vNQz4N72; Fri, 17 Jul 2020 18:40:47 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 06HIUZ52069789 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Jul 2020 11:30:35 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 06HIUYUc069788; Fri, 17 Jul 2020 11:30:34 -0700 (PDT) (envelope-from jmg) Date: Fri, 17 Jul 2020 11:30:34 -0700 From: John-Mark Gurney To: "Brian Mcgovern (bmcgover)" Cc: Ian Lepore , Hans Petter Selasky , "freebsd-hackers@freebsd.org" Subject: Re: Question on structure of USB (specifically USB Serial) stack Message-ID: <20200717183034.GW4213@funkthat.com> Mail-Followup-To: "Brian Mcgovern (bmcgover)" , Ian Lepore , Hans Petter Selasky , "freebsd-hackers@freebsd.org" References: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> <20200717001834.GU4213@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Fri, 17 Jul 2020 11:30:35 -0700 (PDT) X-Rspamd-Queue-Id: 4B7g1D2vNQz4N72 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [2.08 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.64)[0.638]; NEURAL_SPAM_SHORT(0.19)[0.194]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.05)[0.046]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 18:40:49 -0000 Brian Mcgovern (bmcgover) wrote this message on Fri, Jul 17, 2020 at 14:06 +0000: > John-Mark Gurney said > > Look here: > https://reviews.freebsd.org/D21886 > > I've added a script, linked here: > https://www.funkthat.com/~jmg/FreeBSD/usbserialsn > > There are two modes, if the device has a serial number, that will be > used. If the device has an empty serial number, it's usb bus and port > number path will be used. > > Thank you. I'll take a look at the patch and script today. From a quick once over, it looks like it'll meet my needs - pretty much keeping the device names unique and identifiable during reboots and detach/reattach events. If I see any issues, I'll let you know. Just for clarification, the script does not require the patch to be applied. That patch in the review was a separate effort. The script should likely work on past FreeBSD releases as well, but I haven't tested it on them. > ________________________________ > From: John-Mark Gurney > Sent: Thursday, July 16, 2020 8:18 PM > To: Brian Mcgovern (bmcgover) > Cc: Ian Lepore ; Hans Petter Selasky ; freebsd-hackers@freebsd.org > Subject: Re: Question on structure of USB (specifically USB Serial) stack > > FreeBSD Hackers wrote this message on Thu, Jul 16, 2020 at 23:18 +0000: > > Ian Lepore said: > > > > This seems to me to be one of those situations where answering the > > exact question that was asked isn't the right thing to do. Instead it > > needs to be answered with another question: What it is you're really > > trying to accomplish, and why do you think doing this crazy-unsafe > > casting is the only way to get it done? > > > > I get its crazy unsafe for the non-specific case. That is why I'm asking the question - to see if there is a good way to get the info. > > > > What I'm hoping to do is pin some USB devices with FTDI interfaces to more consistent name, similar to /dev/usb, based on the tree of struct usb_device entries and their respective addresses. What I see with the cuaUXX formatting is that if one gets rebooted or someone hits the power cord, it'll bounce fast enough that it'll come back with a different name. As a result, even though we can get a consistent layout on power up, if you come back a week or two later, everything is out of order. I was hoping that if I could at least get an alias that mapped to the port the device was in, that would be sufficient to find the "right one", regardless of what the cuaUX names were doing. > > > > The reason for picking this particular section of the code is that it appears I can get most of the work done locally and have similar behavior with all of the devices that share ucom. However, if what I'm seeing as a hurdle is really a wall, I'm open to better ideas. > > Look here: > https://reviews.freebsd.org/D21886 > > I've added a script, linked here: > https://www.funkthat.com/~jmg/FreeBSD/usbserialsn > > There are two modes, if the device has a serial number, that will be > used. If the device has an empty serial number, it's usb bus and port > number path will be used. > > > Sent: Thursday, July 16, 2020 6:32 PM > > To: Hans Petter Selasky ; Brian Mcgovern (bmcgover) ; freebsd-hackers@freebsd.org > > Subject: Re: Question on structure of USB (specifically USB Serial) stack > > > > On Thu, 2020-07-16 at 23:21 +0200, Hans Petter Selasky wrote: > > > On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers > > > wrote: > > > > All, > > > > I'm doing some playing with the ucom code, and I'm down to a > > > > link in the data that I'm just not confident I've parsed the code > > > > correctly. In sys/dev/usb/serial/usb_serial.c, specifically in > > > > ucom_attach_tty, I'm trying to get a reference to the usb_device > > > > structure for the device used elsewhere in the USB code. The > > > > specific devices I'm working with are USB->RJ 45 cables with a > > > > built in FTDI chip, in case this matters > > > > > > > > It appears that the ucom_super_softc and ucom_softc structures > > > > are available. From looking around the code, it appears the > > > > sc_parent field of ucom_softc is pointing back to the uftdi_softc > > > > structure in uftdi.c (for the uftdi case), so the path would be > > > > ucom_softc->sc_parent->sc_udev, but my concern is going through the > > > > void *, as it appears each of the devices that use ucom as the base > > > > have sc_udev in a different part of their structure, meaning I'm > > > > likely going to crash the system if I plan on it being an FTDI > > > > device, and its not. Is there a callback or a canonical mechanism > > > > for accessing this part of the structure given a starting point of > > > > the ucom_softc? Alternatively, are there any well defined > > > > attributes I can use to figure out what that void* is pointing to, > > > > or at least conditionalizing the code so I can dereference it > > > > correctly? > > > > > > Hi, > > > > > > Usually using void pointers this way works fine, as long as you are > > > careful. There is also something called __containerof() which can be > > > used to get the pointer to a structure based on the pointer to a > > > structure inside that structure, thinking of the struct ucom_softc, > > > which is type-safe. > > > > > > > > > > You still can't just blindly cast ucom_softc->sc_parent back to a > > struct uftdi_softc in ucom_tty_attach() because it will crash and burn > > if any non-ftdi serial device is attached. Using __container_of() > > doesn't change that in any way -- you must already know for certain > > that the type pointed to by the pointer is the type you name in the > > container_of() invocation. > > > > This seems to me to be one of those situations where answering the > > exact question that was asked isn't the right thing to do. Instead it > > needs to be answered with another question: What it is you're really > > trying to accomplish, and why do you think doing this crazy-unsafe > > casting is the only way to get it done? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@freebsd.org Fri Jul 17 18:45:58 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DEBBF36BBF2 for ; Fri, 17 Jul 2020 18:45:58 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7g7B5XVyz4NYK; Fri, 17 Jul 2020 18:45:58 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id A77CA2D2D; Fri, 17 Jul 2020 18:45:58 +0000 (UTC) Date: Fri, 17 Jul 2020 20:45:56 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Cc: "Brian Mcgovern (bmcgover)" , Ian Lepore , Hans Petter Selasky Subject: Re: Question on structure of USB (specifically USB Serial) stack Message-ID: <20200717184556.2ad5wby3demdxeo4@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org, "Brian Mcgovern (bmcgover)" , Ian Lepore , Hans Petter Selasky References: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> <20200717001834.GU4213@funkthat.com> <20200717183034.GW4213@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w4gtqdzvg7aa4kp7" Content-Disposition: inline In-Reply-To: <20200717183034.GW4213@funkthat.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 18:45:58 -0000 --w4gtqdzvg7aa4kp7 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 17, 2020 at 11:30:34AM -0700, John-Mark Gurney wrote: >Brian Mcgovern (bmcgover) wrote this message on Fri, Jul 17, 2020 at 14:06= +0000: >> John-Mark Gurney said >> >> Look here: >> https://reviews.freebsd.org/D21886 >> >> I've added a script, linked here: >> https://www.funkthat.com/~jmg/FreeBSD/usbserialsn >> >> There are two modes, if the device has a serial number, that will be >> used. If the device has an empty serial number, it's usb bus and port >> number path will be used. >> >> Thank you. I'll take a look at the patch and script today. From a quick = once over, it looks like it'll meet my needs - pretty much keeping the devi= ce names unique and identifiable during reboots and detach/reattach events.= If I see any issues, I'll let you know. > >Just for clarification, the script does not require the patch to be >applied. That patch in the review was a separate effort. > >The script should likely work on past FreeBSD releases as well, but >I haven't tested it on them. > I'm using it on 12.1-RELEASE, and it works fine there. :) >> ________________________________ >> From: John-Mark Gurney >> Sent: Thursday, July 16, 2020 8:18 PM >> To: Brian Mcgovern (bmcgover) >> Cc: Ian Lepore ; Hans Petter Selasky ;= freebsd-hackers@freebsd.org >> Subject: Re: Question on structure of USB (specifically USB Serial) stack >> >> FreeBSD Hackers wrote this message on Thu, Jul 16, 2020 at 23:18 +0000: >> > Ian Lepore said: >> > >> > This seems to me to be one of those situations where answering the >> > exact question that was asked isn't the right thing to do. Instead it >> > needs to be answered with another question: What it is you're really >> > trying to accomplish, and why do you think doing this crazy-unsafe >> > casting is the only way to get it done? >> > >> > I get its crazy unsafe for the non-specific case. That is why I'm aski= ng the question - to see if there is a good way to get the info. >> > >> > What I'm hoping to do is pin some USB devices with FTDI interfaces to = more consistent name, similar to /dev/usb, based on the tree of struct usb_= device entries and their respective addresses. What I see with the cuaUXX f= ormatting is that if one gets rebooted or someone hits the power cord, it'l= l bounce fast enough that it'll come back with a different name. As a resul= t, even though we can get a consistent layout on power up, if you come back= a week or two later, everything is out of order. I was hoping that if I co= uld at least get an alias that mapped to the port the device was in, that w= ould be sufficient to find the "right one", regardless of what the cuaUX na= mes were doing. >> > >> > The reason for picking this particular section of the code is that it = appears I can get most of the work done locally and have similar behavior w= ith all of the devices that share ucom. However, if what I'm seeing as a hu= rdle is really a wall, I'm open to better ideas. >> >> Look here: >> https://reviews.freebsd.org/D21886 >> >> I've added a script, linked here: >> https://www.funkthat.com/~jmg/FreeBSD/usbserialsn >> >> There are two modes, if the device has a serial number, that will be >> used. If the device has an empty serial number, it's usb bus and port >> number path will be used. >> >> > Sent: Thursday, July 16, 2020 6:32 PM >> > To: Hans Petter Selasky ; Brian Mcgovern (bmcgover) <= bmcgover@cisco.com>; freebsd-hackers@freebsd.org >> > Subject: Re: Question on structure of USB (specifically USB Serial) st= ack >> > >> > On Thu, 2020-07-16 at 23:21 +0200, Hans Petter Selasky wrote: >> > > On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers >> > > wrote: >> > > > All, >> > > > I'm doing some playing with the ucom code, and I'm down to a >> > > > link in the data that I'm just not confident I've parsed the code >> > > > correctly. In sys/dev/usb/serial/usb_serial.c, specifically in >> > > > ucom_attach_tty, I'm trying to get a reference to the usb_device >> > > > structure for the device used elsewhere in the USB code. The >> > > > specific devices I'm working with are USB->RJ 45 cables with a >> > > > built in FTDI chip, in case this matters >> > > > >> > > > It appears that the ucom_super_softc and ucom_softc structures >> > > > are available. From looking around the code, it appears the >> > > > sc_parent field of ucom_softc is pointing back to the uftdi_softc >> > > > structure in uftdi.c (for the uftdi case), so the path would be >> > > > ucom_softc->sc_parent->sc_udev, but my concern is going through the >> > > > void *, as it appears each of the devices that use ucom as the base >> > > > have sc_udev in a different part of their structure, meaning I'm >> > > > likely going to crash the system if I plan on it being an FTDI >> > > > device, and its not. Is there a callback or a canonical mechanism >> > > > for accessing this part of the structure given a starting point of >> > > > the ucom_softc? Alternatively, are there any well defined >> > > > attributes I can use to figure out what that void* is pointing to, >> > > > or at least conditionalizing the code so I can dereference it >> > > > correctly? >> > > >> > > Hi, >> > > >> > > Usually using void pointers this way works fine, as long as you are >> > > careful. There is also something called __containerof() which can be >> > > used to get the pointer to a structure based on the pointer to a >> > > structure inside that structure, thinking of the struct ucom_softc, >> > > which is type-safe. >> > > >> > > >> > >> > You still can't just blindly cast ucom_softc->sc_parent back to a >> > struct uftdi_softc in ucom_tty_attach() because it will crash and burn >> > if any non-ftdi serial device is attached. Using __container_of() >> > doesn't change that in any way -- you must already know for certain >> > that the type pointed to by the pointer is the type you name in the >> > container_of() invocation. >> > >> > This seems to me to be one of those situations where answering the >> > exact question that was asked isn't the right thing to do. Instead it >> > needs to be answered with another question: What it is you're really >> > trying to accomplish, and why do you think doing this crazy-unsafe >> > casting is the only way to get it done? > >--=20 > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." >_______________________________________________ >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" --w4gtqdzvg7aa4kp7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl8R8eRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87ooHggAnUAK0eoyuNQXcCxt/c4F5DICTcRjJ5tV3DoW/rAfLxua3Xrt/ymMiYYF hHPGHEzca6D3zVWDMmd9EC2P5nmH3UTPLm3lejBn7uCzxlFM6eOowel45S3y3U4c cGDQYbPy48CS50OjL8zdbfRHNAS/7EIrhSLubUKdDz7aPIpNLCZZNa9X7a2VofHd M1FCts6LfIrwvUWZmwfEE/yo0Q3/XiUHu68YWQK0I+ovrXGQT5CS6Rm2BkTumh9r 18Y2DqZRqWFbeV8DBXZrzvljdwZ6mEb7PjIR16A0cjqWufb02i7SVPt1ceBXVxHI f6nw/2vqO6Is+A4BROvAxvMXKMZ6WQ== =Q4M2 -----END PGP SIGNATURE----- --w4gtqdzvg7aa4kp7-- From owner-freebsd-hackers@freebsd.org Fri Jul 17 20:14:35 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3D34236DC17 for ; Fri, 17 Jul 2020 20:14:35 +0000 (UTC) (envelope-from bmcgover@cisco.com) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (Client CN "iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7j5N70v3z4TZT; Fri, 17 Jul 2020 20:14:32 +0000 (UTC) (envelope-from bmcgover@cisco.com) IronPort-PHdr: =?us-ascii?q?9a23=3AWEUY/RHPdNNOAONMMEDXMp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401Q+bc5/W5th/p6zRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutSUffr1eJwXgVAB?= =?us-ascii?q?qsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAQAoBRJf/4sNJK1dAxYFAQEBAQE?= =?us-ascii?q?BAQEFAQEBEgEBAQMDAQEBQIFKgSMvIwYoBxEBXVgvLId5A41Gk3KEbIJTA1U?= =?us-ascii?q?LAQEBDAEBGAEKCgIEAQGECEQCghkCJDgTAgMBAQsBAQUBAQECAQYEbYVbDIV?= =?us-ascii?q?vAQEBBAEBEBUZAQEMIAsBEQEIEQQBAQFVAQkBHQoEAQcGAQQBBxUEAYMFgX5?= =?us-ascii?q?NAy4BDp9VAoE5iGF0gQEzgwEBAQWBMgGDVxiCDgMGgTgBgmmDSAKGPhqBQT+?= =?us-ascii?q?BEUOBT34+glwBBIEUJgEBAiAfDBqDAoItj2qJOCaBFZpgCoJdiFaGNIQghli?= =?us-ascii?q?fQ5F9iieUVgIEAgQFAg4BAQWBaiOBV3AVO4JpUBcCDY4eDBeBAgEIgkOFFIV?= =?us-ascii?q?CdBEmAgYIAQEDCXyMQYI1AQE?= X-IronPort-AV: E=Sophos;i="5.75,364,1589241600"; d="scan'208,217";a="801256865" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jul 2020 20:14:29 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 06HKETi4031364 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jul 2020 20:14:29 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jul 2020 15:14:28 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jul 2020 16:14:27 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 17 Jul 2020 15:14:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n6o6SR/0h2ZINFg/A02Zk+AeKLnartGZ08WsbtBh8c6U+Fdk20duaLA1w8JK+jxpgS9sZFBTuhHdMkEMcd/VRtswkx7sTTGpOYOtaI0+8649UjYRh3WdIeKpJ3Glmk7IC+b0mRm7e0QUwp59BkoU6s6SvbKfVp+zuSK+uPtZG5zclZOTwmStL8LAo9Dqe5BMtVOO4PkUy4UntwC+eTp16bTyoGK9V0OaRAHKhC+IxYeppA0x5BMFI04et5P1pPevo0bE05PJxtC7dsULLA8dJB1Y70PFlMUAZsQt9Z1NFz8SyjVQbvyl+OB2jb58fx4ZwdXS3bHP4Xff647QsYD57Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F2DrNWo9sNAihfA/ZWW+syhi1U2bKKxXSz55H1ip9t8=; b=a+CLriKAPNGWzyE59op9XDhdYVR4/A99niXCvCJsOFkb1whI46ZFUHRcwceB3mHN2nEkRR8FtjbGALW1EwZkaCuslnzQLtyaZA2yYndlbos/tcSxhSCibf1yXBTB16QTtVWX9GKDY2XNBiOwNrpurydMJLq9crMDxdpkwhUpAiLBTP1YsyL5hyihNPa1K4NZn7nbNXMcUeuzg6/4og3tqO5+6zKDeFKJrp5l04KKLNuHmT/U9b4H/OYXNfqN2rRyrVjzBz4q6NA1vQyc85GDVO651ppnJh4JPkKj1p2I0/9HjKeg51E9vTgWWpy3g4uvEQ+T3VRx98EE77lFzw47RQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none Received: from BL0PR11MB3442.namprd11.prod.outlook.com (2603:10b6:208:68::19) by MN2PR11MB4173.namprd11.prod.outlook.com (2603:10b6:208:137::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.17; Fri, 17 Jul 2020 20:14:26 +0000 Received: from BL0PR11MB3442.namprd11.prod.outlook.com ([fe80::844f:50d2:7986:e539]) by BL0PR11MB3442.namprd11.prod.outlook.com ([fe80::844f:50d2:7986:e539%7]) with mapi id 15.20.3174.026; Fri, 17 Jul 2020 20:14:26 +0000 From: "Brian Mcgovern (bmcgover)" To: Daniel Ebdrup Jensen , "freebsd-hackers@freebsd.org" , John-Mark Gurney CC: Ian Lepore , Hans Petter Selasky Subject: Re: Question on structure of USB (specifically USB Serial) stack Thread-Topic: Question on structure of USB (specifically USB Serial) stack Thread-Index: AQHWXHYS3z0wT4II5U+lFc6NpNfYIQ== Date: Fri, 17 Jul 2020 20:14:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:18c:d07f:d140:547b:bff9:d6a8:7b19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 77505eaa-ce04-43be-199e-08d82a8e014e x-ms-traffictypediagnostic: MN2PR11MB4173: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zuECJAyPeMXiCheov1SxMUlgczCC3VtvnDZq2TWbbfim/a7I7tT9Tx6+hxM9u/dlT8qbTn0g0cTQBSjS0H882fFVGYN03gkdBYhI0/4vxWp7KcV0ExS2VZdJh4B1VnOIp2q/0r6tMbpuZ1GjGN+9BhT0uS8DwEwDbaCMTzWUP0YMBJwvKWEvX0JdrvzyGlYF+XBy1QLFMWhF0kpW3Rai89RXb5JNzLoTxlQHGBAKbl87m8G4xqrIKJdszr2eMQvkMItmVy+BBDU78dsVRSFNDT8oCpOXHsoeQ4gddxfhjuT6watDwX/ECEoa/lhEJQoWHt1eYQypByoLin90g2Muged8ZzaE1ZachPWrkPZir9bCwJUMLABeBFcoavctJuuF5dYP+CmJp1Sl2fFA9r/gzg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3442.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(366004)(136003)(346002)(376002)(66446008)(64756008)(66556008)(66946007)(66476007)(5660300002)(53546011)(6506007)(110136005)(76116006)(2906002)(186003)(52536014)(7696005)(4326008)(19627405001)(478600001)(966005)(71200400001)(33656002)(166002)(55016002)(9686003)(316002)(54906003)(86362001)(83380400001)(8676002)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AeCQZ9izIfoHtIA/4QLrkMnrVDUr+mHPtzivURPrWIerzDMkFu3PY4GTWh79uQNkyhCLqh16QACccoPQlNIXrdtCnd2bcrJoRr6EdRbMuSgwAiw/2qAov+2tFn8yjgLlCL0vFjYGw+E/Y3GgfRVFZV/6Ui7FFNzdgGjWA5K/8rcEEd7yYVtVhOaF/3YXChvrWH7FaroWELozOgF8gaLHBV/+MEv99FFLxnwLzBKJAubsvSBrPpUb7yIZSZLU+zDY08zNntqKQb3kyue151gF+YfUKtVpPnkd4gSzt9N+zERy2seNbJKnqoAVPU53LnkzPsrwkLAKCZbgFdczP9xnzrtkZWvrifBYz9/XVopxG5DEI2slzkcVWOAgJdvWSVJyfKrB2aeuCbN5rJGRgOgBCIOHKOB1xGiKXEqkUHP9B//fNnszf+Kvh8wUlTQCXpMRTbqWEGNkrejYJRX+82BkiEzF4Mg6xH77RvK105JMU1C0ORPU78OZJmzAoPO6hEGQ/PCs3Yq34mPDhKmckN2jfTGCL47to5zEwqerRPNCX5b5hefrAg+RDn7wyqyILAJE x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3442.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 77505eaa-ce04-43be-199e-08d82a8e014e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2020 20:14:26.6582 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EMg9wfEOA8ndEg1avY1nrk2kxecpjZKMDVD/X84bD1iaLIIXr242AtY8dGSk1AfkzQKDkXpQtepEkNMykqvBgw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4173 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-6.cisco.com X-Rspamd-Queue-Id: 4B7j5N70v3z4TZT X-Spamd-Bar: ----------- X-Spamd-Result: default: False [-11.27 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[173.37.86.77:from]; R_SPF_ALLOW(-0.20)[+ip4:173.37.86.0/24]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[cisco.com:+,cisco.onmicrosoft.com:+]; DMARC_POLICY_ALLOW(-0.50)[cisco.com,quarantine]; NEURAL_HAM_SHORT(-1.72)[-1.718]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; ASN(0.00)[asn:109, ipnet:173.37.64.0/18, country:US]; FAKE_REPLY(1.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.033]; R_DKIM_ALLOW(-0.20)[cisco.com:s=iport,cisco.onmicrosoft.com:s=selector2-cisco-onmicrosoft-com]; RCVD_DKIM_ARC_DNSWL_HI(-1.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[cisco.com:dkim]; NEURAL_HAM_LONG(-1.02)[-1.024]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; WHITELIST_SPF_DKIM(-3.00)[cisco.com:d:+,cisco.com:s:+]; RCVD_IN_DNSWL_HI(-0.50)[173.37.86.77:from]; RCVD_COUNT_SEVEN(0.00)[8] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 20:14:35 -0000 I installed both. The script looks like its working, the patch, not quite. = To explain, I did a quick log with the script to print out $1-$4. What I'm seeing in the log is this.... attach uftdi0 A9L5QT3S U384 attach uftdi1 A978RDEY U384 attach utfdi2 A9LITAWI U384 It appears the drivers are mapping all of the USB devices to /dev/cuaU384 a= nd friends. I am seeing appropriate entities in /dev/usb - e.g. I'm getting= 0.4.[0-2], 0.5.[0-2], and 0.6.[0-2]. This might be due to me not reverting= all my own changes back, so to be sure, I'm going to grab clean source and= reapply the patch, but I thought I'd mention it. Good to know there is suc= cess elsewhere. -B ________________________________ From: Daniel Ebdrup Jensen Sent: Friday, July 17, 2020 2:45 PM To: freebsd-hackers@freebsd.org Cc: Brian Mcgovern (bmcgover); Ian Lepore; Hans Petter Selasky Subject: Re: Question on structure of USB (specifically USB Serial) stack On Fri, Jul 17, 2020 at 11:30:34AM -0700, John-Mark Gurney wrote: >Brian Mcgovern (bmcgover) wrote this message on Fri, Jul 17, 2020 at 14:06= +0000: >> John-Mark Gurney said >> >> Look here: >> https://reviews.freebsd.org/D21886 >> >> I've added a script, linked here: >> https://www.funkthat.com/~jmg/FreeBSD/usbserialsn >> >> There are two modes, if the device has a serial number, that will be >> used. If the device has an empty serial number, it's usb bus and port >> number path will be used. >> >> Thank you. I'll take a look at the patch and script today. From a quick = once over, it looks like it'll meet my needs - pretty much keeping the devi= ce names unique and identifiable during reboots and detach/reattach events.= If I see any issues, I'll let you know. > >Just for clarification, the script does not require the patch to be >applied. That patch in the review was a separate effort. > >The script should likely work on past FreeBSD releases as well, but >I haven't tested it on them. > I'm using it on 12.1-RELEASE, and it works fine there. :) >> ________________________________ >> From: John-Mark Gurney >> Sent: Thursday, July 16, 2020 8:18 PM >> To: Brian Mcgovern (bmcgover) >> Cc: Ian Lepore ; Hans Petter Selasky ;= freebsd-hackers@freebsd.org >> Subject: Re: Question on structure of USB (specifically USB Serial) stac= k >> >> FreeBSD Hackers wrote this message on Thu, Jul 16, 2020 at 23:18 +0000: >> > Ian Lepore said: >> > >> > This seems to me to be one of those situations where answering the >> > exact question that was asked isn't the right thing to do. Instead it >> > needs to be answered with another question: What it is you're really >> > trying to accomplish, and why do you think doing this crazy-unsafe >> > casting is the only way to get it done? >> > >> > I get its crazy unsafe for the non-specific case. That is why I'm aski= ng the question - to see if there is a good way to get the info. >> > >> > What I'm hoping to do is pin some USB devices with FTDI interfaces to = more consistent name, similar to /dev/usb, based on the tree of struct usb_= device entries and their respective addresses. What I see with the cuaUXX f= ormatting is that if one gets rebooted or someone hits the power cord, it'l= l bounce fast enough that it'll come back with a different name. As a resul= t, even though we can get a consistent layout on power up, if you come back= a week or two later, everything is out of order. I was hoping that if I co= uld at least get an alias that mapped to the port the device was in, that w= ould be sufficient to find the "right one", regardless of what the cuaUX na= mes were doing. >> > >> > The reason for picking this particular section of the code is that it = appears I can get most of the work done locally and have similar behavior w= ith all of the devices that share ucom. However, if what I'm seeing as a hu= rdle is really a wall, I'm open to better ideas. >> >> Look here: >> https://reviews.freebsd.org/D21886 >> >> I've added a script, linked here: >> https://www.funkthat.com/~jmg/FreeBSD/usbserialsn >> >> There are two modes, if the device has a serial number, that will be >> used. If the device has an empty serial number, it's usb bus and port >> number path will be used. >> >> > Sent: Thursday, July 16, 2020 6:32 PM >> > To: Hans Petter Selasky ; Brian Mcgovern (bmcgover) <= bmcgover@cisco.com>; freebsd-hackers@freebsd.org >> > Subject: Re: Question on structure of USB (specifically USB Serial) st= ack >> > >> > On Thu, 2020-07-16 at 23:21 +0200, Hans Petter Selasky wrote: >> > > On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers >> > > wrote: >> > > > All, >> > > > I'm doing some playing with the ucom code, and I'm down to a >> > > > link in the data that I'm just not confident I've parsed the code >> > > > correctly. In sys/dev/usb/serial/usb_serial.c, specifically in >> > > > ucom_attach_tty, I'm trying to get a reference to the usb_device >> > > > structure for the device used elsewhere in the USB code. The >> > > > specific devices I'm working with are USB->RJ 45 cables with a >> > > > built in FTDI chip, in case this matters >> > > > >> > > > It appears that the ucom_super_softc and ucom_softc structures >> > > > are available. From looking around the code, it appears the >> > > > sc_parent field of ucom_softc is pointing back to the uftdi_softc >> > > > structure in uftdi.c (for the uftdi case), so the path would be >> > > > ucom_softc->sc_parent->sc_udev, but my concern is going through th= e >> > > > void *, as it appears each of the devices that use ucom as the bas= e >> > > > have sc_udev in a different part of their structure, meaning I'm >> > > > likely going to crash the system if I plan on it being an FTDI >> > > > device, and its not. Is there a callback or a canonical mechanism >> > > > for accessing this part of the structure given a starting point of >> > > > the ucom_softc? Alternatively, are there any well defined >> > > > attributes I can use to figure out what that void* is pointing to, >> > > > or at least conditionalizing the code so I can dereference it >> > > > correctly? >> > > >> > > Hi, >> > > >> > > Usually using void pointers this way works fine, as long as you are >> > > careful. There is also something called __containerof() which can be >> > > used to get the pointer to a structure based on the pointer to a >> > > structure inside that structure, thinking of the struct ucom_softc, >> > > which is type-safe. >> > > >> > > >> > >> > You still can't just blindly cast ucom_softc->sc_parent back to a >> > struct uftdi_softc in ucom_tty_attach() because it will crash and burn >> > if any non-ftdi serial device is attached. Using __container_of() >> > doesn't change that in any way -- you must already know for certain >> > that the type pointed to by the pointer is the type you name in the >> > container_of() invocation. >> > >> > This seems to me to be one of those situations where answering the >> > exact question that was asked isn't the right thing to do. Instead it >> > needs to be answered with another question: What it is you're really >> > trying to accomplish, and why do you think doing this crazy-unsafe >> > casting is the only way to get it done? > >-- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." >_______________________________________________ >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 Sat Jul 18 05:01:40 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EB6EF35D353 for ; Sat, 18 Jul 2020 05:01:40 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7wnb5xhSz3ZWT; Sat, 18 Jul 2020 05:01:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A6E65260AA7; Sat, 18 Jul 2020 07:01:31 +0200 (CEST) Subject: Re: Question on structure of USB (specifically USB Serial) stack To: "Brian Mcgovern (bmcgover)" , Ian Lepore , "freebsd-hackers@freebsd.org" References: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> From: Hans Petter Selasky Message-ID: <4504811e-9eed-d3a1-8d5e-561f7f3ce837@selasky.org> Date: Sat, 18 Jul 2020 07:01:07 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B7wnb5xhSz3ZWT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.17 / 15.00]; TO_DN_EQ_ADDR_SOME(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]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.09)[0.091]; NEURAL_HAM_LONG(-1.01)[-1.011]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.953]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 05:01:41 -0000 On 2020-07-17 01:18, Brian Mcgovern (bmcgover) wrote: > What I'm hoping to do is pin some USB devices with FTDI interfaces to more consistent name, similar to /dev/usb, based on the tree of struct usb_device entries and their respective addresses. You might get some ideas how to get struct usb_device inside ucom, by looking at this differential revision: https://reviews.freebsd.org/D21886 Basically you need to make a new API which is passed the uaa->device pointer. Then no void * casting will be needed. --HPS From owner-freebsd-hackers@freebsd.org Sat Jul 18 07:08:28 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AA07535F7EA for ; Sat, 18 Jul 2020 07:08:28 +0000 (UTC) (envelope-from workmail.dhananjayv@gmail.com) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4B7zbv4ydYz3flM for ; Sat, 18 Jul 2020 07:08:27 +0000 (UTC) (envelope-from workmail.dhananjayv@gmail.com) Received: by mail-il1-x12f.google.com with SMTP id p15so9130400ilh.13 for ; Sat, 18 Jul 2020 00:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EsJw2Ms8a4w/kW97wbaKTehtRmctNgMaLd5IK2bVMS4=; b=RkodToZbMiS9TdAkAXgdO5CRg2NkzKASpRpkvgsr7RGj2IdfQy5CEXCf2idvIcKO4F rzDb5CzsSJlLxTqOOZkqezGM2CdcBI0cm2kl1C0glwTPJJNnQlgxWGnvF+czKkabIqzy 0rI7rImqZPFgVXX1S02oClYLQe6J1SB7BbPqlhHi2ueoj+iqVIyaGxGUSty70FEf7alu L71zbVXnKujG/OZv7TpKoPYKusWclVmxdJrJQy0iancYm9+9xwUkKKRAYLLCHJfba7jI sArsumMBbto8S5ttikydAJXwKKsUnpMuwWkGnqwwfEQG+x/nu7JGmfeeZaMZyKayZLe3 X/Ig== 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=EsJw2Ms8a4w/kW97wbaKTehtRmctNgMaLd5IK2bVMS4=; b=ZZif3k6WO8pKrGjIo81rBIv/sXC+paKlw1zlbkIbjMIEwXhOoi/X33EfdyN9Is1k13 wH2fKBZMCyNNG8KW/bBKZlVaLYfPe/Acg8E6gr2aPsT4x7HOY+4boinq0ywSIqtZne9v 7nyYspvVysnKfyCxIRFzWfLnjyUPj3AWSiwF+fON5YOOGYW+TcPOszAHz6aBhehlBDaR JPN7vnYJzZpxIe5Bk4GUpmkZoTWcFLLDBAzy5UrVUjM7GOmOaFoaA8WCvd/x+icwLke4 Ybg2C8HXLOViC+0xgyqd2dUGEQQCC4SzBaXGcqD1b+NSlZCE8UJJAj5LvhlbXv3SscWS QeTQ== X-Gm-Message-State: AOAM532UlnB4JwZXvySzIQkaMa8i65Ogz3dpUGgo1ruJou/Vfw5+A7+p bUEbRLauMOrH7FR4UbdcXqMfgD1yMNKn33BDZelm7A== X-Google-Smtp-Source: ABdhPJya+/01Svogr5leBCJ44sNXe9ZWsh2H6EunaFlWxNScZAAyXHdbs7Txk/+DoX5mbrd5SbpfKSSXfJmPBOuxo7g= X-Received: by 2002:a92:5857:: with SMTP id m84mr13049553ilb.144.1595056106365; Sat, 18 Jul 2020 00:08:26 -0700 (PDT) MIME-Version: 1.0 From: Dhananjay V Date: Sat, 18 Jul 2020 12:38:15 +0530 Message-ID: Subject: Unable to run FreeBSD 12.1 on Skylake Processor (QEMU) To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 4B7zbv4ydYz3flM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=RkodToZb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of workmaildhananjayv@gmail.com designates 2607:f8b0:4864:20::12f as permitted sender) smtp.mailfrom=workmaildhananjayv@gmail.com X-Spamd-Result: default: False [-3.05 / 15.00]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.05)[-1.047]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; 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)[-0.996]; MANY_INVISIBLE_PARTS(0.05)[1]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12f:from]; NEURAL_HAM_SHORT(-0.06)[-0.060]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; 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.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 07:08:28 -0000 I have been trying to run FreeBSD 12.1 on a Skylake processor using QEMU, but when I try to boot the OS, it shows a kernel panic, along with the message *' Unregistered use of FPU in kernel'. *The command I used to start the VM is : qemu-system-x86_64 -cpu Skylake-Client -hda > FreeBSD-12.1-RELEASE-amd64.qcow2 -m 8192 -smp 1 -net > user,hostfwd=3Dtcp::10022-:22 -net nic --monitor stdio *The same disk image works perfectly if I do not include the -cpu Skylake-Client in the command.* This issue also occurs if I try to install FreeBSD while including the -cpu flag during initialization of the VM. What's the solution to this problem? =E1=90=A7