Re: Upcoming release of V 12

2018-09-11 Thread Benjamin Kaduk 
On Tue, Sep 11, 2018 at 10:21:31AM -0700, Jeffrey Bouquet wrote:
> I'm running v12 as HEAD [ 12.0-CURRENT]
> 
> And am at a loss as to how to change it to 12.0-STABLE vs one day
> running  a non-rebuilt 13.0-CURRENT  
> 
> Without risking a scenario such as:
>svn up 12.0, fail for some reason to be able to build the GPU driver, so I 
> should
>have stuck with svn up 13.0 ??? 
> As I've no second machine setup as backup.  due to moving issues. 

The stable/12 branch does not yet exist in Subversion.  Once it does,
you'd be able to use 'svn switch' to switch from tracking base/head to
tracking base/stable/12 .

-Ben
___
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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context [md related processes left waiting (and more)]

2018-09-11 Thread Mark Millard 
[After the run top -CawSopid shows something interesting/odd:
lots of g_eli[?] and md?? processes are still around in 
geli:w state for g_eli[?] and mdwait for md??. Also there
are 4 processes in aiordy state.]

On 2018-Sep-11, at 8:48 AM, Mark Millard  wrote:

> [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones.
> lib/libc/string/memcmp_test:diff is one of them.]
> 
> On 2018-Sep-11, at 2:44 AM, Mark Millard  wrote:
> 
>> [No zfs use, just a UFS e.MMC filesystem on a microsd adapter.]
>> 
>> I got 14 failures. I've not enabled any configuration properties.
>> 
>> I do not know if official devel/kyua tests are part of the head ->
>> stable transition for any tier or not. I'm not claiming to know if
>> anything here could be a significant issue.
>> 
>> Someone may want to test an official aarch64 build rather than presume
>> that my personal build is good enough. But I expect that its results
>> should be strongly suggestive, even if an official tests uses a more
>> normal-for-FreeBSD configuration of an aarch64 system.
>> 
>> The e.MMC is V5.1 is operating in DDR52 mode and is faster than normal
>> configurations for the Pine 64+ 2GB. TRIM is in use for the UFS file
>> system. This might let some things pass that otherwise would time out.
>> 
>> 
>> ===> Failed tests
>> lib/libc/resolv/resolv_test:getaddrinfo_test  ->  failed: 
>> /usr/src/lib/libc/tests/resolv/resolv_test.c:299: run_tests(_hostlist_file, 
>> METHOD_GETADDRINFO) == 0 not met  [98.834s]
>> lib/libc/ssp/ssp_test:vsnprintf  ->  failed: atf-check failed; see the 
>> output of the test for details  [0.107s]
>> lib/libc/ssp/ssp_test:vsprintf  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.105s]
>> lib/libproc/proc_test:symbol_lookup  ->  failed: 
>> /usr/src/lib/libproc/tests/proc_test.c:143: memcmp(sym, , sizeof(*sym)) 
>> != 0 [0.057s]
>> lib/msun/trig_test:accuracy  ->  failed: 3 checks failed; see output for 
>> more details  [0.013s]
>> lib/msun/trig_test:special  ->  failed: 8 checks failed; see output for more 
>> details  [0.013s]
>> local/kyua/utils/stacktrace_test:dump_stacktrace__integration  ->  failed: 
>> Line 391: atf::utils::grep_file("#0", exit_handle.stderr_file().str()) not 
>> met  [4.015s]
>> local/kyua/utils/stacktrace_test:dump_stacktrace__ok  ->  failed: Line 420: 
>> atf::utils::grep_file("^frame 1$", exit_handle.stderr_file().str()) not met  
>> [4.470s]
>> local/kyua/utils/stacktrace_test:dump_stacktrace_if_available__append  ->  
>> failed: Line 560: atf::utils::grep_file("frame 1", 
>> exit_handle.stderr_file().str()) not met  [4.522s]
>> local/kyua/utils/stacktrace_test:find_core__found__long  ->  failed: Core 
>> dumped, but no candidates found  [3.988s]
>> local/kyua/utils/stacktrace_test:find_core__found__short  ->  failed: Core 
>> dumped, but no candidates found  [4.014s]
>> sys/kern/ptrace_test:ptrace__PT_STEP_with_signal  ->  failed: 
>> /usr/src/tests/sys/kern/ptrace_test.c:3465: WSTOPSIG(status) == SIGABRT not 
>> met  [0.017s]
>> usr.bin/indent/functional_test:nsac  ->  failed: atf-check failed; see the 
>> output of the test for details  [0.151s]
>> usr.bin/indent/functional_test:sac  ->  failed: atf-check failed; see the 
>> output of the test for details  [0.150s]
>> ===> Summary
>> Results read from 
>> /root/.kyua/store/results.usr_tests.20180911-070147-413583.db
>> Test cases: 7301 total, 212 skipped, 37 expected failures, 116 broken, 14 
>> failed
>> Total time: 6688.125s
>> 
>> 
>> 
>> 
>> I'll note that the console reported over 73720 messages like (with figures
>> where I've listed 's):
>> 
>> md.eli: Failed to authenticate  bytes of data at offset .
>> 
>> There are also device created and destroyed/removed notices with related
>> material. Overall there were over 84852 lines reported with "GEOM_ELI:"
>> on the line.
>> 
>> This did not prevent tests from passing.
>> 
>> (The huge console output is unfortunate in my view: it makes finding
>> interesting console messages a problem  while watching messages
>> go by.)
>> 
>> 
>> 
>> I did get the console message block:
>> 
>> kern.ipc.maxpipekva exceeded; see tuning(7)
>> Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
>> Sep 11 01:36:25 pine64 kernel: nd6_dad_timer: called with non-tentative 
>> address (epair2Freed UMA keg (rtentry) was not em

Intel help with i915 drm-next-kmod (was: drm / drm2 removal in 12)

2018-09-11 Thread Graham Perrin 
On 25/08/2018 09:32, Ali Abdallah wrote:
> Isn't Intel supposed to be working on a native drm driver for FreeBSD?
>
> https://bwidawsk.net/blog/index.php/2018/06/i965-compiler-architecture-from-2015/
…

Not that I can see. 

A more recent blog post 
 mentions 
"Help i915 drm-next-kmod work".

HTH

___
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: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M

2018-09-11 Thread Graham Perrin 
On 22/08/2018 17:50, Pete Wright wrote:
>
> On 8/22/18 2:11 AM, Graham Perrin wrote:
>> HP EliteBook 8570p with AMD 'Thames' Radeon HD 7570M.

…

>> With and without drm-next-kmod:
>> if boot is hybrid UEFI with CSM,
>> then suspend occurs, but resume fails. No beep, the computer restarts.
>>
>> debug.acpi.resume_beep=1
>> in /boot/loader.conf for an audible beep.
>>
>> 
>>
>> Please: might graphics/drm-devel-kmod be better for either the tearing 
>> (without CSM) or for suspend?
>
> not sure this will address this specific issue - but have you tested setting 
> this sysctl knob and seeing if that fixes your resume issues:
> hw.acpi.reset_video=1
>
> -pete
>
Thanks again. Briefly:

- with CSM
- with hw.acpi.reset_video=1
- without using /boot/modules/radeonkms.ko
- FreeBSD 12.0-ALPHA2 #2 r337986: Fri Aug 17 22:01:23 BST 2018


Result:

- endless beep when resume is attempted.

A short press on the power button (around two seconds, not long enough to stop 
the computer) temporarily silences the beep.



 
there's the additional advice from Johannes Lundberg. Updating the OS etc. now, 
I'll share test results in due course. *
*

___
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: jail exec.clean busted in 12?

2018-09-11 Thread Michael W. Lucas 
On Tue, Sep 11, 2018 at 06:55:56PM -0400, Shawn Webb wrote:
> On Tue, Sep 11, 2018 at 03:58:02PM -0400, Michael W. Lucas wrote:
> > 
> > Hi,
> > 
> > storm~;uname -a
> > FreeBSD storm 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #10 r338496: Thu Sep  6 
> > 12:29:00 EDT 2018 root@storm:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  
> > amd64
> > 
> > It appears that exec.clean is busted. Here's my jail.conf:
> > 
> > ---
> > 
> > $j="/jail";
> > path="$j/$name";
> > host.hostname="$name.mwl.io";
> > 
> > mount.devfs;
> > exec.clean=0;
> > exec.start="sh /etc/rc";
> > exec.stop="sh /etc/rc.shutdown";
> > 
> > loghost {
> >   ip4.addr="203.0.113.231";
> >   allow.raw_sockets=1;
> >   jid=99;
> > }
> > 
> > logdb {
> >   host.hostname="logdb.mwl.io";
> >   ip4.addr="203.0.113.232";
> >   }
> > 
> > ---
> > 
> > exec.clean is not explicitly defined on the command line, but it's the
> > default, so it maybe shouldn't be?
> > 
> > storm~;jls -n
> > devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable 
> > jid=8 linux=new name=logdb osreldate=1200084 osrelease=12.0-ALPHA4 parent=0 
> > path=/jail/logdb nopersist securelevel=-1 sysvmsg=disable sysvsem=disable 
> > sysvshm=disable vnet=inherit allow.nochflags allow.nomlock allow.nomount 
> > allow.mount.nodevfs allow.mount.nofdescfs allow.mount.nolinprocfs 
> > allow.mount.nonullfs allow.mount.noprocfs allow.mount.notmpfs 
> > allow.mount.nozfs allow.noquotas allow.noraw_sockets allow.reserved_ports 
> > allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=0 
> > children.max=0 cpuset.id=6 host.domainname="" host.hostid=0 
> > host.hostname=logdb.mwl.io 
> > host.hostuuid=---- ip4.addr=203.0.113.232 
> > ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux 
> > linux.osrelease=2.6.32 linux.oss_version=198144
> > devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable 
> > jid=99 linux=new name=loghost osreldate=1200084 osrelease=12.0-ALPHA4 
> > parent=0 path=/jail/loghost nopersist securelevel=-1 sysvmsg=disable 
> > sysvsem=disable sysvshm=disable vnet=inherit allow.nochflags allow.nomlock 
> > allow.nomount allow.mount.nodevfs allow.mount.nofdescfs 
> > allow.mount.nolinprocfs allow.mount.nonullfs allow.mount.noprocfs 
> > allow.mount.notmpfs allow.mount.nozfs allow.noquotas allow.raw_sockets 
> > allow.reserved_ports allow.set_hostname allow.nosocket_af allow.nosysvipc 
> > children.cur=0 children.max=0 cpuset.id=7 host.domainname="" host.hostid=0 
> > host.hostname=loghost.mwl.io 
> > host.hostuuid=---- ip4.addr=203.0.113.231 
> > ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux 
> > linux.osrelease=2.6.32 linux.oss_version=198144
> > 
> > Anyway, I found this by:
> > 
> > # jexec loghost env
> > HOME=/home/mwlucas
> > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/mwlucas/bin
> > TERM=xterm
> > LC_COLLATE=C
> > LANG=en_US.UTF-8
> > SSH_CLIENT=203.0.113.70 59076 22
> > SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22
> > SSH_TTY=/dev/pts/2
> > SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492
> > LC_CTYPE=en_US.ISO-8859-1
> > MAIL=/var/mail/root
> > ...
> > 
> > I'm highly confident my SSH environment shouldn't be in the jail. Yes,
> > it goes away if I add -l, but my (admittedly sketchy) reading of the
> > jexec source says that jexec handles stripping the environment before
> > running the command.
> > 
> > Even if I start it the hard way (from a discussion at
> > https://github.com/iocage/iocage/issues/610)
> > 
> > storm~;jail -c path=/jail/loghost/ host.hostname=loghost exec.clean=1 
> > persist
> > storm~;jls
> >JID  IP Address  Hostname  Path
> >  9  loghost   /jail/loghost
> >  
> > storm~;jexec 9 env | grep -i ssh
> > SSH_CLIENT=203.0.113.70 59076 22
> > SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22
> > SSH_TTY=/dev/pts/2
> > SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492
> > storm~;
> > 
> > Any ideas?
> 
> Hey Michael,
> 
> It appears the jail.exec option is for jail(8) only.

Ah, okay. Thanks. Not obvious, but makes sense.

(So you can run your dirty environment in the jail through jexec? Cool.)

==ml

> You need to pass
> the -l option to jexec(8) to sanitize the environment.
> 
> Thanks,
> 
> -- 
> Shawn Webb
> Cofounder and Security Engineer
> HardenedBSD
> 
> Tor-ified Signal:+1 443-546-8752
> Tor+XMPP+OTR:latt...@is.a.hacker.sx
> GPG Key ID:  0x6A84658F52456EEE
> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE



-- 
Michael W. Lucashttps://mwl.io/
author of: Absolute OpenBSD, SSH Mastery, git commit murder,
Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc...
___
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: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-11 Thread Rodney W. Grimes 
> On 11 September 2018 at 07:35, Tomoaki AOKI  wrote:
> > I prefer releng, rather than stable, to make it default.
> > Binary releases requiring reproducible builds are built from
> > release and releng branches.
> 
> This might be the reasonable long-term strategy, but we don't yet have
> experience running through the release process with it enabled. I
> would like to enable it by default on the branch, at least initially,
> to avoid discovering issues only immediately prior to the release.

I wish we had done this before ALPHA1 it would of given us
a larger window to work in.

There should be a set of builds Thursday,
can we get this turned on for them so we
can get at least a build with it before
we branch?  IE, commit this to ^head/ now.

Then once stable/12 is branched we can turn it off
in head so the developers are not disturbed.

And further then once releng/12.0 is branched
we can turn it off in stable/12 so that those
users have status quo.

This I think gives us maximal test time, including
the binary upgrade bits that should get tested between
each BETA and RC build.  And minimal impact to developers
and users.

-- 
Rod Grimes rgri...@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"

amd64: enable options NUMA ing GENERIC and MINIMAL

2018-09-11 Thread Kevin Bowling 
-CURRENT users, in svn rS338602, 'options NUMA' has just been enabled
for amd64 GENERIC and MINIMAL kernels.

This should provide good effect to systems with more than one physical
CPU with associated memory, certain high core count Intel chips when
configured to use Cluster-on-Die or Sub-NUMA-Clustering, and recent
AMD products with multiple chiplets like Thread Ripper and EPYC.  If
you have a single domain system, there is no expected change.

If you have such NUMA machines, early testing would be greatly
appreciated in order to ensure the quality and stability of the 12.0
release.

You can confirm configuration of NUMA domains with 'sysctl
vm.ndomains', example output:
vm.ndomains: 2

This work was sponsored by Dell EMC Isilon and Netflix and led by Jeff
Roberson.  Some folks have participated for a long time in bi-weekly
calls and stabilization.  It is known to be used in production
configurations for some time at Netflix and Limelight Networks.

If you encounter any issues where you suspect this is the root cause,
please disable 'options NUMA' in the kernel configuration and
reproduce before reporting as such.

This would be a good time to audit your kernel config if copied from
GENERIC and consider if you can instead use 'include GENERIC-NODEBUG'
to only track local modifications.

Regards,
Kevin Bowling
___
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: Request for Review: Generate /etc/services from the IANA registry

2018-09-11 Thread Steffen Nurpmeso 
Eric van Gyzen wrote in :
 |On 9/11/18 10:04 AM, Steffen Nurpmeso wrote:
 |> Alan Somers wrote in  w...@mail.gmail.com>:
 |>|Don't worry Steffen.  Python won't be a build requirement for FreeBSD \
 |>|even after Eric's patch.  His Python script will only need to be run \
 |>|whenever IANA
 |>|updates its database, and the results will be checked into source contro\
 |>|l.  So for a normal user, there is no change to "make buildworld && make
 |>|installworld".
 |> 
 |> I cannot, unfortunately.  I use binary updates and even
 |> preinstalled VM images (thanks for that, by the way).
 |
 |So there will be no impact on you at all, except that /etc/services will 
 |have a lot more services.  As Alan said, Python and XML will only be 
 |added to the developer workflow.

Oh please, of course.  For me personally the FreeBSD version is
good enough anyway, it is just that i discovered this script for
a pretty common Linux distribution, and adopted it for a lesser
common one when there was a need to update the DBs.  To be honest
i have discovered it in the packaging system in some repository,
and that is a pity.  FreeBSD as i got to know it, and i would have
snooped around in /usr/share/misc of a default install in that
case first, and if i would have been lucky i would have discovered
good stuff to help me out.  That is all.

 |>|As for Python vs Awk, I too tried to do this with Awk.  However, Awk \
 |>|can't easily handle things like IANA's representation of aliases, and \
 |>|it can't
 |>|easily format the list in the same order as our current list.  Python \
 |>|is truly a better choice.
 |> 
 |> I absolutely fail to see what you mean.  The script (which is in
 |> actual use, mind you) generates the desired output except that
 |> comments get lost, but this could be added upon interest, of
 |> course.  It (or a derivative) would have been a good candidate for
 |> /usr/share/misc/ in elder times i guess, too.
 |
 |That awk script depends on the formatting of the XML file.  It will 
 |break if the IANA decides to format it differently.  Granted, this is 
 |unlikely, but it's possible.

If you argue like this, anything is possible, is it.  If IANA
changes the XML tags, the Python script needs to be adjusted, too.
And if you ask me, i would vote for, and change to JSON.  No
offense, i said the same on a Unicode list, for example.

 |Also, that script would become much more complex if it supported local 
 |additions and overrides, which are unfortunately necessary in our case.

Come one.  I mean, come on.  What are you talking about?  You have
written these things, and they will likely enter FreeBSD.  This
does not make it just just any better in my eyes.  (Though the
counting program could be adjusted and be used as a test if the
sorted output would be compared against a sed(1) run on
/etc/services.)  If it would be me, a very small awk script would
enter /usr/share/misc, and some makefile would be adjusted and
call it, or a duplicate.  Base system self-contained, and some
nice hint to be found for someone who looks around.

I mean, i really looked out of interest at some review page in the
webbrowser (glad that you posted this for people who do not like
browsers that much, or get email notifications or whatever), which
was so large or whatever, anyway it blocked the tab.  Isn't that
absurd for a simple update framework for IANA databases in /etc?
(And what about protocols, by the way.)
Just my one cent, of course.  I am not even a developer.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
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: jail exec.clean busted in 12?

2018-09-11 Thread Shawn Webb 
On Tue, Sep 11, 2018 at 03:58:02PM -0400, Michael W. Lucas wrote:
> 
> Hi,
> 
> storm~;uname -a
> FreeBSD storm 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #10 r338496: Thu Sep  6 
> 12:29:00 EDT 2018 root@storm:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  
> amd64
> 
> It appears that exec.clean is busted. Here's my jail.conf:
> 
> ---
> 
> $j="/jail";
> path="$j/$name";
> host.hostname="$name.mwl.io";
> 
> mount.devfs;
> exec.clean=0;
> exec.start="sh /etc/rc";
> exec.stop="sh /etc/rc.shutdown";
> 
> loghost {
>   ip4.addr="203.0.113.231";
>   allow.raw_sockets=1;
>   jid=99;
> }
> 
> logdb {
>   host.hostname="logdb.mwl.io";
>   ip4.addr="203.0.113.232";
>   }
> 
> ---
> 
> exec.clean is not explicitly defined on the command line, but it's the
> default, so it maybe shouldn't be?
> 
> storm~;jls -n
> devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable 
> jid=8 linux=new name=logdb osreldate=1200084 osrelease=12.0-ALPHA4 parent=0 
> path=/jail/logdb nopersist securelevel=-1 sysvmsg=disable sysvsem=disable 
> sysvshm=disable vnet=inherit allow.nochflags allow.nomlock allow.nomount 
> allow.mount.nodevfs allow.mount.nofdescfs allow.mount.nolinprocfs 
> allow.mount.nonullfs allow.mount.noprocfs allow.mount.notmpfs 
> allow.mount.nozfs allow.noquotas allow.noraw_sockets allow.reserved_ports 
> allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=0 
> children.max=0 cpuset.id=6 host.domainname="" host.hostid=0 
> host.hostname=logdb.mwl.io host.hostuuid=---- 
> ip4.addr=203.0.113.232 ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux 
> linux.osrelease=2.6.32 linux.oss_version=198144
> devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable 
> jid=99 linux=new name=loghost osreldate=1200084 osrelease=12.0-ALPHA4 
> parent=0 path=/jail/loghost nopersist securelevel=-1 sysvmsg=disable 
> sysvsem=disable sysvshm=disable vnet=inherit allow.nochflags allow.nomlock 
> allow.nomount allow.mount.nodevfs allow.mount.nofdescfs 
> allow.mount.nolinprocfs allow.mount.nonullfs allow.mount.noprocfs 
> allow.mount.notmpfs allow.mount.nozfs allow.noquotas allow.raw_sockets 
> allow.reserved_ports allow.set_hostname allow.nosocket_af allow.nosysvipc 
> children.cur=0 children.max=0 cpuset.id=7 host.domainname="" host.hostid=0 
> host.hostname=loghost.mwl.io 
> host.hostuuid=---- ip4.addr=203.0.113.231 
> ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux linux.osrelease=2.6.32 
> linux.oss_version=198144
> 
> Anyway, I found this by:
> 
> # jexec loghost env
> HOME=/home/mwlucas
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/mwlucas/bin
> TERM=xterm
> LC_COLLATE=C
> LANG=en_US.UTF-8
> SSH_CLIENT=203.0.113.70 59076 22
> SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22
> SSH_TTY=/dev/pts/2
> SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492
> LC_CTYPE=en_US.ISO-8859-1
> MAIL=/var/mail/root
> ...
> 
> I'm highly confident my SSH environment shouldn't be in the jail. Yes,
> it goes away if I add -l, but my (admittedly sketchy) reading of the
> jexec source says that jexec handles stripping the environment before
> running the command.
> 
> Even if I start it the hard way (from a discussion at
> https://github.com/iocage/iocage/issues/610)
> 
> storm~;jail -c path=/jail/loghost/ host.hostname=loghost exec.clean=1 persist
> storm~;jls
>JID  IP Address  Hostname  Path
>  9  loghost   /jail/loghost
>  
> storm~;jexec 9 env | grep -i ssh
> SSH_CLIENT=203.0.113.70 59076 22
> SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22
> SSH_TTY=/dev/pts/2
> SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492
> storm~;
> 
> Any ideas?

Hey Michael,

It appears the jail.exec option is for jail(8) only. You need to pass
the -l option to jexec(8) to sanitize the environment.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Routine Panic on HP Proliant G10

2018-09-11 Thread Dave Robison 
Hiya,

I'm currently evaluating two classes of server which we source through NEC. 
However, the motherboards for these machines are HP. I can routinely panic both 
of these machines using 12.0-A4, as well as 11.1-R with a shoehorned in 
SES/SMARTPQI driver, and 11.2-R with its native SES/SMARTPQI driver. NEC seems 
to think this is a ZFS issue and they may be correct. If so I suspect ARC, 
though as I explain further down, I haven't had a problem on other hardware. 

I've managed to get a core dump on 11.1 and 11.2, but on 12.0 when the panic 
occurs, I can backtrace and force a panic and the system claims it is writing 
out a core dump, but on reboot there is no core dump.

Machine A: HP ProLiant DL360 Gen 10 with a Xeon Bronze 3106 and 16 gigs RAM and 
three hard drives.

Machine B: HP Proliant DL380 Gen 10 with a Xeon Silver 4114 and 32 gigs RAM and 
five hard drives.

I install 12.0-A4 using ZFS on root. I install with 8 gigs of swap but 
otherwise it's a standard FreeBSD install. I can panic these machines rather 
easily in 10-15 minutes by firing up 6 instances of bonnie++ and a few 
memtesters, three using 2g and three using 4g. I've done this on the 11.x 
installs without memtester and gotten panics within 10-15 minutes. Those gave 
me core dumps, but the panic error is different than with 12.0-A4. I have run 
some tests using UFS2 and did not manage to force a panic.

At first I thought the problem was the HPE RAID card which uses the SES driver, 
so I put in a recent LSI MegaRAID card using the MRSAS driver, and can panic 
that as well. I've managed to panic Machine B while it was using either RAID 
card to create two mirrors and one hot spare, and I've managed to panic it when 
letting the RAID cards pass through the hard drives so I could create a raidz 
of 4 drives and one hot spare. I know many people immediately think "Don't use 
a RAID card with ZFS!" but I've done this for years without a problem using the 
LSI MegaRAID in a variety of configurations.

It really seems to me that when ARC starts to ramp up and hits a lot of memory 
contention, a panic occurs. However, I've been running the same test on a 
previous generation NEC server with an LSI MegaRAID using the MRSAS driver 
under 11.2-R and it has been running like clockwork for 11 days. We use this 
iteration of server extensively. If this were a problem with ARC, I assume 
(perhaps presumptuously) that I would see the same problems. I also have 
servers running 11.2-R with ZFS and rather large and very heavily used JBOD 
arrays and have never had an issue.

The HPE RAID card info, from pciconf -lv:

smartpqi0@pci0:92:0:0:  class=0x010700 card=0x0654103c chip=0x028f9005 rev=0x01 
hdr=0x00
vendor = 'Adaptec'
device = 'Smart Storage PQI 12G SAS/PCIe 3'
class  = mass storage
subclass   = SAS

And from dmesg:

root@hvm2d:~ # dmesg | grep smartpq
smartpqi0:  port 0x8000-0x80ff mem 0xe6c0-0xe6c07fff at 
device 0.0 on pci9
smartpqi0: using MSI-X interrupts (40 vectors)
da0 at smartpqi0 bus 0 scbus0 target 0 lun 0
da1 at smartpqi0 bus 0 scbus0 target 1 lun 0
ses0 at smartpqi0 bus 0 scbus0 target 69 lun 0
pass3 at smartpqi0 bus 0 scbus0 target 1088 lun 0
smartpqi0:  port 0x8000-0x80ff mem 0xe6c0-0xe6c07fff at 
device 0.0 on pci9
smartpqi0: using MSI-X interrupts (40 vectors)
da0 at smartpqi0 bus 0 scbus0 target 0 lun 0
da1 at smartpqi0 bus 0 scbus0 target 1 lun 0
ses0 at smartpqi0 bus 0 scbus0 target 69 lun 0
pass3 at smartpqi0 bus 0 scbus0 target 1088 lun 0

However, since I can panic these with either RAID card, I don't suspect the HPE 
RAID card as the culprit.

Here is an image with the scant bt info I got from the last panic:

https://ibb.co/dzFOn9

This thread from Saturday on -stable sounded all too familiar:

https://lists.freebsd.org/pipermail/freebsd-stable/2018-September/089623.html

I'm at a loss so I have gathered as much info as I can to predict questions and 
requests for more info. Hoping someone can point me in the right direction for 
further troubleshooting or at least isolation of the problem to a specific area.

Thanks for your time,

Dave

___
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: testing early microcode loading

2018-09-11 Thread Pete Wright 

On 9/10/18 8:55 PM, Pete Wright wrote:
> On 9/10/18 5:41 PM, Mark Johnston wrote:
>> On Mon, Sep 10, 2018 at 12:48:56PM -0700, Pete Wright wrote:
>>> On 9/10/18 11:26 AM, Mark Johnston wrote:
 Hi,

 Support for boot-time loading of Intel microcode updates has landed in
 the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20.
 I'd like to solicit some testing of the feature ahead of 12.0.
>>> Hey there Mark,
>>> So I've just tested this on a kabylake system running a kernel/world 
>>> from Sept 7th which I believe is recent enough.
>>>
>>> After updating /boot/loader.conf as per your email I am not sure if any 
>>> microcode updates are being applied.  I'm not seeing any messages 
>>> regarding firmware updates being applied in the dmesg buffer.  
>> Right, we currently print something only if an update was configured
>> but failed to apply.  We should probably print something either way,
>> perhaps only if the kernel is booted with -v.
> i could certainly as being helpful for debugging.
>>> running x86info results in the following:
>>>
>>> $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro
>>> Microcode version: 0x008e
>>>
>>> this is after rebooting with the updated loader.conf as well as running 
>>> the rc script by hand.  i didn't think to compare the output of x86info 
>>> before running the rc script, i can do that later today.
>> Thanks.  If the boot-time update succeeded, the rc script should have
>> been a no-op.  Can you check for "updating cpu /dev/cpuctl..." messages
>> in /var/log/messages?  That would indicate that the rc script applied an
>> update, which would imply that the boot-time update failed somehow.
>
> when i ran the rc script after boot i saw the CPU related messages in
> dmesg on the console (CPU count, type, features, etc).  i did not see
> anything in /var/log/messages of interest either.  i'll re-test tomorrow
> when i get back into the office and let you know if i see anything of
> interest.  my plan is to:

ok had time to test during lunch:

> - boot with the /boot/loader.conf additions for applying microcode and
> save the output from x86info

Microcode version: 0x0..48


>
> - boot with loader.conf settings uncommented, view output of x86conf
Microcode version: 0x0...8e
> - then run rc script and get output of x86conf

Microcode version: 0x0..8e


great, so it looks like this is working on my kabylake workstation.  the
only time i see a log entry is when i update the microcode via rc, i do
not see anything when its updated via loader.conf.


cheers,

-pete



-- 
Pete Wright
p...@nomadlogic.org
310.309.9298

___
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"

jail exec.clean busted in 12?

2018-09-11 Thread Michael W. Lucas 


Hi,

storm~;uname -a
FreeBSD storm 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #10 r338496: Thu Sep  6 12:29:00 
EDT 2018 root@storm:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

It appears that exec.clean is busted. Here's my jail.conf:

---

$j="/jail";
path="$j/$name";
host.hostname="$name.mwl.io";

mount.devfs;
exec.clean=0;
exec.start="sh /etc/rc";
exec.stop="sh /etc/rc.shutdown";

loghost {
  ip4.addr="203.0.113.231";
  allow.raw_sockets=1;
  jid=99;
}

logdb {
  host.hostname="logdb.mwl.io";
  ip4.addr="203.0.113.232";
  }

---

exec.clean is not explicitly defined on the command line, but it's the
default, so it maybe shouldn't be?

storm~;jls -n
devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable jid=8 
linux=new name=logdb osreldate=1200084 osrelease=12.0-ALPHA4 parent=0 
path=/jail/logdb nopersist securelevel=-1 sysvmsg=disable sysvsem=disable 
sysvshm=disable vnet=inherit allow.nochflags allow.nomlock allow.nomount 
allow.mount.nodevfs allow.mount.nofdescfs allow.mount.nolinprocfs 
allow.mount.nonullfs allow.mount.noprocfs allow.mount.notmpfs allow.mount.nozfs 
allow.noquotas allow.noraw_sockets allow.reserved_ports allow.set_hostname 
allow.nosocket_af allow.nosysvipc children.cur=0 children.max=0 cpuset.id=6 
host.domainname="" host.hostid=0 host.hostname=logdb.mwl.io 
host.hostuuid=---- ip4.addr=203.0.113.232 
ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux linux.osrelease=2.6.32 
linux.oss_version=198144
devfs_ruleset=0 nodying enforce_statfs=2 host=new ip4=disable ip6=disable 
jid=99 linux=new name=loghost osreldate=1200084 osrelease=12.0-ALPHA4 parent=0 
path=/jail/loghost nopersist securelevel=-1 sysvmsg=disable sysvsem=disable 
sysvshm=disable vnet=inherit allow.nochflags allow.nomlock allow.nomount 
allow.mount.nodevfs allow.mount.nofdescfs allow.mount.nolinprocfs 
allow.mount.nonullfs allow.mount.noprocfs allow.mount.notmpfs allow.mount.nozfs 
allow.noquotas allow.raw_sockets allow.reserved_ports allow.set_hostname 
allow.nosocket_af allow.nosysvipc children.cur=0 children.max=0 cpuset.id=7 
host.domainname="" host.hostid=0 host.hostname=loghost.mwl.io 
host.hostuuid=---- ip4.addr=203.0.113.231 
ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux linux.osrelease=2.6.32 
linux.oss_version=198144

Anyway, I found this by:

# jexec loghost env
HOME=/home/mwlucas
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/mwlucas/bin
TERM=xterm
LC_COLLATE=C
LANG=en_US.UTF-8
SSH_CLIENT=203.0.113.70 59076 22
SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22
SSH_TTY=/dev/pts/2
SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492
LC_CTYPE=en_US.ISO-8859-1
MAIL=/var/mail/root
...

I'm highly confident my SSH environment shouldn't be in the jail. Yes,
it goes away if I add -l, but my (admittedly sketchy) reading of the
jexec source says that jexec handles stripping the environment before
running the command.

Even if I start it the hard way (from a discussion at
https://github.com/iocage/iocage/issues/610)

storm~;jail -c path=/jail/loghost/ host.hostname=loghost exec.clean=1 persist
storm~;jls
   JID  IP Address  Hostname  Path
 9  loghost   /jail/loghost
 
storm~;jexec 9 env | grep -i ssh
SSH_CLIENT=203.0.113.70 59076 22
SSH_CONNECTION=203.0.113.70 59076 203.0.113.50 22
SSH_TTY=/dev/pts/2
SSH_AUTH_SOCK=/tmp/ssh-ZfvZOatcsu/agent.60492
storm~;

Any ideas?

Thanks,
==ml

-- 
Michael W. Lucashttps://mwl.io/
author of: Absolute OpenBSD, SSH Mastery, git commit murder,
Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc...
___
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: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-11 Thread Ed Maste 
On 11 September 2018 at 07:35, Tomoaki AOKI  wrote:
> I prefer releng, rather than stable, to make it default.
> Binary releases requiring reproducible builds are built from
> release and releng branches.

This might be the reasonable long-term strategy, but we don't yet have
experience running through the release process with it enabled. I
would like to enable it by default on the branch, at least initially,
to avoid discovering issues only immediately prior to the release.
___
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"

Upcoming release of V 12

2018-09-11 Thread Jeffrey Bouquet 
I'm running v12 as HEAD [ 12.0-CURRENT]

And am at a loss as to how to change it to 12.0-STABLE vs one day
running  a non-rebuilt 13.0-CURRENT  

Without risking a scenario such as:
   svn up 12.0, fail for some reason to be able to build the GPU driver, so I 
should
   have stuck with svn up 13.0 ??? 
As I've no second machine setup as backup.  due to moving issues. 
 
Background
At present I've various OSVERSION and UNAME_ENV set in make.conf
to work around some type of kernel mismatch issue which prevents otherwise
many ports building.

However it is working seamlessly and I wish it to continue to do so
after the day CURRENT changes from 12 to 13... 

The system was crafted from a thumbdrive ISO so still has 
/mnt/usr/freebsd-dist/base.txz ... 

Otherwise it is all good. 
___
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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context

2018-09-11 Thread Mark Millard 
[Adding listing broken tests, but ignoring sys/cddl/zfs/ ones.
lib/libc/string/memcmp_test:diff is one of them.]

On 2018-Sep-11, at 2:44 AM, Mark Millard  wrote:

> [No zfs use, just a UFS e.MMC filesystem on a microsd adapter.]
> 
> I got 14 failures. I've not enabled any configuration properties.
> 
> I do not know if official devel/kyua tests are part of the head ->
> stable transition for any tier or not. I'm not claiming to know if
> anything here could be a significant issue.
> 
> Someone may want to test an official aarch64 build rather than presume
> that my personal build is good enough. But I expect that its results
> should be strongly suggestive, even if an official tests uses a more
> normal-for-FreeBSD configuration of an aarch64 system.
> 
> The e.MMC is V5.1 is operating in DDR52 mode and is faster than normal
> configurations for the Pine 64+ 2GB. TRIM is in use for the UFS file
> system. This might let some things pass that otherwise would time out.
> 
> 
> ===> Failed tests
> lib/libc/resolv/resolv_test:getaddrinfo_test  ->  failed: 
> /usr/src/lib/libc/tests/resolv/resolv_test.c:299: run_tests(_hostlist_file, 
> METHOD_GETADDRINFO) == 0 not met  [98.834s]
> lib/libc/ssp/ssp_test:vsnprintf  ->  failed: atf-check failed; see the output 
> of the test for details  [0.107s]
> lib/libc/ssp/ssp_test:vsprintf  ->  failed: atf-check failed; see the output 
> of the test for details  [0.105s]
> lib/libproc/proc_test:symbol_lookup  ->  failed: 
> /usr/src/lib/libproc/tests/proc_test.c:143: memcmp(sym, , sizeof(*sym)) 
> != 0  [0.057s]
> lib/msun/trig_test:accuracy  ->  failed: 3 checks failed; see output for more 
> details  [0.013s]
> lib/msun/trig_test:special  ->  failed: 8 checks failed; see output for more 
> details  [0.013s]
> local/kyua/utils/stacktrace_test:dump_stacktrace__integration  ->  failed: 
> Line 391: atf::utils::grep_file("#0", exit_handle.stderr_file().str()) not 
> met  [4.015s]
> local/kyua/utils/stacktrace_test:dump_stacktrace__ok  ->  failed: Line 420: 
> atf::utils::grep_file("^frame 1$", exit_handle.stderr_file().str()) not met  
> [4.470s]
> local/kyua/utils/stacktrace_test:dump_stacktrace_if_available__append  ->  
> failed: Line 560: atf::utils::grep_file("frame 1", 
> exit_handle.stderr_file().str()) not met  [4.522s]
> local/kyua/utils/stacktrace_test:find_core__found__long  ->  failed: Core 
> dumped, but no candidates found  [3.988s]
> local/kyua/utils/stacktrace_test:find_core__found__short  ->  failed: Core 
> dumped, but no candidates found  [4.014s]
> sys/kern/ptrace_test:ptrace__PT_STEP_with_signal  ->  failed: 
> /usr/src/tests/sys/kern/ptrace_test.c:3465: WSTOPSIG(status) == SIGABRT not 
> met  [0.017s]
> usr.bin/indent/functional_test:nsac  ->  failed: atf-check failed; see the 
> output of the test for details  [0.151s]
> usr.bin/indent/functional_test:sac  ->  failed: atf-check failed; see the 
> output of the test for details  [0.150s]
> ===> Summary
> Results read from 
> /root/.kyua/store/results.usr_tests.20180911-070147-413583.db
> Test cases: 7301 total, 212 skipped, 37 expected failures, 116 broken, 14 
> failed
> Total time: 6688.125s
> 
> 
> 
> 
> I'll note that the console reported over 73720 messages like (with figures
> where I've listed 's):
> 
> md.eli: Failed to authenticate  bytes of data at offset .
> 
> There are also device created and destroyed/removed notices with related
> material. Overall there were over 84852 lines reported with "GEOM_ELI:"
> on the line.
> 
> This did not prevent tests from passing.
> 
> (The huge console output is unfortunate in my view: it makes finding
> interesting console messages a problem  while watching messages
> go by.)
> 
> 
> 
> I did get the console message block:
> 
> kern.ipc.maxpipekva exceeded; see tuning(7)
> Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
> Sep 11 01:36:25 pine64 kernel: nd6_dad_timer: called with non-tentative 
> address (epair2Freed UMA keg (rtentry) was not empty (18 items).  
> Lost 1 pages of memory.
> a)
> Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
> Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
> Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
> Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
> Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
> Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
> Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
> Freed UMA keg (rten

Re: Request for Review: Generate /etc/services from the IANA registry

2018-09-11 Thread Eric van Gyzen 

On 9/11/18 10:04 AM, Steffen Nurpmeso wrote:

Alan Somers wrote in :
  |Don't worry Steffen.  Python won't be a build requirement for FreeBSD \
  |even after Eric's patch.  His Python script will only need to be run \
  |whenever IANA
  |updates its database, and the results will be checked into source contro\
  |l.  So for a normal user, there is no change to "make buildworld && make
  |installworld".

I cannot, unfortunately.  I use binary updates and even
preinstalled VM images (thanks for that, by the way).


So there will be no impact on you at all, except that /etc/services will 
have a lot more services.  As Alan said, Python and XML will only be 
added to the developer workflow.



  |As for Python vs Awk, I too tried to do this with Awk.  However, Awk \
  |can't easily handle things like IANA's representation of aliases, and \
  |it can't
  |easily format the list in the same order as our current list.  Python \
  |is truly a better choice.

I absolutely fail to see what you mean.  The script (which is in
actual use, mind you) generates the desired output except that
comments get lost, but this could be added upon interest, of
course.  It (or a derivative) would have been a good candidate for
/usr/share/misc/ in elder times i guess, too.


That awk script depends on the formatting of the XML file.  It will 
break if the IANA decides to format it differently.  Granted, this is 
unlikely, but it's possible.


Also, that script would become much more complex if it supported local 
additions and overrides, which are unfortunately necessary in our case.


Eric
___
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: Request for Review: Generate /etc/services from the IANA registry

2018-09-11 Thread Steffen Nurpmeso 
Alan Somers wrote in :
 |Don't worry Steffen.  Python won't be a build requirement for FreeBSD \
 |even after Eric's patch.  His Python script will only need to be run \
 |whenever IANA 
 |updates its database, and the results will be checked into source contro\
 |l.  So for a normal user, there is no change to "make buildworld && make 
 |installworld".

I cannot, unfortunately.  I use binary updates and even
preinstalled VM images (thanks for that, by the way).

 |As for Python vs Awk, I too tried to do this with Awk.  However, Awk \
 |can't easily handle things like IANA's representation of aliases, and \
 |it can't 
 |easily format the list in the same order as our current list.  Python \
 |is truly a better choice.

I absolutely fail to see what you mean.  The script (which is in
actual use, mind you) generates the desired output except that
comments get lost, but this could be added upon interest, of
course.  It (or a derivative) would have been a good candidate for
/usr/share/misc/ in elder times i guess, too.

 |-Alan

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
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: testing early microcode loading

2018-09-11 Thread Mark Johnston 
On Tue, Sep 11, 2018 at 10:20:56AM +0200, Andrea Venturoli wrote:
> On 9/10/18 8:26 PM, Mark Johnston wrote:
> > Hi,
> > 
> > Support for boot-time loading of Intel microcode updates has landed in
> > the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20.
> 
> Thanks for your work.
> Altough I cannot test it yet, I appreciate it.
> 
> Just one question: what about AMD?
> Is support for this brand coming in the future?
> Is it impossible for some reason?

I do plan to work on it:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231024
___
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: how to enforce one version of python

2018-09-11 Thread Baptiste Daroussin 
On Tue, Sep 11, 2018 at 03:28:15PM +0100, tech-lists wrote:
> Hi,
> 
> There are a number of ports that seem to have their own preferential flavour
> of python, and some for example want to install python27 and python36 in the
> same place, and it's a pain when using portupgrade or similar tools.
> 
> I have this in my /etc/make.conf:
> 
> DEFAULT_VERSIONS+= python=2.7
> 
> Is this incorrect? I assume it must be, as for example devel/pylint
> (pylint-py27-1.9.2) wants to upgrade to pylint-py36-2.1.1
> 
That is because portupgrade is not flavor aware (or badly if it has been patched
to support flavors)

Best regards,
Bapt


signature.asc
Description: PGP signature

how to enforce one version of python

2018-09-11 Thread tech-lists 

Hi,

There are a number of ports that seem to have their own preferential 
flavour of python, and some for example want to install python27 and 
python36 in the same place, and it's a pain when using portupgrade or 
similar tools.


I have this in my /etc/make.conf:

DEFAULT_VERSIONS+= python=2.7

Is this incorrect? I assume it must be, as for example devel/pylint 
(pylint-py27-1.9.2) wants to upgrade to pylint-py36-2.1.1


thanks,
--
J.
___
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: Request for Review: Generate /etc/services from the IANA registry

2018-09-11 Thread Alan Somers 
Don't worry Steffen.  Python won't be a build requirement for FreeBSD even
after Eric's patch.  His Python script will only need to be run whenever
IANA updates its database, and the results will be checked into source
control.  So for a normal user, there is no change to "make buildworld &&
make installworld".

As for Python vs Awk, I too tried to do this with Awk.  However, Awk can't
easily handle things like IANA's representation of aliases, and it can't
easily format the list in the same order as our current list.  Python is
truly a better choice.

-Alan

On Tue, Sep 11, 2018 at 8:19 AM Steffen Nurpmeso  wrote:

> Eric van Gyzen wrote in <59cd421e-f5d4-855a-83ec-65726f792...@vangyzen.net
> >:
>  |On 9/10/18 12:04 PM, Eric van Gyzen wrote:
>  |> Would anyone like to review this change to generate /etc/services from
>  |> the IANA registry?
>  |>
>  |>  https://reviews.freebsd.org/D17106
>  |
>  |If that review made your browser unhappy, try this one instead:
>
> Yes it did.
>
>  | https://reviews.freebsd.org/D17115
>
> I mean, i have nothing to do with FreeBSD except that i use it
> since 4.7 (though some yours only indirectly as Mac OS X), and
> i am in opposition to quite some directions taken, but who am i,
> that is ok, i have a very narrow use case.  But this is one of the
> things i really do not understand, bringing XML and Python stuff
> needlessly into FreeBSD seems very odd.  For example, ArchLinux
> and CRUX Linux use a simple portable awk script to generate
> services and protocols, and all you need to count the number of
> services is a normal Unix pipeline which strips comments and then
> calls wc -l.  I'll paste the script below this.  Thank you.
> And ciao already here
>
> #!/bin/sh -
> #@ Update protocols and services from IANA.
> #@ Taken from ArchLinux script written by Gaetan Bisson.  Adjusted for
> CRUX.
>
> awk=awk
> curl=curl
> url_pn=
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
> url_snpn=https://www.iana.org/assignments/service-names-port-numbers/\
> service-names-port-numbers.xml
> 
>
> datetime=`date +'%FT%T%z'`
>
> download() {
>echo 'Downloading protocols'
>${curl} -o protocols.xml ${url_pn}
>[ ${?} -eq 0 ] || exit 20
>echo 'Downloading services'
>${curl} -o services.xml ${url_snpn}
>[ ${?} -eq 0 ] || exit 21
> }
>
> process() {
>echo 'Processing protocols'
>${awk} -F "[<>]" -v URL="${url_pn}" -v DT="${datetime}" '
>   BEGIN{
>  print "# /etc/protocols, created " DT
>  print "# Source: " URL
>   }
>   /   /   /   /<\/record/ && n && v != ""{
>  printf "%-12s %3i %s\n", tolower(n), v, n
>   }
>' < protocols.xml > protocols.new
>[ ${?} -eq 0 ] || exit 30
>
>echo 'Processing services'
>${awk} -F "[<>]" -v URL="${url_snpn}" -v DT="${datetime}" '
>   BEGIN{
>  print "# /etc/services, created " DT
>  print "# Source: " URL
>   }
>   /   /   /   /   /Unassigned/ || /Reserved/ || /historic/ {c = 1}
>   /<\/record/ && n && u && p && !c{
>  printf "%-15s %5i/%s\n", n, u, p
>   }
>' < services.xml > services.new
>[ ${?} -eq 0 ] || exit 31
> }
>
> update() {
>mv protocols.new protocols
>[ ${?} -eq 0 ] || exit 40
>mv services.new services
>[ ${?} -eq 0 ] || exit 41
>rm -f protocols.xml services.xml
> }
>
> download
> process
> #update
>
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> ___
> 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: Request for Review: Generate /etc/services from the IANA registry

2018-09-11 Thread Steffen Nurpmeso 
Eric van Gyzen wrote in <59cd421e-f5d4-855a-83ec-65726f792...@vangyzen.net>:
 |On 9/10/18 12:04 PM, Eric van Gyzen wrote:
 |> Would anyone like to review this change to generate /etc/services from 
 |> the IANA registry?
 |> 
 |>  https://reviews.freebsd.org/D17106
 |
 |If that review made your browser unhappy, try this one instead:

Yes it did.

 | https://reviews.freebsd.org/D17115

I mean, i have nothing to do with FreeBSD except that i use it
since 4.7 (though some yours only indirectly as Mac OS X), and
i am in opposition to quite some directions taken, but who am i,
that is ok, i have a very narrow use case.  But this is one of the
things i really do not understand, bringing XML and Python stuff
needlessly into FreeBSD seems very odd.  For example, ArchLinux
and CRUX Linux use a simple portable awk script to generate
services and protocols, and all you need to count the number of
services is a normal Unix pipeline which strips comments and then
calls wc -l.  I'll paste the script below this.  Thank you.
And ciao already here

#!/bin/sh -
#@ Update protocols and services from IANA.
#@ Taken from ArchLinux script written by Gaetan Bisson.  Adjusted for CRUX.

awk=awk
curl=curl
url_pn=https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
url_snpn=https://www.iana.org/assignments/service-names-port-numbers/\
service-names-port-numbers.xml

datetime=`date +'%FT%T%z'`

download() {
   echo 'Downloading protocols'
   ${curl} -o protocols.xml ${url_pn}
   [ ${?} -eq 0 ] || exit 20
   echo 'Downloading services'
   ${curl} -o services.xml ${url_snpn}
   [ ${?} -eq 0 ] || exit 21
}

process() {
   echo 'Processing protocols'
   ${awk} -F "[<>]" -v URL="${url_pn}" -v DT="${datetime}" '
  BEGIN{
 print "# /etc/protocols, created " DT
 print "# Source: " URL
  }
  / protocols.new
   [ ${?} -eq 0 ] || exit 30

   echo 'Processing services'
   ${awk} -F "[<>]" -v URL="${url_snpn}" -v DT="${datetime}" '
  BEGIN{
 print "# /etc/services, created " DT
 print "# Source: " URL
  }
  / services.new
   [ ${?} -eq 0 ] || exit 31
}

update() {
   mv protocols.new protocols
   [ ${?} -eq 0 ] || exit 40
   mv services.new services
   [ ${?} -eq 0 ] || exit 41
   rm -f protocols.xml services.xml
}

download
process
#update

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
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: make packages fails recent -current

2018-09-11 Thread Andreas Nilsson 
On Mon, Sep 10, 2018 at 5:55 PM Mikaël Urankar 
wrote:

> 2018-09-10 17:45 GMT+02:00 Andreas Nilsson :
>
>> Hello,
>>
>> I have for about a week been trying to get new (base)packages built. make
>> buildworld/buildkernel works as expected, however make packages has been
>> failing:
>>
>> ===> Creating FreeBSD-runtime-12.0.s20180910124534
>> pkg: duplicate directory listing: /boot, ignoring
>> pkg: duplicate directory listing: /etc, ignoring
>> ...
>> pkg: duplicate directory listing: /etc/syslog.d, ignoring
>> pkg: duplicate directory listing: /root, ignoring
>> pkg: duplicate directory listing: /root, ignoring
>> pkg: duplicate directory listing: /root, ignoring
>> pkg: Plist error, @config /root/.cshrc: not a regular file
>> pkg: Plist error, @config /root/.profile: not a regular file
>> pkg: duplicate file listing: /usr/bin/zstdegrep, ignoring
>> pkg: duplicate directory listing: /usr/lib, ignoring
>> pkg: duplicate directory listing: /usr/lib/dtrace, ignoring
>> pkg: duplicate directory listing: /usr/lib/dtrace, ignoring
>> pkg: duplicate directory listing: /usr/lib32, ignoring
>> ...
>>
>> Is anyone else seeing this? This is on git 4e22ee37542 . I use metamode
>> for
>> building. I'm currently building from scratch just to rule out metamode.
>>
>
> See
> https://lists.freebsd.org/pipermail/freebsd-pkgbase/2018-September/000383.html
>

Thanks, that would explain it. Although even after installing
pkg-devel-1.10.99.8 it still fails. Guess I'll have to wait for it to
trickle into the packages.

Best regards
Andreas
___
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: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-11 Thread Tomoaki AOKI 
I prefer releng, rather than stable, to make it default.
Binary releases requiring reproducible builds are built from
release and releng branches.


On Mon, 10 Sep 2018 10:56:14 -0400
Ed Maste  wrote:

> The FreeBSD base system is a reproducible build[1] with a minor
> exception: the build metadata (timestamps, user, hostname, etc.)
> included in the kernel and loader.
> 
> With the default, non-reproducible build the kernel ident looks like:
> 
> FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018
>user@hostname:/path/to/freebsd/src
> 
> and the loader ident:
> 
> FreeBSD/amd64 EFI loader, Revision 1.1
> (Mon Jan 1 10:11:12 EDT 2018 user@hostname)
> 
> With reproducible builds enabled the kernel ident looks like:
> 
> FreeBSD 12.0-ALPHA5  r338195
> 
> and the loader ident:
> 
> FreeBSD/amd64 EFI loader, Revision 1.1
> 
> I would like to enable the REPRODUCIBLE_BUILD knob by default for the
> 12.0 release, and propose we do this by adding a step to switch the
> default to the list of changes[2] that re@ commits to the branch as
> part of the release process.
> 
> [1] https://reproducible-builds.org
> [2] 
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/releng-head.html
> ___
> 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"
> 


-- 
Tomoaki AOKI
___
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"

Poudriere

2018-09-11 Thread Nathan Owens 
Submitting this here as I believe this may be best place to ask the question as 
I use poudriere to test ports before sending patches
I am on 12 current. If I’m building a port that can use either py27 or py36 on 
an non x86based system the py27 works fine on all my jails. If I test with py36 
poudriere errors out saying a file touched my FS during build and it actually 
does install a file on my FS as I can delete the file it refers to and retry 
build and it will be there again. The FS violation happens on my 
mips/mips64/armv6/arm64/ poudriere jails with py36. To try something I forced 
it to use py37 and it does the same. 
I’ve created a new arch jail with new name and it happens on fresh jail install 
as well. I’ve disabled ccache and that didn’t fix the issue either 


Sent from Yahoo Mail for iPhone
___
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"

FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context

2018-09-11 Thread Mark Millard 
[No zfs use, just a UFS e.MMC filesystem on a microsd adapter.]

I got 14 failures. I've not enabled any configuration properties.

I do not know if official devel/kyua tests are part of the head ->
stable transition for any tier or not. I'm not claiming to know if
anything here could be a significant issue.

Someone may want to test an official aarch64 build rather than presume
that my personal build is good enough. But I expect that its results
should be strongly suggestive, even if an official tests uses a more
normal-for-FreeBSD configuration of an aarch64 system.

The e.MMC is V5.1 is operating in DDR52 mode and is faster than normal
configurations for the Pine 64+ 2GB. TRIM is in use for the UFS file
system. This might let some things pass that otherwise would time out.


===> Failed tests
lib/libc/resolv/resolv_test:getaddrinfo_test  ->  failed: 
/usr/src/lib/libc/tests/resolv/resolv_test.c:299: run_tests(_hostlist_file, 
METHOD_GETADDRINFO) == 0 not met  [98.834s]
lib/libc/ssp/ssp_test:vsnprintf  ->  failed: atf-check failed; see the output 
of the test for details  [0.107s]
lib/libc/ssp/ssp_test:vsprintf  ->  failed: atf-check failed; see the output of 
the test for details  [0.105s]
lib/libproc/proc_test:symbol_lookup  ->  failed: 
/usr/src/lib/libproc/tests/proc_test.c:143: memcmp(sym, , sizeof(*sym)) != 
0  [0.057s]
lib/msun/trig_test:accuracy  ->  failed: 3 checks failed; see output for more 
details  [0.013s]
lib/msun/trig_test:special  ->  failed: 8 checks failed; see output for more 
details  [0.013s]
local/kyua/utils/stacktrace_test:dump_stacktrace__integration  ->  failed: Line 
391: atf::utils::grep_file("#0", exit_handle.stderr_file().str()) not met  
[4.015s]
local/kyua/utils/stacktrace_test:dump_stacktrace__ok  ->  failed: Line 420: 
atf::utils::grep_file("^frame 1$", exit_handle.stderr_file().str()) not met  
[4.470s]
local/kyua/utils/stacktrace_test:dump_stacktrace_if_available__append  ->  
failed: Line 560: atf::utils::grep_file("frame 1", 
exit_handle.stderr_file().str()) not met  [4.522s]
local/kyua/utils/stacktrace_test:find_core__found__long  ->  failed: Core 
dumped, but no candidates found  [3.988s]
local/kyua/utils/stacktrace_test:find_core__found__short  ->  failed: Core 
dumped, but no candidates found  [4.014s]
sys/kern/ptrace_test:ptrace__PT_STEP_with_signal  ->  failed: 
/usr/src/tests/sys/kern/ptrace_test.c:3465: WSTOPSIG(status) == SIGABRT not met 
 [0.017s]
usr.bin/indent/functional_test:nsac  ->  failed: atf-check failed; see the 
output of the test for details  [0.151s]
usr.bin/indent/functional_test:sac  ->  failed: atf-check failed; see the 
output of the test for details  [0.150s]
===> Summary
Results read from /root/.kyua/store/results.usr_tests.20180911-070147-413583.db
Test cases: 7301 total, 212 skipped, 37 expected failures, 116 broken, 14 failed
Total time: 6688.125s




I'll note that the console reported over 73720 messages like (with figures
where I've listed 's):

md.eli: Failed to authenticate  bytes of data at offset .

There are also device created and destroyed/removed notices with related
material. Overall there were over 84852 lines reported with "GEOM_ELI:"
on the line.

This did not prevent tests from passing.

(The huge console output is unfortunate in my view: it makes finding
interesting console messages a problem  while watching messages
go by.)



I did get the console message block:

kern.ipc.maxpipekva exceeded; see tuning(7)
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Sep 11 01:36:25 pine64 kernel: nd6_dad_timer: called with non-tentative address 
(epair2Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 
pages of memory.
a)
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.
Freed UMA keg (rtentry) was not empty (18 items).  Lost 1 pages of memory.

But no failure reports seemed to be associated.

Still, I wo

TCP RACK performance

2018-09-11 Thread Chenyang Zhong 
Hi,

I am really excited to see that @rrs from Netflix is adding TCP RACK
and High Precision Timer System to the kernel, so I built a kernel
(r338543) and ran some test.

I used the following kernel config, as suggested in commit rS334804.

makeoptions WITH_EXTRA_TCP_STACKS=1
options TCPHPTS

After booting the new kernel, I loaded the tcp_rack.ko,
# kldload tcp_rack

and checked the sysctl to make sure rack is there.
# sysctl net.inet.tcp.functions_available
net.inet.tcp.functions_available:
Stack   D AliasPCB count
freebsd * freebsd  3
rack  rack 0

I ran the first test with the default stack. I was running iperf3 over
a wireless network where rtt was fluctuating but no packet loss. Here
is a ping result summary. The average and stddev of rtt is relatively
high.

39 packets transmitted, 39 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.920/40.206/124.094/39.093 ms

Here is the iperf3 result of a 30-second benchmark.

[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-30.00  sec   328 MBytes  91.8 Mbits/sec   62 sender
[  5]   0.00-30.31  sec   328 MBytes  90.9 Mbits/sec  receiver

Then I switched to the new RACK stack.
# sysctl net.inet.tcp.functions_default=rack
net.inet.tcp.functions_default: freebsd -> rack

There was a 10% - 15% performance loss after running the same iperf3
benchmark. Also, the number of retransmissions increased dramatically.

[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-30.00  sec   286 MBytes  79.9 Mbits/sec  271 sender
[  5]   0.00-30.30  sec   286 MBytes  79.0 Mbits/sec  receiver

I then ran iperf3 on a Linux machine with kernel 4.15, which uses RACK
by default. I verified that through sysctl:

# sysctl net.ipv4.tcp_recovery
net.ipv4.tcp_recovery = 1

The iperf3 result showed the same speed with the default freebsd
stack, and the number of retransmission matched the RACK stack on
freebsd.

[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-30.00  sec   330 MBytes  92.3 Mbits/sec  270 sender
[  4]   0.00-30.00  sec   329 MBytes  92.1 Mbits/sec  receiver

I am not sure whether the performance issue is related to my
configuration or to the new implementation of RACK on FreeBSD. I am
glad to offer more information if anyone is interested. Thanks again
for all the hard work. I cannot wait to see TCP BBR on FreeBSD.

Best,
Chenyang
___
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: testing early microcode loading

2018-09-11 Thread Andrea Venturoli 

On 9/10/18 8:26 PM, Mark Johnston wrote:

Hi,

Support for boot-time loading of Intel microcode updates has landed in
the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20.


Thanks for your work.
Altough I cannot test it yet, I appreciate it.

Just one question: what about AMD?
Is support for this brand coming in the future?
Is it impossible for some reason?

 bye & Thanks
av.
___
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"