Re: svn commit: r298950 - head/sys/dev/pci

[Harry Schmalzbauer]

 Bezüglich John Baldwin's Nachricht vom 03.05.2016 02:35 (localtime):
> Author: jhb
> Date: Tue May  3 00:35:11 2016
> New Revision: 298950
> URL: https://svnweb.freebsd.org/changeset/base/298950
>
> Log:
>   Fix an off by one error when remapping MSI-X vectors.
>   
>   pci_remap_msix() can be used to alter the mapping of allocated
>   MSI-X vectors to the MSI-X table.  The code had an off by one error
>   when adding the IRQ resources after performing a remap.  This was
>   fatal for any vectors in the table that used the "last" valid IRQ as
>   those vectors were assigned a garbage IRQ value.
>   
>   MFC after:  3 days

Was this superseded by any other merge?
As far as I saw, it's missing in stable/10?

Thanks,

-Harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304426 - stable/11/sys/net

[Harry Schmalzbauer]

Bezüglich Alexander Motin's Nachricht vom 24.08.2016 11:02 (localtime):
> On 24.08.16 11:42, Harry Schmalzbauer wrote:
>>  Bezüglich Alexander Motin's Nachricht vom 18.08.2016 14:08 (localtime):
>>> Author: mav
>>> Date: Thu Aug 18 12:08:39 2016
>>> New Revision: 304426
>>> URL: https://svnweb.freebsd.org/changeset/base/304426
>>>
>>> Log:
>>>   MFC r303009: Negotiate/disable TXCSUM_IPV6 same as TXCSUM.
>>
>> Have you asked for RE-approval to get this into 11.0?
>> If I understand it correctly it's a essential fix for jail+epair+IPv6
>> useres, solving nasty hard to track oddities?
> 
> No, I haven't asked, because I haven't seen related bug reports and
> found this accidentally.  But if anybody wants it -- be my guest.

I haven't filed a PR because I ran out of time tracking my bridge(4)
oddities, since so many exotics are involved:
VT-d PCIe-passthrough of two igb(4) = lagg(4) - bridge(4) - epair(4).
At some point I clearly found bridge(4) misbehaving, and I did some(tm)
workarround and went on. This was with stable/10 between 10.0 and 10.1
(currently running 10.1 on that setup).
Can't tell if igb(4) in 10.1 is even TXCSUM_IPV6 capable (this was added
quiet lately in igb(4)'s live, afair), but the symptoms match very well
this missing TXCSUM_IPV6 disabling.

Even if not in my case, as far as I understand, everybody else using
11.0-RC2 with TXCSUM_IPV6-enabledNic(4)+bridge(4) would suffer from
network failures.

You found + fixed it, so 11.0 should get this :-)

Thanks,

-harry


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304426 - stable/11/sys/net

[Harry Schmalzbauer]

 Bezüglich Alexander Motin's Nachricht vom 18.08.2016 14:08 (localtime):
> Author: mav
> Date: Thu Aug 18 12:08:39 2016
> New Revision: 304426
> URL: https://svnweb.freebsd.org/changeset/base/304426
>
> Log:
>   MFC r303009: Negotiate/disable TXCSUM_IPV6 same as TXCSUM.

Have you asked for RE-approval to get this into 11.0?
If I understand it correctly it's a essential fix for jail+epair+IPv6
useres, solving nasty hard to track oddities?

Thanks,

-Harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306103 - releng/11.0/release/doc/en_US.ISO8859-1/relnotes

[Harry Schmalzbauer]

 Bezüglich Glen Barber's Nachricht vom 21.09.2016 16:19 (localtime):
> Author: gjb
> Date: Wed Sep 21 14:19:01 2016
> New Revision: 306103
> URL: https://svnweb.freebsd.org/changeset/base/306103
>
> Log:
>   Document r291292, if_enc(4) addition.
>   
>   Submitted by:   ae
>   Approved by:re (implicit)
>   Sponsored by:   The FreeBSD Foundation
>
> Modified:
>   releng/11.0/release/doc/en_US.ISO8859-1/relnotes/article.xml
>
> Modified: releng/11.0/release/doc/en_US.ISO8859-1/relnotes/article.xml
> ==
> --- releng/11.0/release/doc/en_US.ISO8859-1/relnotes/article.xml  Wed Sep 
> 21 14:15:15 2016(r306102)
> +++ releng/11.0/release/doc/en_US.ISO8859-1/relnotes/article.xml  Wed Sep 
> 21 14:19:01 2016(r306103)
> @@ -1433,6 +1433,12 @@
>   arch="arm64">Initial SMP support has been
>   added to the / port.
>  
> +  The
> +  driver has been added, providing an interface
> + through which IPSEC can be used via
> +  without requiring additional kernel and/or
> + userland changes.

Please correct me if I'm wrong, but if_enc(4) has been present at least
since 9.x.
In my opinion (non-native english speaker), the paragraph is misleading.
if_enc(4) cannot be »used« for IPSec, but proviedes access to
decapsulated ESP traffic processd in kernel space.
I would understand this paragraph as if I could construct any kind of
VPN(IPSec)-tunnel with if_enc(4).
Mybe it's just me, please jump in experts!

Thanks,

-Harry


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r308217 - in head/sys/dev: mpr mps

[Harry Schmalzbauer]

Bezüglich Scott Long's Nachricht vom 09.11.2016 17:06 (localtime):
> 
>> On Nov 4, 2016, at 3:18 AM, Harry Schmalzbauer <free...@omnilan.de> wrote:
…
>> If it's really mps(4) who decides to store driveserial-targetID
>> numbering in the /"persitent non-manufacturing config pages/" of the
>> controller, mpsutil(8) should be able to reset. Otherwise replacing
>> failed drives, or - even mor confusing - rearranging drive/zpool layouts
>> is very unsatisfying.
>>
>> Maybe "-1" should be mentioned with sysctl decription, otherwise this is
>> another very hard to find/influence behaviour.
>>
>>
> 
> Thanks for the feedback.  For the record, this problem happens on a
> Supermicro X10SDV-7TP4F motherboard.  It appears that the support
> logic around the LSI controller is mis-configured to show the SAS ports
> being part of an enclosure with 0 slots, instead of 8.  This confuses
> the device mapper logic in the driver that activates if the controller NVRAM
> doesn’t specify a pre-existing mapping.  Typically this is not the default,
> the NVRAM persistent mappings are the default and are used by the driver,
> so I considered this problem to be unique to our deployment.  Maybe it’s
> more of a problem than I estimated?  Anyways, sounds like this new

I haven't had too much diversity regarding Fusion-MPT and this mapping
problem has never hit me yet, so I can't help estimating the severity of
that specific problem.

But I think I haven't described clearly that I'm having da(4)-numbering
problems which are not directly enclosure-mapping related (at least not
related to the nvram mapping page), but which hopefully could be worked
arround the same way:

I frequently had problems replacing drives due to the eternal targetID
assigning (every drive with a new/unknown serial gets a consecutive
targetID regardless of the enclosure-slot or the number of attached drives).
I guess this is stored in a completely different NVRAM page than the
enclosure-mapping page.
Your patch is intended to solve problems with invalid/absent
enclosure-mapping page, but I guess I'll sooner or later need to try the
"hw.mpr.use_phy_num=-1" sysctl
to hopefully overwrite the targetID++ assigning, which causes "wholes"
every time a drive gets replaced.
In that case it's just a cosmetic problem, but when rearranging old and
new drives on the same controller, it can cause severe confusion for the
admins – leading to fatal mistakes. And migrating disks to new
controller/chassis is even more problematic if the host had hard wired
da(4) assignins via device.hints.

