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
___
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 information.
> Linux has g
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
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 tha
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 hack
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
> > memory
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 log
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:
> > >
> >
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 d
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. msg
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
> F
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:
msgbufp=
12 matches
Mail list logo
