Re: Enabling NUMA in BIOS stop booting FreeBSD

On Thu, Dec 15, 2016 at 02:33:30PM +0200, Konstantin Belousov wrote: > On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote: > > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > > > So my opinion did not changed, this sounds like firmware problem. > > > I

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Thu, Dec 15, 2016 at 04:16:24PM +0300, Slawa Olhovchenkov wrote: > On Thu, Dec 15, 2016 at 02:33:30PM +0200, Konstantin Belousov wrote: > > > On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote: > > > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > >

Re: FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing

On Thu, Dec 15, 2016 at 12:42:00 +0100, Dimitry Andric wrote: > On 15 Dec 2016, at 12:03, jenkins-ad...@freebsd.org wrote: > > > > FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing: > > > > Build information: > > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/ > > Full change

Questions about FreeBSD support for NVDIMM

Dear All, Does anybody know NVDIMM support status and plan in current FreeBSD? I noticed this message "Have "Traditional" NVDIMM support (rpokala@)" on https://wiki.freebsd.org/VendorDevSummit/201611/HaveNeedWant. If anyone knows about the details, please share with me and I will appreciate

best approximation of getcpu() ?

TL;DR; is there any way a userspace thread in FreeBSD can tell on which CPU it is (was) running ? I know the thread can migrate at any time but as long as the event is rare I can live with the occasionally wrong information. Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3), but the

Re: Enabling NUMA in BIOS stop booting FreeBSD

heh, an updated BIOS that solves the problem will solve the problem. :) I think you have enough information to provide to supermicro. Ie, "SMAP says X, when physical memory pages at addresses X are accessed, they don't behave like memory, maybe something is wrong". All I can think of is some

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Thu, Dec 15, 2016 at 03:56:56PM +0200, Konstantin Belousov wrote: > > > Possibly, the dmesg of the boot (with late_console=0) with this and only > > > this patch applied against stock HEAD. This might be long. > > > > Do you need all (262144?) lines? > > > > Testing system > >

syslogd no longer listens (or sends) on a network socket

It appears that SVN r309925 and onward no longer opens a network socket unless the command-line explicitly contains "-b :syslog" :-( This also stops one syslog daemon forwarding to another (which is why I noticed). Was this an intentional behaviour change? Michael

Re: best approximation of getcpu() ?

On Thu, Dec 15, 2016 at 7:17 PM, Luigi Rizzo wrote: > TL;DR; is there any way a userspace thread in FreeBSD can tell > on which CPU it is (was) running ? I know the thread can migrate > at any time but as long as the event is rare I can live with > the occasionally wrong

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > So my opinion did not changed, this sounds like firmware problem. > I do not see how can I drill into it more. I am don't know how it related. msgbufp mapped different with and w/o memory test: w/o memory test, hang:

Re: FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing

On 15 Dec 2016, at 12:03, jenkins-ad...@freebsd.org wrote: > > FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing: > > Build information: > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/ > Full change log: > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/changes >

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > So my opinion did not changed, this sounds like firmware problem. > > I do not see how can I drill into it more. > > I am don't know how it related.