I couldn't search the driver to find out if the "save eternal targetID
in nvram page N" is really present and not firmware-only induced, but
since I saw a different behaviour on windows, I guess it is.
I could circumvent the problem by simply using IR firmware since it is
only active when mps(4) runs IT firmware.

But having a way to disable "save eternal targetID in nvram page N" for
mps(4)-IT (via sysctl, and possibly for mpr/mpt also) would be very welcome.

Top on my wishlist was extending mpsutil(8) to be able to list and
selectively delete single serial-targetID mappings, but I haven't even
found a way to do that with any vendor provided tool, not even with
LSIUtil – where I can at least erase _all_ mappings.


> functionality should be properly documented in the driver.

Thanks for your continuous supprt/help/improvements!

-Harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303848 - head/sys/netgraph

[Harry Schmalzbauer]

 Bezüglich Sean Bruno's Nachricht vom 08.08.2016 21:31 (localtime):
> Author: sbruno
> Date: Mon Aug  8 19:31:01 2016
> New Revision: 303848
> URL: https://svnweb.freebsd.org/changeset/base/303848
>
> Log:
>   Avoid panic from ng_uncallout when unpluggin ethernet cable with active
>   PPTP VPN connection.
>   
>   Submitted by:   Michael Zhilin 
>   Reviewed by:ngie
>   MFC after:  3 days
>   Differential Revision:  https://reviews.freebsd.org/D7209

Could you catch up this MFC?

Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304443 - head/sys/cam

[Harry Schmalzbauer]

 Bezüglich Warner Losh's Nachricht vom 19.08.2016 06:30 (localtime):
> Author: imp
> Date: Fri Aug 19 04:30:29 2016
> New Revision: 304443
> URL: https://svnweb.freebsd.org/changeset/base/304443
>
> Log:
>   Improve the pattern matching so that internal *'s work, as well as
>   [set] notation. This fixes pattern matching for recently added drives
>   that would set the NCQ Trim being broken incorrectly.
>   
>   PR: 210686
>   Tested-by: Tomoaki AOKI
>   MFC After: 3 days

Hasn't made it into 11.0, but also not in stable/11 yet?

Thanks,

-Harry


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304437 - head/sys/netinet

[Harry Schmalzbauer]

 Bezüglich Ryan Stone's Nachricht vom 19.08.2016 00:59 (localtime):
> Author: rstone
> Date: Thu Aug 18 22:59:10 2016
> New Revision: 304437
> URL: https://svnweb.freebsd.org/changeset/base/304437
>
> Log:
>   Fix unlocked access to ifnet address list
>   
>   in_broadcast() was iterating over the ifnet address list without
>   first taking an IF_ADDR_RLOCK.  This could cause a panic if a
>   concurrent operation modified the list.
>   
>   Reviewed by: bz
>   MFC after: 2 months
>   Sponsored by: EMC / Isilon Storage Division
>   Differential Revision: https://reviews.freebsd.org/D7227

Is this intentionally unMFCd?

Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r297568 - head/sys/dev/fdc

[Harry Schmalzbauer]

 Bezüglich John Baldwin's Nachricht vom 05.04.2016 02:08 (localtime):
> Author: jhb
> Date: Tue Apr  5 00:08:42 2016
> New Revision: 297568
> URL: https://svnweb.freebsd.org/changeset/base/297568
>
> Log:
>   Don't wakeup the fdc worker thread once a second when idle.
>   
>   The fdc worker thread was using a one second timeout while waiting for
>   a new bio to arrive or for the device to detach.  However, the driver
>   already does a wakeup when queueing a new bio or asking the thread to
>   detach, so the timeout only served to waste CPU time waking up the
>   thread once a second just so it could go right back to sleep.  Use an
>   infinite timeout instead.
>   
>   Discussed with: phk
>   Sponsored by:   Netflix

Imho that was nice to have in 10.4. Any reason not to MFS?

Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r308217 - in head/sys/dev: mpr mps

[Harry Schmalzbauer]

 Bezüglich Scott Long's Nachricht vom 02.11.2016 16:13 (localtime):
> Author: scottl
> Date: Wed Nov  2 15:13:25 2016
> New Revision: 308217
> URL: https://svnweb.freebsd.org/changeset/base/308217
>
> Log:
>   Add a fallback to the device mapper logic.  We've seen systems in the field
>   that are apparently misconfigured by the manufacturer and cause the mapping
>   logic to fail.  The fallback allows drive numbers to be assigned based on 
> the
>   PHY number that they're attached to.  Add sysctls and tunables to overrid
>   this new behavior, but they should be considered only necessary for 
> debugging.

Thanks a lot, this is welcome not only for debugging!

I had a hard time finding out how to get rid of static
driveserial-targetID assigning.
And more surprising, this affects only IT-fw. When using the same
controller in IR-mode, mapping is done (correctly) slot-based.
In IT-mode, every drive got a consecutive target ID which was static,
and even persistent over firmware updates. There's only one possibility
with LSIUtil(1.71) to erase /"persitent non-manufacturing config pages/".
But I guess this hard drive-targetID assigning is triggered by the
driver, namely the mps(4) in FreeBSD.
I did quick tests on windows and IT-mode, where I think I saw slot (or
Phy?) based assigning.

If it's really mps(4) who decides to store driveserial-targetID
numbering in the /"persitent non-manufacturing config pages/" of the
controller, mpsutil(8) should be able to reset. Otherwise replacing
failed drives, or - even mor confusing - rearranging drive/zpool layouts
is very unsatisfying.

Maybe "-1" should be mentioned with sysctl decription, otherwise this is
another very hard to find/influence behaviour.

Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: MFC reminder emails (was Re: svn commit: r308296 - head/sys/cam/scsi)

[Harry Schmalzbauer]

 Bezüglich Oliver Pinter's Nachricht vom 12.12.2016 00:57 (localtime):
> Hi Pedro!
>
> On 12/11/16, Pedro Giffuni  wrote:
>> Hello;
>> On 12/10/16 19:58, Oliver Pinter wrote:
>> ...
>>
   Reviewed by: ken
   Obtained from:   Netflix
   MFC after:   3 days
>>> Hi Scott!
>>>
>>> What's the status of the MFCs to 10-STABLE and 11-STABLE?
>>>
>> Not meaning to pester anyone but given that you (and others) tend
>> to remind about MFCs you would like to see done ...
>>
>> 1) Committers get an email reminder in due time when they add an
>> MFC tag to the commit log.
>>
>> 2) MFCs are advisory: committer may change mind about them or
>> otherwise not do them due to any reason.
>>
>> 3) It's still not official, but we have an additional service
>> that lets committers verify the state of MFC requests if they wish.
>>
>> Given the points above, which you may not have been aware of,
>> it may be seen as rude to post additional reminders.

Thanks for explaining, and apologies, since I've been one of those
others too.

But sometimes I got back »Thanks for the reminder, forgt/lost a/b/c...«

So I hope those adressees for whom point 2) was the case will just
ignore it and don't feel disordered.
Since people asking about a MFC status are aware of the committ, the
reminder is meant to support committers and the release quality,
otherwise we could silently adopt ourselfs...

I'm completely unsure if these reminders are welcome or not. Of course,
it's committer-dependent to some degree, but what's the "official"
position: Being quiet or asking if chances are good that it got lost?

Shall we strip svn-src-all@ ?

Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r320802 - head/etc/rc.d

[Harry Schmalzbauer]

 Bezüglich Harry Schmalzbauer's Nachricht vom 29.07.2017 17:20 (localtime):
