Re: bhyve fopen failure

[Conrad Meyer]

Hi Chuck,

In capability mode (capsicum sandbox), files like this need to be opened
before bhyve enters sandboxed mode.  (That’s ‘cap_enter()’.)

Best,
Conrad

On Tue, Mar 2, 2021 at 09:31 Chuck Tuffli  wrote:

> I'm porting some code to bhyve and am getting a failure I don't
> understand. This is git as of af11c2029006 FWIW.
>
> The code in question is for an emulated device and looks like:
> dbg = fopen("/tmp/bhyve_ata.log", "w+");
> if (dbg == NULL)
> perror("fopen");
>
> Running this fails with:
> fopen: Not permitted in capability mode
> Googling suggests this might be capsicum related. If so, what do I
> need to change to allow writes to a debug file?
>
> --chuck
> ___
> 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: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Conrad Meyer]

Typo:

On Mon, Jan 4, 2021 at 5:25 PM Conrad Meyer  wrote:
> SHA1 has always, by design, been vulnerable to a 2^80 resource attack :-).

2^160 for a specific hash.  2^80 if you're just trying to find any collision.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Conrad Meyer]

On Mon, Jan 4, 2021 at 1:44 PM Ryan Stone  wrote:
> FWIW, a coworker of mine had a little hobby of introducing commits
> into our internal repro that had hashes that all started with
> deadc0de.  As I understand it, it was able to do this by adding an
> bogus attribute with the right value to the commit object.

Yeah, the git commit object is essentially text with some headers, and
the git tools are all permissive of unrecognized headers.  You can
create a "visually identical" commit (same commit message, parent
commit(s), author/committer/dates, etc) by just adding an extra header
with an arbitrary value and brute force on that value to find a vanity
prefix.  This isn't anything related to the SHA1 attacks, it's just
brute-forcing the output of a truncated SHA1 to a 1-in-2^32 result.

E.g., https://github.com/cemeyer/gitbrutec does it by injecting a
header named "x-gitbrutec-nonce."

$ git cat-file -p 009
tree 4e778673b8af45ecd4c62e8b1d1438d06db7f440
parent 0080b4fc4c2066fa05641e73d5f0985c15ea
author Conrad Meyer  1590357489 -0700
committer Conrad Meyer  1590357489 -0700
x-gitbrutec-nonce YYZSKGIQCLLXGE

Use 'git update-ref' in post-commit example
...

> Now,
> brute-forcing 8 digits in the hash is one thing and doing it for all
> 40 is quite another, but I suspect that this demonstrates that it's
> *possible* to do it for a git hash, given enough computing resources.

SHA1 has always, by design, been vulnerable to a 2^80 resource attack :-).

Best,
Conrad
___
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: rand() is racy in multi-threaded programs?

[Conrad Meyer]

Hi Andriy,

On Wed, Dec 2, 2020 at 11:34 PM Andriy Gapon  wrote:
>
> On 03/12/2020 01:20, Conrad Meyer wrote:
> > Rand(3) is explicitly unsafe to use from concurrent threads without some
> > external serialization, even after initialization. I’d suggest using a 
> > different
> > API.
>
> thank you!
> Just want to check, unsafe in terms of bogus results (with respect to
> randomness) or unsafe as in may crash?

Well, unsafe in that it's a data race, which is formally undefined
behavior in C (if I understand correctly).  So anything could happen,
including a crash.  In practice, you would probably see something more
like the former (bogus results, e.g., multiple calls returning the
same number because the state wasn't updated atomically, or something
like that) rather than a crash.

Best,
Conrad
___
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: rand() is racy in multi-threaded programs?

[Conrad Meyer]

Hi Andriy,

Rand(3) is explicitly unsafe to use from concurrent threads without some
external serialization, even after initialization. I’d suggest using a
different API.

Best,
Conrad

On Wed, Dec 2, 2020 at 13:53 Andriy Gapon  wrote:

>
> Specifically, concurrent "first" calls to rand().
> There can be a moment when rand3_state is allocated but not completely set
> up
> with initstate_r().
> Is this a known / documented issue?
> Should we try to do better?
>
> P.S.
> I am seeing this issue from time to time when running ztest program (from
> ZFS).
> I guess that it uses rand() just because that's what OpenZFS did / does on
> illumos and Linux.
>
> P.P.S.
> Just realized that the problem can be relatively recent.
> https://svnweb.freebsd.org/base?view=revision=357382
>
> --
> Andriy Gapon
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: iflib/bridge kernel panic

[Conrad Meyer]

Hi Shawn,

Is it possible to reproduce the issue on FreeBSD?  The excerpt you've
linked to is not on FreeBSD.

Conrad

On Sun, Sep 20, 2020 at 5:53 PM Shawn Webb  wrote:
>
> From latest HEAD on a Dell Precision 7550 laptop:
>
> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2
>
> The last working boot environment was 14 Aug 2020. If I get some time to
> bisect commits, I'll try to figure out the culprit.
>
> Thanks,
>
> Shawn Webb
>
> (Sorry for the brevity. Only partially working system due to above
> breakage.)
> ___
> 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: To people upgrading from before r363679

[Conrad Meyer]

The problem identified in Warner's email was fixed in r364030, so an
easy solution is updating from r363678 or earlier directly to r364030
or later.

Best,
Conrad

On Mon, Aug 10, 2020 at 3:20 AM Dennis Clarke  wrote:
>
> On 8/5/20 9:19 PM, Warner Losh wrote:
> > If you are upgrading across r363679, you may have installworld fail, as
> > documented in UPDATING.
> >
> > I have a fix (that requires a trip through buildworld) that's under review
> > at https://reviews.freebsd.org/D25967 . The changes are likely good, but
> > comments likely need updating.
> >
> > The short version is that we purposely use old libraries to install the
> > system. We created a symbolic link to a bunch of binaries on the system and
> > once installworld installs one of them, we get the error. The workaround
> > works because we copy libc.so before doing the installworld, so now we're
> > running with a new libc.so with new binaries, which works. My fix always
> > copies and never symlinks. The symbolic link stuff is too fragile.
> >
> > With it, I've done one system, but I'd appreciate reports (on the code
> > review if possible, to me in email if not) of people who have success
> > upgrading with this. If you've already run installworld and hit the
> > undefined symbol, it's too late for you to help me test (since re-running
> > is the same as hitting to test is the same as the workaround and so it will
> > work even if my workaround is busted).
> >
> > Some history: This was introduced about 2 years ago. Prior to that, we
> > always copied binaries for the install.
>
> This will fix the situation :
>
> triton$
> triton$ cat /usr/src/my.patch
> ...
___
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: routed && route6d removal proposal

[Conrad Meyer]

Sounds good to me.  We don't need a RIP daemon in base, and if needed,
it is just a pkg install away via one of the myrriad maintained
routing daemons.

Thanks,
Conrad

On Sun, Jun 21, 2020 at 4:06 PM Alexander V. Chernikov
 wrote:
>
> Hey,
>
> I would like to propose removal of  sbin/routed and usr.sbin/route6d.
>
> routed(8) is the daemon implementing RIPv2 routing protocol.
> route6d(8) is the daemon implementing RIPng routing protocol for IPv6.
>
> RIP [1] was one of the first  protocols used in the networking. The first 
> version was implemented back in 1982.
>
> 1. Network landscape has changed since then. BGP, OSPF, IS-ISIS and other 
> routing protocols have been created and greatly improved over years. People 
> have created and adopted numerous designs leveraging OSPF/ISIS or BGP.
> RIP became obsolete a while ago as there were no competitive advantage it can 
> offer.
> "It is the oldest routing protocol used by the network industry and is 
> considered by many to be inefficient or border-line obsolete." — [2], 2009
> "Today, the only reason you might run across a network running RIPv2 is 
> either that the network is very old and in serious need of an upgrade or the 
> network is running cheaper, consumer-grade routing hardware that can only 
> support RIP" — [3], 2016.
>
> 1.1. Nowadays the daemon name is simply misleading. Given situation described 
> above, one does expect far wider functionality from the program named 
> "route[6]d" than just  RIP implementation.
>
> 2. Multiple routing stacks supporting all major routing protocol including 
> RIP exists these days: bird, frr, quagga. Many BGP-only designs in are 
> gaining popularity, so do bgp speakers such as exabgp or gobgp.  Nowadays, if 
> one needs dynamic routing on the host, OSPF or BGP speaker is the choice. 
> FreeBSD packages contains well-maintained ports for these. Having RIP[ng] 
> speakers in base offers no advantage.
>
> 3. Both routed/route6d are largely unmaintained [4] and presents an 
> additional attack vector. Here is the list of last non-trivial commits to 
> routed/route6d:
>
> sbin/routed:
> r327276 - coverity
> r317035 - rtsock fix
> r299825 - coverity
> r299822 - coverity, from netbsd
> r299821 - coverity, from netbsd
> r299784 - coverity, from netbsd
> r299771 - coverify, from netbsd
> r286347 - bugfix
> r276602 - SA14:21 patch
> r271919 - SA14:21 fix
> r215702 - logic fix, 2010
>
> usr.sbin/route6d:
> r337500 - functional fix, 2018
> r317035 - rtsock fix
> r311994 - coverity
> r311985 - coverity
> r299869 - coverity
> r299491 - coverity
> r270234 - link-local fix
> r243233 - functionality improvement, 2012
>
> To summarise: RIP protocol is obsolete, implementations for newer protocols 
> exists in ports,  implementation in base  is unmaintained.
>
> With all that in mind I propose to remove routed and route6d from base in 
> FreeBSD 13.
> Timeline:
> June 5 - feedback aggregation and decision point
> July 19 - removal (proposed)
>
>
> [1] https://en.wikipedia.org/wiki/Routing_Information_Protocol
> [2] 
> https://www.globalknowledge.com/ca-en/resources/resource-library/articles/basics-of-understanding-rip/
> [3] 
> https://www.networkcomputing.com/data-centers/comparing-dynamic-routing-protocols
> [4] 
> https://bugs.freebsd.org/bugzilla/buglist.cgi?cmdtype=runnamed_id=361897=routed_prs
>
> /Alexander
> ___
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-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: HEADSUP: GEOM label may be broken [Was Re: svn commit: r361838 - in head/sys/geom: . label]

[Conrad Meyer]

# geli attach /dev/gpt/testingeli
Enter passphrase:
GEOM_ELI: Device md0s1.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI: Crypto: software
GEOM_LABEL[2]: Tasting md0s1.eli.
# ls -l /dev/gpt/testingeli*
lrwxr-xr-x 1 root wheel  8 Jun  6 09:22 /dev/gpt/testingeli -> ../md0s1
lrwxr-xr-x 1 root wheel 12 Jun  6 09:24 /dev/gpt/testingeli.eli -> ../md0s1.eli

https://reviews.freebsd.org/D25168

On Sat, Jun 6, 2020 at 8:52 AM Conrad Meyer  wrote:
>
> Hi Xin Li,
>
> Thank you for the report and diagnosis.  Sorry for the breakage.
>
> I have reverted the change and hope to address the issues you have identified.
>
> There seem to be two issues identified:
> 1. When ZFS attaches to a partition of a disk, the /dev/diskid label 
> disappears.
> 2. geli(8) attach of symlink labels doesn't work
>
> (1) is interesting, as it does not seem to happen to UFS or swap consumers:
>
> # mount
> /dev/gpt/rootfs on / (ufs, local, noatime, soft-updates)
> # swapctl -l
> Device:   1024-blocks Used:
> /dev/vtbd0p21048576 0
> # ls -l /dev/diskid/DISK-BHYVE-2613-8EFD-BAF4 /dev/gpt/{rootfs,swapfs}
> lrwxr-xr-x 1 root wheel  8 May 22 20:18
> /dev/diskid/DISK-BHYVE-2613-8EFD-BAF4 -> ../vtbd0
> lrwxr-xr-x 1 root wheel 10 May 22 20:18 /dev/gpt/rootfs -> ../vtbd0p3
> lrwxr-xr-x 1 root wheel 10 May 22 20:18 /dev/gpt/swapfs -> ../vtbd0p2
>
> I wonder what is different in the ZFS case here.
>
> (2)
>
> # ls -l /dev/gpt/testingeli
> lrwxr-xr-x 1 root wheel 8 Jun  6 08:33 /dev/gpt/testingeli -> ../md0s1
> # geli init /dev/gpt/testingeli
> Enter new passphrase:
> Reenter new passphrase:
> ...
> # geli attach /dev/gpt/testingeli
> Enter passphrase:
> geli: Provider gpt/testingeli is invalid.
> geli: There was an error with at least one provider.
>
> So at least the latter problem is straightforward to resolve.  I have
> a patch I'm testing locally now, and will upload to phabricator
> shortly.
>
> Best regards,
> Conrad
>
>
> On Sat, Jun 6, 2020 at 1:17 AM Xin Li  wrote:
> >
> > I just spent quite some time to revive my laptop.  TL;DR: if you are
> > using /dev/diskid or /dev/gptid labels and GELI, please wait until
> > things settled.
> >
> > ===
> >
> > On 6/5/20 9:12 AM, Conrad Meyer wrote:
> > > Author: cem
> > > Date: Fri Jun  5 16:12:21 2020
> > > New Revision: 361838
> > > URL: https://svnweb.freebsd.org/changeset/base/361838
> > >
> > > Log:
> > >   geom_label: Use provider aliasing to alias upstream geoms
> > >
> > >   For synthetic aliases (just pseudonyms inferred from metadata like GPT 
> > > or
> > >   UFS labels, GPT UUIDs, etc), use the GEOM provider aliasing system to 
> > > create
> > >   a symlink to the real device instead of creating an independent device.
> > >   This makes it more clear which labels and devices correspond, and we can
> > >   safely have multiple labels to a single device accessed at once.
> > >
> > >   The confusingly named geom_label on-disk construct continues to behave
> > >   identically to how it did before.
> > >
> > >   This requires teaching GEOM's provider aliasing about the possibility
> > >   that aliases might be added later in time, and GEOM's devfs interaction
> > >   layer not to worry about existing aliases during retaste.
> > >
> > >   Discussed with: imp
> > >   Relnotes:   sure, if we don't end up reverting it
> >
> > This would break (and the effect can be quite persistent and hard to
> > repair, see explanation below) existing configuration as some GEOM
> > classes are not converted to support the new way of device
> > representation, so I'd like to request this change be reverted for now
> > until these are fixed.
> >
> > Consider the following configuration, where one have a hard drive
> > partitioned with GPT, like:
> >
> > =>40  1953525088  ada1  GPT  (932G)
> >   40  262144 1  efi  (128M)
> >   262184 8388608 2  freebsd-zfs  (4.0G)
> >  865079267108864 3  freebsd-swap  (32G)
> > 75759656  1877765472 4  freebsd-zfs  (895G)
> >
> > Now, the first ZFS pool is created as root pool.  ZFS gets an exclusive
> > hold of 'ada1p2' despite the pool is carefully created to use
> > /dev/diskid/p2 instead of ada1p2.
> >
> > ZFS writes the new device path to vdev label.  For ZFS, this doesn't
> > matter much as it always checks the label.
> >
> > However, this will prevent GEOM from properly creating
> > /dev/diskid/.
>

Re: HEADSUP: GEOM label may be broken [Was Re: svn commit: r361838 - in head/sys/geom: . label]

[Conrad Meyer]

Hi Xin Li,

Thank you for the report and diagnosis.  Sorry for the breakage.

I have reverted the change and hope to address the issues you have identified.

There seem to be two issues identified:
1. When ZFS attaches to a partition of a disk, the /dev/diskid label disappears.
2. geli(8) attach of symlink labels doesn't work

(1) is interesting, as it does not seem to happen to UFS or swap consumers:

# mount
/dev/gpt/rootfs on / (ufs, local, noatime, soft-updates)
# swapctl -l
Device:   1024-blocks Used:
/dev/vtbd0p21048576 0
# ls -l /dev/diskid/DISK-BHYVE-2613-8EFD-BAF4 /dev/gpt/{rootfs,swapfs}
lrwxr-xr-x 1 root wheel  8 May 22 20:18
/dev/diskid/DISK-BHYVE-2613-8EFD-BAF4 -> ../vtbd0
lrwxr-xr-x 1 root wheel 10 May 22 20:18 /dev/gpt/rootfs -> ../vtbd0p3
lrwxr-xr-x 1 root wheel 10 May 22 20:18 /dev/gpt/swapfs -> ../vtbd0p2

I wonder what is different in the ZFS case here.

(2)

# ls -l /dev/gpt/testingeli
lrwxr-xr-x 1 root wheel 8 Jun  6 08:33 /dev/gpt/testingeli -> ../md0s1
# geli init /dev/gpt/testingeli
Enter new passphrase:
Reenter new passphrase:
...
# geli attach /dev/gpt/testingeli
Enter passphrase:
geli: Provider gpt/testingeli is invalid.
geli: There was an error with at least one provider.

So at least the latter problem is straightforward to resolve.  I have
a patch I'm testing locally now, and will upload to phabricator
shortly.

Best regards,
Conrad


