Re: Current status of Ryzen (non-)support

Sent from my iPhone > On Oct 22, 2018, at 6:00 PM, Hannes Hauswedell wrote: > >> On 21.10.18 19:33, Konstantin Belousov wrote: >>> On Sun, Oct 21, 2018 at 06:09:50PM +0200, Hannes Hauswedell wrote: >>> Hi everyone, >>> >>> I wanted to ask what the current status of Ryzen support is and/or

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

[I' unable to reproduce the under-Hyper-V early kernel crash for WITH_ZFS= (implicit) build that includes the for-loaders patch I was given to try.] On 2018-Oct-22, at 10:01 AM, Mark Millard wrote: > [I will note the the loader problem has been shown to > not be involved in the kernel problem

Re: which way to update export_args structure?

On Mon, Oct 22, 2018 at 09:59:52PM +, Rick Macklem wrote: > > > From: owner-freebsd-curr...@freebsd.org > on behalf of Rick Macklem > Sent: Monday, October 22, 2018 5:24 PM > To: Brooks Davis > Cc: FreeBSD Current; Josh Paetzel > Subject: Re: which

Re: Current status of Ryzen (non-)support

On 21.10.18 19:33, Konstantin Belousov wrote: > On Sun, Oct 21, 2018 at 06:09:50PM +0200, Hannes Hauswedell wrote: >> Hi everyone, >> >> I wanted to ask what the current status of Ryzen support is and/or >> whether any new changes are planned. >> >> My situation: >> * second generation Ryzen:

Re: which way to update export_args structure?

From: owner-freebsd-curr...@freebsd.org on behalf of Rick Macklem Sent: Monday, October 22, 2018 5:24 PM To: Brooks Davis Cc: FreeBSD Current; Josh Paetzel Subject: Re: which way to update export_args structure? Brooks Davis wrote: On Sat, Oct 20,

Re: ctm(1) deprecation in the FreeBSD base system?

Hi, Reference: > From: "Rodney W. Grimes" > Date: Mon, 22 Oct 2018 14:11:43 -0700 (PDT) "Rodney W. Grimes" wrote: > > > > In message > > > > , Warner Losh writes: > > > > >> > I think Julian Stacy is still running CTM generation ? > > >> > > >> Ah, yes, that brought

Re: ctm(1) deprecation in the FreeBSD base system?

> "Rodney W. Grimes" wrote: > > > The ctm(1) client remains in the FreeBSD base system, although > > > FreeBSD-hosted ctm infrastructure was shut down some time ago. I > > > suspect it is time to remove it from the base system (perhaps making a > > > port). > > > > > > How much use does ctm have

Re: which way to update export_args structure?

Brooks Davis wrote: On Sat, Oct 20, 2018 at 01:17:37AM +, Rick Macklem wrote: [lots of stuff snipped] >> + if (error == 0) { >> + gotexp = 0; >> + memset(, 0, sizeof(export)); >> + if (vfs_getopt(mp->mnt_optnew, "export.exflags", , >> + )

Re: ctm(1) deprecation in the FreeBSD base system?

"Rodney W. Grimes" wrote: > > The ctm(1) client remains in the FreeBSD base system, although > > FreeBSD-hosted ctm infrastructure was shut down some time ago. I > > suspect it is time to remove it from the base system (perhaps making a > > port). > > > > How much use does ctm have these days? >

Re: ctm(1) deprecation in the FreeBSD base system?

> > In message > > , Warner Losh writes: > > >> > I think Julian Stacy is still running CTM generation ? > >> > >> Ah, yes, that brought back enough brain cells, > >> confirmed that is who I saw with ctm usage. > > > >Do we need it in base? Or can we make it a port? > > Absolutely

Re: careless commits disrupt

Hi, Reference: > From: Stefan Esser > Date: Fri, 12 Oct 2018 11:44:59 +0200 Stefan Esser wrote: > Am 12.10.18 um 07:39 schrieb Dag-Erling Sm�rgrav: > > Julian H. Stacey writes: > >> Stefan Esser writes: > >>> You should also delete old files: > >>> > >>> cd /usr/src > >>>

Re: ctm(1) deprecation in the FreeBSD base system?

In message , Warner Losh writes: >> > I think Julian Stacy is still running CTM generation ? >> >> Ah, yes, that brought back enough brain cells, >> confirmed that is who I saw with ctm usage. > >Do we need it in base? Or can we make it a port? Absolutely make it a port! --

Re: ctm(1) deprecation in the FreeBSD base system?

Hi, Reference: > From: "Rodney W. Grimes" > Date: Mon, 22 Oct 2018 13:38:25 -0700 (PDT) "Rodney W. Grimes" wrote: > > > > In message <201810221957.w9mjvdxx012...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. > > Gri > > mes" writes: > > > > >I do not know that other than I do

Re: ctm(1) deprecation in the FreeBSD base system?

On Mon, Oct 22, 2018 at 2:40 PM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > In message <201810221957.w9mjvdxx012...@pdx.rh.cn85.dnsmgr.net>, > "Rodney W. Gri > > mes" writes: > > > > >I do not know that other than I do know that I have seen > > >one data point

Re: ctm(1) deprecation in the FreeBSD base system?

> > In message <201810221957.w9mjvdxx012...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. > Gri > mes" writes: > > >I do not know that other than I do know that I have seen > >one data point in the last 14 days of a user who was infact > >using ctm though I can not associate a username/email

Re: Hyper-V FreeBSD-CURRENT Guest and SR-IOV Pass Through

None of the Intel networking drivers on FreeBSD support Hyper-V. Could you try "Discrete Device Assignment" instead? Create the VFs on the host somehow, then pass them through to the VMs? That looks like it might work for the FreeBSD VF drivers. - Eric On Mon, Oct 22, 2018 at 12:11 PM Michael

Re: ctm(1) deprecation in the FreeBSD base system?

In message <201810221957.w9mjvdxx012...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. Gri mes" writes: >I do not know that other than I do know that I have seen >one data point in the last 14 days of a user who was infact >using ctm though I can not associate a username/email address >with that

Re: ctm(1) deprecation in the FreeBSD base system?

> The ctm(1) client remains in the FreeBSD base system, although > FreeBSD-hosted ctm infrastructure was shut down some time ago. I > suspect it is time to remove it from the base system (perhaps making a > port). > > How much use does ctm have these days? I do not know that other than I do know

ctm(1) deprecation in the FreeBSD base system?

The ctm(1) client remains in the FreeBSD base system, although FreeBSD-hosted ctm infrastructure was shut down some time ago. I suspect it is time to remove it from the base system (perhaps making a port). How much use does ctm have these days? ___

Hyper-V FreeBSD-CURRENT Guest and SR-IOV Pass Through

When we try to enable the SR-IOV function of Network-Adapter in the properties of the virtual machine, we get f12rw kernel: hn0: got notify, nvs type 128 f12rw kernel: pcib0: on vmbus0 f12rw kernel: pcib0: failed to get resource for cfg window f12rw kernel: device_attach: pcib0 attach returned 6

Re: A new stable/12 poudriere jail is inferior to its stable/12 host

-- Start of PGP signed section. > On Sun, Oct 21, 2018 at 02:14:16PM +0100, Graham Perrin wrote: > > On 21/10/2018 13:31, David Wolfskill wrote: > > > On Sun, Oct 21, 2018 at 09:41:46AM +0100, Graham Perrin wrote: > > >> With the host already at r339438, > > >> creation of a jail (method: svn

Re: which way to update export_args structure?

On Mon, Oct 22, 2018 at 11:49:23AM -0500, Josh Paetzel wrote: > > > On Mon, Oct 22, 2018, at 11:05 AM, Brooks Davis wrote: > > > > > This is the direction I'd been thinking. FWIW, the usecase is more that > > once you've moved away from the struct it's easy to make incremental > > changes

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

[I will note the the loader problem has been shown to not be involved in the kernel problem that this "Subject:" was originally for.] On 2018-Oct-22, at 9:26 AM, Warner Losh wrote: > On Mon, Oct 22, 2018 at 6:39 AM Mark Millard wrote: >> On 2018-Oct-22, at 4:07 AM, Toomas Soome wrote: >> >>

Re: which way to update export_args structure?

On Mon, Oct 22, 2018, at 11:05 AM, Brooks Davis wrote: > > This is the direction I'd been thinking. FWIW, the usecase is more that > once you've moved away from the struct it's easy to make incremental > changes then to use a 32-bit mountd on a 64-bit kernel. Moving toward >

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

On Mon, Oct 22, 2018 at 6:39 AM Mark Millard wrote: > On 2018-Oct-22, at 4:07 AM, Toomas Soome wrote: > > > On 22 Oct 2018, at 13:58, Mark Millard wrote: > >> > >> On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote: > >>> > On 22 Oct 2018, at 06:30, Warner Losh wrote: > > On Sun,

Re: which way to update export_args structure?

On Sat, Oct 20, 2018 at 01:17:37AM +, Rick Macklem wrote: > Brooks Davis wrote: > > Yes, I think that's the right way foward. Thanks for following up. > >Rick Macklem wrote: > >> Just in case you missed it in the email thread, in your general question > >> below... > >> Did you mean/suggest

Head won't build tool-chain at r339586

Group: I have been building HEAD for the past several years about every 2 weeks. I updated my base source today from r339234 to r339586 and the buildworld stops because a missing libarchive.so.7 dependency. It is looking for libcrypto.so.9 which has not been built at this part of the toolchain

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

On 2018-Oct-22, at 4:07 AM, Toomas Soome wrote: > On 22 Oct 2018, at 13:58, Mark Millard wrote: >> >> On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote: >>> On 22 Oct 2018, at 06:30, Warner Losh wrote: On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: > >

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

> On 22 Oct 2018, at 13:58, Mark Millard wrote: > > On 2018-Oct-22, at 2:27 AM, Toomas Soome http://me.com/>> > wrote: >> >>> On 22 Oct 2018, at 06:30, Warner Losh wrote: >>> >>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: >>> On Sun, Oct 21, 2018 at 8:57 PM Mark

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote: > >> On 22 Oct 2018, at 06:30, Warner Losh wrote: >> >> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: >> >>> >>> >>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable < >>> freebsd-sta...@freebsd.org> wrote: >>> [I

Re: Page fault in midi/sequencer.c

On Mon, Oct 22, 2018 at 11:00:41AM +0200, Hans Petter Selasky wrote: > On 10/20/18 6:56 PM, Peter Holm wrote: > > I can trigger this on 13.0-CURRENT r339445 with a non-root test program: > > > > Hi, > > The following commits should fix the issues you experience: > >

Re: Current status of Ryzen (non-)support

On Sun, Oct 21, 2018 at 7:09 PM, Hannes Hauswedell wrote: Hi everyone, I wanted to ask what the current status of Ryzen support is and/or whether any new changes are planned. My situation: * second generation Ryzen: 2600X * running -CURRENT * I have done the things described here:

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

> On 22 Oct 2018, at 06:30, Warner Losh wrote: > > On Sun, Oct 21, 2018 at 9:28 PM Warner Losh > wrote: > >> >> >> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable < >> freebsd-sta...@freebsd.org> wrote: >> >>> [I built based on WITHOUT_ZFS= for

Re: Page fault in midi/sequencer.c

On 10/20/18 6:56 PM, Peter Holm wrote: I can trigger this on 13.0-CURRENT r339445 with a non-root test program: Hi, The following commits should fix the issues you experience: https://svnweb.freebsd.org/changeset/base/339581 https://svnweb.freebsd.org/changeset/base/339582

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

On 2018-Oct-21, at 8:30 PM, Warner Losh wrote: > On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: > > On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable > wrote: >> [I built based on WITHOUT_ZFS= for other reasons. But, >> after installing the build, Hyper-V based boots are