>  Bezüglich Kristof Provost's Nachricht vom 08.07.2017 11:28 (localtime):
>> Author: kp
>> Date: Sat Jul  8 09:28:31 2017
>> New Revision: 320802
>> URL: https://svnweb.freebsd.org/changeset/base/320802
>>
>> Log:
>>   Allow more services to run in vnet jails
>>   
>>   After some tests, here are the services that run into a vnet jail:
>> - defaultroute
>> - dhclient
>> - ip6addrctl
>> - natd
>> - pf
>> - pfsync
>> - pflog (deamon runs, pflog0 interface usable, but /var/log/pflog not 
>> filled)
>> - rarpd
>> - route6d (do nothing anyway because obsolete)
>> - routed (do nothing anyway because obsolete)
>> - rtsold
>> - static_arp
>> - static_ndp
>>   
>>   PR:220530
>>   Submitted by:  oliv...@freebsd.org
> Do you (or somebidy else) plan to MFC this, along with r320696?
Forgot to mention r320618 also.

> Valuable "extension" IMHO.
>
> Thanks,
>
> -harry
>


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r320802 - head/etc/rc.d

[Harry Schmalzbauer]

 Bezüglich Kristof Provost's Nachricht vom 08.07.2017 11:28 (localtime):
> Author: kp
> Date: Sat Jul  8 09:28:31 2017
> New Revision: 320802
> URL: https://svnweb.freebsd.org/changeset/base/320802
>
> Log:
>   Allow more services to run in vnet jails
>   
>   After some tests, here are the services that run into a vnet jail:
> - defaultroute
> - dhclient
> - ip6addrctl
> - natd
> - pf
> - pfsync
> - pflog (deamon runs, pflog0 interface usable, but /var/log/pflog not 
> filled)
> - rarpd
> - route6d (do nothing anyway because obsolete)
> - routed (do nothing anyway because obsolete)
> - rtsold
> - static_arp
> - static_ndp
>   
>   PR: 220530
>   Submitted by:   oliv...@freebsd.org

Do you (or somebidy else) plan to MFC this, along with r320696?
Valuable "extension" IMHO.

Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r320802 - head/etc/rc.d

[Harry Schmalzbauer]

Bezüglich Kristof Provost's Nachricht vom 29.07.2017 17:22 (localtime):
> On 29 Jul 2017, at 17:20, Harry Schmalzbauer wrote:
>>  Bezüglich Kristof Provost's Nachricht vom 08.07.2017 11:28 (localtime):
>>> Author: kp
>>> Date: Sat Jul  8 09:28:31 2017
>>> New Revision: 320802
>>> URL: https://svnweb.freebsd.org/changeset/base/320802
>>>
>>> Log:
>>>   Allow more services to run in vnet jails
>>>
>> Do you (or somebidy else) plan to MFC this, along with r320696?
>> Valuable "extension" IMHO.
>>
> I have no plans to, no.
> 
> I’m not terribly confident that vnet is sufficiently robust in stable/11 to
> encourage people to use it.  There are a number of vnet bugs that are
> fixed (or
> being worked on) in CURRENT that still affect stable/11.

I see, thanks a lot for your quick response.

Haven't used vnet (in production) before stable/11, but palnning to do
so, so I'm prepared to find some of them in the near future. I'm merging
locally and can at least provide testing.

Thanks,

-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r320659 - head/usr.sbin/nfsuserd

[Harry Schmalzbauer]

 Bezüglich Rick Macklem's Nachricht vom 05.07.2017 13:58 (localtime):
> Well, I know nothing about jails, so I can't answer either of these.
> All I can tell you is that 127.0.0.1 no longer works as localhost when
> jails are run for some situations which I don't understand and that
> breaks the nfsuserd upcall. (Something about 127.0.0.1 being replaced
> by the first IP# for the net interface when jails are running?)

This was changed with https://svnweb.freebsd.org/changeset/base/316313
(and https://svnweb.freebsd.org/changeset/base/316328 for IPv6) if I
don't confuse things here.
Haven't had time to read/test NFS+jail, but it was on my "things to
solve" list and the mentioned two commits made me thinking there's
already a solution.

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304443 - head/sys/cam

[Harry Schmalzbauer]

 Bezüglich Harry Schmalzbauer's Nachricht vom 01.11.2016 16:00 (localtime):
>  Bezüglich Warner Losh's Nachricht vom 19.08.2016 06:30 (localtime):
>> Author: imp
>> Date: Fri Aug 19 04:30:29 2016
>> New Revision: 304443
>> URL: https://svnweb.freebsd.org/changeset/base/304443
>>
>> Log:
>>   Improve the pattern matching so that internal *'s work, as well as
>>   [set] notation. This fixes pattern matching for recently added drives
>>   that would set the NCQ Trim being broken incorrectly.
>>   
>>   PR: 210686
>>   Tested-by: Tomoaki AOKI
>>   MFC After: 3 days
> Hasn't made it into 11.0, but also not in stable/11 yet?

Just found a reminder at stable@:
https://lists.freebsd.org/pipermail/freebsd-stable/2017-June/087240.html
Is there any strong reason not to MFC?

Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r319881 - head/sys/dev/netmap

[Harry Schmalzbauer]

 Bezüglich Harry Schmalzbauer's Nachricht vom 15.06.2017 15:14 (localtime):
>  Bezüglich Luiz Otavio O Souza's Nachricht vom 13.06.2017 00:53
> (localtime):
>> Author: loos
>> Date: Mon Jun 12 22:53:18 2017
>> New Revision: 319881
>> URL: https://svnweb.freebsd.org/changeset/base/319881
>>
>> Log:
>>   Update the current version of netmap to bring it in sync with the github
>>   version.
>>   
>>   This commit contains mostly refactoring, a few fixes and minor added
>>   functionality.
>>   
>>   Submitted by:  Vincenzo Maffione 
>>   Requested by:  many
>>   Sponsored by:  Rubicon Communications, LLC (Netgate)
>>
>> Modified:
>>   head/sys/dev/netmap/if_ixl_netmap.h
>>   head/sys/dev/netmap/netmap.c
>>   head/sys/dev/netmap/netmap_freebsd.c
> Here's a interfering change which
> reverts r313982 for sys/dev/netmap/netmap_freebsd.c:
>
> @@ -2143,7 +2146,7 @@
> if (ptnmd->ptn_dev) {
> nm_os_pt_memdev_iounmap(ptnmd->ptn_dev);
> }
> - ptnmd->nm_addr = NULL;
> + ptnmd->nm_addr = 0;
> ptnmd->nm_paddr = 0;
> }
> }
>
> …
>>   head/sys/dev/netmap/netmap_mem2.c
> Also in sys/dev/netmap/netmap_mem2.c
> r313982 was reverted:
>
> @@ -648,7 +671,7 @@
> , 0, ~0, *mem_size, RF_ACTIVE);
> if (ptn_dev->pci_mem == NULL) {
> *nm_paddr = 0;
> - *nm_addr = NULL;
> + *nm_addr = 0;
> return ENOMEM;
> }
>

Urghs, pasted the hunks wrong!

The latter is in sys/dev/netmap/netmap_freebsd.c
and the former belongs to  sys/dev/netmap/netmap_mem2.c.
Sorry for the consfusion!

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r319881 - head/sys/dev/netmap

[Harry Schmalzbauer]

 Bezüglich Luiz Otavio O Souza's Nachricht vom 13.06.2017 00:53