On Sat, Jun 6, 2020 at 1:17 AM Xin Li  wrote:
>
> I just spent quite some time to revive my laptop.  TL;DR: if you are
> using /dev/diskid or /dev/gptid labels and GELI, please wait until
> things settled.
>
> ===
>
> On 6/5/20 9:12 AM, Conrad Meyer wrote:
> > Author: cem
> > Date: Fri Jun  5 16:12:21 2020
> > New Revision: 361838
> > URL: https://svnweb.freebsd.org/changeset/base/361838
> >
> > Log:
> >   geom_label: Use provider aliasing to alias upstream geoms
> >
> >   For synthetic aliases (just pseudonyms inferred from metadata like GPT or
> >   UFS labels, GPT UUIDs, etc), use the GEOM provider aliasing system to 
> > create
> >   a symlink to the real device instead of creating an independent device.
> >   This makes it more clear which labels and devices correspond, and we can
> >   safely have multiple labels to a single device accessed at once.
> >
> >   The confusingly named geom_label on-disk construct continues to behave
> >   identically to how it did before.
> >
> >   This requires teaching GEOM's provider aliasing about the possibility
> >   that aliases might be added later in time, and GEOM's devfs interaction
> >   layer not to worry about existing aliases during retaste.
> >
> >   Discussed with: imp
> >   Relnotes:   sure, if we don't end up reverting it
>
> This would break (and the effect can be quite persistent and hard to
> repair, see explanation below) existing configuration as some GEOM
> classes are not converted to support the new way of device
> representation, so I'd like to request this change be reverted for now
> until these are fixed.
>
> Consider the following configuration, where one have a hard drive
> partitioned with GPT, like:
>
> =>40  1953525088  ada1  GPT  (932G)
>   40  262144 1  efi  (128M)
>   262184 8388608 2  freebsd-zfs  (4.0G)
>  865079267108864 3  freebsd-swap  (32G)
> 75759656  1877765472 4  freebsd-zfs  (895G)
>
> Now, the first ZFS pool is created as root pool.  ZFS gets an exclusive
> hold of 'ada1p2' despite the pool is carefully created to use
> /dev/diskid/p2 instead of ada1p2.
>
> ZFS writes the new device path to vdev label.  For ZFS, this doesn't
> matter much as it always checks the label.
>
> However, this will prevent GEOM from properly creating
> /dev/diskid/.
>
> In order to prevent accidentally writing data to wrong disk, for "raw"
> disk partitions it's usually a good idea to reference them with labels,
> either by /dev/diskid or /dev/gptid.  With /dev/ada1p2 exclusively
> accessed by ZFS, the /dev/diskid/ representing the disk is
> now gone.
>
> And to make the situation even worse, simply changing the partition
> reference to the corresponding /dev/gptid/ doesn't really work
> either, when one is encrypting partitions individually.  In the example
> above, adap4 is an encrypted partition and with the alias change, one
> can no longer "geli attach" them via /dev/gptid/.  They can still
> be attached by the "canonical" path (/dev/ada1p4), but for the swap
> partition that would completely defeat the purpose of using label (to
> prevent accidentally writing to the wrong disk).
>
> For my case, reverting to an older kernel is not sufficient to fix the
> configurat

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

[Conrad Meyer]

Hi Grzegorz,

If you have another machine connected by network that you can install
and start netdumpd on, and; ipv4 configured on a supported network
device before the machine paniced; and a recent CURRENT; you should be
able to initiate a kernel dump over the network with 'netdump -s
server-ip' in DDB.  In more complicated situations you might also need
to specify '-g gateway-ip -c client-ip -i interface', but for servers
on the LAN or available via the default gateway route, the former
ought to work.

Best,
Conrad

On Sat, May 2, 2020 at 6:56 AM Grzegorz Junka  wrote:
>
>
> On 02/05/2020 14:15, Grzegorz Junka wrote:
> > cpuid = 3
> >
> > time = 1588422616
> >
> > KDB: stack backtrace:
> >
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe00b27e86b0
> >
> > vpanic() at vpanic+0x182/frame 0xfe00b27e8700
> >
> > panic() at panic+0x43/frame ...
> >
> > sleepq_add()
> >
> > ...
> >
> > I see
> >
> > db>
> >
> > in the terminal. I tried "dump" but it says, Cannot dump: no dump
> > device specified.
> >
> > Is there a guide how to deal wit those, i.e. to gather information
> > required to investigate issues?
> >
> > ___
> > 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"
>
>
> OK, I found this handbook
> https://www.freebsd.org/doc/en/books/developers-handbook/book.html#kerneldebug
>
> Obviously something must have been misconfigured that I can't dump the
> core now. Is there anything I can fetch from the system while I am in
> db> or I should just forget and restart?
>
> GrzegorzJ
>
> ___
> 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: Working on Zoom port

[Conrad Meyer]

Hi Matthias,

From personal experience, receiving Zoom video in conferences with
native www/chromium and the web interface works perfectly fine and has
for some time (at least the last year).  I think, but don't recall if
I personally tried it, that mic support is fine as well.  Audio
playback is fine.

Unfortunately, until recently, the webcam support in our chromium port
was disabled; it is restored in the '80.mumble.163_1' version of the
port.  There have been mixed reports of success (or not) with webcams
in chromium after 163_1; it works ok for some people and there are
flickering issues for others.  I don't have a supported webcam easily
available to test, but would appreciate more data (either "it works
for me," or "it doesn't, in this way") in PR 245505 (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245505 ).

So, it may work well; it may only work half-duplex for video.  Try it out!

Firefox support may be better; I'm not familiar with the status of our
Firefox port.

Best regards,
Conrad

P.S., the web interface only offers a subset of the full
functionality, so I believe the efforts to port the linux binary
client are valuable.  Still, the web interface works well enough that
it might be an option.  It's what I use at my day job.

On Mon, Apr 13, 2020 at 10:36 AM Matthias Apitz  wrote:
>
> El día lunes, abril 13, 2020 a las 07:32:31p. m. +0300, Alexandr Krivulya 
> escribió:
>
> > Hello!
> > All of you need - a conference ID and probably password. Now you can
> > participate in conference by pressing Join button in zoom client and
> > providing this ID and/or password. Conference ID is part of your url
> > after '/j/' - for example conference url is
> > https://zoom.us/j/111222333?pwd=ejhxhshyocdyaszT9 and conference ID is
> > 111222333. BTW, you can join conference via web-client from browser by
> > url https://zoom.us/wc/join/YOUR-CONFERENCE-ID, but with firefox prior
> > version 77 (nightly) without audio and with chromium without webcam
> > (FreeBSD only, also audio and screen sharing works).
>
> Hello Alexandr,
> Thanks for the kind explanation. With this I understand now the
> invitation data:
>
> Bernhard S. invites you to a scheduled Zoom-meeting.
> Zoom-Meeting join
>
> https://us04web.zoom.us/j/454819xxx?pwd=OUtlOHB4RTk2dz09
>
> Meeting-ID: 454 819 xxx
> Passwort: 8xWxxx
>
> And, your port will make the Linux client running on FreeBSD?
>
> Wouldn't it be an option to make video working in chromium on FreeBSD?
>
> Thanks again
>
> matthias
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> ___
> 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: System clock is slow

[Conrad Meyer]

On Tue, Mar 10, 2020 at 9:24 AM Theron  wrote:
> I had previously used powerd to let the CPU underclock to 700MHz when
> idle.  Now, I've lost all control over CPU frequency (either by powerd
> or by sysctl) since there is some in-kernel cpufreq driver which I can't
> figure out how to disable.

It's hwpstate_intel(4).  You can add
'hint.hwpstate_intel.0.disabled="1"' in loader.conf or device.hints to
disable and use est(4), if you prefer.

The idea of the device is that hardware can do a better job managing
the frequency / power states rapidly than daemons like powerd.  But if
you like powerd/est, feel free to disable it.  Future models of Intel
CPU may not provide est(4).

If you leave it enabled, you can control the energy efficiency /
performance trade-off of hwpstate_intel on a per-core basis (or
per-package, if not disabled and hardware supports package-level
control) with 'dev.hwpstate_intel..epp=0-100' (sysctl or
tunable); the CPU uses this knob to control how biased it is towards
low frequency states.  100 is most efficient, 0 is most performant.
The default is 50.

Best,
Conrad
___
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: Which AMD CPUs are supported -- temperature

[Conrad Meyer]

The step size of 1/8 degree C/K is documented in the public BKDG (prior to
17h) and PPR (17h+) documents available on AMD’s website, at least for
relatively recent models. I don’t know about very old models (really
anything older than 17h, although I’ve looked at the 15h docs some).

Best,
Conrad

On Wed, Feb 12, 2020 at 23:22 Peter Jeremy  wrote:

> On 2020-Feb-12 15:23:51 -0500, mike tancsa  wrote:
> >Not sure about the older Athlon CPUs, but the 2 generations of Ryzen's I
> >have seem correct as well as an APU
> >
> >CPU: AMD GX-412TC SOC(998.17-MHz K8-class
> CPU)
>
> OTOH, I'm not confident about temperatures on my APU.  The publicly
> available data just says that the SoC reports "a temperature on its own
> scale" relative to a Tctl_max which "is specified in the power and thermal
> data sheet" (that I have been unable to locate).  Everyone seems to assume
> that the step size is 0.125K but I haven't found that publicly documented
> anywhere.  The AMD Product Brief states that the maximum temperature is
> 90°C but using that as Tctl_max gives me temperature readings that don't
> look right.
>
> >And on a fanless APU
> >
> ># sysctl -a dev.cpu.0.temperature
> >dev.cpu.0.temperature: 62.6C
> >
> ># sysctl -a dev.amdtemp.0.core0.sensor0
> >dev.amdtemp.0.core0.sensor0: 63.1C
>
> At what ambient temperature?  I see a similar value from my (idle) APU3
> but don't believe the (implied) ~35K junction-to-ambient difference.
>
> --
> Peter Jeremy
>
___
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: hwpstate_intel hangs kernel

[Conrad Meyer]

Hi Andreas,

No, nothing new on this front.  I don't have any of this hardware nor
do I work for Intel, and nothing I see in the code or published spec
would result in hangs.  I don't have more cycles to spend on this
driver.  So I suggest using 'hint.hwpstate_intel.0.disabled="1"' as a
workaround indefinitely.

On a private email with Andrey I discussed making disabled="1" the
default, and allowing users to opt in with disabled="0" (or perhaps
enabled="1", for fewer double negatives).  It's not especially
satisfying, but would prevent this class of unknown issue with
hwpstate_intel(4).

Best,
Conrad

On Tue, Feb 11, 2020 at 11:49 AM Andreas Nilsson  wrote:
>
> Hello,
>
> any new leads on this? As of what is in git on 2020-02-05, my computer still 
> hangs on kernel boot on "hwpstate_intel0:  on cpu0"
>
> I guess it would have been easier to debug a panic. Setting 
> debug.hwpstate_verbose=1 doesn't really give any difference in output.
>
> Best regards
> Andreas
>
> On Wed, Feb 5, 2020 at 2:45 PM Andreas Nilsson  wrote:
>>
>> Hello,
>>
>> I upgraded to a newer version,  git 87d669d3863-c266265, and I do not 
>> experience the random hang anymore. The machine still hangs on boot on 
>> "hwpstate_intel0:  on cpu0" unless I set 
>> 'hint.hwpstate_intel.0.disabled="1"' in loader.conf.
>>
>> On a side note I cannot set or unset that hint from loader prompt;
>>
>> ok> set hint.hwpstate_intel.0.disabled="0"
>> ok> show
>> 
>> hint.hwpstate=
>> ...
>>
>> Best regards
>> Andreas
>>
>> On Sat, Feb 1, 2020 at 11:26 PM Andreas Nilsson  wrote:
>>>
>>> Hello Conrad,
>>>
>>> thank you Andrey for bisecting! I'll try with that hint and see how it 
>>> works for me.
>>>
>>> Best regards
>>> Andreas
>>>
>>> On Sat, Feb 1, 2020, 18:18 Conrad Meyer  wrote:
>>>>
>>>> Hi Andrey,
>>>>
>>>> Please try 'hint.hwpstate_intel.0.disabled="1"' as a workaround for now.
>>>>
>>>> I think I have identified at least one problematic piece of code,
>>>> although I don't know if it's the root cause.  I will go ahead and fix
>>>> that, which may not fix the hang, and also add some debug printfs that
>>>> can be enabled to help identify the real issue.
>>>>
>>>> Thanks for the report and bisect.
>>>>
>>>> Best,
>>>> Conrad
>>>>
>>>> On Sat, Feb 1, 2020 at 6:06 AM Andrey V. Elsukov  wrote:
>>>> >
>>>> > 31.01.2020 18:11, Andrey V. Elsukov пишет:
>>>> > > On 24.01.2020 19:52, Andreas Nilsson wrote:
>>>> > >> It hangs during kernel boot and the last message printed on console 
>>>> > >> is:
>>>> > >> hwpstate_intel0:  on cpu0
>>>> > >
>>>> > > Hi,
>>>> > >
>>>> > > Did you find the cause of this hang?
>>>> > > I also tried to update today from r350816 to r357330. But my Lenovo X1
>>>> > > Carbon 4th hangs on the same message.
>>>> > >
>>>> >
>>>> > Hi,
>>>> >
>>>> > I have bisected the bad commit, it is r357002.
>>>> >
>>>> > --
>>>> > WBR, Andrey V. Elsukov
>>>> >
___
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: Is amd automount still supported in 13.0 or not?

[Conrad Meyer]

Yep, amd is deprecated for 13.0:
https://svnweb.freebsd.org/base?view=revision=354902 ,
https://svnweb.freebsd.org/base?view=revision=354997 .

Conrad

On Mon, Feb 3, 2020 at 3:23 PM Bob Willcox  wrote:
>
> Hi All,
>
> I've recently installed a 13.0 snapshot on one of my system to get some 
> experience with it
> and am having trouble trying to setup the amd automount program. In fact, I 
> can't find amd
> on this system. Has amd been removed and all we have for automatically 
> mounting
> filesystems autofs?
>
> Thanks,
> Bob
>
> --
> Bob Willcox| It's possible that the whole purpose of your life is to
> b...@immure.com | serve as a warning to others.
> Austin, TX |
> ___
> 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: hwpstate_intel hangs kernel

[Conrad Meyer]

Hi Andrey,

Please try 'hint.hwpstate_intel.0.disabled="1"' as a workaround for now.

I think I have identified at least one problematic piece of code,
although I don't know if it's the root cause.  I will go ahead and fix
that, which may not fix the hang, and also add some debug printfs that
can be enabled to help identify the real issue.

Thanks for the report and bisect.

Best,
Conrad

On Sat, Feb 1, 2020 at 6:06 AM Andrey V. Elsukov  wrote:
>
> 31.01.2020 18:11, Andrey V. Elsukov пишет:
> > On 24.01.2020 19:52, Andreas Nilsson wrote:
> >> It hangs during kernel boot and the last message printed on console is:
> >> hwpstate_intel0:  on cpu0
> >
> > Hi,
> >
> > Did you find the cause of this hang?
> > I also tried to update today from r350816 to r357330. But my Lenovo X1
> > Carbon 4th hangs on the same message.
> >
>
> Hi,
>
> I have bisected the bad commit, it is r357002.
>
> --
> WBR, Andrey V. Elsukov
>
___
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: AT_EXECPATH aux_info vector contains path of interpreter when directly exec'ing rtld

[Conrad Meyer]

Isn’t rtld’s behavior here correct? It’s really Clang which is doing
something quite odd.

On Fri, Dec 20, 2019 at 13:27 Ryan Stone  wrote:

> I've noticed that on head, if I directly execute rtld to run an
> executable, AT_EXECPATH contains the path to rtld on head (on
> 12.0-RELEASE it will contain nothing).  This is causing me a problem
> because clang uses AT_EXECPATH to preferentially locate where it's
> installed, which it uses to locate its driver programs.
>
> The end result is that clang can no longer successfully be executed
> from a process in capability mode, whereas before I could fexecve rtld
> and give it a pre-opened file descriptor to /usr/bin/clang.
>
> I've put together a quick test program demonstrating the problem:
>
> https://people.freebsd.org/~rstone/getprogname.c
>
> On 12.0-RELEASE, directly executing rtld to run this program gives this
> output:
> $ /libexec/ld-elf.so.1 -- ./progname
> progname: progname
> argv[0]:  ./progname
> elf_aux_info failed: No such file or directory
>
> On head, I get this instead:
> /libexec/ld-elf.so.1 -- ./progname
> progname: progname
> argv[0]:  ./progname
> AT_EXECPATH: /libexec/ld-elf.so.1
> ___
> 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: /etc/os-release isn't created

[Conrad Meyer]

Hi,

Did you run etcupdate or mergemaster as part of updating your host?

Best,
Conrad

On Sat, Nov 23, 2019 at 1:15 PM Yasuhiro KIMURA  wrote:
>
> Hello,
>
> Yesterday I updated my 13-CURRENT host from r354592 to r355028 and
> /etc/os-release symbolic link wasn't created.
>
> yasu@rolling-vm-freebsd1[2061]% uname -a
> FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD 
> 13.0-CURRENT #0 r355028: Sat Nov 23 22:35:58 JST 2019 
> ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/base/obj/usr0/freebsd/base/head/amd64.amd64/sys/GENERIC
>   amd64
> yasu@rolling-vm-freebsd1[2062]% ls -l /etc/os-release
> ls: /etc/os-release: No such file or directory
> yasu@rolling-vm-freebsd1[2063]%
>
> But after that I made same update of 13-CURRENT poudriere jail and
> then /etc/os-release was created in it.
>
> yasu@rolling-vm-freebsd1[2063]% ls -l 
> /usr/local/poudriere/jails/curamd64/etc/os-release
> lrwxr-xr-x  1 root  wheel  21 Nov 24 05:04 
> /usr/local/poudriere/jails/curamd64/etc/os-release@ -> 
> ../var/run/os-releaseyasu@rolling-vm-freebsd1[2064]%
>
> Why such difference happens?
>
> ---
> Yasuhiro KIMURA
> ___
> 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: panic: Unregistered use of FPU in kernel

[Conrad Meyer]

This kinda just looks like ddb doesn't know how to disassemble crc32q?
 Which might not be too surprising.

Note that it also truncates the qword constant in "add" at +167/+0xa7.
That one isn't corruption; just a DDB bug.

