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

Re: DRM: radeonkms no longer usable following a switch to stable, FreeBSD 12.0-BETA1

tl;dr it seems that rc.conf can handle radeonkms and sddm _if_ I enable CSM at boot _and if_ I have: /usr/local/etc/X11/xorg.conf.d/driver-vesa.conf Not truly benefiting from radeonkms. AFAICT if I exclude the VESA workaround and manually load radeonkmos and start sddm, then as previously noted

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

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 other reasons. But, >> after installing the build, Hyper-V based boots are >> working.] >> >> On

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

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 other reasons. But, > after installing the build, Hyper-V based boots are > working.] > > On 2018-Oct-20, at 2:09 AM, Mark Millard wrote: > > > On 2018-Oct-20,

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

[I built based on WITHOUT_ZFS= for other reasons. But, after installing the build, Hyper-V based boots are working.] On 2018-Oct-20, at 2:09 AM, Mark Millard wrote: > On 2018-Oct-20, at 1:39 AM, Mark Millard wrote: > >> I attempted to jump from head -r334014 to -r339076 >> on a threadripper 19

fetch: https://www.FreeBSD.org/ports/INDEX-13.bz2: Authentication error - portupgrade

Hi: Just upgraded a machine to 13-current: FreeBSD 13.0-CURRENT FreeBSD 13.0-CURRENT #18 r339556: Sun Oct 21 17:33:46 EDT 2018 root@sparc:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 130 I deleted /usr/ports and did a fresh svnlite co into /usr/ports. When trying to rebuild all

Re: boot message: sendmsg on igb0: No buffer space available

On 10/20/2018 4:31 AM, Dave Cottlehuber wrote: > On Fri, 19 Oct 2018, at 19:46, Mike Tancsa wrote: >> Feeding entropy: . >> lo0: link state changed to UP >> sendmsg on igb0: No buffer space available >> igb0: link state changed to UP >> cxl1: link state changed to UP >> Starting Network: lo0 igb0 c

Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ WITHOUT_ZFS= fixes it ]

[Building and installing based on WITHOUT_ZFS= allows the resulting loader to work correctly on the 1950X.] On 2018-Oct-21, at 12:05 AM, Mark Millard wrote: > On 2018-Oct-20, at 10:32 PM, Warner Losh wrote: > >> On Sat, Oct 20, 2018 at 11:04 PM Mark Millard wrote: >> [I found what change lead

Re: Current status of Ryzen (non-)support

On Sun, 21 Oct 2018 18:09:50 +0200 Hannes Hauswedell wrote: > 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: > https://l

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

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 (other methods failed)) resulted in > >> inferi

Re: Current status of Ryzen (non-)support

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: 2600X > * running -CURRENT > * I have done the things desc

clang debugging code in stable/12 and current

It looks like the enabling of debugging code in clang/llvm was flipped around during the stable/12 branch. See the definition of NDEBUG in lib/clang/llvm.build.mk line 20: current before r339436: #CFLAGS+= -DNDEBUG after r339436: CFLAGS+=-DNDEBUG stable/12 at r339435: #CFLAGS+=

Current status of Ryzen (non-)support

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: https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069799.html

Re: DRM: radeonkms … can not be unloaded (kernel panic)) …

On Sun, Oct 21, 2018, 2:29 AM Kevin Oberman wrote: > On Sat, Oct 20, 2018 at 1:28 AM Hans Petter Selasky > wrote: > > > On 10/20/18 3:10 AM, Graham Perrin wrote: > > > On 20/10/2018 00:01, Graham Perrin wrote: > > > > > >> kldunload radeonkms > > >> > > >> – results in a kernel panic. > > > > >

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

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 (other methods failed)) resulted in >> inferior version r339435. >> >> Is this normal? >> >> Re: >>

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: Calling uiomove() with the following non-sleepable locks held: exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ dev/sound/midi/sequencer.c:952 stack backtrace

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

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 (other methods failed)) resulted in > inferior version r339435. > > Is this normal? > > Re: >

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

With the host already at r339438, creation of a jail (method: svn (other methods failed)) resulted in inferior version r339435. Is this normal? Re: I want the version of the jail to match the version of the host befo

Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ -r336532 broke it ]

On Sat, Oct 20, 2018 at 11:04 PM Mark Millard wrote: > [I found what change lead to the 1950X boot crashing > with BTX halted.] > > On 2018-Oct-20, at 12:44 PM, Mark Millard wrote: > > > [Adding some vintage information for a loader > > that allowed a native boot.] > > > > On 2018-Oct-20, at 4:0

Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ -r336532 broke it ]

On 2018-Oct-20, at 10:32 PM, Warner Losh wrote: > On Sat, Oct 20, 2018 at 11:04 PM Mark Millard wrote: > [I found what change lead to the 1950X boot crashing > with BTX halted.] > >> On 2018-Oct-20, at 12:44 PM, Mark Millard wrote: >> >> > [Adding some vintage information for a loader >> > th

Re: DRM: radeonkms … can not be unloaded (kernel panic)) …

On Sat, Oct 20, 2018 at 1:28 AM Hans Petter Selasky wrote: > On 10/20/18 3:10 AM, Graham Perrin wrote: > > On 20/10/2018 00:01, Graham Perrin wrote: > > > >> kldunload radeonkms > >> > >> – results in a kernel panic. > > > > Found, at < > https://github.com/FreeBSDDesktop/kms-drm/issues/90#issuec

Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ -r336532 broke it ]

[I found what change lead to the 1950X boot crashing with BTX halted.] On 2018-Oct-20, at 12:44 PM, Mark Millard wrote: > [Adding some vintage information for a loader > that allowed a native boot.] > > On 2018-Oct-20, at 4:00 AM, Mark Millard wrote: > >> I attempted to jump from head -r33401