(localtime):
> Author: loos
> Date: Mon Jun 12 22:53:18 2017
> New Revision: 319881
> URL: https://svnweb.freebsd.org/changeset/base/319881
>
> Log:
>   Update the current version of netmap to bring it in sync with the github
>   version.
>   
>   This commit contains mostly refactoring, a few fixes and minor added
>   functionality.
>   
>   Submitted by:   Vincenzo Maffione 
>   Requested by:   many
>   Sponsored by:   Rubicon Communications, LLC (Netgate)
>
> Modified:
>   head/sys/dev/netmap/if_ixl_netmap.h
>   head/sys/dev/netmap/netmap.c
>   head/sys/dev/netmap/netmap_freebsd.c

Here's a interfering change which
reverts r313982 for sys/dev/netmap/netmap_freebsd.c:

@@ -2143,7 +2146,7 @@
if (ptnmd->ptn_dev) {
nm_os_pt_memdev_iounmap(ptnmd->ptn_dev);
}
- ptnmd->nm_addr = NULL;
+ ptnmd->nm_addr = 0;
ptnmd->nm_paddr = 0;
}
}

…
>   head/sys/dev/netmap/netmap_mem2.c

Also in sys/dev/netmap/netmap_mem2.c
r313982 was reverted:

@@ -648,7 +671,7 @@
, 0, ~0, *mem_size, RF_ACTIVE);
if (ptn_dev->pci_mem == NULL) {
*nm_paddr = 0;
- *nm_addr = NULL;
+ *nm_addr = 0;
return ENOMEM;
}

Don't know about the impact of
https://svnweb.freebsd.org/base?view=revision=313982 and
whether this partial 0/NULL replacement makes sence in
sys/dev/netmap/netmap_mem2.c and sys/dev/netmap/netmap_freebsd.c.
Just wanted to report and ask for review.

Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r325928 - in stable/11/share: colldef ctypedef monetdef msgdef numericdef

[Harry Schmalzbauer]

 Bezüglich Baptiste Daroussin's Nachricht vom 17.11.2017 10:14 (localtime):
> Author: bapt
> Date: Fri Nov 17 09:14:18 2017
> New Revision: 325928
> URL: https://svnweb.freebsd.org/changeset/base/325928
>
> Log:
>   MFC r325361:
>   
>   Update to CLDR 32 and Unicode 10
>   
>   Relnotes:   ye

Hello,

unfortunately installworld fails after this commit:
===> share/ctypedef (install)  
install  -o root  -g wheel -m 444  be_BY.CP1131.LC_CTYPE 
/usr/local/share/deploy-tools/UNSPEC-amd64/preed/masterroot/usr/share/locale/be_BY.CP1131/LC_CTYPE


install  -o root  -g wheel -m 444  ca_IT.ISO8859-1.LC_CTYPE 
/usr/local/share/deploy-tools/UNSPEC-amd64/preed/masterroot/usr/share/locale/ca_IT.ISO8859-1/LC_CTYP
E  
install  -o root  -g wheel -m 444  ca_IT.ISO8859-15.LC_CTYPE 
/usr/local/share/deploy-tools/UNSPEC-amd64/preed/masterroot/usr/share/locale/ca_IT.ISO8859-15/LC_CT
YPE
install  -o root  -g wheel -m 444  el_GR.ISO8859-7.LC_CTYPE 
/usr/local/share/deploy-tools/UNSPEC-amd64/preed/masterroot/usr/share/locale/el_GR.ISO8859-7/LC_CTYP
E  
install  -o root  -g wheel -m 444  en_US.ISO8859-1.LC_CTYPE 
/usr/local/share/deploy-tools/UNSPEC-amd64/preed/masterroot/usr/share/locale/en_US.ISO8859-1/LC_CTYP
E  
install  -o root  -g wheel -m 444  en_US.ISO8859-15.LC_CTYPE 
/usr/local/share/deploy-tools/UNSPEC-amd64/preed/masterroot/usr/share/locale/en_US.ISO8859-15/LC_CT
YPE
install  -o root  -g wheel -m 444  en_US.US-ASCII.LC_CTYPE 
/usr/local/share/deploy-tools/UNSPEC-amd64/preed/masterroot/usr/share/locale/en_US.US-ASCII/LC_CTYPE

localedef -D -U -c -w
/usr/local/share/deploy-tools/RELENG_11/src/share/ctypedef/../../tools/tools/locale/etc/final-maps/widths.txt
 
-f /usr/local/share/deploy-t
ools/RELENG_11/src/share/ctypedef/../../tools/tools/locale/etc/final-maps/map.UTF-8
 
-i /usr/local/share/deploy-tools/RELENG_11/src/share/ctypedef/en_US.UTF-8.sr
c
/usr/local/share/deploy-tools/obj-amd64/UNSPEC/usr/local/share/deploy-tools/RELENG_11/src/share/ctypedef/en_US.UTF-8
 
|| true 
/usr/local/share/deploy-tools/RELENG_11/src/share/ctypedef/en_US.UTF-8.src:
3184: error: syntax
error   
install  -o root  -g wheel -m 444  en_US.UTF-8.LC_CTYPE 
/usr/local/share/deploy-tools/UNSPEC-amd64/preed/masterroot/usr/share/locale/en_US.UTF-8/LC_CTYPE
  

install: en_US.UTF-8.LC_CTYPE: No such file or
directory   
*** Error code 71  
   
Stop.  

make[11]: stopped in
/usr/local/share/deploy-tools/RELENG_11/src/share/ctypedef  
   

*** Error code 1

Does jenkins only make buildworld target, not installworld?  Local
fallout?!? - never touched anything ctypedef related...

Thanks,

-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r325928 - in stable/11/share: colldef ctypedef monetdef msgdef numericdef

[Harry Schmalzbauer]

Bezüglich Baptiste Daroussin's Nachricht vom 17.11.2017 14:02 (localtime):
> On Fri, Nov 17, 2017 at 01:45:30PM +0100, Harry Schmalzbauer wrote:
>>  Bezüglich Baptiste Daroussin's Nachricht vom 17.11.2017 10:14 (localtime):
>>> Author: bapt
>>> Date: Fri Nov 17 09:14:18 2017
>>> New Revision: 325928
>>> URL: https://svnweb.freebsd.org/changeset/base/325928
>>>
>>> Log:
>>>   MFC r325361:
>>>   
>>>   Update to CLDR 32 and Unicode 10
>>>   
>>>   Relnotes: ye

…
> 
> I forgot to commit a merge, which I have just done as in r325933. Can you
> confirm it fixes your problem?

Fix confiremd!

Thanks,

-harry


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Harry Schmalzbauer]

 Bezüglich Alexey Dokuchaev's Nachricht vom 12.12.2017 07:18 (localtime):
> On Mon, Dec 11, 2017 at 10:14:04AM -0800, Nathan Whitehorn wrote:
>> I think this name might confuse people looking for "syscons". Can it be
>> renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?
> +1 for rename, it's very confusing now.

Not that mine would have much weight, but also +1 from here. Stumbled at
any commit log yet – mmdevcon corecon[f] chpcon[f] soccon[f] – just to
throw in seomthing…

-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r327362 - in head/usr.bin/find: . tests

[Harry Schmalzbauer]

Am 29.12.2017 um 23:08 schrieb Conrad Meyer:

Author: cem
Date: Fri Dec 29 22:08:43 2017
New Revision: 327362
URL: https://svnweb.freebsd.org/changeset/base/327362

Log:
   find(1): Fix -newer and -samefile to conform to POSIX[0]
   
   By default, or with the -P flag, find(1) should evaluate paths "physically."

   For symlinks, this means using the link itself instead of the target.
   
   Historically (since the import of BSD 4.4-lite from CSRG), find(1) has

   failed to refer to the link itself, at least for -newer and -samefile.
   
   [0]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html
   