Can you print the faulting %rip and dump a few bytes at that address
in both ddb and gdb (assuming ddb can't disassemble crc32q)?

Best,
Conrad

On Thu, Sep 26, 2019 at 1:12 PM Alan Somers  wrote:
>
> On Thu, Sep 26, 2019 at 11:29 AM Konstantin Belousov 
> wrote:
>
> > On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote:
> > > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov <
> > kostik...@gmail.com>
> > > wrote:
> > >
> > > > On Thu, Sep 26, 2019 at 09:45:43AM -0600, Alan Somers wrote:
> > > > > The latest VM snapshot
> > > > (FreeBSD-13.0-CURRENT-amd64-20190920-r352544.qcow2)
> > > > > instapanics on boot:
> > > > >
> > > > > panic: Unregistered use of FPU in kernel
> > > > >
> > > > > stack trace:
> > > > > ...
> > > > > sse42_crc32c
> > > > > readsuper
> > > > > ffs_sbget
> > > > > g_label_ufs_taste_common
> > > > > g_label_taste
> > > > > g_new_provider_event
> > > > > g_run_events
> > > > > fork_exit
> > > > > ...
> > > > >
> > > > > Has anybody touched this area recently?  I'll try to narrow down the
> > > > commit
> > > > > range.
> > > >
> > > > Start with disassembling the faulting instruction.  I suspect that
> > somehow
> > > > vital compiler switches like -mno-sse got omitted in the build.
> > > >
> > >
> > > No problem with compiler switches here.  The C file uses inline assembly
> > to
> > > generate a crc32q instruction, in crc32_sse42.c:257.  But why would that
> > > generate a floating point exception?  The instruction doesn't appear to
> > be
> > > using any floating point registers.  This is on a Kaby Lake CPU.
> > >
> > > crc32q %rsi, %rbx
> >
> > No idea, this instruction does not generate #NP at all.
> >
> > Provide exact script of the panic and backtrace,
> > together with the disassembly of the function which contained the faulted
> > instruction.  Do disassemble from ddb, in case text was corrupted.
> >
>
> Ok, here's the full stack trace:
>  #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> #1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392
> #2  0x804a1edb in db_dump (dummy=,
> dummy2=, dummy3=, dummy4=)
> at /usr/src/sys/ddb/db_command.c:575
> #3  0x804a1c8f in db_command (last_cmdp=,
> cmd_table=, dopager=1) at
> /usr/src/sys/ddb/db_command.c:482
> #4  0x804a1a04 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:535
> #5  0x804a4cbf in db_trap (type=, code= out>)
> at /usr/src/sys/ddb/db_main.c:252
> #6  0x80c1e55c in kdb_trap (type=3, code=0, tf=)
> at /usr/src/sys/kern/subr_kdb.c:692
> #7  0x811957df in trap (frame=0xfe00907e8d20)
> at /usr/src/sys/amd64/amd64/trap.c:621
> #8  
>
> Your guess about corrupted text was prescient.  Here is the disassembly
> according to ddb:
> https://people.freebsd.org/~asomers/Screenshot_fbsd-head_2019-09-26_13%3A51%3A34.png
> And here is the disassembly of the same section according to gdb:
>0x8113b2e0 : mov%rsi,%r9
>0x8113b2e3 : sub$0xff80,%r9
>0x8113b2e7 : add$0x100,%rsi
>0x8113b2ee : mov%r11,%rbx
>0x8113b2f1 : xor%eax,%eax
>0x8113b2f3 : xor%r11d,%r11d
>0x8113b2f6 : nopw   %cs:0x0(%rax,%rax,1)
>0x8113b300 : mov%rsi,%rdx
>0x8113b303 : mov-0x100(%rsi),%rsi
>0x8113b30a : mov-0x80(%rdx),%rdi
>0x8113b30e : crc32q %rsi,%rbx
>0x8113b314 : crc32q %rdi,%rax
>0x8113b31a : mov(%rdx),%rsi
>0x8113b31d : crc32q %rsi,%r11
>0x8113b323 : lea0x8(%rdx),%rsi
>0x8113b327 : add$0xff08,%rdx
>0x8113b32e : cmp%r9,%rdx
>0x8113b331 :
> jb 0x8113b300 
>0x8113b333 : movzbl %cl,%r9d
>0x8113b337 : movzbl %ch,%edi
>0x8113b33a : mov%ecx,%edx
>
> Care to guess what's causing the corruption?
> -Alan
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Deadlock involving truss -f, pdfork() and wait4()

[Conrad Meyer]

On Fri, Sep 13, 2019 at 11:37 AM Mark Johnston  wrote:
>
> On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote:
> > This gets me a little further but now the wait4 call by the parent
> > never reaps the child and instead blocks forever:
>
> Does it perform a wildcarded wait(), or does it explicitly specify the
> PID of the child?  By design, the former will not return children
> created by pdfork().

Explicit PID:

https://people.freebsd.org/~rstone/pdfork.c

Best,
Conrad
___
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: Building world with gcc9 not working

[Conrad Meyer]

On Mon, Sep 9, 2019 at 8:25 PM Rebecca Cran  wrote:
>
> Is building world with gcc still supported? I'm getting an error running
> the following:
>
> make XCC=/usr/local/bin/gcc9 XCXX=/usr/local/bin/g++9 buildworld

Hi Rebecca,

Aspirationally, yes.  I did a successful CROSS_TOOLCHAIN=amd64-gcc
buildworld earlier this week.  (It doesn't play well with binary pkg's
built with Clang, so I ended up replacing it with a Clang-built world
instead, but it compiled.)

Unfortunately, amd64-xtoolchain-gcc is stuck on GCC 6.4.0, while
you're running the much more recent GCC9.  I think GCC6.4.0 is more or
less expected to build world today, but I don't think many people are
building with GCC9.  I would love for amd64-xtoolchain to move to a
newer version, but I don't know what is blocking that — it seems like
it should be straightforward.

Best regards,
Conrad
___
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: HEADSUP: drm-current-kmod now installs sources

[Conrad Meyer]

This is super cool, thank you!  Is it feasible to integrate other
out-of-tree kmods in a similar way, e.g., nvidia-driver?

On Tue, Aug 13, 2019 at 2:58 PM John Baldwin  wrote:
>
> With help from zeising@ in particular, I've just committed a change
> to the drm-current-kmod port that makes it install sources into
> /usr/local/sys/modules by default.  This will result in some behavior
> changes on HEAD (and only head for now):
>
> 1) When you build a kernel after installing the updated package,
>your buildkernel will now build DRM modules using the sources
>from the package.  For developers at least I suspect this to be
>a win as if you have made changes to the kernel KBI you will
>always end up with matching modules installed into /boot/kernel
>alongside your kernel.
>
> 2) In order to use these modules, you need to update the 'kld_list'
>lines in your rc.conf to just list the modules without a
>path, e.g. "kld_list=i915kms" just as you would for other
>modules.  This will prefer the module built with your kernel if
>one exists and fall back to the module in /boot/modules
>otherwise.
>
> If a change in current breaks the build of DRM modules, you have a
> couple of options:
>
> 1) Pass 'LOCAL_MODULES=' (empty string) on the command line of
>'make buildkernel' to disable building the DRM modules.
>
> 2) Hack on the sources in /usr/local/sys/modules/drm-current-kmod
>to fix the compile breakage, perhaps using a patch from the
>mailing lists if one exists.
>
> 3) Wait for a new package/port version and update to that before
>doing a buildkernel.
>
> For developers this means even if you are doing testing on a box
> that doesn't use DRM, you can install the package so that kernel
> builds will try to compile it and hopefully spot KPI/KBI changes
> before they land in the tree so that the port/package can be
> patched in tandem with committing changes to HEAD.  Note that even
> builds of work trees in git checkouts, etc. will find the DRM
> modules and try to build them if the package is installed.
>
> --
> John Baldwin
> ___
> 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: SVN r350713 breaks non-debug kernel builds

[Conrad Meyer]

Thanks for the report Michael, and sorry about the breakage.  I
believe this patch should fix the build, and I am testing it now:

--- sys/kern/kern_sysctl.c  (revision 350714)
+++ sys/kern/kern_sysctl.c  (working copy)
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -67,7 +68,6 @@
 #endif

 #ifdef DDB
-#include 
 #include 
 #include 
 #endif

On Wed, Aug 7, 2019 at 6:23 PM Michael Butler
 wrote:
>
> As follows ..
>
> --- kern_sysctl.o ---
> /usr/src/sys/kern/kern_sysctl.c:1623:19: error: use of undeclared
> identifier 'kdb_active'
> if (arg2 == 0 || kdb_active) {
>  ^
> 1 error generated.
> *** [kern_sysctl.o] Error code 1
>
> imb
>
>
___
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: Reducing UFS corruption from unclean shutdowns?

[Conrad Meyer]

On Fri, Jun 21, 2019 at 2:55 PM Alan Somers  wrote:
> I would've thought that immediately following a sync(8), the
> filesystem would be consistent.  Why do I still see errors after a
> panic in files that were written before I sync()ed?
> -Alan

Hi Alan,

Contra the name, sync(2) (sync(8)) isn't synchronous.  It invokes
VFS_SYNC() with MNT_NOWAIT across all mountpoints.

Cheers,
Conrad
___
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: CURRENT >r349150: boot failure in rc.conf.local

[Conrad Meyer]

Hi everyone,

Please find a proposed fix in https://reviews.freebsd.org/D20686 .

I didn't notice this thread because I'm already subscribed to current
and CC's don't display any differently in my mail reader.  (I don't
read every thread on current.)

Take care,
Conrad

On Tue, Jun 18, 2019 at 11:03 AM Cy Schubert  wrote:
>
> Looping in the committer of r349154.
> On June 18, 2019 8:39:34 AM PDT, Takanori Watanabe  
> wrote:
> >On Tue, Jun 18, 2019 at 09:03:17AM -0400, Jung-uk Kim wrote:
> ...
> >> I had the same problem and reverting r349154 fixed the problem for
> >me.
> ...
> >In my machine, some executable, such as chromium, perl will hang like
> >you.
> >It is also fixed by reverting r349154. Thanks.
___
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: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

[Conrad Meyer]

Hi Rainier,

On Mon, May 27, 2019 at 7:47 AM  wrote:
> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
> department who is technically responsible for the service gets around
> redoing that service.

Even if this proposal is approved, it would only affect 13+.  You
could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
Bhyve.  But do consider lighting a fire under whatever department
thinks it's ok to deploy like that :-).

Take care,
Conrad
___
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: Weirdness when writing to pseudofs file

[Conrad Meyer]

On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg  wrote:
> > It seems, a single '>' will cause it to try to create the file (even
> > though it already exists) and that fails (kern_openat).
> >
> I would guess because of
>
> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042
>
> struct vop_vector pfs_vnodeops = {
> ...
> .vop_create = VOP_EOPNOTSUPP,
> ...
> }

kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei()
cannot find the named vnode (ni_vp == NULL).  Otherwise, it should
just invoke VOP_OPEN.  This suggests there might be a lookup bug in
pfs?  Tracing VOPs as Mark suggested seems like a good next step.

Best,
Conrad
___
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: random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy.

[Conrad Meyer]

Sorry about that. Please update to r347329.

Thanks,
Conrad

On Wed, May 8, 2019 at 9:16 AM Andrey V. Elsukov  wrote:

> Hi,
>
> today I updated one of my test machines and discovered that message from
> the subject periodically printed in the console.
>
> FreeBSD 13.0-CURRENT r347327=4f47587(svn_head) GENERIC-NODEBUG amd64
> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on
> LLVM 8.0.0)
> VT(vga): resolution 640x480
> CPU: Intel(R) Xeon(R) CPU E5-2660 v4@ 2.00GHz (2000.04-MHz K8-class CPU)
> ...
> real memory  = 68719476736 (65536 MB)
> avail memory = 66722340864 (63631 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 28 CPUs
> FreeBSD/SMP: 2 package(s) x 14 core(s)
> ...
>
> % grep -c random /var/run/dmesg.boot
> 606
>
> % grep random /var/run/dmesg.boot | head -10
> __stack_chk_init: WARNING: Initializing stack protection with non-random
> cookies!
> random: entropy device external interface
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> arc4random: WARNING: initial seeding bypassed the cryptographic random
> device because it was not yet seeded and the knob
> 'bypass_before_seeding' was enabled.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG'
> returned no entropy.
>
> % sysctl -a | grep -v random_sources_feed | grep rand
> kern.fallback_elf_brand: -1
> device  random
> device  rdrand_rng
> kern.randompid: 0
> kern.elf32.fallback_brand: -1
> kern.elf64.fallback_brand: -1
> kern.random.fortuna.minpoolsize: 64
> kern.random.harvest.mask_symbolic:
>
> PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
> kern.random.harvest.mask_bin: 000100011101
> kern.random.harvest.mask: 66015
> kern.random.use_chacha20_cipher: 0
> kern.random.block_seeded_status: 0
> kern.random.random_sources: 'Intel Secure Key RNG'
> kern.random.initial_seeding.disable_bypass_warnings: 0
> kern.random.initial_seeding.arc4random_bypassed_before_seeding: 1
> kern.random.initial_seeding.read_random_bypassed_before_seeding: 0
> kern.random.initial_seeding.bypass_before_seeding: 1
> net.inet.ip.portrange.randomtime: 45
> net.inet.ip.portrange.randomcps: 10
> net.inet.ip.portrange.randomized: 1
> net.inet.ip.random_id_total: 0
> net.inet.ip.random_id_collisions: 0
> net.inet.ip.random_id_period: 0
> net.inet.ip.random_id: 0
> net.key.int_random: 60
> debug.fail_point.status_fill_kinfo_vnode__random_path: off
> debug.fail_point.fill_kinfo_vnode__random_path: off
> debug.fail_point.status_random_fortuna_pre_read: off
> debug.fail_point.random_fortuna_pre_read: off
> security.stack_protect.permit_nonrandom_cookies: 1
>
> --
> WBR, Andrey V. Elsukov
>
>
___
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: Optimization bug with floating-point?

[Conrad Meyer]

Hi John,

On Wed, Mar 13, 2019 at 10:17 AM John Baldwin  wrote:
> One issue I'm aware of is that clang does not have any support for the
> special arrangement FreeBSD/i386 uses where it uses different precision
> for registers vs in-memory for some of the floating point types (GCC has
> a special hack that is only used on FreeBSD for this but isn't used on
> any other OS's).  I wonder if that could be a factor?  Volatile probably
> forces a round trip between memory which might explain why this is the
> case.
>
> I wonder what your test program does on i386 Linux with GCC?

$ uname -sr
Linux 4.20.4
$ gcc --version
gcc (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6)
...
$ rpm -qf /usr/lib/libm-2.27.so
glibc-2.27-37.fc28.i686

$ gcc -m32 -fno-builtin -o z kargl.c -lm && ./z
Max ULP: 1.959975
Count: 0
$ gcc -O -m32 -fno-builtin -o z kargl.c -lm && ./z
Max ULP: 1.959975
Count: 0
$ gcc -O1 -m32 -fno-builtin -o z kargl.c -lm && ./z
Max ULP: 1.959975
Count: 0
$ gcc -O2 -m32 -fno-builtin -o z kargl.c -lm && ./z
Max ULP: nan
Count: 0
$ gcc -O3 -m32 -fno-builtin -o z kargl.c -lm && ./z
Max ULP: nan
Count: 0

Uh.

kargl.c: In function ‘main’:
kargl.c:80:10: warning: ‘u’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   if (ur > u) u = ur;
  ^

If I initialize 'u' (to, e.g., -1e52), I get:
Max ULP: 1.959975
Count: 0

at -O2 and -O3 as well.

Best,
Conrad
___
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: PMC Sierra SPC SAS-SATA Card + ESXi

[Conrad Meyer]

Hi Evgheni,

Is it possible to replace the card with a different one?  The PMC
Sierra driver is not very good.

Best,
Conrad

On Sun, Mar 10, 2019 at 12:24 AM Evgheni Melman  wrote:
>
> So I got this weird setup, where I … a PMC-Sierra PM8003
> card (same as PM8001, but with external QSFP afaik) …
___
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: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

[Conrad Meyer]

On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl
 wrote:
> This is interesting as well.  Does this mean that amd64 is now
> the only tier 1 platform and all other architectures are after
> thoughts?

This has been the de facto truth for years.  i386 is mostly only
supported by virtue of sharing code with amd64.  There are efforts to
promote arm64 to Tier 1, but it isn't there yet.  Power8+ might be
another good alternative Tier 1 candidate eventually.  None have
anything like the developer popularity that amd64 enjoys.

Conrad
___
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: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

[Conrad Meyer]

On Sat, Feb 23, 2019 at 12:44 AM Steve Kargl
 wrote:
> Ideas?
> ...
> +CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.04-MHz 686-class 
> CPU)
>Origin="GenuineIntel"  Id=0x6fd  Family=0x6  Model=0xf  Stepping=13

https://ark.intel.com/content/www/us/en/ark/products/31728/intel-core-2-duo-processor-t7250-2m-cache-2-00-ghz-800-mhz-fsb.html

> Intel® Virtualization Technology (VT-x) ‡  Yes
> Intel® 64 ‡   Yes

> Merom is the first Intel mobile processor to feature Intel 64 architecture.

So, as a workaround, maybe run amd64?
___
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: r344398 Import ACPICA 20190215: breaks bhyve

[Conrad Meyer]

Oops, to the list this time.

Hi Oleg,

Those look like the ACPI lines bhyve attempts to generate and compile
in basl_fwrite_madt():

272 /* Legacy IRQ0 is connected to pin 2 of the IOAPIC */
273 EFPRINTF(fp, "[0001]\t\tSubtable Type : 02\n");
274 EFPRINTF(fp, "[0001]\t\tLength : 0A\n");
275 EFPRINTF(fp, "[0001]\t\tBus : 00\n");
276 EFPRINTF(fp, "[0001]\t\tSource : 00\n");
277 EFPRINTF(fp, "[0004]\t\tInterrupt : 0002\n");
278 EFPRINTF(fp, "[0002]\t\tFlags (decoded below) : 0005\n");
^^^ this line ("maximum 1 bit")
279 EFPRINTF(fp, "\t\t\tPolarity : 1\n");
280 EFPRINTF(fp, "\t\t\tTrigger Mode : 1\n");
281 EFPRINTF(fp, "\n");
282
283 EFPRINTF(fp, "[0001]\t\tSubtable Type : 02\n");
284 EFPRINTF(fp, "[0001]\t\tLength : 0A\n");
285 EFPRINTF(fp, "[0001]\t\tBus : 00\n");
286 EFPRINTF(fp, "[0001]\t\tSource : %02X\n", SCI_INT);
287 EFPRINTF(fp, "[0004]\t\tInterrupt : %08X\n", SCI_INT);
^^^ this line ("maximum 2 bit"; SCI_INT==9)
288 EFPRINTF(fp, "[0002]\t\tFlags (decoded below) : \n");
289 EFPRINTF(fp, "\t\t\tPolarity : 3\n");
290 EFPRINTF(fp, "\t\t\tTrigger Mode : 3\n");
291 EFPRINTF(fp, "\n");

Would you mind filing a PR to track this investigation?

The error message and constraint on Value being in range of BitLength
was added to DtCompileFlag() in compiler/dtfield.c way back in r208625
(ACPICA 20100528) — it's not new.  What must be new is the idea that
these fields have a smaller bit width that the numbers bhyve has
chosen, or bhyve's choice of numbers.

We can eliminate bhyve as a suspect, maybe?  acpi.c hasn't changed
substantially for years.  In fact, there is a seemingly related commit
r272838 which converted some fields to hexadecimal in order to comply
with length limitations.  The first of these two tables was introduced
in r257933 by tycho@ / neel@.  The second was changed from a bare
constant by jhb@ in r259998, but previously held the value 9.  It
dates to the original 2012 "ACPI support for bhyve" commit by grehan@
in r243327.

So yeah, probably something changed recently in ACPICA.

Best,
Conrad

On Thu, Feb 21, 2019 at 8:38 AM Oleg Ginzburg  wrote:
>
> Hi,
>
> most likely r344398[1] commit breaks bhyve with the following errors:
>
> Subtable Type : 02
> Error6302 -   Flag value is too large ^  (Maximum 1 bit)
> 58: [0002] Flags (decoded below) : 0005
> Error6302 -   Flag value is too large ^  (Maximum 2 bit)
> 66: [0004]  Interrupt : 0009
> Error6302 -   Flag value is too large ^  (Maximum 2 bit)
> Assertion failed: (error == 0), function main, file
> /usr/src/usr.sbin/bhyve/bhyverun.c, line 1190.
>
> Can anyone else confirm this?
>
> Howto reproduce:
>
> fetch 
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/FreeBSD-10.3-RELEASE-amd64-bootonly.iso
>
> sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -i -I
> FreeBSD-10.3-RELEASE-amd64-bootonly.iso guestname
>
>
> __
> [1] - https://svnweb.freebsd.org/base?view=revision=r344398
> ___
> 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: sha256 speed

[Conrad Meyer]

There is support for the SHA intrinsic in aesni(4) that would be
relatively easy to adapt to userspace for libmd, if someone was
interested.  Especially now that we demand linker ifunc support (on
x86 platforms, at least).  I posted a patch and some performance
comparison in https://svnweb.freebsd.org/base?view=revision=r324037
.

Best,
Conrad

On Sun, Jan 6, 2019 at 4:19 PM Stefan Ehmann  wrote:
>
> Hello,
>
> On my Ryzen the sha256 command is much slower than openssl dgst -sha256.
> For large files, openssl is more than 7 times faster in practice.
>
> You can also test it with the builtin benchmarks:
> sha256 -t
> openssl speed sha256
>
> I think the reason is that openssl supports the SHA CPU extensions
> whereas libmd (used by sha256) does not.
>
> Any chance we can make the base sha256 faster?
> I guess there is some reason why we use libmd instead of openssl.
>
> https://reviews.freebsd.org/D2651 looks related but not sure it's still
> relevant.
> ___
> 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: buildworld falure: truncated or malformed archive

[Conrad Meyer]

There's always 'WITHOUT_CLANG=1' in src.conf.

Best,
Conrad

On Mon, Dec 31, 2018 at 12:09 PM Warner Losh  wrote:
>
> On Mon, Dec 31, 2018, 1:36 PM Ryan Stone 
> > Does this mean that it's currently impossible to build a world with
> > debug symbols?
> >
>
> Yes. Clang is simply too big until 64 bit offset support goes in.
>
> Warner
>
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
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: possible POLA violation for NFS server to make it Linux compatible

[Conrad Meyer]

On Tue, Dec 18, 2018 at 5:07 PM Rick Macklem  wrote:
> The change to make the FreeBSD NFSv4 server use vfs.nfsd.nfs_privport is 
> trivial
> and I think being compatible with Linux is important (I see it as the defacto
> standard NFS implementation these days).
>
> What do others think I should do?

Hi Rick,

I think we should go ahead and honor nfs_privport.

Best,
Conrad
___
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: toolchain(s) for universe kernels

[Conrad Meyer]

I use:

make -sj${NCPU} tinderbox JFLAG=-j${NCPU}
UNIVERSE_TARGET=kernel-toolchain -DNO_CLEAN

Best,
Conrad
On Mon, Nov 19, 2018 at 10:00 AM Eric van Gyzen  wrote:
>
> I want to
>
> make MAKE_JUST_KERNELS=1 universe
>
> but it seems that I need a toolchain first.  There are multiple
> toolchain-ish make targets.  If I start with an empty obj, which
> toolchain target(s) should I build?
>
> 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"
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

Perfect!  Sounds like we are on the right track, at least.

Best,
Conrad
On Tue, Nov 13, 2018 at 8:55 PM Rebecca Cran  wrote:
>
> On Tuesday, 13 November 2018 21:41:58 MST Conrad Meyer wrote:
> > You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL?
> >  I.e., sometimes the CPU chooses to report on a range from 0-225C and
> > sometimes -49C-206C.  I think someone else's 2990WX did the same
> > thing.  I guess that patch never landed?  102°C - 49°C is the very
> > reasonable 53°C.
> >
> > Yeah, sigh, it never landed:  https://reviews.freebsd.org/D16855
>
> Thanks, that's it: setting the sensor_offset sysctls to -76 results in FreeBSD
> reporting 51.1C while the readout on the motherboard shows 51C :)
>
> I'll fetch and build r340426 tomorrow.
>
> --
> Rebecca
>
>
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

