Date: Tue, 17 Nov 2020 12:56:19 +0000 (UTC) From: Filippo Moretti <filippomore@yahoo.com> To: "current@freebsd.org" <current@freebsd.org> Subject: Re: in -current is svn still canonical? Message-ID: <1456265078.6475084.1605617779122@mail.yahoo.com> In-Reply-To: <X7O1/9%2BToX7ufTZm@albert.catwhisker.org> References: <X7L02oCA1yveimZD@rpi4.local> <5fb33a11.1c69fb81.2d2a6.f92eSMTPIN_ADDED_MISSING@mx.google.com> <CANCZdfqb7TqhZA4yAVChyKhez5sxuhb-nYYbTP3DcsJKdk%2BFRw@mail.gmail.com> <5fb35900.1c69fb81.7679c.a50eSMTPIN_ADDED_MISSING@mx.google.com> <CANCZdfo%2Bk7bW=AepkDFUYQsQC3DqMAYsJKDxR-D9D=eyRKX97w@mail.gmail.com> <X7O1/9%2BToX7ufTZm@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
For user will git be in the base system or should we install from ports/pkg?Filippo
On Tuesday, November 17, 2020, 12:38:00 PM GMT+1, David Wolfskill <david@catwhisker.org> wrote:
On Mon, Nov 16, 2020 at 10:32:38PM -0700, Warner Losh wrote:
> ...
> However, when you make the switch to git (either due to the flag day and
> tracking -current, or jumping from svn on a stable branch), there's no tool
> to convert the subversion checked out tree to a git tree. The needed
> information needed to create the git tree isn't easily available from the
> subversion checkout, so you'll need to do a git clone. If bandwidth is a
> problem, you can do a shallow clone that omits all the history and just
> grabs the branch of interest. Git is a bit more link efficient than
> subversion, which is helpful. Git also has ways to help you share one local
> repo across checked out versions, which can also help if you have to track
> multiple branches.
> ....
Folks in that position might want to consider making the switch (for a
given repo -- src; ports; doc) in two stages over a period of time: the
first, to get an initial copy, then (the first of a series of)
incremental updates. The duration of the first need not be especially
critical. Of course, this presumes adequate local storage space.
(I am currently testing my approach, using cgit-beta.freebsd.org for
each of the three repos; the approach I am using is described in
http://www.catwhisker.org/~david/FreeBSD/repo-sync.html, in case that's
of use. Please note that I am actually using both svn & git, relying on
svn for now, as it is the Source of Truth.)
Peace,
david
--
David H. Wolfskill               david@catwhisker.org
Trump's continuing malfeasance is costing lives -- and 72M voted for this??!?
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
From owner-freebsd-current@freebsd.org Tue Nov 17 13:03:45 2020
Return-Path: <owner-freebsd-current@freebsd.org>
Delivered-To: freebsd-current@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 B3F982EC519
for <freebsd-current@mailman.nyi.freebsd.org>;
Tue, 17 Nov 2020 13:03:45 +0000 (UTC)
(envelope-from vladimir@kondratyev.su)
Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org
[IPv6:2610:1c1:1:606c::50:13])
by mx1.freebsd.org (Postfix) with ESMTP id 4Cb5jY2Mcjz4dRB
for <freebsd-current@freebsd.org>; Tue, 17 Nov 2020 13:03:45 +0000 (UTC)
(envelope-from vladimir@kondratyev.su)
Received: by mailman.nyi.freebsd.org (Postfix)
id 4F76B2EC518; Tue, 17 Nov 2020 13:03:45 +0000 (UTC)
Delivered-To: current@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 4F2C52EC07A;
Tue, 17 Nov 2020 13:03:45 +0000 (UTC)
(envelope-from vladimir@kondratyev.su)
Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3])
by mx1.freebsd.org (Postfix) with ESMTP id 4Cb5jY0vdHz4dJD;
Tue, 17 Nov 2020 13:03:44 +0000 (UTC)
(envelope-from vladimir@kondratyev.su)
Received: from corp (corp.infotel.ru [195.170.219.3])
by corp.infotel.ru (Postfix) with ESMTP id 3C91714A1DB;
Tue, 17 Nov 2020 16:03:41 +0300 (MSK)
X-Virus-Scanned: amavisd-new at corp.infotel.ru
Received: from corp.infotel.ru ([195.170.219.3])
by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024)
with ESMTP id LbZ41G1Y-B3O; Tue, 17 Nov 2020 16:03:40 +0300 (MSK)
Received: from mail.cicgroup.ru (unknown [195.170.219.74])
by corp.infotel.ru (Postfix) with ESMTP id 3682514A1C9;
Tue, 17 Nov 2020 16:03:40 +0300 (MSK)
Received: from mail.cicgroup.ru (localhost [127.0.0.1])
by mail.cicgroup.ru (Postfix) with ESMTP id A26D942211F;
Tue, 17 Nov 2020 16:00:05 +0300 (MSK)
X-Virus-Scanned: amavisd-new at cicgroup.ru
Received: from mail.cicgroup.ru ([127.0.0.1])
by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024)
with SMTP id SoR4_zRiYRoB; Tue, 17 Nov 2020 16:00:02 +0300 (MSK)
Received: from localhost (localhost [127.0.0.1])
by mail.cicgroup.ru (Postfix) with ESMTPA id 827E142211C;
Tue, 17 Nov 2020 16:00:02 +0300 (MSK)
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_f223c48cebd9d2186d47a843b4b786c1"
Date: Tue, 17 Nov 2020 16:00:02 +0300
From: Vladimir Kondratyev <vladimir@kondratyev.su>
To: Yuri Pankov <yuripv@yuripv.dev>
Cc: current@freebsd.org, owner-freebsd-current@freebsd.org
Subject: Re: acpi_wmi noisy without EC
In-Reply-To: <5bb9ac64-ebab-4d22-8a43-1305b16f28cd@www.fastmail.com>
References: <7dc142d3-1e0b-41d4-bdb4-7217bd09bbef@www.fastmail.com>
<7b80877ae59fdd90f2f3b5dbf3db2113@kondratyev.su>
<fb0874b1cf4510a2d797a83a01d55935@kondratyev.su>
<5bb9ac64-ebab-4d22-8a43-1305b16f28cd@www.fastmail.com>
Message-ID: <274d456e15ce621889bfe9e7eda190da@kondratyev.su>
X-Sender: vladimir@kondratyev.su
User-Agent: Roundcube Webmail/1.3.5
X-Rspamd-Queue-Id: 4Cb5jY0vdHz4dJD
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
REPLY(-4.00)[]
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>;
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2020 13:03:45 -0000
--=_f223c48cebd9d2186d47a843b4b786c1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
format=flowed
On 2020-11-17 15:29, Yuri Pankov wrote:
> On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
>> On 2020-11-17 10:57, Vladimir Kondratyev wrote:
>> > On 2020-11-17 03:00, Yuri Pankov wrote:
>> >> I have started seeing the following on boot since some time:
>> >>
>> >> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>> >> acpi_wmi0: cannot find EC device
>> >> device_attach: acpi_wmi0 attach returned 6
>> >> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>> >> acpi_wmi0: cannot find EC device
>> >> device_attach: acpi_wmi0 attach returned 6
>> >> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>> >> acpi_wmi0: cannot find EC device
>> >> device_attach: acpi_wmi0 attach returned 6
>> >> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>> >> acpi_wmi0: cannot find EC device
>> >> device_attach: acpi_wmi0 attach returned 6
>> >>
>> >> Likely following this commit:
>> >>
>> >> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
>> >> Author: Vladimir Kondratyev <wulf@FreeBSD.org>
>> >> Date: Sat Oct 31 22:19:39 2020 +0000
>> >>
>> >> acpi_wmi(4): Add ACPI_PNP_INFO
>> >>
>> >> While the reason is obvious -- there's no EC in this system (Gigabyte
>> >> X299X AORUS MASTER desktop motherboard), at least searching the
>> >> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
>> >> looks like "something is broken" when first noticed. I wonder if we
>> >> could/should handle this gracefully -- no EC, do nothing, simply exit?
>> >
>> > Following patch should ignore missing EC like Linux does. Could you
>> > test it?
>> >
>> > diff --git a/sys/dev/acpi_support/acpi_wmi.c
>> > b/sys/dev/acpi_support/acpi_wmi.c
>> > index 379cfd1705f1..efae96cdcc9a 100644
>> > --- a/sys/dev/acpi_support/acpi_wmi.c
>> > +++ b/sys/dev/acpi_support/acpi_wmi.c
>> > @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
>> > if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
>> > == NULL)
>> > device_printf(dev, "cannot find EC device\n");
>> > - else if (ACPI_FAILURE((status >> > AcpiInstallNotifyHandler(sc->wmi_handle,
>> > + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
>> > ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc))))
>> > device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
>> > AcpiFormatException(status));
>> > @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
>> > ACPI_PHYSICAL_ADDRESS address,
>> > return (AE_BAD_PARAMETER);
>> > if (address + (width / 8) - 1 > 0xFF)
>> > return (AE_BAD_ADDRESS);
>> > + if (sc->ec_dev == NULL)
>> > + return (AE_NOT_FOUND);
>> > if (function == ACPI_READ)
>> > *value = 0;
>> > ec_addr = address;
>>
>> @#@##! Web client ate all the tabs.
>>
>> Patch is in attachment.
>
> Output changed, though it's still somewhat noisy -- I guess there
> isn't a way to NOT report the device that we are not going to attach
> to, or do that e.g. only for verbose boot?
>
> acpi_wmi0: <ACPI-WMI mapping> on acpi0
> acpi_wmi0: cannot find EC device
> acpi_wmi0: Embedded MOF found
> ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
> object (Buffer) (20201113/nsarguments-361)
> acpi_wmi1: <ACPI-WMI mapping> on acpi0
> acpi_wmi1: cannot find EC device
> acpi_wmi2: <ACPI-WMI mapping> on acpi0
> acpi_wmi2: cannot find EC device
> acpi_wmi3: <ACPI-WMI mapping> on acpi0
> acpi_wmi3: cannot find EC device
acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it
in OpRegion handler.
WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has
successfully attached to 4 nodes.
Verbosity can be reduced with attached patch if current level is too
high for you.
--
WBR
Vladimir Kondratyev
--=_f223c48cebd9d2186d47a843b4b786c1
Content-Transfer-Encoding: base64
Content-Type: text/x-diff;
name¬pi_wmi.c.patch
Content-Disposition: attachment;
filename¬pi_wmi.c.patch;
size60
ZGlmZiAtLWdpdCBhL3N5cy9kZXYvYWNwaV9zdXBwb3J0L2FjcGlfd21pLmMgYi9zeXMvZGV2L2Fj
cGlfc3VwcG9ydC9hY3BpX3dtaS5jCmluZGV4IDM3OWNmZDE3MDVmMS4uMWZkZGNkNGYzNjM3IDEw
MDY0NAotLS0gYS9zeXMvZGV2L2FjcGlfc3VwcG9ydC9hY3BpX3dtaS5jCisrKyBiL3N5cy9kZXYv
YWNwaV9zdXBwb3J0L2FjcGlfd21pLmMKQEAgLTI0NSw4ICsyNDUsOSBAQCBhY3BpX3dtaV9hdHRh
Y2goZGV2aWNlX3QgZGV2KQogCS8qIFhYWCBPbmx5IHdvcmtzIHdpdGggb25lIEVDLCBidXQgbmVh
cmx5IGFsbCBzeXN0ZW1zIG9ubHkgaGF2ZSBvbmUuICovCiAJaWYgKChzYy0+ZWNfZGV2ID0gZGV2
Y2xhc3NfZ2V0X2RldmljZShkZXZjbGFzc19maW5kKCJhY3BpX2VjIiksIDApKQogCSAgICA9PSBO
VUxMKQotCQlkZXZpY2VfcHJpbnRmKGRldiwgImNhbm5vdCBmaW5kIEVDIGRldmljZVxuIik7Ci0J
ZWxzZSBpZiAoQUNQSV9GQUlMVVJFKChzdGF0dXMgPSBBY3BpSW5zdGFsbE5vdGlmeUhhbmRsZXIo
c2MtPndtaV9oYW5kbGUsCisJCUFDUElfVlBSSU5UKGRldiwgYWNwaV9kZXZpY2VfZ2V0X3BhcmVu
dF9zb2Z0YyhkZXYpLAorCQkgICAgImNhbm5vdCBmaW5kIEVDIGRldmljZVxuIik7CisJaWYgKEFD
UElfRkFJTFVSRSgoc3RhdHVzID0gQWNwaUluc3RhbGxOb3RpZnlIYW5kbGVyKHNjLT53bWlfaGFu
ZGxlLAogCQkgICAgQUNQSV9ERVZJQ0VfTk9USUZZLCBhY3BpX3dtaV9ub3RpZnlfaGFuZGxlciwg
c2MpKSkpCiAJCWRldmljZV9wcmludGYoc2MtPndtaV9kZXYsICJjb3VsZG4ndCBpbnN0YWxsIG5v
dGlmeSBoYW5kbGVyIC0gJXNcbiIsCiAJCSAgICBBY3BpRm9ybWF0RXhjZXB0aW9uKHN0YXR1cykp
OwpAQCAtNzAxLDYgKzcwMiw4IEBAIGFjcGlfd21pX2VjX2hhbmRsZXIoVUlOVDMyIGZ1bmN0aW9u
LCBBQ1BJX1BIWVNJQ0FMX0FERFJFU1MgYWRkcmVzcywKIAkJcmV0dXJuIChBRV9CQURfUEFSQU1F
VEVSKTsKIAlpZiAoYWRkcmVzcyArICh3aWR0aCAvIDgpIC0gMSA+IDB4RkYpCiAJCXJldHVybiAo
QUVfQkFEX0FERFJFU1MpOworCWlmIChzYy0+ZWNfZGV2ID09IE5VTEwpCisJCXJldHVybiAoQUVf
Tk9UX0ZPVU5EKTsKIAlpZiAoZnVuY3Rpb24gPT0gQUNQSV9SRUFEKQogCQkqdmFsdWUgPSAwOwog
CWVjX2FkZHIgPSBhZGRyZXNzOwo--=_f223c48cebd9d2186d47a843b4b786c1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1456265078.6475084.1605617779122>