It's a bit late, but is it possible to MFC this commit in time for 11.2?
This wasn't tagged for MFC by cem@ and I forgot to ask if somone else 
wants to take care.


Thanks,

-harry


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333174 - head/sys/amd64/vmm/io

[Harry Schmalzbauer]

Am 02.05.2018 um 20:20 schrieb Peter Grehan:

That places the MFC right before the optional 11.2 Beta3, I would rather
see this "low risk" change merged before May 11th, the code freeze
date and Beta1, if it is desired in 11.2, for maximal test exposure.


 Sure, that can be done.


Hope it's not too late to do so and somebody doing MFCs can take care of 
this one?


Thanks,

-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Post r337773 EFIRT-boot-panic still happening with r337838 [Was: Re: svn commit: r337838 - head/sys/amd64/amd64]

[Harry Schmalzbauer]

Am 15.08.2018 um 14:48 schrieb Konstantin Belousov:

Author: kib
Date: Wed Aug 15 12:48:49 2018
New Revision: 337838
URL: https://svnweb.freebsd.org/changeset/base/337838

Log:
   Fix early EFIRT on PCID machines after r337773.
   
   Ensure that the valid PCID state is created for proc0 pmap, since it

   might be used by efirt enter() before first context switch on the BSP.
   
   Sponsored by:	The FreeBSD Foundation

   MFC after:   6 days

Modified:
   head/sys/amd64/amd64/pmap.c


Hello,

I'm testing ALPHA4 on a Ivy bridge machine, without recent firmware 
update, so no PCID.

This fix doesn't cover that hardware.
Setting efi.rt.disabled=1 in loader.conf makes it bootable.

Without this tweak, the following panic happens:
Fatal trap 12: Page fault while in kernel mode
:
cpuid = 5; apic id = 05
:
fault code: supervisor read data, page not present.
:
Stopped at 0xbed7143d calll *ll+0x27(%rax)

Unfortunately keyboard doesn't work and no serial connection easily 
possible.
But I'll be able to connect a serail console if more info is 
needed/useful, please tell me!


-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: Post r337773 EFIRT-boot-panic still happening with r337838 [Was: Re: svn commit: r337838 - head/sys/amd64/amd64]

[Harry Schmalzbauer]

Am 01.09.2018 um 21:01 schrieb Konstantin Belousov:

On Sat, Sep 01, 2018 at 08:16:15PM +0200, Harry Schmalzbauer wrote:

I'm testing ALPHA4 on a Ivy bridge machine, without recent firmware
update, so no PCID.

I have no idea what is the connection between firware updates and PCID.
Ivy CPUs do have the PCID feature.


Sorry, I confused it with INVPCID which is nonsense too.
IBPB was firmware related, but this is completely different to this EFIRT...
Ignore please.




This fix doesn't cover that hardware.
Setting efi.rt.disabled=1 in loader.conf makes it bootable.

Without this tweak, the following panic happens:
Fatal trap 12: Page fault while in kernel mode
:
cpuid = 5; apic id = 05
:
fault code: supervisor read data, page not present.
:

Try https://reviews.freebsd.org/D16972


Panic vanished, boots fine with D16972-47525, nothing more checked.

Thanks a lot,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r324508 - head/sys/kern

[Harry Schmalzbauer]

Bezüglich Mark Johnston's Nachricht vom 01.04.2018 18:47 (localtime):
> On Sat, Mar 31, 2018 at 11:33:48AM +0200, Harry Schmalzbauer wrote:
>>  Bezüglich Sean Bruno's Nachricht vom 11.10.2017 00:21 (localtime):
>>> Author: sbruno
>>> Date: Tue Oct 10 22:21:05 2017
>>> New Revision: 324508
>>> URL: https://svnweb.freebsd.org/changeset/base/324508
>>>
>>> Log:
>>>   match sendfile() error handling to send().
>>>   
>>>   Sendfile() should match the error checking order of send() which
>>>   is currently:
>>>   
>>>   SBS_CANTSENDMORE
>>>   so_error
>>>   SS_ISCONNECTED
>>>   
>>>   Submitted by: Jason Eggleston <ja...@eggnet.com>
>>>   Reviewed by:  glebius
>>>   MFC after:2 weeks
>>>   Sponsored by: Limelight Networks
>>>   Differential Revision:https://reviews.freebsd.org/D12633
>>>
>>> Modified:
>>>   head/sys/kern/kern_sendfile.c
>>>
>>
>> I'm still applying this one locally to stable/11.
>> Is it going to be MFCd before 11.2?
>>
>> There are a view more candidates:
>> https://svnweb.freebsd.org/base?view=revision=324601 along with
>> r324448
>> https://svnweb.freebsd.org/base?view=revision=327596
>> https://svnweb.freebsd.org/base?view=revision=328977
>> These were flagged for MFC with expired defer time.
>> And tomorrow this one was supposed to be MFCd also:
>> https://svnweb.freebsd.org/base?view=revision=331130
> 
> I think r324446 and r324448 need to be MFCed before most of these can go
> in. I MFCed the other commits (r317567, r324508) that you asked about in
> other threads.

Thanks for MFCing the unrelated other two (r317567, r324508) from cem@!

Hope someone finds time to sort out the dependiencies of r324446,
r324448 and this r324508 along with r324601, r327596, r328977.

Currently I don't have a sendfile() test case, but for some reason I
stumbled across this MFCflagged commit some time ago and I guess 11.2
shouldn't ship without.

Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r324673 - head/sys/kern

[Harry Schmalzbauer]

 Bezüglich Andriy Voskoboinyk's Nachricht vom 17.10.2017 00:50 (localtime):
> Tue, 17 Oct 2017 00:53:28 +0300 було написано Bryan Drewery
> :
>
>> On 10/16/2017 2:46 PM, Andriy Voskoboinyk wrote:
>>> Author: avos
>>> Date: Mon Oct 16 21:46:11 2017
>>> New Revision: 324673
>>> URL: https://svnweb.freebsd.org/changeset/base/324673
>>>
>>> Log:
>>>   mbuf(9): unbreak m_fragment()
>>
>> How was it broken
>
> Due to m_cat() usage reason (as described below); this part was
> not changed since function creation in r119644.
>
>> and since when?
>
> No idea here - probably, it was partially working until m_cat()
> improvement in r242256.
>
> P.S. Just checked with m_fragment(m, M_NOWAIT, -2) placed
> right before ieee80211_mbuf_defrag() (from D4077) and
> various m_len printf's before and after - it defragments
> frames before this change and works as intended after it.
>
>>
>>>
>>>   - Fix it by replacing m_cat() with m_prev->m_next = m_new
>>>   (m_cat() will try to append data - as a result, there will be no
>>>   fragmentation).
>>>   - Move some constants out of the loop.
>>>
>>>   Was previously tested with D4077.
>>>
>>>   Differential Revision:https://reviews.freebsd.org/D4090


Will r324673 be MFCd before 11.2?

Thanks,

-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r324102 - head/sys/netsmb

[Harry Schmalzbauer]

 Bezüglich Conrad Meyer's Nachricht vom 29.09.2017 17:53 (localtime):
> Author: cem
> Date: Fri Sep 29 15:53:26 2017
> New Revision: 324102
> URL: https://svnweb.freebsd.org/changeset/base/324102
>
> Log:
>   netsmb: Fix buggy/racy smb_strdupin()
>   
>   smb_strdupin() tried to roll a copyin() based strlen to allocate a buffer
>   and then blindly copyin that size.  Of course, a malicious user program
>   could simultaneously manipulate the buffer, resulting in a non-terminated
>   string being copied.
>   
>   Later assumptions in the code rely upon the string being nul-terminated.
>   
>   Just use copyinstr() and drop the racy sizing.
>   
>   PR: 222687
>   Reported by:Meng Xu 
>   Security:   possible local DoS
>   Sponsored by:   Dell EMC Isilon