Please try r340426 :-).
On Tue, Nov 13, 2018 at 8:41 PM Conrad Meyer  wrote:
>
> You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL?
>  I.e., sometimes the CPU chooses to report on a range from 0-225C and
> sometimes -49C-206C.  I think someone else's 2990WX did the same
> thing.  I guess that patch never landed?  102°C - 49°C is the very
> reasonable 53°C.
>
> Yeah, sigh, it never landed:  https://reviews.freebsd.org/D16855
>
> Ok I'll go ahead and commit that too.
>
> Thanks,
> Conrad
> On Tue, Nov 13, 2018 at 8:38 PM Conrad Meyer  wrote:
> >
> > On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran  wrote:
> > >
> > > On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote:
> > >
> > > > Maybe it should be -54 instead of +54?  183-(54*2) is the somewhat
> > > > plausible 75?C (still pretty warm even for load).  How good is your
> > > > cooling solution?
> > >
> > > D'oh, of course it's -54 instead of +54 (For some reason I presumed a 
> > > positive
> > > offset would be *subtracted*)!   I have an all-in-one liquid thermaltake
> > > cooler installed, and under Windows it reports reaching 67C when running 
> > > flat
> > > out, which doesn't seem bad.
> >
> > Yeah, 67C seems totally great at load.
> >
> > > > (The references I can find with a quick search suggest TR 29xx should
> > > > also be -27? rather than -54?C, but they may be mistaken.  183-54-27
> > > > is still 102?C ? extremely hot!)
> > >
> > > That's why I thought 54 was more likely! My 2990WX has 4 units for 32 
> > > cores
> > > instead of 2 units and 16 cores for other models, so I guessed that 
> > > perhaps I
> > > should double the 27 value other people had said should be used.
> >
> > Hm, the Linux folks still use -27 for the 2990WX as well as all of the
> > other threadripper models.  I'm not sure what's right.  I wish I had
> > access to the Ryzen 2 register docs, but I don't.
> >
> > Best,
> > Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL?
 I.e., sometimes the CPU chooses to report on a range from 0-225C and
sometimes -49C-206C.  I think someone else's 2990WX did the same
thing.  I guess that patch never landed?  102°C - 49°C is the very
reasonable 53°C.

Yeah, sigh, it never landed:  https://reviews.freebsd.org/D16855

Ok I'll go ahead and commit that too.

Thanks,
Conrad
On Tue, Nov 13, 2018 at 8:38 PM Conrad Meyer  wrote:
>
> On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran  wrote:
> >
> > On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote:
> >
> > > Maybe it should be -54 instead of +54?  183-(54*2) is the somewhat
> > > plausible 75?C (still pretty warm even for load).  How good is your
> > > cooling solution?
> >
> > D'oh, of course it's -54 instead of +54 (For some reason I presumed a 
> > positive
> > offset would be *subtracted*)!   I have an all-in-one liquid thermaltake
> > cooler installed, and under Windows it reports reaching 67C when running 
> > flat
> > out, which doesn't seem bad.
>
> Yeah, 67C seems totally great at load.
>
> > > (The references I can find with a quick search suggest TR 29xx should
> > > also be -27? rather than -54?C, but they may be mistaken.  183-54-27
> > > is still 102?C ? extremely hot!)
> >
> > That's why I thought 54 was more likely! My 2990WX has 4 units for 32 cores
> > instead of 2 units and 16 cores for other models, so I guessed that perhaps 
> > I
> > should double the 27 value other people had said should be used.
>
> Hm, the Linux folks still use -27 for the 2990WX as well as all of the
> other threadripper models.  I'm not sure what's right.  I wish I had
> access to the Ryzen 2 register docs, but I don't.
>
> Best,
> Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran  wrote:
>
> On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote:
>
> > Maybe it should be -54 instead of +54?  183-(54*2) is the somewhat
> > plausible 75?C (still pretty warm even for load).  How good is your
> > cooling solution?
>
> D'oh, of course it's -54 instead of +54 (For some reason I presumed a positive
> offset would be *subtracted*)!   I have an all-in-one liquid thermaltake
> cooler installed, and under Windows it reports reaching 67C when running flat
> out, which doesn't seem bad.

Yeah, 67C seems totally great at load.

> > (The references I can find with a quick search suggest TR 29xx should
> > also be -27? rather than -54?C, but they may be mistaken.  183-54-27
> > is still 102?C ? extremely hot!)
>
> That's why I thought 54 was more likely! My 2990WX has 4 units for 32 cores
> instead of 2 units and 16 cores for other models, so I guessed that perhaps I
> should double the 27 value other people had said should be used.

Hm, the Linux folks still use -27 for the 2990WX as well as all of the
other threadripper models.  I'm not sure what's right.  I wish I had
access to the Ryzen 2 register docs, but I don't.

Best,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 8:05 PM Rebecca Cran  wrote:
>
> On Tuesday, 13 November 2018 16:20:22 MST Stefan Ehmann wrote:
>
> > The 2700 has an offset of 0 though (2700X has 10).
> > And I'm seeing a difference of more than 30 degrees. I guess something
> > else must be happening here.
>
> I had thought 54 was the right offset for my 2990WX system, but now it's under
> load building ports the temperature reported via dev.amdtemp is 183C!
> Meanwhile the readout on the motherboard says "CPU Temp 53 C".

Maybe it should be -54 instead of +54?  183-(54*2) is the somewhat
plausible 75°C (still pretty warm even for load).  How good is your
cooling solution?

(The references I can find with a quick search suggest TR 29xx should
also be -27° rather than -54°C, but they may be mistaken.  183-54-27
is still 102°C — extremely hot!)

Best,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 7:16 PM Daniel Eischen  wrote:
>
> On Tue, 13 Nov 2018, Conrad Meyer wrote:
>
> > On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:
> >> I've attached it.  If it gets filtered by the mail list, I'll
> >> make it http accessible.
> >
> > Thanks Daniel.
> >
> > It looks like your hostbridge zero device has a different device id
> > than in my first generation Ryzen system.  Would you please try the
> > following patch and see if it attaches on your system?  I don't
> > actually have documentation for Ryzen 2, unfortunately, so I'm not
> > totally sure if the SMN is accessed in the same way for the new
> > hostbridge device id.  The change below should at least attempt
> > attaching to hostb0 on your system.
>
> That seems to have done the trick, thanks!  Output
> attached.

Thanks for the quick test!  I've committed Johannes' substantially
similar patch as r340425.

Cheers,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

