From owner-freebsd-hackers@freebsd.org Sun Dec 27 14:09:34 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 BE1084BC50F for ; Sun, 27 Dec 2020 14:09:34 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 4D3jH24sH8z4ftp; Sun, 27 Dec 2020 14:09:34 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-oi1-x236.google.com with SMTP id 15so9085124oix.8; Sun, 27 Dec 2020 06:09:34 -0800 (PST) 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=CnwmlBlH60VbOWwpvElrV3kuGEPYmDeTowh4r701uV4=; b=NvZvZelbs/oLH3MtT1/R5QMwCr6RveCPTA35G3oJFDnHQ0bP57Kp+2YzSVL+uqEaK1 DrQ0QxZPlJLS5HLsSSBgL4iTEfMuFd0813IYBbwx5bOax3o6julEDa244Qd2OzUudcTx gTcDLmScyHP4UqrgLyL5EtZ/zNqG8hDRcFddpYDMQBJVLfgg9CD98ul/B+40OHGuyUQM zobbTNma85w3uScLcjCiYx0bcWPS1L17vOxkBmIeHLGRg4GYC8yS3BBuE17pD4HNClbE aVk7w+Og0lzohowCKU7dC8TQMz10uqWKDGAr9Txl+Nw/jZbw53CwYPURuH2US8ZNLuxr MGaA== 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=CnwmlBlH60VbOWwpvElrV3kuGEPYmDeTowh4r701uV4=; b=n/n1kwOvBP2d1J/EIAAV7ZqB8WHPHjEOZe2lKxBq6/41bcHjFVnwUsv39dTq4fnL4q 0sBq9kmgK3XoorReNwz1YFzRpgkHhfQ9f4lJVLxZ+F+FeGbmALCWjGGvCBsrPR25NnV+ z2S1xdbP/awHlu+loPRG/RCNRAlkJg3AB2UpSZL8md5Vs5aq4N/uzOFuaWxSPepegnCT LSBJKgs2IhSVV8zFeVF3F6Qa6lvIagvSyDZdZJpHqHHvgJf6TtmTmufKMk1PugQIG2Cg ZJ/HCdHmS15eflE9lD4AOyW9yHZF6Unl80811qDec9M4v4ARcR26GFZhggfnPsAYKvLm lGiw== X-Gm-Message-State: AOAM533D3Uh4OTFn+ZCsCvJtfyOeB+Qlu7jXsNm9T7GjtRKFAfLM8axI eRXCT82+apVXugPHfzVfHJXs4AFsANJb5FwOcPg= X-Google-Smtp-Source: ABdhPJw9y/QcFUHgTE5PZvtjzSU2VI9uIGsJBI9wN+taqsrrXA5wvEJ03/9mJAnjvq+zYvE9D1Y8kgUKsh0euXXXhnA= X-Received: by 2002:a05:6808:8e4:: with SMTP id d4mr9427482oic.160.1609078173526; Sun, 27 Dec 2020 06:09:33 -0800 (PST) MIME-Version: 1.0 References: <20201224085435.7bs6426646k53wid@frix230> <20201226162135.ihvrlevze4sw47tg@frix230> In-Reply-To: <20201226162135.ihvrlevze4sw47tg@frix230> From: Ganbold Tsagaankhuu Date: Sun, 27 Dec 2020 22:09:22 +0800 Message-ID: Subject: Re: PATCH: Please add if_ure support for Thinkpad Gen2 docks To: Ali Abdallah Cc: Hans Petter Selasky , freebsd-hackers , kevlo@freebsd.org X-Rspamd-Queue-Id: 4D3jH24sH8z4ftp X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2020 14:09:34 -0000 On Sun, Dec 27, 2020 at 12:21 AM Ali Abdallah via freebsd-hackers < freebsd-hackers@freebsd.org> wrote: > On 24.12.2020 13:01, Hans Petter Selasky wrote: > > On 12/24/20 9:54 AM, Ali Abdallah via freebsd-hackers wrote: > > > if_ure: Add support for USB-C and TB3 Gen2. > > > > > > Add support for LAN found on Thinkpad USB-C and Thunderbolt Gen 2 > > > docking stations. > > > > Happy Christmas: > > > https://cgit.freebsd.org/src/commit/?id=a8261b70e6814d09f2f7bef0d344e23ad554f14e > > Many thanks! I've sent you another patch to avoid a hardware issue of > the RTL8153B chip with QFN32. In any case, the if_ure driver needs some > love, I'm not sure if it is currently maintained in FreeBSD. > IIRC, it doesn't have an active maintainer. You can send the patches via bugzilla. At least if_ure lacks the support of RTL8153B which is found in some boards such as NanoPI R2S. Ganbold > > Happy Christmas! > > > > > --HPS > > > > -- > Ali Abdallah | SUSE L3 Engineer > GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Dec 28 22:41:44 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 3DE994C399F for ; Mon, 28 Dec 2020 22:41:44 +0000 (UTC) (envelope-from leres@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 4D4XbX1Pqdz4q5S for ; Mon, 28 Dec 2020 22:41:44 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from ice.alameda.xse.com (unknown [IPv6:2600:1700:a570:e20:f2ad:4eff:fe0b:a065]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id E7276224BB for ; Mon, 28 Dec 2020 22:41:43 +0000 (UTC) (envelope-from leres@freebsd.org) From: Craig Leres Subject: Re: mouse tilt wheel between 12.1 and 12.2 References: <9bc997ae-096c-c38b-377d-3bf64f530715@freebsd.org> To: "freebsd-hackers@freebsd.org" Message-ID: <67274697-202d-f75c-9008-a11ca000904a@freebsd.org> Date: Mon, 28 Dec 2020 14:41:42 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <9bc997ae-096c-c38b-377d-3bf64f530715@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 22:41:44 -0000 On 10/29/20 1:36 PM, Craig Leres wrote: > working with firefox (e.g. tilt-left does not go back a page). I finally solved this. Here are details. First I noticed that left/right tiltwheel would cause firefox to horizontally scroll left and right. (I'm sure this is desired behavior for some.) Looking in /var/log/Xorg.0.log I (re)confirmed that I'm using evdev. That lead me to some references to xinput. To find out the input device number of the mouse use: ice 2 % xinput --list | fgrep mouse System mouse id=6 [slave pointer (2)] Once you have the device number you can see the current button map: ice 3 % xinput get-button-map 6 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 I was able to confirm that the tiltwheel buttons were 6 and 7 using xev; turn the mouse upside down so it doesn't generate any movement events and then click the wheel left and right. You can see the mouse button labels with: xinput --list 6 | fgrep label Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" "Button Side" "Button Extra" "Button Forward" "Button Back" "Button Task" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown" I found an ubuntu reference that indicated that left tiltwheel is button 8 and right is 9. So in theory we need to map 6 to 8 and 7 to 9. Previously I had used: moused_flags="-m 4=6 -m 5=7" in rc.conf. So changed rc.d, kill moused, replug the usb mouse and test; I couldn't get it to work with the new desired mappings. Next I tried using xinput: xinput -set-button-map 6 1 2 3 4 5 8 9 6 7 but for whatever reason this does not take effect during the current X session. Looking at the evdev man page I found you can define a ButtonMapping option in the mouse inputclass section so I added this: Section "InputClass" Identifier "mouse defaults" Driver "evdev" Option "ButtonMapping" "1 2 3 4 5 8 9 6 7" EndSection After restarting X I was able to confirm the new mapping with xinput: ice 19 % xinput get-button-map 6 1 2 3 4 5 8 9 6 7 10 11 12 13 14 15 16 also with xev and with (importantly) firefox. As a bonus here is the inputclass I use to map caps lock to ctrl: Section "InputClass" Identifier "keyboard defaults" MatchIsKeyboard "on" Option "XkbLayout" "us" Option "XKbOptions" "caps:ctrl_modifier" EndSection Hopefully it'll be a long time before the next time the X gods change the mouse button numbers. Craig From owner-freebsd-hackers@freebsd.org Tue Dec 29 05:48:02 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 176034D11E2 for ; Tue, 29 Dec 2020 05:48:02 +0000 (UTC) (envelope-from arka.sw1988@gmail.com) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 4D4k3P1mBfz3JKR for ; Tue, 29 Dec 2020 05:48:01 +0000 (UTC) (envelope-from arka.sw1988@gmail.com) Received: by mail-ej1-x62d.google.com with SMTP id x16so16851859ejj.7 for ; Mon, 28 Dec 2020 21:48:01 -0800 (PST) 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=0aIyMUhzdyOJn0LK+kFnqoRDzDMa3P+gfgbcYlHBHEk=; b=Qx0lqGimJv8vAQKQ1XJPeHKZdXEfNRCDQ4/Tq+0IYNU7RdL8wlLLhkGu9UNgceHiKN XLuYO5fZw1l3Xn/DQl5nUDaJlyuis+6u3OsMb/d8nHaqGuA08q1fXSwfFsARpp2yqZsB ZytJqDY+UuEEKwQRVxyL39J4XljJaiP1uprZnZax202AYHPUSjdYKT1WXi3RjoRmfXyb c5qzeeBqbgyJhZlX8BTYMYQGborsniMJkiTZp+qDhcI5GrzF9oJ5JNAFQvgME+RBXt8K a9R5SUQJ3SFJsxVJdNijlgG9xJZrhYdTojKNXEHUinmTSa9CZW+qdgKOQQ524v5SAMLx Aprw== 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=0aIyMUhzdyOJn0LK+kFnqoRDzDMa3P+gfgbcYlHBHEk=; b=KOd9YrpAkFKyMkmUJmFjKqWFh9fBGlFygGHTIGolbJrn1zrRUFaY55CGAlNnWoaUI0 OU+i3UPLrP/KdJ4ak1AylbNqr4k5odRZCejMb7Q6OB1VpkSsvvCMximDO+FbNVBw27e1 NcYMvk4ciCHw13eQJubD6N6kB9pW1OtolF3v1aluuNrqMEPswHtFkTK8qOW4BscvBPDT J3yhBXzc4iEvsHXj+qsatTBzB4XPnkVob4gAqOFrN6LozVtV3JKeuzZlJTsZCKktI4VJ +lXOFdvjMBRS7YfDAaR/B61WuTH7sP3eOHeuYu9gbjU+C+blob9xNMWj8B0ABhpXsFFF S6aw== X-Gm-Message-State: AOAM530yEcqTzJoHLFeF66xOGR8pTMkq2wjFRzfroqJ+NRPcMBm4F5bW bcgc/ZQAmo1EIfQV+D0OuOO7BYCWBiwofYJ6oOKveMoju4A= X-Google-Smtp-Source: ABdhPJzaUVLCDpC3+jG8fV0zIdsC1SSniGjD9fETBLxB3myu6M5VXrTsPnexPZVRgW8/akiMGzX8rTsW5TOhkkyWXlg= X-Received: by 2002:a17:906:5e0f:: with SMTP id n15mr37919715eju.459.1609220879781; Mon, 28 Dec 2020 21:47:59 -0800 (PST) MIME-Version: 1.0 From: Arka Sharma Date: Tue, 29 Dec 2020 11:17:48 +0530 Message-ID: Subject: Updating 'bio_completed' field in case of unwritten LBA To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 4D4k3P1mBfz3JKR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Qx0lqGim; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of arkasw1988@gmail.com designates 2a00:1450:4864:20::62d as permitted sender) smtp.mailfrom=arkasw1988@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::62d:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::62d:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62d:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 05:48:02 -0000 Hi All, Sorry if this is not the right place to ask this question. I am writing a driver which creates a disk instance and processes bio's coming from GEOM. GEOM can send read requests for LBA's which are yet to be written. In this case should we update the 'bio_completed' field in bio instance sent by GEOM ? Regards, Arka From owner-freebsd-hackers@freebsd.org Tue Dec 29 10:50: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 E368F4B82EB for ; Tue, 29 Dec 2020 10:50:05 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.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 4D4rlv5wk5z3qx4 for ; Tue, 29 Dec 2020 10:50:03 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy05.your-server.de ([78.46.172.2]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kuCZb-00065q-3i for freebsd-hackers@freebsd.org; Tue, 29 Dec 2020 11:49:56 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1kuCZb-000X8l-0z for freebsd-hackers@freebsd.org; Tue, 29 Dec 2020 11:49:51 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id AB02E2A1610 for ; Tue, 29 Dec 2020 11:49:50 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id t7u6AuxKKDz6 for ; Tue, 29 Dec 2020 11:49:50 +0100 (CET) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 4A1482A165B for ; Tue, 29 Dec 2020 11:49:50 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wywKqePuBD27 for ; Tue, 29 Dec 2020 11:49:50 +0100 (CET) Received: from shuber-nb-linux.eb.localhost (unknown [10.10.171.18]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 29E072A1610 for ; Tue, 29 Dec 2020 11:49:50 +0100 (CET) To: freebsd-hackers@freebsd.org From: Sebastian Huber Subject: Why is there e_drain_sx and e_drain_mtx? Message-ID: <5eeae691-b7d4-932b-14cc-065a368e77de@embedded-brains.de> Date: Tue, 29 Dec 2020 11:49:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.102.4/26031/Mon Dec 28 13:43:18 2020) X-Rspamd-Queue-Id: 4D4rlv5wk5z3qx4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-2.30 / 15.00]; RCVD_COUNT_SEVEN(0.00)[8]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[85.10.215.148:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; 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]; SPAMHAUS_ZRD(0.00)[85.10.215.148:from:127.0.2.255]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_NA(0.00)[embedded-brains.de]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; HAS_X_AS(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 10:50:05 -0000 Hello, in the epoch based reclamation implementation we have struct epoch { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct ck_epoch e_epoch __ali= gned(EPOCH_ALIGN); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 epoch_record_t e_pcpu_record; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int=C2=A0=C2=A0=C2=A0=C2=A0 e= _in_use; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int=C2=A0=C2=A0=C2=A0=C2=A0 e= _flags; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct sx e_drain_sx; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct mtx e_drain_mtx; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 volatile int e_drain_count; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const char *e_name; }; The e_drain_sx and e_drain_mtx are only used in void epoch_drain_callbacks(epoch_t epoch) { ... =C2=A0=C2=A0=C2=A0 DROP_GIANT(); =C2=A0=C2=A0=C2=A0 sx_xlock(&epoch->e_drain_sx); =C2=A0=C2=A0=C2=A0 mtx_lock(&epoch->e_drain_mtx); ... =C2=A0=C2=A0=C2=A0 mtx_unlock(&epoch->e_drain_mtx); =C2=A0=C2=A0=C2=A0 sx_xunlock(&epoch->e_drain_sx); =C2=A0=C2=A0=C2=A0 PICKUP_GIANT(); } Why is there a combination of a shared/exclusive lock and a mutex used=20 like this? Why is a single mutex insufficient? --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From owner-freebsd-hackers@freebsd.org Tue Dec 29 10:56:37 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 A06554B8A9A for ; Tue, 29 Dec 2020 10:56:37 +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 4D4rvS4S0Zz3rVT for ; Tue, 29 Dec 2020 10:56:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0BTAuNlD065835 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 29 Dec 2020 12:56:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0BTAuNlD065835 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0BTAuNo5065834; Tue, 29 Dec 2020 12:56:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 29 Dec 2020 12:56:23 +0200 From: Konstantin Belousov To: Arka Sharma Cc: freebsd-hackers@freebsd.org Subject: Re: Updating 'bio_completed' field in case of unwritten LBA Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 4D4rvS4S0Zz3rVT 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 [-2.56 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; NEURAL_HAM_SHORT(-0.56)[-0.556]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 10:56:37 -0000 On Tue, Dec 29, 2020 at 11:17:48AM +0530, Arka Sharma wrote: > Hi All, > > Sorry if this is not the right place to ask this question. I am writing a > driver which creates a disk instance and processes bio's coming from GEOM. > GEOM can send read requests for LBA's which are yet to be written. In this > case should we update the 'bio_completed' field in bio instance sent by > GEOM ? Disk must execute the BIO command according to its state at the moment the command is processed. Why does it matter was the block written or not ? If you write a driver for the storage that implements some kind of allocate on write, you need to also allocate on read, and define the state of the block if it was not written yet. Typically such (virtual) storages read the newly allocated block as all zeros. From owner-freebsd-hackers@freebsd.org Tue Dec 29 11:07: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 5B8224B8FF3 for ; Tue, 29 Dec 2020 11:07:28 +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 4D4s7y4NyRz3sQP for ; Tue, 29 Dec 2020 11:07:26 +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 81F6E26009E; Tue, 29 Dec 2020 12:07:18 +0100 (CET) Subject: Re: Why is there e_drain_sx and e_drain_mtx? To: Sebastian Huber , freebsd-hackers@freebsd.org References: <5eeae691-b7d4-932b-14cc-065a368e77de@embedded-brains.de> From: Hans Petter Selasky Message-ID: <529e7ef5-18e9-0e56-16d3-000d324f42d0@selasky.org> Date: Tue, 29 Dec 2020 12:07:10 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <5eeae691-b7d4-932b-14cc-065a368e77de@embedded-brains.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4D4s7y4NyRz3sQP 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.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[88.99.82.50:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[88.99.82.50:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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:24940, ipnet:88.99.0.0/16, country:DE]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 11:07:28 -0000 On 12/29/20 11:49 AM, Sebastian Huber wrote: > Hello, > > in the epoch based reclamation implementation we have > > struct epoch { >         struct ck_epoch e_epoch __aligned(EPOCH_ALIGN); >         epoch_record_t e_pcpu_record; >         int     e_in_use; >         int     e_flags; >         struct sx e_drain_sx; >         struct mtx e_drain_mtx; >         volatile int e_drain_count; >         const char *e_name; > }; > > The e_drain_sx and e_drain_mtx are only used in > > void > epoch_drain_callbacks(epoch_t epoch) > { > ... >     DROP_GIANT(); > >     sx_xlock(&epoch->e_drain_sx); >     mtx_lock(&epoch->e_drain_mtx); > > ... > >     mtx_unlock(&epoch->e_drain_mtx); >     sx_xunlock(&epoch->e_drain_sx); > >     PICKUP_GIANT(); > } > > Why is there a combination of a shared/exclusive lock and a mutex used > like this? Why is a single mutex insufficient? > Hi Sebastian, The sx_xlock() is there because the operation may sleep and mutexes must be dropped when sleeping. We only allow one drain at a time. The mtx_lock() is there to make the operation atomic with regards to the msleep/wakeup sequence. Search for the use of e_drain_mtx . Else the msleep and wakeup calls may miss eachother. How is the porting going otherwise? Do you see any performance improvements using EPOCH? --HPS From owner-freebsd-hackers@freebsd.org Tue Dec 29 15:26: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 002C34C2ADF for ; Tue, 29 Dec 2020 15:26:10 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.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 4D4ytT0qdvz4jMT for ; Tue, 29 Dec 2020 15:26:08 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy05.your-server.de ([78.46.172.2]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kuGsw-000EIJ-RM; Tue, 29 Dec 2020 16:26:07 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1kuGsw-000SuS-ON; Tue, 29 Dec 2020 16:26:06 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 761952A1610; Tue, 29 Dec 2020 16:26:06 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 87FxUPgQfIs2; Tue, 29 Dec 2020 16:26:06 +0100 (CET) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1F4D22A165B; Tue, 29 Dec 2020 16:26:06 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DjZZaqc-5ZHW; Tue, 29 Dec 2020 16:26:06 +0100 (CET) Received: from shuber-nb-linux.eb.localhost (unknown [10.10.171.18]) by mail.embedded-brains.de (Postfix) with ESMTPSA id EA3062A1610; Tue, 29 Dec 2020 16:26:05 +0100 (CET) Subject: Re: Why is there e_drain_sx and e_drain_mtx? To: Hans Petter Selasky , freebsd-hackers@freebsd.org References: <5eeae691-b7d4-932b-14cc-065a368e77de@embedded-brains.de> <529e7ef5-18e9-0e56-16d3-000d324f42d0@selasky.org> From: Sebastian Huber Message-ID: Date: Tue, 29 Dec 2020 16:26:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <529e7ef5-18e9-0e56-16d3-000d324f42d0@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.102.4/26032/Tue Dec 29 13:42:39 2020) X-Rspamd-Queue-Id: 4D4ytT0qdvz4jMT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-2.27 / 15.00]; RCVD_COUNT_SEVEN(0.00)[8]; 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)[+ip4:85.10.215.148]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; SPAMHAUS_ZRD(0.00)[85.10.215.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[85.10.215.148:from]; NEURAL_HAM_SHORT(-0.97)[-0.969]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; HAS_X_AS(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 15:26:10 -0000 On 29/12/2020 12:07, Hans Petter Selasky wrote: > On 12/29/20 11:49 AM, Sebastian Huber wrote: >> Hello, >> >> in the epoch based reclamation implementation we have >> >> struct epoch { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct ck_epoch e_epo= ch __aligned(EPOCH_ALIGN); >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 epoch_record_t e_pcpu= _record; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int=C2=A0=C2=A0=C2=A0= =C2=A0 e_in_use; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int=C2=A0=C2=A0=C2=A0= =C2=A0 e_flags; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct sx e_drain_sx; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct mtx e_drain_mt= x; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 volatile int e_drain_= count; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const char *e_name; >> }; >> >> The e_drain_sx and e_drain_mtx are only used in >> >> void >> epoch_drain_callbacks(epoch_t epoch) >> { >> ... >> =C2=A0=C2=A0=C2=A0=C2=A0 DROP_GIANT(); >> >> =C2=A0=C2=A0=C2=A0=C2=A0 sx_xlock(&epoch->e_drain_sx); >> =C2=A0=C2=A0=C2=A0=C2=A0 mtx_lock(&epoch->e_drain_mtx); >> >> ... >> >> =C2=A0=C2=A0=C2=A0=C2=A0 mtx_unlock(&epoch->e_drain_mtx); >> =C2=A0=C2=A0=C2=A0=C2=A0 sx_xunlock(&epoch->e_drain_sx); >> >> =C2=A0=C2=A0=C2=A0=C2=A0 PICKUP_GIANT(); >> } >> >> Why is there a combination of a shared/exclusive lock and a mutex=20 >> used like this? Why is a single mutex insufficient? >> > > Hi Sebastian, > > The sx_xlock() is there because the operation may sleep and mutexes=20 > must be dropped when sleeping. We only allow one drain at a time. > > The mtx_lock() is there to make the operation atomic with regards to=20 > the msleep/wakeup sequence. Search for the use of e_drain_mtx . Else=20 > the msleep and wakeup calls may miss eachother. Thanks for the explanation. I overlooked the msleep() call. > > How is the porting going otherwise? Do you see any performance=20 > improvements using EPOCH? It works quite well, even on old chips like the MCF5475. I didn't=20 monitor the performance over time, but nobody complained so far. --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From owner-freebsd-hackers@freebsd.org Tue Dec 29 20:31:38 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 E66624CA343; Tue, 29 Dec 2020 20:31:38 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D55fx5t4Tz3MZp; Tue, 29 Dec 2020 20:31:37 +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 0BTKVZRd090207 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Dec 2020 12:31:35 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 0BTKVZ4s090206; Tue, 29 Dec 2020 12:31:35 -0800 (PST) (envelope-from jmg) Date: Tue, 29 Dec 2020 12:31:35 -0800 From: John-Mark Gurney To: Arka Sharma Cc: freebsd-hackers@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Updating 'bio_completed' field in case of unwritten LBA Message-ID: <20201229203135.GW31099@funkthat.com> Mail-Followup-To: Arka Sharma , freebsd-hackers@freebsd.org, freebsd-geom@freebsd.org References: 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]); Tue, 29 Dec 2020 12:31:35 -0800 (PST) X-Rspamd-Queue-Id: 4D55fx5t4Tz3MZp 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.80 / 15.00]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[funkthat.com]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-geom] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 20:31:39 -0000 Arka Sharma wrote this message on Tue, Dec 29, 2020 at 11:17 +0530: > Sorry if this is not the right place to ask this question. I am writing a the -geom list is a better place, I have cc'd it there for more visibility... > driver which creates a disk instance and processes bio's coming from GEOM. > GEOM can send read requests for LBA's which are yet to be written. In this > case should we update the 'bio_completed' field in bio instance sent by > GEOM ? If by not yet written, you're talking about a fresh disk device, that has never been written to, and reads are issued to blocks? If so, this is expected as FreeBSD doesn't know when the dev appears if it's fresh or not... The reads are part of a process called tasting, and it reads data to find out information about the dev, like if it's part of a mirror, or the partitions that are on it and the like... If this is the case, then, I'd suggest you driver return all zero's, that is zero out the buffer, and update the read as if it worked... If you return an error (like geli does when using authenticated encryption), there are many parts of the kernel that will not handle that gracefully... (Just realized that'd be a useful mode for geli to have, to return zeros for failed authentication.) -- 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 Wed Dec 30 02:30:34 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 F14D54D1DD9; Wed, 30 Dec 2020 02:30:34 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) (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 4D5Fd54Hkcz4SQN; Wed, 30 Dec 2020 02:30:33 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id D0C23EB48F; Tue, 29 Dec 2020 18:30:23 -0800 (PST) MIME-Version: 1.0 Date: Tue, 29 Dec 2020 18:30:23 -0800 From: Neel Chauhan To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5Fd54Hkcz4SQN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 2001:19f0:8001:fed:5400:2ff:fe73:c622 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+a]; SPAMHAUS_ZRD(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 02:30:35 -0000 Hi freebsd-hackers@, CC'd freebsd-current@, I hope you all had a wonderful holiday season. I recently got a HP Spectre x360 13t-aw200 which is an Intel TigerLake-based laptop. It has the Intel "Evo" branding and an "Optane" SSD which I disabled (so I can get a "second" SSD). On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ I don't know if it is HP or Intel, but the VMD IDs device id is 8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also have this device ID [1]. Sadly, NVMe RAID is forced on this laptop. I wrote a rough patch to add the device IDs, and the patch is below: --- a/sys/dev/vmd/vmd.c +++ b/sys/dev/vmd/vmd.c @@ -66,13 +66,20 @@ struct vmd_type { #define INTEL_VENDOR_ID 0x8086 #define INTEL_DEVICE_ID_VMD 0x201d #define INTEL_DEVICE_ID_VMD2 0x28c0 +#define INTEL_DEVICE_ID_VMD3 0x9a0b static struct vmd_type vmd_devs[] = { { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume Management Device" }, { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume Management Device" }, + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume Management Device" }, { 0, 0, NULL } However, I get a panic whenever I use this patch: https://imgur.com/a/XUQksOi Without this patch, I am able to boot fine but can't see the SSD or any nvd* devices beyond a "none" device in `pciconf -lv`. For those who know about PCI/ACPI subsystems, can you please tell me what's going wrong? I'm still debugging in the meanwhile, but am no expert on PCI/ACPI subsystems. I may know more than most PC builders or CS grads, but not really enough to do it full-time. The Spectre's SSD works fine with Windows 10 (obviously) and Linux (Fedora and Debian tested). Best, Neel Chauhan Sources: [1]: Linux probes: * Vostro: https://certification.ubuntu.com/hardware/202007-28047 * XPS: https://linux-hardware.org/?probe=ba53f6e513 From owner-freebsd-hackers@freebsd.org Wed Dec 30 12:42: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 CF8A34C2462 for ; Wed, 30 Dec 2020 12:42:07 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 4D5WBl1byNz3LWZ for ; Wed, 30 Dec 2020 12:42:07 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd30.google.com with SMTP id z5so14596438iob.11 for ; Wed, 30 Dec 2020 04:42:07 -0800 (PST) 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=Mk9U6wGQ3sBLtYK9hDi6DxpdWeJqXh1xvaslaoH/RHY=; b=QMkMQ4sfRTIhVoIJNJRDuP6dCpaJKLtnJE+QEqzlcxFfL+4gsgbI6ntKsQeq+GBVh/ nByAhOr/kNi08GxNYELm3eFRNWGA38+HUxy6OK7uIEx7InrVYt5MT7GM+tNpJOmHk6Mg DAAd/sFY9nAj4k+L1rtpJeIamVg9PeuBjyqk3bmksmTIHtoOD2jY1OokFfA/GzXdpjpP 3rm3L2rjaiOUTV7Wjtrs0nyYeZ5Cpr7hVb3hvCEON3hqm1RdUX/C6YdGF0sME25Za0Io eM5Rm8HRmi16m9PhCqveFGqpoEl7xh3aOJ9S2LUCf1TrmbdiwQn0p0EUevGl4iGUXw0R EEIw== 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=Mk9U6wGQ3sBLtYK9hDi6DxpdWeJqXh1xvaslaoH/RHY=; b=R3o7JcUKDNWYpUCIneaBZ02gzP/be67NWPoHknSxjc0xhFGQzUd8ckk1T8goyJXOrP DtG3hu46rjOWmvoYLnRK6/ZLXBRsX/5OgFQNnc5DhwRHsdoYD51HzHAyu7Av/7ZJBOyC OdOxJ1XbwpCf5eIW20qucsKVdkiGfks7XLj1zW5K78b72FvNmQJXXTwM9VRWl1HB8YOK UdFNoI4BrDbtyxjmrzmKL297syPZNvBvsno6/xx1tDrLTXkU0rv1bZpLHv/391hGqRcj KVgTov4ZNIZUEU94v8A/cC/3c2m5Keg98tlfN8qZ6+CF0QNso+/w1cZhk9wIaL8OjhAh sXuw== X-Gm-Message-State: AOAM532N5Az7hmBcpi3GHu5AiiCX/gRy4rGj3YMjwoQVYrjwBAPry5PI wR+hur1mNhQ0qJfwZNRlevOZfHqg89F3FlztXkf4TWCgALc= X-Google-Smtp-Source: ABdhPJw/tWfktqD5kpW+gWj7qFejA4m4WiEaQD+4LlcJUe/b9Q4f/9U6JmVsCesx6Sj6QWrQcveopi4m7HE9uzAoOjk= X-Received: by 2002:a6b:c414:: with SMTP id y20mr43273438ioa.150.1609332125738; Wed, 30 Dec 2020 04:42:05 -0800 (PST) MIME-Version: 1.0 From: Michael Schuster Date: Wed, 30 Dec 2020 13:41:55 +0100 Message-ID: Subject: up-to-date CURRENT: occasional panic at boot in HDAC To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 4D5WBl1byNz3LWZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=QMkMQ4sf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d30 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::d30:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::d30:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d30:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 12:42:07 -0000 Hi, I'm running CURRENT (updated yesterday) on an AMD ryzen 4700 - powered laptop; occasionally, when I boot after a complete power-off, the boot process panics quite early with a panic in a page fault from hdac_rirb_flush() being called from hdac_intr_handler(), and a message "Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex hdac1 (HDA driver mutex) r = 0 (0xff... ) locked at /usr/src/.../hdac.c:385" I have a picture of the console (including stack trace) on my phone, I can send it to individuals if you want to have it (I get the impression sending attachments on the list is frowned upon). 1) Has anyone else seen this before? 2) what do I need to do to collect more information, and what kind of information is that? TIA for any suggestions ... Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From owner-freebsd-hackers@freebsd.org Wed Dec 30 16:43:23 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 6FF674C862F for ; Wed, 30 Dec 2020 16:43:23 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) (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 4D5cY56lF2z3sp1 for ; Wed, 30 Dec 2020 16:43:21 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 0AFAEEB2A5 for ; Wed, 30 Dec 2020 08:43:18 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 08:43:17 -0800 From: Neel Chauhan To: freebsd-hackers@freebsd.org Subject: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL User-Agent: Roundcube Webmail/1.4.9 Message-ID: <44528336fa9168966d121bf771e1e229@neelc.org> X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5cY56lF2z3sp1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 2001:19f0:8001:fed:5400:2ff:fe73:c622 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; TO_DN_NONE(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ONCE_RECEIVED(0.10)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from:127.0.2.255]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 16:43:23 -0000 Hi all, I'm writing a patch to support the VMD subsystem in Intel TigerLake systems such as the HP Spectre x360 13t-aw200. VMD is needed for NVMe here. The patch is as follows --- a/sys/dev/vmd/vmd.c +++ b/sys/dev/vmd/vmd.c @@ -66,13 +66,20 @@ struct vmd_type { #define INTEL_VENDOR_ID 0x8086 #define INTEL_DEVICE_ID_VMD 0x201d #define INTEL_DEVICE_ID_VMD2 0x28c0 +#define INTEL_DEVICE_ID_VMD3 0x9a0b static struct vmd_type vmd_devs[] = { { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume Management Device" }, { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume Management Device" }, + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume Management Device" }, { 0, 0, NULL } However, when I use the patch, I get a kernel panic related to PCI: https://imgur.com/a/XUQksOi (sorry for the image) It gives me the Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL error. Could you please help me figure out why it's panicking? -Neel From owner-freebsd-hackers@freebsd.org Wed Dec 30 17:06: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 42A6C4C8C77 for ; Wed, 30 Dec 2020 17:06:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 4D5d483kpjz3tnT for ; Wed, 30 Dec 2020 17:06:48 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x834.google.com with SMTP id g24so11285045qtq.12 for ; Wed, 30 Dec 2020 09:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=o9TUslfEN26IIArPPIrerW3rOMj2LrJPdkNqiNtTP/w=; b=q2lwYJk+ZKPmrl30JtK1MAvz+GbvoYkjfQN41JQjovnaSeJaV/xpgXiXgC+IRv/HIU Sbe39OPrCJ5+bHezo2MeyLGu/cRkKE+b1ZUwfaaS7qArh/orNL5qorStlZpBHh9e+thl Ypiird/Zg+ubQdLUpO1Uxff8yWnkMXtCTJCq39UgE5IGCnjGw1lNq3gpNi7Ahj73Wp6L j1c/OHo2osXeEg0gDSQ7pv1KGxicUReihtbEs0zipVWqVtli8PR4JSzDkKV24yE/F3Ag fIsjbFh65ct/nc15tCLbNLc2HmIzB8bwHp3mHZayTXqagjYr1qFC7IROtBMGmjOhfa29 Uv/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=o9TUslfEN26IIArPPIrerW3rOMj2LrJPdkNqiNtTP/w=; b=N+JtMKbvtTJBqk7ZEd8EGcR0M5F3yswAVWwTMkL52ii7BWFh1W+9J1m+1jwiE9S6db 2GQk1rzJ4Dvv9rU2lDlAvjDpfja/Hk6qsYgboK/WArYPkLNOtXOLyDRPUcEj+BHnOUGV 6jbtphrFqA1p0QaqNUrGurunV8lKy6WbxLiVgQyqlAV9eiZntH20hgbPP6Sgnbzmap3/ dWVg7Bh7zX386DyWwvoC6p3o8lYb1IbrDe3ByjTtwGOXagcdKTUouKiEUqr+sLFuc2VW 7w2k8k828y2sP33CYl4pho6nlcQa2C3GovrKDpKnOP+iM0nH7j2zrM4p7eANfYb9j4Bi YHPg== X-Gm-Message-State: AOAM533Akeu/9DrCbdkGTGE4lLAk8GEIN5LcnNA7RSEF7pJfs5hKXDCH LwGnCnGbNjHpldt0oto81/cnFyNMx63FMw== X-Google-Smtp-Source: ABdhPJxh/PUdN6WdxdOnIIf2xLj18cdmBug5jkjv2T3ai7PGhP4rWOfqL5UaSSUKX8iQ0BBKwABZBQ== X-Received: by 2002:ac8:6703:: with SMTP id e3mr53534924qtp.344.1609348007519; Wed, 30 Dec 2020 09:06:47 -0800 (PST) Received: from raichu ([142.126.164.150]) by smtp.gmail.com with ESMTPSA id n4sm28652336qtl.22.2020.12.30.09.06.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Dec 2020 09:06:46 -0800 (PST) Sender: Mark Johnston Date: Wed, 30 Dec 2020 12:06:44 -0500 From: Mark Johnston To: Neel Chauhan Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL Message-ID: References: <44528336fa9168966d121bf771e1e229@neelc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44528336fa9168966d121bf771e1e229@neelc.org> X-Rspamd-Queue-Id: 4D5d483kpjz3tnT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=q2lwYJk+; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::834 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.69 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.991]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::834:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::834:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::834:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 17:06:49 -0000 On Wed, Dec 30, 2020 at 08:43:17AM -0800, Neel Chauhan wrote: > Hi all, > > I'm writing a patch to support the VMD subsystem in Intel TigerLake > systems such as the HP Spectre x360 13t-aw200. VMD is needed for NVMe > here. > > The patch is as follows > > --- a/sys/dev/vmd/vmd.c > +++ b/sys/dev/vmd/vmd.c > @@ -66,13 +66,20 @@ struct vmd_type { > #define INTEL_VENDOR_ID 0x8086 > #define INTEL_DEVICE_ID_VMD 0x201d > #define INTEL_DEVICE_ID_VMD2 0x28c0 > +#define INTEL_DEVICE_ID_VMD3 0x9a0b > > static struct vmd_type vmd_devs[] = { > { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume > Management Device" }, > { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume > Management Device" }, > + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume > Management Device" }, > { 0, 0, NULL } > > However, when I use the patch, I get a kernel panic related to PCI: > https://imgur.com/a/XUQksOi (sorry for the image) > > It gives me the Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL > error. > > Could you please help me figure out why it's panicking? Based on the backtrace, we are panicking in rman_init() because the global rman_head list is corrupted (the panic message is basically stating that the next element of the last element of the list is not NULL). This suggests that the item was freed without removing it from the list, i.e., an rman_fini() call is missing. vmd_attach() creates a resource container with rman_init(). If vmd_attach() fails for some reason, it calls vmd_free(), which is supposed to roll back anything done by vmd_attach(). Note that if attach is successful, the driver subsystem may later call vmd_detach() to deinitialize the driver, and vmd_detach() does a bit of extra work in addition to calling vmd_free()... From owner-freebsd-hackers@freebsd.org Wed Dec 30 17:57: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 B8A1D4CA23F for ; Wed, 30 Dec 2020 17:57:17 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5fBN4XSkz4RcK for ; Wed, 30 Dec 2020 17:57:16 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609351034; bh=Hdp1hwYy3O3xYNxhM9MjKPe8Zm1AWLh5HMhzAu+ls5s=; h=X-UI-Sender-Class:To:From:Subject:Date; b=Ux8J/LIZGrZPRCbY0ER+ZrElRa/XN3f9PpTBB3QiJSGU8cj22/E9fHaqPxUZak/7H sXoOaNuPL2iqWPrVrkIDk9/7SPKs3ji94mIMzCv+gKkv/MJoCDeXeSFwEZ/wN2fvJx Y0HCeForPWmf9nn01CKN3KJ1qmnxpbEfHfhjdBnQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [2.2.3.2] ([87.122.30.127]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MKsjH-1ka6Qp36Lt-00LIzm for ; Wed, 30 Dec 2020 18:57:14 +0100 To: freebsd-hackers@freebsd.org From: CerebrosuS Subject: Project information - SMBv2+ Message-ID: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> Date: Wed, 30 Dec 2020 18:57:14 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:7QNtvWE3eEQ1jvgz96U4MvmWIitSPSSkgXl+sIRz9V6t3IROBsV swpDbg+sbqUvHJm+9w5dmUvuryTrPJrSfiXCQRLiYyp52KUsGzKcBvHet1r8M4o8pMB6q07 dQRahnE96Sz/nhvjLwRLsWWB3rQU1EA5D6iiZs8C8vrDgCzbEm1eOWIOq9RbfnBPpvWpn3Q v5RMZfj50MkMFfeum/0Yg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:3CaCfc3cBx4=:W+31wsrvxQhoOuvJGEbri5 UjVrm6TZDVWGVIVBDAly/YOigf9Op2wO8b3FO0RVrikYjiHY+BBZhVQGuH9rursqagMtebWDc BtkU9jSl7NXyxDpgoD26NEzEg0MhWMy5PVLeuPUwN25VTYDSRO3OnCkTXdQOT7GE0CBomEj9Q RMBk/WoZY7fQ93bw5Cp+yU3riMmO7Lu2QVJ8IS9f94NdlhkIMaEv01AcnehvPQEFTAlJejXqE zbyKJ/pKQIbF5MSFCE8x2+jMV9XvwFLo3zZ58oNKFHd8UTvEulbfyMcMDx6nR745MY1S5zuIW B4XZaTtLiBPUEsAei9jGsiTalj0pE6vuWBbeAPZIOfxTXyc4zzkvGFVtH+pxVsdqARZLRstYW axI9PSj/diDlt73zP0l3ABVkqFbW70OLkuw/H1qAhDaLYU5S34pP7ffE68izK1nRgtmMwFwPu duASiGVzl6L6KbnI1PWbxTTNs1wajpSpDSkYg2n0YuIF7LUnpwNMZ7AizxaFXqCIDcPo09/uG dbqwpjWLQHky0j3u7p0fQWsqJdpVRJ9R+xViIcEP+IH84tLG1ind3HRycyGv9YmgDoLE/z0wq XiuGNauU4k8VZxEuqqIJg9j/Ly1gzAx6BTrxkCDHHtXM8SX4lEnOpO6gMqb2esi32JOYylVMw PfxqkF4Xq79A7iMZgUPYvAzQt6oJ+dyvtoN1mIKWkgW/8qqJ9eomjcn7eQ1AtpMjumur9Sjq1 Yf3uOW6q2HFC33YIQ6TOP6EDakTpJnN87W4ON+kamJGbWAOiUHNbYSB7/Sd3GHSO+BqHvL7Dx W9+PgfxbHAIRle2iGJPsxiftj6yXbtEQYSyKs+0P8pKPEvEmAasBfHmSAlrm/r1gn25xhR9i8 QdiXU50FibzhpQqrtMjQ== X-Rspamd-Queue-Id: 4D5fBN4XSkz4RcK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=Ux8J/LIZ; dmarc=pass (policy=none) header.from=gmx.net; spf=pass (mx1.freebsd.org: domain of CerebrosuS@gmx.net designates 212.227.15.18 as permitted sender) smtp.mailfrom=CerebrosuS@gmx.net X-Spamd-Result: default: False [-4.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25:c]; FREEMAIL_FROM(0.00)[gmx.net]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; DMARC_POLICY_ALLOW(-0.50)[gmx.net,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.18:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmx.net]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.15.18:from]; DWL_DNSWL_NONE(0.00)[gmx.net:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RECEIVED_SPAMHAUS_PBL(0.00)[87.122.30.127:received]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[212.227.15.18:from:127.0.2.255]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.18:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 17:57:17 -0000 Hello at all, the community and developer at FreeBSD seem to know, that SMBv1 for clients is nearly over and that the included mount_smbfs doesn't support newer versions. So good, so far... So I can find multiple information about the situation, but no clear path on how FreeBSD community and developer will go on to solve this missing function. (Just got the information on: https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSambaClie= nt) This is what I am asking: - Is there a project existing for solving this problem (with whatever target)? - What is the way to go in future? Extend mount_smbfs or support the fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and laggy here)? - Who is mainly working on it, if a project already exist? I'am just interested, cause of not finding such information clearly. Is there maybe a general project management list / team to see what projects are going on in whatever state? I am a hobby developer mainly coming from chemical engineering side, having some time to help. I've already written some cross platform software but never related to network or on os-level. So I am motivated to invest some time in getting stuff into FreeBSD, but for me, there is a lack on information (see above). Thank you in advance for information and help. =2D- Mit freundlichen Gr=C3=BC=C3=9Fen / Best regards Christian Kr From owner-freebsd-hackers@freebsd.org Wed Dec 30 18:03:42 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 DC40B4CA477 for ; Wed, 30 Dec 2020 18:03:42 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) (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 4D5fKp1sXHz4SSF; Wed, 30 Dec 2020 18:03:42 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 60EC2EB2A5; Wed, 30 Dec 2020 10:03:39 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 10:03:39 -0800 From: Neel Chauhan To: Mark Johnston Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL In-Reply-To: References: <44528336fa9168966d121bf771e1e229@neelc.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <3c9ff844e527daacd04c51f48836b57d@neelc.org> X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5fKp1sXHz4SSF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 2001:19f0:8001:fed:5400:2ff:fe73:c622 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+a]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_SHORT(-1.00)[-0.997]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 18:03:42 -0000 Thank you so much! Adding a rman_fini() call made my system boot. I get stuck at a "Cannot allocate dinfo!" error now (I can't see the SSD), but I will debug first before coming back. -Neel On 2020-12-30 09:06, Mark Johnston wrote: > On Wed, Dec 30, 2020 at 08:43:17AM -0800, Neel Chauhan wrote: >> Hi all, >> >> I'm writing a patch to support the VMD subsystem in Intel TigerLake >> systems such as the HP Spectre x360 13t-aw200. VMD is needed for NVMe >> here. >> >> The patch is as follows >> >> --- a/sys/dev/vmd/vmd.c >> +++ b/sys/dev/vmd/vmd.c >> @@ -66,13 +66,20 @@ struct vmd_type { >> #define INTEL_VENDOR_ID 0x8086 >> #define INTEL_DEVICE_ID_VMD 0x201d >> #define INTEL_DEVICE_ID_VMD2 0x28c0 >> +#define INTEL_DEVICE_ID_VMD3 0x9a0b >> >> static struct vmd_type vmd_devs[] = { >> { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume >> Management Device" }, >> { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume >> Management Device" }, >> + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume >> Management Device" }, >> { 0, 0, NULL } >> >> However, when I use the patch, I get a kernel panic related to PCI: >> https://imgur.com/a/XUQksOi (sorry for the image) >> >> It gives me the Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL >> error. >> >> Could you please help me figure out why it's panicking? > > Based on the backtrace, we are panicking in rman_init() because the > global rman_head list is corrupted (the panic message is basically > stating that the next element of the last element of the list is not > NULL). This suggests that the item was freed without removing it from > the list, i.e., an rman_fini() call is missing. > > vmd_attach() creates a resource container with rman_init(). If > vmd_attach() fails for some reason, it calls vmd_free(), which is > supposed to roll back anything done by vmd_attach(). Note that if > attach is successful, the driver subsystem may later call vmd_detach() > to deinitialize the driver, and vmd_detach() does a bit of extra work > in > addition to calling vmd_free()... > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed Dec 30 18:38:37 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 C1D394CB94D for ; Wed, 30 Dec 2020 18:38:37 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (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 4D5g650J7yz4VmL for ; Wed, 30 Dec 2020 18:38:36 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lf1-f42.google.com with SMTP id o13so39536268lfr.3 for ; Wed, 30 Dec 2020 10:38:36 -0800 (PST) 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=PaiP995gNiPuUp8G5e5otSFe0dRfc3pcjW33nfJDf9k=; b=DQsn4r/SCkq2exzk8XKd4nTtb/EzADnEktGmdxgwBusaZ10E5/PPWl3j5MWEF58QJp /iAT7sxUljquRL3LTbcg8MzKDrdP8ZrhiCSOpAaOHIEdSLEKpKf0r6loKUexdL0X/kON opH9rjAXymI/sq5x70KQEeJlZ1QtqDj4mDqoNgmOlewhB3N8LQz+t1HIbRTe2isw4eEP E2gsNERgYmYCLf93otAu647CgiWxI4I1PIufGyByptdWIiyN5rbnN9Lhz5KluUvye2Dx 7OppucaLAr0QqUhVshpiWsWc3DZItmnKI1DSXpKrrqrn3fo3x3rnIVA29eBJfguBwk1v nDRw== X-Gm-Message-State: AOAM530sKqYG5ul1Iqf3BODA1T+kAZC2U2eylH4wRSS97RuwfKfd6WhA jotd4sqTGBzwhojW8ckJ0jrcEuOqmKkqrA== X-Google-Smtp-Source: ABdhPJxsw60UOQo4dkxRz6QZ6F9dMLmsaBnzzCpGocQ1ipTuiOm988UCUabiDsVC5hWmwKM8HpEH3g== X-Received: by 2002:ac2:5083:: with SMTP id f3mr24681289lfm.645.1609353515297; Wed, 30 Dec 2020 10:38:35 -0800 (PST) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id y13sm6013374lfg.189.2020.12.30.10.38.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 10:38:35 -0800 (PST) Received: by mail-lf1-f46.google.com with SMTP id o13so39536203lfr.3 for ; Wed, 30 Dec 2020 10:38:35 -0800 (PST) X-Received: by 2002:a05:651c:1355:: with SMTP id j21mr24776425ljb.441.1609353514946; Wed, 30 Dec 2020 10:38:34 -0800 (PST) MIME-Version: 1.0 References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> In-Reply-To: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> From: Gleb Popov Date: Wed, 30 Dec 2020 22:38:09 +0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Project information - SMBv2+ To: CerebrosuS Cc: freebsd-hackers X-Rspamd-Queue-Id: 4D5g650J7yz4VmL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmx.net]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.167.42:from]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.167.42:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.42:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.42:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 18:38:37 -0000 On Wed, Dec 30, 2020 at 9:57 PM CerebrosuS wrote: > Hello at all, > > the community and developer at FreeBSD seem to know, that SMBv1 for > clients is nearly over and that the included mount_smbfs doesn't support > newer versions. So good, so far... > > So I can find multiple information about the situation, but no clear > path on how FreeBSD community and developer will go on to solve this > missing function. (Just got the information on: > > https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSambaCli= ent > ) > > This is what I am asking: > - Is there a project existing for solving this problem (with whatever > target)? > - What is the way to go in future? Extend mount_smbfs or support the > fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and > laggy here)? > - Who is mainly working on it, if a project already exist? > > I'am just interested, cause of not finding such information clearly. Is > there maybe a general project management list / team to see what > projects are going on in whatever state? > > I am a hobby developer mainly coming from chemical engineering side, > having some time to help. I've already written some cross platform > software but never related to network or on os-level. So I am motivated > to invest some time in getting stuff into FreeBSD, but for me, there is > a lack on information (see above). > > Thank you in advance for information and help. > > -- > > Mit freundlichen Gr=C3=BC=C3=9Fen / Best regards > Christian Kr > _______________________________________________ > 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= " > Relevant thread: https://lists.freebsd.org/pipermail/freebsd-current/2016-March/060014.html From owner-freebsd-hackers@freebsd.org Wed Dec 30 19:05:33 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 EF6CB4CC578 for ; Wed, 30 Dec 2020 19:05:33 +0000 (UTC) (envelope-from SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4D5gj902HHz4Y76 for ; Wed, 30 Dec 2020 19:05:32 +0000 (UTC) (envelope-from SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id DB75428411; Wed, 30 Dec 2020 20:05:24 +0100 (CET) Received: from illbsd.quip.test (ip-94-113-69-69.net.upcbroadband.cz [94.113.69.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 908E828416; Wed, 30 Dec 2020 20:05:23 +0100 (CET) Subject: Re: Project information - SMBv2+ To: CerebrosuS , freebsd-hackers@freebsd.org References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Wed, 30 Dec 2020 20:05:22 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5gj902HHz4Y76 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmx.net,freebsd.org]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[94.113.69.69:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.124.105.4:from]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[94.124.105.4:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 19:05:34 -0000 On 30/12/2020 18:57, CerebrosuS wrote: > Hello at all, > > the community and developer at FreeBSD seem to know, that SMBv1 for > clients is nearly over and that the included mount_smbfs doesn't support > newer versions. So good, so far... > > So I can find multiple information about the situation, but no clear > path on how FreeBSD community and developer will go on to solve this > missing function. (Just got the information on: > https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSambaClient) > > > This is what I am asking: > - Is there a project existing for solving this problem (with whatever > target)? > - What is the way to go in future? Extend mount_smbfs or support the > fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and > laggy here)? > - Who is mainly working on it, if a project already exist? > > I'am just interested, cause of not finding such information clearly. Is > there maybe a general project management list / team to see what > projects are going on in whatever state? > > I am a hobby developer mainly coming from chemical engineering side, > having some time to help. I've already written some cross platform > software but never related to network or on os-level. So I am motivated > to invest some time in getting stuff into FreeBSD, but for me, there is > a lack on information (see above). > > Thank you in advance for information and help. I was involved in the thread linked by Gleb. AFAIK nothing changed from that time. I tried something from ports but it has more problems (shares cannot be mounted on boot like mount_smbfs does). If somebody has time and skills to try to bring SMBv2 or v3 to FreeBSD then Apple or Solaris sources is good start. The both were using the same mount_smbfs (v1) as FreeBSD so one can check their sources and see how they evolve to v2 / v3. But it is out of my skill. I am not developer. I am just an extensive user of SMB mounted shares from Windows servers. Kind regards Miroslav Lachman From owner-freebsd-hackers@freebsd.org Wed Dec 30 19:24: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 D05C04CD0F9 for ; Wed, 30 Dec 2020 19:24:35 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5h764NW3z4Z1L for ; Wed, 30 Dec 2020 19:24:34 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609356272; bh=qj7/NhofgfQoKW8pqDKFCkqfXn+2rtqIwd+GkOFBRak=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=QM5H5Lc5iAksdgXfuA4BsfsRRAH8ren1xR17HXLP0WdEX+CVQ8/wcEl4x5fQBDf5Y qwYIoZ3436zjRUKfzXQuaf2mgHxtfM38Kh8j9cOCGQgqr3/U2/R4Hb15xTjNvPpuTd Uej987dlxEvYBbWK6XHgAL0jTz6+cz3hptArN2JA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [2.2.3.2] ([87.122.30.127]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M9o1v-1kyFr83uDd-005nhu; Wed, 30 Dec 2020 20:24:31 +0100 Subject: Re: Project information - SMBv2+ To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-hackers@freebsd.org References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> From: CerebrosuS Message-ID: <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> Date: Wed, 30 Dec 2020 20:24:31 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:qm3d1f5qMYN2bufE4gGu2uLL22qfBSflztHGJ/NJ3ntDh+AdOA5 Scuf65rsjc89Jpi8xmlq/NJGYXUsJV0LT+zH9fkOqxOIjmbyp4x429cocYX2gURIS9m1tnn Z/krTgP92YhUUqb9H7IPhobQa75UEgehsil4Qd+BZ/vv7AsiLT/OklE5FeuoUgliYoB+5Ro cTNZ21IPQGRG2FvQ+hOVg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:4icGr1aCNBE=:7k88lggwNGrmySFBuCuusZ nV+XAxkg7MoHZkXIlLDbt8vhuFWo2uAkoaB31iFLIWFcgkASMAy824uUASqxlYpR4Qbo6o31h zeui7k43tVnGaYbBRegDgSmtF+mlY1SjPw7HY9ftBfF6/jIfeP64puCjgOs0CZzblaQCZMw06 D5tx8xBWaMyVO4kU7MLbBbJCcCWmhua9ioh36/r/d8l1WEVLkqX8RZrK62XHBcgT77ij/QWSd 1WUgHoUq7qNjT6z8dQkotUsrQm0eUF575xzMjxP2JOn8fLOS3Hvsa2aMlZQuAKaohLWP0qBw0 xzVToqlXoWVNGLadTPQOAbw869JOeJjBVI0gYOX254AddkeCfEbZwKjQCJZPusXiwj4KX0/I+ ocIh0Z4v7SRLKKM7GZCkzW0zw3t1gY1ckVvLAWkb9R9gxvZRTm7YQDjY6DbEEWZs++o8VoNP1 1/oPKdUf+7N6M0RtvdM1r3coZMbpEV/opcVlPSGyD1ACZIALzeWrQkhSgXuGLGG2BStAL5BnJ nAIXSIZElm4xyW0OQZpYw9+8Tsn6Wucp/nWIFsYtXYon/gj7zJhv57S/BK/HA8K+8tIjs2SWD ntzkjru4y6SQUO0+YmmraG3L3jCvOdU29SNyYDm2hQrdrlZS2lVwkKC9mnmM8p2JTP191g6hM JdsipeuBJh4ufDVa78qWeijJQl7hWJXY6Z9IKdJXOh6BSiTcSkDnZra9ZXx2EY+9xM19Kcj+1 aFyPN2Zk8eL7DEqKc7+SFA87xJftuJxF+CEF9sblsS815sVV5lsTnrpaZzvNw4tUdV5BV+yNx h9EaU590h/nQ47xpEM5xuqQzRjLvsAi4kK5SgZKGelxJDrOA3god1GBn6BBdqacAa8NvrSaZd lCmbajkfi9fIugazBGVw== X-Rspamd-Queue-Id: 4D5h764NW3z4Z1L X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=QM5H5Lc5; dmarc=pass (policy=none) header.from=gmx.net; spf=pass (mx1.freebsd.org: domain of CerebrosuS@gmx.net designates 212.227.15.19 as permitted sender) smtp.mailfrom=CerebrosuS@gmx.net X-Spamd-Result: default: False [-4.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmx.net]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; DKIM_TRACE(0.00)[gmx.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmx.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmx.net]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.15.19:from]; DWL_DNSWL_NONE(0.00)[gmx.net:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RECEIVED_SPAMHAUS_PBL(0.00)[87.122.30.127:received]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[212.227.15.19:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.19:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 19:24:35 -0000 Am 30.12.20 um 20:05 schrieb Miroslav Lachman: > On 30/12/2020 18:57, CerebrosuS wrote: >> Hello at all, >> >> the community and developer at FreeBSD seem to know, that SMBv1 for >> clients is nearly over and that the included mount_smbfs doesn't suppor= t >> newer versions. So good, so far... >> >> So I can find multiple information about the situation, but no clear >> path on how FreeBSD community and developer will go on to solve this >> missing function. (Just got the information on: >> https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSambaC= lient) >> >> >> This is what I am asking: >> - Is there a project existing for solving this problem (with whatever >> target)? >> - What is the way to go in future? Extend mount_smbfs or support the >> fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and >> laggy here)? >> - Who is mainly working on it, if a project already exist? >> >> I'am just interested, cause of not finding such information clearly. Is >> there maybe a general project management list / team to see what >> projects are going on in whatever state? >> >> I am a hobby developer mainly coming from chemical engineering side, >> having some time to help. I've already written some cross platform >> software but never related to network or on os-level. So I am motivated >> to invest some time in getting stuff into FreeBSD, but for me, there is >> a lack on information (see above). >> >> Thank you in advance for information and help. > > I was involved in the thread linked by Gleb. AFAIK nothing changed from > that time. I tried something from ports but it has more problems (shares > cannot be mounted on boot like mount_smbfs does). > If somebody has time and skills to try to bring SMBv2 or v3 to FreeBSD > then Apple or Solaris sources is good start. The both were using the > same mount_smbfs (v1) as FreeBSD so one can check their sources and see > how they evolve to v2 / v3. They are both using exactly the same source code as a starting point and extend it (or rewrite it) to SMBv2? > But it is out of my skill. I am not > developer. I am just an extensive user of SMB mounted shares from > Windows servers. That might also be my problem, cause I've never written an application for network nor anything related to FreeBSD on os-level. But if no one starts, nothing might change at all. > > Kind regards > Miroslav Lachman > From owner-freebsd-hackers@freebsd.org Wed Dec 30 20:34: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 CBCDF4CE88A for ; Wed, 30 Dec 2020 20:34:18 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5jgZ5R1wz4dh0 for ; Wed, 30 Dec 2020 20:34:18 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1609360458; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=th3eNMxG5yMxdoqpR0zyTd/d6i6f9W9Oo56kvL6Y1s8=; b=FgLonHxAkVCweuxBKM7g62DmtiQ8YrcJKHV1C0P4J8M22rjqS+ir1Nj30CpqqdOqlig3eU tf3Z40igwxGmiiYrEW2cx7rE05vdXGYayKdXCwSzCy0fciO2oaRsYJyQGn4M1H8xVK7S0V XnzBvaMHKiAF6uEI8/Q1NXp1p8IXs0kcYW6FLijVpnbefx4STTaPcMmyEvUf08MSJRPGTj fYSvS1xp33N12HG7zTIZPM2239wgKbJre5BZlMX+WHYEyIMoghwxcj7ovlkyqgvfiJlaE4 mWrglmPvfreCgwFS+S3GKHtFILALiXH67Jq3wwuOwt2CoQFq1VzQjjH7gecpHg== Received: by freefall.freebsd.org (Postfix, from userid 1471) id ABAD61EBEB; Wed, 30 Dec 2020 20:34:18 +0000 (UTC) Date: Wed, 30 Dec 2020 21:34:16 +0100 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: Project information - SMBv2+ Message-ID: <20201230203416.xr42tsdo2m7txex7@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i6zsmpbkywmh6xoh" Content-Disposition: inline In-Reply-To: <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1609360458; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=th3eNMxG5yMxdoqpR0zyTd/d6i6f9W9Oo56kvL6Y1s8=; b=K3zLxXa7cwDUxrZvHffOqs8/G5/OcgW4tHU5aWyjq0TEaOaoo1ZR0ZPU63CwzK1GcAglbu tE9ZioorYkzG6EIj9XvK/uEvyuEEBLFK6pmILgWSvdftbXfQA60XbID6qXeRIawPQuuPZF EQREE1EDcBn4yQ+0KSH9MeRjS7S9RCdRMQ2hMtoh3aFUcSdZeCO73u6BPuFzKR2SR+f+Vn diXWkuK9b5uHqRSq08Iz51M1Ro2bjP/6NyLkdocp0rJaXkKD60yzfUcksq1d8y+bCQ+Jpz 0sDQqfHvcMQBlP8yIeNeH0PEQ7LXKMwjNDnebp74xq1u2EoXFhZy5zBXRN06Og== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1609360458; a=rsa-sha256; cv=none; b=sMCFkXX7S4DzXEo6nTfVGyVKtzAXNbE9EO29iXlLXNUTxy3K7I7mTTtR8P4DUYN8RJR2Fe G9yRX87C5Lvv6DuaYPLakmR7OXKu1YNbNFWPap5MFdKOT+IA6ogISQhLKTb3JnG3D7TN3J r6qGv0oymV14OilVmx9EpvriQjNTJK/3QiGynXZ/52qGn8oTsXIrstsfpeZoq/7+zG83Dv DOE9kNP4TvlSam8o5C+akfq2fBNzBBziLqQixHhWpT3quC7X1zJpd6vrbyP8BkMWwMTxWl eYsm8jjVCqD86DVK+NFcsGJUS50c0xELOwZ/30P2ZRYZaCIl6tgP+VKl3KkdoA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 20:34:18 -0000 --i6zsmpbkywmh6xoh Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 30, 2020 at 08:24:31PM +0100, CerebrosuS wrote: > > >Am 30.12.20 um 20:05 schrieb Miroslav Lachman: >>On 30/12/2020 18:57, CerebrosuS wrote: >>>Hello at all, >>> >>>the community and developer at FreeBSD seem to know, that SMBv1 for >>>clients is nearly over and that the included mount_smbfs doesn't support >>>newer versions. So good, so far... >>> >>>So I can find multiple information about the situation, but no clear >>>path on how FreeBSD community and developer will go on to solve this >>>missing function. (Just got the information on: >>>https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSambaCl= ient) >>> >>> >>>This is what I am asking: >>>- Is there a project existing for solving this problem (with whatever >>>target)? >>>- What is the way to go in future? Extend mount_smbfs or support the >>>fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and >>>laggy here)? >>>- Who is mainly working on it, if a project already exist? >>> >>>I'am just interested, cause of not finding such information clearly. Is >>>there maybe a general project management list / team to see what >>>projects are going on in whatever state? >>> >>>I am a hobby developer mainly coming from chemical engineering side, >>>having some time to help. I've already written some cross platform >>>software but never related to network or on os-level. So I am motivated >>>to invest some time in getting stuff into FreeBSD, but for me, there is >>>a lack on information (see above). >>> >>>Thank you in advance for information and help. >> >>I was involved in the thread linked by Gleb. AFAIK nothing changed from >>that time. I tried something from ports but it has more problems (shares >>cannot be mounted on boot like mount_smbfs does). >>If somebody has time and skills to try to bring SMBv2 or v3 to FreeBSD >>then Apple or Solaris sources is good start. The both were using the >>same mount_smbfs (v1) as FreeBSD so one can check their sources and see >>how they evolve to v2 / v3. > >They are both using exactly the same source code as a starting point and >extend it (or rewrite it) to SMBv2? > >>But it is out of my skill. I am not >>developer. I am just an extensive user of SMB mounted shares from >>Windows servers. >That might also be my problem, cause I've never written an application >for network nor anything related to FreeBSD on os-level. But if no one >starts, nothing might change at all. > >> >>Kind regards >>Miroslav Lachman >> >_______________________________________________ >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" Hi folks, Justin T Gibbs, during one of the Office Hours meetings that have been happ= ening=20 throughout the year, spoke at some length on the subject of SMBv3 as it rel= ates=20 to integraetion in the base system [1] - and suffice it to say, it's not ne= arly=20 as simple as some people seem to asume that it is. I hope that's somewhat helpful, and it's at least a little newer than what'= s=20 referenced elsewhere. [1]: https://www.youtube.com/watch?v=3DJi4ux4FWpRU&t=3D970 --i6zsmpbkywmh6xoh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl/s5EhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87rrZgf9FgJMC9miiYg/SGWx9ByL+lvGMuDHyPuY2BUFpmSAaLGUbMnt/muYyCWU 5haVomFB/49SuVmKlOG0HLmHXhCK0nCPpzkVPH5cRJZZOXK8Nub4XnnKH+He+ttH OCd2sj50Xg8xECjpmdgsr1ZdwiTGwnYwmzLPFf0k76YJfoE7/tJPsk8w6oey1rfA CeLHCyLJnV4uZWtQunnd1P18bxVusabIH83ZWOgPLTdooFbTn6Qq7hZ9eKU7iUwH xggU5EAjExS1U/+5Sqi5cNAjTisRE1aS5Rc/JpfT6cZRqCdYOdJvbF1VX4pHNd3U PdSBDUmJpPb8lIYpGdCGChwqdi15vg== =eOgT -----END PGP SIGNATURE----- --i6zsmpbkywmh6xoh-- From owner-freebsd-hackers@freebsd.org Wed Dec 30 20:44:34 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 B87624CEB90 for ; Wed, 30 Dec 2020 20:44:34 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5jvP4ZGsz4dxK; Wed, 30 Dec 2020 20:44:33 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609361071; bh=O5H96av3W2jGlePW4YWzG2JeitVlucPxVd42a1RBsJQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=ORjvJtn73i7QG51JwBZe1CIwhMMAxKPBMIEhX4uX+vMg9cyzlbwFpsdUH6fQADVzQ YIH+Ki4SW5DGnKosbMFS7vt/WL4WIiZUbS3EV4BbhR7IcM3QtmdqMGXdDieCVc5NPS SlbIPuhKzWYla9GANC8d3tRBNwtKko3y7nLn1Gbs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [2.2.3.2] ([87.122.30.127]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M4b1o-1ku9ph37zy-001iU9; Wed, 30 Dec 2020 21:44:31 +0100 Subject: Re: Project information - SMBv2+ To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> <20201230203416.xr42tsdo2m7txex7@nerd-thinkpad.local> From: CerebrosuS Message-ID: <8758d2d0-12e9-77bb-e417-4bac430b4e9a@gmx.net> Date: Wed, 30 Dec 2020 21:44:31 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20201230203416.xr42tsdo2m7txex7@nerd-thinkpad.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:EFyfUtsYCDwgD4AL0x6d//HucWEj1P4hbBCk1GpHlQPazgjE0K/ xTk+ksDys+4N6P5GWNddz66DUsGfMfsv7jnoKFhk+gPq15o5renUhq6GMEM5dAzhBOsXGd5 Vw8wLRwJ67JheIUo/bmX3gj17vI00pdtcOS36Ui26TO/V87BqQH1l4JajJbmv8xWZRpJ+Z3 dpBsCwrt2k4H5+JnkoS+g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:TgyB61tqJZM=:uowhy+dlBslpliifvuF9NU sn7ima+rBy3Wu1o1FtjKgGEdhA8evZY2IyDmUEdLcNZc3HIpXe4DkGrWaQWlWoDCXgeQBqOxu DX/k5clssep/QIFC6FB5XzCu/dgOYh6L1lFma4LtwN1MSG3BxvwMQkgTqaXRl45A613PsI9i/ balEM3YQD377GyDKpbjL/5XhCWxO62wviCPJ2oh8cMAF8RDKBQtf6WCibIQWyg2LTBtiTNYj7 tyhT6pE6N+2Gj6JnaV8O9bl5NdL4vnKa+jRexQTIIUTAy8xHvWkrMtZbL3UUd7GhzVDbe+al7 q0zZukF2wY5GaNgozar3+FINQ35yHjoH1kCVOkKSrVj90mk5qXpgGkodDvuD82yeNnN8GbmWY 5OmiZLzr+pj8kAOHHQtAZt5E2+bHj5ZC1EJupV3hPfBIyZrq8QHAbdu7SPe5Q8pX0LfiXlZS0 Zi0nUu9g1DIJNHaHucTSeBV4WtoqGYo9KsYT1TV8wtEDzw2c2DPqUPkicZpCNCJmP/reni2nJ sFdwyEtFdSlkKuK209HcobOZWcHQSl0fCDBbJJw311NiUmSZUvyenkdoaDBxcc3gn7UHexRXB oNhjOAh6gFMtLaw6lC92S/iGLR4mxVBxKrLf9UcdvsbRcHuJm6wXfuLqShLEEs5wyI3N44Vq8 BBx+UdHdGDB3jno5AVUkpZ4/K1bevM0wFjFJmEvG5A9UboIVWTufDY83zSky340LSqfuB7ThR eZOL5fmIryRua7U9E9Y56lE5w796rnVNW6YUvZxy6U9YN+9bwDgBonF4WezQGnWnBt2z3Rn7e ZQRyENYK5Dk0g00X4czw/zLr1DCJSCT/BkOe6gSNf1AtQC4cFmEDYBF2VUvx5qyjleTxPDu0r D0BZq3WDzmerzKMyMMvA== X-Rspamd-Queue-Id: 4D5jvP4ZGsz4dxK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=ORjvJtn7; dmarc=pass (policy=none) header.from=gmx.net; spf=pass (mx1.freebsd.org: domain of CerebrosuS@gmx.net designates 212.227.15.15 as permitted sender) smtp.mailfrom=CerebrosuS@gmx.net X-Spamd-Result: default: False [-4.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmx.net]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; DKIM_TRACE(0.00)[gmx.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmx.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.15:from]; FROM_EQ_ENVFROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.15.15:from]; FREEMAIL_ENVFROM(0.00)[gmx.net]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RECEIVED_SPAMHAUS_PBL(0.00)[87.122.30.127:received]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmx.net:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; SPAMHAUS_ZRD(0.00)[212.227.15.15:from:127.0.2.255]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.15:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 20:44:34 -0000 Yes, the video is part of the wiki.freebsd.org entry I've written down. The information in the video is a little bit unmotivated and I am aware that it is not that simple. That video leads me to the question here, if anyone is working on it. Cause Mr. Gibbs talks about it like he already started something in this direction and is already into it (or he just knows). :-) Yet, I will start by looking into the FreeBSD mount_smbfs code and the one from apple. Am 30.12.20 um 21:34 schrieb Daniel Ebdrup Jensen: > On Wed, Dec 30, 2020 at 08:24:31PM +0100, CerebrosuS wrote: >> >> >> Am 30.12.20 um 20:05 schrieb Miroslav Lachman: >>> On 30/12/2020 18:57, CerebrosuS wrote: >>>> Hello at all, >>>> >>>> the community and developer at FreeBSD seem to know, that SMBv1 for >>>> clients is nearly over and that the included mount_smbfs doesn't >>>> support >>>> newer versions. So good, so far... >>>> >>>> So I can find multiple information about the situation, but no clear >>>> path on how FreeBSD community and developer will go on to solve this >>>> missing function. (Just got the information on: >>>> https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSamb= aClient) >>>> >>>> >>>> >>>> This is what I am asking: >>>> - Is there a project existing for solving this problem (with whatever >>>> target)? >>>> - What is the way to go in future? Extend mount_smbfs or support the >>>> fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and >>>> laggy here)? >>>> - Who is mainly working on it, if a project already exist? >>>> >>>> I'am just interested, cause of not finding such information clearly. = Is >>>> there maybe a general project management list / team to see what >>>> projects are going on in whatever state? >>>> >>>> I am a hobby developer mainly coming from chemical engineering side, >>>> having some time to help. I've already written some cross platform >>>> software but never related to network or on os-level. So I am motivat= ed >>>> to invest some time in getting stuff into FreeBSD, but for me, there = is >>>> a lack on information (see above). >>>> >>>> Thank you in advance for information and help. >>> >>> I was involved in the thread linked by Gleb. AFAIK nothing changed fro= m >>> that time. I tried something from ports but it has more problems (shar= es >>> cannot be mounted on boot like mount_smbfs does). >>> If somebody has time and skills to try to bring SMBv2 or v3 to FreeBSD >>> then Apple or Solaris sources is good start. The both were using the >>> same mount_smbfs (v1) as FreeBSD so one can check their sources and se= e >>> how they evolve to v2 / v3. >> >> They are both using exactly the same source code as a starting point an= d >> extend it (or rewrite it) to SMBv2? >> >>> But it is out of my skill. I am not >>> developer. I am just an extensive user of SMB mounted shares from >>> Windows servers. >> That might also be my problem, cause I've never written an application >> for network nor anything related to FreeBSD on os-level. But if no one >> starts, nothing might change at all. >> >>> >>> Kind regards >>> Miroslav Lachman >>> >> _______________________________________________ >> 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" > > Hi folks, > > Justin T Gibbs, during one of the Office Hours meetings that have been > happening throughout the year, spoke at some length on the subject of > SMBv3 as it relates to integraetion in the base system [1] - and suffice > it to say, it's not nearly as simple as some people seem to asume that > it is. > > I hope that's somewhat helpful, and it's at least a little newer than > what's referenced elsewhere. > > [1]: https://www.youtube.com/watch?v=3DJi4ux4FWpRU&t=3D970 From owner-freebsd-hackers@freebsd.org Wed Dec 30 21:16:50 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 7E57F4CF516 for ; Wed, 30 Dec 2020 21:16:50 +0000 (UTC) (envelope-from SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4D5kcd3cGwz4gLF for ; Wed, 30 Dec 2020 21:16:49 +0000 (UTC) (envelope-from SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 5214328416; Wed, 30 Dec 2020 22:16:47 +0100 (CET) Received: from illbsd.quip.test (ip-94-113-69-69.net.upcbroadband.cz [94.113.69.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CF33A28411; Wed, 30 Dec 2020 22:16:45 +0100 (CET) Subject: Re: Project information - SMBv2+ To: CerebrosuS , freebsd-hackers@freebsd.org References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <704a700c-32ff-66eb-6711-5d75099abcd4@quip.cz> Date: Wed, 30 Dec 2020 22:16:44 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5kcd3cGwz4gLF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [0.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmx.net,freebsd.org]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[94.113.69.69:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.124.105.4:from]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[94.124.105.4:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 21:16:50 -0000 On 30/12/2020 20:24, CerebrosuS wrote: > > > Am 30.12.20 um 20:05 schrieb Miroslav Lachman: >> On 30/12/2020 18:57, CerebrosuS wrote: >>> Hello at all, >>> >>> the community and developer at FreeBSD seem to know, that SMBv1 for >>> clients is nearly over and that the included mount_smbfs doesn't support >>> newer versions. So good, so far... >>> >>> So I can find multiple information about the situation, but no clear >>> path on how FreeBSD community and developer will go on to solve this >>> missing function. (Just got the information on: >>> https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSambaClient) >>> >>> >>> >>> This is what I am asking: >>> - Is there a project existing for solving this problem (with whatever >>> target)? >>> - What is the way to go in future? Extend mount_smbfs or support the >>> fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and >>> laggy here)? >>> - Who is mainly working on it, if a project already exist? >>> >>> I'am just interested, cause of not finding such information clearly. Is >>> there maybe a general project management list / team to see what >>> projects are going on in whatever state? >>> >>> I am a hobby developer mainly coming from chemical engineering side, >>> having some time to help. I've already written some cross platform >>> software but never related to network or on os-level. So I am motivated >>> to invest some time in getting stuff into FreeBSD, but for me, there is >>> a lack on information (see above). >>> >>> Thank you in advance for information and help. >> >> I was involved in the thread linked by Gleb. AFAIK nothing changed from >> that time. I tried something from ports but it has more problems (shares >> cannot be mounted on boot like mount_smbfs does). >> If somebody has time and skills to try to bring SMBv2 or v3 to FreeBSD >> then Apple or Solaris sources is good start. The both were using the >> same mount_smbfs (v1) as FreeBSD so one can check their sources and see >> how they evolve to v2 / v3. > > They are both using exactly the same source code as a starting point and > extend it (or rewrite it) to SMBv2? They are based on the ported code. Apple Mac OS X and Solaris have different kernel so they needed modified port of the same code as was in FreeBSD back in the days (there is the same copyright header). Apple sources or Solaris sources cannot be used directly on FreeBSD but some skilled developer can look in to those sources to see their evolution. But as was already noted v2 and v3 are very different from v1. It will be hard to port but not impossible. Current solutions in ports (fusefs) are almost useless in server environment. Miroslav Lachman From owner-freebsd-hackers@freebsd.org Wed Dec 30 22:33:23 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 7C0444D0EA9 for ; Wed, 30 Dec 2020 22:33:23 +0000 (UTC) (envelope-from chrisj@rtems.org) Received: from nsstlmta33p.bpe.bigpond.com (nsstlmta33p.bpe.bigpond.com [203.38.21.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5mJx31R1z4m9r for ; Wed, 30 Dec 2020 22:33:20 +0000 (UTC) (envelope-from chrisj@rtems.org) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep33p-svc.bpe.nexus.telstra.com.au with ESMTP id <20201230223315.PNJZ4353.nsstlfep33p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com> for ; Thu, 31 Dec 2020 09:33:15 +1100 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedrvddvgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvffttedpqfgfvfenuceurghilhhouhhtmecugedttdenucenucfjughrpefvhffuohfkffgfgggtgfesthejredttdefjeenucfhrhhomhepvehhrhhishculfhohhhnshcuoegthhhrihhsjhesrhhtvghmshdrohhrgheqnecuggftrfgrthhtvghrnheptdejtdetieeigfehhfehvdetueehtedtfedtudffueduvdelvdegkeelvdfghefhnecukfhppedufeelrddufedtrddvgeehrddvtddtpdeitddrvdefuddrfeejrdefleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehmrghilhdrtghonhhtvghmphhorhgrrhihrdhnvghtrdgruhdpihhnvghtpedufeelrddufedtrddvgeehrddvtddtpdhmrghilhhfrhhomhepoegthhhrihhsjhesrhhtvghmshdrohhrgheqpdhrtghpthhtohepoehfrhgvvggsshguqdhhrggtkhgvrhhssehfrhgvvggsshgurdhorhhgqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RG-VS-CLASS: clean Received: from mail.contemporary.net.au (139.130.245.200) by smtp.telstra.com (5.8.420) id 5FE6CD41013EB2A0 for freebsd-hackers@freebsd.org; Thu, 31 Dec 2020 09:33:15 +1100 Received: from [192.168.15.73] ([60.231.37.39]) (authenticated bits=0) by mail.contemporary.net.au (8.15.2/8.15.2) with ESMTPSA id 0BUMXCli064323 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 31 Dec 2020 09:33:12 +1100 (EST) (envelope-from chrisj@rtems.org) X-Authentication-Warning: corb.contemporary.net.au: Host [60.231.37.39] claimed to be [192.168.15.73] To: freebsd-hackers@freebsd.org From: Chris Johns Subject: sys/fs/nfsclient on RTEMS gets a bad seqid error with open Organization: https://www.rtems.org/ Message-ID: <447e4bfa-ebe3-62a3-26e4-c7f3108d5fa5@rtems.org> Date: Thu, 31 Dec 2020 09:33:07 +1100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-102.8 required=2.7 tests=ALL_TRUSTED, BAYES_00, TW_EQ, USER_IN_WELCOMELIST,USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on corb.contemporary.net.au X-Rspamd-Queue-Id: 4D5mJx31R1z4m9r X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of chrisj@rtems.org has no SPF policy when checking 203.38.21.33) smtp.mailfrom=chrisj@rtems.org X-Spamd-Result: default: False [-0.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCVD_IN_DNSWL_LOW(-0.10)[203.38.21.33:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[203.38.21.33:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:1221, ipnet:203.36.0.0/14, country:AU]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[203.38.21.33:from:127.0.2.255]; DMARC_NA(0.00)[rtems.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 22:33:23 -0000 Hello, I am porting the kernel's nfsclient file system to the RTEMS port of FreeBSD. I have ported across the FreeBSD file descriptors, VFS and NFS code. I have a custom pseudofs file system as my root file system and I can mount an NFSv4 mount exported from a FreeBSD 12 box. When I open a file there are a some getattr RPC calls that are successful however the open call (PUTFH, OPEN, GETATTR) results in the server returning the bas seqid (10026) error code for the OPEN and I am not sure why this is happening. I suspect I am missing a step in the nfsclient set up. Any hints or help would be most welcome. Thanks Chris From owner-freebsd-hackers@freebsd.org Wed Dec 30 22:36: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 D9BB54D1137 for ; Wed, 30 Dec 2020 22:36:59 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) (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 4D5mP66prnz4m64; Wed, 30 Dec 2020 22:36:58 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id DA57DEB2BD; Wed, 30 Dec 2020 14:36:54 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 14:36:54 -0800 From: Neel Chauhan To: Mark Johnston Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL In-Reply-To: <3c9ff844e527daacd04c51f48836b57d@neelc.org> References: <44528336fa9168966d121bf771e1e229@neelc.org> <3c9ff844e527daacd04c51f48836b57d@neelc.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5mP66prnz4m64 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 2001:19f0:8001:fed:5400:2ff:fe73:c622 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+a]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 22:36:59 -0000 Mark, thank you so much for your help! However, I am getting an issue with `pci_read_device()` where it returns a `vid` (PCI Vendor ID) of 0xffff. This ends up returning "Cannot allocate dinfo!" from vmd. Log (via grep): https://imgur.com/a/tAmmY7i What usually causes this? I'm no expert on PC hardware, my $DAYJOB is not related to hardware (I'm a C#/.NET developer for a living). I do however want my Spectre running FreeBSD and am willing to write patches (to some extent at least). -Neel On 2020-12-30 10:03, Neel Chauhan wrote: > Thank you so much! > > Adding a rman_fini() call made my system boot. > > I get stuck at a "Cannot allocate dinfo!" error now (I can't see the > SSD), but I will debug first before coming back. > > -Neel > > On 2020-12-30 09:06, Mark Johnston wrote: >> On Wed, Dec 30, 2020 at 08:43:17AM -0800, Neel Chauhan wrote: >>> Hi all, >>> >>> I'm writing a patch to support the VMD subsystem in Intel TigerLake >>> systems such as the HP Spectre x360 13t-aw200. VMD is needed for NVMe >>> here. >>> >>> The patch is as follows >>> >>> --- a/sys/dev/vmd/vmd.c >>> +++ b/sys/dev/vmd/vmd.c >>> @@ -66,13 +66,20 @@ struct vmd_type { >>> #define INTEL_VENDOR_ID 0x8086 >>> #define INTEL_DEVICE_ID_VMD 0x201d >>> #define INTEL_DEVICE_ID_VMD2 0x28c0 >>> +#define INTEL_DEVICE_ID_VMD3 0x9a0b >>> >>> static struct vmd_type vmd_devs[] = { >>> { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume >>> Management Device" }, >>> { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume >>> Management Device" }, >>> + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume >>> Management Device" }, >>> { 0, 0, NULL } >>> >>> However, when I use the patch, I get a kernel panic related to PCI: >>> https://imgur.com/a/XUQksOi (sorry for the image) >>> >>> It gives me the Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL >>> error. >>> >>> Could you please help me figure out why it's panicking? >> >> Based on the backtrace, we are panicking in rman_init() because the >> global rman_head list is corrupted (the panic message is basically >> stating that the next element of the last element of the list is not >> NULL). This suggests that the item was freed without removing it from >> the list, i.e., an rman_fini() call is missing. >> >> vmd_attach() creates a resource container with rman_init(). If >> vmd_attach() fails for some reason, it calls vmd_free(), which is >> supposed to roll back anything done by vmd_attach(). Note that if >> attach is successful, the driver subsystem may later call vmd_detach() >> to deinitialize the driver, and vmd_detach() does a bit of extra work >> in >> addition to calling vmd_free()... >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed Dec 30 22:56:26 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 19BC94D1DDE for ; Wed, 30 Dec 2020 22:56:26 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5mqZ0G6xz4p65 for ; Wed, 30 Dec 2020 22:56:26 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1609368986; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v0xtHQOnKRxVXFuoQ717gy8Pjscq4crRTgbr7ZMb57E=; b=OzruXIUX+O3ZHNLM7pjs4qp7qElizpBhElruYlnNhMB7d+OhtDQKb9grXdRA9AphS/fREb DaK3/gLEvsYem8nxN2kSJtn90pRcuG38cDToiItZMnOGI8/WGtdY/Cj/OMvC8tSxmaYRbv UvdaFQ+sZK7DQak3EMfUpJiyyXeVIHZFJXVHNjlefspWuQABIE+WZCVMGmeMbGYRvpiSej Zvco9lIrGQwtAuXLaqiCL70FhDFK9vvWdBaZM1UEJTF6Rm0dGai3Xmo2x037UqzViLHIem tu38gw5R9jRCfnDKbdnTT/r9zndtB3BBTdF2i7H6lwJeqbOQPmF3SuW8IH0I7A== Received: by freefall.freebsd.org (Postfix, from userid 1471) id EEE58FD6; Wed, 30 Dec 2020 22:56:25 +0000 (UTC) Date: Wed, 30 Dec 2020 23:56:24 +0100 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: Project information - SMBv2+ Message-ID: <20201230225624.atsnf6u5mmtcu5sw@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> <704a700c-32ff-66eb-6711-5d75099abcd4@quip.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x6ccdfbtybphjisq" Content-Disposition: inline In-Reply-To: <704a700c-32ff-66eb-6711-5d75099abcd4@quip.cz> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1609368986; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v0xtHQOnKRxVXFuoQ717gy8Pjscq4crRTgbr7ZMb57E=; b=mdfAvStUxDQqJ8ZqMvRHGzop0CCz8+cxXNq4r23x9OLcqhSfK3UH5+jzxmr+8UKbqr2egt teNsIn3EbKUTASBuTI4m2Fs5HqRoXgxvDATACvsRIMnR5b5Tp+UXEapmS3BFTEqx0RXuIH sLTMQD6mkPT6qofnIssXsnfhqAgdLzyImaX3LSKAP2yWKkHNSisVs05rlJIZA05l5C71OC R9Q4KhG3pbTpw7fodZf9Ghia4LMIovxkDzrkrEf7nHnrutkNJEsiANdTnxLOBl+NOc05j5 2RrhyWG9eY44pp1kEkbGcuhUnwIV/iejgokvG3Td/MDRJhwbu4/b+Z3sJkC/Dw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1609368986; a=rsa-sha256; cv=none; b=WdfUOUi9BecNUt7GA1qBEujJzJ3/1qgUvGHRbQCGID4265OvEA8MKIK1u3L2bTDDCJXqlG z+TPlxrvEb53S06fqviV0A3/QitOoF/Ge6joPgAM3V7WMfxjImfzqWPyATpqJtOVF7bcVM 76AJjzTkKAQGLpDmmZEZ8wyummocbqZ/FEyJnUAVob9e9v1oBqVmmBGka3fSLUfobzhXkV zIH0nr8EGqPewlSCYTEYdSqPdGR4+EcdzJl1k29gIhioUPl4BUs/TyZ0XiIHJNXi4bQUs3 BuTufLC8hB03tZQgsVgDb9KTYuH2i7j8n2CBsg7Ij40iSd8eJLHQyaT4hHYCww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 22:56:26 -0000 --x6ccdfbtybphjisq Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 30, 2020 at 10:16:44PM +0100, Miroslav Lachman wrote: >On 30/12/2020 20:24, CerebrosuS wrote: >> >> >>Am 30.12.20 um 20:05 schrieb Miroslav Lachman: >>>On 30/12/2020 18:57, CerebrosuS wrote: >>>>Hello at all, >>>> >>>>the community and developer at FreeBSD seem to know, that SMBv1 for >>>>clients is nearly over and that the included mount_smbfs doesn't support >>>>newer versions. So good, so far... >>>> >>>>So I can find multiple information about the situation, but no clear >>>>path on how FreeBSD community and developer will go on to solve this >>>>missing function. (Just got the information on: >>>>https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSambaC= lient) >>>> >>>> >>>> >>>>This is what I am asking: >>>>- Is there a project existing for solving this problem (with whatever >>>>target)? >>>>- What is the way to go in future? Extend mount_smbfs or support the >>>>fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and >>>>laggy here)? >>>>- Who is mainly working on it, if a project already exist? >>>> >>>>I'am just interested, cause of not finding such information clearly. Is >>>>there maybe a general project management list / team to see what >>>>projects are going on in whatever state? >>>> >>>>I am a hobby developer mainly coming from chemical engineering side, >>>>having some time to help. I've already written some cross platform >>>>software but never related to network or on os-level. So I am motivated >>>>to invest some time in getting stuff into FreeBSD, but for me, there is >>>>a lack on information (see above). >>>> >>>>Thank you in advance for information and help. >>> >>>I was involved in the thread linked by Gleb. AFAIK nothing changed from >>>that time. I tried something from ports but it has more problems (shares >>>cannot be mounted on boot like mount_smbfs does). >>>If somebody has time and skills to try to bring SMBv2 or v3 to FreeBSD >>>then Apple or Solaris sources is good start. The both were using the >>>same mount_smbfs (v1) as FreeBSD so one can check their sources and see >>>how they evolve to v2 / v3. >> >>They are both using exactly the same source code as a starting point and >>extend it (or rewrite it) to SMBv2? > >They are based on the ported code. Apple Mac OS X and Solaris have=20 >different kernel so they needed modified port of the same code as was=20 >in FreeBSD back in the days (there is the same copyright header).=20 >Apple sources or Solaris sources cannot be used directly on FreeBSD=20 >but some skilled developer can look in to those sources to see their=20 >evolution. But as was already noted v2 and v3 are very different from=20 >v1. It will be hard to port but not impossible. >Current solutions in ports (fusefs) are almost useless in server=20 >environment. > >Miroslav Lachman > >_______________________________________________ >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" Hi folks, Assuming that the reasons for not using fuse in a server environment are re= lated=20 primarily to performance and that the implementation that was in base used = to be=20 quite out-of-date, has this at all been reevalulated since a new version wa= s=20 merged? [1] Yours, Daniel Ebdrup Jensen [1]: https://svnweb.freebsd.org/changeset/base/350665 --x6ccdfbtybphjisq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl/tBZhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87oJLgf+PmTDrmRy0kGZLj3BQ8Kvg3QjSt7GY4FetyPW4t00u4KZ4G910lVC2Wnr L4/7VrLh1UwoHYPjeIDRZbR6A9uqBhhL2Fljjh0XzJGrt6WkQMgRZXyBXWa0XvyJ RsUSCaax33oZGGE/NjBm9yuXqCYNyK6hpVSH/bbjMlykaiNmqvSOeqOkLH/YmzxR 6jNhz6PcnkkvPPdwJ50mTw3pfBDdD4gyU2Dgk2/cHwG/fv8lPaGJQd5xSsjYiOvh p6P6a1nBnRSOfnkgMLIHjElo77Y66Ua6Zfd1WBVEyY+6EXDPmbI2cj7QyVt0YFJO erfpt7OIpjHG89Ty4wI8nmoHfOGpUw== =UrDw -----END PGP SIGNATURE----- --x6ccdfbtybphjisq-- From owner-freebsd-hackers@freebsd.org Wed Dec 30 23:02: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 C1B894D23E7 for ; Wed, 30 Dec 2020 23:02:21 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5myN4yJNz4qLD; Wed, 30 Dec 2020 23:02:20 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609369339; bh=a4VpHIoWDkfmdZQo6dkvYN9yuDPQ8Amc3/IW7Jmkpxo=; h=X-UI-Sender-Class:From:Subject:Date:References:Cc:In-Reply-To:To; b=FQO9u7FIP8CgTh6sgwJdnAE1F27U9qpPOdbV8Gvzo++FYiHcLRnxrEy8yMm8McxWf 3ezT5Xj4mry4VmuJfQwmARCZj3RMtLXdTXJm/cHklYMYaWQ47CfKrowWSJCSINIn3F ZDHk8WiO+HHcP1ukr/ARJobTAxEgQ6nNKIAJMER0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [2.2.2.3] ([87.122.30.127]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MowKi-1kEal23sre-00qO1b; Thu, 31 Dec 2020 00:02:19 +0100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: CerebrosuS Mime-Version: 1.0 (1.0) Subject: Re: Project information - SMBv2+ Date: Thu, 31 Dec 2020 00:02:18 +0100 Message-Id: <43C8B023-8DDF-4BA1-B9ED-483CB45B8E58@gmx.net> References: <20201230225624.atsnf6u5mmtcu5sw@nerd-thinkpad.local> Cc: freebsd-hackers@freebsd.org In-Reply-To: <20201230225624.atsnf6u5mmtcu5sw@nerd-thinkpad.local> To: Daniel Ebdrup Jensen X-Mailer: iPhone Mail (18B92) X-Provags-ID: V03:K1:mKv1+qCqjDR7GTnDsyjOdLlRRczPZbZ9QgWrYazTV6Kh2DHsWIs uQZxSL7vKubTgnsfh7fhgnkIR2R78wKU1Nu+VlSqI/VE4KsDFvzR3dSN24zoDtyQCPRw59m +Rroa4eeAczOuyIbLQHwBPOY60bg7Im7EXYl4xKB+LseSoCrs6ZAIO3s02lEBeglg256H8c lUdqXmP0Rk9jJ4kMJm/qg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:5+8LuPxPvQM=:GVZ8qUSs3peXiUrk6/rSPA EbBYWdYcR8yrhxEp4o+GprOCeI19oBu2Jg9Ik/T0SnkYxkIRfEKvUaSrSbmOjdsFxd9A3+p5w ukfl+qWanCo1Y45JpBiTigpnURNvDIyAYTDBOW50Ik3yEuqqhO2PC2o3GFEklalBzOfqKPMUM Z7VRMszNZHxUWgHku3ibGV/AKd0GuavJYC4BnzFYNsvqEelrmDj8hk/ne91VjHpjOOwGhXfqd xTkvoH93jW8qBcvHDrpyeZAAeKgYxchZOGNkiGtV5ai/Kfh8SSfsJ/O6FEB3pclTp8xfeSbJY ys7+YbsExWIv1hFhn3o1Y0Opw4J/FqpnSakqrhMGOiwZXcMS5s+6g0sFgiMUaWQIZ5R8zIzWP ZhJte0fNhDbh6atlcq/kGuMx24UqjBRFiQLeJMqmfmod8SGShvB4ZVexmp/v4KcoYv9MXpb+y HTre74xvMEIDpIKSXBtozBw6w4M2LnkSgdJh7vAbLBlKu8bbzxAtWPA2z7dfnbdwjBv4hFVSm /Fanqf1lfJ1gsw/71y6+sqbZXxqVNNxJFp1+GWa+hfXEUEIElw2KrlgidTVaM9YexcMEYrBuj G2C3vmUPXvXoFjL2xQf8CM0t6vsT8/ZmuVZyLtcHFngsqLga8y5JypuQfx8uycf8Rq7+A7Mt2 C0du/iSRlfg4WK5jft2WagmqAQr009zHUYZHrpTOPdoRoiDdeT3884csX66VczSdxx/AKlp2r hlaceLhM87o/mvHSKKbEsUAvB3oPbtGRc6OF79Tr/sEC5f+Js02yP+c0hZabSZfCxSYLwvbaW MyDy1XHUhpjvec+Q9xfpqMzE1omD4p0VHLYD84Dhxry+b/F4MR13FS/MkmqVkRL2uQADXfDHT 6zFtcQuLn91wVyZJ2Fkg== X-Rspamd-Queue-Id: 4D5myN4yJNz4qLD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=FQO9u7FI; dmarc=pass (policy=none) header.from=gmx.net; spf=pass (mx1.freebsd.org: domain of CerebrosuS@gmx.net designates 212.227.15.19 as permitted sender) smtp.mailfrom=CerebrosuS@gmx.net X-Spamd-Result: default: False [-3.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmx.net]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; DKIM_TRACE(0.00)[gmx.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmx.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmx.net]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.15.19:from]; DWL_DNSWL_NONE(0.00)[gmx.net:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RECEIVED_SPAMHAUS_PBL(0.00)[87.122.30.127:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; SPAMHAUS_ZRD(0.00)[212.227.15.19:from:127.0.2.255]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.19:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 23:02:21 -0000 My experience with the fuse smbnetnfs is about a week old on FreeBSD 12.2. > Am 30.12.2020 um 23:56 schrieb Daniel Ebdrup Jensen := >=20 > =EF=BB=BFOn Wed, Dec 30, 2020 at 10:16:44PM +0100, Miroslav Lachman wrote:= >>> On 30/12/2020 20:24, CerebrosuS wrote: >>>=20 >>>=20 >>> Am 30.12.20 um 20:05 schrieb Miroslav Lachman: >>>> On 30/12/2020 18:57, CerebrosuS wrote: >>>>> Hello at all, >>>>>=20 >>>>> the community and developer at FreeBSD seem to know, that SMBv1 for >>>>> clients is nearly over and that the included mount_smbfs doesn't suppo= rt >>>>> newer versions. So good, so far... >>>>>=20 >>>>> So I can find multiple information about the situation, but no clear >>>>> path on how FreeBSD community and developer will go on to solve this >>>>> missing function. (Just got the information on: >>>>> https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSamba= Client) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> This is what I am asking: >>>>> - Is there a project existing for solving this problem (with whatever >>>>> target)? >>>>> - What is the way to go in future? Extend mount_smbfs or support the >>>>> fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and >>>>> laggy here)? >>>>> - Who is mainly working on it, if a project already exist? >>>>>=20 >>>>> I'am just interested, cause of not finding such information clearly. I= s >>>>> there maybe a general project management list / team to see what >>>>> projects are going on in whatever state? >>>>>=20 >>>>> I am a hobby developer mainly coming from chemical engineering side, >>>>> having some time to help. I've already written some cross platform >>>>> software but never related to network or on os-level. So I am motivate= d >>>>> to invest some time in getting stuff into FreeBSD, but for me, there i= s >>>>> a lack on information (see above). >>>>>=20 >>>>> Thank you in advance for information and help. >>>>=20 >>>> I was involved in the thread linked by Gleb. AFAIK nothing changed from= >>>> that time. I tried something from ports but it has more problems (share= s >>>> cannot be mounted on boot like mount_smbfs does). >>>> If somebody has time and skills to try to bring SMBv2 or v3 to FreeBSD >>>> then Apple or Solaris sources is good start. The both were using the >>>> same mount_smbfs (v1) as FreeBSD so one can check their sources and see= >>>> how they evolve to v2 / v3. >>>=20 >>> They are both using exactly the same source code as a starting point and= >>> extend it (or rewrite it) to SMBv2? >>=20 >> They are based on the ported code. Apple Mac OS X and Solaris have differ= ent kernel so they needed modified port of the same code as was in FreeBSD b= ack in the days (there is the same copyright header). Apple sources or Solar= is sources cannot be used directly on FreeBSD but some skilled developer can= look in to those sources to see their evolution. But as was already noted v= 2 and v3 are very different from v1. It will be hard to port but not impossi= ble. >> Current solutions in ports (fusefs) are almost useless in server environm= ent. >>=20 >> Miroslav Lachman >>=20 >> _______________________________________________ >> 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= " >=20 > Hi folks, >=20 > Assuming that the reasons for not using fuse in a server environment are r= elated primarily to performance and that the implementation that was in base= used to be quite out-of-date, has this at all been reevalulated since a new= version was merged? [1] >=20 > Yours, > Daniel Ebdrup Jensen >=20 > [1]: https://svnweb.freebsd.org/changeset/base/350665 From owner-freebsd-hackers@freebsd.org Wed Dec 30 23:04: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 46B744D282F for ; Wed, 30 Dec 2020 23:04:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670087.outbound.protection.outlook.com [40.107.67.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5n12203Nz4qb4 for ; Wed, 30 Dec 2020 23:04:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SpfBtimI0bLpLb5ow/WYWEHIkCB3De/TqOYxSTE8l7oaDk92lZr3CbUNAl8p5p+8rsCYQFFm9mPFrSLXgbuBUzXRqLrx+BxVT7wPbtVqiU9d9/gSV54lamTrQ75bHjudDcwgBcI4bY+FUJq8DASABogoLWVGjhfm4cn6r4hNzMxiTPzARpaQB4rVilE7bX5HrjO2BjwXr5ItiOwKc1pb2w+3z98kWf99R65CEBfMu74gwkbYnMJoiMVFAHgvVrrFTJJVKZ/B8YlLAghE30MTCem1uYySUhR4oTlBgmOuo4jSYMmKr3vsqNdaalpC3s3Kgj2lvRCgOgQsCkM/cPjajA== 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=5jEufvCU3SmBLB6BpQapFWsER6OzgmhewmnoQE6QfqM=; b=P7tnbidSwCElKGZleMHjbL9ZVJ9196aY2lg2PonnBUXatMT3eKxsaQkf0GFEFoq9tLRHIj8Rg/nmRRk78wz08Qpo0eBcGN/X3ynNfz9vvlBnl6Ps3Y1cwcrbzSHW8JjXd20QWWzlsOL1gAn4UTJ8edH0yWHzPImHSH5HSURm7+FuIFdSJ1Ywgk/yeqqiHgFjsqg87l7zTrr/nQiR9TZrCLHVDsiu/dkl+ctQkQkV8i73lBy3dqP8NaLed3eE21aX2KapRcgzu9ig3RZHn1JbFUwjkcTg9XTKcznD47+a5zLrFYJzrcemUAriawoDB4vk8RE2gkkw9F19chepmwAVZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5jEufvCU3SmBLB6BpQapFWsER6OzgmhewmnoQE6QfqM=; b=heatmyumn4B0EZZNYGUf1as5phIEA/29LyZcgrXwhVRTMCYOywEDlm6kxdv05jW7cdSenNDB0uS2uNd2JTg6HKIIN+i4zAOgqdggL8qbCD6LcUco8cPvdrs2j80jpZmzh65Q/xTt49G/poZ24cnGtIDpd5j6jSD6B0joJuyDHXCUnc/b9+NcFiVXtW/zUUthoTjzs7a9k0af9JZCmX2gElxRTNxaBD4iSJNhSUwKU467THpCaO+V4V+aItwN4VoqUHPe3DOUh/LDc4RAhe7XY+mXhlHPZgcx3yH7Pl+odyI93dKoa/mdaUdFc0wLHNzJvr2Pi4vdFPacIzGk8F7yDg== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB3431.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:50::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.19; Wed, 30 Dec 2020 23:04:36 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3721.020; Wed, 30 Dec 2020 23:04:36 +0000 From: Rick Macklem To: Chris Johns , "freebsd-hackers@freebsd.org" Subject: Re: sys/fs/nfsclient on RTEMS gets a bad seqid error with open Thread-Topic: sys/fs/nfsclient on RTEMS gets a bad seqid error with open Thread-Index: AQHW3vvMptXvn9DSVEiX21X2JwySZ6oQPtfs Date: Wed, 30 Dec 2020 23:04:36 +0000 Message-ID: References: <447e4bfa-ebe3-62a3-26e4-c7f3108d5fa5@rtems.org> In-Reply-To: <447e4bfa-ebe3-62a3-26e4-c7f3108d5fa5@rtems.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88de84f1-c793-4454-6edb-08d8ad174732 x-ms-traffictypediagnostic: YQXPR01MB3431: 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: VRuE51RHob+VjCWqJwvKFva9atMDcDFAeG3MN6HIVPO6TaMNDuj7vTeadA3avVgrDB70kFhu31Zs/+kvLwcRkdJ1t4rNwXvVsFT3oB5Rr2aRN1qAv5RSR4ga+WjvhhQaPe0EalPVMn7UIGLiXJyE5xrgYUrZrTsJ58eKHTl1tWEsGdoXQgn1FCIUtkXJuum1U5pd3RdwpbO+xPRMpeV8cg+BLi3t1TylQxStcXKUGUR4kG7ex5Ayhdq4Wo14ZurBxyalQMB66TXLaBM6jZD/XaI6QbEVHTjQARqTHfG64jkLxhYbbO5/mbVpZrNOQSnyImMCMphQu78mim7pXWYuPGY1/dhdzwGekX+uhwWIkoEhkSsPG+/aGBbytoye+MJ5ec9RkGhdD9Je6vICijqH437n0PNayieLGHPaB/pg4lEsz9QGekVbKOL7/0yTCiDC/CPMeWhTiAsT7YHo+JR5KQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(39850400004)(136003)(346002)(396003)(366004)(86362001)(5660300002)(9686003)(83380400001)(8936002)(55016002)(110136005)(316002)(786003)(52536014)(71200400001)(26005)(186003)(33656002)(6506007)(8676002)(66556008)(478600001)(64756008)(66476007)(2906002)(66446008)(91956017)(66946007)(7696005)(966005)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?prdqMRPC1RJjqbUZlZGPdvp/pAx/Inlj8PZWkqUH4gWaRC5QmPbNCJJxvg?= =?iso-8859-1?Q?gfMc1AmzswR1MRk8m3my9+L7jAXLCBwFPuctyQKBtCRsO5bE2s+Nx3HsPi?= =?iso-8859-1?Q?qpLzM9am6L44yLHyO++eF6FQtWxdHhva55Zg7rNhU7+/T5Z2H3v/JWdhdp?= =?iso-8859-1?Q?G1rakBlHurjYe1uilACAwwnTVhuDbpC2c+QVCcfGkebNgYSmOzAxCqORpB?= =?iso-8859-1?Q?d4RcCydh04Ev4jHhBtIwOYytEgEap3caV19um27B6qxBCDCr1BM+4Xb6n+?= =?iso-8859-1?Q?HizOatOBj4azne/ulQL2TVdWEU6Qvfmfz6ieHgfMBUkm4kaT9NcdfmcA1m?= =?iso-8859-1?Q?ISUNipmVZ9HpGwUyOM1LIjjsPhyXog5KTrtD4od3ih8Zrk/Esb38ibGaYW?= =?iso-8859-1?Q?bm+1+sHITlRiW99z21jTI20Afv5wl/tTa8i+jeH/eTOYTx1B3PLhk7iyHo?= =?iso-8859-1?Q?T5v91Gj5HDGgGIr7bvXgBPSua4ivZU3xzTE0NuboWmlHKI2XaQNKY62W28?= =?iso-8859-1?Q?Rwj9PAIfZtUJDJD0txznR3u2qkCgAbtoHfbQQsr+OB1xd3phqTrbTgXWBc?= =?iso-8859-1?Q?5Wq8/k9F2amX1F7SE/GMLpamx5CFHhrDKbtcfxnWZdnFnzzX/qR7js87mH?= =?iso-8859-1?Q?m62hF8VUFfRvkB5TOxdLMdBhzLSz5hVNl1TzG0ANd+GEdrheF3cMUPj9SC?= =?iso-8859-1?Q?jDZY4PxJCNNCiote8Rwm51sVr1wDU78LqIVCrpoNv52kDIfohTSBaJOvC9?= =?iso-8859-1?Q?QwKVy1Ge8cgSBcRaoLBgBq3is1pX30k+xRVgWIBQFUoKTlDusQxzgP7yyX?= =?iso-8859-1?Q?xj4roiM80VxWRUMrGtVVcs+O32Fwti2Kw9XXTVEt+kjAcChZlyr4b9dspN?= =?iso-8859-1?Q?znbMBouWrlRyq4GoqJyB82uPMvYJrxBBm93wUwH2LG3uV+b7E9dh/yyeqN?= =?iso-8859-1?Q?u+OiO4h+DxaPRgTaVEiza4Iimguflr7llLgjssiZDbBwLVOcXRsejefBD0?= =?iso-8859-1?Q?Wy88W48pmDqwEV9U0=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 88de84f1-c793-4454-6edb-08d8ad174732 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2020 23:04:36.2306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gqObl95jisbmxjfyc/6hX0ZxGQzZfCvi6ag8EEsEp8sieU+GYpvQR91pduXLcORGXcFKCpemXi+riA50Rs/KOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3431 X-Rspamd-Queue-Id: 4D5n12203Nz4qb4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=heatmyum; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.87 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[40.107.67.87:from]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.67.87:from]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FROM_EQ_ENVFROM(0.00)[]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; SPAMHAUS_ZRD(0.00)[40.107.67.87:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.87:from]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 23:04:39 -0000 Chris Johns wrote:=0A= >Hello,=0A= >=0A= >I am porting the kernel's nfsclient file system to the RTEMS port of FreeB= SD. I=0A= >have ported across the FreeBSD file descriptors, VFS and NFS code. I have = a=0A= >custom pseudofs file system as my root file system and I can mount an NFSv= 4=0A= >mount exported from a FreeBSD 12 box.=0A= >=0A= >When I open a file there are a some getattr RPC calls that are successful= =0A= >however the open call (PUTFH, OPEN, GETATTR) results in the server returni= ng the=0A= >bas seqid (10026) error code for the OPEN and I am not sure why this is=0A= >happening. I suspect I am missing a step in the nfsclient set up.=0A= Well, for NFSv4.0 Opens, there is a field in the open_owner called a "seqid= ',=0A= which is used to serialize Open calls. If that "seqid" gets screwed up, you= =0A= get a "bad seqid" (10026) from the server and your mount is broken.=0A= A couple of possibilities:=0A= - The FreeBSD client code depends on an exclusive lock on the vnode=0A= to serialize the Opens.=0A= --> If what you are doing doesn't serialize them, then that will be a=0A= problem.=0A= - If the VOP_OPEN() generates an unexpected error (I just ran into this=0A= on FreeBSD head), then the client might not get things correct.=0A= --> The seqid is incremented for some errors, but not others.=0A= =0A= Btw, all this seqid stuff goes away when you use NFSv4.1 and there=0A= are NFSv4.1 only clients out there. You might want to consider doing=0A= this. If I was writing the code now, there would be no NFSv4.0.=0A= =0A= rick=0A= ps: Getting this seqid stuff right was about the hardest part of=0A= implementing NFSv4.0 and it could still be buggy.=0A= =0A= Any hints or help would be most welcome.=0A= =0A= Thanks=0A= Chris=0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= =0A= From owner-freebsd-hackers@freebsd.org Wed Dec 30 23:13:29 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 0F0994D2B87 for ; Wed, 30 Dec 2020 23:13:29 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (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 4D5nCD6wcwz4qqg; Wed, 30 Dec 2020 23:13:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f171.google.com with SMTP id s2so20301893oij.2; Wed, 30 Dec 2020 15:13:28 -0800 (PST) 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=IhshQka+dHwUXv6eNefntLup/Qb/+DB6CIfjeEMV4YU=; b=Aw30u82eFSL2yAfPxpQMndjq0QzDhlDfa+OCUGBZMKeiGCudQKJXPPO6KDwYW35tOX 5JsXmVwOawG7RzKetSujDpNYZIcNuZ5yQ8Od5J8THZnTJtLYxyiR4hWf1nhxzJo0DLwr ahrWM+ngZcKLL5ubM9lbWxmgycnmr4WJtbRxSDmO5vPd0GZEKwUfF3gSTkW2HheEUFNT 1X/lZz107R6jGD/Dt24LurlxQB5encr1cYjLf+w3vxwjQMsKjk1RufkyewxpEjkdlWGq bGcb/dBG2ldIIDRaOh8TnT7d1LJcq5E4U7G4aAPJCQQsRJhfIndKZ6V6OdBACK1m71T8 wCDA== X-Gm-Message-State: AOAM531JXffXPDtmXe5NPQjBNK0O0FT4n4B0zOY9K/VNgD8khMwlxAIu FF1FTb7BixBSfs5InP69BTQPVMLKgHvdJPOWZmE= X-Google-Smtp-Source: ABdhPJxSdLbxvMXsTgSL8t9Tgi9go3Jsjkw1Q/kr2MULTmD9CQMcuChCq0iLgiWGHUHvwck4WGK4uyd6YOF8/8eQYJE= X-Received: by 2002:aca:540e:: with SMTP id i14mr6507911oib.57.1609370007625; Wed, 30 Dec 2020 15:13:27 -0800 (PST) MIME-Version: 1.0 References: <20201230225624.atsnf6u5mmtcu5sw@nerd-thinkpad.local> <43C8B023-8DDF-4BA1-B9ED-483CB45B8E58@gmx.net> In-Reply-To: <43C8B023-8DDF-4BA1-B9ED-483CB45B8E58@gmx.net> From: Alan Somers Date: Wed, 30 Dec 2020 16:13:15 -0700 Message-ID: Subject: Re: Project information - SMBv2+ To: CerebrosuS Cc: Daniel Ebdrup Jensen , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 4D5nCD6wcwz4qqg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 23:13:29 -0000 I notice that smbnetfs is still using libfuse-2. libfuse-3 uses a newer protocol, with more features and better performance. If you want to help FreeBSD's SMB situation, your time might be more productively spent by upgrading smbnetfs to libfuse-3. -Alan On Wed, Dec 30, 2020 at 4:02 PM CerebrosuS wrote: > My experience with the fuse smbnetnfs is about a week old on FreeBSD 12.2= . > > > Am 30.12.2020 um 23:56 schrieb Daniel Ebdrup Jensen >: > > > > =EF=BB=BFOn Wed, Dec 30, 2020 at 10:16:44PM +0100, Miroslav Lachman wro= te: > >>> On 30/12/2020 20:24, CerebrosuS wrote: > >>> > >>> > >>> Am 30.12.20 um 20:05 schrieb Miroslav Lachman: > >>>> On 30/12/2020 18:57, CerebrosuS wrote: > >>>>> Hello at all, > >>>>> > >>>>> the community and developer at FreeBSD seem to know, that SMBv1 for > >>>>> clients is nearly over and that the included mount_smbfs doesn't > support > >>>>> newer versions. So good, so far... > >>>>> > >>>>> So I can find multiple information about the situation, but no clea= r > >>>>> path on how FreeBSD community and developer will go on to solve thi= s > >>>>> missing function. (Just got the information on: > >>>>> > https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSambaCli= ent > ) > >>>>> > >>>>> > >>>>> > >>>>> This is what I am asking: > >>>>> - Is there a project existing for solving this problem (with whatev= er > >>>>> target)? > >>>>> - What is the way to go in future? Extend mount_smbfs or support th= e > >>>>> fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy an= d > >>>>> laggy here)? > >>>>> - Who is mainly working on it, if a project already exist? > >>>>> > >>>>> I'am just interested, cause of not finding such information clearly= . > Is > >>>>> there maybe a general project management list / team to see what > >>>>> projects are going on in whatever state? > >>>>> > >>>>> I am a hobby developer mainly coming from chemical engineering side= , > >>>>> having some time to help. I've already written some cross platform > >>>>> software but never related to network or on os-level. So I am > motivated > >>>>> to invest some time in getting stuff into FreeBSD, but for me, ther= e > is > >>>>> a lack on information (see above). > >>>>> > >>>>> Thank you in advance for information and help. > >>>> > >>>> I was involved in the thread linked by Gleb. AFAIK nothing changed > from > >>>> that time. I tried something from ports but it has more problems > (shares > >>>> cannot be mounted on boot like mount_smbfs does). > >>>> If somebody has time and skills to try to bring SMBv2 or v3 to FreeB= SD > >>>> then Apple or Solaris sources is good start. The both were using the > >>>> same mount_smbfs (v1) as FreeBSD so one can check their sources and > see > >>>> how they evolve to v2 / v3. > >>> > >>> They are both using exactly the same source code as a starting point > and > >>> extend it (or rewrite it) to SMBv2? > >> > >> They are based on the ported code. Apple Mac OS X and Solaris have > different kernel so they needed modified port of the same code as was in > FreeBSD back in the days (there is the same copyright header). Apple > sources or Solaris sources cannot be used directly on FreeBSD but some > skilled developer can look in to those sources to see their evolution. Bu= t > as was already noted v2 and v3 are very different from v1. It will be har= d > to port but not impossible. > >> Current solutions in ports (fusefs) are almost useless in server > environment. > >> > >> Miroslav Lachman > >> > >> _______________________________________________ > >> 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" > > > > Hi folks, > > > > Assuming that the reasons for not using fuse in a server environment ar= e > related primarily to performance and that the implementation that was in > base used to be quite out-of-date, has this at all been reevalulated sinc= e > a new version was merged? [1] > > > > Yours, > > Daniel Ebdrup Jensen > > > > [1]: https://svnweb.freebsd.org/changeset/base/350665 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Wed Dec 30 23:32: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 D00184D3170 for ; Wed, 30 Dec 2020 23:32:14 +0000 (UTC) (envelope-from chrisj@rtems.org) Received: from nsstlmta09p.bpe.bigpond.com (nsstlmta09p.bpe.bigpond.com [203.38.21.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5ncs0lwpz4s9Y for ; Wed, 30 Dec 2020 23:32:12 +0000 (UTC) (envelope-from chrisj@rtems.org) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep09p-svc.bpe.nexus.telstra.com.au with ESMTP id <20201230233208.TCQV25903.nsstlfep09p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com>; Thu, 31 Dec 2020 10:32:08 +1100 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedrvddvgedgudefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuuffpveftpgfvgffnuffvtfetpdfqfgfvnecuuegrihhlohhuthemucegtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefjeenucfhrhhomhepvehhrhhishculfhohhhnshcuoegthhhrihhsjhesrhhtvghmshdrohhrgheqnecuggftrfgrthhtvghrnhepieekuedtjeeuhfdugeejgfekueeiffevfedvveevtdevheffveffieevueelffejnecukfhppedufeelrddufedtrddvgeehrddvtddtpdeitddrvdefuddrfeejrdefleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehmrghilhdrtghonhhtvghmphhorhgrrhihrdhnvghtrdgruhdpihhnvghtpedufeelrddufedtrddvgeehrddvtddtpdhmrghilhhfrhhomhepoegthhhrihhsjhesrhhtvghmshdrohhrgheqpdhrtghpthhtohepoehfrhgvvggsshguqdhhrggtkhgvrhhssehfrhgvvggsshgurdhorhhgqedprhgtphhtthhopeeorhhmrggtkhhlvghmsehuohhguhgvlhhphhdrtggrqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RG-VS-CLASS: clean Received: from mail.contemporary.net.au (139.130.245.200) by smtp.telstra.com (5.8.420) id 5FE6CD410143550F; Thu, 31 Dec 2020 10:32:07 +1100 Received: from [192.168.15.73] ([60.231.37.39]) (authenticated bits=0) by mail.contemporary.net.au (8.15.2/8.15.2) with ESMTPSA id 0BUNW4Z2066215 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 Dec 2020 10:32:04 +1100 (EST) (envelope-from chrisj@rtems.org) X-Authentication-Warning: corb.contemporary.net.au: Host [60.231.37.39] claimed to be [192.168.15.73] Subject: Re: sys/fs/nfsclient on RTEMS gets a bad seqid error with open To: Rick Macklem , "freebsd-hackers@freebsd.org" References: <447e4bfa-ebe3-62a3-26e4-c7f3108d5fa5@rtems.org> From: Chris Johns Organization: https://www.rtems.org/ Message-ID: <948ecbbf-5e6f-694b-1a40-9f1fa14bfd89@rtems.org> Date: Thu, 31 Dec 2020 10:31:59 +1100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-106.2 required=2.7 tests=ALL_TRUSTED,BAYES_00, NICE_REPLY_A,TW_EQ,USER_IN_WELCOMELIST,USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on corb.contemporary.net.au X-Rspamd-Queue-Id: 4D5ncs0lwpz4s9Y X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of chrisj@rtems.org has no SPF policy when checking 203.38.21.9) smtp.mailfrom=chrisj@rtems.org X-Spamd-Result: default: False [-2.20 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_LOW(-0.10)[203.38.21.9:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[203.38.21.9:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:1221, ipnet:203.36.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[rtems.org]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[203.38.21.9:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 23:32:14 -0000 On 31/12/20 10:04 am, Rick Macklem wrote: > Chris Johns wrote: >> Hello, >> >> I am porting the kernel's nfsclient file system to the RTEMS port of FreeBSD. I >> have ported across the FreeBSD file descriptors, VFS and NFS code. I have a >> custom pseudofs file system as my root file system and I can mount an NFSv4 >> mount exported from a FreeBSD 12 box. >> >> When I open a file there are a some getattr RPC calls that are successful >> however the open call (PUTFH, OPEN, GETATTR) results in the server returning the >> bas seqid (10026) error code for the OPEN and I am not sure why this is >> happening. I suspect I am missing a step in the nfsclient set up. > Well, for NFSv4.0 Opens, there is a field in the open_owner called a "seqid', > which is used to serialize Open calls. If that "seqid" gets screwed up, you > get a "bad seqid" (10026) from the server and your mount is broken. There is only one open call being made and the seq id in the packet is 0. The server code seems to consider ownership when returning this error and this is an area I am not sure about. RTEMS simulates a process and does not have a normal user/group model. > A couple of possibilities: > - The FreeBSD client code depends on an exclusive lock on the vnode > to serialize the Opens. There is only one open call active. This is something I can control. > --> If what you are doing doesn't serialize them, then that will be a > problem. > - If the VOP_OPEN() generates an unexpected error (I just ran into this > on FreeBSD head), then the client might not get things correct. > --> The seqid is incremented for some errors, but not others. I am currently basing this work on the FreeBSD 12 branch we have. A master port is next. > Btw, all this seqid stuff goes away when you use NFSv4.1 and there > are NFSv4.1 only clients out there. You might want to consider doing > this. If I was writing the code now, there would be no NFSv4.0. Ah OK. How do I make the FreeBSD nfsclient operate as NFSv4.1? I looked into this but I could not figure out how. > rick > ps: Getting this seqid stuff right was about the hardest part of > implementing NFSv4.0 and it could still be buggy. Hmm yes it seems a little tricky. Thanks Chris From owner-freebsd-hackers@freebsd.org Wed Dec 30 23:33: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 2A6994D348C for ; Wed, 30 Dec 2020 23:33:35 +0000 (UTC) (envelope-from SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4D5nfP5KGLz4sVZ; Wed, 30 Dec 2020 23:33:33 +0000 (UTC) (envelope-from SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B2A7E28416; Thu, 31 Dec 2020 00:33:31 +0100 (CET) Received: from illbsd.quip.test (ip-94-113-69-69.net.upcbroadband.cz [94.113.69.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 1DB7C28411; Thu, 31 Dec 2020 00:33:30 +0100 (CET) Subject: Re: Project information - SMBv2+ To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> <704a700c-32ff-66eb-6711-5d75099abcd4@quip.cz> <20201230225624.atsnf6u5mmtcu5sw@nerd-thinkpad.local> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <8644f79e-3957-3498-efa9-8fbfc7b57581@quip.cz> Date: Thu, 31 Dec 2020 00:33:28 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201230225624.atsnf6u5mmtcu5sw@nerd-thinkpad.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5nfP5KGLz4sVZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[quip.cz]; ARC_NA(0.00)[]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[94.124.105.4:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.124.105.4:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[94.113.69.69:received]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 23:33:35 -0000 On 30/12/2020 23:56, Daniel Ebdrup Jensen wrote: > On Wed, Dec 30, 2020 at 10:16:44PM +0100, Miroslav Lachman wrote: >> On 30/12/2020 20:24, CerebrosuS wrote: >>> >>> >>> Am 30.12.20 um 20:05 schrieb Miroslav Lachman: >>>> On 30/12/2020 18:57, CerebrosuS wrote: >>>>> Hello at all, >>>>> >>>>> the community and developer at FreeBSD seem to know, that SMBv1 for >>>>> clients is nearly over and that the included mount_smbfs doesn't >>>>> support >>>>> newer versions. So good, so far... >>>>> >>>>> So I can find multiple information about the situation, but no clear >>>>> path on how FreeBSD community and developer will go on to solve this >>>>> missing function. (Just got the information on: >>>>> https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSambaClient) >>>>> >>>>> >>>>> >>>>> >>>>> This is what I am asking: >>>>> - Is there a project existing for solving this problem (with whatever >>>>> target)? >>>>> - What is the way to go in future? Extend mount_smbfs or support the >>>>> fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and >>>>> laggy here)? >>>>> - Who is mainly working on it, if a project already exist? >>>>> >>>>> I'am just interested, cause of not finding such information >>>>> clearly. Is >>>>> there maybe a general project management list / team to see what >>>>> projects are going on in whatever state? >>>>> >>>>> I am a hobby developer mainly coming from chemical engineering side, >>>>> having some time to help. I've already written some cross platform >>>>> software but never related to network or on os-level. So I am >>>>> motivated >>>>> to invest some time in getting stuff into FreeBSD, but for me, >>>>> there is >>>>> a lack on information (see above). >>>>> >>>>> Thank you in advance for information and help. >>>> >>>> I was involved in the thread linked by Gleb. AFAIK nothing changed from >>>> that time. I tried something from ports but it has more problems >>>> (shares >>>> cannot be mounted on boot like mount_smbfs does). >>>> If somebody has time and skills to try to bring SMBv2 or v3 to FreeBSD >>>> then Apple or Solaris sources is good start. The both were using the >>>> same mount_smbfs (v1) as FreeBSD so one can check their sources and see >>>> how they evolve to v2 / v3. >>> >>> They are both using exactly the same source code as a starting point and >>> extend it (or rewrite it) to SMBv2? >> >> They are based on the ported code. Apple Mac OS X and Solaris have >> different kernel so they needed modified port of the same code as was >> in FreeBSD back in the days (there is the same copyright header). >> Apple sources or Solaris sources cannot be used directly on FreeBSD >> but some skilled developer can look in to those sources to see their >> evolution. But as was already noted v2 and v3 are very different from >> v1. It will be hard to port but not impossible. >> Current solutions in ports (fusefs) are almost useless in server >> environment. >> >> Miroslav Lachman >> >> _______________________________________________ >> 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" > > Hi folks, > > Assuming that the reasons for not using fuse in a server environment are > related primarily to performance and that the implementation that was in > base used to be quite out-of-date, has this at all been reevalulated > since a new version was merged? [1] Last time I tried smb with fuse it was unstable and does not allowed me to configure what to mount where at boot time. AFAIK fusefs-smbnetfs cannot be used the same way as mount_smbfs in fstab. So I think smbnetfs is not usable solution in our environment even if it works stable and fast. Kind regards Miroslav Lachman From owner-freebsd-hackers@freebsd.org Thu Dec 31 00:38: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 0D7654D4A04; Thu, 31 Dec 2020 00:38:25 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (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 4D5q5D0Db9z3CHm; Thu, 31 Dec 2020 00:38:23 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 9C7C5EB2A5; Wed, 30 Dec 2020 16:38:16 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 16:38:16 -0800 From: Neel Chauhan To: Chuck Tuffli Cc: freebsd-hackers@freebsd.org, FreeBSD-Current Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5q5D0Db9z3CHm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 66.42.69.219 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-3.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+a]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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:20473, ipnet:66.42.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 00:38:25 -0000 Hi Chuck, On 2020-12-30 10:04, Chuck Tuffli wrote: > What is the output from > # pciconf -rb pci0:0:14:0 0x40:0x48 The output is: 01 00 00 00 01 2e 68 02 00 > --chuck I was also able to stop kernel panics by adding: rman_fini(&sc->vmd_bus.rman); In the fail: statement in vmd_attach(). But I still cannot detect the SSD. -Neel From owner-freebsd-hackers@freebsd.org Thu Dec 31 01:21: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 3B4524D667E; Thu, 31 Dec 2020 01:21:18 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (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 4D5r2j0swBz3GjR; Thu, 31 Dec 2020 01:21:16 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 9892FEB2A5; Wed, 30 Dec 2020 17:21:14 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 17:21:14 -0800 From: Neel Chauhan To: Chuck Tuffli Cc: freebsd-hackers@freebsd.org, FreeBSD-Current Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.9 Message-ID: <3c55d6d50b1bcf1d45d4599502060f34@neelc.org> X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5r2j0swBz3GjR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 66.42.69.219 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-3.72 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+a]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_SHORT(-0.92)[-0.920]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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:20473, ipnet:66.42.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 01:21:18 -0000 To extend, I am getting an issue with `pci_read_device()` where it returns a `vid` (PCI Vendor ID) of 0xffff. This ends up returning "Cannot allocate dinfo!" from vmd. Log (via grep): https://imgur.com/a/tAmmY7i -Neel On 2020-12-30 16:38, Neel Chauhan wrote: > Hi Chuck, > > On 2020-12-30 10:04, Chuck Tuffli wrote: >> What is the output from >> # pciconf -rb pci0:0:14:0 0x40:0x48 > > The output is: > > 01 00 00 00 01 2e 68 02 00 > >> --chuck > > I was also able to stop kernel panics by adding: > > rman_fini(&sc->vmd_bus.rman); > > In the fail: statement in vmd_attach(). > > But I still cannot detect the SSD. > > -Neel > _______________________________________________ > 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 Thu Dec 31 02:10: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 3784B4D88A8 for ; Thu, 31 Dec 2020 02:10:16 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (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 4D5s7C20Fsz3Kn1; Thu, 31 Dec 2020 02:10:14 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 6ED42EB2A5; Wed, 30 Dec 2020 18:10:11 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 18:10:11 -0800 From: Neel Chauhan To: Mark Johnston Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL In-Reply-To: References: <44528336fa9168966d121bf771e1e229@neelc.org> <3c9ff844e527daacd04c51f48836b57d@neelc.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: neel@neelc.org Content-Type: multipart/mixed; boundary="=_d3c477c3f144d2b9a03ca9c8b269190d" X-Rspamd-Queue-Id: 4D5s7C20Fsz3Kn1 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 66.42.69.219 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-1.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; ASN(0.00)[asn:20473, ipnet:66.42.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 02:10:16 -0000 --=_d3c477c3f144d2b9a03ca9c8b269190d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I have attached two files: * pcidump: A dump of `pciconf -lv` * acpidump: A dump of `acpidump` Hope this can help. -Neel On 2020-12-30 14:36, Neel Chauhan wrote: > Mark, thank you so much for your help! > > However, I am getting an issue with `pci_read_device()` where it > returns a `vid` (PCI Vendor ID) of 0xffff. > > This ends up returning "Cannot allocate dinfo!" from vmd. > > Log (via grep): https://imgur.com/a/tAmmY7i > > What usually causes this? > > I'm no expert on PC hardware, my $DAYJOB is not related to hardware > (I'm a C#/.NET developer for a living). > > I do however want my Spectre running FreeBSD and am willing to write > patches (to some extent at least). > > -Neel > > On 2020-12-30 10:03, Neel Chauhan wrote: >> Thank you so much! >> >> Adding a rman_fini() call made my system boot. >> >> I get stuck at a "Cannot allocate dinfo!" error now (I can't see the >> SSD), but I will debug first before coming back. >> >> -Neel >> >> On 2020-12-30 09:06, Mark Johnston wrote: >>> On Wed, Dec 30, 2020 at 08:43:17AM -0800, Neel Chauhan wrote: >>>> Hi all, >>>> >>>> I'm writing a patch to support the VMD subsystem in Intel TigerLake >>>> systems such as the HP Spectre x360 13t-aw200. VMD is needed for >>>> NVMe >>>> here. >>>> >>>> The patch is as follows >>>> >>>> --- a/sys/dev/vmd/vmd.c >>>> +++ b/sys/dev/vmd/vmd.c >>>> @@ -66,13 +66,20 @@ struct vmd_type { >>>> #define INTEL_VENDOR_ID 0x8086 >>>> #define INTEL_DEVICE_ID_VMD 0x201d >>>> #define INTEL_DEVICE_ID_VMD2 0x28c0 >>>> +#define INTEL_DEVICE_ID_VMD3 0x9a0b >>>> >>>> static struct vmd_type vmd_devs[] = { >>>> { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume >>>> Management Device" }, >>>> { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume >>>> Management Device" }, >>>> + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume >>>> Management Device" }, >>>> { 0, 0, NULL } >>>> >>>> However, when I use the patch, I get a kernel panic related to PCI: >>>> https://imgur.com/a/XUQksOi (sorry for the image) >>>> >>>> It gives me the Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL >>>> error. >>>> >>>> Could you please help me figure out why it's panicking? >>> >>> Based on the backtrace, we are panicking in rman_init() because the >>> global rman_head list is corrupted (the panic message is basically >>> stating that the next element of the last element of the list is not >>> NULL). This suggests that the item was freed without removing it >>> from >>> the list, i.e., an rman_fini() call is missing. >>> >>> vmd_attach() creates a resource container with rman_init(). If >>> vmd_attach() fails for some reason, it calls vmd_free(), which is >>> supposed to roll back anything done by vmd_attach(). Note that if >>> attach is successful, the driver subsystem may later call >>> vmd_detach() >>> to deinitialize the driver, and vmd_detach() does a bit of extra work >>> in >>> addition to calling vmd_free()... >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > 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" --=_d3c477c3f144d2b9a03ca9c8b269190d Content-Transfer-Encoding: base64 Content-Type: text/plain; name=acpidump Content-Disposition: attachment; filename=acpidump; size=10947 LyoKICBSU0QgUFRSOiBPRU09SFBRT0VNLCBBQ1BJX1Jldj0yLjB4ICgyKQoJWFNEVD0weDAwMDAw MDAwNTRkYmI3MjgsIGxlbmd0aD0zNiwgY2tzdW09MjA2CiAqLwovKgogIFhTRFQ6IExlbmd0aD0y NzYsIFJldmlzaW9uPTEsIENoZWNrc3VtPTU0LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9 U0xJQy1NUEMsIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUFNSSwgQ3JlYXRv ciBSZXZpc2lvbj0weDEwMDAwMTMKCUVudHJpZXM9eyAweDAwMDAwMDAwNTRkYjYwMDAsIDB4MDAw MDAwMDA1NGRiYTAwMCwgMHgwMDAwMDAwMDU0ZGI3MDAwLCAweDAwMDAwMDAwNTRkNjEwMDAsIDB4 MDAwMDAwMDA1NGQ2MDAwMCwgMHgwMDAwMDAwMDU0ZDVjMDAwLCAweDAwMDAwMDAwNTRkNTUwMDAs IDB4MDAwMDAwMDA1NGQ0ODAwMCwgMHgwMDAwMDAwMDU0ZDQ3MDAwLCAweDAwMDAwMDAwNTRkNDUw MDAsIDB4MDAwMDAwMDA1NGQ0NDAwMCwgMHgwMDAwMDAwMDU0ZDQwMDAwLCAweDAwMDAwMDAwNTRk M2YwMDAsIDB4MDAwMDAwMDA1NGQzZTAwMCwgMHgwMDAwMDAwMDU0ZDNkMDAwLCAweDAwMDAwMDAw NTRkM2MwMDAsIDB4MDAwMDAwMDA1NGQzYjAwMCwgMHgwMDAwMDAwMDU0ZDNhMDAwLCAweDAwMDAw MDAwNTRkMzkwMDAsIDB4MDAwMDAwMDA1NGQzODAwMCwgMHgwMDAwMDAwMDU0ZDM3MDAwLCAweDAw MDAwMDAwNTRkZTYwMDAsIDB4MDAwMDAwMDA1NGRlNTAwMCwgMHgwMDAwMDAwMDU0ZDM2MDAwLCAw eDAwMDAwMDAwNTRkNDkwMDAsIDB4MDAwMDAwMDA1NGQ1OTAwMCwgMHgwMDAwMDAwMDU0ZDM1MDAw LCAweDAwMDAwMDAwNTRkNDMwMDAsIDB4MDAwMDAwMDA1NGQzNDAwMCwgMHgwMDAwMDAwMDU0ZDMz MDAwIH0KICovCi8qCiAgRkFDUDogTGVuZ3RoPTI3NiwgUmV2aXNpb249NiwgQ2hlY2tzdW09MTYz LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9U0xJQy1NUEMsIE9FTSBSZXZpc2lvbj0weDEw NzIwMDksCglDcmVhdG9yIElEPUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMTMKIAlGQUNTPTB4 NTRlNzcwMDAsIERTRFQ9MHg1NGQ2MjAwMAoJSU5UX01PREVMPVBJQwoJUHJlZmVycmVkX1BNX1By b2ZpbGU9TW9iaWxlICgyKQoJU0NJX0lOVD05CglTTUlfQ01EPTB4YjIsIEFDUElfRU5BQkxFPTB4 YTAsIEFDUElfRElTQUJMRT0weGExLCBTNEJJT1NfUkVRPTB4MAoJUFNUQVRFX0NOVD0weDAKCVBN MWFfRVZUX0JMSz0weDE4MDAtMHgxODAzCglQTTFhX0NOVF9CTEs9MHgxODA0LTB4MTgwNQoJUE0y X0NOVF9CTEs9MHgxODUwLTB4MTg1MAoJUE1fVE1SX0JMSz0weDE4MDgtMHgxODBiCglHUEUwX0JM Sz0weDE4NjAtMHgxODdmCglQX0xWTDJfTEFUPTEwMSB1cywgUF9MVkwzX0xBVD0xMDAxIHVzCglG TFVTSF9TSVpFPTEwMjQsIEZMVVNIX1NUUklERT0xNgoJRFVUWV9PRkZTRVQ9MSwgRFVUWV9XSURU SD0zCglEQVlfQUxSTT0xMywgTU9OX0FMUk09MCwgQ0VOVFVSWT01MAoJSUFQQ19CT09UX0FSQ0g9 ezgwNDIsTk9fQVNQTX0KCUZsYWdzPXtXQklOVkQsQzFfU1VQUE9SVEVELFNMRUVQX0JVVFRPTixT NF9SVENfV0FLRSxSRVNFVF9SRUdJU1RFUixQQ0lfRVhQUkVTU19XQUtFLFBMQVRGT1JNX0NMT0NL LFM0X1JUQ19WQUxJRCxSRU1PVEVfUE9XRVJfT04sTE9XX1BPV0VSX1MwfQoJUkVTRVRfUkVHPTB4 YjI6MFs4XSAoSU8pLCBSRVNFVF9WQUxVRT0weGViCiAqLwovKgogIEZBQ1M6CUxlbmd0aD02NCwg SHdTaWc9MHhjMGYxYmUyZiwgRmlybV9XYWtlX1ZlYz0weDAwMDAwMDAwCglHbG9iYWxfTG9jaz0K CUZsYWdzPQoJVmVyc2lvbj0yCiAqLwovKgogIERTRFQ6IExlbmd0aD0zNDE5MjQsIFJldmlzaW9u PTIsIENoZWNrc3VtPTE5NywKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBS ZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgy MDE5MTAxOAogKi8KLyoKICBNQ0ZHOiBMZW5ndGg9NjAsIFJldmlzaW9uPTEsIENoZWNrc3VtPTM3 LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAw OSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHg5NwoKCUJhc2UgQWRkcmVzcz0w eDAwMDAwMDAwYzAwMDAwMDAKCVNlZ21lbnQgR3JvdXA9MHgwMDAwCglTdGFydCBCdXM9MAoJRW5k IEJ1cz0yNTUKICovCi8qCiAgU1NEVDogTGVuZ3RoPTk2NzksIFJldmlzaW9uPTIsIENoZWNrc3Vt PTczLAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MzAw MCwKCUNyZWF0b3IgSUQ9QUNQSSwgQ3JlYXRvciBSZXZpc2lvbj0weDIwMTkxMDE4CiAqLwovKgog IEZJRFQ6IExlbmd0aD0xNTYsIFJldmlzaW9uPTEsIENoZWNrc3VtPTIxMCwKCU9FTUlEPUhQUU9F TSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElE PUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMTMKICovCi8qCiAgTVNETTogTGVuZ3RoPTg1LCBS ZXZpc2lvbj0zLCBDaGVja3N1bT0xOTYsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD1TTElD LU1QQywgT0VNIFJldmlzaW9uPTB4MSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249 MHgxMDAxMwogKi8KLyoKICBTU0RUOiBMZW5ndGg9MTMwNTYsIFJldmlzaW9uPTIsIENoZWNrc3Vt PTEwNywKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEw MDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgyMDE5MTAxOAogKi8KLyoK ICBTU0RUOiBMZW5ndGg9MTMxMzYsIFJldmlzaW9uPTIsIENoZWNrc3VtPTQxLAoJT0VNSUQ9SFBR T0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MzAwMCwKCUNyZWF0b3IgSUQ9 QUNQSSwgQ3JlYXRvciBSZXZpc2lvbj0weDIwMTkxMDE4CiAqLwovKgogIEhQRVQ6IExlbmd0aD01 NiwgUmV2aXNpb249MSwgQ2hlY2tzdW09MzIsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04 NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZp c2lvbj0weDEwMDAwMTMKCUhQRVQgTnVtYmVyPTAKCUFERFI9MHgwMDAwMDAwMGZlZDAwMDAwOjBb NjRdIChNZW1vcnkpCglIVyBSZXY9MHgxCglDb21wYXJhdG9ycz0yCglDb3VudGVyIFNpemU9MQoJ TGVnYWN5IElSUSByb3V0aW5nIGNhcGFibGU9e1RSVUV9CglQQ0kgVmVuZG9yIElEPTB4ODA4NgoJ TWluaW1hbCBUaWNrPTEyOAoJRmxhZ3M9MHgwMAogKi8KLyoKICBBUElDOiBMZW5ndGg9MzAwLCBS ZXZpc2lvbj00LCBDaGVja3N1bT0yNDIsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5 LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lv bj0weDEwMDAwMTMKCUxvY2FsIEFQSUMgQUREUj0weGZlZTAwMDAwCglGbGFncz17UEMtQVR9CgoJ VHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0wCglGbGFncz17RU5BQkxFRH0KCUFQSUMgSUQ9MAoK CVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9MQoJRmxhZ3M9e0VOQUJMRUR9CglBUElDIElEPTIK CglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTIKCUZsYWdzPXtFTkFCTEVEfQoJQVBJQyBJRD00 CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0zCglGbGFncz17RU5BQkxFRH0KCUFQSUMgSUQ9 NgoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9NAoJRmxhZ3M9e0VOQUJMRUR9CglBUElDIElE PTEKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTUKCUZsYWdzPXtFTkFCTEVEfQoJQVBJQyBJ RD0zCgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT02CglGbGFncz17RU5BQkxFRH0KCUFQSUMg SUQ9NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9NwoJRmxhZ3M9e0VOQUJMRUR9CglBUElD IElEPTcKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTgKCUZsYWdzPXtESVNBQkxFRH0KCUFQ SUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT05CglGbGFncz17RElTQUJMRUR9 CglBUElDIElEPTI1NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9MTAKCUZsYWdzPXtESVNB QkxFRH0KCUFQSUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0xMQoJRmxhZ3M9 e0RJU0FCTEVEfQoJQVBJQyBJRD0yNTUKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTEyCglG bGFncz17RElTQUJMRUR9CglBUElDIElEPTI1NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9 MTMKCUZsYWdzPXtESVNBQkxFRH0KCUFQSUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJ IENQVT0xNAoJRmxhZ3M9e0RJU0FCTEVEfQoJQVBJQyBJRD0yNTUKCglUeXBlPUxvY2FsIEFQSUMK CUFDUEkgQ1BVPTE1CglGbGFncz17RElTQUJMRUR9CglBUElDIElEPTI1NQoKCVR5cGU9SU8gQVBJ QwoJQVBJQyBJRD0yCglJTlQgQkFTRT0wCglBRERSPTB4MDAwMDAwMDBmZWMwMDAwMAoKCVR5cGU9 SU5UIE92ZXJyaWRlCglCVVM9MAoJSVJRPTAKCUlOVFI9MgoJRmxhZ3M9e1BvbGFyaXR5PWNvbmZv cm1pbmcsIFRyaWdnZXI9Y29uZm9ybWluZ30KCglUeXBlPUlOVCBPdmVycmlkZQoJQlVTPTAKCUlS UT05CglJTlRSPTkKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9bGV2ZWx9CgoJ VHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MQoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFy aXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkg Q1BVPTIKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRn ZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0zCglMSU5UIFBpbj0xCglGbGFncz17 UG9sYXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJ QUNQSSBDUFU9NAoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dl cj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkgQ1BVPTUKCUxJTlQgUGluPTEKCUZs YWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMg Tk1JCglBQ1BJIENQVT02CglMSU5UIFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBU cmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9NwoJTElOVCBQaW49 MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwg QVBJQyBOTUkKCUFDUEkgQ1BVPTgKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUt aGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT05CglMSU5U IFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1M b2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MTAKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1h Y3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0x MQoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoK CVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkgQ1BVPTEyCglMSU5UIFBpbj0xCglGbGFncz17UG9s YXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQ SSBDUFU9MTMKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9 ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0xNAoJTElOVCBQaW49MQoJRmxh Z3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBO TUkKCUFDUEkgQ1BVPTE1CglMSU5UIFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBU cmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MTYKCUxJTlQgUGlu PTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KICovCi8qCiAgTkhM VDogTGVuZ3RoPTcwNDQsIFJldmlzaW9uPTAsIENoZWNrc3VtPTExMywKCU9FTUlEPUhQUU9FTSwg T0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUhQ LCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMDAxMwogKi8KLyoKICBMUElUOiBMZW5ndGg9MjA0LCBS ZXZpc2lvbj0xLCBDaGVja3N1bT0xMjUsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5 LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lv bj0weDEwMDAwMTMKCglUeXBlPUFDUElfTFBJVF9UWVBFX05BVElWRV9DU1RBVEUKCUxlbmd0aD01 NgoJVW5pcXVlSWQ9MHgwMDAwCglGbGFncz0KCUVudHJ5VHJpZ2dlcj0weDAwMDAwMDAwMDAwMDAw NjAgKD8pCglSZXNpZGVuY3k9MzAwMDAKCUxhdGVuY3k9MzAwMAoJUmVzaWRlbmN5Q291bnRlcj0w eDAwMDAwMDAwMDAwMDA2MzIgKD8pCglDb3VudGVyRnJlcXVlbmN5PVRTQwoKCVR5cGU9QUNQSV9M UElUX1RZUEVfTkFUSVZFX0NTVEFURQoJTGVuZ3RoPTU2CglVbmlxdWVJZD0weDAwMDEKCUZsYWdz PQoJRW50cnlUcmlnZ2VyPTB4MDAwMDAwMDAwMDAwMDA2MCAoPykKCVJlc2lkZW5jeT0zMDAwMAoJ TGF0ZW5jeT0zMDAwCglSZXNpZGVuY3lDb3VudGVyPTB4MDAwMDAwMDBmZTAwMTkzYzowWzMyXSAo TWVtb3J5KQoJQ291bnRlckZyZXF1ZW5jeT04MTk3CgoJVHlwZT1BQ1BJX0xQSVRfVFlQRV9OQVRJ VkVfQ1NUQVRFCglMZW5ndGg9NTYKCVVuaXF1ZUlkPTB4MDAwMgoJRmxhZ3M9e1NUQVRFX0RJU0FC TEVEfQoJRW50cnlUcmlnZ2VyPTB4MDAwMDAwMDAwMDAwMDA2MCAoPykKCVJlc2lkZW5jeT0zMDAw MAoJTGF0ZW5jeT0zMDAwCglSZXNpZGVuY3lDb3VudGVyPTB4MDAwMDAwMDAwMDAwMDBmZjowWzMy XSAoTWVtb3J5KQoJQ291bnRlckZyZXF1ZW5jeT1UU0MKICovCi8qCiAgU1NEVDogTGVuZ3RoPTEw MDE2LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0zOCwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElE PTg3MDksIE9FTSBSZXZpc2lvbj0weDEwMDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2 aXNpb249MHgyMDE5MTAxOAogKi8KLyoKICBTU0RUOiBMZW5ndGg9Mjk4LCBSZXZpc2lvbj0yLCBD aGVja3N1bT0yNDAsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNp b249MHgwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICov Ci8qCiAgREJHUDogTGVuZ3RoPTUyLCBSZXZpc2lvbj0xLCBDaGVja3N1bT0xNjgsCglPRU1JRD1I UFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRv ciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMTMKICovCi8qCiAgREJHMjogTGVuZ3Ro PTg0LCBSZXZpc2lvbj0wLCBDaGVja3N1bT0yNDksCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJ RD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBS ZXZpc2lvbj0weDEwMDAwMTMKICovCi8qCiAgU1NEVDogTGVuZ3RoPTI5ODAsIFJldmlzaW9uPTIs IENoZWNrc3VtPTEwMCwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZp c2lvbj0weDEwMDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgyMDE5MTAx OAogKi8KLyoKICBETUFSOiBMZW5ndGg9MTg0LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0xOTEsCglP RU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgyLAoJQ3JlYXRv ciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMTMKCUhvc3QgQWRkcmVzcyBXaWR0aD0z OQoJRmxhZ3M9e0lOVFJfUkVNQVB9CgoJVHlwZT1EUkhECglMZW5ndGg9MjQKCUZsYWdzPQoJU2Vn bWVudD0wCglBZGRyZXNzPTB4MDAwMDAwMDBmZWQ5MDAwMAoJRGV2aWNlIFNjb3BlOgoJCVR5cGU9 UENJIEVuZHBvaW50IERldmljZQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezI6MH0KCglUeXBlPURSSEQKCUxlbmd0aD0yNAoJRmxhZ3M9CglT ZWdtZW50PTAKCUFkZHJlc3M9MHgwMDAwMDAwMGZlZDg0MDAwCglEZXZpY2UgU2NvcGU6CgkJVHlw ZT1QQ0kgU3ViLUhpZXJhcmNoeQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezc6MH0KCglUeXBlPURSSEQKCUxlbmd0aD0yNAoJRmxhZ3M9CglT ZWdtZW50PTAKCUFkZHJlc3M9MHgwMDAwMDAwMGZlZDg1MDAwCglEZXZpY2UgU2NvcGU6CgkJVHlw ZT1QQ0kgU3ViLUhpZXJhcmNoeQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezc6MX0KCglUeXBlPURSSEQKCUxlbmd0aD0zMgoJRmxhZ3M9e0lO Q0xVREVfQUxMfQoJU2VnbWVudD0wCglBZGRyZXNzPTB4MDAwMDAwMDBmZWQ5MTAwMAoJRGV2aWNl IFNjb3BlOgoJCVR5cGU9SU9BUElDCgkJTGVuZ3RoPTgKCQlFbnVtZXJhdGlvbklkPTIKCQlTdGFy dEJ1c051bWJlcj0wCgkJUGF0aD17MzA6N30KCgkJVHlwZT1IUEVUCgkJTGVuZ3RoPTgKCQlFbnVt ZXJhdGlvbklkPTAKCQlTdGFydEJ1c051bWJlcj0wCgkJUGF0aD17MzA6Nn0KCglUeXBlPVJNUlIK CUxlbmd0aD0zMgoJU2VnbWVudD0wCglCYXNlQWRkcmVzcz0weDAwMDAwMDAwNjQwMDAwMDAKCUxp bWl0QWRkcmVzcz0weDAwMDAwMDAwNjgzZmZmZmYKCURldmljZSBTY29wZToKCQlUeXBlPVBDSSBF bmRwb2ludCBEZXZpY2UKCQlMZW5ndGg9OAoJCUVudW1lcmF0aW9uSWQ9MAoJCVN0YXJ0QnVzTnVt YmVyPTAKCQlQYXRoPXsyOjB9CiAqLwovKgogIFNTRFQ6IExlbmd0aD0xNjg1LCBSZXZpc2lvbj0y LCBDaGVja3N1bT0xNDMsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2 aXNpb249MHgwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgK ICovCi8qCiAgU1NEVDogTGVuZ3RoPTMyNCwgUmV2aXNpb249MiwgQ2hlY2tzdW09ODYsCglPRU1J RD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDAwLAoJQ3JlYXRv ciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVu Z3RoPTE1NywgUmV2aXNpb249MSwgQ2hlY2tzdW09NzEsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJs ZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJl dmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVuZ3RoPTk2LCBSZXZpc2lvbj0xLCBD aGVja3N1bT0yMjQsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNp b249MHgxLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICov Ci8qCiAgVUVGSTogTGVuZ3RoPTE1OTQsIFJldmlzaW9uPTEsIENoZWNrc3VtPTE2OSwKCU9FTUlE PUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDAsCglDcmVhdG9yIElE PUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MAogKi8KLyoKICBVRUZJOiBMZW5ndGg9OTIsIFJldmlz aW9uPTEsIENoZWNrc3VtPTg0LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VN IFJldmlzaW9uPTB4MCwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgwCiAqLwov KgogIFRQTTI6IExlbmd0aD03NiwgUmV2aXNpb249NCwgQ2hlY2tzdW09MjQ1LAoJT0VNSUQ9SFBR T0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MSwKCUNyZWF0b3IgSUQ9SFAs IENyZWF0b3IgUmV2aXNpb249MHgwCgkJQ29udHJvbEFyZWE9MAoJCVN0YXJ0TWV0aG9kPTYKICov Ci8qCiAgU1NEVDogTGVuZ3RoPTQ1NTUyLCBSZXZpc2lvbj0yLCBDaGVja3N1bT0yMzEsCglPRU1J RD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDAwLAoJQ3JlYXRv ciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVu Z3RoPTExMDk3LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0xMzgsCglPRU1JRD1IUFFPRU0sIE9FTSBU YWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgzMDAwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVh dG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgUFREVDogTGVuZ3RoPTMzMjYsIFJldmlz aW9uPTAsIENoZWNrc3VtPTEyNiwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9F TSBSZXZpc2lvbj0weDUsCglDcmVhdG9yIElEPUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMDAw ZAogKi8KLyoKICBXU01UOiBMZW5ndGg9NDAsIFJldmlzaW9uPTEsIENoZWNrc3VtPTcwLAoJT0VN SUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAwOSwKCUNy ZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgxMDAxMwogKi8KLyoKICBGUERUOiBMZW5n dGg9NjgsIFJldmlzaW9uPTEsIENoZWNrc3VtPTE1LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUg SUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAwOSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3Ig UmV2aXNpb249MHgxMDAwMDEzCiAqLwovKgogIEJHUlQ6IExlbmd0aD01NiwgUmV2aXNpb249MSwg Q2hlY2tzdW09MjA1LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlz aW9uPTB4MTA3MjAwOSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgxMDAxMwog Ki8K --=_d3c477c3f144d2b9a03ca9c8b269190d Content-Transfer-Encoding: base64 Content-Type: text/plain; name=pcidump Content-Disposition: attachment; filename=pcidump; size=5467 aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIHJldj0weDAxIGhkcj0weDAwIHZlbmRv cj0weDgwODYgZGV2aWNlPTB4OWExNCBzdWJ2ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkK ICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzEx dGggR2VuIENvcmUgUHJvY2Vzc29yIEhvc3QgQnJpZGdlL0RSQU0gUmVnaXN0ZXJzJwogICAgY2xh c3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCnZnYXBjaTBAcGNpMDow OjI6MDoJY2xhc3M9MHgwMzAwMDAgcmV2PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHg5YTQ5IHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVUhEIEdyYXBoaWNzJwog ICAgY2xhc3MgICAgICA9IGRpc3BsYXkKICAgIHN1YmNsYXNzICAgPSBWR0EKbm9uZTBAcGNpMDow OjQ6MDoJY2xhc3M9MHgxMTgwMDAgcmV2PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHg5YTAzIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBkYXNwCnBjaWIxQHBjaTA6 MDo3OjA6CWNsYXNzPTB4MDYwNDAwIHJldj0weDAxIGhkcj0weDAxIHZlbmRvcj0weDgwODYgZGV2 aWNlPTB4OWEyMyBzdWJ2ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAg VGh1bmRlcmJvbHQgUENJIEV4cHJlc3MgUm9vdCBQb3J0JwogICAgY2xhc3MgICAgICA9IGJyaWRn ZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKcGNpYjJAcGNpMDowOjc6MToJY2xhc3M9MHgwNjA0 MDAgcmV2PTB4MDEgaGRyPTB4MDEgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHg5YTI1IHN1YnZlbmRv cj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBUaHVuZGVyYm9sdCBQQ0kgRXhw cmVzcyBSb290IFBvcnQnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0g UENJLVBDSQpub25lMUBwY2kwOjA6ODowOgljbGFzcz0weDA4ODAwMCByZXY9MHgwMSBoZHI9MHgw MCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDlhMTEgc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9 MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAg ICA9IGJhc2UgcGVyaXBoZXJhbAp4aGNpMEBwY2kwOjA6MTM6MDoJY2xhc3M9MHgwYzAzMzAgcmV2 PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHg5YTEzIHN1YnZlbmRvcj0weDEw M2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicK ICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBUaHVuZGVyYm9sdCBVU0IgQ29udHJvbGxl cicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCm5vbmUy QHBjaTA6MDoxMzoyOgljbGFzcz0weDBjMDM0MCByZXY9MHgwMSBoZHI9MHgwMCB2ZW5kb3I9MHg4 MDg2IGRldmljZT0weDlhMWIgc3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAwCiAgICB2 ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdUaWdlciBM YWtlLUxQIFRodW5kZXJib2x0IE5ISScKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBz dWJjbGFzcyAgID0gVVNCCm5vbmUzQHBjaTA6MDoxNDowOgljbGFzcz0weDAxMDQwMCByZXY9MHgw MCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDlhMGIgc3VidmVuZG9yPTB4ODA4NiBz dWJkZXZpY2U9MHgwMDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg ZGV2aWNlICAgICA9ICdWb2x1bWUgTWFuYWdlbWVudCBEZXZpY2UgTlZNZSBSQUlEIENvbnRyb2xs ZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyAgID0gUkFJRApu b25lNEBwY2kwOjA6MTg6MDoJY2xhc3M9MHgwNzAwMDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9y PTB4ODA4NiBkZXZpY2U9MHhhMGZjIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQog ICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGln ZXIgTGFrZS1MUCBJbnRlZ3JhdGVkIFNlbnNvciBIdWInCiAgICBjbGFzcyAgICAgID0gc2ltcGxl IGNvbW1zCiAgICBzdWJjbGFzcyAgID0gVUFSVAp4aGNpMUBwY2kwOjA6MjA6MDoJY2xhc3M9MHgw YzAzMzAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGVkIHN1YnZl bmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBVU0IgMy4yIEdlbiAyeDEg eEhDSSBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3Vi Y2xhc3MgICA9IFVTQgpub25lNUBwY2kwOjA6MjA6MjoJY2xhc3M9MHgwNTAwMDAgcmV2PTB4MjAg aGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGVmIHN1YnZlbmRvcj0weDEwM2Mgc3Vi ZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRl dmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBTaGFyZWQgU1JBTScKICAgIGNsYXNzICAgICAgPSBt ZW1vcnkKICAgIHN1YmNsYXNzICAgPSBSQU0Kbm9uZTZAcGNpMDowOjIwOjM6CWNsYXNzPTB4MDI4 MDAwIHJldj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBmMCBzdWJ2ZW5k b3I9MHg4MDg2IHN1YmRldmljZT0weDAwNzQKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1dpLUZpIDYgQVgyMDEnCiAgICBjbGFzcyAgICAgID0g bmV0d29yawppZzRpaWMwQHBjaTA6MDoyMTowOgljbGFzcz0weDBjODAwMCByZXY9MHgyMCBoZHI9 MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weGEwZTggc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZp Y2U9MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNl ICAgICA9ICdUaWdlciBMYWtlLUxQIFNlcmlhbCBJTyBJMkMgQ29udHJvbGxlcicKICAgIGNsYXNz ICAgICAgPSBzZXJpYWwgYnVzCmlnNGlpYzFAcGNpMDowOjIxOjE6CWNsYXNzPTB4MGM4MDAwIHJl dj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBlOSBzdWJ2ZW5kb3I9MHgx MDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24n CiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAgU2VyaWFsIElPIEkyQyBDb250cm9sbGVy JwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKbm9uZTdAcGNpMDowOjIyOjA6CWNsYXNzPTB4 MDc4MDAwIHJldj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBlMCBzdWJ2 ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29y cG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAgTWFuYWdlbWVudCBFbmdp bmUgSW50ZXJmYWNlJwogICAgY2xhc3MgICAgICA9IHNpbXBsZSBjb21tcwpwY2liM0BwY2kwOjA6 Mjg6MDoJY2xhc3M9MHgwNjA0MDAgcmV2PTB4MjAgaGRyPTB4MDEgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHhhMGJkIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNs YXNzICAgPSBQQ0ktUENJCm5vbmU4QHBjaTA6MDoyOTowOgljbGFzcz0weDA4ODAwMCByZXY9MHgw MCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDA5YWIgc3VidmVuZG9yPTB4MTAzYyBz dWJkZXZpY2U9MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg Y2xhc3MgICAgICA9IGJhc2UgcGVyaXBoZXJhbAppc2FiMEBwY2kwOjA6MzE6MDoJY2xhc3M9MHgw NjAxMDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMDgyIHN1YnZl bmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBMUEMgQ29udHJvbGxlcicK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNBCmhkYWMwQHBj aTA6MDozMTozOgljbGFzcz0weDA0MDEwMCByZXY9MHgyMCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2 IGRldmljZT0weGEwYzggc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9MHg4NzA5CiAgICB2ZW5k b3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdUaWdlciBMYWtl LUxQIFNtYXJ0IFNvdW5kIFRlY2hub2xvZ3kgQXVkaW8gQ29udHJvbGxlcicKICAgIGNsYXNzICAg ICAgPSBtdWx0aW1lZGlhCiAgICBzdWJjbGFzcyAgID0gYXVkaW8KaWNoc21iMEBwY2kwOjA6MzE6 NDoJY2xhc3M9MHgwYzA1MDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9 MHhhMGEzIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBTTUJ1 cyBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAg PSBTTUJ1cwpub25lOUBwY2kwOjA6MzE6NToJY2xhc3M9MHgwYzgwMDAgcmV2PTB4MjAgaGRyPTB4 MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGE0IHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNl PTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAg ICAgPSAnVGlnZXIgTGFrZS1MUCBTUEkgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJp YWwgYnVzCnJ0c3gwQHBjaTA6ODc6MDowOgljbGFzcz0weGZmMDAwMCByZXY9MHgwMSBoZHI9MHgw MCB2ZW5kb3I9MHgxMGVjIGRldmljZT0weDUyNWEgc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9 MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ1JlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0ZC4n CiAgICBkZXZpY2UgICAgID0gJ1JUUzUyNUEgUENJIEV4cHJlc3MgQ2FyZCBSZWFkZXInCg== --=_d3c477c3f144d2b9a03ca9c8b269190d-- From owner-freebsd-hackers@freebsd.org Thu Dec 31 02:14: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 077434D89D2; Thu, 31 Dec 2020 02:14:40 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (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 4D5sDH0wxFz3LGY; Thu, 31 Dec 2020 02:14:38 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id BA200EB2A5; Wed, 30 Dec 2020 18:14:36 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 18:14:36 -0800 From: Neel Chauhan To: Chuck Tuffli Cc: freebsd-hackers@freebsd.org, FreeBSD-Current Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch In-Reply-To: <3c55d6d50b1bcf1d45d4599502060f34@neelc.org> References: <3c55d6d50b1bcf1d45d4599502060f34@neelc.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: neel@neelc.org Content-Type: multipart/mixed; boundary="=_2d58dca25f95ab28b533ae54b1567b6b" X-Rspamd-Queue-Id: 4D5sDH0wxFz3LGY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 66.42.69.219 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-1.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; ASN(0.00)[asn:20473, ipnet:66.42.64.0/20, country:US]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 02:14:40 -0000 --=_2d58dca25f95ab28b533ae54b1567b6b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I have attached two files: * pcidump.txt: A dump of `pciconf -lv` * acpidump.txt: A dump of `acpidump` Hope this can help. -Neel On 2020-12-30 17:21, Neel Chauhan wrote: > To extend, I am getting an issue with `pci_read_device()` where it > returns a `vid` (PCI Vendor ID) of 0xffff. > > This ends up returning "Cannot allocate dinfo!" from vmd. > > Log (via grep): https://imgur.com/a/tAmmY7i > > -Neel > > On 2020-12-30 16:38, Neel Chauhan wrote: >> Hi Chuck, >> >> On 2020-12-30 10:04, Chuck Tuffli wrote: >>> What is the output from >>> # pciconf -rb pci0:0:14:0 0x40:0x48 >> >> The output is: >> >> 01 00 00 00 01 2e 68 02 00 >> >>> --chuck >> >> I was also able to stop kernel panics by adding: >> >> rman_fini(&sc->vmd_bus.rman); >> >> In the fail: statement in vmd_attach(). >> >> But I still cannot detect the SSD. >> >> -Neel >> _______________________________________________ >> 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" > _______________________________________________ > 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" --=_2d58dca25f95ab28b533ae54b1567b6b Content-Transfer-Encoding: base64 Content-Type: text/plain; name=pcidump.txt Content-Disposition: attachment; filename=pcidump.txt; size=5467 aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIHJldj0weDAxIGhkcj0weDAwIHZlbmRv cj0weDgwODYgZGV2aWNlPTB4OWExNCBzdWJ2ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkK ICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzEx dGggR2VuIENvcmUgUHJvY2Vzc29yIEhvc3QgQnJpZGdlL0RSQU0gUmVnaXN0ZXJzJwogICAgY2xh c3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCnZnYXBjaTBAcGNpMDow OjI6MDoJY2xhc3M9MHgwMzAwMDAgcmV2PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHg5YTQ5IHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVUhEIEdyYXBoaWNzJwog ICAgY2xhc3MgICAgICA9IGRpc3BsYXkKICAgIHN1YmNsYXNzICAgPSBWR0EKbm9uZTBAcGNpMDow OjQ6MDoJY2xhc3M9MHgxMTgwMDAgcmV2PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHg5YTAzIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBkYXNwCnBjaWIxQHBjaTA6 MDo3OjA6CWNsYXNzPTB4MDYwNDAwIHJldj0weDAxIGhkcj0weDAxIHZlbmRvcj0weDgwODYgZGV2 aWNlPTB4OWEyMyBzdWJ2ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAg VGh1bmRlcmJvbHQgUENJIEV4cHJlc3MgUm9vdCBQb3J0JwogICAgY2xhc3MgICAgICA9IGJyaWRn ZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKcGNpYjJAcGNpMDowOjc6MToJY2xhc3M9MHgwNjA0 MDAgcmV2PTB4MDEgaGRyPTB4MDEgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHg5YTI1IHN1YnZlbmRv cj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBUaHVuZGVyYm9sdCBQQ0kgRXhw cmVzcyBSb290IFBvcnQnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0g UENJLVBDSQpub25lMUBwY2kwOjA6ODowOgljbGFzcz0weDA4ODAwMCByZXY9MHgwMSBoZHI9MHgw MCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDlhMTEgc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9 MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAg ICA9IGJhc2UgcGVyaXBoZXJhbAp4aGNpMEBwY2kwOjA6MTM6MDoJY2xhc3M9MHgwYzAzMzAgcmV2 PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHg5YTEzIHN1YnZlbmRvcj0weDEw M2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicK ICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBUaHVuZGVyYm9sdCBVU0IgQ29udHJvbGxl cicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCm5vbmUy QHBjaTA6MDoxMzoyOgljbGFzcz0weDBjMDM0MCByZXY9MHgwMSBoZHI9MHgwMCB2ZW5kb3I9MHg4 MDg2IGRldmljZT0weDlhMWIgc3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAwCiAgICB2 ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdUaWdlciBM YWtlLUxQIFRodW5kZXJib2x0IE5ISScKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBz dWJjbGFzcyAgID0gVVNCCm5vbmUzQHBjaTA6MDoxNDowOgljbGFzcz0weDAxMDQwMCByZXY9MHgw MCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDlhMGIgc3VidmVuZG9yPTB4ODA4NiBz dWJkZXZpY2U9MHgwMDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg ZGV2aWNlICAgICA9ICdWb2x1bWUgTWFuYWdlbWVudCBEZXZpY2UgTlZNZSBSQUlEIENvbnRyb2xs ZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyAgID0gUkFJRApu b25lNEBwY2kwOjA6MTg6MDoJY2xhc3M9MHgwNzAwMDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9y PTB4ODA4NiBkZXZpY2U9MHhhMGZjIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQog ICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGln ZXIgTGFrZS1MUCBJbnRlZ3JhdGVkIFNlbnNvciBIdWInCiAgICBjbGFzcyAgICAgID0gc2ltcGxl IGNvbW1zCiAgICBzdWJjbGFzcyAgID0gVUFSVAp4aGNpMUBwY2kwOjA6MjA6MDoJY2xhc3M9MHgw YzAzMzAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGVkIHN1YnZl bmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBVU0IgMy4yIEdlbiAyeDEg eEhDSSBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3Vi Y2xhc3MgICA9IFVTQgpub25lNUBwY2kwOjA6MjA6MjoJY2xhc3M9MHgwNTAwMDAgcmV2PTB4MjAg aGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGVmIHN1YnZlbmRvcj0weDEwM2Mgc3Vi ZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRl dmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBTaGFyZWQgU1JBTScKICAgIGNsYXNzICAgICAgPSBt ZW1vcnkKICAgIHN1YmNsYXNzICAgPSBSQU0Kbm9uZTZAcGNpMDowOjIwOjM6CWNsYXNzPTB4MDI4 MDAwIHJldj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBmMCBzdWJ2ZW5k b3I9MHg4MDg2IHN1YmRldmljZT0weDAwNzQKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1dpLUZpIDYgQVgyMDEnCiAgICBjbGFzcyAgICAgID0g bmV0d29yawppZzRpaWMwQHBjaTA6MDoyMTowOgljbGFzcz0weDBjODAwMCByZXY9MHgyMCBoZHI9 MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weGEwZTggc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZp Y2U9MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNl ICAgICA9ICdUaWdlciBMYWtlLUxQIFNlcmlhbCBJTyBJMkMgQ29udHJvbGxlcicKICAgIGNsYXNz ICAgICAgPSBzZXJpYWwgYnVzCmlnNGlpYzFAcGNpMDowOjIxOjE6CWNsYXNzPTB4MGM4MDAwIHJl dj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBlOSBzdWJ2ZW5kb3I9MHgx MDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24n CiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAgU2VyaWFsIElPIEkyQyBDb250cm9sbGVy JwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKbm9uZTdAcGNpMDowOjIyOjA6CWNsYXNzPTB4 MDc4MDAwIHJldj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBlMCBzdWJ2 ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29y cG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAgTWFuYWdlbWVudCBFbmdp bmUgSW50ZXJmYWNlJwogICAgY2xhc3MgICAgICA9IHNpbXBsZSBjb21tcwpwY2liM0BwY2kwOjA6 Mjg6MDoJY2xhc3M9MHgwNjA0MDAgcmV2PTB4MjAgaGRyPTB4MDEgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHhhMGJkIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNs YXNzICAgPSBQQ0ktUENJCm5vbmU4QHBjaTA6MDoyOTowOgljbGFzcz0weDA4ODAwMCByZXY9MHgw MCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDA5YWIgc3VidmVuZG9yPTB4MTAzYyBz dWJkZXZpY2U9MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg Y2xhc3MgICAgICA9IGJhc2UgcGVyaXBoZXJhbAppc2FiMEBwY2kwOjA6MzE6MDoJY2xhc3M9MHgw NjAxMDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMDgyIHN1YnZl bmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBMUEMgQ29udHJvbGxlcicK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNBCmhkYWMwQHBj aTA6MDozMTozOgljbGFzcz0weDA0MDEwMCByZXY9MHgyMCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2 IGRldmljZT0weGEwYzggc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9MHg4NzA5CiAgICB2ZW5k b3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdUaWdlciBMYWtl LUxQIFNtYXJ0IFNvdW5kIFRlY2hub2xvZ3kgQXVkaW8gQ29udHJvbGxlcicKICAgIGNsYXNzICAg ICAgPSBtdWx0aW1lZGlhCiAgICBzdWJjbGFzcyAgID0gYXVkaW8KaWNoc21iMEBwY2kwOjA6MzE6 NDoJY2xhc3M9MHgwYzA1MDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9 MHhhMGEzIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBTTUJ1 cyBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAg PSBTTUJ1cwpub25lOUBwY2kwOjA6MzE6NToJY2xhc3M9MHgwYzgwMDAgcmV2PTB4MjAgaGRyPTB4 MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGE0IHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNl PTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAg ICAgPSAnVGlnZXIgTGFrZS1MUCBTUEkgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJp YWwgYnVzCnJ0c3gwQHBjaTA6ODc6MDowOgljbGFzcz0weGZmMDAwMCByZXY9MHgwMSBoZHI9MHgw MCB2ZW5kb3I9MHgxMGVjIGRldmljZT0weDUyNWEgc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9 MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ1JlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0ZC4n CiAgICBkZXZpY2UgICAgID0gJ1JUUzUyNUEgUENJIEV4cHJlc3MgQ2FyZCBSZWFkZXInCg== --=_2d58dca25f95ab28b533ae54b1567b6b Content-Transfer-Encoding: base64 Content-Type: text/plain; name=acpidump.txt Content-Disposition: attachment; filename=acpidump.txt; size=10947 LyoKICBSU0QgUFRSOiBPRU09SFBRT0VNLCBBQ1BJX1Jldj0yLjB4ICgyKQoJWFNEVD0weDAwMDAw MDAwNTRkYmI3MjgsIGxlbmd0aD0zNiwgY2tzdW09MjA2CiAqLwovKgogIFhTRFQ6IExlbmd0aD0y NzYsIFJldmlzaW9uPTEsIENoZWNrc3VtPTU0LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9 U0xJQy1NUEMsIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUFNSSwgQ3JlYXRv ciBSZXZpc2lvbj0weDEwMDAwMTMKCUVudHJpZXM9eyAweDAwMDAwMDAwNTRkYjYwMDAsIDB4MDAw MDAwMDA1NGRiYTAwMCwgMHgwMDAwMDAwMDU0ZGI3MDAwLCAweDAwMDAwMDAwNTRkNjEwMDAsIDB4 MDAwMDAwMDA1NGQ2MDAwMCwgMHgwMDAwMDAwMDU0ZDVjMDAwLCAweDAwMDAwMDAwNTRkNTUwMDAs IDB4MDAwMDAwMDA1NGQ0ODAwMCwgMHgwMDAwMDAwMDU0ZDQ3MDAwLCAweDAwMDAwMDAwNTRkNDUw MDAsIDB4MDAwMDAwMDA1NGQ0NDAwMCwgMHgwMDAwMDAwMDU0ZDQwMDAwLCAweDAwMDAwMDAwNTRk M2YwMDAsIDB4MDAwMDAwMDA1NGQzZTAwMCwgMHgwMDAwMDAwMDU0ZDNkMDAwLCAweDAwMDAwMDAw NTRkM2MwMDAsIDB4MDAwMDAwMDA1NGQzYjAwMCwgMHgwMDAwMDAwMDU0ZDNhMDAwLCAweDAwMDAw MDAwNTRkMzkwMDAsIDB4MDAwMDAwMDA1NGQzODAwMCwgMHgwMDAwMDAwMDU0ZDM3MDAwLCAweDAw MDAwMDAwNTRkZTYwMDAsIDB4MDAwMDAwMDA1NGRlNTAwMCwgMHgwMDAwMDAwMDU0ZDM2MDAwLCAw eDAwMDAwMDAwNTRkNDkwMDAsIDB4MDAwMDAwMDA1NGQ1OTAwMCwgMHgwMDAwMDAwMDU0ZDM1MDAw LCAweDAwMDAwMDAwNTRkNDMwMDAsIDB4MDAwMDAwMDA1NGQzNDAwMCwgMHgwMDAwMDAwMDU0ZDMz MDAwIH0KICovCi8qCiAgRkFDUDogTGVuZ3RoPTI3NiwgUmV2aXNpb249NiwgQ2hlY2tzdW09MTYz LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9U0xJQy1NUEMsIE9FTSBSZXZpc2lvbj0weDEw NzIwMDksCglDcmVhdG9yIElEPUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMTMKIAlGQUNTPTB4 NTRlNzcwMDAsIERTRFQ9MHg1NGQ2MjAwMAoJSU5UX01PREVMPVBJQwoJUHJlZmVycmVkX1BNX1By b2ZpbGU9TW9iaWxlICgyKQoJU0NJX0lOVD05CglTTUlfQ01EPTB4YjIsIEFDUElfRU5BQkxFPTB4 YTAsIEFDUElfRElTQUJMRT0weGExLCBTNEJJT1NfUkVRPTB4MAoJUFNUQVRFX0NOVD0weDAKCVBN MWFfRVZUX0JMSz0weDE4MDAtMHgxODAzCglQTTFhX0NOVF9CTEs9MHgxODA0LTB4MTgwNQoJUE0y X0NOVF9CTEs9MHgxODUwLTB4MTg1MAoJUE1fVE1SX0JMSz0weDE4MDgtMHgxODBiCglHUEUwX0JM Sz0weDE4NjAtMHgxODdmCglQX0xWTDJfTEFUPTEwMSB1cywgUF9MVkwzX0xBVD0xMDAxIHVzCglG TFVTSF9TSVpFPTEwMjQsIEZMVVNIX1NUUklERT0xNgoJRFVUWV9PRkZTRVQ9MSwgRFVUWV9XSURU SD0zCglEQVlfQUxSTT0xMywgTU9OX0FMUk09MCwgQ0VOVFVSWT01MAoJSUFQQ19CT09UX0FSQ0g9 ezgwNDIsTk9fQVNQTX0KCUZsYWdzPXtXQklOVkQsQzFfU1VQUE9SVEVELFNMRUVQX0JVVFRPTixT NF9SVENfV0FLRSxSRVNFVF9SRUdJU1RFUixQQ0lfRVhQUkVTU19XQUtFLFBMQVRGT1JNX0NMT0NL LFM0X1JUQ19WQUxJRCxSRU1PVEVfUE9XRVJfT04sTE9XX1BPV0VSX1MwfQoJUkVTRVRfUkVHPTB4 YjI6MFs4XSAoSU8pLCBSRVNFVF9WQUxVRT0weGViCiAqLwovKgogIEZBQ1M6CUxlbmd0aD02NCwg SHdTaWc9MHhjMGYxYmUyZiwgRmlybV9XYWtlX1ZlYz0weDAwMDAwMDAwCglHbG9iYWxfTG9jaz0K CUZsYWdzPQoJVmVyc2lvbj0yCiAqLwovKgogIERTRFQ6IExlbmd0aD0zNDE5MjQsIFJldmlzaW9u PTIsIENoZWNrc3VtPTE5NywKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBS ZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgy MDE5MTAxOAogKi8KLyoKICBNQ0ZHOiBMZW5ndGg9NjAsIFJldmlzaW9uPTEsIENoZWNrc3VtPTM3 LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAw OSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHg5NwoKCUJhc2UgQWRkcmVzcz0w eDAwMDAwMDAwYzAwMDAwMDAKCVNlZ21lbnQgR3JvdXA9MHgwMDAwCglTdGFydCBCdXM9MAoJRW5k IEJ1cz0yNTUKICovCi8qCiAgU1NEVDogTGVuZ3RoPTk2NzksIFJldmlzaW9uPTIsIENoZWNrc3Vt PTczLAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MzAw MCwKCUNyZWF0b3IgSUQ9QUNQSSwgQ3JlYXRvciBSZXZpc2lvbj0weDIwMTkxMDE4CiAqLwovKgog IEZJRFQ6IExlbmd0aD0xNTYsIFJldmlzaW9uPTEsIENoZWNrc3VtPTIxMCwKCU9FTUlEPUhQUU9F TSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElE PUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMTMKICovCi8qCiAgTVNETTogTGVuZ3RoPTg1LCBS ZXZpc2lvbj0zLCBDaGVja3N1bT0xOTYsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD1TTElD LU1QQywgT0VNIFJldmlzaW9uPTB4MSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249 MHgxMDAxMwogKi8KLyoKICBTU0RUOiBMZW5ndGg9MTMwNTYsIFJldmlzaW9uPTIsIENoZWNrc3Vt PTEwNywKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEw MDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgyMDE5MTAxOAogKi8KLyoK ICBTU0RUOiBMZW5ndGg9MTMxMzYsIFJldmlzaW9uPTIsIENoZWNrc3VtPTQxLAoJT0VNSUQ9SFBR T0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MzAwMCwKCUNyZWF0b3IgSUQ9 QUNQSSwgQ3JlYXRvciBSZXZpc2lvbj0weDIwMTkxMDE4CiAqLwovKgogIEhQRVQ6IExlbmd0aD01 NiwgUmV2aXNpb249MSwgQ2hlY2tzdW09MzIsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04 NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZp c2lvbj0weDEwMDAwMTMKCUhQRVQgTnVtYmVyPTAKCUFERFI9MHgwMDAwMDAwMGZlZDAwMDAwOjBb NjRdIChNZW1vcnkpCglIVyBSZXY9MHgxCglDb21wYXJhdG9ycz0yCglDb3VudGVyIFNpemU9MQoJ TGVnYWN5IElSUSByb3V0aW5nIGNhcGFibGU9e1RSVUV9CglQQ0kgVmVuZG9yIElEPTB4ODA4NgoJ TWluaW1hbCBUaWNrPTEyOAoJRmxhZ3M9MHgwMAogKi8KLyoKICBBUElDOiBMZW5ndGg9MzAwLCBS ZXZpc2lvbj00LCBDaGVja3N1bT0yNDIsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5 LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lv bj0weDEwMDAwMTMKCUxvY2FsIEFQSUMgQUREUj0weGZlZTAwMDAwCglGbGFncz17UEMtQVR9CgoJ VHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0wCglGbGFncz17RU5BQkxFRH0KCUFQSUMgSUQ9MAoK CVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9MQoJRmxhZ3M9e0VOQUJMRUR9CglBUElDIElEPTIK CglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTIKCUZsYWdzPXtFTkFCTEVEfQoJQVBJQyBJRD00 CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0zCglGbGFncz17RU5BQkxFRH0KCUFQSUMgSUQ9 NgoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9NAoJRmxhZ3M9e0VOQUJMRUR9CglBUElDIElE PTEKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTUKCUZsYWdzPXtFTkFCTEVEfQoJQVBJQyBJ RD0zCgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT02CglGbGFncz17RU5BQkxFRH0KCUFQSUMg SUQ9NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9NwoJRmxhZ3M9e0VOQUJMRUR9CglBUElD IElEPTcKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTgKCUZsYWdzPXtESVNBQkxFRH0KCUFQ SUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT05CglGbGFncz17RElTQUJMRUR9 CglBUElDIElEPTI1NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9MTAKCUZsYWdzPXtESVNB QkxFRH0KCUFQSUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0xMQoJRmxhZ3M9 e0RJU0FCTEVEfQoJQVBJQyBJRD0yNTUKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTEyCglG bGFncz17RElTQUJMRUR9CglBUElDIElEPTI1NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9 MTMKCUZsYWdzPXtESVNBQkxFRH0KCUFQSUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJ IENQVT0xNAoJRmxhZ3M9e0RJU0FCTEVEfQoJQVBJQyBJRD0yNTUKCglUeXBlPUxvY2FsIEFQSUMK CUFDUEkgQ1BVPTE1CglGbGFncz17RElTQUJMRUR9CglBUElDIElEPTI1NQoKCVR5cGU9SU8gQVBJ QwoJQVBJQyBJRD0yCglJTlQgQkFTRT0wCglBRERSPTB4MDAwMDAwMDBmZWMwMDAwMAoKCVR5cGU9 SU5UIE92ZXJyaWRlCglCVVM9MAoJSVJRPTAKCUlOVFI9MgoJRmxhZ3M9e1BvbGFyaXR5PWNvbmZv cm1pbmcsIFRyaWdnZXI9Y29uZm9ybWluZ30KCglUeXBlPUlOVCBPdmVycmlkZQoJQlVTPTAKCUlS UT05CglJTlRSPTkKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9bGV2ZWx9CgoJ VHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MQoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFy aXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkg Q1BVPTIKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRn ZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0zCglMSU5UIFBpbj0xCglGbGFncz17 UG9sYXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJ QUNQSSBDUFU9NAoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dl cj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkgQ1BVPTUKCUxJTlQgUGluPTEKCUZs YWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMg Tk1JCglBQ1BJIENQVT02CglMSU5UIFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBU cmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9NwoJTElOVCBQaW49 MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwg QVBJQyBOTUkKCUFDUEkgQ1BVPTgKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUt aGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT05CglMSU5U IFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1M b2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MTAKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1h Y3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0x MQoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoK CVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkgQ1BVPTEyCglMSU5UIFBpbj0xCglGbGFncz17UG9s YXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQ SSBDUFU9MTMKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9 ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0xNAoJTElOVCBQaW49MQoJRmxh Z3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBO TUkKCUFDUEkgQ1BVPTE1CglMSU5UIFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBU cmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MTYKCUxJTlQgUGlu PTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KICovCi8qCiAgTkhM VDogTGVuZ3RoPTcwNDQsIFJldmlzaW9uPTAsIENoZWNrc3VtPTExMywKCU9FTUlEPUhQUU9FTSwg T0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUhQ LCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMDAxMwogKi8KLyoKICBMUElUOiBMZW5ndGg9MjA0LCBS ZXZpc2lvbj0xLCBDaGVja3N1bT0xMjUsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5 LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lv bj0weDEwMDAwMTMKCglUeXBlPUFDUElfTFBJVF9UWVBFX05BVElWRV9DU1RBVEUKCUxlbmd0aD01 NgoJVW5pcXVlSWQ9MHgwMDAwCglGbGFncz0KCUVudHJ5VHJpZ2dlcj0weDAwMDAwMDAwMDAwMDAw NjAgKD8pCglSZXNpZGVuY3k9MzAwMDAKCUxhdGVuY3k9MzAwMAoJUmVzaWRlbmN5Q291bnRlcj0w eDAwMDAwMDAwMDAwMDA2MzIgKD8pCglDb3VudGVyRnJlcXVlbmN5PVRTQwoKCVR5cGU9QUNQSV9M UElUX1RZUEVfTkFUSVZFX0NTVEFURQoJTGVuZ3RoPTU2CglVbmlxdWVJZD0weDAwMDEKCUZsYWdz PQoJRW50cnlUcmlnZ2VyPTB4MDAwMDAwMDAwMDAwMDA2MCAoPykKCVJlc2lkZW5jeT0zMDAwMAoJ TGF0ZW5jeT0zMDAwCglSZXNpZGVuY3lDb3VudGVyPTB4MDAwMDAwMDBmZTAwMTkzYzowWzMyXSAo TWVtb3J5KQoJQ291bnRlckZyZXF1ZW5jeT04MTk3CgoJVHlwZT1BQ1BJX0xQSVRfVFlQRV9OQVRJ VkVfQ1NUQVRFCglMZW5ndGg9NTYKCVVuaXF1ZUlkPTB4MDAwMgoJRmxhZ3M9e1NUQVRFX0RJU0FC TEVEfQoJRW50cnlUcmlnZ2VyPTB4MDAwMDAwMDAwMDAwMDA2MCAoPykKCVJlc2lkZW5jeT0zMDAw MAoJTGF0ZW5jeT0zMDAwCglSZXNpZGVuY3lDb3VudGVyPTB4MDAwMDAwMDAwMDAwMDBmZjowWzMy XSAoTWVtb3J5KQoJQ291bnRlckZyZXF1ZW5jeT1UU0MKICovCi8qCiAgU1NEVDogTGVuZ3RoPTEw MDE2LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0zOCwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElE PTg3MDksIE9FTSBSZXZpc2lvbj0weDEwMDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2 aXNpb249MHgyMDE5MTAxOAogKi8KLyoKICBTU0RUOiBMZW5ndGg9Mjk4LCBSZXZpc2lvbj0yLCBD aGVja3N1bT0yNDAsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNp b249MHgwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICov Ci8qCiAgREJHUDogTGVuZ3RoPTUyLCBSZXZpc2lvbj0xLCBDaGVja3N1bT0xNjgsCglPRU1JRD1I UFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRv ciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMTMKICovCi8qCiAgREJHMjogTGVuZ3Ro PTg0LCBSZXZpc2lvbj0wLCBDaGVja3N1bT0yNDksCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJ RD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBS ZXZpc2lvbj0weDEwMDAwMTMKICovCi8qCiAgU1NEVDogTGVuZ3RoPTI5ODAsIFJldmlzaW9uPTIs IENoZWNrc3VtPTEwMCwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZp c2lvbj0weDEwMDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgyMDE5MTAx OAogKi8KLyoKICBETUFSOiBMZW5ndGg9MTg0LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0xOTEsCglP RU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgyLAoJQ3JlYXRv ciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMTMKCUhvc3QgQWRkcmVzcyBXaWR0aD0z OQoJRmxhZ3M9e0lOVFJfUkVNQVB9CgoJVHlwZT1EUkhECglMZW5ndGg9MjQKCUZsYWdzPQoJU2Vn bWVudD0wCglBZGRyZXNzPTB4MDAwMDAwMDBmZWQ5MDAwMAoJRGV2aWNlIFNjb3BlOgoJCVR5cGU9 UENJIEVuZHBvaW50IERldmljZQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezI6MH0KCglUeXBlPURSSEQKCUxlbmd0aD0yNAoJRmxhZ3M9CglT ZWdtZW50PTAKCUFkZHJlc3M9MHgwMDAwMDAwMGZlZDg0MDAwCglEZXZpY2UgU2NvcGU6CgkJVHlw ZT1QQ0kgU3ViLUhpZXJhcmNoeQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezc6MH0KCglUeXBlPURSSEQKCUxlbmd0aD0yNAoJRmxhZ3M9CglT ZWdtZW50PTAKCUFkZHJlc3M9MHgwMDAwMDAwMGZlZDg1MDAwCglEZXZpY2UgU2NvcGU6CgkJVHlw ZT1QQ0kgU3ViLUhpZXJhcmNoeQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezc6MX0KCglUeXBlPURSSEQKCUxlbmd0aD0zMgoJRmxhZ3M9e0lO Q0xVREVfQUxMfQoJU2VnbWVudD0wCglBZGRyZXNzPTB4MDAwMDAwMDBmZWQ5MTAwMAoJRGV2aWNl IFNjb3BlOgoJCVR5cGU9SU9BUElDCgkJTGVuZ3RoPTgKCQlFbnVtZXJhdGlvbklkPTIKCQlTdGFy dEJ1c051bWJlcj0wCgkJUGF0aD17MzA6N30KCgkJVHlwZT1IUEVUCgkJTGVuZ3RoPTgKCQlFbnVt ZXJhdGlvbklkPTAKCQlTdGFydEJ1c051bWJlcj0wCgkJUGF0aD17MzA6Nn0KCglUeXBlPVJNUlIK CUxlbmd0aD0zMgoJU2VnbWVudD0wCglCYXNlQWRkcmVzcz0weDAwMDAwMDAwNjQwMDAwMDAKCUxp bWl0QWRkcmVzcz0weDAwMDAwMDAwNjgzZmZmZmYKCURldmljZSBTY29wZToKCQlUeXBlPVBDSSBF bmRwb2ludCBEZXZpY2UKCQlMZW5ndGg9OAoJCUVudW1lcmF0aW9uSWQ9MAoJCVN0YXJ0QnVzTnVt YmVyPTAKCQlQYXRoPXsyOjB9CiAqLwovKgogIFNTRFQ6IExlbmd0aD0xNjg1LCBSZXZpc2lvbj0y LCBDaGVja3N1bT0xNDMsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2 aXNpb249MHgwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgK ICovCi8qCiAgU1NEVDogTGVuZ3RoPTMyNCwgUmV2aXNpb249MiwgQ2hlY2tzdW09ODYsCglPRU1J RD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDAwLAoJQ3JlYXRv ciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVu Z3RoPTE1NywgUmV2aXNpb249MSwgQ2hlY2tzdW09NzEsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJs ZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJl dmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVuZ3RoPTk2LCBSZXZpc2lvbj0xLCBD aGVja3N1bT0yMjQsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNp b249MHgxLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICov Ci8qCiAgVUVGSTogTGVuZ3RoPTE1OTQsIFJldmlzaW9uPTEsIENoZWNrc3VtPTE2OSwKCU9FTUlE PUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDAsCglDcmVhdG9yIElE PUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MAogKi8KLyoKICBVRUZJOiBMZW5ndGg9OTIsIFJldmlz aW9uPTEsIENoZWNrc3VtPTg0LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VN IFJldmlzaW9uPTB4MCwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgwCiAqLwov KgogIFRQTTI6IExlbmd0aD03NiwgUmV2aXNpb249NCwgQ2hlY2tzdW09MjQ1LAoJT0VNSUQ9SFBR T0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MSwKCUNyZWF0b3IgSUQ9SFAs IENyZWF0b3IgUmV2aXNpb249MHgwCgkJQ29udHJvbEFyZWE9MAoJCVN0YXJ0TWV0aG9kPTYKICov Ci8qCiAgU1NEVDogTGVuZ3RoPTQ1NTUyLCBSZXZpc2lvbj0yLCBDaGVja3N1bT0yMzEsCglPRU1J RD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDAwLAoJQ3JlYXRv ciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVu Z3RoPTExMDk3LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0xMzgsCglPRU1JRD1IUFFPRU0sIE9FTSBU YWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgzMDAwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVh dG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgUFREVDogTGVuZ3RoPTMzMjYsIFJldmlz aW9uPTAsIENoZWNrc3VtPTEyNiwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9F TSBSZXZpc2lvbj0weDUsCglDcmVhdG9yIElEPUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMDAw ZAogKi8KLyoKICBXU01UOiBMZW5ndGg9NDAsIFJldmlzaW9uPTEsIENoZWNrc3VtPTcwLAoJT0VN SUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAwOSwKCUNy ZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgxMDAxMwogKi8KLyoKICBGUERUOiBMZW5n dGg9NjgsIFJldmlzaW9uPTEsIENoZWNrc3VtPTE1LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUg SUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAwOSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3Ig UmV2aXNpb249MHgxMDAwMDEzCiAqLwovKgogIEJHUlQ6IExlbmd0aD01NiwgUmV2aXNpb249MSwg Q2hlY2tzdW09MjA1LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlz aW9uPTB4MTA3MjAwOSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgxMDAxMwog Ki8K --=_2d58dca25f95ab28b533ae54b1567b6b-- From owner-freebsd-hackers@freebsd.org Thu Dec 31 03:57:06 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 03B784DB2DB for ; Thu, 31 Dec 2020 03:57:06 +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 4D5vVT41d5z3hYC for ; Thu, 31 Dec 2020 03:57:05 +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 0BV3uoht029130 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Dec 2020 03:56:52 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: 000.fbsd@quip.cz Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 0BV3uhTi067825 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 31 Dec 2020 10:56:43 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Project information - SMBv2+ To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-hackers@freebsd.org References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> <704a700c-32ff-66eb-6711-5d75099abcd4@quip.cz> <20201230225624.atsnf6u5mmtcu5sw@nerd-thinkpad.local> <8644f79e-3957-3498-efa9-8fbfc7b57581@quip.cz> From: Eugene Grosbein Message-ID: <41400a64-5f0b-295b-399e-711b9b40b6d3@grosbein.net> Date: Thu, 31 Dec 2020 10:56:36 +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: <8644f79e-3957-3498-efa9-8fbfc7b57581@quip.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,LOCAL_FROM, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 * -3.4 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: 4D5vVT41d5z3hYC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 03:57:06 -0000 31.12.2020 6:33, Miroslav Lachman wrote: > Last time I tried smb with fuse it was unstable and does not allowed me > to configure what to mount where at boot time. > AFAIK fusefs-smbnetfs cannot be used the same way as mount_smbfs in fstab. > So I think smbnetfs is not usable solution in our environment even if it works stable and fast. What are you problems with fuse+fstab, exactly? Have you considered systax similar to the following example for net/glusterfs? gluster1:name /mnt/name fusefs rw,late,backup-volfile-servers=gluster2:gluster3,mountprog=/usr/local/sbin/mount_glusterfs 0 0 From owner-freebsd-hackers@freebsd.org Thu Dec 31 05:41: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 039D24DD458 for ; Thu, 31 Dec 2020 05:41:59 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (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 4D5xqV1q0Sz3nN0 for ; Thu, 31 Dec 2020 05:41:58 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id E5522EB2A5 for ; Wed, 30 Dec 2020 21:41:55 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 21:41:55 -0800 From: Neel Chauhan To: freebsd-hackers@freebsd.org Subject: PCIe Root Port/Bus Not Detected in VMD User-Agent: Roundcube Webmail/1.4.9 Message-ID: <9cb4a47a4899b3cccaab2028c1e81177@neelc.org> X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5xqV1q0Sz3nN0 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 66.42.69.219 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-1.80 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; R_SPF_ALLOW(-0.20)[+a:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; MID_RHS_MATCH_FROM(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:66.42.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 05:41:59 -0000 Hi freebsd-hackers@, My apologies for so many emails from me. I have the following patch: diff --git a/sys/dev/vmd/vmd.c b/sys/dev/vmd/vmd.c index 2cc6f45bed9..7cc0a8a91a7 100644 --- a/sys/dev/vmd/vmd.c +++ b/sys/dev/vmd/vmd.c @@ -66,10 +66,12 @@ struct vmd_type { #define INTEL_VENDOR_ID 0x8086 #define INTEL_DEVICE_ID_VMD 0x201d #define INTEL_DEVICE_ID_VMD2 0x28c0 +#define INTEL_DEVICE_ID_VMD3 0x9a0b static struct vmd_type vmd_devs[] = { { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume Management Device" }, { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume Management Device" }, + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume Management Device" }, { 0, 0, NULL } }; @@ -425,6 +427,7 @@ vmd_attach(device_t dev) return (0); fail: + rman_fini(&sc->vmd_bus.rman); vmd_free(sc); return (ENXIO); } This patch helps me detect the VMD controller, but I am unable to attach to it. Therefore, I am not able to attach any PCIe buses that will be used by a NVMe SSD. If this patch worked, I would see these devices (as I do in Linux): 10000:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI Express Root Port #9 [8086:a0b0] (rev 20) SI 10000:e0:1d.2 PCI bridge [0604]: Intel Corporation Device [8086:a0b2] (rev 20) 10000:e1:00.0 Non-Volatile memory controller [0108]: Intel Corporation Device [8086:0975] (rev 03) 10000:e2:00.0 Non-Volatile memory controller [0108]: Intel Corporation Device [8086:0975] And therefore a `nvd*` device. Could a developer please help me with this? -Neel === https://www.neelc.org/ From owner-freebsd-hackers@freebsd.org Thu Dec 31 05:45: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 5AA804DD67C for ; Thu, 31 Dec 2020 05:45:45 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (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 4D5xvr4MvPz3nr2 for ; Thu, 31 Dec 2020 05:45:44 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id CB8FCEB2A5 for ; Wed, 30 Dec 2020 21:45:42 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 21:45:42 -0800 From: Neel Chauhan To: freebsd-hackers@freebsd.org Subject: Re: PCIe Root Port/Bus Not Detected in VMD In-Reply-To: <9cb4a47a4899b3cccaab2028c1e81177@neelc.org> References: <9cb4a47a4899b3cccaab2028c1e81177@neelc.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <2709a4d62bb369257cab98e1d446520c@neelc.org> X-Sender: neel@neelc.org Content-Type: multipart/mixed; boundary="=_f957e90ef874fca7759daf4de03c9f2d" X-Rspamd-Queue-Id: 4D5xvr4MvPz3nr2 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 66.42.69.219 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [0.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.986]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; ASN(0.00)[asn:20473, ipnet:66.42.64.0/20, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 05:45:45 -0000 --=_f957e90ef874fca7759daf4de03c9f2d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed For reference, I am attaching the `pciconf -lv` and `acpidump -dt` dumps. -Neel On 2020-12-30 21:41, Neel Chauhan wrote: > Hi freebsd-hackers@, > > My apologies for so many emails from me. > > I have the following patch: > > diff --git a/sys/dev/vmd/vmd.c b/sys/dev/vmd/vmd.c > index 2cc6f45bed9..7cc0a8a91a7 100644 > --- a/sys/dev/vmd/vmd.c > +++ b/sys/dev/vmd/vmd.c > @@ -66,10 +66,12 @@ struct vmd_type { > #define INTEL_VENDOR_ID 0x8086 > #define INTEL_DEVICE_ID_VMD 0x201d > #define INTEL_DEVICE_ID_VMD2 0x28c0 > +#define INTEL_DEVICE_ID_VMD3 0x9a0b > > static struct vmd_type vmd_devs[] = { > { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume > Management Device" }, > { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume > Management Device" }, > + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume > Management Device" }, > { 0, 0, NULL } > }; > > @@ -425,6 +427,7 @@ vmd_attach(device_t dev) > return (0); > > fail: > + rman_fini(&sc->vmd_bus.rman); > vmd_free(sc); > return (ENXIO); > } > > This patch helps me detect the VMD controller, but I am unable to > attach to it. > > Therefore, I am not able to attach any PCIe buses that will be used by > a NVMe SSD. > > If this patch worked, I would see these devices (as I do in Linux): > > 10000:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI > Express Root Port #9 [8086:a0b0] (rev 20) SI > 10000:e0:1d.2 PCI bridge [0604]: Intel Corporation Device [8086:a0b2] > (rev 20) > 10000:e1:00.0 Non-Volatile memory controller [0108]: Intel Corporation > Device [8086:0975] (rev 03) > 10000:e2:00.0 Non-Volatile memory controller [0108]: Intel Corporation > Device [8086:0975] > > And therefore a `nvd*` device. > > Could a developer please help me with this? > > -Neel > > === > > https://www.neelc.org/ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" --=_f957e90ef874fca7759daf4de03c9f2d Content-Transfer-Encoding: base64 Content-Type: text/plain; name=acpidump.txt Content-Disposition: attachment; filename=acpidump.txt; size=10947 LyoKICBSU0QgUFRSOiBPRU09SFBRT0VNLCBBQ1BJX1Jldj0yLjB4ICgyKQoJWFNEVD0weDAwMDAw MDAwNTRkYmI3MjgsIGxlbmd0aD0zNiwgY2tzdW09MjA2CiAqLwovKgogIFhTRFQ6IExlbmd0aD0y NzYsIFJldmlzaW9uPTEsIENoZWNrc3VtPTU0LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9 U0xJQy1NUEMsIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUFNSSwgQ3JlYXRv ciBSZXZpc2lvbj0weDEwMDAwMTMKCUVudHJpZXM9eyAweDAwMDAwMDAwNTRkYjYwMDAsIDB4MDAw MDAwMDA1NGRiYTAwMCwgMHgwMDAwMDAwMDU0ZGI3MDAwLCAweDAwMDAwMDAwNTRkNjEwMDAsIDB4 MDAwMDAwMDA1NGQ2MDAwMCwgMHgwMDAwMDAwMDU0ZDVjMDAwLCAweDAwMDAwMDAwNTRkNTUwMDAs IDB4MDAwMDAwMDA1NGQ0ODAwMCwgMHgwMDAwMDAwMDU0ZDQ3MDAwLCAweDAwMDAwMDAwNTRkNDUw MDAsIDB4MDAwMDAwMDA1NGQ0NDAwMCwgMHgwMDAwMDAwMDU0ZDQwMDAwLCAweDAwMDAwMDAwNTRk M2YwMDAsIDB4MDAwMDAwMDA1NGQzZTAwMCwgMHgwMDAwMDAwMDU0ZDNkMDAwLCAweDAwMDAwMDAw NTRkM2MwMDAsIDB4MDAwMDAwMDA1NGQzYjAwMCwgMHgwMDAwMDAwMDU0ZDNhMDAwLCAweDAwMDAw MDAwNTRkMzkwMDAsIDB4MDAwMDAwMDA1NGQzODAwMCwgMHgwMDAwMDAwMDU0ZDM3MDAwLCAweDAw MDAwMDAwNTRkZTYwMDAsIDB4MDAwMDAwMDA1NGRlNTAwMCwgMHgwMDAwMDAwMDU0ZDM2MDAwLCAw eDAwMDAwMDAwNTRkNDkwMDAsIDB4MDAwMDAwMDA1NGQ1OTAwMCwgMHgwMDAwMDAwMDU0ZDM1MDAw LCAweDAwMDAwMDAwNTRkNDMwMDAsIDB4MDAwMDAwMDA1NGQzNDAwMCwgMHgwMDAwMDAwMDU0ZDMz MDAwIH0KICovCi8qCiAgRkFDUDogTGVuZ3RoPTI3NiwgUmV2aXNpb249NiwgQ2hlY2tzdW09MTYz LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9U0xJQy1NUEMsIE9FTSBSZXZpc2lvbj0weDEw NzIwMDksCglDcmVhdG9yIElEPUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMTMKIAlGQUNTPTB4 NTRlNzcwMDAsIERTRFQ9MHg1NGQ2MjAwMAoJSU5UX01PREVMPVBJQwoJUHJlZmVycmVkX1BNX1By b2ZpbGU9TW9iaWxlICgyKQoJU0NJX0lOVD05CglTTUlfQ01EPTB4YjIsIEFDUElfRU5BQkxFPTB4 YTAsIEFDUElfRElTQUJMRT0weGExLCBTNEJJT1NfUkVRPTB4MAoJUFNUQVRFX0NOVD0weDAKCVBN MWFfRVZUX0JMSz0weDE4MDAtMHgxODAzCglQTTFhX0NOVF9CTEs9MHgxODA0LTB4MTgwNQoJUE0y X0NOVF9CTEs9MHgxODUwLTB4MTg1MAoJUE1fVE1SX0JMSz0weDE4MDgtMHgxODBiCglHUEUwX0JM Sz0weDE4NjAtMHgxODdmCglQX0xWTDJfTEFUPTEwMSB1cywgUF9MVkwzX0xBVD0xMDAxIHVzCglG TFVTSF9TSVpFPTEwMjQsIEZMVVNIX1NUUklERT0xNgoJRFVUWV9PRkZTRVQ9MSwgRFVUWV9XSURU SD0zCglEQVlfQUxSTT0xMywgTU9OX0FMUk09MCwgQ0VOVFVSWT01MAoJSUFQQ19CT09UX0FSQ0g9 ezgwNDIsTk9fQVNQTX0KCUZsYWdzPXtXQklOVkQsQzFfU1VQUE9SVEVELFNMRUVQX0JVVFRPTixT NF9SVENfV0FLRSxSRVNFVF9SRUdJU1RFUixQQ0lfRVhQUkVTU19XQUtFLFBMQVRGT1JNX0NMT0NL LFM0X1JUQ19WQUxJRCxSRU1PVEVfUE9XRVJfT04sTE9XX1BPV0VSX1MwfQoJUkVTRVRfUkVHPTB4 YjI6MFs4XSAoSU8pLCBSRVNFVF9WQUxVRT0weGViCiAqLwovKgogIEZBQ1M6CUxlbmd0aD02NCwg SHdTaWc9MHhjMGYxYmUyZiwgRmlybV9XYWtlX1ZlYz0weDAwMDAwMDAwCglHbG9iYWxfTG9jaz0K CUZsYWdzPQoJVmVyc2lvbj0yCiAqLwovKgogIERTRFQ6IExlbmd0aD0zNDE5MjQsIFJldmlzaW9u PTIsIENoZWNrc3VtPTE5NywKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBS ZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgy MDE5MTAxOAogKi8KLyoKICBNQ0ZHOiBMZW5ndGg9NjAsIFJldmlzaW9uPTEsIENoZWNrc3VtPTM3 LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAw OSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHg5NwoKCUJhc2UgQWRkcmVzcz0w eDAwMDAwMDAwYzAwMDAwMDAKCVNlZ21lbnQgR3JvdXA9MHgwMDAwCglTdGFydCBCdXM9MAoJRW5k IEJ1cz0yNTUKICovCi8qCiAgU1NEVDogTGVuZ3RoPTk2NzksIFJldmlzaW9uPTIsIENoZWNrc3Vt PTczLAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MzAw MCwKCUNyZWF0b3IgSUQ9QUNQSSwgQ3JlYXRvciBSZXZpc2lvbj0weDIwMTkxMDE4CiAqLwovKgog IEZJRFQ6IExlbmd0aD0xNTYsIFJldmlzaW9uPTEsIENoZWNrc3VtPTIxMCwKCU9FTUlEPUhQUU9F TSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElE PUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMTMKICovCi8qCiAgTVNETTogTGVuZ3RoPTg1LCBS ZXZpc2lvbj0zLCBDaGVja3N1bT0xOTYsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD1TTElD LU1QQywgT0VNIFJldmlzaW9uPTB4MSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249 MHgxMDAxMwogKi8KLyoKICBTU0RUOiBMZW5ndGg9MTMwNTYsIFJldmlzaW9uPTIsIENoZWNrc3Vt PTEwNywKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEw MDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgyMDE5MTAxOAogKi8KLyoK ICBTU0RUOiBMZW5ndGg9MTMxMzYsIFJldmlzaW9uPTIsIENoZWNrc3VtPTQxLAoJT0VNSUQ9SFBR T0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MzAwMCwKCUNyZWF0b3IgSUQ9 QUNQSSwgQ3JlYXRvciBSZXZpc2lvbj0weDIwMTkxMDE4CiAqLwovKgogIEhQRVQ6IExlbmd0aD01 NiwgUmV2aXNpb249MSwgQ2hlY2tzdW09MzIsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04 NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZp c2lvbj0weDEwMDAwMTMKCUhQRVQgTnVtYmVyPTAKCUFERFI9MHgwMDAwMDAwMGZlZDAwMDAwOjBb NjRdIChNZW1vcnkpCglIVyBSZXY9MHgxCglDb21wYXJhdG9ycz0yCglDb3VudGVyIFNpemU9MQoJ TGVnYWN5IElSUSByb3V0aW5nIGNhcGFibGU9e1RSVUV9CglQQ0kgVmVuZG9yIElEPTB4ODA4NgoJ TWluaW1hbCBUaWNrPTEyOAoJRmxhZ3M9MHgwMAogKi8KLyoKICBBUElDOiBMZW5ndGg9MzAwLCBS ZXZpc2lvbj00LCBDaGVja3N1bT0yNDIsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5 LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lv bj0weDEwMDAwMTMKCUxvY2FsIEFQSUMgQUREUj0weGZlZTAwMDAwCglGbGFncz17UEMtQVR9CgoJ VHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0wCglGbGFncz17RU5BQkxFRH0KCUFQSUMgSUQ9MAoK CVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9MQoJRmxhZ3M9e0VOQUJMRUR9CglBUElDIElEPTIK CglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTIKCUZsYWdzPXtFTkFCTEVEfQoJQVBJQyBJRD00 CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0zCglGbGFncz17RU5BQkxFRH0KCUFQSUMgSUQ9 NgoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9NAoJRmxhZ3M9e0VOQUJMRUR9CglBUElDIElE PTEKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTUKCUZsYWdzPXtFTkFCTEVEfQoJQVBJQyBJ RD0zCgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT02CglGbGFncz17RU5BQkxFRH0KCUFQSUMg SUQ9NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9NwoJRmxhZ3M9e0VOQUJMRUR9CglBUElD IElEPTcKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTgKCUZsYWdzPXtESVNBQkxFRH0KCUFQ SUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT05CglGbGFncz17RElTQUJMRUR9 CglBUElDIElEPTI1NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9MTAKCUZsYWdzPXtESVNB QkxFRH0KCUFQSUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0xMQoJRmxhZ3M9 e0RJU0FCTEVEfQoJQVBJQyBJRD0yNTUKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTEyCglG bGFncz17RElTQUJMRUR9CglBUElDIElEPTI1NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9 MTMKCUZsYWdzPXtESVNBQkxFRH0KCUFQSUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJ IENQVT0xNAoJRmxhZ3M9e0RJU0FCTEVEfQoJQVBJQyBJRD0yNTUKCglUeXBlPUxvY2FsIEFQSUMK CUFDUEkgQ1BVPTE1CglGbGFncz17RElTQUJMRUR9CglBUElDIElEPTI1NQoKCVR5cGU9SU8gQVBJ QwoJQVBJQyBJRD0yCglJTlQgQkFTRT0wCglBRERSPTB4MDAwMDAwMDBmZWMwMDAwMAoKCVR5cGU9 SU5UIE92ZXJyaWRlCglCVVM9MAoJSVJRPTAKCUlOVFI9MgoJRmxhZ3M9e1BvbGFyaXR5PWNvbmZv cm1pbmcsIFRyaWdnZXI9Y29uZm9ybWluZ30KCglUeXBlPUlOVCBPdmVycmlkZQoJQlVTPTAKCUlS UT05CglJTlRSPTkKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9bGV2ZWx9CgoJ VHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MQoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFy aXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkg Q1BVPTIKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRn ZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0zCglMSU5UIFBpbj0xCglGbGFncz17 UG9sYXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJ QUNQSSBDUFU9NAoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dl cj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkgQ1BVPTUKCUxJTlQgUGluPTEKCUZs YWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMg Tk1JCglBQ1BJIENQVT02CglMSU5UIFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBU cmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9NwoJTElOVCBQaW49 MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwg QVBJQyBOTUkKCUFDUEkgQ1BVPTgKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUt aGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT05CglMSU5U IFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1M b2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MTAKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1h Y3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0x MQoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoK CVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkgQ1BVPTEyCglMSU5UIFBpbj0xCglGbGFncz17UG9s YXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQ SSBDUFU9MTMKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9 ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0xNAoJTElOVCBQaW49MQoJRmxh Z3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBO TUkKCUFDUEkgQ1BVPTE1CglMSU5UIFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBU cmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MTYKCUxJTlQgUGlu PTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KICovCi8qCiAgTkhM VDogTGVuZ3RoPTcwNDQsIFJldmlzaW9uPTAsIENoZWNrc3VtPTExMywKCU9FTUlEPUhQUU9FTSwg T0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUhQ LCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMDAxMwogKi8KLyoKICBMUElUOiBMZW5ndGg9MjA0LCBS ZXZpc2lvbj0xLCBDaGVja3N1bT0xMjUsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5 LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lv bj0weDEwMDAwMTMKCglUeXBlPUFDUElfTFBJVF9UWVBFX05BVElWRV9DU1RBVEUKCUxlbmd0aD01 NgoJVW5pcXVlSWQ9MHgwMDAwCglGbGFncz0KCUVudHJ5VHJpZ2dlcj0weDAwMDAwMDAwMDAwMDAw NjAgKD8pCglSZXNpZGVuY3k9MzAwMDAKCUxhdGVuY3k9MzAwMAoJUmVzaWRlbmN5Q291bnRlcj0w eDAwMDAwMDAwMDAwMDA2MzIgKD8pCglDb3VudGVyRnJlcXVlbmN5PVRTQwoKCVR5cGU9QUNQSV9M UElUX1RZUEVfTkFUSVZFX0NTVEFURQoJTGVuZ3RoPTU2CglVbmlxdWVJZD0weDAwMDEKCUZsYWdz PQoJRW50cnlUcmlnZ2VyPTB4MDAwMDAwMDAwMDAwMDA2MCAoPykKCVJlc2lkZW5jeT0zMDAwMAoJ TGF0ZW5jeT0zMDAwCglSZXNpZGVuY3lDb3VudGVyPTB4MDAwMDAwMDBmZTAwMTkzYzowWzMyXSAo TWVtb3J5KQoJQ291bnRlckZyZXF1ZW5jeT04MTk3CgoJVHlwZT1BQ1BJX0xQSVRfVFlQRV9OQVRJ VkVfQ1NUQVRFCglMZW5ndGg9NTYKCVVuaXF1ZUlkPTB4MDAwMgoJRmxhZ3M9e1NUQVRFX0RJU0FC TEVEfQoJRW50cnlUcmlnZ2VyPTB4MDAwMDAwMDAwMDAwMDA2MCAoPykKCVJlc2lkZW5jeT0zMDAw MAoJTGF0ZW5jeT0zMDAwCglSZXNpZGVuY3lDb3VudGVyPTB4MDAwMDAwMDAwMDAwMDBmZjowWzMy XSAoTWVtb3J5KQoJQ291bnRlckZyZXF1ZW5jeT1UU0MKICovCi8qCiAgU1NEVDogTGVuZ3RoPTEw MDE2LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0zOCwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElE PTg3MDksIE9FTSBSZXZpc2lvbj0weDEwMDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2 aXNpb249MHgyMDE5MTAxOAogKi8KLyoKICBTU0RUOiBMZW5ndGg9Mjk4LCBSZXZpc2lvbj0yLCBD aGVja3N1bT0yNDAsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNp b249MHgwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICov Ci8qCiAgREJHUDogTGVuZ3RoPTUyLCBSZXZpc2lvbj0xLCBDaGVja3N1bT0xNjgsCglPRU1JRD1I UFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRv ciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMTMKICovCi8qCiAgREJHMjogTGVuZ3Ro PTg0LCBSZXZpc2lvbj0wLCBDaGVja3N1bT0yNDksCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJ RD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBS ZXZpc2lvbj0weDEwMDAwMTMKICovCi8qCiAgU1NEVDogTGVuZ3RoPTI5ODAsIFJldmlzaW9uPTIs IENoZWNrc3VtPTEwMCwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZp c2lvbj0weDEwMDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgyMDE5MTAx OAogKi8KLyoKICBETUFSOiBMZW5ndGg9MTg0LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0xOTEsCglP RU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgyLAoJQ3JlYXRv ciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMTMKCUhvc3QgQWRkcmVzcyBXaWR0aD0z OQoJRmxhZ3M9e0lOVFJfUkVNQVB9CgoJVHlwZT1EUkhECglMZW5ndGg9MjQKCUZsYWdzPQoJU2Vn bWVudD0wCglBZGRyZXNzPTB4MDAwMDAwMDBmZWQ5MDAwMAoJRGV2aWNlIFNjb3BlOgoJCVR5cGU9 UENJIEVuZHBvaW50IERldmljZQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezI6MH0KCglUeXBlPURSSEQKCUxlbmd0aD0yNAoJRmxhZ3M9CglT ZWdtZW50PTAKCUFkZHJlc3M9MHgwMDAwMDAwMGZlZDg0MDAwCglEZXZpY2UgU2NvcGU6CgkJVHlw ZT1QQ0kgU3ViLUhpZXJhcmNoeQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezc6MH0KCglUeXBlPURSSEQKCUxlbmd0aD0yNAoJRmxhZ3M9CglT ZWdtZW50PTAKCUFkZHJlc3M9MHgwMDAwMDAwMGZlZDg1MDAwCglEZXZpY2UgU2NvcGU6CgkJVHlw ZT1QQ0kgU3ViLUhpZXJhcmNoeQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezc6MX0KCglUeXBlPURSSEQKCUxlbmd0aD0zMgoJRmxhZ3M9e0lO Q0xVREVfQUxMfQoJU2VnbWVudD0wCglBZGRyZXNzPTB4MDAwMDAwMDBmZWQ5MTAwMAoJRGV2aWNl IFNjb3BlOgoJCVR5cGU9SU9BUElDCgkJTGVuZ3RoPTgKCQlFbnVtZXJhdGlvbklkPTIKCQlTdGFy dEJ1c051bWJlcj0wCgkJUGF0aD17MzA6N30KCgkJVHlwZT1IUEVUCgkJTGVuZ3RoPTgKCQlFbnVt ZXJhdGlvbklkPTAKCQlTdGFydEJ1c051bWJlcj0wCgkJUGF0aD17MzA6Nn0KCglUeXBlPVJNUlIK CUxlbmd0aD0zMgoJU2VnbWVudD0wCglCYXNlQWRkcmVzcz0weDAwMDAwMDAwNjQwMDAwMDAKCUxp bWl0QWRkcmVzcz0weDAwMDAwMDAwNjgzZmZmZmYKCURldmljZSBTY29wZToKCQlUeXBlPVBDSSBF bmRwb2ludCBEZXZpY2UKCQlMZW5ndGg9OAoJCUVudW1lcmF0aW9uSWQ9MAoJCVN0YXJ0QnVzTnVt YmVyPTAKCQlQYXRoPXsyOjB9CiAqLwovKgogIFNTRFQ6IExlbmd0aD0xNjg1LCBSZXZpc2lvbj0y LCBDaGVja3N1bT0xNDMsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2 aXNpb249MHgwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgK ICovCi8qCiAgU1NEVDogTGVuZ3RoPTMyNCwgUmV2aXNpb249MiwgQ2hlY2tzdW09ODYsCglPRU1J RD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDAwLAoJQ3JlYXRv ciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVu Z3RoPTE1NywgUmV2aXNpb249MSwgQ2hlY2tzdW09NzEsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJs ZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJl dmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVuZ3RoPTk2LCBSZXZpc2lvbj0xLCBD aGVja3N1bT0yMjQsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNp b249MHgxLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICov Ci8qCiAgVUVGSTogTGVuZ3RoPTE1OTQsIFJldmlzaW9uPTEsIENoZWNrc3VtPTE2OSwKCU9FTUlE PUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDAsCglDcmVhdG9yIElE PUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MAogKi8KLyoKICBVRUZJOiBMZW5ndGg9OTIsIFJldmlz aW9uPTEsIENoZWNrc3VtPTg0LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VN IFJldmlzaW9uPTB4MCwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgwCiAqLwov KgogIFRQTTI6IExlbmd0aD03NiwgUmV2aXNpb249NCwgQ2hlY2tzdW09MjQ1LAoJT0VNSUQ9SFBR T0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MSwKCUNyZWF0b3IgSUQ9SFAs IENyZWF0b3IgUmV2aXNpb249MHgwCgkJQ29udHJvbEFyZWE9MAoJCVN0YXJ0TWV0aG9kPTYKICov Ci8qCiAgU1NEVDogTGVuZ3RoPTQ1NTUyLCBSZXZpc2lvbj0yLCBDaGVja3N1bT0yMzEsCglPRU1J RD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDAwLAoJQ3JlYXRv ciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVu Z3RoPTExMDk3LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0xMzgsCglPRU1JRD1IUFFPRU0sIE9FTSBU YWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgzMDAwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVh dG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgUFREVDogTGVuZ3RoPTMzMjYsIFJldmlz aW9uPTAsIENoZWNrc3VtPTEyNiwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9F TSBSZXZpc2lvbj0weDUsCglDcmVhdG9yIElEPUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMDAw ZAogKi8KLyoKICBXU01UOiBMZW5ndGg9NDAsIFJldmlzaW9uPTEsIENoZWNrc3VtPTcwLAoJT0VN SUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAwOSwKCUNy ZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgxMDAxMwogKi8KLyoKICBGUERUOiBMZW5n dGg9NjgsIFJldmlzaW9uPTEsIENoZWNrc3VtPTE1LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUg SUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAwOSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3Ig UmV2aXNpb249MHgxMDAwMDEzCiAqLwovKgogIEJHUlQ6IExlbmd0aD01NiwgUmV2aXNpb249MSwg Q2hlY2tzdW09MjA1LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlz aW9uPTB4MTA3MjAwOSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgxMDAxMwog Ki8K --=_f957e90ef874fca7759daf4de03c9f2d Content-Transfer-Encoding: base64 Content-Type: text/plain; name=pcidump.txt Content-Disposition: attachment; filename=pcidump.txt; size=5467 aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIHJldj0weDAxIGhkcj0weDAwIHZlbmRv cj0weDgwODYgZGV2aWNlPTB4OWExNCBzdWJ2ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkK ICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzEx dGggR2VuIENvcmUgUHJvY2Vzc29yIEhvc3QgQnJpZGdlL0RSQU0gUmVnaXN0ZXJzJwogICAgY2xh c3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCnZnYXBjaTBAcGNpMDow OjI6MDoJY2xhc3M9MHgwMzAwMDAgcmV2PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHg5YTQ5IHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVUhEIEdyYXBoaWNzJwog ICAgY2xhc3MgICAgICA9IGRpc3BsYXkKICAgIHN1YmNsYXNzICAgPSBWR0EKbm9uZTBAcGNpMDow OjQ6MDoJY2xhc3M9MHgxMTgwMDAgcmV2PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHg5YTAzIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBkYXNwCnBjaWIxQHBjaTA6 MDo3OjA6CWNsYXNzPTB4MDYwNDAwIHJldj0weDAxIGhkcj0weDAxIHZlbmRvcj0weDgwODYgZGV2 aWNlPTB4OWEyMyBzdWJ2ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAg VGh1bmRlcmJvbHQgUENJIEV4cHJlc3MgUm9vdCBQb3J0JwogICAgY2xhc3MgICAgICA9IGJyaWRn ZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKcGNpYjJAcGNpMDowOjc6MToJY2xhc3M9MHgwNjA0 MDAgcmV2PTB4MDEgaGRyPTB4MDEgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHg5YTI1IHN1YnZlbmRv cj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBUaHVuZGVyYm9sdCBQQ0kgRXhw cmVzcyBSb290IFBvcnQnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0g UENJLVBDSQpub25lMUBwY2kwOjA6ODowOgljbGFzcz0weDA4ODAwMCByZXY9MHgwMSBoZHI9MHgw MCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDlhMTEgc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9 MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAg ICA9IGJhc2UgcGVyaXBoZXJhbAp4aGNpMEBwY2kwOjA6MTM6MDoJY2xhc3M9MHgwYzAzMzAgcmV2 PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHg5YTEzIHN1YnZlbmRvcj0weDEw M2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicK ICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBUaHVuZGVyYm9sdCBVU0IgQ29udHJvbGxl cicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCm5vbmUy QHBjaTA6MDoxMzoyOgljbGFzcz0weDBjMDM0MCByZXY9MHgwMSBoZHI9MHgwMCB2ZW5kb3I9MHg4 MDg2IGRldmljZT0weDlhMWIgc3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAwCiAgICB2 ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdUaWdlciBM YWtlLUxQIFRodW5kZXJib2x0IE5ISScKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBz dWJjbGFzcyAgID0gVVNCCm5vbmUzQHBjaTA6MDoxNDowOgljbGFzcz0weDAxMDQwMCByZXY9MHgw MCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDlhMGIgc3VidmVuZG9yPTB4ODA4NiBz dWJkZXZpY2U9MHgwMDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg ZGV2aWNlICAgICA9ICdWb2x1bWUgTWFuYWdlbWVudCBEZXZpY2UgTlZNZSBSQUlEIENvbnRyb2xs ZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyAgID0gUkFJRApu b25lNEBwY2kwOjA6MTg6MDoJY2xhc3M9MHgwNzAwMDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9y PTB4ODA4NiBkZXZpY2U9MHhhMGZjIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQog ICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGln ZXIgTGFrZS1MUCBJbnRlZ3JhdGVkIFNlbnNvciBIdWInCiAgICBjbGFzcyAgICAgID0gc2ltcGxl IGNvbW1zCiAgICBzdWJjbGFzcyAgID0gVUFSVAp4aGNpMUBwY2kwOjA6MjA6MDoJY2xhc3M9MHgw YzAzMzAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGVkIHN1YnZl bmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBVU0IgMy4yIEdlbiAyeDEg eEhDSSBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3Vi Y2xhc3MgICA9IFVTQgpub25lNUBwY2kwOjA6MjA6MjoJY2xhc3M9MHgwNTAwMDAgcmV2PTB4MjAg aGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGVmIHN1YnZlbmRvcj0weDEwM2Mgc3Vi ZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRl dmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBTaGFyZWQgU1JBTScKICAgIGNsYXNzICAgICAgPSBt ZW1vcnkKICAgIHN1YmNsYXNzICAgPSBSQU0Kbm9uZTZAcGNpMDowOjIwOjM6CWNsYXNzPTB4MDI4 MDAwIHJldj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBmMCBzdWJ2ZW5k b3I9MHg4MDg2IHN1YmRldmljZT0weDAwNzQKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1dpLUZpIDYgQVgyMDEnCiAgICBjbGFzcyAgICAgID0g bmV0d29yawppZzRpaWMwQHBjaTA6MDoyMTowOgljbGFzcz0weDBjODAwMCByZXY9MHgyMCBoZHI9 MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weGEwZTggc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZp Y2U9MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNl ICAgICA9ICdUaWdlciBMYWtlLUxQIFNlcmlhbCBJTyBJMkMgQ29udHJvbGxlcicKICAgIGNsYXNz ICAgICAgPSBzZXJpYWwgYnVzCmlnNGlpYzFAcGNpMDowOjIxOjE6CWNsYXNzPTB4MGM4MDAwIHJl dj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBlOSBzdWJ2ZW5kb3I9MHgx MDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24n CiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAgU2VyaWFsIElPIEkyQyBDb250cm9sbGVy JwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKbm9uZTdAcGNpMDowOjIyOjA6CWNsYXNzPTB4 MDc4MDAwIHJldj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBlMCBzdWJ2 ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29y cG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAgTWFuYWdlbWVudCBFbmdp bmUgSW50ZXJmYWNlJwogICAgY2xhc3MgICAgICA9IHNpbXBsZSBjb21tcwpwY2liM0BwY2kwOjA6 Mjg6MDoJY2xhc3M9MHgwNjA0MDAgcmV2PTB4MjAgaGRyPTB4MDEgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHhhMGJkIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNs YXNzICAgPSBQQ0ktUENJCm5vbmU4QHBjaTA6MDoyOTowOgljbGFzcz0weDA4ODAwMCByZXY9MHgw MCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDA5YWIgc3VidmVuZG9yPTB4MTAzYyBz dWJkZXZpY2U9MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg Y2xhc3MgICAgICA9IGJhc2UgcGVyaXBoZXJhbAppc2FiMEBwY2kwOjA6MzE6MDoJY2xhc3M9MHgw NjAxMDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMDgyIHN1YnZl bmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBMUEMgQ29udHJvbGxlcicK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNBCmhkYWMwQHBj aTA6MDozMTozOgljbGFzcz0weDA0MDEwMCByZXY9MHgyMCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2 IGRldmljZT0weGEwYzggc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9MHg4NzA5CiAgICB2ZW5k b3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdUaWdlciBMYWtl LUxQIFNtYXJ0IFNvdW5kIFRlY2hub2xvZ3kgQXVkaW8gQ29udHJvbGxlcicKICAgIGNsYXNzICAg ICAgPSBtdWx0aW1lZGlhCiAgICBzdWJjbGFzcyAgID0gYXVkaW8KaWNoc21iMEBwY2kwOjA6MzE6 NDoJY2xhc3M9MHgwYzA1MDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9 MHhhMGEzIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBTTUJ1 cyBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAg PSBTTUJ1cwpub25lOUBwY2kwOjA6MzE6NToJY2xhc3M9MHgwYzgwMDAgcmV2PTB4MjAgaGRyPTB4 MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGE0IHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNl PTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAg ICAgPSAnVGlnZXIgTGFrZS1MUCBTUEkgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJp YWwgYnVzCnJ0c3gwQHBjaTA6ODc6MDowOgljbGFzcz0weGZmMDAwMCByZXY9MHgwMSBoZHI9MHgw MCB2ZW5kb3I9MHgxMGVjIGRldmljZT0weDUyNWEgc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9 MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ1JlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0ZC4n CiAgICBkZXZpY2UgICAgID0gJ1JUUzUyNUEgUENJIEV4cHJlc3MgQ2FyZCBSZWFkZXInCg== --=_f957e90ef874fca7759daf4de03c9f2d-- From owner-freebsd-hackers@freebsd.org Thu Dec 31 08:29: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 43B914B8971 for ; Thu, 31 Dec 2020 08:29:20 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D61Xb6Z2jz4SCx; Thu, 31 Dec 2020 08:29:19 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609403358; bh=zpoNoj3xJ2NTKxXqO5lgcsHFGOiZdEiLDplesij+ubs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ilyUtkmzW1flyH4vZU75N+pc6ZB8gP1bgWivmgICEdpUIe3666Dk+3ayEaWCwNQZD QflpgfbFg+/XqBmfedWbK4U3mWlMVXSNwORioQHO7+3X/x5TSmmgoF8fqpnayHi7pT SMY+y+j8MwENbphEttqcXH7yh58AbzrzdliyzE9o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [2.2.3.2] ([87.122.30.47]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MKsjH-1kZmTb050v-00LIIM; Thu, 31 Dec 2020 09:29:18 +0100 Subject: Re: Project information - SMBv2+ To: Alan Somers Cc: Daniel Ebdrup Jensen , "freebsd-hackers@freebsd.org" References: <20201230225624.atsnf6u5mmtcu5sw@nerd-thinkpad.local> <43C8B023-8DDF-4BA1-B9ED-483CB45B8E58@gmx.net> From: CerebrosuS Message-ID: <6b3c39cd-bb9f-6a0f-34c1-8cbaf8a25c37@gmx.net> Date: Thu, 31 Dec 2020 09:29:18 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:qzG+/0NcJIu+P//HjjxiqoW+RrsaJICQkJWhIlQK0jXoI/lDjN6 GQYlQhmUBFRof/I9SG45/mvqL9guxVil4rd0aAuK6bKg1oVSHp/N13mbqk5onFzax7RIez/ 0r6YWvOWz+Bx0y7sGd+YK8BdQw4um5+G+/541BSzN5f6MMdxKaTS+FcC5fIswpbLeiqywdV gZxu14hIfaA5I1HZfYGVA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Xga1uyFjIe0=:x4tNOXDKqxMY+EpOqmBpYx NiCx9aFrMf4yVY+WXPQhZWyVwSwWl8nUGMTYheQdx0Tfa93Ihisr1YYRBJXM7gYp+5Cyxz0Yc hQm7EXzTCgyeyLc/b6uQ1JiJGZx3tHStMmQOX+jhD7BtvTkEcQdSKXyCKMcdl2JXBNtVPfWls 9QCTI/59L0cV8HaGQYAcs3KpAiF6nXvlqcP5k6kk1inzXHf1VQyeccJ4HzurQWqwgumfVVyvn owO/MxNs9o6JIjeFloE6zIf5M/T9ppQYgPY8gC1x/4s5Qu/yN9rMuaJMvVLAWSiUOOaOr93/7 0kUKtqwSEpZtPIIjUJsYKjDiMPywBZ7CtSVYaUx9uPYD0EDszThPHUInuYNbNqZ2oWduIKEOM J5LPRJzXbP/YCDwfgGiWL8lPvUb15DEl3hFouCSsUxTl+GEztXVrd9hZIcb6bUluEPDWergpm KIo7l1rIhuJgndpVcYYp82ynvN3aI+mdFfZ6FAWbvlRSiAEsyhhk6ZJ9HoIzo6/rPI8e0dfXl KwLALfjmZY7nNtCUTZxHn1JYajG1OZFLpchYOvNhnjRmesrKvPz2T90AiKY0LARF1dAb6UGmz HmyFvg/GUtRYlFNniHtMdRzkm9FWyNtX2ipVf+HFbBquMD40ZMCdWa9w62hDg3dRObX5/apxD IPCt2T8XsEaXDyBoRWqqJZQ2ZEkityLAoUKPp95/aBDVCRpgqY1rXTWDr2K97nlDyFWuZGjY/ t32RQR4ZR9kmXXaPeoIvwkICTx+31HwULH79CnlKPdNdg9vzO4WSh2WPUlUoftwbR12AnsF6O 7zUQMw6owfMxtuWbq9mk3xR0vf9yOl2yqO46YbSziwJGkvUsUMrXTVQqWDbJNgc9TyZ9E+k/i v4Zjz4yx561OsH2tu06g== X-Rspamd-Queue-Id: 4D61Xb6Z2jz4SCx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 08:29:20 -0000 From the starting point I cannot imagine what might be the optimum in investing time and fitting all needs of FreeBSD folks. Cause for now my knowledge in samba/network and FreeBSD os-level programming is limited. This will come with time while working on it. And it might be a question the community should answer like: Should we optimize a third party smb client library or should the smbfs FreeBSD module be extended (or rewritten ... whatever)? I don't know how such a question gets its answer in the FreeBSD community. From my point of view: an external library might have better future support, cause developer of many os are working on it. But I would prefer a fixed solution inside FreeBSD cause it is more easy to handle and once implemented less influenced by outside opinions from evolution of other operating systems. Am 31.12.20 um 00:13 schrieb Alan Somers: > I notice that smbnetfs is still using libfuse-2. libfuse-3 uses a newer > protocol, with more features and better performance. If you want to hel= p > FreeBSD's SMB situation, your time might be more productively spent by > upgrading smbnetfs to libfuse-3. > -Alan > > On Wed, Dec 30, 2020 at 4:02 PM CerebrosuS wrote: > >> My experience with the fuse smbnetnfs is about a week old on FreeBSD 12= .2. >> >>> Am 30.12.2020 um 23:56 schrieb Daniel Ebdrup Jensen >> : >>> >>> =EF=BB=BFOn Wed, Dec 30, 2020 at 10:16:44PM +0100, Miroslav Lachman wr= ote: >>>>> On 30/12/2020 20:24, CerebrosuS wrote: >>>>> >>>>> >>>>> Am 30.12.20 um 20:05 schrieb Miroslav Lachman: >>>>>> On 30/12/2020 18:57, CerebrosuS wrote: >>>>>>> Hello at all, >>>>>>> >>>>>>> the community and developer at FreeBSD seem to know, that SMBv1 fo= r >>>>>>> clients is nearly over and that the included mount_smbfs doesn't >> support >>>>>>> newer versions. So good, so far... >>>>>>> >>>>>>> So I can find multiple information about the situation, but no cle= ar >>>>>>> path on how FreeBSD community and developer will go on to solve th= is >>>>>>> missing function. (Just got the information on: >>>>>>> >> https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSambaC= lient >> ) >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is what I am asking: >>>>>>> - Is there a project existing for solving this problem (with whate= ver >>>>>>> target)? >>>>>>> - What is the way to go in future? Extend mount_smbfs or support t= he >>>>>>> fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy a= nd >>>>>>> laggy here)? >>>>>>> - Who is mainly working on it, if a project already exist? >>>>>>> >>>>>>> I'am just interested, cause of not finding such information clearl= y. >> Is >>>>>>> there maybe a general project management list / team to see what >>>>>>> projects are going on in whatever state? >>>>>>> >>>>>>> I am a hobby developer mainly coming from chemical engineering sid= e, >>>>>>> having some time to help. I've already written some cross platform >>>>>>> software but never related to network or on os-level. So I am >> motivated >>>>>>> to invest some time in getting stuff into FreeBSD, but for me, the= re >> is >>>>>>> a lack on information (see above). >>>>>>> >>>>>>> Thank you in advance for information and help. >>>>>> >>>>>> I was involved in the thread linked by Gleb. AFAIK nothing changed >> from >>>>>> that time. I tried something from ports but it has more problems >> (shares >>>>>> cannot be mounted on boot like mount_smbfs does). >>>>>> If somebody has time and skills to try to bring SMBv2 or v3 to Free= BSD >>>>>> then Apple or Solaris sources is good start. The both were using th= e >>>>>> same mount_smbfs (v1) as FreeBSD so one can check their sources and >> see >>>>>> how they evolve to v2 / v3. >>>>> >>>>> They are both using exactly the same source code as a starting point >> and >>>>> extend it (or rewrite it) to SMBv2? >>>> >>>> They are based on the ported code. Apple Mac OS X and Solaris have >> different kernel so they needed modified port of the same code as was i= n >> FreeBSD back in the days (there is the same copyright header). Apple >> sources or Solaris sources cannot be used directly on FreeBSD but some >> skilled developer can look in to those sources to see their evolution. = But >> as was already noted v2 and v3 are very different from v1. It will be h= ard >> to port but not impossible. >>>> Current solutions in ports (fusefs) are almost useless in server >> environment. >>>> >>>> Miroslav Lachman >>>> >>>> _______________________________________________ >>>> 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" >>> >>> Hi folks, >>> >>> Assuming that the reasons for not using fuse in a server environment a= re >> related primarily to performance and that the implementation that was i= n >> base used to be quite out-of-date, has this at all been reevalulated si= nce >> a new version was merged? [1] >>> >>> Yours, >>> Daniel Ebdrup Jensen >>> >>> [1]: https://svnweb.freebsd.org/changeset/base/350665 >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" > From owner-freebsd-hackers@freebsd.org Thu Dec 31 10:13: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 E49624BB734 for ; Thu, 31 Dec 2020 10:13:59 +0000 (UTC) (envelope-from SRS0=bbpu=GD=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4D63sL1KZTz4YBD for ; Thu, 31 Dec 2020 10:13:57 +0000 (UTC) (envelope-from SRS0=bbpu=GD=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id D368428416; Thu, 31 Dec 2020 11:13:55 +0100 (CET) Received: from illbsd.quip.test (ip-94-113-69-69.net.upcbroadband.cz [94.113.69.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id BCAA528411; Thu, 31 Dec 2020 11:13:54 +0100 (CET) Subject: Re: Project information - SMBv2+ To: Eugene Grosbein , freebsd-hackers@freebsd.org References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> <704a700c-32ff-66eb-6711-5d75099abcd4@quip.cz> <20201230225624.atsnf6u5mmtcu5sw@nerd-thinkpad.local> <8644f79e-3957-3498-efa9-8fbfc7b57581@quip.cz> <41400a64-5f0b-295b-399e-711b9b40b6d3@grosbein.net> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Thu, 31 Dec 2020 11:13:53 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <41400a64-5f0b-295b-399e-711b9b40b6d3@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D63sL1KZTz4YBD X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=bbpu=GD=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=bbpu=GD=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [0.20 / 15.00]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=bbpu=GD=quip.cz=000.fbsd@elsa.codelab.cz]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[quip.cz]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.124.105.4:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[94.124.105.4:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=bbpu=GD=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[94.113.69.69:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 10:14:00 -0000 On 31/12/2020 04:56, Eugene Grosbein wrote: > 31.12.2020 6:33, Miroslav Lachman wrote: > >> Last time I tried smb with fuse it was unstable and does not allowed me >> to configure what to mount where at boot time. >> AFAIK fusefs-smbnetfs cannot be used the same way as mount_smbfs in fstab. >> So I think smbnetfs is not usable solution in our environment even if it works stable and fast. > > What are you problems with fuse+fstab, exactly? > Have you considered systax similar to the following example for net/glusterfs? > > gluster1:name /mnt/name fusefs rw,late,backup-volfile-servers=gluster2:gluster3,mountprog=/usr/local/sbin/mount_glusterfs 0 0 Do you or anybody else have a working example for smbnetfs? I tested it about a year ago, I do not remember all the details but I cannot find how to use it in fstab. I remember the configuration file was per user, mounting was done automaticly in the form: cd mountpoint/username:password@computer_or_ip or mounted in hierarchy like: /workgroup/computer/share So if there is some way to configure it in /etc/fstab to mount "//user@server/share" to /mnt/my_share I would really like to re-test it. Kind regards Miroslav Lachman From owner-freebsd-hackers@freebsd.org Thu Dec 31 10:42:09 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 59AF54BC65A for ; Thu, 31 Dec 2020 10:42:09 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 4D64Tr51Zfz4ZN9 for ; Thu, 31 Dec 2020 10:42:08 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42f.google.com with SMTP id t16so19787116wra.3 for ; Thu, 31 Dec 2020 02:42:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=Mew18U/f4Wv8lvCN4WtdlEqA6AU0DRQycjQKLeX3sG8=; b=YERqFsga3Hvz+nu9DVzHhUxcv8GGPd6soRF3GMTGbtqg5WdN1CJ1N9Kw62XLOKgQ17 e067qN4ylVtANXmKGyhS6xk6PIKQIYn56mfYnKgn8hmRud2l7lPmZ63FN61TKs89NJkX GjHnhsazxBiTsiCRq1LdPoflZ6gJClqsuTlJ4G1tDLi3/oByRbKf32+KeeKQKUfjPVAG BQKydamUwqvJ3awppg8xHcq4p7WU7aRp2GOx4mEuUIHYmUOyky7maQtXWatlfnjxi8wg hYKaLjcXtlvHvfqOhRCb/DxkuaKcBLgwaWibqt2GDrqp6TRe3kYK7ac0HTG0WG3sVYOx tCyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=Mew18U/f4Wv8lvCN4WtdlEqA6AU0DRQycjQKLeX3sG8=; b=ElDtwr82ev0KkPGT0ukcs5Gmzb3MIjBr/rk/bHwyFmvBe3d2WsOfxU/mAr43Jgfl8s +TYr/MrgDk9TgzFzH7MRO3gLC7f5W/znAnK36PlCESufaCpF7h6ZpeWuq6ZL5UaEy36J pLR5rJY3B0yt2ziS1ogk2QXIVm49qJ7mUdX/yLxDRwE+6kj4leVE7tTLAJEB0+PiCf6/ 7hdUxn1Uo1EFeVx0ohjuMZUnUzj0Jlt7JIJTOaK4ROVlDMnLE+Lazf4IheBaAZGwRNt6 KdbHyJ8Or5DZ0juE16WoO/WoxF64dvIGM4+VFOzy+vpIu71CNgGbBF16aEivWSicA220 Oq/g== X-Gm-Message-State: AOAM532DhY7QtVsf5VnhQ3XQC7+6bIQMHs2d2c49BX5KV0cE7k/kVQ/j vttGk/HgjzHDce6VhBjX0YLiMDlrigw= X-Google-Smtp-Source: ABdhPJwBoh2CpEELhIZfotube9ey+cJg9hX+51aUelbkq5Si98RZKNRTzZK3wLpdfNiIeoE/FEcedQ== X-Received: by 2002:a5d:570e:: with SMTP id a14mr63584166wrv.126.1609411326689; Thu, 31 Dec 2020 02:42:06 -0800 (PST) Received: from ernst.home (p5b02350e.dip0.t-ipconnect.de. [91.2.53.14]) by smtp.gmail.com with ESMTPSA id y11sm11790661wmi.0.2020.12.31.02.42.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Dec 2020 02:42:06 -0800 (PST) Date: Thu, 31 Dec 2020 11:42:02 +0100 From: Gary Jennejohn To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Eugene Grosbein , freebsd-hackers@freebsd.org Subject: Re: Project information - SMBv2+ Message-ID: <20201231104202.5170c797@ernst.home> In-Reply-To: References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> <704a700c-32ff-66eb-6711-5d75099abcd4@quip.cz> <20201230225624.atsnf6u5mmtcu5sw@nerd-thinkpad.local> <8644f79e-3957-3498-efa9-8fbfc7b57581@quip.cz> <41400a64-5f0b-295b-399e-711b9b40b6d3@grosbein.net> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D64Tr51Zfz4ZN9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=YERqFsga; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::42f as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::42f:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[91.2.53.14:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::42f:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42f:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 10:42:09 -0000 On Thu, 31 Dec 2020 11:13:53 +0100 Miroslav Lachman <000.fbsd@quip.cz> wrote: > On 31/12/2020 04:56, Eugene Grosbein wrote: > > 31.12.2020 6:33, Miroslav Lachman wrote: > > > >> Last time I tried smb with fuse it was unstable and does not allowed me > >> to configure what to mount where at boot time. > >> AFAIK fusefs-smbnetfs cannot be used the same way as mount_smbfs in fstab. > >> So I think smbnetfs is not usable solution in our environment even if it works stable and fast. > > > > What are you problems with fuse+fstab, exactly? > > Have you considered systax similar to the following example for net/glusterfs? > > > > gluster1:name /mnt/name fusefs rw,late,backup-volfile-servers=gluster2:gluster3,mountprog=/usr/local/sbin/mount_glusterfs 0 0 > > Do you or anybody else have a working example for smbnetfs? I tested it about a year ago, I do not remember all the details but I cannot find how to use it in fstab. > I remember the configuration file was per user, mounting was done automaticly in the form: > cd mountpoint/username:password@computer_or_ip > > or mounted in hierarchy like: > /workgroup/computer/share > > So if there is some way to configure it in /etc/fstab to mount "//user@server/share" to /mnt/my_share I would really like to re-test it. > Seems unlikely. Looking at the source code reveals that getfsent and the other routines used to parse /etc/fstab are not present. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Thu Dec 31 15:25: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 DD5B14C4E1B for ; Thu, 31 Dec 2020 15:25:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 4D6BnF5lQ6z4sj3; Thu, 31 Dec 2020 15:25:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x734.google.com with SMTP id z11so16548850qkj.7; Thu, 31 Dec 2020 07:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Wk+c0vmpOn9xcv6nPUam85/xZQd7bK7px+5r/0xdWjY=; b=I8FvYZ0nkY5ZcKxE5rB1cvAzp5nDkTHquahaz6C7/j9YJElyn9OERcX+WO0wNjacze nLLYj9xKNHfOrQvt0l8x3fNpbnqcFab3lzf0HwQ1ceNhJwhunSE4gkop4+jl1igndujR gt6b4pnSL2rBguSn/Y8xNMKIOAlo5ds1ReSvlWK0Skl96+EVOmQUSo7BIp2ejaEUwMQX MX8mg7dbmBKE0YSzriFrYd2+x9fMdBSB/19Q4azR2jQiMXGuNyko28IWwfylo2vfL1Y7 1OPNhwEmC8Uu339W3RMhGSFRbqEu4uYHWGWUbpnnqmGhTs/w5xgYXI23H2OussUmsWfw JL6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=Wk+c0vmpOn9xcv6nPUam85/xZQd7bK7px+5r/0xdWjY=; b=qg4TUvWVezjL8uP9WsVr5Biwfm+R4l7i7kxk/LXuIonshd3g8HISlRd/m90RSl0hff Og6075NbvBH9aOrvukSMx1fo//GlUAU1UfSOR9tkpk8WrrxnXOD0LR1lewYuDcYAZ7f6 c5Ms7voxn7wsq3WDe/Q9+0yriKtbrLyf+u0ApKEh6xxY88eIjcUqHB3e1CyTXU46PyOE nhfLM2Ly8MrzEylS/wdkEI8Gb8ZAvBZ+0wW1Fj4oL55zfWddH9dpJ7Y1VOBZTPnoaqx3 qAR+YUigkZYJXfH06dSMN+ckOuJEiHd1nJKdfKFZYZFNe3I/3QPRSziNZKdREME9m0pB lvpg== X-Gm-Message-State: AOAM530LcpzRYJZnwCwo1F7PQvrHWpKkuMlpTf4NXs7SvHCV0/GPDRuU WX5whqarqIHxm7bx/2EhFjNnW60UA+tzpQ== X-Google-Smtp-Source: ABdhPJxbgoIggkO0OJdJp87aET7CbGdPa192vcB2e96XqhWcpDGYf+genH7rntMgDVL2xM4JG1U23A== X-Received: by 2002:a05:620a:68e:: with SMTP id f14mr24113082qkh.460.1609428352676; Thu, 31 Dec 2020 07:25:52 -0800 (PST) Received: from raichu ([142.126.164.150]) by smtp.gmail.com with ESMTPSA id z30sm29555438qtc.15.2020.12.31.07.25.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Dec 2020 07:25:51 -0800 (PST) Sender: Mark Johnston Date: Thu, 31 Dec 2020 10:25:49 -0500 From: Mark Johnston To: Neel Chauhan Cc: freebsd-hackers@freebsd.org, ambrisko@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL Message-ID: References: <44528336fa9168966d121bf771e1e229@neelc.org> <3c9ff844e527daacd04c51f48836b57d@neelc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4D6BnF5lQ6z4sj3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 15:25:53 -0000 On Wed, Dec 30, 2020 at 06:10:11PM -0800, Neel Chauhan wrote: > I have attached two files: > > * pcidump: A dump of `pciconf -lv` > * acpidump: A dump of `acpidump` > > Hope this can help. > > -Neel > > On 2020-12-30 14:36, Neel Chauhan wrote: > > Mark, thank you so much for your help! > > > > However, I am getting an issue with `pci_read_device()` where it > > returns a `vid` (PCI Vendor ID) of 0xffff. > > > > This ends up returning "Cannot allocate dinfo!" from vmd. > > > > Log (via grep): https://imgur.com/a/tAmmY7i > > > > What usually causes this? > > > > I'm no expert on PC hardware, my $DAYJOB is not related to hardware > > (I'm a C#/.NET developer for a living). > > > > I do however want my Spectre running FreeBSD and am willing to write > > patches (to some extent at least). Hi Neel, In the future please avoid posting to multiple threads on the same topic. I'm not sure what the problem is here. I cc'ed Doug, the author of the driver, to see if he can help. For context, the goal is to add support for a new device (ID 0x9a0b) to vmd(4), but vmd_bus_attach() fails with the aforementioned error. We found a minor bug already in that vmd_attach() does not call rman_fini() in error paths, but I don't know enough about vmd to usefully comment further. From owner-freebsd-hackers@freebsd.org Thu Dec 31 15:42: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 42FFA4C5AA4 for ; Thu, 31 Dec 2020 15:42:07 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6C7y1Vqvz3BvX for ; Thu, 31 Dec 2020 15:42:05 +0000 (UTC) (envelope-from CerebrosuS@gmx.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609429324; bh=6oSqUpQLovf+6s+9U9s+rJmzsf63sYYMQKxp7bBikDM=; h=X-UI-Sender-Class:Subject:From:To:References:Date:In-Reply-To; b=hkPjgcWUo7YXZ/HtFaYL9B4drApWUlcuHghRTHoqFohzuEHLDLC2Gj8kPpqLpjUHc lgK13SBLmg1FY4YprBEkD/+DMeSK292qdalV2cTGXY8/xQ0L0fe/5tkcyTWblSQILV 0BnT8OiSOvNx0PJlKQEMIGj9rn8RrRkvM/8w32Oc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [2.2.3.2] ([87.122.30.47]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M3UUy-1kvYJq1ubq-000Z6g for ; Thu, 31 Dec 2020 16:42:04 +0100 Subject: Re: Project information - SMBv2+ From: CerebrosuS To: freebsd-hackers@freebsd.org References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> <20201230203416.xr42tsdo2m7txex7@nerd-thinkpad.local> <8758d2d0-12e9-77bb-e417-4bac430b4e9a@gmx.net> Message-ID: <8edb2ee8-0643-f3f4-ef5a-bdd9bd8a1b9a@gmx.net> Date: Thu, 31 Dec 2020 16:42:04 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <8758d2d0-12e9-77bb-e417-4bac430b4e9a@gmx.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:l31b1WqFhsJ7H3xHTJZmIrFC+ikUWuWnLYVIDxxe1BVAevOJWAU HKdOizTxw8bSCm/1dDRBMeV2Z3q1pz5AMcEvcH5+Hiood07zloJuUGJGbRBihzKtToEV3TU tmjIGTd4z0JbXUYFh6ofDG2Uh5vYVTVvb6DAYexnwYsB4IVbaJ23K8VCoxeyOSJlLYRCjkO pWb0Ojg18iWnyn1UIjYGA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:tgCRCgpxb68=:wjJyqBcimjZWv9oCDamBtS 4EP1HHpPfgntCaFJisOGgUJJrxxcy0TbKbQWUMzpJHRuiz+MYF1SUKDn5SSgFTCbdI+OxPX7e qvjf2hrjeWAWWHUs+ykRygA7SSfsFeqCAwNSgse2yVoTxTBr2YeTZyhXTe5Udvg7rfAGYEYDn H4BFi1+ZHdIJ5q9wRWrMoAy2CJXkEijh2MmFrI0wSvBOqHd7ThY+C0McT1CiI01mFNIYshiNb Tnx9YxLOHbArYs6y7iS2JAmk/viFP6iAYRjEcUq0Nuqcu8pDepfXVpneJjxvkPwooy+YEogCO nNw8dMKVGQfWit9t5+Wez3K9OEXsr+QWnj+7so1preLSVDlcOIpImPQpbqJWaKgyxpAFBRpAl y5jvEvyQ6kO2/N0Mx5zRCv4nPKENPzlm6F8AROVVa0D/dmHWRznPOMQBOCji1IT7bF7ut+ZrZ UnTLiYhSy3wibEfyzX8RH71BIBVIofMndU1b0cM2i9Za7JanHbPgJyOgU+lIcGrn85SIsVvUv KWk6OFzlj8udEwHIpR/e3gB2cnaR2hTnQLdLYDluKXF3OdB+PHet3UFBCb5VLOutsQaY+7+mA 1gwGrsK5HK7xoUuVuQ99VOkl3fqobFQ67QO542YKKZxkqlrVW6DMcaGf9LgcsyBZ5TClQAloS inlzPA4A0jZKDuJjSGUXxOAKzFUqVXimKaE+cZn3S69RRMBAHkkTlEjiyCDn0fDUO6VFk0mJ1 dUaQOHeb3058UksfJmoiPjbiBGFllbFHXbnyN33+BqLjid9bDOhJh7AKACkSNTXo7/xqCAevJ dSyqerm3JM5X6N33FMeCJFGqHa9orXWz6tWLWRkgAbKG0hZuMr4bu7vM2WWasHnOCwolCn9R4 m8mnmiEv1IbBFd2/E2+g== X-Rspamd-Queue-Id: 4D6C7y1Vqvz3BvX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=hkPjgcWU; dmarc=pass (policy=none) header.from=gmx.net; spf=pass (mx1.freebsd.org: domain of CerebrosuS@gmx.net designates 212.227.15.19 as permitted sender) smtp.mailfrom=CerebrosuS@gmx.net X-Spamd-Result: default: False [-2.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmx.net]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; DMARC_POLICY_ALLOW(-0.50)[gmx.net,none]; NEURAL_HAM_SHORT(-0.92)[-0.924]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmx.net]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.15.19:from]; DWL_DNSWL_NONE(0.00)[gmx.net:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RECEIVED_SPAMHAUS_PBL(0.00)[87.122.30.47:received]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[212.227.15.19:from:127.0.2.255]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.19:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 15:42:07 -0000 So I am found the main protocol spec existing in freebsd-src/sys/netsmb and got the corresponding implementation from apple. As I've never developed on FreeBSD, I am searching for a good workflow to test builds. Right now I've build freebsd-src from git. As far as I understand netsmb in sys is not a module build into the kernel? Therefore I have to update kernel and install it in a test environment for debugging. I don't want to polute my main system and read about using bhyve as a vm system for testing. Is this the only way or is there a smarter way getting debugging done to test my implementation. I've never developed things on kernel-level so I got a prog-debug cycle with high frequency for now. (As you can see, I am starting from the beginning related to FreeBSD development. Sry for that.) Am 30.12.20 um 21:44 schrieb CerebrosuS: > Yes, the video is part of the wiki.freebsd.org entry I've written down. > > The information in the video is a little bit unmotivated and I am aware > that it is not that simple. That video leads me to the question here, if > anyone is working on it. Cause Mr. Gibbs talks about it like he already > started something in this direction and is already into it (or he just > knows). :-) > > Yet, I will start by looking into the FreeBSD mount_smbfs code and the > one from apple. > > Am 30.12.20 um 21:34 schrieb Daniel Ebdrup Jensen: >> On Wed, Dec 30, 2020 at 08:24:31PM +0100, CerebrosuS wrote: >>> >>> >>> Am 30.12.20 um 20:05 schrieb Miroslav Lachman: >>>> On 30/12/2020 18:57, CerebrosuS wrote: >>>>> Hello at all, >>>>> >>>>> the community and developer at FreeBSD seem to know, that SMBv1 for >>>>> clients is nearly over and that the included mount_smbfs doesn't >>>>> support >>>>> newer versions. So good, so far... >>>>> >>>>> So I can find multiple information about the situation, but no clear >>>>> path on how FreeBSD community and developer will go on to solve this >>>>> missing function. (Just got the information on: >>>>> https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSam= baClient) >>>>> >>>>> >>>>> >>>>> >>>>> This is what I am asking: >>>>> - Is there a project existing for solving this problem (with whateve= r >>>>> target)? >>>>> - What is the way to go in future? Extend mount_smbfs or support the >>>>> fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and >>>>> laggy here)? >>>>> - Who is mainly working on it, if a project already exist? >>>>> >>>>> I'am just interested, cause of not finding such information >>>>> clearly. Is >>>>> there maybe a general project management list / team to see what >>>>> projects are going on in whatever state? >>>>> >>>>> I am a hobby developer mainly coming from chemical engineering side, >>>>> having some time to help. I've already written some cross platform >>>>> software but never related to network or on os-level. So I am >>>>> motivated >>>>> to invest some time in getting stuff into FreeBSD, but for me, >>>>> there is >>>>> a lack on information (see above). >>>>> >>>>> Thank you in advance for information and help. >>>> >>>> I was involved in the thread linked by Gleb. AFAIK nothing changed fr= om >>>> that time. I tried something from ports but it has more problems >>>> (shares >>>> cannot be mounted on boot like mount_smbfs does). >>>> If somebody has time and skills to try to bring SMBv2 or v3 to FreeBS= D >>>> then Apple or Solaris sources is good start. The both were using the >>>> same mount_smbfs (v1) as FreeBSD so one can check their sources and s= ee >>>> how they evolve to v2 / v3. >>> >>> They are both using exactly the same source code as a starting point a= nd >>> extend it (or rewrite it) to SMBv2? >>> >>>> But it is out of my skill. I am not >>>> developer. I am just an extensive user of SMB mounted shares from >>>> Windows servers. >>> That might also be my problem, cause I've never written an application >>> for network nor anything related to FreeBSD on os-level. But if no one >>> starts, nothing might change at all. >>> >>>> >>>> Kind regards >>>> Miroslav Lachman >>>> >>> _______________________________________________ >>> 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" >> >> Hi folks, >> >> Justin T Gibbs, during one of the Office Hours meetings that have been >> happening throughout the year, spoke at some length on the subject of >> SMBv3 as it relates to integraetion in the base system [1] - and suffic= e >> it to say, it's not nearly as simple as some people seem to asume that >> it is. >> >> I hope that's somewhat helpful, and it's at least a little newer than >> what's referenced elsewhere. >> >> [1]: https://www.youtube.com/watch?v=3DJi4ux4FWpRU&t=3D970 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" From owner-freebsd-hackers@freebsd.org Thu Dec 31 20:07:52 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 12E7C4CDDE2 for ; Thu, 31 Dec 2020 20:07:52 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6K2b4xg6z3mm9; Thu, 31 Dec 2020 20:07:51 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: VbWFv33tOCMXIWQFctqZ5bO0Zez0KLeUdBXJTl+wbr5DxzI5IEi9gjIDKBwbQ5Qd14tzxS+wF8 zFafhIERhS6PpSx3wWMJ4eMFc5vckTHuw= X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 31 Dec 2020 11:31:06 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.15.2/8.15.2) with ESMTPS id 0BVK7iXU098379 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 31 Dec 2020 12:07:44 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.15.2/8.15.2/Submit) id 0BVK7iPU098378; Thu, 31 Dec 2020 12:07:44 -0800 (PST) (envelope-from ambrisko) Date: Thu, 31 Dec 2020 12:07:44 -0800 From: Doug Ambrisko To: Mark Johnston Cc: Neel Chauhan , freebsd-hackers@freebsd.org, ambrisko@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL Message-ID: <20201231200744.GA95383@ambrisko.com> References: <44528336fa9168966d121bf771e1e229@neelc.org> <3c9ff844e527daacd04c51f48836b57d@neelc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4D6K2b4xg6z3mm9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 20:07:52 -0000 On Thu, Dec 31, 2020 at 10:25:49AM -0500, Mark Johnston wrote: | On Wed, Dec 30, 2020 at 06:10:11PM -0800, Neel Chauhan wrote: | > I have attached two files: | > | > * pcidump: A dump of `pciconf -lv` | > * acpidump: A dump of `acpidump` | > | > Hope this can help. | > | > -Neel | > | > On 2020-12-30 14:36, Neel Chauhan wrote: | > > Mark, thank you so much for your help! | > > | > > However, I am getting an issue with `pci_read_device()` where it | > > returns a `vid` (PCI Vendor ID) of 0xffff. | > > | > > This ends up returning "Cannot allocate dinfo!" from vmd. | > > | > > Log (via grep): https://imgur.com/a/tAmmY7i | > > | > > What usually causes this? | > > | > > I'm no expert on PC hardware, my $DAYJOB is not related to hardware | > > (I'm a C#/.NET developer for a living). | > > | > > I do however want my Spectre running FreeBSD and am willing to write | > > patches (to some extent at least). | | Hi Neel, | | In the future please avoid posting to multiple threads on the same | topic. | | I'm not sure what the problem is here. I cc'ed Doug, the author of the | driver, to see if he can help. For context, the goal is to add support | for a new device (ID 0x9a0b) to vmd(4), but vmd_bus_attach() fails with | the aforementioned error. We found a minor bug already in that | vmd_attach() does not call rman_fini() in error paths, but I don't know | enough about vmd to usefully comment further. FYI, looks like this needs to be ported over from Linux: static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus *bus, unsigned int devfn, int reg, int len) { char __iomem *addr = vmd->cfgbar + ((bus->number - vmd->busn_start) << 20) + (devfn << 12) + reg; to vmd_read_config offset = (b << 20) + (s << 15) + (f << 12) + reg; vmd_write_config(device_t dev, u_int b, u_int s, u_int f, u_int reg, offset = (b << 20) + (s << 15) + (f << 12) + reg; ie. offset = ((b - sc->vmd_bus_start) << 20) + (s << 15) + (f << 12) + reg; vmd_bus_start should be added to the softc as a uint8_t type and needs to be set via attach. We need range checks to make sure vmd_write_config/vmd_read_config doesn't read something out of range since it has been reduced. Not sure what the shadow registers do. These both seem to be new Intel features and Intel doc's have been minimal. Looks like Intel is doing a sparse map now on newer devices. I'm concerned about the Linux comment of: * Certain VMD devices may have a root port configuration option which * limits the bus range to between 0-127, 128-255, or 224-255 since I don't see anything to limit it between 0-127 only starting at 0, 128 or 224, Maybe there is max of 128 busses overall? I don't have this type of HW to test things. Doug A. From owner-freebsd-hackers@freebsd.org Thu Dec 31 22:54: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 297864D388D; Thu, 31 Dec 2020 22:54:57 +0000 (UTC) (envelope-from jhb@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 4D6NlP0Qc5z4V1m; Thu, 31 Dec 2020 22:54:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:6d91:ae61:b3ec:ca03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 707EB240AE; Thu, 31 Dec 2020 22:54:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch To: Chuck Tuffli , Neel Chauhan Cc: freebsd-hackers@freebsd.org, FreeBSD-Current References: From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Thu, 31 Dec 2020 14:54:55 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 22:54:57 -0000 On 12/31/20 2:40 PM, Chuck Tuffli wrote: > On Wed, Dec 30, 2020 at 4:38 PM Neel Chauhan wrote: >> >> Hi Chuck, >> >> On 2020-12-30 10:04, Chuck Tuffli wrote: >>> What is the output from >>> # pciconf -rb pci0:0:14:0 0x40:0x48 >> >> The output is: >> >> 01 00 00 00 01 2e 68 02 00 > > Perfect. The Linux driver says the 8086:9a0b device you have "... may > provide root port configuration information which limits bus > numbering" which causes the code to read the VM Capability register > (0x40) and the VM Configuration register (0x44). Here, VMCAP = 0x0001 > where bit 0 set appears to mean the config register has starting bus > number information. VMCFG = 0x2e01 where bits 5:4 give the coded start > number of bus 224 or 0xe0 which matches the PCI bridge shown in the > lspci output (i.e. 10000:e0:06.0). > > I wonder if mirroring the logic in [1] and setting > bus->rman.rm_start = 224; > in vmd_attach() might help. > >> I was also able to stop kernel panics by adding: >> >> rman_fini(&sc->vmd_bus.rman); >> >> In the fail: statement in vmd_attach(). >> >> But I still cannot detect the SSD. > > [1] https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L507 You will also need to subtract that starting bus number from the bus number used to compute the offset into the PCI-express region for config register read/write as this code does: https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L339 Also, that means the vm_bus.c can't hardcode reading from bus 0. Instead, vmd(4) might need to export an IVAR to vmd_bus(4) that is the starting bus number and vm_bus needs to use that instead of hardcoding 0. -- John Baldwin From owner-freebsd-hackers@freebsd.org Fri Jan 1 01:09:21 2021 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 69D734B8C58 for ; Fri, 1 Jan 2021 01:09:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670083.outbound.protection.outlook.com [40.107.67.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6RkS1N4Nz4j6N for ; Fri, 1 Jan 2021 01:09:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wi6mWhn9Yk0NUG0L9jvJpX1i3KvncYUDeChfnnfIEf8B61m2X0uYsTtRQGeLNX3V5wkl+tqQjbrt8S0Srl4DiA9WWLLmEJ5Tfmq6E1KrDDSN6S+fNqAmSNxvkSL5hkvQpCkPSSqWNFxPFau0CWJOtxngvp+9QLMRwOK2TxUOe1fDQxF+KPjotFx16UzQS8he3bdJPpykboZqwvDiCy2N5KuWJuX9sHPCf8F0jLURX7cOFd5o6CWePhRsKJ7v2Vpn8+J641Uhmi8urDz43zTOGyPF9fgr3wTv071L+e9Iu+AzX5/1cBaCEMUIjbN5yVD7+I2vDAfyTQAUXAoZdr0lqA== 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=q2ib9NSqMK2Qj2RLc6P7cTcGULLf3sYF7ZjTLcooo00=; b=atlveXEDJl3l/ifbTM2KA49/JBP8SANWb/dfptkGAX999hb11mE8f/O8uCnRCmJi8p1FwPGGz7V8gosJ6w1gBOWV+Xj9y3NmV4CerBAi9iO6NPOlphaCuxrsIl8AHqAe05rW+B2tVjkhhwJS7wR1m/clacrkbTlSU5o165V1ZPzaBRpxWgSGd7bwmukv9IAheYn7gdibO06IXDLq3c2CQf5To8J+Yvd4vKkJ4STb33wDozxoKpnE+wo55pS/B8h2o3d4wVq8nFnpVOIMjp2CLEUHtAVHWSo7e+UHtiBomkw4co9IkEd3a9DvIPG26sLM6hqUo3422HY33Tsj4wQjZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q2ib9NSqMK2Qj2RLc6P7cTcGULLf3sYF7ZjTLcooo00=; b=AvOO8gKQJtGFvon5SIsWU6sfPUmY6xfTmeaT4rOK7Gwx0s5O8nhsOUxHYWncZfgblbW+0XMVV4XdNzL2D8CcKldcTqjh9F18S0YFtUJwm6scxj7zHs8yt1tsJFLtzywi1b36fFLeCakpQ1TOyRpwRl2EMdVcMoHWuPh8ihlYEPpsRfU0MvosRWHM95nymyVhfZ4zwwzPuPPMqalIly6NDcfEcQqd/u8QUjNe8reMmZa9g9VpV1BKU8bNol9bG+XZTQ7dij6lyouKpxHLGRytgK3cBrw09Peonv1M2Bbx/8jwUxzP4w1Ko6PX75ooKgJhlDZv2U+2gmUdbgnbRqutpQ== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR0101MB1479.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:1c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.22; Fri, 1 Jan 2021 01:09:18 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3721.020; Fri, 1 Jan 2021 01:09:18 +0000 From: Rick Macklem To: Chris Johns CC: "freebsd-hackers@freebsd.org" Subject: Re: sys/fs/nfsclient on RTEMS gets a bad seqid error with open Thread-Topic: sys/fs/nfsclient on RTEMS gets a bad seqid error with open Thread-Index: AQHW39ixX2g8xupI30yVViAOBKgn+g== Date: Fri, 1 Jan 2021 01:09:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4cfd3067-117e-4df8-25d1-08d8adf1dd71 x-ms-traffictypediagnostic: YQXPR0101MB1479: 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: Gy4oVQfkRnRpP6Q9PYTlUAsiT2yZ3FeAPTaaG91ulAPyxA2NF75JsRHA2Si9myF0j9KTtHaDOPQuUGp/YNErjJTYHFMsRQffyo3oMi4tReKuvA8fUQCKJoW0Jg2xhzY5wL33B425DsO56Gmg25rE4jCys0AXohma7yFGeMZkrLoC5Wh6PxCuyv6EKNpLb5mWPU+LblEu9M487b/cBA9436VcvBtS81CNo3M07qFbFJf8JqdCeMnXIf0M51+fiKXgkW7Nf8fu5DUUjzvaBURJIs9A+lLQZYlCN0ocX7nL6Pgqx61EQey5y99cAGu9/TtHXb95BJVI7Z+UN0bWKIjodVIGAnJZxuzAU7eI6KhaO/1yPa3TGc/qI/ks0mTN7Sbu60C33MJWR/5guRZNnvTw6g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(39860400002)(136003)(346002)(396003)(376002)(316002)(8936002)(86362001)(7696005)(26005)(66946007)(786003)(4326008)(55016002)(9686003)(6916009)(186003)(5660300002)(478600001)(6506007)(83380400001)(91956017)(76116006)(33656002)(66556008)(66446008)(66476007)(64756008)(2906002)(52536014)(8676002)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?dVfP7L7VPbAn0PnFIIX+lSW41QwngECbs7Ybkxhh9Vw9Pj8o8F73IfeNpx?= =?iso-8859-1?Q?gLvSRpfkvuJRE4R333CMcIVDUY16PKc4Vrsybq4/SmlZSjAhAcjjgjpI0L?= =?iso-8859-1?Q?yXksKoRYrpayLDq7TU8r6MV4+HoGQQLsmXTQt9F3beCz5f3XzplNrJKnN6?= =?iso-8859-1?Q?Tv6Oq6AEGmmidUyXCCmeAIxJ9vngTrrVWZyOQG/yl01Q1xFmgSRVn9CHZo?= =?iso-8859-1?Q?lQmPORT1kVgIXNBbOS9EzJypH+kOZRyhp9Kp797acX8x41HMIqolBBEMu4?= =?iso-8859-1?Q?kii+IGwl8MgKKaE7YTfAryfbSIlstwFSZR9UrpDtXoTvhfVJdLmOgF/W6z?= =?iso-8859-1?Q?E7yKu6qFf+Fpw+9ihl+tjK0kJyyOmo7fnUr1Vka/EbeIZn9C/53evEOblJ?= =?iso-8859-1?Q?xKsNL6uz5v+BJS+oeloFeBTuwQ7et0b01zm5ctcXfB4GG/wFmXIxGBXwoX?= =?iso-8859-1?Q?4ZNYlK8PwtvXJ86+xVwatlvVJoSA0ToOxHvUcr3cRGrdTEP9Xxns96dtIh?= =?iso-8859-1?Q?BT5uysvpU8T8xVFn3mEntL9+ZYCylWWKuCT0Pd2fEZQQzOZyzWWdr4FbVv?= =?iso-8859-1?Q?rUZgoM+IvEF5KyO1RB/HPtdwUNFocx+lw6hIt2+HY7jiFUAqGKxNzuBFSS?= =?iso-8859-1?Q?KB3t837SNmxyvqBq2vfScclhH2PZOEPFgE+g+WM3btDmpxuiiXol+pfHpN?= =?iso-8859-1?Q?hZOuSrMbDRkT6hE4q0dq2ijxBZnI38tZxfMMEDxqKKK9Cy7g37jKAlVZpe?= =?iso-8859-1?Q?+5UNfgsKQAw3+Maa+pM9HaqGe6XyrTkyWzoPNGbMoWbVMiGGSWZM+jZLyX?= =?iso-8859-1?Q?9Llyz4VZv/ZUXVHQ6p1oVSyWdsvj5LnRVkB3mJcwPvQsU8JzuMqboL6h+b?= =?iso-8859-1?Q?p6bXoTysfK2948ppMCmH3a3Kh7asfbQrcF3WNkgnxADFEIJSSIojgh1rEk?= =?iso-8859-1?Q?WzARiTarPcl3ZNclGB6tkvow5pKoH02YfX6y78yXdi2m5Wh76eUGNrHxuh?= =?iso-8859-1?Q?XdtrjLquZlgzWpkjA=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 4cfd3067-117e-4df8-25d1-08d8adf1dd71 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jan 2021 01:09:18.6618 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eyC/KlGtH2/IY3ry5wG/a7Fy67v7Rezv8tzgahMD4rHrswg5tNHMD4ema++ih/KAqPa2ve9R7Xw0HYbUbSYPYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB1479 X-Rspamd-Queue-Id: 4D6RkS1N4Nz4j6N X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=AvOO8gKQ; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.83 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-1.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.67.83:from]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; FAKE_REPLY(1.00)[]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; SPAMHAUS_ZRD(0.00)[40.107.67.83:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.83:from]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2021 01:09:21 -0000 >On 31/12/20 10:04 am, Rick Macklem wrote:=0A= >> Chris Johns wrote:=0A= >>> Hello,=0A= >>>=0A= >>> I am porting the kernel's nfsclient file system to the RTEMS port of Fr= eeBSD. I=0A= >>> have ported across the FreeBSD file descriptors, VFS and NFS code. I ha= ve a=0A= >>> custom pseudofs file system as my root file system and I can mount an N= FSv4=0A= >>> mount exported from a FreeBSD 12 box.=0A= >>>=0A= >>> When I open a file there are a some getattr RPC calls that are successf= ul=0A= >>> however the open call (PUTFH, OPEN, GETATTR) results in the server retu= rning the=0A= >>> bas seqid (10026) error code for the OPEN and I am not sure why this is= =0A= >>> happening. I suspect I am missing a step in the nfsclient set up.=0A= >> Well, for NFSv4.0 Opens, there is a field in the open_owner called a "se= qid',=0A= >> which is used to serialize Open calls. If that "seqid" gets screwed up, = you=0A= >> get a "bad seqid" (10026) from the server and your mount is broken.=0A= >=0A= >There is only one open call being made and the seq id in the packet is 0. = The=0A= >server code seems to consider ownership when returning this error and this= is an=0A= >area I am not sure about. RTEMS simulates a process and does not have a no= rmal=0A= >user/group model.=0A= Did you do a Setclientid, Setclientidconfirm to set up the clientid?=0A= =0A= The first Open should be fine with seqid=3D=3D0 and the reply will flag it= =0A= as "needs Openconfirm".=0A= --> 10026 means the server thinks it has already seen the open_owner=0A= string for that client.=0A= =0A= I'd suggest to capture a packet trace of a mount from the FreeBSD client=0A= and then look at it in wireshark, to see what should be happening.=0A= =0A= >> A couple of possibilities:=0A= >> - The FreeBSD client code depends on an exclusive lock on the vnode=0A= >> to serialize the Opens.=0A= >=0A= >There is only one open call active. This is something I can control.=0A= If all your Opens are serialized, you can use a single open_owner for=0A= everything. The open_owner string should always be the same to do=0A= this.=0A= The FreeBSD client can do this for NFSv4.1 by specifying "oneopenown"=0A= as a mount option.=0A= =0A= >> --> If what you are doing doesn't serialize them, then that will be a= =0A= >> problem.=0A= >> - If the VOP_OPEN() generates an unexpected error (I just ran into this= =0A= >> on FreeBSD head), then the client might not get things correct.=0A= >> --> The seqid is incremented for some errors, but not others.=0A= >=0A= >I am currently basing this work on the FreeBSD 12 branch we have. A master= port=0A= >is next.=0A= >=0A= > Btw, all this seqid stuff goes away when you use NFSv4.1 and there=0A= > are NFSv4.1 only clients out there. You might want to consider doing=0A= > this. If I was writing the code now, there would be no NFSv4.0.=0A= >=0A= >Ah OK. How do I make the FreeBSD nfsclient operate as NFSv4.1? I looked in= to=0A= >this but I could not figure out how.=0A= minorversion=3D1 mount option, which sets nm_minorvers to 1.=0A= =0A= rick=0A= =0A= > rick=0A= > ps: Getting this seqid stuff right was about the hardest part of=0A= > implementing NFSv4.0 and it could still be buggy.=0A= =0A= Hmm yes it seems a little tricky.=0A= =0A= Thanks=0A= Chris=0A= From owner-freebsd-hackers@freebsd.org Fri Jan 1 03:17:25 2021 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 8F44E4BBE53 for ; Fri, 1 Jan 2021 03:17:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660072.outbound.protection.outlook.com [40.107.66.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6VZD4TyFz4pck for ; Fri, 1 Jan 2021 03:17:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a6nTePzmrr22M7j9iatYlcWmgx9/F0CwhznmWpY5q2dNXm9bAXXhynSF+JaU+IlNvW4m2lXlcpEHlF44Scq/P6MTqbkIcY/cUWZzOjFGVV/cSenYGD9oPY8R+sptN8xX3bWrhPHDLJhoVit2g8rRM7GZjAD1g6J3U7QZD8erfZwlEoRB2KoryrK9g/hf3bBsPJGBpVxySeveic8jC31OGQQS+OTF9LYRU0n63WbOcnDhwizn3rngH7amk4O6fCS221oTun6Sf+POpuqvfYBSykBNoYMzZhsuJJ7mg8IVsozW6/ZB6GBDmkpTtLf1cSVpD8LahCu8JC7anuzkd81E0A== 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=0pBaifrEwGmp5qFjfnkc60C4IR8CupISHU4t6yQqPfs=; b=gfZUi83DqJS1QpGl4gUCXUn350s0hnXxwjsNpryenVo005baCUPHxWaWewiqThT+g0x5sswwThoT1ZCFuPX8Y25oprdQXMyO0E2XsqqxsFXZp0lX03wfIlNmTMaqhFq8Jrkf+yHQor+gjGUGjmcxJCJucwAsZUWx0pUj+ZH10/5nyFC8XMN1I8suZriNcuGCFuK2C9xqSWOjQIhSUm4lVx8DoFcrkiZrrxZdI/BJ3OBBfCHl1N+mmC8LwH844zmUSgcuhV5uzo0ectpJapZikWK64jSLBDwVn8uU0EWtYC7L35QXSTPd3VUsmEdd0U+N1xTj1TKFu/VKqnrpQx+xrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0pBaifrEwGmp5qFjfnkc60C4IR8CupISHU4t6yQqPfs=; b=egICP3noaYax9s2GDVM9mKNIVXq+eiAvBsrW95pO223lgJ139deuRggV7T4LwBBYTgqexjbDFjSWOsG/jLD2j8NMu//2pyidWZLCapdLt2n8p1ZVgm08LPF90qSDgZzJu6k6zJmxuUhe/OWlNxfyXdTKWPdfS8/DTyAERA/c3QB5Egv81BMVoX5k42e9jfOo2Vvl38zF7gh4KceY8kxvA4De4PRp3F+M2/3wWBIgT+61vrr7XKwk3FhuE6dXLS8JBfQkb3jWsbsQDpeU47Qhdu2E2WgXTNVtImzv0T9Smbxdu1vashnSMDKcQwPpXXLX9LGtGo1d93xGm+GkosLJwQ== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB2084.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:10::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.28; Fri, 1 Jan 2021 03:17:23 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3721.020; Fri, 1 Jan 2021 03:17:22 +0000 From: Rick Macklem To: CerebrosuS , "freebsd-hackers@freebsd.org" Subject: Re: Project information - SMBv2+ Thread-Topic: Project information - SMBv2+ Thread-Index: AQHW34uHwap5JTg7LE2u+haHAb4S86oSFbDl Date: Fri, 1 Jan 2021 03:17:22 +0000 Message-ID: References: <16e5725b-ec2f-3222-d20d-fd15e597c12c@gmx.net> <075f31cb-dd13-778d-ed50-3ec7d6f30731@gmx.net> <20201230203416.xr42tsdo2m7txex7@nerd-thinkpad.local> <8758d2d0-12e9-77bb-e417-4bac430b4e9a@gmx.net>, <8edb2ee8-0643-f3f4-ef5a-bdd9bd8a1b9a@gmx.net> In-Reply-To: <8edb2ee8-0643-f3f4-ef5a-bdd9bd8a1b9a@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1de6fb0c-9d87-42fa-0269-08d8ae03c1a6 x-ms-traffictypediagnostic: YQBPR0101MB2084: 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: 79311eY/a2K3/QyYgPRKKPjRnoLxRI0csV6tnjXSDLV76UydZYoARi79PgfgeP/MIdozy7reyi7iCb4KQeUMct4jXP2KoGzw1d0EeVub9SfZkV2tQIqawBv37rpYfiO1cp9ylyvgU9o7QiwSRoLUOQIMPXvTtHCrQlQXBwLRi5n4QM9hp0sDwfye9LpL1xPGeUiYEi/1MGHslL3a63nAuwejwECaL/OWJHWZED2g6KJJQMeFYmR+uFS+n7pMokM9I44aZZgb2jU8iISkB7sSsgUgJUi2hlGoe1gVK6VbzPQ71yxtlBbtegrwSuyyNx4cEL5+K1it9d3Y3w6R28NmwcAv7yYbOpGFF2dkheGMM9djVPu7HLzHVi8Idus+feoMoDxSXJhZ4eVNF8a+QeyFuN0IKsJAOn0E8QCTIuzbilyxUd44g5/stpyzybbVkPnrf16UQyy40hCcvDdrNbMMIg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(396003)(376002)(346002)(39850400004)(366004)(71200400001)(966005)(8936002)(86362001)(478600001)(8676002)(66476007)(786003)(83380400001)(186003)(53546011)(26005)(76116006)(66556008)(52536014)(5660300002)(6506007)(66946007)(64756008)(2906002)(316002)(110136005)(55016002)(33656002)(9686003)(7696005)(91956017)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?VWb23VlQ5teyUHiC12rKjqh6UlB8/ROsGjZIycMgXnj+r9x3DmyPYPVXjg?= =?iso-8859-1?Q?yExlasotuC0o8BUPan0Hm0u+bGD5YOR1W2iz3r7ypiSxNzO1JpyjYSzHdJ?= =?iso-8859-1?Q?d8Ec4z/vJbyPZRAbNRLuSEzO4tOk3eTsl04wLDGM+6cWebK+M1t00eVPBz?= =?iso-8859-1?Q?cStJYlyXTbodtAP+RFbPMfsOZ9RIHA+jNRZLleG5mWa0yMIS1IYx5Fon0x?= =?iso-8859-1?Q?2sOIKvfLgMYZk8QXOxcIp09EPu+pOGd++RWP205cd+07h0Ni2pGkQuY+J9?= =?iso-8859-1?Q?e4EWRafE242C1QcyGgtqrCGk6zFfkXqG/MsjHfRyb+kX71w/hnt9mOaFiB?= =?iso-8859-1?Q?3F77ieWbWuCfOCe1GAFX5vTq69tTL0UlIp0YQmRM84KqSodnU6ZPs8UzYN?= =?iso-8859-1?Q?SvXZU+zqPiyCIXw/pebP+7c9cSKkLLx8IxTdskrQHwDeiggPK7Vy40Pwdb?= =?iso-8859-1?Q?6JRCkTC5pBxiW0ZVrJYTZXRkoATAw5y2Zq4MJQmW1bRkSX+K//3p9Q3g5i?= =?iso-8859-1?Q?2V49I4mgbf3iNiI6h1K464niMs4AxYEGpma28vGPqs9iw/+9woNyWKi16Q?= =?iso-8859-1?Q?4DZ37E2inh+CgjyHYzrNzV09ckMSa979wv6JhrRVuLUXgrq3Z/YaBm/H8l?= =?iso-8859-1?Q?m9NNCZ8lVvpdtZSjddTYStZ8FCx0/gqrU922n1H3TFLE1uVfPv/5S0+fKZ?= =?iso-8859-1?Q?drSEwm2D+OmFAxQfbqUHCRz6h1yhhx6ucTZWVjglJBcWWQN/to7/EYe6j7?= =?iso-8859-1?Q?v8hfPDwAIT+9CpFxVDEE7ELJaZq6DLTT+S+R6aeVy2wugVvincFeq/tmE8?= =?iso-8859-1?Q?K4Pi6UGxu/Je8MG4hQ8ZiGZLgOiZGP1z9x1dhU6cI0VINcwvvQV0D+99Ps?= =?iso-8859-1?Q?1N5D3d0Rw6zIeToL0258GKFnOBqygmeuGOjHFZLb9BNm+jvI7ojMe/R928?= =?iso-8859-1?Q?6mGK5I6B7adRXhdX7rCtJyYTwy9zwWDmCXtc54s8x6TZYL0pAAh3GCMrha?= =?iso-8859-1?Q?0ahe83LLVPz6NV4Gc=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 1de6fb0c-9d87-42fa-0269-08d8ae03c1a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jan 2021 03:17:22.8932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +j/xuXtwRwfN6NykJY2AM+lP2Wk5QcQS0ke1vDKgxTZLVGnwXzKGcTgZZYKaArj9RdqywYDYraikoIPMDI7nCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB2084 X-Rspamd-Queue-Id: 4D6VZD4TyFz4pck X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=egICP3no; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.72 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmx.net,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.66.72:from]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[40.107.66.72:from:127.0.2.255]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.72:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.72:from]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2021 03:17:25 -0000 CerebrosuS wrote:=0A= >So I am found the main protocol spec existing in freebsd-src/sys/netsmb=0A= >and got the corresponding implementation from apple.=0A= >=0A= >As I've never developed on FreeBSD, I am searching for a good workflow=0A= >to test builds. Right now I've build freebsd-src from git.=0A= >=0A= >As far as I understand netsmb in sys is not a module build into the=0A= >kernel? Therefore I have to update kernel and install it in a test=0A= >environment for debugging. I don't want to polute my main system and=0A= >read about using bhyve as a vm system for testing.=0A= I'm not a vm guy, but I use any old hardware I can find.=0A= In 2011, I needed a box for FreeBSD devel. I dumpster dived a computer=0A= recycling pile. Picked up an old Dell tower I still use for FreeBSD devel.= =0A= (cost $0.00)=0A= =0A= Recently I needed amd64 (the above is i386) and I like laptops, since=0A= they are easy to move around.=0A= --> Found a used Dell Latitude 6420 for $200, which works great.=0A= =0A= I wouldn't recommend i386 any more, but anything that is amd64=0A= with a few Gbytes of RAM, 100 Gbytes of disk and a net port should do.=0A= (I don't bother with X windows or anything like that on them.)=0A= =0A= As for testing/debugging, the kernel debugger can do a lot, but I=0A= don't use it often enough to be useful with it.=0A= Normally, I just use lots of printf's.=0A= And for file system work "options DEBUG_VFS_LOCKS" in the=0A= kernel config file.=0A= =0A= Yea, I'm weird, but it works for me, rick=0A= ps: For a pure build and test kernel system, you don't need=0A= any ports and can re-install it in 15min if you mess it up.=0A= =0A= Is this the only way=0A= or is there a smarter way getting debugging done to test my=0A= implementation. I've never developed things on kernel-level so I got a=0A= prog-debug cycle with high frequency for now.=0A= =0A= (As you can see, I am starting from the beginning related to FreeBSD=0A= development. Sry for that.)=0A= =0A= Am 30.12.20 um 21:44 schrieb CerebrosuS:=0A= > Yes, the video is part of the wiki.freebsd.org entry I've written down.= =0A= >=0A= > The information in the video is a little bit unmotivated and I am aware= =0A= > that it is not that simple. That video leads me to the question here, if= =0A= > anyone is working on it. Cause Mr. Gibbs talks about it like he already= =0A= > started something in this direction and is already into it (or he just=0A= > knows). :-)=0A= >=0A= > Yet, I will start by looking into the FreeBSD mount_smbfs code and the=0A= > one from apple.=0A= >=0A= > Am 30.12.20 um 21:34 schrieb Daniel Ebdrup Jensen:=0A= >> On Wed, Dec 30, 2020 at 08:24:31PM +0100, CerebrosuS wrote:=0A= >>>=0A= >>>=0A= >>> Am 30.12.20 um 20:05 schrieb Miroslav Lachman:=0A= >>>> On 30/12/2020 18:57, CerebrosuS wrote:=0A= >>>>> Hello at all,=0A= >>>>>=0A= >>>>> the community and developer at FreeBSD seem to know, that SMBv1 for= =0A= >>>>> clients is nearly over and that the included mount_smbfs doesn't=0A= >>>>> support=0A= >>>>> newer versions. So good, so far...=0A= >>>>>=0A= >>>>> So I can find multiple information about the situation, but no clear= =0A= >>>>> path on how FreeBSD community and developer will go on to solve this= =0A= >>>>> missing function. (Just got the information on:=0A= >>>>> https://wiki.freebsd.org/MateuszPiotrowski/AccessingSmbSharesWithSamb= aClient)=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> This is what I am asking:=0A= >>>>> - Is there a project existing for solving this problem (with whatever= =0A= >>>>> target)?=0A= >>>>> - What is the way to go in future? Extend mount_smbfs or support the= =0A= >>>>> fuse-smbnetfs part to be stable and fast like mount_smbfs (buggy and= =0A= >>>>> laggy here)?=0A= >>>>> - Who is mainly working on it, if a project already exist?=0A= >>>>>=0A= >>>>> I'am just interested, cause of not finding such information=0A= >>>>> clearly. Is=0A= >>>>> there maybe a general project management list / team to see what=0A= >>>>> projects are going on in whatever state?=0A= >>>>>=0A= >>>>> I am a hobby developer mainly coming from chemical engineering side,= =0A= >>>>> having some time to help. I've already written some cross platform=0A= >>>>> software but never related to network or on os-level. So I am=0A= >>>>> motivated=0A= >>>>> to invest some time in getting stuff into FreeBSD, but for me,=0A= >>>>> there is=0A= >>>>> a lack on information (see above).=0A= >>>>>=0A= >>>>> Thank you in advance for information and help.=0A= >>>>=0A= >>>> I was involved in the thread linked by Gleb. AFAIK nothing changed fro= m=0A= >>>> that time. I tried something from ports but it has more problems=0A= >>>> (shares=0A= >>>> cannot be mounted on boot like mount_smbfs does).=0A= >>>> If somebody has time and skills to try to bring SMBv2 or v3 to FreeBSD= =0A= >>>> then Apple or Solaris sources is good start. The both were using the= =0A= >>>> same mount_smbfs (v1) as FreeBSD so one can check their sources and se= e=0A= >>>> how they evolve to v2 / v3.=0A= >>>=0A= >>> They are both using exactly the same source code as a starting point an= d=0A= >>> extend it (or rewrite it) to SMBv2?=0A= >>>=0A= >>>> But it is out of my skill. I am not=0A= >>>> developer. I am just an extensive user of SMB mounted shares from=0A= >>>> Windows servers.=0A= >>> That might also be my problem, cause I've never written an application= =0A= >>> for network nor anything related to FreeBSD on os-level. But if no one= =0A= >>> starts, nothing might change at all.=0A= >>>=0A= >>>>=0A= >>>> Kind regards=0A= >>>> Miroslav Lachman=0A= >>>>=0A= >>> _______________________________________________=0A= >>> freebsd-hackers@freebsd.org mailing list=0A= >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= >>> To unsubscribe, send any mail to=0A= >>> "freebsd-hackers-unsubscribe@freebsd.org"=0A= >>=0A= >> Hi folks,=0A= >>=0A= >> Justin T Gibbs, during one of the Office Hours meetings that have been= =0A= >> happening throughout the year, spoke at some length on the subject of=0A= >> SMBv3 as it relates to integraetion in the base system [1] - and suffice= =0A= >> it to say, it's not nearly as simple as some people seem to asume that= =0A= >> it is.=0A= >>=0A= >> I hope that's somewhat helpful, and it's at least a little newer than=0A= >> what's referenced elsewhere.=0A= >>=0A= >> [1]: https://www.youtube.com/watch?v=3DJi4ux4FWpRU&t=3D970=0A= > _______________________________________________=0A= > freebsd-hackers@freebsd.org mailing list=0A= > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= "=0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= =0A= From owner-freebsd-hackers@freebsd.org Fri Jan 1 05:50:06 2021 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 52F724BF6F0 for ; Fri, 1 Jan 2021 05:50:06 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (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 4D6YyQ1R1Bz4T3m; Fri, 1 Jan 2021 05:50:05 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id B2365EB2A5; Thu, 31 Dec 2020 21:49:56 -0800 (PST) MIME-Version: 1.0 Date: Thu, 31 Dec 2020 21:49:56 -0800 From: Neel Chauhan To: Doug Ambrisko Cc: Mark Johnston , freebsd-hackers@freebsd.org, ambrisko@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL In-Reply-To: <20201231200744.GA95383@ambrisko.com> References: <44528336fa9168966d121bf771e1e229@neelc.org> <3c9ff844e527daacd04c51f48836b57d@neelc.org> <20201231200744.GA95383@ambrisko.com> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <4f3f6a02a452f766063ae2acb060dc64@neelc.org> X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D6YyQ1R1Bz4T3m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2021 05:50:06 -0000 Hi Doug, Thank you so much for this information. On 2020-12-31 12:07, Doug Ambrisko wrote: > FYI, looks like this needs to be ported over from Linux: > static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus > *bus, > unsigned int devfn, int reg, int len) > { > char __iomem *addr = vmd->cfgbar + > ((bus->number - vmd->busn_start) << 20) + > (devfn << 12) + reg; > > to > vmd_read_config > offset = (b << 20) + (s << 15) + (f << 12) + reg; > > vmd_write_config(device_t dev, u_int b, u_int s, u_int f, u_int reg, > offset = (b << 20) + (s << 15) + (f << 12) + reg; > > ie. > offset = ((b - sc->vmd_bus_start) << 20) + (s << 15) + (f << 12) + > reg; > > vmd_bus_start should be added to the softc as a uint8_t type and needs > to > be set via attach. We need range checks to make sure > vmd_write_config/vmd_read_config doesn't read something out of range > since it has been reduced. One thing I noticed is that the "b" variable (which corresponds to the Linux bus->number) is 0 (thanks to printf). This should be the bus number if we want to attach. If I use: "b = pci_get_bus(dev);" in the attach, b is still 0. And that leads to a kernel panic. > Not sure what the shadow registers do. These both seem to be new Intel > features and Intel doc's have been minimal. Looks like Intel is doing > a sparse map now on newer devices. I guess Linux is our best hope. Unless the new Intel docs is the Linux kernel source. > I'm concerned about the Linux comment of: > * Certain VMD devices may have a root port configuration > option which > * limits the bus range to between 0-127, 128-255, or 224-255 > > since I don't see anything to limit it between 0-127 only starting > at 0, 128 or 224, Maybe there is max of 128 busses overall? I could be wrong, but I guess that's a typo. > I don't have this type of HW to test things. I can use my hardware for testing. In the worse case scenario, I can donate an entry-level 11th Gen/TigerLake system if I have the funds and/or can get a tax credit. > Doug A. -Neel From owner-freebsd-hackers@freebsd.org Sat Jan 2 05:25:55 2021 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 6352E4C2D63; Sat, 2 Jan 2021 05:25:55 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 4D79N20sX7z3C0C; Sat, 2 Jan 2021 05:25:53 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf1-x135.google.com with SMTP id m25so51852398lfc.11; Fri, 01 Jan 2021 21:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:subject:message-id:mime-version :content-transfer-encoding; bh=6iDYSKTkEb75yo2men6ijWcGFi7LEXYAOF1HoRh9aus=; b=Ny51LMDPVdXWO6zCB2/3vNC2VOH9rM0c7T/UCC5i11fT+vJz1rlAiItzBig4m2JLNv opEfqTsE4cqGgMsV/HGJ4B6CPW2IKG8GTMd/LOIjoInrm/ZPOc1GErSCbd2JTn5GjW6K DiKlfeQJrkzlRjedZ3IeepCdqBUbGlkN84p/haGXDEkwVnI/sZbCQ5Nhwi89zrhjqv5F hKdJ1sYXe6zAquSXQmMehgy1T5r8st3DiUV64OoheiH5VRKKwvcLVPkn2iFL6Xt9ld9S EN3+oWIKFtMNsnkMvkGbVNaPKUpk+vjE4Uq8CHNoYL/SQjpkH+mmL6F2V6Iq5Djhp/Ii CiEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:mime-version :content-transfer-encoding; bh=6iDYSKTkEb75yo2men6ijWcGFi7LEXYAOF1HoRh9aus=; b=OYZ0TSqr5EWGjcVKBf23JfQlyL4b/PTSZe1W6Y3AnbnGgJ3Nq+dPWq9TwAHBMaCGvL T4AAwHSEh+71yA8dO1h7LMNzpbfHHa7a2sr3tmOmKavlRXJHtUJLnQt4vHuzpWB9GNPN YzcWAfqqkxaPgi46u1MA5M6d5guhyS2Q+H+6ywTwhMpzVJCOynaRjxTXhFHM+5PR/pr4 ueGL2icVmoR+bc+e8RAqB4Nx8u2DgU8n42k7KPB4NaxR58rpPLqDgZJE3yLlPtpc2q4F +/SZ+fx19kr2pLJn564EAx1qn2ccQsu6rualq+jlmZ4z3khDsn699d2xaZZES+vtBcSJ tuzg== X-Gm-Message-State: AOAM5339zuEhY3/7J8Q9pCCV3f8YMz9r1BoqBzZSF1j9SNF0f5jm+pdB CK4ewpQbOndC8UfKWKGevP+ca2whI38= X-Google-Smtp-Source: ABdhPJxVSpS0tsygh0RynVH5IGauRgMWhUc0y4+DWJ1tWE38UV0o1iWNkoOjAJtaTrUd/NjeBib+4w== X-Received: by 2002:a05:6512:21d:: with SMTP id a29mr25692044lfo.444.1609565152205; Fri, 01 Jan 2021 21:25:52 -0800 (PST) Received: from rimwks.local ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id v14sm4224400lfd.69.2021.01.01.21.25.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Jan 2021 21:25:51 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 2 Jan 2021 08:25:49 +0300 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Terminal colours in current Message-ID: <20210102082549.758bd189@rimwks.local> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; amd64-portbld-freebsd12.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D79N20sX7z3C0C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Ny51LMDP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::135 as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::135:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::135:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::135:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 05:25:55 -0000 Hi! I am tring current and found that kernel options: options TERMINAL_NORM_ATTR = (FG_GREEN|BG_BLACK) # def to SC_NORM_ATTR / 2 | 0x00 options TERMINAL_KERN_ATTR = (FG_YELLOW|BG_BLACK) # def to SC_KERNEL_CONS_ATTR / 14 / 0x00 does not work anymore. Fast greping sources give me loader tunables: teken.fg_color="2" # teken.bg_color="0" # but these optios does not allow set kernel messages colour. https://www.freebsd.org/cgi/man.cgi?query=vt&apropos=0&sektion=4&manpath=FreeBSD+13.0-current&arch=default&format=html say that TERMINAL_NORM_ATTR and TERMINAL_KERN_ATTR should work. Also it say that I should have: kern.vt.color..rgb="" kern.vt.fb.default_mode="x" kern.vt.fb.modes.="x" but I only get: kern.vty: vt kern.vt.splash_cpu_duration: 10 kern.vt.splash_cpu_style: 2 kern.vt.splash_ncpu: 0 kern.vt.splash_cpu: 0 kern.vt.kbd_panic: 0 kern.vt.kbd_debug: 0 kern.vt.kbd_reboot: 0 kern.vt.kbd_poweroff: 0 kern.vt.kbd_halt: 0 kern.vt.suspendswitch: 0 kern.vt.deadtimer: 15 kern.vt.debug: 0 kern.vt.enable_bell: 0 kern.vt.enable_altgr: 1 Do I miss something? From owner-freebsd-hackers@freebsd.org Sat Jan 2 05:41:00 2021 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 051584C3CB7; Sat, 2 Jan 2021 05:41:00 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4D79jR21FPz3DGj; Sat, 2 Jan 2021 05:40:59 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf1-x12d.google.com with SMTP id 23so51874540lfg.10; Fri, 01 Jan 2021 21:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Dla2S2fUhnZL4KgTZiOnVAUt42CB8brcch8ZjAFTa1A=; b=nGKPVlGz2Fg3swkOK2kmItij3pL/7wPV88659iCcLYIz1P1GvJvpcwbAgZYEMUJAaR E+1LHfAlKsJ8MY1g81AKbNFHEH6nzppgN69l2kNzzoL8QGhuMusEB4iUeMEULF3hiLsg cu11F5wwpm0rydPrrT3g3o9um+6Kx0RR9SE3IZ+6GEl3JqOxU0O09MlCPsHMpdxLqs2P /1A6ghuOY9+GiiAzxVV59hJ52LF3Z/I7v/Aldi3mfOhV/q8n41NsTcuan6WT+cJN3MoW zCuP3LtSa/3WvIh6TuclzyoxXQI30TnHmQtlkf2BUeUvtA0+QE5u4j3E9aFFCYJQGzle cMUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Dla2S2fUhnZL4KgTZiOnVAUt42CB8brcch8ZjAFTa1A=; b=BBM8yyuLvuDTdtbj2ZhLaoMoojYj6HLKxnJbLf/udtCMhpL2V8RpF7qTWuyo25IqUb KsVtfFz945c8+N44/xeR39jvd6DDhuvVIOgql8Kj6BdEt8bjcnxJn8Tlo+ZuFM87VXo0 Xwzb9dPY+Q6c8UrdR2Pmc4Gv32UmsOHGHN61nhlbtC+5xEj+IXWeksLGGCUDW9FAWHyZ kGszhKdnGxVko2NoKfpD6pMsWuqOiiamWO3ejv+SJ8ms8C4fiez+AcPeFzoPcSFJH5t3 IeAJVeF0xnp0r/HLSolSD6mWqcy5Se14egeKtB+ePzx4VfNPrT1rTHsK3rMAkJ8ODJbg 7eWg== X-Gm-Message-State: AOAM531WIY+EzrOhpgMkoefVV+8cIzQB1IQHgrMJD7435hgweK71rgJ7 hdOsVCwr5rIpxmOZsVQmH/WbvsGeTvw= X-Google-Smtp-Source: ABdhPJz/xZzjryEwOXNwqRpng82qI0qmNLpgwl7XHze8oiHj81a9NHkzz0Dno7DkFaIqEBHU+tHr/w== X-Received: by 2002:a2e:87d3:: with SMTP id v19mr32823127ljj.207.1609566057489; Fri, 01 Jan 2021 21:40:57 -0800 (PST) Received: from rimwks.local ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id d2sm8078117ljg.39.2021.01.01.21.40.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Jan 2021 21:40:57 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 2 Jan 2021 08:40:55 +0300 To: "Hartmann, O." Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Terminal colours in current Message-ID: <20210102084055.2eebbcfd@rimwks.local> In-Reply-To: <20210102063355.1be83a57@hermann.fritz.box> References: <20210102082549.758bd189@rimwks.local> <20210102063355.1be83a57@hermann.fritz.box> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; amd64-portbld-freebsd12.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D79jR21FPz3DGj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=nGKPVlGz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::12d as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::12d:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::12d:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12d:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 05:41:00 -0000 On Sat, 2 Jan 2021 06:33:55 +0100 "Hartmann, O." wrote: > Colour settings seem to be broken since a couple of months. Out of > the blue, coloured kernel messages vanished - this problem is on 12 > as well as CURRENT (we're running 12.2-RELENG, 12-STABLE and CURRENT). > I do no see problem on stable 12. Also current with loaders from 12 is OK. From owner-freebsd-hackers@freebsd.org Sat Jan 2 15:27:25 2021 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 A021E4D3C18 for ; Sat, 2 Jan 2021 15:27:25 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (static-108-31-38-18.washdc.fios.verizon.net [108.31.38.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7Qk44Bqvz4Whg for ; Sat, 2 Jan 2021 15:27:24 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 28923AA06 for ; Sat, 2 Jan 2021 15:27:18 +0000 (UTC) To: freebsd-hackers@freebsd.org From: Eric McCorkle Subject: Research question Message-ID: <2e0d6aad-4ab6-6ff6-af5b-5f2071bd56ec@metricspace.net> Date: Sat, 2 Jan 2021 10:27:12 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D7Qk44Bqvz4Whg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of eric@metricspace.net has no SPF policy when checking 108.31.38.18) smtp.mailfrom=eric@metricspace.net X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[eric]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[108.31.38.18:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[108.31.38.18:from:127.0.2.255]; DMARC_NA(0.00)[metricspace.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:108.31.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 15:27:25 -0000 All, I'm doing some background literature review relating to microkernel designs and highly-concurrent programming models. The KSE API was one of the primary examples of an activation-style threading API, before it was ultimately abandoned due to the problems that arose. I'm interested in tracking down sources, like reports, discussions, or possibly testimonies from people who were involved that talk specifically about the nature of those problems. I'm aware of the overall design and the sources describing it; the sense I got from some old email threads of the problems it that they were mostly related to mismatches between the programming models that would benefit most from that style of activation and the POSIX thread/signal semantics. If anyone is aware of sources that go into greater detail and could point me to them, it would help me out a great deal. From owner-freebsd-hackers@freebsd.org Sat Jan 2 17:20:28 2021 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 D74C94D7AD8 for ; Sat, 2 Jan 2021 17:20:28 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) (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 4D7TDX1BL2z4gBk; Sat, 2 Jan 2021 17:20:28 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 5A550EB2A5; Sat, 2 Jan 2021 09:20:20 -0800 (PST) MIME-Version: 1.0 Date: Sat, 02 Jan 2021 09:20:20 -0800 From: Neel Chauhan To: Doug Ambrisko Cc: Mark Johnston , freebsd-hackers@freebsd.org, ambrisko@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL In-Reply-To: <4f3f6a02a452f766063ae2acb060dc64@neelc.org> References: <44528336fa9168966d121bf771e1e229@neelc.org> <3c9ff844e527daacd04c51f48836b57d@neelc.org> <20201231200744.GA95383@ambrisko.com> <4f3f6a02a452f766063ae2acb060dc64@neelc.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <7cda3be6594d5ad5bdc69019f72b03d3@neelc.org> X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D7TDX1BL2z4gBk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 2001:19f0:8001:fed:5400:2ff:fe73:c622 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-1.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[neel]; 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]; R_SPF_ALLOW(-0.20)[+a]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 17:20:28 -0000 Just to ping you in case you may have missed my reply (I understand, New Years Day). Is there a reason why "b = pci_get_bus(dev);" return 0 even when the bus number is shifted (as it is on Linux)? -Neel On 2020-12-31 21:49, Neel Chauhan wrote: > Hi Doug, > > Thank you so much for this information. > > On 2020-12-31 12:07, Doug Ambrisko wrote: >> FYI, looks like this needs to be ported over from Linux: >> static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus >> *bus, >> unsigned int devfn, int reg, int >> len) >> { >> char __iomem *addr = vmd->cfgbar + >> ((bus->number - vmd->busn_start) << 20) + >> (devfn << 12) + reg; >> >> to >> vmd_read_config >> offset = (b << 20) + (s << 15) + (f << 12) + reg; >> >> vmd_write_config(device_t dev, u_int b, u_int s, u_int f, u_int reg, >> offset = (b << 20) + (s << 15) + (f << 12) + reg; >> >> ie. >> offset = ((b - sc->vmd_bus_start) << 20) + (s << 15) + (f << 12) + >> reg; >> >> vmd_bus_start should be added to the softc as a uint8_t type and needs >> to >> be set via attach. We need range checks to make sure >> vmd_write_config/vmd_read_config doesn't read something out of range >> since it has been reduced. > > One thing I noticed is that the "b" variable (which corresponds to the > Linux bus->number) is 0 (thanks to printf). This should be the bus > number if we want to attach. > > If I use: "b = pci_get_bus(dev);" in the attach, b is still 0. > > And that leads to a kernel panic. > >> Not sure what the shadow registers do. These both seem to be new >> Intel >> features and Intel doc's have been minimal. Looks like Intel is doing >> a sparse map now on newer devices. > > I guess Linux is our best hope. Unless the new Intel docs is the Linux > kernel source. > >> I'm concerned about the Linux comment of: >> * Certain VMD devices may have a root port configuration >> option which >> * limits the bus range to between 0-127, 128-255, or 224-255 >> >> since I don't see anything to limit it between 0-127 only starting >> at 0, 128 or 224, Maybe there is max of 128 busses overall? > > I could be wrong, but I guess that's a typo. > >> I don't have this type of HW to test things. > > I can use my hardware for testing. In the worse case scenario, I can > donate an entry-level 11th Gen/TigerLake system if I have the funds > and/or can get a tax credit. > >> Doug A. > > -Neel > _______________________________________________ > 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 Jan 2 19:06:51 2021 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 135814DB556 for ; Sat, 2 Jan 2021 19:06:51 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7WbG51Rkz4pHr; Sat, 2 Jan 2021 19:06:50 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: UVCxjv2eXQsCV+ckB7miTEZqhH/G5RKkDRTABlsu6Wwp8tgSke5ryVWS1T7+Z+hc84G30FAss9 xDzssj9U/jUsphpdD/42UYWJ2oOqbnKW0= X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 02 Jan 2021 10:30:00 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.15.2/8.15.2) with ESMTPS id 102J6iAe090727 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 2 Jan 2021 11:06:44 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.15.2/8.15.2/Submit) id 102J6i5u090726; Sat, 2 Jan 2021 11:06:44 -0800 (PST) (envelope-from ambrisko) Date: Sat, 2 Jan 2021 11:06:44 -0800 From: Doug Ambrisko To: Neel Chauhan Cc: Mark Johnston , freebsd-hackers@freebsd.org, ambrisko@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL Message-ID: <20210102190644.GB87535@ambrisko.com> References: <44528336fa9168966d121bf771e1e229@neelc.org> <3c9ff844e527daacd04c51f48836b57d@neelc.org> <20201231200744.GA95383@ambrisko.com> <4f3f6a02a452f766063ae2acb060dc64@neelc.org> <7cda3be6594d5ad5bdc69019f72b03d3@neelc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7cda3be6594d5ad5bdc69019f72b03d3@neelc.org> X-Rspamd-Queue-Id: 4D7WbG51Rkz4pHr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 19:06:51 -0000 With VMD, the PCI "root" is hidden behind it. To access devices behind the VMD device, a new domain is created and when PCI config. space is accessed, it is indexed via the VMD device via the offset. Intel seems to have reduced the available bus space on some HW. So for a bus access less then what they implemented in HW we have to return error that nothing is there. Then when we get to the starting bus device, we need to offset that to 0 based in the HW. The PCI probe will run look for busses from 0 to 255. From the Linux driver your HW only works from 224 to 255. So we need to fail anything under 224 and for bus requests 224 and higher then subtract 224. Thus the b - sc->vmd_bus_start part. I'm not sure if we could do it the other way in which we allow 0-12 bus requests to pass and fail if it is over. I'm not sure if there is any specific reason why that wouldn't work. Linux didn't do that but that doesn't mean it wouldn't work. It would be good to start with the Linux method and then test 0-n, where n is the max. busses that HW allows. Anything n or more would have to return a fail. Doug A. On Sat, Jan 02, 2021 at 09:20:20AM -0800, Neel Chauhan wrote: | Just to ping you in case you may have missed my reply (I understand, New | Years Day). | | Is there a reason why "b = pci_get_bus(dev);" return 0 even when the bus | number is shifted (as it is on Linux)? | | -Neel | | On 2020-12-31 21:49, Neel Chauhan wrote: | > Hi Doug, | > | > Thank you so much for this information. | > | > On 2020-12-31 12:07, Doug Ambrisko wrote: | >> FYI, looks like this needs to be ported over from Linux: | >> static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus | >> *bus, | >> unsigned int devfn, int reg, int | >> len) | >> { | >> char __iomem *addr = vmd->cfgbar + | >> ((bus->number - vmd->busn_start) << 20) + | >> (devfn << 12) + reg; | >> | >> to | >> vmd_read_config | >> offset = (b << 20) + (s << 15) + (f << 12) + reg; | >> | >> vmd_write_config(device_t dev, u_int b, u_int s, u_int f, u_int reg, | >> offset = (b << 20) + (s << 15) + (f << 12) + reg; | >> | >> ie. | >> offset = ((b - sc->vmd_bus_start) << 20) + (s << 15) + (f << 12) + | >> reg; | >> | >> vmd_bus_start should be added to the softc as a uint8_t type and needs | >> to | >> be set via attach. We need range checks to make sure | >> vmd_write_config/vmd_read_config doesn't read something out of range | >> since it has been reduced. | > | > One thing I noticed is that the "b" variable (which corresponds to the | > Linux bus->number) is 0 (thanks to printf). This should be the bus | > number if we want to attach. | > | > If I use: "b = pci_get_bus(dev);" in the attach, b is still 0. | > | > And that leads to a kernel panic. | > | >> Not sure what the shadow registers do. These both seem to be new | >> Intel | >> features and Intel doc's have been minimal. Looks like Intel is doing | >> a sparse map now on newer devices. | > | > I guess Linux is our best hope. Unless the new Intel docs is the Linux | > kernel source. | > | >> I'm concerned about the Linux comment of: | >> * Certain VMD devices may have a root port configuration | >> option which | >> * limits the bus range to between 0-127, 128-255, or 224-255 | >> | >> since I don't see anything to limit it between 0-127 only starting | >> at 0, 128 or 224, Maybe there is max of 128 busses overall? | > | > I could be wrong, but I guess that's a typo. | > | >> I don't have this type of HW to test things. | > | > I can use my hardware for testing. In the worse case scenario, I can | > donate an entry-level 11th Gen/TigerLake system if I have the funds | > and/or can get a tax credit. | > | >> Doug A. | > | > -Neel From owner-freebsd-hackers@freebsd.org Sat Jan 2 23:45:22 2021 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 394D04BC441 for ; Sat, 2 Jan 2021 23:45:22 +0000 (UTC) (envelope-from chrisj@rtems.org) Received: from nsstlmta38p.bpe.bigpond.com (nsstlmta38p.bpe.bigpond.com [203.38.21.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7dmc1dKhz3PWN for ; Sat, 2 Jan 2021 23:45:19 +0000 (UTC) (envelope-from chrisj@rtems.org) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep38p-svc.bpe.nexus.telstra.com.au with ESMTP id <20210102234515.WTRO10214.nsstlfep38p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com>; Sun, 3 Jan 2021 10:45:15 +1100 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedrvdeftddgudehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuuffpveftpgfvgffnuffvtfetpdfqfgfvnecuuegrihhlohhuthemucegtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefjeenucfhrhhomhepvehhrhhishculfhohhhnshcuoegthhhrihhsjhesrhhtvghmshdrohhrgheqnecuggftrfgrthhtvghrnhepieekuedtjeeuhfdugeejgfekueeiffevfedvveevtdevheffveffieevueelffejnecukfhppedufeelrddufedtrddvgeehrddvtddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepmhgrihhlrdgtohhnthgvmhhpohhrrghrhidrnhgvthdrrghupdhinhgvthepudefledrudeftddrvdeghedrvddttddpmhgrihhlfhhrohhmpeeotghhrhhishhjsehrthgvmhhsrdhorhhgqedprhgtphhtthhopeeofhhrvggvsghsugdqhhgrtghkvghrshesfhhrvggvsghsugdrohhrgheqpdhrtghpthhtohepoehrmhgrtghklhgvmhesuhhoghhuvghlphhhrdgtrgeq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RG-VS-CLASS: clean Received: from mail.contemporary.net.au (139.130.245.200) by smtp.telstra.com (5.8.420) id 5FE6CCD0024EE70D; Sun, 3 Jan 2021 10:45:15 +1100 Received: from [10.10.11.8] ([10.10.11.8]) (authenticated bits=0) by mail.contemporary.net.au (8.15.2/8.15.2) with ESMTPSA id 102NjAe8023959 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 3 Jan 2021 10:45:10 +1100 (EST) (envelope-from chrisj@rtems.org) Subject: Re: sys/fs/nfsclient on RTEMS gets a bad seqid error with open To: Rick Macklem Cc: "freebsd-hackers@freebsd.org" References: From: Chris Johns Organization: https://www.rtems.org/ Message-ID: <888017f2-eea6-12f9-fb24-04a1e1d95ea8@rtems.org> Date: Sun, 3 Jan 2021 10:45:09 +1100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-104.0 required=2.7 tests=ALL_TRUSTED,BAYES_00, NICE_REPLY_A,TW_EQ,USER_IN_WELCOMELIST,USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on corb.contemporary.net.au X-Rspamd-Queue-Id: 4D7dmc1dKhz3PWN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of chrisj@rtems.org has no SPF policy when checking 203.38.21.38) smtp.mailfrom=chrisj@rtems.org X-Spamd-Result: default: False [-2.20 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_LOW(-0.10)[203.38.21.38:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[203.38.21.38:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:1221, ipnet:203.36.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[rtems.org]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[203.38.21.38:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 23:45:22 -0000 On 1/1/21 12:09 pm, Rick Macklem wrote: >> On 31/12/20 10:04 am, Rick Macklem wrote: >>> Chris Johns wrote: >>>> Hello, >>>> >>>> I am porting the kernel's nfsclient file system to the RTEMS port of FreeBSD. I >>>> have ported across the FreeBSD file descriptors, VFS and NFS code. I have a >>>> custom pseudofs file system as my root file system and I can mount an NFSv4 >>>> mount exported from a FreeBSD 12 box. >>>> >>>> When I open a file there are a some getattr RPC calls that are successful >>>> however the open call (PUTFH, OPEN, GETATTR) results in the server returning the >>>> bas seqid (10026) error code for the OPEN and I am not sure why this is >>>> happening. I suspect I am missing a step in the nfsclient set up. >>> Well, for NFSv4.0 Opens, there is a field in the open_owner called a "seqid', >>> which is used to serialize Open calls. If that "seqid" gets screwed up, you >>> get a "bad seqid" (10026) from the server and your mount is broken. >> >> There is only one open call being made and the seq id in the packet is 0. The >> server code seems to consider ownership when returning this error and this is an >> area I am not sure about. RTEMS simulates a process and does not have a normal >> user/group model. > Did you do a Setclientid, Setclientidconfirm to set up the clientid? The nfsclient code by default seemed to do this but now I have set nfsv4 as an option (required by minorversion) I get a different set of packets being exchanged. I will work with NFSv4.1. > The first Open should be fine with seqid==0 and the reply will flag it > as "needs Openconfirm". > --> 10026 means the server thinks it has already seen the open_owner > string for that client. > > I'd suggest to capture a packet trace of a mount from the FreeBSD client > and then look at it in wireshark, to see what should be happening. Yes and thanks, I am doing this. My lack of knowledge about the NFSv4 protocol is the issue here :) >>> A couple of possibilities: >>> - The FreeBSD client code depends on an exclusive lock on the vnode >>> to serialize the Opens. >> >> There is only one open call active. This is something I can control. > If all your Opens are serialized, you can use a single open_owner for > everything. The open_owner string should always be the same to do > this. > The FreeBSD client can do this for NFSv4.1 by specifying "oneopenown" > as a mount option. I had this set. >>> --> If what you are doing doesn't serialize them, then that will be a >>> problem. >>> - If the VOP_OPEN() generates an unexpected error (I just ran into this >>> on FreeBSD head), then the client might not get things correct. >>> --> The seqid is incremented for some errors, but not others. >> >> I am currently basing this work on the FreeBSD 12 branch we have. A master port >> is next. >> >> Btw, all this seqid stuff goes away when you use NFSv4.1 and there >> are NFSv4.1 only clients out there. You might want to consider doing >> this. If I was writing the code now, there would be no NFSv4.0. >> >> Ah OK. How do I make the FreeBSD nfsclient operate as NFSv4.1? I looked into >> this but I could not figure out how. > minorversion=1 mount option, which sets nm_minorvers to 1. Ah yes I see it now. Thank you. I was required to set nfsv4 which is what I want but it does make me wonder about the default version I was using. I would have thought v4 would be the default. Maybe it is something in the defaults in mount_nfs that I should take a look at. These settings seems to have resolved the situation and I have moved further and onto other issues related to the port of the lockmgr. Chris From owner-freebsd-hackers@freebsd.org Sat Jan 2 23:58:53 2021 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 9ABC84BCED0 for ; Sat, 2 Jan 2021 23:58:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on061d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::61d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7f4D2sYPz3PwF for ; Sat, 2 Jan 2021 23:58:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dL0yUwbhlJcH4koFXb8d6LZ0xBrKQy7yBFLriu0AWGLYw2Dzztu3B4QWm4qrM9D0N+wRC9PVC4f3Qd0kwdFOb+iyZcw5f6R/l2DfpQ8Zt8hIf+trgNQTZ7fYQtRtVJkLLqZ/QwZCiCa8hr11LJTlkSLoQZCFOHLfDCCNvfZ9vYqsr618VJznvYdj0oCx5qoMwgwhtkkcMub7qYO00HoOBJdLWAjcQPQLwGYqy1ZvvVl0pXGbWUYCe7mr7TCN2DwowI6Co5FOb1Gz4xN63nU28ONjuyu3bW37Tp4FNAZKo5tFgdGK4w1A0iIL1fN4KRG8J3ERrRqIaWRv2xeirkilpw== 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=Rn2Cg/oNlrOOIR8doEwc8m7qn2xqrgAM+uEQDHhi2aE=; b=eufhlfWBMLDyhCYbupdrZVDwqkKbcfFaews14pAxrOx7HBkApTYvdIAVevILS2mPXcyekhLR6M/FG7AWV5NILQGGUQK42xIPatz8+7N9bP82pfjpHMey2lA23G+bPBnfE0Cs4xYtNuU9P4VS19sVl/6RgyoTH0+x5Fcq5//Q6SxajcZHHJ8d70snVr3+G+29Q67Bk+QJ0uvFqbYDNrxs02gl4YkQho4EEsP/3YiaPuc9n7b2TKI394FII4XiMUsfvM83a5cjcYk4llD8XBvnRhR4e4jcyCNSxhKTpNSSvenzynQqtB07NVpHs69QgDq5ifb/Hp7GAjm2DQVF+F9LyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rn2Cg/oNlrOOIR8doEwc8m7qn2xqrgAM+uEQDHhi2aE=; b=vyRlGvDbfks3DiEWfUdmxQsHfuCVC7fMSzFw/1l2ZvDRic9SfnaFvvXMFZStVC62HX8BBxn+Ajv1pGs3otbttsucw8D8jLzpFcfWY+oVUbniLIbOKQOm++HWq7xP9Xb0jrosv68BVYYVQ9xafkxpIEJllmJyqXLNumrINcbuWJjJ6GNwC0dsCGVo7W5oLtnc/jXa8u4oa1uO9lJ7+XlMGH3jkr2AoJ2BA6Cenx0yLOY3trpYXdSQTEE174uAnJm74VQAauUbU03OhzpLzogCqHKktGw/ET7Kzn8v9/CR9u9e84M6DWgsc9GMjSUD5ylO5O409NApXf8exUKx1C6QUA== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB3093.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:4b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.19; Sat, 2 Jan 2021 23:58:49 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3721.023; Sat, 2 Jan 2021 23:58:49 +0000 From: Rick Macklem To: Chris Johns CC: "freebsd-hackers@freebsd.org" Subject: Re: sys/fs/nfsclient on RTEMS gets a bad seqid error with open Thread-Topic: sys/fs/nfsclient on RTEMS gets a bad seqid error with open Thread-Index: AQHW39ixX2g8xupI30yVViAOBKgn+qoVAuqAgAACQiQ= Date: Sat, 2 Jan 2021 23:58:49 +0000 Message-ID: References: , <888017f2-eea6-12f9-fb24-04a1e1d95ea8@rtems.org> In-Reply-To: <888017f2-eea6-12f9-fb24-04a1e1d95ea8@rtems.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cc517a92-3de9-4baa-e67c-08d8af7a5996 x-ms-traffictypediagnostic: YQXPR01MB3093: 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: MJpslhCCtEpLIJrGgQp53uhfu4JCnUajv8v8PiTVhYhN9iDfvXAhWns6SeQyoGuPMx0GG9/2/nylff1OYBZPLSbajgjKmX/4/1tgnpq4Tq9yb9m2DgAli29DxjqVzXnVtdRLHiK8FGVtjBP6p8D02eUutOScQz7umJfIyctiyU4TiNG0mHadldCL9dkrFDRYHIap95xXrtJCZjICi8EyU4jm466skPoo3okUxevkMZsyQs77DJVnPW5UsBljO1A63dYiPWRGx/MP034byMZ66upoDpdLkuA+0UvkzWaAusrlAGAAmresO9Yxe89T5/hv1akJNvAmevvtsVCt7s07TukVZz4Ei/GAazQzV/+wOS7/BtqmcrAzQETGrBUURxZrR/dXt7LQ+fKo+TNzbsIkEQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(366004)(376002)(39850400004)(136003)(396003)(71200400001)(478600001)(52536014)(33656002)(6506007)(8936002)(76116006)(66556008)(64756008)(91956017)(66476007)(66946007)(66446008)(2906002)(83380400001)(86362001)(6916009)(786003)(4326008)(8676002)(7696005)(26005)(5660300002)(316002)(186003)(55016002)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?X9EUt34YFF2f+9GKWLfoMRE9yOUG6sEFtu/neQHg07LfgG9Fq5XFHyYG3R?= =?iso-8859-1?Q?3oMPFpR2GLRPzUCQg2ulqoADhhDfX88yEoZB9DGnqa5oiLZok1yPopnP7/?= =?iso-8859-1?Q?tNGi/SDGESuwOhOJir0rGBdjNjBzeTAJ5pJwyfxR/N5V69E3DygsjUWrTn?= =?iso-8859-1?Q?JEMtHjhfTz66sO4bODBV4CtlZulpV6bnljTDHe3PcGhi/CwK+ZxZdLDMSU?= =?iso-8859-1?Q?VltLE7H5dCelf4spdHRQ2NMPPYRORHO1BN8iE94EUE2T70AKTumAYGWg3y?= =?iso-8859-1?Q?7ipIWohJ4eGMKk+IRkq4pLAUUlY88+onS0TJUL8abFXcpoZwsaFMHDWQE8?= =?iso-8859-1?Q?QBB5SgzjgtcujPmooNzb7/+F3KK4F0oMRrslejkdGZMheURH1YgVJZ8q0k?= =?iso-8859-1?Q?gtIsLVeTh+6kvhM3/9Ha06jrrrrP/maJlWLjqWTFCEAHqOZ7qgQjQd5hmq?= =?iso-8859-1?Q?yx051bUnmmETiGGKlcFy25GlGrJoaaI0SrEQTGIX9Gvv9AtVb4e8l4zQXj?= =?iso-8859-1?Q?V57xtdqzsh/sZILeoZRhseWDRW/JxKmkZAGEDk8o7SPZ9ewrqn4n2TvM3W?= =?iso-8859-1?Q?hvTQ4YxG6RAeh8kyDi/9Pzm8v9s3GE7GQcWKa2UB553RIPsCBmIuz90b6X?= =?iso-8859-1?Q?5qHTABAWa85qZLR5VzgMThBtpuXTVfxA9BX7izA6RXIyLcXIi176uCv+EV?= =?iso-8859-1?Q?vVlU98tnxiMNJHvVxI0lsnRESAq5VGyT7ptP0wwRSA7chPItdoxN6RUcBh?= =?iso-8859-1?Q?OL451/T5lmCtJ4enE+FWONZ7suBHp0IraGb1s7Tn9NYkyZHNkWZjPHLOKg?= =?iso-8859-1?Q?mef4B81YyVF4iOQAjtcX2Ml9ce9ypnEsHsiz9Mtc0LQQormAUA6o27cpZy?= =?iso-8859-1?Q?88EwpAyLNantzJZQvswznJ41A69LMy0AuLdzpFUp7ANu0foF7D7P9IphmN?= =?iso-8859-1?Q?Fb//9yK74Kd6VzoGhRw7sqlxbdB9YXqHBM+ZmZDT1eILJPRi7lcBOGRf04?= =?iso-8859-1?Q?vDrrBmCyIRpvSFxqA=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: cc517a92-3de9-4baa-e67c-08d8af7a5996 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2021 23:58:49.6407 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yMhdjsl3RurZg4O+xawSY2sfNscrhcix0HvsJjlioBkpvrSfhZ8cRj39YwXCdcJItLAQXBoS4P5qeQOhBqgCIg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3093 X-Rspamd-Queue-Id: 4D7f4D2sYPz3PwF X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=vyRlGvDb; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5d::61d as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a01:111:f400:fe5d::61d:from]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[2a01:111:f400:fe5d::61d:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 23:58:53 -0000 Chris Johns wrote:=0A= [stuff snipped]=0A= >Rick Macklem wrote:=0A= >> Did you do a Setclientid, Setclientidconfirm to set up the clientid?=0A= >=0A= >The nfsclient code by default seemed to do this but now I have set nfsv4 a= s an=0A= >option (required by minorversion) I get a different set of packets being= =0A= >exchanged. I will work with NFSv4.1.=0A= Yes. Setclientid, Setclientidcfrm is NFSv4.0 specific.=0A= For NFSv4.1 and 4.2, the clientid is created/confirmed by=0A= ExchangeID, CreateSession=0A= =0A= rick=0A= =0A= > The first Open should be fine with seqid=3D=3D0 and the reply will flag i= t=0A= > as "needs Openconfirm".=0A= > --> 10026 means the server thinks it has already seen the open_owner=0A= > string for that client.=0A= >=0A= > I'd suggest to capture a packet trace of a mount from the FreeBSD client= =0A= > and then look at it in wireshark, to see what should be happening.=0A= =0A= Yes and thanks, I am doing this. My lack of knowledge about the NFSv4 proto= col=0A= is the issue here :)=0A= =0A= >>> A couple of possibilities:=0A= >>> - The FreeBSD client code depends on an exclusive lock on the vnode=0A= >>> to serialize the Opens.=0A= >>=0A= >> There is only one open call active. This is something I can control.=0A= > If all your Opens are serialized, you can use a single open_owner for=0A= > everything. The open_owner string should always be the same to do=0A= > this.=0A= > The FreeBSD client can do this for NFSv4.1 by specifying "oneopenown"=0A= > as a mount option.=0A= =0A= I had this set.=0A= =0A= >>> --> If what you are doing doesn't serialize them, then that will be = a=0A= >>> problem.=0A= >>> - If the VOP_OPEN() generates an unexpected error (I just ran into this= =0A= >>> on FreeBSD head), then the client might not get things correct.=0A= >>> --> The seqid is incremented for some errors, but not others.=0A= >>=0A= >> I am currently basing this work on the FreeBSD 12 branch we have. A mast= er port=0A= >> is next.=0A= >>=0A= >> Btw, all this seqid stuff goes away when you use NFSv4.1 and there=0A= >> are NFSv4.1 only clients out there. You might want to consider doing=0A= >> this. If I was writing the code now, there would be no NFSv4.0.=0A= >>=0A= >> Ah OK. How do I make the FreeBSD nfsclient operate as NFSv4.1? I looked = into=0A= >> this but I could not figure out how.=0A= > minorversion=3D1 mount option, which sets nm_minorvers to 1.=0A= =0A= Ah yes I see it now. Thank you. I was required to set nfsv4 which is what I= want=0A= but it does make me wonder about the default version I was using. I would h= ave=0A= thought v4 would be the default. Maybe it is something in the defaults in= =0A= mount_nfs that I should take a look at.=0A= =0A= These settings seems to have resolved the situation and I have moved furthe= r and=0A= onto other issues related to the port of the lockmgr.=0A= =0A= Chris=0A=