Does anybody want to MFC this one before 11.2?

Thanks,

-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r324508 - head/sys/kern

[Harry Schmalzbauer]

 Bezüglich Sean Bruno's Nachricht vom 11.10.2017 00:21 (localtime):
> Author: sbruno
> Date: Tue Oct 10 22:21:05 2017
> New Revision: 324508
> URL: https://svnweb.freebsd.org/changeset/base/324508
>
> Log:
>   match sendfile() error handling to send().
>   
>   Sendfile() should match the error checking order of send() which
>   is currently:
>   
>   SBS_CANTSENDMORE
>   so_error
>   SS_ISCONNECTED
>   
>   Submitted by:   Jason Eggleston 
>   Reviewed by:glebius
>   MFC after:  2 weeks
>   Sponsored by:   Limelight Networks
>   Differential Revision:  https://reviews.freebsd.org/D12633
>
> Modified:
>   head/sys/kern/kern_sendfile.c
>

I'm still applying this one locally to stable/11.
Is it going to be MFCd before 11.2?

There are a view more candidates:
https://svnweb.freebsd.org/base?view=revision=324601 along with
r324448
https://svnweb.freebsd.org/base?view=revision=327596
https://svnweb.freebsd.org/base?view=revision=328977
These were flagged for MFC with expired defer time.
And tomorrow this one was supposed to be MFCd also:
https://svnweb.freebsd.org/base?view=revision=331130

Thanks,

-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317567 - head/sys/x86/x86

[Harry Schmalzbauer]

 Bezüglich Conrad Meyer's Nachricht vom 28.04.2017 20:25 (localtime):
> Author: cem
> Date: Fri Apr 28 18:25:10 2017
> New Revision: 317567
> URL: https://svnweb.freebsd.org/changeset/base/317567
>
> Log:
>   x86 MCA: Fix a deadlock in MCA exception processing
>   
>   In exceptional circumstances, an MCA exception will trigger when the
>   freelist is exhausted. In such a case, no error will be logged on the list
>   and 'mca_count' will not be incremented.
>   
>   Prior to this patch, all CPUs that received the exception would spin
>   forever.
>   
>   With this change, the CPU that detects the error but finds the freelist
>   empty will proceed to panic the machine, ending the deadlock.
>   
>   A follow-up to r260457.
>   
>   Reported by:Ryan Libby 
>   Reviewed by:jhb@
>   Sponsored by:   Dell EMC Isilon
>   Differential Revision:  https://reviews.freebsd.org/D10536
>
> Modified:
>   head/sys/x86/x86/mca.c

Does anybody want to MFC this one before 11.2?

Thanks,

-harry



___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r344974 - stable/12/sys/netpfil/pf

[Harry Schmalzbauer]

Am 10.03.2019 um 01:56 schrieb Kristof Provost:

Author: kp
Date: Sun Mar 10 00:56:38 2019
New Revision: 344974
URL: https://svnweb.freebsd.org/changeset/base/344974

Log:
   pf: Small performance tweak


Seems to be the MFC of 344493.
Out of curiosity, do you have to manually write these log messages each 
time?  I do my local svn commits with ' -m "A one liner since svn and me 
never beacem good friends, especailly if it's about log view/search"...  
I saw the FreeBSD provided templates, but since my skills and time won't 
allow me to advance to commiting anything, I haven't had a closer look.


Thanks,

-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r345057 - head/share/man/man7

[Harry Schmalzbauer]

Am 12.03.2019 um 10:27 schrieb Mateusz Piotrowski:

Author: 0mp (ports committer)
Date: Tue Mar 12 09:27:37 2019
New Revision: 345057
URL: https://svnweb.freebsd.org/changeset/base/345057

Log:
   ports.7: Add an example of how to use flavors
   
   At the moment the manual page is not documenting how to build

   a flavored package. Let's start documenting flavors with
   an example of a typical use case.
   
   Reported by:	cem, dim

   Reviewed by: bcr, cem, mat, matthew
   Approved by: cem (src)
   Differential Revision:   https://reviews.freebsd.org/D19531

Modified:
   head/share/man/man7/ports.7

Modified: head/share/man/man7/ports.7
==
--- head/share/man/man7/ports.7 Tue Mar 12 09:24:58 2019(r345056)
+++ head/share/man/man7/ports.7 Tue Mar 12 09:27:37 2019(r345057)
@@ -25,7 +25,7 @@
  .\"
  .\" $FreeBSD$
  .\"
-.Dd February 12, 2019
+.Dd March 12, 2019
  .Dt PORTS 7
  .Os
  .Sh NAME
@@ -587,7 +587,7 @@ The following command builds and installs Emacs.
  .Ed
  .It Sy Example 2\&: No Installing Dependencies with Xr pkg 8
  .Pp
-The following examples shows how to build and install a port without having to
+The following example shows how to build and install a port without having to
  build its dependencies.
  Instead, the dependencies are downloaded via
  .Xr pkg 8 .
@@ -603,6 +603,16 @@ The drawback is that
  .Xr pkg 8
  offers only packages built with the default set of
  .Va OPTIONS .
+.It Sy Example 3\&: No Building a Non-Default Flavor of a Port
+.Pp
+The following command builds a non-default flavor of a port.
+(In this case
+.Pa devel/py-pip
+is going to be built with Python 3.7 support.)
+.Bd -literal -offset 2n
+.Li # Ic cd /usr/ports/devel/py-pip
+.Li # Ic env FLAVOR=py37 make build


Since cem and dim seem to stumbled over the missing FLAVOR 
documentation, I see my main objection against current FLAVOR 
implementation confirmed:  Build stage must'nt silently chose a default 
FALVOR, but an OPTIONS-like dialog must inform the user and she _must_ 
choose one.


FLAVOR is a severe regression for ports usage to all FreeBSD users imho.
Users can't see if a port makes use of FLAVOR or not.
User won't get informed that default FLAVOR is in use.
Users can't see what FLAVORs are supported (and/or why, with what 
consequences...).
Port/Package name relation gets lost (also for make(1) variables widley 
used in my scripts, which I still have to track down...).

FLAVOR silently broke $WRKDIRPREFIX.

If of any use, it's solely for maintainers, but at the cost of users.  
The ports options framework is not really user friendly too, but does a 
basic job in guiding users.  FLAVOR does the opposite.
There was nothing wrong with slave ports.  If maintainers have to spend 
a fraction more time on slave ports than on FLAVORized ports, it's worth 
every second, instead of distracting users. The more poudriere 
optimization the ports tree gets, the more distraction for 
users/admins/engineers/students comes along and FreeBSD loses one 
elementary strength of the project, imho.
Instructing users to set an environment variable to a value, which they 
have to lookup from a Makefile, is a very poor usability design, imho.


Hope this isn't the completely wrong place to point to ports stuff...

Thanks,

-harry


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r345057 - head/share/man/man7

[Harry Schmalzbauer]

Am 12.03.2019 um 11:50 schrieb Alexey Dokuchaev:

On Tue, Mar 12, 2019 at 11:17:58AM +0100, Harry Schmalzbauer wrote:

Am 12.03.2019 um 10:27 schrieb Mateusz Piotrowski:

New Revision: 345057
URL: https://svnweb.freebsd.org/changeset/base/345057