Of course, Johannes has already thought of this!  See
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228480 and
https://reviews.freebsd.org/D15567 .
On Tue, Nov 13, 2018 at 6:41 PM Conrad Meyer  wrote:
>
> On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:
> > I've attached it.  If it gets filtered by the mail list, I'll
> > make it http accessible.
>
> Thanks Daniel.
>
> It looks like your hostbridge zero device has a different device id
> than in my first generation Ryzen system.  Would you please try the
> following patch and see if it attaches on your system?  I don't
> actually have documentation for Ryzen 2, unfortunately, so I'm not
> totally sure if the SMN is accessed in the same way for the new
> hostbridge device id.  The change below should at least attempt
> attaching to hostb0 on your system.
>
> diff --git a/sys/dev/amdsmn/amdsmn.c b/sys/dev/amdsmn/amdsmn.c
> index 17792dd922cd..6fe36b4cc4da 100644
> --- a/sys/dev/amdsmn/amdsmn.c
> +++ b/sys/dev/amdsmn/amdsmn.c
> @@ -60,7 +60,8 @@ struct amdsmn_softc {
>  static struct pciid {
> uint32_tdevice_id;
>  } amdsmn_ids[] = {
> -   { 0x14501022 },
> +   { 0x14501022 }, /* Ryzen */
> +   { 0x15d01022 }, /* Ryzen 2 */
>  };
>
>  /*
> diff --git a/sys/dev/amdtemp/amdtemp.c b/sys/dev/amdtemp/amdtemp.c
> index 2463212c25f5..765e660a8461 100644
> --- a/sys/dev/amdtemp/amdtemp.c
> +++ b/sys/dev/amdtemp/amdtemp.c
> @@ -102,6 +102,7 @@ static struct amdtemp_product {
> { VENDORID_AMD, DEVICEID_AMD_MISC16_M30H },
> { VENDORID_AMD, DEVICEID_AMD_MISC17 },
> { VENDORID_AMD, DEVICEID_AMD_HOSTB17H },
> +   { VENDORID_AMD, 0x15d0 },
>  };
>
>  /*
>
>
> Thanks,
> Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:
> I've attached it.  If it gets filtered by the mail list, I'll
> make it http accessible.

Thanks Daniel.

It looks like your hostbridge zero device has a different device id
than in my first generation Ryzen system.  Would you please try the
following patch and see if it attaches on your system?  I don't
actually have documentation for Ryzen 2, unfortunately, so I'm not
totally sure if the SMN is accessed in the same way for the new
hostbridge device id.  The change below should at least attempt
attaching to hostb0 on your system.

diff --git a/sys/dev/amdsmn/amdsmn.c b/sys/dev/amdsmn/amdsmn.c
index 17792dd922cd..6fe36b4cc4da 100644
--- a/sys/dev/amdsmn/amdsmn.c
+++ b/sys/dev/amdsmn/amdsmn.c
@@ -60,7 +60,8 @@ struct amdsmn_softc {
 static struct pciid {
uint32_tdevice_id;
 } amdsmn_ids[] = {
-   { 0x14501022 },
+   { 0x14501022 }, /* Ryzen */
+   { 0x15d01022 }, /* Ryzen 2 */
 };

 /*
diff --git a/sys/dev/amdtemp/amdtemp.c b/sys/dev/amdtemp/amdtemp.c
index 2463212c25f5..765e660a8461 100644
--- a/sys/dev/amdtemp/amdtemp.c
+++ b/sys/dev/amdtemp/amdtemp.c
@@ -102,6 +102,7 @@ static struct amdtemp_product {
{ VENDORID_AMD, DEVICEID_AMD_MISC16_M30H },
{ VENDORID_AMD, DEVICEID_AMD_MISC17 },
{ VENDORID_AMD, DEVICEID_AMD_HOSTB17H },
+   { VENDORID_AMD, 0x15d0 },
 };

 /*


Thanks,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 5:15 PM Rozhuk Ivan  wrote:
>
> On Tue, 13 Nov 2018 19:41:47 -0500
> Daniel Eischen  wrote:
>
> > >> I'm trying to track down a couple of things.  amdtemp doesn't
> > >> report any temperature sensors, and acpi seems to have some
> > >> errors.  Not sure if they are related.
> > >
> > > It s a bit legacy )
> > > Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
> > > does not use amdsmn.
> >
> > Thanks, I think?!  I tried it and it panic'd as soon as it was
> > kldload'd.  I don't have the trace back handy, but it was in a mtx
> > lock after a pci_write.  I'm running 13-current, so it could be
> > something different between that and -stable or whatever you're
> > testing it on.
>
>
> I do not test it on 13.
> Make sure that you have not amdtemp and amdsmn built in kernel and that they 
> not loaded.

Your amdtemp_rtc_temp_sysctl has a lock recursion bug and any
INVARIANTS kernel will panic running it.
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

Hi Daniel,

On Tue, Nov 13, 2018 at 10:01 AM Daniel Eischen  wrote:
>
> Greetings,
>
> I'm trying to track down a couple of things.  amdtemp doesn't
> report any temperature sensors, and acpi seems to have some
> errors.  Not sure if they are related.

Maybe not.  If they do not attach, it suggests that maybe the Ryzen 2
has a different hostbridge PCI devid.

> ...
> The amdtemp module loads fine (including the dependent amdsmn), but
> doesn't report any temperature related sysctls.

Can you run 'devinfo -v' and send or paste the output?  Thank you.

All the best,
Conrad
___
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: Hole-punching, TRIM, etc

[Conrad Meyer]

On Tue, Nov 13, 2018 at 2:59 PM Alan Somers  wrote:
>
> On Tue, Nov 13, 2018 at 3:51 PM Conrad Meyer  wrote:
>>
>> On Tue, Nov 13, 2018 at 2:10 PM Alan Somers  wrote:
>> > ...
>> > 8) Add aio_freesp(2), an asynchronous version of fcntl(F_FREESP).
>>
>> Why not just add DIOCGDELETE support to various VOP_IOCTL
>> implementations?  The file objects forward correctly through vn_ioctl
>> to VOP_IOCTL for both regular files and devfs VCHR nodes.
>>
>> We can emulate the Linux API if we want to be compatible there, but I
>> wouldn't bother with Solaris.
>
> The only reason that I prefer the Solaris API is because it doesn't require 
> adding another syscall, and because Linux's fallocate(2) does a whole bunch 
> of other things besides hole-punching.

I am imagining that if we went this route, we would implement Linux
fallocate as a library shim around the native FreeBSD ioctl (or
whatever) rather than an independent system call.  This would be for
API compatibility, not ABI compatibility.  But Linux compat can be set
aside for now, I think — it's a secondary concern.

> What about an asynchronous version?  ioctl(2) is still synchronous.  Do you 
> see any better way to hole-punch/TRIM asynchronously than with aio?

Yeah, this is a good consideration.  No, I don't have any better
suggestion for an asynchronous API.  In general our VOPs tend to be
synchronous.  Aio does seem like the logical home for a new
asynchronous API.

Best regards,
Conrad
___
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: Hole-punching, TRIM, etc

[Conrad Meyer]

Hi Alan,

On Tue, Nov 13, 2018 at 2:10 PM Alan Somers  wrote:
>
> Hole-punching has been discussed on these lists before[1].  It basically
> means to turn a dense file into a sparse file by deallocating storage for
> some of the blocks in the middle.  There's no standard API for it.  Linux
> uses fallocate(2); Solaris and OSX add a new opcode to fcntl(2).
>
> A related concept is telling a block device that some blocks are no longer
> used.  SATA calls this "TRIM", SCSI calls it "UNMAP", NVMe calls it
> "Deallocate", ZBC and ZAC call it "Reset Write Pointer".  They all do
> basically the same thing, and it's analogous to hole-punching for regular
> files.  They are also all inaccessible from FreeBSD's userland except by
> using pass(4), which is inconvenient and protocol-specific.

Geom devices have the DIOCGDELETE ioctl, which translates into
BIO_DELETE (which is TRIM, as I understand it).  It's available in
libgeom as g_delete() and used by hastd, newfs_nandfs, and nandtool.

> Linux has a BLKDISCARD ioctl for issuing TRIM-like commands from userland,
> but it's totally undocumented and doesn't work on regular files.
>
> I propose adding support for all of these things using the fcntl(2) API.
> Using the same syntax that Solaris defined, you would be able to punch a
> hole in a regular file or TRIM blocks from an SSD.  ZFS already supports it
> (though FreeBSD's port never did, and the code was deleted in r303763).
> Here's what I would do:
>
> 1) Add the F_FREESP command to fcntl(2).
> 2) Add a .fo_space field for struct fileops
> 3) Add a devfs_space method that implements .fo_space
> 4) Add a .d_space field to struct cdevsw
> 5) Add a g_dev_space method for GEOM that implements .d_space using
> BIO_DELETE.
> 6) Add a VOP_SPACE vop
> 7) Implement VOP_SPACE for tmpfs
> 8) Add aio_freesp(2), an asynchronous version of fcntl(F_FREESP).

Why not just add DIOCGDELETE support to various VOP_IOCTL
implementations?  The file objects forward correctly through vn_ioctl
to VOP_IOCTL for both regular files and devfs VCHR nodes.

We can emulate the Linux API if we want to be compatible there, but I
wouldn't bother with Solaris.

Best,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 1:04 PM Stefan Ehmann  wrote:
> After kldload amdtemp I see the following sysctls:
> dev.cpu.0.temperature: 77.1C
> dev.amdtemp.0.core0.sensor0: 77.1C
>
> The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
> know if just the offset is wrong or the numbers are completely bogus.
>
> Numbers from sysutils/xmbmon look saner but not sure if they are correct.

You can adjust dev.amdtemp.N.sensor_offset as needed.  By default, the
amdtemp sysctl gives you the unadjusted value.  On different Ryzen
models the raw value is wrong by different amounts.  E.g. on my 1950X,
I have sensor_offset set to "-27" to show correct temperature
readings.

See this link for a table of offset values for various Ryzen models:
https://www.guru3d.com/articles-pages/amd-ryzen-7-2700-review,7.html

Take care,
Conrad
___
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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

[Conrad Meyer]

One thing that may allow progress is explicitly passing the path to a
new enough linker to make.

In the past when some I encountered a similar problem (I use
amd64-xtoolchain-gcc, amd64-gcc, and binutils for toolchain, and due
to some miscommunication the wrong linker was selected automatically),
I had good results passing an explicit linker LD like:

LD=/usr/local/bin/ld make -sj4 buildkernel KERNCONF=foo
CROSS_TOOLCHAIN=amd64-gcc

Best,
Conrad

On Fri, Sep 21, 2018 at 9:10 PM, Rebecca Cran  wrote:
> On 9/21/18 10:00 PM, Warner Losh wrote:
>
>> That may be the issue... Does the patch I included help? I'm building now
>> on my stable system, but it's slow...
>
>
> It does seem to have got further this time, so a cautious yes.
>
>
> --
> Rebecca
>
> ___
> 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: newfs silently fails if random is not ready (?)

[Conrad Meyer]

Differential up here: https://reviews.freebsd.org/D17049 for any
lurkers I didn't manage to tag in the review.

Best,
Conrad

On Wed, Sep 5, 2018 at 12:57 AM, Mark R V Murray  wrote:
> Nice catch! Thanks :-)
>
> M
>
>
>> On 5 Sep 2018, at 04:13, Conrad Meyer  wrote:
>>
>> Hi Lev,
>>
>> I took a first attempt at reproducing this problem on a fast
>> desktop-class system.  First steps, give us a way to revert back to
>> unseeded status:
>>
>> --- a/sys/dev/random/fortuna.c
>> +++ b/sys/dev/random/fortuna.c
>> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>>
>> #ifdef _KERNEL
>> #include 
>> +#include 
>> #include 
>> #include 
>> #include 
>> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
>>return;
>>}
>>
>> +   /*
>> +* When set, pretend we do not have enough entropy to reseed yet.
>> +*/
>> +   KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
>> +   if (RETURN_VALUE != 0) {
>> +   RANDOM_RESEED_UNLOCK();
>> +   return;
>> +   }
>> +   });
>> +
>> +
>> #ifdef _KERNEL
>>fortuna_state.fs_lasttime = now;
>> #endif
>> @@ -442,5 +454,11 @@ bool
>> random_fortuna_seeded(void)
>> {
>>
>> +   /* When set, act as if we are not seeded. */
>> +   KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
>> +   if (RETURN_VALUE != 0)
>> +   fortuna_state.fs_counter = UINT128_ZERO;
>> +   });
>> +
>>return (!uint128_is_zero(fortuna_state.fs_counter));
>> }
>>
>>
>> Second step, enable the failpoints and launch repro program:
>>
>> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
>> debug.fail_point.random_fortuna_pre_read: off -> return(1)
>> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
>> debug.fail_point.random_fortuna_seeded: off -> return(1)
>>
>> $ cat ./blocked_random_poc.c
>> #include 
>> #include 
>> #include 
>>
>> int
>> main(int argc, char **argv)
>> {
>>printf("%x\n", arc4random());
>>return (0);
>> }
>>
>>
>> $ ./blocked_random_poc
>> ...
>>
>>
>> Third step, I looked at what that process was doing:
>>
>> Curiously, it is not in getrandom() at all, but instead the ARND
>> sysctl fallback.  I probably need to rebuild world (libc) to test this
>> (new libc arc4random based on Chacha).
>>
>> $ procstat -kk 1196
>>  PIDTID COMMTDNAME  KSTACK
>> 1196 100435 blocked_random_poc  -   read_random+0x3d
>> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
>> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
>> amd64_syscall+0x940 fast_syscall_common+0x101
>>
>>
>> When I unblocked the failpoints, it completed successfully:
>>
>> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
>> debug.fail_point.random_fortuna_pre_read: return(1) -> off
>> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off
>> debug.fail_point.random_fortuna_seeded: return(1) -> off
>>
>> ...
>> 9e5eb30f
>>
>>
>> Best,
>> Conrad
>> ___
>> 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"
>>
>
> --
> Mark R V Murray
>
___
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: newfs silently fails if random is not ready (?)

[Conrad Meyer]

With current libc, I instead see:

load: 0.10  cmd: blocked_random_poc 1668 [randseed] 1.27r 0.00u 0.00s
0% 2328k (SIGINFO)

$ procstat -kk 1668
  PIDTID COMMTDNAME  KSTACK
 1668 100609 blocked_random_poc  -   mi_switch+0xd3
sleepq_catch_signals+0x386 sleepq_timedwait_sig+0x12 _sleep+0x272
read_random_uio+0xb3 sys_getrandom+0xa3 amd64_syscall+0x940
fast_syscall_common+0x101

and:

$ truss ./blocked_random_poc
...
getrandom(0x7fffd340,40,0)   ERR#35 'Resource
temporarily unavailable'
thr_self(0x7fffd310) = 0 (0x0)
thr_kill(100609,SIGKILL) = 0 (0x0)
SIGNAL 9 (SIGKILL) code=SI_NOINFO

So getrandom(2) (via READ_RANDOM_UIO) is returning a bogus EAGAIN
after we have already slept until random was seeded.  This bubbles up
to getentropy(3) -> arc4random(3), which sees a surprising failure
from getentropy(3) and raises KILL against the program.

I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout
condition.  This may be sufficient to fix the problem:

--- a/sys/dev/random/randomdev.c
+++ b/sys/dev/random/randomdev.c
@@ -156,6 +156,10 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock)
error = tsleep(_alg_context, PCATCH, "randseed", hz/10);
if (error == ERESTART || error == EINTR)
break;
+   /* Squash hz/10 timeout condition */
+   if (error == EWOULDBLOCK)
+   error = 0;
+   KASSERT(error == 0, ("unexpected %d", error));
}
if (error == 0) {
read_rate_increment((uio->uio_resid +
sizeof(uint32_t))/sizeof(uint32_t));


Best,
Conrad


On Tue, Sep 4, 2018 at 8:13 PM, Conrad Meyer  wrote:
> Hi Lev,
>
> I took a first attempt at reproducing this problem on a fast
> desktop-class system.  First steps, give us a way to revert back to
> unseeded status:
>
> --- a/sys/dev/random/fortuna.c
> +++ b/sys/dev/random/fortuna.c
> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>
>  #ifdef _KERNEL
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
> return;
> }
>
> +   /*
> +* When set, pretend we do not have enough entropy to reseed yet.
> +*/
> +   KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
> +   if (RETURN_VALUE != 0) {
> +   RANDOM_RESEED_UNLOCK();
> +   return;
> +   }
> +   });
> +
> +
>  #ifdef _KERNEL
> fortuna_state.fs_lasttime = now;
>  #endif
> @@ -442,5 +454,11 @@ bool
>  random_fortuna_seeded(void)
>  {
>
> +   /* When set, act as if we are not seeded. */
> +   KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
> +   if (RETURN_VALUE != 0)
> +   fortuna_state.fs_counter = UINT128_ZERO;
> +   });
> +
> return (!uint128_is_zero(fortuna_state.fs_counter));
>  }
>
>
> Second step, enable the failpoints and launch repro program:
>
> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
> debug.fail_point.random_fortuna_pre_read: off -> return(1)
> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
> debug.fail_point.random_fortuna_seeded: off -> return(1)
>
> $ cat ./blocked_random_poc.c
> #include 
> #include 
> #include 
>
> int
> main(int argc, char **argv)
> {
> printf("%x\n", arc4random());
> return (0);
> }
>
>
> $ ./blocked_random_poc
> ...
>
>
> Third step, I looked at what that process was doing:
>
> Curiously, it is not in getrandom() at all, but instead the ARND
> sysctl fallback.  I probably need to rebuild world (libc) to test this
> (new libc arc4random based on Chacha).
>
> $ procstat -kk 1196
>   PIDTID COMMTDNAME  KSTACK
>  1196 100435 blocked_random_poc  -   read_random+0x3d
> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
> amd64_syscall+0x940 fast_syscall_common+0x101
>
>
> When I unblocked the failpoints, it completed successfully:
>
> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
> debug.fail_point.random_fortuna_pre_read: return(1) -> off
> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off
> debug.fail_point.random_fortuna_seeded: return(1) -> off
>
> ...
> 9e5eb30f
>
>
> Best,
> Conrad
___
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: newfs silently fails if random is not ready (?)

[Conrad Meyer]

Hi Lev,

I took a first attempt at reproducing this problem on a fast
desktop-class system.  First steps, give us a way to revert back to
unseeded status:

--- a/sys/dev/random/fortuna.c
+++ b/sys/dev/random/fortuna.c
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");

 #ifdef _KERNEL
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
return;
}

+   /*
+* When set, pretend we do not have enough entropy to reseed yet.
+*/
+   KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
+   if (RETURN_VALUE != 0) {
+   RANDOM_RESEED_UNLOCK();
+   return;
+   }
+   });
+
+
 #ifdef _KERNEL
fortuna_state.fs_lasttime = now;
 #endif
@@ -442,5 +454,11 @@ bool
 random_fortuna_seeded(void)
 {

+   /* When set, act as if we are not seeded. */
+   KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
+   if (RETURN_VALUE != 0)
+   fortuna_state.fs_counter = UINT128_ZERO;
+   });
+
return (!uint128_is_zero(fortuna_state.fs_counter));
 }


Second step, enable the failpoints and launch repro program:

$ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
debug.fail_point.random_fortuna_pre_read: off -> return(1)
$ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
debug.fail_point.random_fortuna_seeded: off -> return(1)

$ cat ./blocked_random_poc.c
#include 
#include 
#include 

int
main(int argc, char **argv)
{
printf("%x\n", arc4random());
return (0);
}


$ ./blocked_random_poc
...


Third step, I looked at what that process was doing:

Curiously, it is not in getrandom() at all, but instead the ARND
sysctl fallback.  I probably need to rebuild world (libc) to test this
(new libc arc4random based on Chacha).

$ procstat -kk 1196
  PIDTID COMMTDNAME  KSTACK
 1196 100435 blocked_random_poc  -   read_random+0x3d
sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
amd64_syscall+0x940 fast_syscall_common+0x101


When I unblocked the failpoints, it completed successfully:

$ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
debug.fail_point.random_fortuna_pre_read: return(1) -> off
$ sudo sysctl debug.fail_point.random_fortuna_seeded=off
debug.fail_point.random_fortuna_seeded: return(1) -> off

...
9e5eb30f


Best,
Conrad
___
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: newfs silently fails if random is not ready (?)

[Conrad Meyer]

On Tue, Sep 4, 2018 at 2:10 PM, Lev Serebryakov  wrote:
> Wednesday, September 5, 2018, 12:05:43 AM, you wrote:
>> I think it is tripping on raise/abort() in one of these routines, but
>> nothing is printing that information.  See below.
>
>  Maybe, it should be fixed?

Yes, it should.

> One second after that random is ready to use and
> newfs works as intended. It is, really, some race between early init script
> (rc.initdiskless) and kernel. I don't think, that newfs must be
> killed/aborted in such situation, it could wait!

I agree.  It looks like it is waiting, in fact, but then Something Bad
Happens when the random device is unblocked.

>> Ah, thanks.  I missed this.  mdmfs(8) has a bug in its run() function.
>> It treats programs that exit with a signal (KILL, ABRT, ILL, SEGV...)
>> the same as programs that exit with success.  This is a (major)
>> problem and the reason raise/abort is not visible.
>
>  And it is another problem. But if it will be fixed, it doesn't help to init
> system properly in my case, only diagnostic will be better.

Yep.

Best,
Conrad
___
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: newfs silently fails if random is not ready (?)

[Conrad Meyer]

Hi Lev,

On Tue, Sep 4, 2018 at 1:55 PM, Lev Serebryakov  wrote:
> Tuesday, September 4, 2018, 11:37:59 PM, you wrote:
>> Is newfs tripping on a raise()/abort() in arc4random(3) /
>> getentropy(3)?
>   Nope, it is silently does nothing

I think it is tripping on raise/abort() in one of these routines, but
nothing is printing that information.  See below.

>>   Is your program that runs newfs checking for non-zero
>> exit status?
>   It is not "my" program, it is system mdmfs(8), and it checks exit
>  statuses, as far as I can see from source code.

Ah, thanks.  I missed this.  mdmfs(8) has a bug in its run() function.
It treats programs that exit with a signal (KILL, ABRT, ILL, SEGV...)
the same as programs that exit with success.  This is a (major)
problem and the reason raise/abort is not visible.

Best,
Conrad
___
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: newfs silently fails if random is not ready (?)

[Conrad Meyer]

Hi Lev,

Newfs just uses arc4random(3) to generate its FSID and generation
numbers.  arc4random(3) is seeded from getentropy(3) -> getrandom(2)
-> read_random_uio(9), which is what produces the "random:
read_random_uio unblock wait" messages.

Is newfs tripping on a raise()/abort() in arc4random(3) /
getentropy(3)?  Is your program that runs newfs checking for non-zero
exit status?  Do you see any newfs cores when this happens?

Thanks,
Conrad

On Tue, Sep 4, 2018 at 1:08 PM, Lev Serebryakov  wrote:
> Hello FreeBSD,
>
>  I have problems with diskless install when kernel doesn't have tmpfs and
> random device takes long time to unlock.
>
>  Looks like newfs used to create in-memory /etc (on /dev/md0) silently fail
> to create FS.
>
>  I've added '-XL' options to mdmfs and it looks like this:
>
> da0: quirks=0x2
> arc4random: no preloaded entropy cache
> arc4random: no preloaded entropy cache
> *** Figure out our NFS root path ***
> *** handle_remount /conf ***
> *** templates are base default ***
> *** handle_remount /conf/base/etc ***
> *** handle_remount /conf/base/var ***
> *** handle_remount /conf/default/etc ***
> *** handle_remount /conf/default/var ***
> *** create_md etc with size 20480 ***
> DEBUG: running: /sbin/mdconfig -a -t swap -s 10485760B
> DEBUG: running: /sbin/newfs -U /dev/md0
> random: read_random_uio unblock wait
> random: read_random_uio unblock wait
> random: unblocking device.
> DEBUG: running: /sbin/mount /dev/md0 /etc
> mount: /dev/md0: No such file or directory
> mdmfs: mount exited with error code 1
>
>  "/dev/md0" is here, but it is empty, without any FS.
>
>  I could run "/sbin/newfs -U /dev/md0" later by hands and it works.
>
> --
> Best regards,
>  Lev  mailto:l...@freebsd.org
>
> ___
> freebsd...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-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: github freebsd and svn freebsd

[Conrad Meyer]

On Tue, Sep 4, 2018 at 3:32 AM, tech-lists  wrote:
> Hello list,
>
> What's the difference between github freebsd and svn freebsd, other than one
> is on github and the other is on svn?

The github repository is  read-only mirror -- new additions all come
through SVN.

> How does one transcode or translate a git commit reference into a svn
> reference number?

See https://wiki.freebsd.org/GitWorkflow and look for "notes."

Best,
Conrad
___
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: ffs_truncate3 panics

[Conrad Meyer]

On Wed, Aug 8, 2018 at 5:30 AM, Rick Macklem  wrote:
> - Oh, and this is an old i386 with 256Mbytes (not one of them new fangled 
> computers,
>where memory is in Gbytes;-)

