Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Don Lewis]

On 24 Apr, Mike Tancsa wrote:
> On 4/24/2018 10:01 AM, Pete French wrote:
>> 
>> Well, I ranh the iperf tests between real machine for 24 hours and that
>> worked fine. I also then spun up a Virtualbox with Win10 in it, and ran
>> iuperf to there at the same time as doing it betwene real machines, and
>> also did a full virus scan to exercise the disc. the idea being to
>> replicate Mondays lockup.
> 
> I was able to lock it up with vbox. bhyve was just a little easier to
> script and also I figured would be good to get VBox out of the mix in
> case it was something specific to VBox.  I dont recall if I tried it
> with SMT disabled.  Regardless, on Intel based systems I ran these tests
> for 72hrs straight without issue.   I can sort of believe hardware issue
> or flaky motherboard BIOSes (2 ASUS MBs, 1 MSI MB, 3 Ryzen chips), but
> the fact that two server class MBs from SuperMicro along with an Epyc
> chip also does the same thing makes me think something specific to
> FreeBSD and this class of AMD CPU :(

It would be interesting to test other AMD CPUs.  I think AMD and Intel
have some differences in the virtualization implementations.

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

Deprecating the lmc(4) driver

[Ed Maste]

The lmc(4) driver supports hardware for a number of legacy interfaces,
including EIA612/613, T1/E1, T3, etc.  The driver's license is ambiguous
and attempts to contact the author failed.

I would like to remove this driver from 12.0, and have a deprecation
notice in review D15182 [1]; I would appreciate hearing from anyone who
is currently using lmc(4) in case it is still providing some value.

[1] https://reviews.freebsd.org/D15182
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: What should do in chrooted environment?

[O'Connor, Daniel]

> On 24 Apr 2018, at 23:39, Marc Branchaud  wrote:
> On 2018-04-24 09:24 AM, Glen Barber wrote:
>> There are additional nits regarding jail(8) that chroot(8) does not have
>> the same limitations.  Setting/unsetting the immutable flag on something
>> like /sbin/init, for example, comes to mind.
> 
> Try
>   allow.chflags
> in your jail.conf.

I assume that this also isn't checked by the build so you end up wasting some 
time as well (but probably only in installworld)

I don't see an argument against doing some quick sanity checks before starting 
a run (be it buildworld, installworld or whatever).

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Pete French]

yes, I too think its definitely a Ryzen isssue with FreeBSD - is there a 
way you could try it (at least on the Desktop) with SMT off ? I havbe 
the following options tunred off:


SMT
Glocal C states
Cool-n-quiet
Core boost

The last few obviously tweak processor clocks and thus dont surprise me 
too much as a soource of instabuloty, but I am surprised that SMT causes 
issues, as that should (I belive) simply present as two cores.


On 24/04/2018 15:22, Mike Tancsa wrote:

On 4/24/2018 10:01 AM, Pete French wrote:


Well, I ranh the iperf tests between real machine for 24 hours and that
worked fine. I also then spun up a Virtualbox with Win10 in it, and ran
iuperf to there at the same time as doing it betwene real machines, and
also did a full virus scan to exercise the disc. the idea being to
replicate Mondays lockup.


I was able to lock it up with vbox. bhyve was just a little easier to
script and also I figured would be good to get VBox out of the mix in
case it was something specific to VBox.  I dont recall if I tried it
with SMT disabled.  Regardless, on Intel based systems I ran these tests
for 72hrs straight without issue.   I can sort of believe hardware issue
or flaky motherboard BIOSes (2 ASUS MBs, 1 MSI MB, 3 Ryzen chips), but
the fact that two server class MBs from SuperMicro along with an Epyc
chip also does the same thing makes me think something specific to
FreeBSD and this class of AMD CPU :(

---Mike



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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Mike Tancsa]

On 4/24/2018 10:01 AM, Pete French wrote:
> 
> Well, I ranh the iperf tests between real machine for 24 hours and that
> worked fine. I also then spun up a Virtualbox with Win10 in it, and ran
> iuperf to there at the same time as doing it betwene real machines, and
> also did a full virus scan to exercise the disc. the idea being to
> replicate Mondays lockup.

I was able to lock it up with vbox. bhyve was just a little easier to
script and also I figured would be good to get VBox out of the mix in
case it was something specific to VBox.  I dont recall if I tried it
with SMT disabled.  Regardless, on Intel based systems I ran these tests
for 72hrs straight without issue.   I can sort of believe hardware issue
or flaky motherboard BIOSes (2 ASUS MBs, 1 MSI MB, 3 Ryzen chips), but
the fact that two server class MBs from SuperMicro along with an Epyc
chip also does the same thing makes me think something specific to
FreeBSD and this class of AMD CPU :(

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: What should do in chrooted environment?

[Glen Barber]

On Tue, Apr 24, 2018 at 10:09:40AM -0400, Marc Branchaud wrote:
> On 2018-04-24 09:24 AM, Glen Barber wrote:
> > There are additional nits regarding jail(8) that chroot(8) does not have
> > the same limitations.  Setting/unsetting the immutable flag on something
> > like /sbin/init, for example, comes to mind.
> 
> Try
>   allow.chflags
> in your jail.conf.
> 

Sure, this works, but it requires (IMHO) more "intervention" than
a simple devfs(5) mount in the target build environment.

Glen

>   M.
> 
> > Glen
> > 
> > On Tue, Apr 24, 2018 at 11:49:46AM +0100, krad wrote:
> > > wouldn't it just be easier to do this in a jail, and then all of these
> > > little bits would be taken care of?
> > > 
> > > On 24 April 2018 at 01:48, O'Connor, Daniel  wrote:
> > > 
> > > > 
> > > > 
> > > > > On 24 Apr 2018, at 08:14, Glen Barber  wrote:
> > > > > I think you might not have the devfs mount in the image.  With the 
> > > > > paths
> > > > > provided above, I think this should fix it:
> > > > > 
> > > > > # mount -t devfs devfs /mnt/dev
> > > > 
> > > > I wonder if it's worth doing a basic sanity check that /dev/null and
> > > > /dev/zero look like device nodes.
> > > > 
> > > > I've made this mistake too and it produces some very confusing error
> > > > messages :(
> > > > 
> > > > --
> > > > Daniel O'Connor
> > > > "The nice thing about standards is that there
> > > > are so many of them to choose from."
> > > >   -- Andrew Tanenbaum
> > > > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
> > > > 
> > > > ___
> > > > freebsd-stable@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > > To unsubscribe, send any mail to 
> > > > "freebsd-stable-unsubscr...@freebsd.org"
> > > > 
> 


signature.asc
Description: PGP signature

Re: What should do in chrooted environment?

[Marc Branchaud]

On 2018-04-24 09:24 AM, Glen Barber wrote:

There are additional nits regarding jail(8) that chroot(8) does not have
the same limitations.  Setting/unsetting the immutable flag on something
like /sbin/init, for example, comes to mind.


Try
allow.chflags
in your jail.conf.

M.


Glen

On Tue, Apr 24, 2018 at 11:49:46AM +0100, krad wrote:

wouldn't it just be easier to do this in a jail, and then all of these
little bits would be taken care of?

On 24 April 2018 at 01:48, O'Connor, Daniel  wrote:





On 24 Apr 2018, at 08:14, Glen Barber  wrote:
I think you might not have the devfs mount in the image.  With the paths
provided above, I think this should fix it:

# mount -t devfs devfs /mnt/dev


I wonder if it's worth doing a basic sanity check that /dev/null and
/dev/zero look like device nodes.

I've made this mistake too and it produces some very confusing error
messages :(

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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


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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Pete French]

On 24/04/2018 14:56, Mike Tancsa wrote:

I was doing the tests with bhyve, and the iperf tests were between VMs
on the same box.  That seems to trigger it fairly quickly. The Epyc took
a bit more work, but I could reliable do it there too.


Well, I ranh the iperf tests between real machine for 24 hours and that 
worked fine. I also then spun up a Virtualbox with Win10 in it, and ran 
iuperf to there at the same time as doing it betwene real machines, and 
also did a full virus scan to exercise the disc. the idea being to 
replicate Mondays lockup.


But its all fine - the only differece being that I have disabled SMT 
again. Do you get lockup-s with SMT disabled ?


I dint have any experince with bhyve and dont have the tiime to start 
learning right now, hence me testing with VB, which I already have pa nd 
running. I can repeat with SMt on again to veiry that it does then lock up.


All very odd though - am pleased its stable, but dissapinted at the 
amout of stuff I have had to turn off to get it to that state.


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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Mike Tancsa]

On 4/23/2018 8:19 AM, Pete French wrote:
> 
> All worked fine until just no,w when it did lockup. But the lockup
> happened when I fired up VirtualBox as well on the Ryzen machine, had that
> doing a lot of disc activity and also did a lot of ZFS activity on the box
> itself. Which I find interesting, because your lockups were also happenng
> when VirtualBox was running were they not ?
> 
> So, am going to try that again (the iperf test and simultaneous Win10
> in VirtualBox), but with SMT off, to see if I can reproduce it.
> 


I was doing the tests with bhyve, and the iperf tests were between VMs
on the same box.  That seems to trigger it fairly quickly. The Epyc took
a bit more work, but I could reliable do it there too.

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: What should do in chrooted environment?

[Glen Barber]

There are additional nits regarding jail(8) that chroot(8) does not have
the same limitations.  Setting/unsetting the immutable flag on something
like /sbin/init, for example, comes to mind.

Glen

On Tue, Apr 24, 2018 at 11:49:46AM +0100, krad wrote:
> wouldn't it just be easier to do this in a jail, and then all of these
> little bits would be taken care of?
> 
> On 24 April 2018 at 01:48, O'Connor, Daniel  wrote:
> 
> >
> >
> > > On 24 Apr 2018, at 08:14, Glen Barber  wrote:
> > > I think you might not have the devfs mount in the image.  With the paths
> > > provided above, I think this should fix it:
> > >
> > > # mount -t devfs devfs /mnt/dev
> >
> > I wonder if it's worth doing a basic sanity check that /dev/null and
> > /dev/zero look like device nodes.
> >
> > I've made this mistake too and it produces some very confusing error
> > messages :(
> >
> > --
> > Daniel O'Connor
> > "The nice thing about standards is that there
> > are so many of them to choose from."
> >  -- Andrew Tanenbaum
> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
> >
> > ___
> > freebsd-stable@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> >


signature.asc
Description: PGP signature

Re: What should do in chrooted environment?

[krad]

wouldn't it just be easier to do this in a jail, and then all of these
little bits would be taken care of?

On 24 April 2018 at 01:48, O'Connor, Daniel  wrote:

>
>
> > On 24 Apr 2018, at 08:14, Glen Barber  wrote:
> > I think you might not have the devfs mount in the image.  With the paths
> > provided above, I think this should fix it:
> >
> > # mount -t devfs devfs /mnt/dev
>
> I wonder if it's worth doing a basic sanity check that /dev/null and
> /dev/zero look like device nodes.
>
> I've made this mistake too and it produces some very confusing error
> messages :(
>
> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
>  -- Andrew Tanenbaum
> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"