Log:
ports.7: Add an example of how to use flavors


Since cem and dim seem to stumbled over the missing FLAVOR
documentation, I see my main objection against current FLAVOR
implementation confirmed: build stage must'nt silently chose a
default FLAVOR, but an OPTIONS-like dialog must inform the user
and she _must_ choose one.

FLAVOR is a severe regression for ports usage to all FreeBSD
users imho.  Users can't see if a port makes use of FLAVOR or not.
User won't get informed that default FLAVOR is in use. [...]


Users who install packages that are built from a flavorized port
are well informed which flavor they're about to install, I don't
see how flavors cause a problem -- they must have unique PKGNAMEs.

For users that are building ports by themselves, looking into a
Makefile can be helpful, but then again -- don't we always do that?
It might slip when building the dependencies, so yeah, some extra
care is in order.  I don't see what's a big deal here, and flavors
are certainly less annoying and more flexible than slave ports.

If you really want an OPTIONS-like dialog popup then perhaps you
should've attached some patches to your complaints. :-)


You are right, I missed the patches...

Here's my local diff which works around some more recent regressions 
which were breaking local ports tree usage.
Abusing IGNORE is not a solution, but helps my avoiding unexpected 
results.  I see no easy way to patch FLAVOR, so I preferred spending 
time working around USE_PACKAGE_DEPENDS shortcomings.  Unfortunately 
very limited time, but I'm able to smart-compile packages.


I don't support teaching users using packages in favour of ports.
Ports is great for the ambitious users etc. and often the first 
"isnsight" for newbies.
But it's much more time consuming (wasting) than using packages, due to 
the brute force compile approach widley used.
USE_PACKAGE_DEPENDS virtually always leads to inconsitencies, since only 
the first dependency is resolved with the ports tree, subsequent 
dependencys are resolved by pkg - hence, if not 
in-sync-brute-force-compiled, it's likely that previous built packages 
have different dependency versions than your fresh built.


My tool handles that and generates a _consistent_ iso image repository.
Personally need/want that to maintain production environments with 
sensible ammount of effort (my production environments don't have 
compilers).
I still have to iron out bugs of all categories during usage, but it's 
in use and saving me really a lot of time.
(It also handles OPTIONS mismatches between possibly existing packages 
and current ports options settings – which can also save a lot of time 
and points out possibly unwanted current settinges etc..)


I was also missing the ability to batch-package everything already 
compiled in WRKDIRPREFIX, so I wrote a small Makefile, which acts as a 
harvester.  Simly to be called in the wanted PACKAGES directory.  Happy 
to share on request.



Index: /usr/ports/Mk/bsd.port.mk
===
--- /usr/ports/Mk/bsd.port.mk   (revision 495299)
+++ /usr/ports/Mk/bsd.port.mk   (working copy)
@@ -1051,8 +1051,8 @@
 .if empty(FLAVOR) && !empty(.MAKEOVERRIDES:MFLAVOR)
 .error FLAVOR may not be passed empty as a make argument.
 .endif
-# Store env FLAVOR for later
-.if !defined(_FLAVOR)
+# Store cli FLAVOR for later
+.if !defined(_FLAVOR) && defined(.MAKEOVERRIDES) && 
!empty(.MAKEOVERRIDES:MFLAVOR)

 _FLAVOR:=  ${FLAVOR}
 .endif
 PORTS_FEATURES+=   FLAVORS
@@ -1492,9 +1492,13 @@
 .  endif
 .endif

-.if !empty(FLAVORS) && empty(FLAVOR)
-FLAVOR=${FLAVORS:[1]}
+.if !empty(FLAVORS) && empty(_FLAVOR)
+.if empty(PY_FLAVOR)
+IGNORE= Missing FLAVOR definition! Possible flavors: ${FLAVORS} (Usage: 
'make FLAVOR=${FLAVORS:[1]} ${.TARGETS}' e.g.)

+.else
+_FLAVOR:=${PY_FLAVOR}
 .endif
+.endif

 # Reorder FLAVORS so the default is first if set by the port.
 .if empty(_FLAVOR) && !empty(FLAVORS) && !empty(FLAVOR)
@@ -1675,10 +1679,14 @@
 .endif

 .if empty(FLAVOR)
-_WRKDIR=   work
+.ifdef WRKDIRPREFIX
+WRKDIR=${WRKDIRPREFIX}${.CURDIR:S,${PORTSDIR},,}/work
+.endif
 .else
-_WRKDIR=   work-${FLAVOR}
+.ifdef WRKDIRPREFIX
+WRKDIR=${WRKDIRPREFIX}${.CURDIR:S,${PORTSDIR},,}/work-${FLAVOR}
 .endif
+.endif

 WRKDIR?=   ${WRKDIRPREFIX}${.CURDIR}/${_WRKDIR}
 BINARY_LINKDIR=${WRKDIR}/.bin
@@ -2578,7 +2586,6 @@
 PKGREPOSITORYSUBDIR?=  All
 PKGREPOSITORY?=${PACKAGES}/${PKGREPOSITORYSUBDIR}
 .if exists(${PACKAGES})
-PACKAGES:= ${PACKAGES:S/:/\:/g}
 _HAVE_PACKAGES=yes
 PKGFILE?=  ${PKGREPOSITORY}/${PKGNAME}${PKG_SUFX}
 .el

Re: svn commit: r344027 - in stable/12/sys: dev/vmware/vmxnet3 modules/vmware/vmxnet3 net

[Harry Schmalzbauer]

Am 12.02.2019 um 02:25 schrieb Rodney W. Grimes:

On Mon, Feb 11, 2019 at 8:08 PM John Baldwin  wrote:


On 2/11/19 4:26 PM, Rodney W. Grimes wrote:

Author: pkelsey
Date: Mon Feb 11 23:24:39 2019
New Revision: 344027
URL: https://svnweb.freebsd.org/changeset/base/344027

Log:
   MFC r343291:
   Convert vmx(4) to being an iflib driver.

I strongly object to this MFC, given the current number
of 12.0 RELEASE related iflib problems we have it is
foolish of us to iflib any more drivers in 12.0

This isn't the release branch though and presumably we have some time
before
12.1 ships.  If there are reports of vmx(4) breakage on stable before 12.1
we could always revert this commit then?

I've heard of some EN's for 12.0 for iflib fixes.  Are those fixes in
stable/12
yet or are we still waiting for them to land in HEAD and/or be merged?


iflib.c is currently the same between head and stable/12.  I've found and
fixed a number of iflib bugs by developing the iflib version of the vmx(4)
driver, and it's also being fielded in a product.  I'm also aware that not
all current driver problems are necessarily iflib problems.  I think we'd
be better off letting this version of vmx(4) ride it out in stable/12 until
such time as we discover an actual horror that we then feel we need to
react to in some way other than just going ahead and fixing it.

It can ride it out in head just fine, give it 3 months... plenty of time
before any 12.1.  stable/12 IS NOT A TEST GROUND.


I don't think the intention of this MFC is to test the iflib(4) version 
of vmx(4), but to improve the driver, which has been tested locally by 
the devop and also in HEAD for some time.
Many regressions/problem(combinations) aren't found during HEAD 
lifetime, but after MFC.  And in case of iflib(4), it wasn't the MFC to 
-STABLE, but after -RELEASE.

If it would have had a wider production (-STABLE) usage, possibly...
As long as the devop isn't aware of known, yet to fix _additional_ bugs 
or any regression, I'm happy to reduce my local MFC patchset and have it 
in STABLE as soon as the devops MFC timeframe lapsed without a single 
regression/problem notification.  I've never updated any -stable 
production machine relying on the hope someone else tested every 
possible change.  That's what I'd like to beeing allowed to expect from 
-RELEASE; which hasn't ever been true for major version updates.