Have you run memtest86+ recently?

Best,
Conrad
___
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: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

For those not on the bug, this is being followed up in PR 230290.

On Wed, Aug 1, 2018 at 10:27 PM, Johannes Lundberg  wrote:
>
>
> On Thu, Aug 2, 2018 at 06:20 Andriy Gapon  wrote:
>>
>> On 02/08/2018 01:17, Conrad Meyer wrote:
>> > I don't understand the concern.  There is only one listener to the
>> > event and it just invokes ReqSleepState, which is responsible for
>> > performing all suspend behavior.  The behavior is identical between
>> > lid close and acpiconf.
>>
>> Unless someone is adding a new listener for that event.
>
>
> Exactly my point.
>
>>
>> --
>> Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

I don't understand the concern.  There is only one listener to the
event and it just invokes ReqSleepState, which is responsible for
performing all suspend behavior.  The behavior is identical between
lid close and acpiconf.

On Wed, Aug 1, 2018 at 3:00 PM, Johannes Lundberg  wrote:
>
>
> On Wed, Aug 1, 2018 at 22:55 Conrad Meyer  wrote:
>>
>> ReqSleepState is the routine that takes care of suspend, not the
>> eventhandler.  I'm not sure what difference the proposed change is
>> supposed to make.
>
>
> Listeners to acpi_sleep_event don’t get the event when suspending with
> acpiconf (but they do when suspending via lid or sleep button).
>
> I think one would expect the same behavior when suspending via command line
> or physical switch.
>
>
>>
>>
>> Best,
>> Conrad
>>
>> On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg 
>> wrote:
>> >
>> >
>> > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:
>> >>
>> >> It seems deliberate, although the commit message does not call it out
>> >> and the event is perhaps poorly named.  The event currently indicates
>> >> that the lid was closed.  And the final registered eventhandler for
>> >> the event calls ReqSleepState.
>> >>
>> >> The ReqSleepState routine, as well as the userspace ioctl that
>> >> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
>> >> than invoking the acpi sleep event), were introduced together in
>> >> r170976.
>> >>
>> >
>> > Unless there's a way of calling suspend properly from the cli (zzz uses
>> > acpiconf...) maybe something like this makes more sense to get the same
>> > behavior on for example lid close as zzz or acpiconf -s 3? (untested)
>> >
>> > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
>> > index c1bfd880c89..87b506d6bf5 100644
>> > --- a/sys/dev/acpica/acpi.c
>> > +++ b/sys/dev/acpica/acpi.c
>> > @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t
>> > addr,
>> > int flag, struct thread *t
>> >  case ACPIIO_REQSLPSTATE:
>> > state = *(int *)addr;
>> > if (state != ACPI_STATE_S5)
>> > -   return (acpi_ReqSleepState(sc, state));
>> > +   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
>> > +   acpi_invoke_sleep_eventhandler, )) ? 0 :
>> > ENXIO;
>> > device_printf(sc->acpi_dev, "power off via acpi ioctl not
>> > supported\n");
>> > error = EOPNOTSUPP;
>> > break;
>> >
>> >
>> >>
>> >> Best,
>> >> Conrad
>> >>
>> >> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
>> >> wrote:
>> >> > Hi
>> >> >
>> >> > As the title says, callbacks registered with
>> >> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
>> >> > does not get called when calling acpiconf -s 3.
>> >> > They do however, when suspending with lid or sleep button.
>> >> >
>> >> > Is this deliberate or an oversight?
>> >> >
>> >> > Cheers
>> >> > ___
>> >> > 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: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

ReqSleepState is the routine that takes care of suspend, not the
eventhandler.  I'm not sure what difference the proposed change is
supposed to make.

Best,
Conrad

On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg  wrote:
>
>
> On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:
>>
>> It seems deliberate, although the commit message does not call it out
>> and the event is perhaps poorly named.  The event currently indicates
>> that the lid was closed.  And the final registered eventhandler for
>> the event calls ReqSleepState.
>>
>> The ReqSleepState routine, as well as the userspace ioctl that
>> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
>> than invoking the acpi sleep event), were introduced together in
>> r170976.
>>
>
> Unless there's a way of calling suspend properly from the cli (zzz uses
> acpiconf...) maybe something like this makes more sense to get the same
> behavior on for example lid close as zzz or acpiconf -s 3? (untested)
>
> diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
> index c1bfd880c89..87b506d6bf5 100644
> --- a/sys/dev/acpica/acpi.c
> +++ b/sys/dev/acpica/acpi.c
> @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t addr,
> int flag, struct thread *t
>  case ACPIIO_REQSLPSTATE:
> state = *(int *)addr;
> if (state != ACPI_STATE_S5)
> -   return (acpi_ReqSleepState(sc, state));
> +   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
> +   acpi_invoke_sleep_eventhandler, )) ? 0 :
> ENXIO;
> device_printf(sc->acpi_dev, "power off via acpi ioctl not
> supported\n");
> error = EOPNOTSUPP;
> break;
>
>
>>
>> Best,
>> Conrad
>>
>> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
>> wrote:
>> > Hi
>> >
>> > As the title says, callbacks registered with
>> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
>> > does not get called when calling acpiconf -s 3.
>> > They do however, when suspending with lid or sleep button.
>> >
>> > Is this deliberate or an oversight?
>> >
>> > Cheers
>> > ___
>> > 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: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

It seems deliberate, although the commit message does not call it out
and the event is perhaps poorly named.  The event currently indicates
that the lid was closed.  And the final registered eventhandler for
the event calls ReqSleepState.

The ReqSleepState routine, as well as the userspace ioctl that
'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
than invoking the acpi sleep event), were introduced together in
r170976.

Best,
Conrad

On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg  wrote:
> Hi
>
> As the title says, callbacks registered with
> EVENTHANDLER_REGISTER(acpi_sleep_event, 
> does not get called when calling acpiconf -s 3.
> They do however, when suspending with lid or sleep button.
>
> Is this deliberate or an oversight?
>
> Cheers
> ___
> 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: Changes to sysctl values

[Conrad Meyer]

On Thu, Jul 26, 2018 at 8:52 PM, Shane Ambler  wrote:
> I use devel/py-sysctl in some scripts to get values, using a recent
> 12-current (r336728) I see at least two values that get a different
> value type than on 11-stable. Same version of python and port.
> ...

Hi Shane,

At some point, new sysctl types were added to the kernel, including
CTLTYPE_U32.  As part of the conversion to the counter(9) API, it
seems the v_wire_count (and other vm.stats sysctls) changed to U32
type.  py-sysctl lacks support for CTLTYPE_U32 and defaults to giving
you a bytearray for unrecognized types.

Best,
Conrad
___
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 do I use the make universe machines?

[Conrad Meyer]

On Tue, Jun 5, 2018 at 6:12 PM, Benjamin Kaduk  wrote:
> On Wed, Jun 06, 2018 at 12:47:17AM +, Rick Macklem wrote:
>> I've heard mention of "make universe" machines multiple times,
>> but have no idea how to use them?
>> Is there doc on this?
>>
>> Thanks, rick
>> ps: I'll admit I haven't looked at the developer's guide in a long time.
>
> I think https://www.freebsd.org/internal/machines.html sounds like
> the page you're looking for.  (universe is just a top-level make
> target like buildworld, but will take a while on non-beefy
> hardware.)

Hi Rick,

Yep, those are the machines you want.  Note those host names listed
are subdomains below the top-level freebsd.org domain.  All of the
'universeNNa' hostnames are jails on a single, relatively beefy server
running CURRENT, and the 'universeNNb' hostnames are all jails on a
different, relatively beefy server running CURRENT.  SSH credentials
are the same as for freefall.

Conveniently, motd on these machines contains the usual convention for
running the universe target on them:

Hint: env MAKEOBJDIRPREFIX=/scratch/tmp/$USER/obj \
  make -s -j8 __MAKE_CONF=/dev/null tinderbox

I would modify that slightly, replacing -j8 with -j$(sysctl -n
hw.ncpu), in the usual case that no one else is utilizing the machine
at the same time.  -DNO_CLEAN might be quite useful for incremental
polishing work on a patch for any previously failed arches.  The clean
build should finish in under an hour, IIRC.

Best,
Conrad
___
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: svn commit: r333240 - in head/sys: powerpc/powerpc sys [appears to have broken the builds of head for riscv64]

[Conrad Meyer]

The same change as for powerpc needs to be made for riscv — the
(bcopy) trick — to avoid expansion.

Best,
Conrad

P.S., Mark, your email server is misconfigured and most/all of your
emails get flagged as spam.  I only saw this because I occasionally
check the spam folder.

On Sat, May 5, 2018 at 4:39 PM, Mark Millard  wrote:
> --- bcopy.o ---
> In file included from /workspace/src/sys/riscv/riscv/bcopy.c:39:0:
> /workspace/src/sys/sys/systm.h:262:31: error: expected identifier or '(' 
> before '{' token
>  #define bcopy(from, to, len) ({\
>^
> /workspace/src/sys/riscv/riscv/bcopy.c:134:1: note: in expansion of macro 
> 'bcopy'
>  bcopy(const void *src0, void *dst0, size_t length)
>  ^
___
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: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

[Conrad Meyer]

Hi Vitalij,

On Mon, Apr 16, 2018 at 3:27 AM, Vitalij Satanivskij  wrote:
> DUMP can be found here http://hell.ukr.net/panic/panic.jpg
> or even video record from screen http://hell.ukr.net/panic/recorder.webm

Looks like the panic message is printed directly after: "igb0: using 2
rx queues 2 tx queues" (iflib_msix_init(), called by
iflib_device_register()).

And stack is indeed coming from iflib in probe (0:17 in linked video):

panic()
nexus_add_irq()
msix_alloc()
pci_alloc_msix_method()
iflib_device_register()
iflib_device_attach()
device_attach()
...

Stephen, Matt, or Sean might be able to help diagnose further.

Best,
Conrad
___
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: clang manual page?

[Conrad Meyer]

I think we're on the same page about the deficiency of system Clang's
manual page, if little else...

On Thu, Apr 5, 2018 at 5:56 PM, Steve Kargl
<s...@troutmask.apl.washington.edu> wrote:
> I never said that you said it was in base.  I'm noting that
> referring a user to a non-existent manual page is of little
> help.  In fact, your 7 word response is an affirmation that
> the tools supplied in base should be properly documented.
>
> --
> steve
>
>
>
> On Thu, Apr 05, 2018 at 05:42:58PM -0700, Conrad Meyer wrote:
>> I never said it was in base.
>>
>> On Thu, Apr 5, 2018 at 5:15 PM, Steve Kargl
>> <s...@troutmask.apl.washington.edu> wrote:
>> > This assumes that a gcc(1) is available on the system.
>> >
>> > % man gcc
>> > No manual entry for gcc
>> >
>> > If the system compiler is clang/clang++, then it ought to be
>> > documented better than it currently is.  Ian's suggests for
>> > 'clang --help' is even worse
>> >
>> > %  clang --help | grep -- -std
>> >   -cl-std= OpenCL language standard to compile for.
>> >   -std=Language standard to compile for
>> >   -stdlib= C++ standard library to use
>> >
>> > Does  == ?
>> >
>> > --
>> > steve
>> >
>> > On Thu, Apr 05, 2018 at 04:37:38PM -0700, Conrad Meyer wrote:
>> >> To a first order approximation, the manual page for clang is gcc(1).
>> >>
>> >> Conrad
>> >>
>> >> On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl
>> >> <s...@troutmask.apl.washington.edu> wrote:
>> >> > Is anyone working on fixing the clang manual to actually
>> >> > document the available options?
>> >> >
>> >> > % man clang
>> >> > (search for -std=)
>> >> >-std=
>> >> >   Specify the language standard to compile for.
>> >> >
>> >> > OK, what does  mean?
>> >> >
>> >> > --
>> >> > Steve
>> >> > ___
>> >> > 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"
>> >
>> > --
>> > Steve
>> > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
>> > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
>
> --
> Steve
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
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: clang manual page?

[Conrad Meyer]

To a first order approximation, the manual page for clang is gcc(1).

Conrad

On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl
 wrote:
> Is anyone working on fixing the clang manual to actually
> document the available options?
>
> % man clang
> (search for -std=)
>-std=
>   Specify the language standard to compile for.
>
> OK, what does  mean?
>
> --
> Steve
> ___
> 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: clang manual page?

[Conrad Meyer]

I never said it was in base.

On Thu, Apr 5, 2018 at 5:15 PM, Steve Kargl
<s...@troutmask.apl.washington.edu> wrote:
> This assumes that a gcc(1) is available on the system.
>
> % man gcc
> No manual entry for gcc
>
> If the system compiler is clang/clang++, then it ought to be
> documented better than it currently is.  Ian's suggests for
> 'clang --help' is even worse
>
> %  clang --help | grep -- -std
>   -cl-std= OpenCL language standard to compile for.
>   -std=Language standard to compile for
>   -stdlib= C++ standard library to use
>
> Does  == ?
>
> --
> steve
>
> On Thu, Apr 05, 2018 at 04:37:38PM -0700, Conrad Meyer wrote:
>> To a first order approximation, the manual page for clang is gcc(1).
>>
>> Conrad
>>
>> On Thu, Apr 5, 2018 at 3:38 PM, Steve Kargl
>> <s...@troutmask.apl.washington.edu> wrote:
>> > Is anyone working on fixing the clang manual to actually
>> > document the available options?
>> >
>> > % man clang
>> > (search for -std=)
>> >-std=
>> >   Specify the language standard to compile for.
>> >
>> > OK, what does  mean?
>> >
>> > --
>> > Steve
>> > ___
>> > 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"
>
> --
> Steve
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
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: FreeBSD has a politics problem

[Conrad Meyer]

John,

A good portion of your original email happens to be inaccurate or
misleading.  In the spirit of good faith discussion, I'm going to
assume you're just accidentally misinformed, and not willfully
misrepresenting things.  So, some corrections and clarifications
follow.

If you have further questions about the code of conduct, I suggest
reaching out to the drafting committee or core directly.  They're nice
people, they don't bite, and they're happy to help clarify intent and
nuance.

Thanks.

On Sat, Mar 3, 2018 at 2:30 PM, John Darrah  wrote:
> FreeBSD recently introduced an updated Code of Conduct that developers and
> members must adhere to. There has been much backlash online about it and
> about introducing identity politics into a technical OS project in general.
> The Code of Conduct was adopted

In part, with editorial review and modification by a committee of
conscientious project members.

> from the "Geek Feminism" wiki's version,
> which claims (among other things) that racism against whites doesn't exist,

This claim is factually erroneous.  The Geek Feminism example
anti-harassment policy simply makes no such claim.

