Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 2020-12-17 21:53, Thomas Mueller wrote: > I hope we don't have to start signing all commits. saltstack/salt has > that policy, and it's extremely annoying. Have to? Not currently. As with all process changes, there will be community discussion around the different points. Warner I hope not! Signatures, at least in email messages, are just an annoyance as I see them. I don't even know how do sign an email message or make use of a signature in a message I receive. I have never made a commit to a repository, so would not be familiar with signatures there; imagine it would be a barrier. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" I'm not a FreeBSD committer, but on other git projects I sign my commits. AFAIK it's a good idea. I'm curious what is annoying about it? It's just adding the 'sign' tag. If you want a portable GPG key check out something like a yubikey. I'm sure there's other portable hardware options. # git commit -S -m "message" You can also set to always sign automatically, # git config --global commit.gpgsign true -- Waitman Gobble ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
> > I hope we don't have to start signing all commits. saltstack/salt has > > that policy, and it's extremely annoying. > Have to? Not currently. As with all process changes, there will be > community discussion around the different points. > Warner I hope not! Signatures, at least in email messages, are just an annoyance as I see them. I don't even know how do sign an email message or make use of a signature in a message I receive. I have never made a commit to a repository, so would not be familiar with signatures there; imagine it would be a barrier. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
I tried cloning with the following result: [root@STING /home/filippo]# git clone -o freebsd -b main https://git.freebsd.org/src.git /usr/src Cloning into '/usr/src'... fatal: repository 'https://git.freebsd.org/src.git/' not found Should I wait past the weekend to clone?Filippo On Thursday, December 17, 2020, 8:53:22 PM GMT+1, Alan Somers wrote: On Thu, Dec 17, 2020 at 12:06 PM Warner Losh wrote: > On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn > wrote: > > > > > > > On 12/16/20 7:46 PM, Warner Losh wrote: > > > Greetings, > > > > > > The FreeBSD project will be moving it's source repo from subversion to > > git > > > starting this this weekend. The docs repo was moved 2 weeks ago. The > > ports > > > repo will move at the end of March, 2021 due to timing issues. > > > > > > The short version is that we're switching the version control we're > > using. > > > This switch will preserve much of the current FreeBSD development > > workflow. > > > After the switch, the subversion repo will become almost read-only. All > > > future work will be done in git, however as a transition aide we'll be > > > replaying the MFCs to stable/11, stable/12 and the related releng > > branches > > > for the life of those branches. > > > > > > For more detailed information, please see > > > https://github.com/bsdimp/freebsd-git-docs/ for the current > > documentation. > > > > > > Please see https://wiki.freebsd.org/git for the latest detailed > schedule > > > (please note that this schedule is subject to change). > > > > > > Warner > > > ___ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > > freebsd-current-unsubscr...@freebsd.org" > > > > > > > One question I didn't see in the (excellent!) docs is whether we should > > be PGP-signing commits or not. Is that encouraged? > > > > We've not started doing that in general. I don't think signing would cause > issues, but since it is a bit of an unknown, we've not taken a position on > this. > > Warner (on behalf of the git working group) > I hope we don't have to start signing all commits. saltstack/salt has that policy, and it's extremely annoying. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git tools for building in base?
On Wed, 2020-11-25 at 10:05:48 -0500, Shawn Webb wrote: On Wed, Nov 25, 2020 at 04:00:50PM +0100, Baptiste Daroussin wrote: On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote: > On Tue, Nov 24, 2020 at 2:19 PM tech-lists wrote: > > > As subject - what will there be in base to interact with the new git repo? > > I mean, right now, for svn there is svnlite. What for git? > > > > 'pkg add git' is your choice now. pkg install not pkg add There's also fetch for a one-time download of the ports tree (bootstrapping ports, for example). A HardenedBSD user would do this: fetch -o ports.tar.gz \ https://git-01.md.hardenedbsd.org/HardenedBSD/hardenedbsd-ports/archive/master.tar.gz mkdir -p /usr/ports tar -xf ports.tar.gz --strip-components 1 -C /usr/ports Something similar could be done in FreeBSDlandia. cgit supports this of course, so the troglodytes can download src/ports/doc from cgit, using only FreeBSD-provided tools like so: fetch -o- https://cgit.freebsd.org/doc/snapshot/doc-main.tar.gz | tar -C /usr/doc -xf - hth Uli ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Thu, 2020-12-17 at 13:39:09 -0700, Warner Losh wrote: On Thu, Dec 17, 2020 at 12:53 PM Alan Somers wrote: On Thu, Dec 17, 2020 at 12:06 PM Warner Losh wrote: On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn One question I didn't see in the (excellent!) docs is whether we should > be PGP-signing commits or not. Is that encouraged? > We've not started doing that in general. I don't think signing would cause issues, but since it is a bit of an unknown, we've not taken a position on this. Warner (on behalf of the git working group) I hope we don't have to start signing all commits. saltstack/salt has that policy, and it's extremely annoying. Have to? Not currently. As with all process changes, there will be community discussion around the different points. If you've successfully pushed your commit into FreeBSD.org infra, you've essentially signed it with a working SSH key. Isn't that enough? Cheers Uli ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Thu, Dec 17, 2020 at 12:53 PM Alan Somers wrote: > On Thu, Dec 17, 2020 at 12:06 PM Warner Losh wrote: > >> On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn > > >> wrote: >> >> > >> > >> > On 12/16/20 7:46 PM, Warner Losh wrote: >> > > Greetings, >> > > >> > > The FreeBSD project will be moving it's source repo from subversion to >> > git >> > > starting this this weekend. The docs repo was moved 2 weeks ago. The >> > ports >> > > repo will move at the end of March, 2021 due to timing issues. >> > > >> > > The short version is that we're switching the version control we're >> > using. >> > > This switch will preserve much of the current FreeBSD development >> > workflow. >> > > After the switch, the subversion repo will become almost read-only. >> All >> > > future work will be done in git, however as a transition aide we'll be >> > > replaying the MFCs to stable/11, stable/12 and the related releng >> > branches >> > > for the life of those branches. >> > > >> > > For more detailed information, please see >> > > https://github.com/bsdimp/freebsd-git-docs/ for the current >> > documentation. >> > > >> > > Please see https://wiki.freebsd.org/git for the latest detailed >> schedule >> > > (please note that this schedule is subject to change). >> > > >> > > Warner >> > > ___ >> > > freebsd-current@freebsd.org mailing list >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > > To unsubscribe, send any mail to " >> > freebsd-current-unsubscr...@freebsd.org" >> > > >> > >> > One question I didn't see in the (excellent!) docs is whether we should >> > be PGP-signing commits or not. Is that encouraged? >> > >> >> We've not started doing that in general. I don't think signing would cause >> issues, but since it is a bit of an unknown, we've not taken a position on >> this. >> >> Warner (on behalf of the git working group) >> > > I hope we don't have to start signing all commits. saltstack/salt has > that policy, and it's extremely annoying. > Have to? Not currently. As with all process changes, there will be community discussion around the different points. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Thu, Dec 17, 2020 at 12:06 PM Warner Losh wrote: > On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn > wrote: > > > > > > > On 12/16/20 7:46 PM, Warner Losh wrote: > > > Greetings, > > > > > > The FreeBSD project will be moving it's source repo from subversion to > > git > > > starting this this weekend. The docs repo was moved 2 weeks ago. The > > ports > > > repo will move at the end of March, 2021 due to timing issues. > > > > > > The short version is that we're switching the version control we're > > using. > > > This switch will preserve much of the current FreeBSD development > > workflow. > > > After the switch, the subversion repo will become almost read-only. All > > > future work will be done in git, however as a transition aide we'll be > > > replaying the MFCs to stable/11, stable/12 and the related releng > > branches > > > for the life of those branches. > > > > > > For more detailed information, please see > > > https://github.com/bsdimp/freebsd-git-docs/ for the current > > documentation. > > > > > > Please see https://wiki.freebsd.org/git for the latest detailed > schedule > > > (please note that this schedule is subject to change). > > > > > > Warner > > > ___ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > > freebsd-current-unsubscr...@freebsd.org" > > > > > > > One question I didn't see in the (excellent!) docs is whether we should > > be PGP-signing commits or not. Is that encouraged? > > > > We've not started doing that in general. I don't think signing would cause > issues, but since it is a bit of an unknown, we've not taken a position on > this. > > Warner (on behalf of the git working group) > I hope we don't have to start signing all commits. saltstack/salt has that policy, and it's extremely annoying. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn wrote: > > > On 12/16/20 7:46 PM, Warner Losh wrote: > > Greetings, > > > > The FreeBSD project will be moving it's source repo from subversion to > git > > starting this this weekend. The docs repo was moved 2 weeks ago. The > ports > > repo will move at the end of March, 2021 due to timing issues. > > > > The short version is that we're switching the version control we're > using. > > This switch will preserve much of the current FreeBSD development > workflow. > > After the switch, the subversion repo will become almost read-only. All > > future work will be done in git, however as a transition aide we'll be > > replaying the MFCs to stable/11, stable/12 and the related releng > branches > > for the life of those branches. > > > > For more detailed information, please see > > https://github.com/bsdimp/freebsd-git-docs/ for the current > documentation. > > > > Please see https://wiki.freebsd.org/git for the latest detailed schedule > > (please note that this schedule is subject to change). > > > > Warner > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > > One question I didn't see in the (excellent!) docs is whether we should > be PGP-signing commits or not. Is that encouraged? > We've not started doing that in general. I don't think signing would cause issues, but since it is a bit of an unknown, we've not taken a position on this. Warner (on behalf of the git working group) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 12/16/20 7:46 PM, Warner Losh wrote: Greetings, The FreeBSD project will be moving it's source repo from subversion to git starting this this weekend. The docs repo was moved 2 weeks ago. The ports repo will move at the end of March, 2021 due to timing issues. The short version is that we're switching the version control we're using. This switch will preserve much of the current FreeBSD development workflow. After the switch, the subversion repo will become almost read-only. All future work will be done in git, however as a transition aide we'll be replaying the MFCs to stable/11, stable/12 and the related releng branches for the life of those branches. For more detailed information, please see https://github.com/bsdimp/freebsd-git-docs/ for the current documentation. Please see https://wiki.freebsd.org/git for the latest detailed schedule (please note that this schedule is subject to change). Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" One question I didn't see in the (excellent!) docs is whether we should be PGP-signing commits or not. Is that encouraged? -Nathan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Thu, Dec 17, 2020 at 11:33 AM Andreas Ott wrote: > Hi, > > On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > > This switch will preserve much of the current FreeBSD development > workflow. > > After the switch, the subversion repo will become almost read-only. > > Will there be an update to the build from source instructions in > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > ? > Yes, eventually. There's also a transition to asciidoc going on in doc land, and I didn't want to make it harder by churning things for them while that was in progress. > I am also interested in a (one-time) migration procedure from svn or > svnlite to git, primarily for my servers that are tracking -CURRENT. > I've put together some docs on this. https://github.com/bsdimp/freebsd-git-docs/ has them all. https://github.com/bsdimp/freebsd-git-docs/blob/main/src-cvt.md has the specifics, but I'm still polishing it. It has the basics, but the examples still need work. The tl;dr version, though, is that you'll have to pull a fresh tree from the git repo once we make the cutover and then use git to update that tree. Other than that, the rest of the instructions are the same. If you have local changes, then https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md also has some details beyond the basics. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
Hi, On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > This switch will preserve much of the current FreeBSD development workflow. > After the switch, the subversion repo will become almost read-only. Will there be an update to the build from source instructions in https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html ? I am also interested in a (one-time) migration procedure from svn or svnlite to git, primarily for my servers that are tracking -CURRENT. Thanks, andreas -- Andreas Ott K6OTT +1.408.431.8727 andr...@naund.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AMNESIA:33 and FreeBSD TCP/IP stack involvement
> Hartmann, O. wrote this message on Wed, Dec 09, 2020 at 06:58 +0100: > > I've got a question about recently discovered serious > > vulnerabilities in certain TCP stack implementations, designated as > > AMNESIA:33 (as far as I could follow the recently made > > announcements and statements, please see, for instance, > > https://www.zdnet.com/article/amnesia33-vulnerabilities-impact-millions-of-smart-and-industrial-devices/). > > > > All mentioned open-source TCP stacks seem not to be related in any > > way with freeBSD or any derivative of the FreeBSD project, but I do > > not dare to make a statement about that. > > > > My question is very simple and aimes towards calming down my > > employees requests: is FreeBSD potentially vulnerable to this newly > > discovered flaw (we use mainly 12.1-RELENG, 12.2-RELENG, 12-STABLE > > and 13-CURRENT, latest incarnations, of course, should be least > > vulnerable ...). > > I'd be surprised if FreeBSD is vulnerable to those flaws, but I cannot > make any official statement as there are too many to even start to > investigate them. > > Also of note is that there were three other IP stacks that were NOT > vulnerable to ANY new security issues in that report as well, so it > isn't like the report found security vulnerability in every TCP/IP > stack they tested. > > The best way to have confidence is to pay people to analyize and > verify that the FreeBSD TCP/IP stack is secure, just as it is w/ > any critical code that a company runs. > Thank you very much for responding. I'll take all comments into consideration; I think one thing is clear, that even if I'd had to report that freeBSD is vulnerable, I'd have to wait for a pacth. Since my personal patch policy on RELENG for FreeBSD is to patch/update as fast as possible after a SA has been published, I'd have to wait for the patches. CURRENT and STABLE systems are updated frequently - on a weekly basis, if necessary. Kind regards, O. Hartmann pgpRI55aIgaDW.pgp Description: OpenPGP digital signature
Re: installation on pvscsi fails with "The request was too large for this host"
Andriy Gapon wrote: On 17/12/2020 07:02, Yuri Pankov wrote: Trying to install latest snapshot (20201210) on a VMware ESXi/Workstation VMs with pvscsi fails on bootloader step, and the following is in dmesg: pvscsi0: pvscsi_execute_ccb error 27 pvscsi0: pvscsi_execute_ccb error 27 (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00 (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host (da0:pvscsi0:0:0:0): Error 22, Unretryable error (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00 (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host (da0:pvscsi0:0:0:0): Error 22, Unretryable error That is the first I'm trying installing on pvscsi since it was integrated, so no idea if it worked previously. If yes, I have not tried to bisect this yet hoping that it could be identified as related to any of the recent changes. The VMs in question are set with 8-64 GB RAM, and 100 GB boot disks. Not an expert in this areas, but that command tried to transfer 0x400 / 1024 blocks, which is 512KB of data. Could it be that the problem is revealed by the MAXPHYS increase? There might be a bug in pvscsi where it does not respect or correctly advertise some limit. There could be a similar issue with VMware itself (its emulation of a disk / target). Yes, it looks like reverting MAXPHYS back to 128K made the problem disappear, successfully installed VM from resulting cdrom image. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpi_wmi noisy without EC
On 17.12.2020 11:24, Yuri Pankov wrote:
> Yuri Pankov wrote:
>> On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote:
>>> 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: on acpi0
>>> acpi_wmi0: cannot find EC device
>>> device_attach: acpi_wmi0 attach returned 6
>>> acpi_wmi0: on acpi0
>>> acpi_wmi0: cannot find EC device
>>> device_attach: acpi_wmi0 attach returned 6
>>> acpi_wmi0: on acpi0
>>> acpi_wmi0: cannot find EC device
>>> device_attach: acpi_wmi0 attach returned 6
>>> acpi_wmi0: on acpi0
>>> acpi_wmi0: cannot find EC device
>>> device_attach: acpi_wmi0 attach returned 6
>>>
>>> Likely following this commit:
>>>
>>> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
>>> Author: Vladimir Kondratyev
>>> Date: Sat Oct 31 22:19:39 2020 +
>>>
>>> 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: 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: on acpi0
acpi_wmi1: cannot find EC device
acpi_wmi2: on acpi0
acpi_wmi2: cannot find EC device
acpi_wmi3: 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.
>>
>> Oh great, I misunderstood then. And indeed, sysctl -b
>> dev.acpi_wmi.0.bmof | bmf2mof provides some interesting information.
>> All other 3 instances do not though. In any case, it seems to work now.
>>
>>> Verbosity can be reduced with attached patch if current level is too
>>> high for you.
>>
>> Works for me both ways, I simply had the wrong impression that if we
>> don't have EC, we can't attach at all.
>
> Could you commit this, or is it incomplete fix?
I did some tests with ACER ACPI extras which left functional after
OPregion handler had been disabled, so I think, fix is complete.
I have created a phabricator review: https://reviews.freebsd.org/D27653
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: installation on pvscsi fails with "The request was too large for this host"
On 17/12/2020 07:02, Yuri Pankov wrote: > Trying to install latest snapshot (20201210) on a VMware ESXi/Workstation VMs > with pvscsi fails on bootloader step, and the following is in dmesg: > > pvscsi0: pvscsi_execute_ccb error 27 > pvscsi0: pvscsi_execute_ccb error 27 > (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00 > (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host > (da0:pvscsi0:0:0:0): Error 22, Unretryable error > (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00 > (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host > (da0:pvscsi0:0:0:0): Error 22, Unretryable error > > That is the first I'm trying installing on pvscsi since it was integrated, so > no > idea if it worked previously. If yes, I have not tried to bisect this yet > hoping that it could be identified as related to any of the recent changes. > > The VMs in question are set with 8-64 GB RAM, and 100 GB boot disks. Not an expert in this areas, but that command tried to transfer 0x400 / 1024 blocks, which is 512KB of data. Could it be that the problem is revealed by the MAXPHYS increase? There might be a bug in pvscsi where it does not respect or correctly advertise some limit. There could be a similar issue with VMware itself (its emulation of a disk / target). -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpi_wmi noisy without EC
Yuri Pankov wrote:
On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote:
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: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
Likely following this commit:
commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
Author: Vladimir Kondratyev
Date: Sat Oct 31 22:19:39 2020 +
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: 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: on acpi0
acpi_wmi1: cannot find EC device
acpi_wmi2: on acpi0
acpi_wmi2: cannot find EC device
acpi_wmi3: 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.
Oh great, I misunderstood then. And indeed, sysctl -b dev.acpi_wmi.0.bmof |
bmf2mof provides some interesting information. All other 3 instances do not
though. In any case, it seems to work now.
Verbosity can be reduced with attached patch if current level is too
high for you.
Works for me both ways, I simply had the wrong impression that if we don't have
EC, we can't attach at all.
Could you commit this, or is it incomplete fix?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