So this MFC won't harm -stable in any form, but will improve 
12.1-release quality.

Just a/my opinion from the users view!

Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r346976 - head/usr.sbin/mountd

[Harry Schmalzbauer]

Am 30.04.2019 um 23:38 schrieb Alexander Motin:

Author: mav
Date: Tue Apr 30 21:38:38 2019
New Revision: 346976
URL: https://svnweb.freebsd.org/changeset/base/346976

Log:
   Respect quotes and escapes when splitting exports fields.
   
   Without this r293305 was still unable to handle names with spaces.
   
   MFC after:	1 week


Hi Alexander,

could you please have a look into
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238725

This commit breaks -maproot for :groupX definition in exports(5).

Since this was also MFCd to stable/11 (in r347341), I hope this can be 
fixed quickly and RE approves the fix for 11.3.


Thanks,

-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r346217 - in head/sys: fs/nfs fs/nfsclient kern sys

[Harry Schmalzbauer]

Am 15.04.2019 um 03:27 schrieb Rick Macklem:

Author: rmacklem
Date: Mon Apr 15 01:27:15 2019
New Revision: 346217
URL: https://svnweb.freebsd.org/changeset/base/346217

Log:
   Fix the NFSv4 client to safely find processes.
   
   r340744 broke the NFSv4 client, because it replaced pfind_locked() with a

   call to pfind(), since pfind() acquires the sx lock for the pid hash and
   the NFSv4 already holds a mutex when it does the call.
   The patch fixes the problem by recreating a pfind_any_locked() and adding the
   functions pidhash_slockall() and pidhash_sunlockall to acquire/release
   all of the pid hash locks.
   These functions are then used by the NFSv4 client instead of acquiring
   the allproc_lock and calling pfind().
   
   Reviewed by:	kib, mjg

   MFC after:   2 weeks


Hello, I guess as long as r340744 isn't MFCd, this commit isn't needed 
in /stable/, is it?


Any plans to MFC 
https://svnweb.freebsd.org/base?view=revision=340744

(proc: convert pfind & friends to use pidhash locks and other cleanup)

Thanks,

-Harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r355482 - stable/12/sbin/dhclient

[Harry Schmalzbauer]

Am 07.12.2019 um 04:56 schrieb Ed Maste:

Author: emaste
Date: Sat Dec  7 03:56:36 2019
New Revision: 355482
URL: https://svnweb.freebsd.org/changeset/base/355482

Log:
   MFC r238022 (cem): dhclient: fix braino in previous bugfix r300174


PR vs. SVN typo, cem's commit was r355204.

Thanks,

-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r364863 - head

[Harry Schmalzbauer]

Am 27.08.2020 um 15:26 schrieb Ryan Moeller:

Author: freqlabs
Date: Thu Aug 27 13:26:36 2020
New Revision: 364863
URL: https://svnweb.freebsd.org/changeset/base/364863

Log:
   libzfs: Also add the crypto dependency to Makefile.inc1
   
   Reported by:	kevans

   Discussed with:  kevans
   Sponsored by:iXsystems, Inc.

Modified:
   head/Makefile.inc1



Hello,

this still doesn't allwo me to compile ZFS into the kernel:
linking kernel.full
ld: error: undefined symbol: zfs_zstd_compress
>>> referenced by zio_compress.c
>>>   zio_compress.o:(zio_compress_table)

ld: error: undefined symbol: zfs_zstd_decompress
>>> referenced by zio_compress.c
>>>   zio_compress.o:(zio_compress_table)

ld: error: undefined symbol: zfs_zstd_decompress_level
>>> referenced by zio_compress.c
>>>   zio_compress.o:(zio_compress_table)
*** Error code 1

According to src/sys/amd64/conf/NOTES, "options ZFS" should still be 
supported.

Unfortunately I have no adhoc idea how to fix. Anybody else?

Thanks,
-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r364863 - head

[Harry Schmalzbauer]

Am 28.08.2020 um 17:43 schrieb Ryan Moeller:
…

ld: error: undefined symbol: zfs_zstd_decompress_level
>>> referenced by zio_compress.c
>>>   zio_compress.o:(zio_compress_table)
*** Error code 1

According to src/sys/amd64/conf/NOTES, "options ZFS" should still be 
supported.

Unfortunately I have no adhoc idea how to fix. Anybody else?



You need options ZSTDIO, too. NOTES needs to be updated.


Thanks a lot!

May I suggest the following change:
Index: sys/contrib/openzfs/man/man8/zfsprops.8
===
--- sys/contrib/openzfs/man/man8/zfsprops.8 (Revision 364900)
+++ sys/contrib/openzfs/man/man8/zfsprops.8 (Arbeitskopie)
@@ -1049,8 +1049,9 @@
 dataset creation time and it cannot be changed afterwards.
 .Pp
 For more details and caveats about encryption see the
-.Sy Encryption
-section.
+.Em Encryption
+section of
+.Xr zfs-load-key 8 .
 .It Sy keyformat Ns = Ns Sy raw Ns | Ns Sy hex Ns | Ns Sy passphrase
 Controls what format the user's encryption key will be provided as. This
 property is only set when the dataset is encrypted.


Curious about the new OpenZFS bells and whistles, I promptly struggeld 
over finding "the Encryption section".


Some lines above, the man page already mentiones explicitly 
zfs-load-key.8 while referencing the Encryption section, so I just 
copied the macros used there - not much clue about man here…


Thanks,
-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r368820 - head

[Harry Schmalzbauer]

Am 24.12.2020 um 10:21 schrieb N.J. Mann:

Hi,


On Thursday, December 24, 2020 09:57:16 +0100 Harry Schmalzbauer 
 wrote:
[...]

stumble across an hint about any svn-src-(BRANCH|all)@ replacement.


I wondered this a few days ago and found dev-commits-src-all, et al.  See
https://lists.freebsd.org/mailman/listinfo


Thanks a lot!  Glad to see mailinglist is still provided and 
subscription still as easy as it's been before :-)


Most wanted link these days I guess :-)

-harry
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r368820 - head

[Harry Schmalzbauer]

Am 21.12.2020 um 15:26 schrieb Kyle Evans:

On Mon, Dec 21, 2020 at 8:24 AM Rodney W. Grimes
 wrote:

On Sun, 20 Dec 2020 15:46:12 +0100
"Hartmann, O."  wrote:


On Sun, 20 Dec 2020 02:59:44 + (UTC)
Li-Wen Hsu  wrote:


Author: lwhsu
Date: Sun Dec 20 02:59:44 2020
New Revision: 368820
URL: https://svnweb.freebsd.org/changeset/base/368820

Log:
   Mark the repository as being converted to Git.

   This is the last Subversion commit to src.

   Sponsored by:   The FreeBSD Foundation

:...

Is this message of yours also the last message concerning the source changes? 
Since then
you published this message, no further logs ran into list 
svn-src-h...@freebsd.org.


Take a look at this https://wiki.freebsd.org/git.  Write access to
Subversion has been disabled.

I think the bigger question is why as a committer have I not seen ANY
commits to git since this cut over?  Is it a) none have happened in 24 hours,
or b) commit mail is no longer going to developers as it use to?


Still curious about an answer to Oliver"s question regarding the 
changlog mailing list.
I read asorted sources about Git and briefly imp@'s highly appreciated 
docs, but didn't stumble across an hint about any svn-src-(BRANCH|all)@ 
replacement.


Thanks,
-harry

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"