(Furthermore, criticizing the Geek Feminism document is wholly
off-topic for FreeBSD.  Our code of conduct is not identical to GF's
example policy.  The only conduct document relevant to FreeBSD is the
one at https://www.freebsd.org/internal/code-of-conduct.html .)

> sexism against men doesn't exist,

This claim is also objectively absent from the plain language of
either document.

> and that certain protected classes of
> people should not be criticised.

Again, this hysterical claim comes from blue sky.

> A number of developers, particularly benno@, phk@ and des@, have used racist
> and sexist remarks

Again, this is a claim made without any evidence.  I've briefly
re-skimmed the developers discussion on this topic and don't see any
examples.  (And, this accusation is so far outside of Benno's demeanor
as to be completely laughable.)  phk@ and des@ have used less
conciliatory language but I still do not see any sexist or racist
remarks.

> against those criticising the far-reaching project policy
> change, saying that the concerns about the policy essentially boil down to
> "white male privilege" and being "on the wrong side of history".

They're entitled to their opinions, as you are.  Note that neither
des@ nor phk@ sit on or represent the Core team.

> Other developers expressed concern about the policy being thrown upon them
> with no discussion or debate, as well as The FreeBSD Foundation's choice
> to pay an outside person (with donations from the users) to work on the
> Code of Conduct's enforcement.

The Foundation chooses how to spend donation dollars at its sole
discretion.  That's the deal with 501(c)(3) charities.  If you want to
pick and choose how your donated dollars are spent, Linux Foundation
is a 501(c)(6).

> Said person identifies as a feminist.

We don't object to contribution from people who identify as
Republican, Catholic, or Pastafarian.  Why do you think someone who
identifies as a feminist is incapable of doing a good job advising the
drafting committee?

> Mods on BSD and FreeBSD-related subreddits are censoring posts, removing
> threads, and banning users for posting the link.

This is a misleading oversimplification.  FreeBSD-the-project doesn't
control or have any moderation privileges on BSD-topic subreddits.
The only active moderator on one of the subreddits (freebsd) isn't
even a developer, just some random reddit user who happened to
register long ago.  Colin Percival happens to have moderation
privileges on the other subreddit (BSD), but again, is acting on his
personal volition.  He does not sit on nor represent the Core team.

Most discussions on the code of conduct in both locations have been
left in place, despite fairly low quality discussion.  (The usual
name-calling, spreading of outright FUD, othering, etc etc.)

The few posts that have been removed were outright, low-effort
trolling.  Not any kind of nuanced criticism of the actual code of
conduct.

Note that links to discussion on the BSD subreddits have been shared
in high drama, non-technical subreddits like r/Drama,
r/KotakuInAction, and r/SJWHate, likely leading to an influx of users
from those other spaces.

> Colin Percival is among the mods doing the removal.

Colin can speak to what has been moderated.  Removed subjects and
comments are still easily discovered on reddit archive sites, e.g.,
https://ceddit.com/r/BSD .  You can judge whether anything of value
was lost.  (I think not, but that's just my opinion.)

Clearly, discussion has not been eliminated.  There's tons of active
"discussion" going on.  I don't think it's particularly valuable
discourse because the same misrepresentations and outright falsehoods
are repeated over and over again, but it certainly hasn't been
scrubbed clean by moderators (who are mostly not under control of 

Re: Kernel selection in Lua loader

[Conrad Meyer]

On Wed, Feb 21, 2018 at 6:11 AM, Kyle Evans  wrote:
> On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill  wrote:
>>
>> ...
>> kernels="kernel kernel.old kernel.save"
>>
>> and the Forth loader presented (precisely) those kernels as the
>> available options for selecting a kernel to load and boot.
>>
>
> Right, so, we (and by we I mean cem@) actually implemented a form of
> auto-detection for kernels. Any directory in in /boot with a file
> named 'kernel' inside will be automatically listed, and that
> supplemented(*) 'kernels' and 'kernel' specified in loader.conf(5).
>
> (*) I use "supplemented" because I changed that in r329709, just a
> little bit ago, to not do the autodetection if a 'kernels' is
> explicitly set in loader.conf(5) My reasoning here is that there's
> probably a reason one has set it explicitly, whether it be to hide
> bogus kernels or just to slim down the list of kernels they need to
> cycle through.

Yep.  And to add a little more detail, because I like this behavior,
I've convinced Kyle to add a knob to re-enable the autodetection
behavior even in the presence of kernels="", by adding a
kernels_autodetect="yes" knob to loader.conf (r329733).

Note that any kernels in kernels="" are offered first in the list, in
the same order as configured; any additional autodetected kernels
follow at the end (as you observed earlier):

>> with the Lua loader, I was being offered a choice among 4 kernels
>> (rather than the expected 3).  Cycling through them (twice; I wanted
>> to be sure the behavior was reproducible), I noted that the presented
>> options were:
>>
>> * default/kernel
>> * kernel.old
>> * kernel.save
>> * kernel.panic
>>
>> (in that sequence).

Best,
Conrad
___
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: pkg does not recognize correct kernel version

[Conrad Meyer]

On Mon, Feb 19, 2018 at 2:38 PM, Ronald Klop  wrote:
> On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov
>  wrote:
>
>> Look at the man page.  pkg reads version from the /bin/sh ELF FreeBSD
>
>
> Which man page? I can't find it in pkg help update or pkg help upgrade or
> man pkg.

I had to dig for quite a while to find a reference (pkg.conf(5)):

 ABI: string  The ABI of the package you want to install.  Default:
  derived from the ABI of the /bin/sh binary.

>> version note:
>> orion% file /bin/ls
>> /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
>> dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1
>> (1101506), FreeBSD-style, stripped
>>
>> Update world past the __FreeBSD_version which is reported for the
>> repository.
>
>
> Does this mean I always have to do a *clean* buildworld after every version
> bump? This takes ages.

You could also do a -DNO_CLEAN buildworld.

Or you can continue to override with "-o OSVERSION=foo", although that
may eventually result in broken packages.  In general the OSVERSION is
bumped conservatively (more often than will actually result in
breakage), so you can get away with the easy workaround for a while
between buildworlds.

Best,
Conrad
___
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: Since last week (today) current on my Ryzen box is unstable

[Conrad Meyer]

On Sat, Feb 17, 2018 at 12:52 PM, Andrew Reilly  wrote:
> I've applied the patch, and the boot process is quiet now, but it's still 
> loading cc_vegas.ko, seemingly in response to seeing this device: (from 
> pciconf -l -v)
>
> none4@pci0:17:0:2:  class=0x108000 card=0x14561022 chip=0x14561022 
> rev=0x00 hdr=0x00
> vendor = 'Advanced Micro Devices, Inc. [AMD]'
> device = 'Family 17h (Models 00h-0fh) Platform Security Processor'
> class  = encrypt/decrypt
>
> (from devmatch -v)
> Searching  pci bus at slot=0 function=2 dbsf=pci0:17:0:2 
> handle=\_SB_.PCI0.GP17.APSP for pnpinfo vendor=0x1022 device=0x1456 
> subvendor=0x1022 subdevice=0x1456 class=0x108000
> cc_vegas.ko

That's kind of interesting.  That device should match ccp.ko, not
cc_vegas.ko.  As far as I can tell, cc_vegas has no PNP data at all.
Maybe this is a bug in kldxref or devmatch.

Best,
Conrad
___
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: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Conrad Meyer]

On Tue, Feb 13, 2018 at 6:02 AM, David Wolfskill  wrote:
> On Tue, Feb 13, 2018 at 12:48:19PM +0300, Vladimir Zakharov wrote:
>> 
>> > > It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
>> > > At least, removing it fixes build for me.
>
> FWIW, I have never specified WITH_AUTO_OBJ -- and I do encounter the
> "Variable OBJTOP is recursive" during the "make install kernel" phase
> unless I take evasive action (patches).

FYI, it is on by default since r325520.

Best,
Conrad
___
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: multimedia/libvpx cause clang fatal error on CURRENT

[Conrad Meyer]

Is this the same issue as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225488 ?  That was
fixed in r328513.  Please try that revision if you're not at it yet.



On Mon, Jan 29, 2018 at 7:57 PM, Iblis Lin  wrote:
> Hi,
>
> I got this while building multimedia/libvpx
>
> ```
> cc  -O2 -pipe -march=native  ...
> #0: t25: v8i64 = llvm.x86.avx512.psad.bw.512 TargetConstant:i64<5820>, t11, t5
>
> fatal error: error in backend: Do not know how to split the result of this 
> operator!
>
> cc: error: clang frontend command failed with exit code 70 (use -v to see 
> invocation)
> FreeBSD clang version 6.0.0 (branches/release_60 321788) (based on LLVM 6.0.0)
> Target: x86_64-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
> ```
>
> My box:
>
> FreeBSD abeing 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328198: Mon Jan 22 
> 13:26:48
> CST 2018 root@abeing:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
>
> Here is the script
> https://gist.github.com/iblis17/6a1d899462ba8ba1a475eebad83e993d
>
> --
> Iblis Lin
> 林峻頤
> ___
> 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: To which list should I submit a patch?

[Conrad Meyer]

IMO, either is fine.  I think documentation may refer to docs outside
of the src tree, whereas this is in the src tree.  Thanks for the
submission.

Best,
Conrad

On Thu, Jan 4, 2018 at 12:42 PM, Leonardo Fogel
 wrote:
>
>
> Hi,
> I have written a short patch that replaces the legacy interface make_dev(9) 
> with the newer one make_dev_s(9) in the DEV_MODULE(9) man page and in an 
> example that is included in the base. I do not know if I should submit it as 
> a PR to "Base System" (since they are in the base tree) or to "Documentation".
> Please, could you kindly give me some suggestion?
> Thank you for your time.
>
> Index: src/share/examples/kld/cdev/module/cdevmod.c
> ===
> --- src/share/examples/kld/cdev/module/cdevmod.c(revision 327530)
> +++ src/share/examples/kld/cdev/module/cdevmod.c(working copy)
> @@ -109,6 +109,7 @@
>  cdev_load(module_t mod, int cmd, void *arg)
>  {
>  int  err = 0;
> +struct make_dev_args mda;
>
>  switch (cmd) {
>  case MOD_LOAD:
> @@ -120,9 +121,15 @@
> printf("Copyright (c) 1998\n");
> printf("Rajesh Vaidheeswarran\n");
> printf("All rights reserved\n");
> -   sdev = make_dev(_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "cdev");
> -   break;  /* Success*/
>
> +   make_dev_args_init();
> +   mda.mda_devsw = _devsw;
> +   mda.mda_uid = UID_ROOT;
> +   mda.mda_gid = GID_WHEEL;
> +   mda.mda_mode = 0600;
> +   err = make_dev_s(, , "cdev");
> +   break;
> +
>  case MOD_UNLOAD:
> printf("Unloaded kld character device driver\n");
> destroy_dev(sdev);
> Index: src/share/man/man9/DEV_MODULE.9
> ===
> --- src/share/man/man9/DEV_MODULE.9 (revision 327530)
> +++ src/share/man/man9/DEV_MODULE.9 (working copy)
> @@ -58,11 +58,13 @@
>  .Xr DECLARE_MODULE 9
>  for more information).
>  The event handler is supposed to create the device with
> -.Fn make_dev
> +.Fn make_dev_s
>  on load and to destroy it when it is unloaded using
>  .Fn destroy_dev .
>  .Sh EXAMPLES
>  .Bd -literal
> +#include 
> +#include 
>  #include 
>  #include 
>
> @@ -74,11 +76,17 @@
>  foo_load(module_t mod, int cmd, void *arg)
>  {
>  int err = 0;
> +struct make_dev_args mda;
>
>  switch (cmd) {
>  case MOD_LOAD:
> -sdev = make_dev(_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "foo");
> -break;  /* Success*/
> +   make_dev_args_init();
> +   mda.mda_devsw = _devsw;
> +   mda.mda_uid = UID_ROOT;
> +   mda.mda_gid = GID_WHEEL;
> +   mda.mda_mode = 0600;
> +   err = make_dev_s(, , "foo");
> +   break;
>
>  case MOD_UNLOAD:
>  case MOD_SHUTDOWN:
> ___
> 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: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Conrad Meyer]

Possibly because Xeon 5400 dates to 2007 — it may have less advanced
speculative / out-of-order execution and may not have the same branch
prediction algorithm as Haswell.

On Thu, Jan 4, 2018 at 1:07 PM, Michael Butler
 wrote:
> On 01/04/18 14:59, Klaus P. Ohrhallinger wrote:
>> On 04.01.2018 19:51, Jan Kokemüller wrote:
>>
>>> It is possible to emulate a high resolution counter with a thread that
>>> continuously increments a variable [1]. This is the reason why browser
>>> vendors are currently disabling the SharedArrayBuffer feature [2].
>>>
>>> [1]: 
>>> https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156
>>> [2]: 
>>> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
>>
>> I tried the phtread example from [1] but even with some tweaking is does
>> not work at all.
>>
>> This is a multiprocessor system, with moderate load.
>>
>> As far as I understand the matter, it can only work if both threads
>> share the same cpu cache, otherwise the counter variable is either never
>> up-to-date, or has to be fetched and stored from/to memory, which is way
>> too slow for this purpose.
>>
>> Any suggestions ?
>>
>> ---
>>
>> CPU: Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz (2500.14-MHz
>> K8-class CPU)
>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>> FreeBSD/SMP: 2 package(s) x 4 core(s)
>
> Interestingly, the Xeon 5400 series is not listed as vulnerable in the
> Intel documentation where the 5500 and 5600s are; I checked as I have a
> bunch of E5440s in service.
>
> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088=en-fr
>
> imb
>
> ___
> 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: Poll: should man(1)'s default pager change to "less -s"?

[Conrad Meyer]

Ordinary human decency.

On Tue, Dec 12, 2017 at 11:06 AM, Cy Schubert <cy.schub...@komquats.com> wrote:
> What about those of us who want multiple accounts?
>
> Just kidding but you get my point.
>
> What's to stop someone from having more than one vote?
>
> ---
> Sent using a tiny phone keyboard.
> Apologies for any typos and autocorrect.
> Also, this old phone only supports top post. Apologies.
>
> Cy Schubert
> <cy.schub...@cschubert.com> or <c...@freebsd.org>
> The need of the many outweighs the greed of the few.
> ---
> 
> From: Conrad Meyer
> Sent: 12/12/2017 10:42
> To: s...@troutmask.apl.washington.edu
> Cc: FreeBSD CURRENT
> Subject: Re: Poll: should man(1)'s default pager change to "less -s"?
>
> On Tue, Dec 12, 2017 at 10:27 AM, Steve Kargl
> <s...@troutmask.apl.washington.edu> wrote:
>> There isn't a question.  I'm pointing out your poll apparently
>> is limited to a select few individuals that use FreeBSD.
>
> The select few individuals being "literally anyone that wants to
> participate?"  https://reviews.freebsd.org/auth/register/
> ___
> 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: Poll: should man(1)'s default pager change to "less -s"?

[Conrad Meyer]

On Tue, Dec 12, 2017 at 10:27 AM, Steve Kargl
 wrote:
> There isn't a question.  I'm pointing out your poll apparently
> is limited to a select few individuals that use FreeBSD.

The select few individuals being "literally anyone that wants to
participate?"  https://reviews.freebsd.org/auth/register/
___
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: kernel panic: make_dev_alias_v bad si_name (error=22) si_name=vtcon/ org.qemu.guest_agent.0)

[Conrad Meyer]

Hi Wolfram,

I believe r305900 broke it.  I don't have any patch or workaround,
sorry.  It wouldn't be too hard for someone interested in
virtualization to fix the issue.  Please follow up in the bug :-).

Best,
Conrad

On Wed, Nov 15, 2017 at 7:16 AM, Wolfram Schneider  wrote:
> Hi Conrad,
>
> thanks for the hint. Do you know which commit may broke the driver? Is
> there any patch or workaround?
>
> I do not have access to the physical machine, only full root access to
> the guest. I don't want to bother with the cloud provider, I'm happy
> that they offer FreeBSD at all as a default installation.
>
> -Wolfram
___
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: kernel panic: make_dev_alias_v bad si_name (error=22) si_name=vtcon/ org.qemu.guest_agent.0)

[Conrad Meyer]

Hi Wolfram,

Looks like the same issue as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223531 .

Best,
Conrad

On Wed, Nov 15, 2017 at 1:31 AM, Wolfram Schneider  wrote:
> Hi,
>
> I have a virtual machine running with FreeBSD 11-stable at a cloud
> provider. It runs fine. I tried to upgrade to FreeBSD 12-current and
> the kernel panics at boot time with:
>
> make_dev_alias_v bad si_name (error=22) si_name=vtcon/ org.qemu.guest_agent.0)
>
> and hangs. Lucky, I still can boot from kernel.old and bring the machine up.
>
> any idea whats wrong here?
>
> -Wolfram
>
> --
> Wolfram Schneider  https://wolfram.schneider.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"
___
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: Encrypted Swap Problem with 12.0-CURRENT r324427

[Conrad Meyer]

Thomas,

Please try r32.  Based on your panic message, "panic: freeing
invalid range," it may be the same general swap issue which r32
aimed to address.

Best,
Conrad

On Tue, Oct 10, 2017 at 2:20 PM, Thomas Laus  wrote:
> Allan Jude [allanj...@freebsd.org] wrote:
>>
>> Before the ddb> prompt there should be a message explaining what has
>> gone wrong to make it drops into the debugger. If it has scrolled off
>> the top of the screen, press scroll-lock and then you can use the arrow
>> keys to navigate back up into the buffer.
>>
> The first message is from GEOM_ELI: Device ada0p2.eli created
> GEOM_ELI: Encryption AES-XTS 128
> GEOM_ELI: Crypto: software
> panic: freeing invalid range.
>
> Next follows the stack trace
>
> then:
>
> --- syscall (85, FreeBSD ELF64, sys_swapon), rip = 0x800a88aea, rsp =
> 0x7fffea48, rbp 0x7fffea60 ---
>
> stopped at kdb_enter+0x3b:mmovq $0,kdb_why
>
> I can't save all of this to a file to attach, but this is just an
> overview of the panic.
>
> I get this everytime when going from single user to multi-user and
> about 3 out of 5 times with a normal boot.  My other release has been
> flawless 100 percent of the time.
>
> Tom
>
> --
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF
> ___
> 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: C++ in jemalloc

[Conrad Meyer]

On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore  wrote:
> It isn't about "a broken port".  All C++ code is broken if exceptions
> don't work.  That means devd is broken.  Not to mention clang itself.
>  It may be that neither of those relies on exceptions for routine
> operation and uses them only for error handling, and errors mostly
> don't happen.  There is plenty of C++ code in the world where
> exceptions are used in non-fatal-error cases and where the applications
> just don't work at all without them.

Then use G++ for C++ on those second-tier architectures.  We've got a
working C++ toolchain.

Conrad
___
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: C++ in jemalloc

[Conrad Meyer]

On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard  wrote:
> Luckily most kernel and world code that I actively use
> does not throw C++ exceptions in my use.
>
> But devel/kyua is majorly broken by the C++ exception
> issue: It makes extensive use of C++ exceptions. In my
> view that disqualifies clang as being "close": I view
> my activity as a hack until devel/kyua is generally
> operable and so available for use in testing.

I don't think that is a major roadblock; a broken port is a broken
port.  Kyua is a relatively unimportant one for most users.  In this
particular case, maybe kyua (a leaf binary) could be built with GCC
instead of Clang on any platform with broken C++ exceptions.

Best,
Conrad
___
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: panic in AcpiOsGetTimer during boot.

[Conrad Meyer]

Hey Rick,

Are you running into the same issue reported on this svn-src thread?
https://lists.freebsd.org/pipermail/svn-src-all/2017-September/151775.html

I believe jkim has reverted the change in a subsequent revision (r324136).

Best,
Conrad

On Sun, Oct 1, 2017 at 3:12 PM, Rick Macklem  wrote:
> Hi,
>
> I get the KASSERT panic in AcpiOsGetTimer() while booting a recent (2 day old)
> kernel. When I delete the KASSERT(), the kernel boots and seems to work ok.
> (This is the AcpiOsGetTimer() in sys/dev/acpica/Osd/OsdSchedule.c. There also
>  seems to be one of these functions under contrib.)
>
> Here is my dmesg after boot, if it helps indicate why this is called when 
> "cold"
> is still set. (I've marked where the dmesg ends when it Panics if the 
> KASSERT()
> is enabled.)
>
> dmesg after booting:
> Copyright (c) 1992-2017 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #1: Sun Oct  1 09:48:42 EDT 2017
> r...@nfsv4-newerlap.rick.home:/sub1/sys.headsep30/amd64/compile/GENERIC 
> amd64
> FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): resolution 640x480
> CPU: Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (2294.84-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
>   
> Features=0xbfebfbff
>   
> Features2=0x7fbae3bf
>   AMD Features=0x28100800
>   AMD Features2=0x1
>   Structured Extended Features=0x281
>   XSAVE Features=0x1
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 17179869184 (16384 MB)
> avail memory = 16518905856 (15753 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: <_ASUS_ Notebook>
> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads
> random: unblocking device.
> arc4random: no preloaded entropy cache
> ioapic0  irqs 0-23 on motherboard
> SMP: AP CPU #1 Launched!
> SMP: AP CPU #3 Launched!
> SMP: AP CPU #7 Launched!
> SMP: AP CPU #6 Launched!
> SMP: AP CPU #4 Launched!
>  dmesg ends here when in KASSERT() panics.
> SMP: AP CPU #5 Launched!
> SMP: AP CPU #2 Launched!
> Timecounter "TSC-low" frequency 1147419696 Hz quality 1000
> random: entropy device external interface
> netmap: loaded module
> [ath_hal] loaded
> module_register_init: MOD_LOAD (vesa, 0x80f779d0, 0) error 19
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> kbd1 at kbdmux0
> nexus0
> vtvga0:  on motherboard
> cryptosoft0:  on motherboard
> acpi0: <_ASUS_ Notebook> on motherboard
> acpi_ec0:  port 0x62,0x66 on acpi0
> acpi0: Power Button (fixed)
> cpu0:  on acpi0
> cpu1:  on acpi0
> cpu2:  on acpi0
> cpu3:  on acpi0
> cpu4:  on acpi0
> cpu5:  on acpi0
> cpu6:  on acpi0
> cpu7:  on acpi0
> hpet0:  iomem 0xfed0-0xfed003ff on acpi0
> Timecounter "HPET" frequency 14318180 Hz quality 950
> Event timer "HPET" frequency 14318180 Hz quality 550
> atrtc0:  port 0x70-0x77 irq 8 on acpi0
> atrtc0: Warning: Couldn't map I/O.
> atrtc0: registered as a time-of-day clock, resolution 1.00s
> Event timer "RTC" frequency 32768 Hz quality 0
> attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Event timer "i8254" frequency 1193182 Hz quality 100
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
> pcib0:  port 0xcf8-0xcff on acpi0
> pci0:  on pcib0
> pcib1:  irq 16 at device 1.0 on pci0
> pci1:  on pcib1
> vgapci0:  port 0xe000-0xe07f mem 
> 0xf600-0xf6ff,0xf000-0xf3ff,0xf400-0xf5ff irq 16 at 
> device 0.0 on pci1
> vgapci0: Boot video device
> hdac0:  mem 0xf708-0xf7083fff irq 17 at 
> device 0.1 on pci1
> xhci0:  mem 0xf730-0xf730 irq 
> 16 at device 20.0 on pci0
> xhci0: 32 bytes context size, 64-bit DMA
> usbus0: waiting for BIOS to give up control
> xhci0: Port routing mask set to 0x
> usbus0 on xhci0
> usbus0: 5.0Gbps Super Speed USB v3.0
> pci0:  at device 22.0 (no driver attached)
> ehci0:  mem 0xf7318000-0xf73183ff irq 
> 16 at device 26.0 on pci0
> usbus1: EHCI version 1.0
> usbus1 on ehci0
> usbus1: 480Mbps High Speed USB v2.0
> hdac1:  mem 0xf731-0xf7313fff irq 22 
> at device 27.0 on pci0
> pcib2:  irq 16 at device 28.0 on pci0
> pci2:  on pcib2
> pcib3:  irq 17 at device 28.1 on pci0
> 

Re: r323694 amd64 - crash in linsysfs: Was: svn commit: r323692 - in head/sys/compat: linsysfs linux

[Conrad Meyer]

Please try r323710.  I believe you're running into the issue Hans
noticed here: 
https://lists.freebsd.org/pipermail/svn-src-all/2017-September/151324.html
.  It should be addressed in r323710.

Sorry,
Conrad
___
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: Panic: @r323525: iflib

[Conrad Meyer]

Well, we know it's due to r323516, but unfortunately can't have you
bisect from there because it was committed as a giant lump.  If it
can't be fixed quickly, maybe it should be reverted?

Best,
Conrad

On Wed, Sep 13, 2017 at 6:10 AM, David Wolfskill  wrote:
> My build machine didn't have the problem -- unfortunately (as I have a
> serial console on it).  The laptop did  The panic occurs immediately
> after probing the NICs (so the good news is that it didn't have a chance
> yet to mount any filesystems; the bad news is that there's no dump
> available).  (In transcribing the backtrace, I realized that the laptop
> has an em(4) device; the build machine does not.  And iflib appears to
> be implicated.)
>
> I used my phone to grab screeshots of the backtrace... and the program I
> run on the phone to act as an SSH server so I can get the photos from it
> has suddenly become completely confused as to what the IP address of the
> phone is on the local network (using an unreachable 10/8 address; at
> this point, I won't waste my time trying to figure out how THAT broke).
>
> I did try clearing /usr/obj/usr/src/sys/CANARY/* and rebuilding the
> kernel, but the symptom persists.  (I am using "WITH_META_MODE=yes".)
>
> Previous successful build was:
> FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #398  
> r323483M/323489:1200044: Tue Sep 12 04:31:08 PDT 2017 
> r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>
> The usual historical information, including a verbose-boot dmesg.boot
> from the above-cited build, may be found at
> .
>
> I will try hand-transcribing some of the lock & backtrace info:
>
> ...
> em0: allocated for 1 rx_queues
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex taskqgroup (taskqgroup) r = 0 (0xfe07be2e4800) 
> locked @ /usr/src/sys/kern/subr_gtaskqueue.c:803
> stack backtrace:  [which I am abbreviating at this point -- dhw]
> #0 ... at witness_debugger+0x73
> #1 ... at witness_warn+0x43f
> #2 ... at trap_pfault+0x53
> #3 ... at trap+0x2c5
> #4 ... at calltrap+0x8
> #5 ... at iflib_device_register+0x2a61
> #6 ... at iflib_device_attach+0xb7
> #7 ... at device_attach+0x3ee
> #8 ... at bus_generic_attach+0x5a
> #9 ... at pci_attach+0xd5
> #10 ... at device_attach+0x3ee
> #11 ... at bus_generic_attach+0x5a
> #12 ... at acpi_pcib_acpi_attach+0x3bc
> #13 ... at device_attach+0x3ee
> #14 ... at bus_generic_attach+0x5a
> #15 ... at acpi_attach+0xe85
> #16 ... at device_attach+0x3ee
> #17 ... at bus_generic_attach+0x5a
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address   = 0x8b530c20
> fault code  = supervisor write data, page not present
> ...
> [ thread pid 0 tid 10 ]
> Stopped at  0x80a743b0 = taskqgroup_attach+0x230:orq   
> %rax,-0x 58(%rbp,%xrx,8)
>
> I can provide more specific excerpts, but I need to focus on some
> other activities for a while.
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> http://www.cbc.ca/news/opinion/donald-trump-playbook-1.4265374
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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: extending the maximum filename length (pointer to patch)[request for input]

[Conrad Meyer]

On Tue, Sep 12, 2017 at 2:23 PM, Rainer Duffner  wrote:
> And there’s also this bug:
>
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215067
>
> "g_dev_taste: make_dev_p() failed on importing pool with snapshots with long
> names“
>
>
>
> But maybe that has nothing to do with it.

Hi Rainer,

Yes, I think that one is mostly orthogonal to the filesystem path
lengths.  Still, it might also be nice to expand that one while we're
there.

ino64 was nice enough to bump MNAMELEN from 88 to 1024 and d_namlen to
16 bits, so we don't have to expand those.

Best,
Conrad
___
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: extending the maximum filename length (pointer to patch)[request for input]

[Conrad Meyer]

On Tue, Sep 12, 2017 at 2:11 PM, Ben RUBSON  wrote:
> Hi Conrad,
>
> This patch makes me think about another related bug #184340 :
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340
> It is about PATH_MAX which in some cases can be too small.
>
> Not sure if it's the case / and how to do it,
> but perhaps it is time to raise some other limits /
> think about a global solution regarding these length limits ?
>
> Many thanks !

Hi Ben,

Yes, I think that bug is about basically the same issue under discussion here.

Best,
Conrad
___
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: extending the maximum filename length

[Conrad Meyer]

On Sat, Sep 9, 2017 at 9:09 AM, Julian Elischer  wrote:
> maybe we could get it into -current.
> It'd be silly to have to have people re-inventing hte wheel all the time.
> How about you put those changes into the reviews.freebsd.org and we can get
> some general consensus on them.
> We'll have to do similar for the Asian customers and anyone who uses UTF-8.
> So it
> would be silly to have to develop it all again (but subtly different of
> course).
>
> The key issue is how many system calls and other APIs would be broken,
> and how many would be broken in a non backwards compatible way?
>
> We would need it in a stable/10 and 11 branch but if the patch is isolated
> enough we could carry it forward until we get to 12.
>
> One has to allow people to do whatever they are used to with Windows.
> And in this case the issue is serving files over samba to windows machines.

Hey Julian,

I've thrown the patch up at https://reviews.freebsd.org/D12330 .  I
haven't actually tested it on FreeBSD, but it does compile.  We also
have some patches against contrib/pjdfstest to fix those tests against
long file names, but I think we can hold off on those changes until
we've nailed down what the architectural change will be (if any).

It's quite possible this accidentally breaks even more APIs than
expected and we should do some fine tuning to reduce the damage.  Our
$WORK product mostly doesn't care about ABI, so we may not have
noticed some ABI breakage.

If anyone else is interested, please subscribe or add yourself as a
reviewer on the phabricator revision.

Best,
Conrad
___
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: extending the maximum filename length

[Conrad Meyer]

On Fri, Sep 8, 2017 at 10:21 AM, David Wolfskill  wrote:
> On Sat, Sep 09, 2017 at 01:15:31AM +0800, Julian Elischer wrote:
>> Has anyone using freeBSD ever increased NAME_MAX (filename maximum
>> length) and have any experience with it?
>>
>> We ($JOB) would recompile the entire system so intra-system
>> compatibility would probably be ok, and we have our own filesystem
>> which would support it.
>>
>> But I wonder if anyone has tried it and hit unexpected problems.
>> 
>
> Not *strictly* a "filename length" issue, but one thing I (think
> I) recall encountering a while back was an (88-character?) upper
> limit on the length of the full pathname of a mount point.
>
> So that could prove ... annoying (if I actually recall correctly,
> and the situation has not changed since).

Hi David,

I think mountpoint name length is largely an orthogonal issue.
Fortunately, the 88 character limit (MNAMELEN) was already addressed
recently (bumped to 1024) with the ino64 project.

Best,
Conrad
___
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: extending the maximum filename length

[Conrad Meyer]

On Fri, Sep 8, 2017 at 10:15 AM, Julian Elischer  wrote:
> Has anyone using freeBSD ever increased NAME_MAX (filename maximum length)
> and have any experience with it?
>
> We ($JOB) would recompile the entire system so intra-system compatibility
> would probably be ok, and we have our own filesystem which would support it.
>
> But I wonder if anyone has tried it and hit unexpected problems.
>
>
> reason:  Chinese and Japanese people who have gotten into the habit of
> having a filename of 256 CHINESE/JAPANESE characters in Microsoft and want
> to store their files on a FreeBSD based server witout having to rename
> everything. (3 bytes for each of those characters giving a limit of 83
> characters).
>
> (though since each character is a word the names if I could read them must
> be amazing)
>
>
> NFS behaviour is one issue I don't know but would be interested in..  could
> we SERVE such files?

Hey Julian,

We've done exactly this at Isilon.

Basically we bumped NAME_MAX and related constants out by 4x (maximum
length of a UTF-8 encoded Unicode character, in bytes).  So NAME_MAX
is 1023, PATH_MAX is 4096, and a bunch of follow-on equivalent/related
constants are bumped similarly.

To avoid breaking too many ABIs, we've retained a SHORT_NAME_MAX
constant of 255 which several non-filesystem NAME_MAX users were
converted to.  Stuff like module name APIs, procstat, etc.

Individual filesystems are free to implement and restrict maximum
component lengths in VOP_LOOKUP.  For us, we retained 255 bytes for
basically all filesystems (see e.g. r316509, r313475) aside from IFS
(the OneFS filesystem).  For IFS we check that component names are 255
("MAXNAMCHARS") unicode codepoints or fewer (not all names shorter
than NAME_MAX bytes are valid).

NFS commonly does not support >255 byte names, so we have a hack there
to export longer names as some shorter name plus a hash (total length
of 255 bytes or fewer) to uniquely identify the file.  SMB exports
longer names just fine.

Anyway, we'd love to shift some of these patches upstream, if there is
interest in supporting this kind of thing.

Sure, there are a few snags here and there and some ABIs change.  But
overall it seems to work pretty well.

Best,
Conrad
___
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: 64-bit inodes (ino64) Status Update and Call for Testing

[Conrad Meyer]

Hi Jilles,

Thanks for bringing this up.  And of course, thanks to kib@ for
including the d_namlen size bump and for his work in driving the rest
of this change through to completion.

On Sun, May 21, 2017 at 5:14 AM, Jilles Tjoelker  wrote:
> We have another type in this area which is too small in some situations:
> uint8_t for struct dirent.d_namlen. For filesystems that store filenames
> as upto 255 UTF-16 code units, the name to be stored in d_name may be
> upto 765 bytes long in UTF-8. This was reported in PR 204643. The code
> currently handles this by returning the short (8.3) name, but this name
> may not be present or usable, leaving the file inaccessible.

We've been working to add such support to our FreeBSD-derivative
product.  A big piece of it is expanding d_namlen out to 16 bits.
We've also been trying to divorce system-wide constants like MAXNAMLEN
/ NAME_MAX and MAXPATHLEN / PATH_MAX from filesystem-specific
limitations (UFS' limit of 255 bytes).  And push that upstream when
possible, e.g., r313475, r316509.

Bumping d_namlen in FreeBSD reduces the amount of ABI breakage we have
to introduce in our product relative to FreeBSD, and leaves open the
possibility of supporting 255-unicode-character filesystems natively
in FreeBSD down the road.

> Actually allowing longer names seems too complicated to add to the ino64
> change, but changing d_namlen to uint16_t (using d_pad0 space) and
> skipping entries with d_namlen > 255 in libc may be helpful.
>
> Note that applications using the deprecated readdir_r() will not be able
> to read such long names, since the API does not allow specifying that a
> larger buffer has been provided. (This could be avoided by making struct
> dirent.d_name 766 bytes long instead of 256.)

We're looking at 255 Unicode code points, which can be 4 bytes a piece
in UTF8, or 1020 bytes potentially.

> Unfortunately, the existence of readdir_r() also prevents changing
> struct dirent.d_name to the more correct flexible array.

Best,
Conrad
___
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: svn commit: r316977 - head/sys/dev/syscons

[Conrad Meyer]

On Sat, Apr 15, 2017 at 1:21 PM, O. Hartmann  wrote:
> Am Sat, 15 Apr 2017 20:03:50 + (UTC)
> Bruce Evans  schrieb:
>
>> Author: bde
>> Date: Sat Apr 15 20:03:50 2017
>> New Revision: 316977
>> URL: https://svnweb.freebsd.org/changeset/base/316977
>
> There is a lot of development going on theses days for syscons. What's about 
> vt()? vt() is
> considered broken for x11/nvidia-driver and vt() is considered a requirement 
> when UEFI is
> boot scheme, isn't it?
>
> I'm just curious.

Hi O.,

Bruce uses syscons and cares enough to improve it.  He likely does not
care about UEFI and definitely does not care about vt.  I don't think
there's anything wrong with that.  We can't force volunteers to work
on things they are not interested in.

Best,
Conrad
___
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: panic: invalid bcd xxx

[Conrad Meyer]

On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen  wrote:
> Your system's real-time clock is returning garbage.  r312702 added some
> input validation a few weeks ago.  Previously, the kernel was reading beyond
> the end of an array and either complaining about the clock or setting it to
> the wrong time based on whatever was in the memory beyond the array.
>
> The added validation shouldn't be an assertion because it operates on data
> beyond the kernel's control.  Try this:
>
> --- sys/libkern.h   (revision 314424)
> +++ sys/libkern.h   (working copy)
> @@ -57,8 +57,10 @@
>  bcd2bin(int bcd)
>  {
>
> -   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
> -   ("invalid bcd %d", bcd));
> +   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
> +   printf("invalid bcd %d\n", bcd);
> +   return (0);
> +   }
> return (bcd2bin_data[bcd]);
>  }

I don't think removing this assertion and truncating to zero is the
right thing to do.  Adding an error return to this routine is a little
much, though.  I think probably the caller should perform input
validation between the broken device and this routine.

Thanks,
Conrad
___
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: 'Protocol not supported' on linux socket call ( r313313 amd64 )

[Conrad Meyer]

Hi Oleg,

It seems likely it is related to r313284.

Best,
Conrad

On Wed, Feb 8, 2017 at 7:44 AM, Oleg V. Nauman  wrote:
>  After upgrading of current on amd64 box to r313313 I noticed that skype has
> stopped working.
>  Below is the end of 'truss' output for skype:
>
> 36723: linux_socketcall(1,{ LINUX_SOCKET, 0x0 }) ERR#-93 'Protocol not
> supported'
> 36723: write(6,"@",1) = 1 (0x1)
> 36723: close(6)= 0 (0x0)
> 36723: close(5)= 0 (0x0)
> 36723: linux_rt_sigaction(0x11,0xbaf8,0xba6c,0x8) = 0 (0x0)
> 36723: linux_exit_group(0x1)
> 36723: process exit, rval = 1
>
>  My second current box ( r313090 i386 ) runs skype successfully.
> ___
> 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: ASLR

[Conrad Meyer]

On Wed, Jan 18, 2017 at 9:53 AM, Johannes Lundberg  wrote:
> Hi
>
> What is the status of ASLR?
>
> https://reviews.freebsd.org/D5603
>
> The thread has been silent for a couple of months. I'm happy to test if
> needed.

Hi Johannes,

I think we were waiting on some review, but if that has stalled out,
let's go ahead and commit it.  Default off is fine for now.  It can be
improved as needed and then we at least have an ASLR story for the
checkbox users.

> I'm also interested in KASLR. Is that also on the roadmap? If someone
> involved could share some info I'd be grateful.

KASLR is less useful (grsecurity folks might say useless) — see
https://forums.grsecurity.net/viewtopic.php?f=7=3367 for some
discussion on it.

Best,
Conrad
___
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: r311674: buildworld failure: iso_rrip.h:64:2: error: unknown type name 'cd_ino_t'

[Conrad Meyer]

Please try r311675.

Thanks,
Conrad

On Sun, Jan 8, 2017 at 1:05 AM, O. Hartmann  wrote:
> It seems, the most recent CURRENT sources are broken (r311674), buildworld 
> failure occur
> at:
>
> [...]
>  --- cd9660.o ---
> In file included from /usr/src/usr.sbin/makefs/cd9660.c:108:
> In file included from /usr/src/usr.sbin/makefs/cd9660.h:57:
> /usr/src/sys/fs/cd9660/iso_rrip.h:64:2: error: unknown type name 'cd_ino_t'; 
> did you mean
> '__ino_t'? cd_ino_t*inump; /* inode number pointer */
> ^~~~
> __ino_t
>
> --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
___
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"