Questions about FreeBSD support for NVDIMM
Dear FreeBSD folks, I am Qi Zhang from VMware Guest OS Validation team. And I am doing some investigation about NVDIMM supporint in FreeBSD. I heard from George Neville-Neil that NVDIMM support in FreeBSD has been moving along for a while. But I couldn't find detail project description from freebsd.org, but only one piece information about "Have "Traditional" NVDIMM support (rpokala@)" on https://wiki.freebsd.org/VendorDevSummit/201611/HaveNeedWant. Can you please share with me what is the progress and schedule for FreeBSD supporting NVDIMM? If you can share more details with me, I will much appreciate. Thanks Best Regards - Qi (Keira) GOSV | 18F, Raycom, Beijing | +86-10-599 34604 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On Tue, Dec 13, 2016 at 11:07:19AM -0500, Michael Butler wrote: M> >> Any hints as to why all of my -current equipment is complaining like below. Is M> >> there a sysctl to moderate/turn this off? M> >> M> >> Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:00:21 archive last message repeated 13 times M> >> Dec 13 10:02:21 archive last message repeated 18 times M> >> Dec 13 10:06:21 archive last message repeated 36 times M> >> Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:08:21 archive last message repeated 17 times M> >> Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to 200 M> >> packets/sec M> >> Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:10:21 archive last message repeated 17 times M> >> Dec 13 10:12:21 archive last message repeated 18 times M> >> Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> > M> > What Subversion revision are you running? Did this start happening after a M> > recent update? I ask because r309745 was committed a few days ago and might M> > have changed the behavior. M> M> That's consistent with my observations. I was in Australia for a couple M> of weeks and have just updated from SVN r309056 to r309852, The r310032 should fix it. I'm sorry for the problem. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM_I915_GEM_OBJECT_MAX_PIN_COUNT failure on -current
On 12/13/16 12:07, Konstantin Belousov wrote: On Tue, Dec 13, 2016 at 11:49:37AM -0500, Michael Butler wrote: I've been bitten by this twice on a KDE desktop in the last 24 hours .. same error on both occasions :-( error: [drm:pid1197:i915_gem_object_pin] *ERROR* WARN ON: obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pid 1197 (Xorg), uid 0: exited on signal 6 (core dumped) [ .. ] error: [drm:pid16212:i915_gem_object_pin] *ERROR* WARN ON: obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pid 16212 (Xorg), uid 0: exited on signal 6 (core dumped) I see only one change in the dev/drm2 sources (r309712) but there have been many in the vm code. Any hints/pointers appreciated, This is indeed a bug in r309712, it seems. Please try this. diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c index 2a53ae8f8ed..0fa5249e553 100644 --- a/sys/dev/drm2/i915/i915_gem.c +++ b/sys/dev/drm2/i915/i915_gem.c @@ -1521,7 +1521,7 @@ retry: [ .. ] That seems to have fixed it - thanks for the quick response :-) Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On 2016-12-13 10:24, Michael Butler wrote: > Any hints as to why all of my -current equipment is complaining like > below. Is there a sysctl to moderate/turn this off? > > Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to > 200 packets/sec > Dec 13 10:00:21 archive last message repeated 13 times > Dec 13 10:02:21 archive last message repeated 18 times > Dec 13 10:06:21 archive last message repeated 36 times > Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to > 200 packets/sec > Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to > 200 packets/sec > Dec 13 10:08:21 archive last message repeated 17 times > Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 > to 200 packets/sec > Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to > 200 packets/sec > Dec 13 10:10:21 archive last message repeated 17 times > Dec 13 10:12:21 archive last message repeated 18 times > Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to > 200 packets/sec > Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to > 200 packets/sec > Dec 13 10:14:21 archive last message repeated 17 times > Dec 13 10:16:21 archive last message repeated 18 times > > Michael > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Yeah, this is a bug. When working as intended, the message would read: kernel: Limiting closed port RST response from 201 to 200 packets/sec The first value would be higher than the 2nd value (net.inet.icmp.icmplim). It should only alert if it is actually limiting the response rate. You can mute it by setting: net.inet.icmp.icmplim_output=0 -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 07:25:29PM +0200, Konstantin Belousov wrote: > This is not what I expected. > Also, I realized that I mis-read the memory test code. It does not > obliterate memory, old content is preserved. > > Please do exactly the same testing with another patch, at the end of the > message. There could be more output, up to 256 lines. No problem. Booting... KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=00099c00 SMAP type=02 base=00099c00 len=6400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=7906b000 SMAP type=02 base=7916b000 len=00936000 SMAP type=04 base=79aa1000 len=00509000 SMAP type=02 base=79faa000 len=02056000 SMAP type=01 base=0001 len=001f8000 SMAP type=02 base=7c00 len=1400 SMAP type=02 base=fed1c000 len=00029000 SMAP type=02 base=ff00 len=0100 TTT1 0xf8207ff0 0xf8207fb8 10 . 0 . 1000 . 2000 . 3000 . 4000 . 5000 . 6000 . 7000 . 8000 . 9000 . a000 . b000 . c000 . d000 . e000 . f000 . 1 . 11000 . 12000 . 13000 . 14000 . 15000 . 16000 . 17000 . 18000 . 19000 . 1a000 . 1b000 . 1c000 . 1d000 . 1e000 . 1f000 . 2 . 21000 . 22000 . 23000 . 24000 . 25000 . 26000 . 27000 . 28000 . 29000 . 2a000 . 2b000 > > > > > If the patched kernel boots succesfully, or if the patched kernel > > > boots further, I will provide one more, last patch, to test. > > > > please, next time point what verion of source need to patch: vanila or > > already patched. > I usually send full patches, i.e. the patch must be applied to the clean > checkout. Patch the vanilla sources. np. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 06:28:38PM +0300, Slawa Olhovchenkov wrote:
> On Tue, Dec 13, 2016 at 05:01:39PM +0200, Konstantin Belousov wrote:
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> SMAP type=01 base= len=00099c00
> SMAP type=02 base=00099c00 len=6400
> SMAP type=02 base=000e len=0002
> SMAP type=01 base=0010 len=7906b000
> SMAP type=02 base=7916b000 len=00936000
> SMAP type=04 base=79aa1000 len=00509000
> SMAP type=02 base=79faa000 len=02056000
> SMAP type=01 base=0001 len=001f8000
> SMAP type=02 base=7c00 len=1400
> SMAP type=02 base=fed1c000 len=00029000
> SMAP type=02 base=ff00 len=0100
> TTT1 0xf8207ff0 0xf8207fb8 10
This is not what I expected.
Also, I realized that I mis-read the memory test code. It does not
obliterate memory, old content is preserved.
Please do exactly the same testing with another patch, at the end of the
message. There could be more output, up to 256 lines.
>
> > If the patched kernel boots succesfully, or if the patched kernel
> > boots further, I will provide one more, last patch, to test.
>
> please, next time point what verion of source need to patch: vanila or
> already patched.
I usually send full patches, i.e. the patch must be applied to the clean
checkout. Patch the vanilla sources.
diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c
index f275aef3b4f..1be7a629f65 100644
--- a/sys/kern/subr_msgbuf.c
+++ b/sys/kern/subr_msgbuf.c
@@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size)
mbp->msg_ptr = ptr;
mbp->msg_size = size;
mbp->msg_seqmod = SEQMOD(size);
+printf("YYY1\n");
msgbuf_clear(mbp);
+printf("YYY2\n");
mbp->msg_magic = MSG_MAGIC;
mbp->msg_lastpri = -1;
mbp->msg_flags = 0;
+printf("YYY3\n");
bzero(&mbp->msg_lock, sizeof(mbp->msg_lock));
mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN);
+printf("YYY4\n");
}
+
/*
* Reinitialize a message buffer, retaining its previous contents if
* the size and checksum are correct. If the old contents cannot be
@@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size)
{
u_int cksum;
- if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
+ if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
+printf("XXX1\n");
msgbuf_init(mbp, ptr, size);
+printf("XXX2\n");
return;
}
mbp->msg_seqmod = SEQMOD(size);
@@ -117,10 +124,12 @@ void
msgbuf_clear(struct msgbuf *mbp)
{
+printf("ZZZ1\n");
bzero(mbp->msg_ptr, mbp->msg_size);
mbp->msg_wseq = 0;
mbp->msg_rseq = 0;
mbp->msg_cksum = 0;
+printf("ZZZ2\n");
}
/*
diff --git a/sys/kern/subr_prf.c b/sys/kern/subr_prf.c
index e78863830c7..a72984dbc19 100644
--- a/sys/kern/subr_prf.c
+++ b/sys/kern/subr_prf.c
@@ -998,6 +998,14 @@ msgbufinit(void *ptr, int size)
char *cp;
static struct msgbuf *oldp = NULL;
+printf("TTT1 %p %p %x\n", ptr, (char *)ptr + size - sizeof(*msgbufp), size);
+for (int i = 0; i < size; i++) {
+if (i % PAGE_SIZE == 0) printf(". %x\n", i);
+ volatile char *c = (char *)ptr + i;
+ char tmp;
+ tmp = *c;
+ *c = tmp;
+}
size -= sizeof(*msgbufp);
cp = (char *)ptr;
msgbufp = (struct msgbuf *)(cp + size);
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On Tue, Dec 13, 2016 at 11:19:18AM -0500, Michael Butler wrote: > On 12/13/16 11:15, Gary Palmer wrote: > > On Tue, Dec 13, 2016 at 10:43:27AM -0500, Michael Butler wrote: > >> On 12/13/16 10:29, Dimitry Andric wrote: > >> > >>> Somebody is most likely port scanning your machines. I see this all the > >>> time on boxes connected to the internet. > >> > >> As are mine. I wouldn't mind so much if the message contained sufficient > >> useful information that could be acted on, e.g. originating IP address > >> and, when appropriate, destination port. > > > > sysctl net.inet.tcp.log_in_vain=1 > > sysctl net.inet.udp.log_in_vain=1 > > > > be prepared for a lot of logs if you are being port scanned > > Or, apparently, have a windoze box on that segment :-( Windows client boxes at least do a lot of broadcasts, but in my experience they don't trigger log_in_vain (maybe they will if you have promisc network interfaces enabled). Not sure about servers as I don't have any at home. Gary ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM_I915_GEM_OBJECT_MAX_PIN_COUNT failure on -current
On Tue, Dec 13, 2016 at 11:49:37AM -0500, Michael Butler wrote:
> I've been bitten by this twice on a KDE desktop in the last 24 hours ..
> same error on both occasions :-(
>
> error: [drm:pid1197:i915_gem_object_pin] *ERROR* WARN ON: obj->pin_count
> == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT
> pid 1197 (Xorg), uid 0: exited on signal 6 (core dumped)
>
> [ .. ]
>
> error: [drm:pid16212:i915_gem_object_pin] *ERROR* WARN ON:
> obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT
> pid 16212 (Xorg), uid 0: exited on signal 6 (core dumped)
>
> I see only one change in the dev/drm2 sources (r309712) but there have
> been many in the vm code.
>
> Any hints/pointers appreciated,
This is indeed a bug in r309712, it seems. Please try this.
diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c
index 2a53ae8f8ed..0fa5249e553 100644
--- a/sys/dev/drm2/i915/i915_gem.c
+++ b/sys/dev/drm2/i915/i915_gem.c
@@ -1521,7 +1521,7 @@ retry:
/* Now bind it into the GTT if needed */
ret = i915_gem_object_pin(obj, 0, true, false);
if (ret)
- goto unpin;
+ goto unlock;
pinned = 1;
ret = i915_gem_object_set_to_gtt_domain(obj, write);
@@ -1580,6 +1580,8 @@ have_page:
return (VM_PAGER_OK);
unpin:
+ i915_gem_object_unpin(obj);
+unlock:
DRM_UNLOCK(dev);
out:
KASSERT(ret != 0, ("i915_gem_pager_fault: wrong return"));
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
DRM_I915_GEM_OBJECT_MAX_PIN_COUNT failure on -current
I've been bitten by this twice on a KDE desktop in the last 24 hours .. same error on both occasions :-( error: [drm:pid1197:i915_gem_object_pin] *ERROR* WARN ON: obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pid 1197 (Xorg), uid 0: exited on signal 6 (core dumped) [ .. ] error: [drm:pid16212:i915_gem_object_pin] *ERROR* WARN ON: obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pid 16212 (Xorg), uid 0: exited on signal 6 (core dumped) I see only one change in the dev/drm2 sources (r309712) but there have been many in the vm code. Any hints/pointers appreciated, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On Tue, Dec 13, 2016 at 11:07:19AM -0500, Michael Butler wrote: M> On 12/13/16 10:48, Eric van Gyzen wrote: M> > On 12/13/2016 09:24, Michael Butler wrote: M> >> Any hints as to why all of my -current equipment is complaining like below. Is M> >> there a sysctl to moderate/turn this off? M> >> M> >> Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:00:21 archive last message repeated 13 times M> >> Dec 13 10:02:21 archive last message repeated 18 times M> >> Dec 13 10:06:21 archive last message repeated 36 times M> >> Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:08:21 archive last message repeated 17 times M> >> Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to 200 M> >> packets/sec M> >> Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:10:21 archive last message repeated 17 times M> >> Dec 13 10:12:21 archive last message repeated 18 times M> >> Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 M> >> packets/sec M> >> Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 M> >> packets/sec M> > M> > What Subversion revision are you running? Did this start happening after a M> > recent update? I ask because r309745 was committed a few days ago and might M> > have changed the behavior. M> M> That's consistent with my observations. I was in Australia for a couple M> of weeks and have just updated from SVN r309056 to r309852, Yes, this is our fail. I will take a look today. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On 12/13/16 11:15, Gary Palmer wrote: On Tue, Dec 13, 2016 at 10:43:27AM -0500, Michael Butler wrote: On 12/13/16 10:29, Dimitry Andric wrote: Somebody is most likely port scanning your machines. I see this all the time on boxes connected to the internet. As are mine. I wouldn't mind so much if the message contained sufficient useful information that could be acted on, e.g. originating IP address and, when appropriate, destination port. sysctl net.inet.tcp.log_in_vain=1 sysctl net.inet.udp.log_in_vain=1 be prepared for a lot of logs if you are being port scanned Or, apparently, have a windoze box on that segment :-( Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On Tue, Dec 13, 2016 at 10:43:27AM -0500, Michael Butler wrote: > On 12/13/16 10:29, Dimitry Andric wrote: > > > Somebody is most likely port scanning your machines. I see this all the > > time on boxes connected to the internet. > > As are mine. I wouldn't mind so much if the message contained sufficient > useful information that could be acted on, e.g. originating IP address > and, when appropriate, destination port. sysctl net.inet.tcp.log_in_vain=1 sysctl net.inet.udp.log_in_vain=1 be prepared for a lot of logs if you are being port scanned Regards, Gary ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On 12/13/16 10:48, Eric van Gyzen wrote: On 12/13/2016 09:24, Michael Butler wrote: Any hints as to why all of my -current equipment is complaining like below. Is there a sysctl to moderate/turn this off? Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:00:21 archive last message repeated 13 times Dec 13 10:02:21 archive last message repeated 18 times Dec 13 10:06:21 archive last message repeated 36 times Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 packets/sec Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:08:21 archive last message repeated 17 times Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to 200 packets/sec Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:10:21 archive last message repeated 17 times Dec 13 10:12:21 archive last message repeated 18 times Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 packets/sec Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec What Subversion revision are you running? Did this start happening after a recent update? I ask because r309745 was committed a few days ago and might have changed the behavior. That's consistent with my observations. I was in Australia for a couple of weeks and have just updated from SVN r309056 to r309852, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On 2016/12/13 15:43, Michael Butler wrote: > On 12/13/16 10:29, Dimitry Andric wrote: > >> Somebody is most likely port scanning your machines. I see this all the >> time on boxes connected to the internet. > > As are mine. I wouldn't mind so much if the message contained sufficient > useful information that could be acted on, e.g. originating IP address > and, when appropriate, destination port. If you want that sort of information, you can use pf(4) with a default rule to log and reject connections to your system. (Plus rules to permit traffic to legitimate services, obviously.) You can also just 'drop' the denied connections rather than the default response of sending back an ICMP unreachable or reset response, which will save you sending out a lot of itty-bitty packets that the port scanners wouldn't pay attention to anyhow. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On 12/13/2016 09:24, Michael Butler wrote: > Any hints as to why all of my -current equipment is complaining like below. Is > there a sysctl to moderate/turn this off? > > Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec > Dec 13 10:00:21 archive last message repeated 13 times > Dec 13 10:02:21 archive last message repeated 18 times > Dec 13 10:06:21 archive last message repeated 36 times > Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 > packets/sec > Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec > Dec 13 10:08:21 archive last message repeated 17 times > Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to > 200 > packets/sec > Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec > Dec 13 10:10:21 archive last message repeated 17 times > Dec 13 10:12:21 archive last message repeated 18 times > Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 > packets/sec > Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec What Subversion revision are you running? Did this start happening after a recent update? I ask because r309745 was committed a few days ago and might have changed the behavior. Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On 12/13/16 10:29, Dimitry Andric wrote: Somebody is most likely port scanning your machines. I see this all the time on boxes connected to the internet. As are mine. I wouldn't mind so much if the message contained sufficient useful information that could be acted on, e.g. originating IP address and, when appropriate, destination port. sysctl net.inet.icmp.icmplim_output=0, or increase the ICMP limit, if you want to help the port scanners. :-) I've added the sysctl to mute the warnings - thanks :-) Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Log spam: Limiting * response from 1 to 200 packets/sec
On 13 Dec 2016, at 16:24, Michael Butler wrote: > > Any hints as to why all of my -current equipment is complaining like below. Somebody is most likely port scanning your machines. I see this all the time on boxes connected to the internet. > Is there a sysctl to moderate/turn this off? > > Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec > Dec 13 10:00:21 archive last message repeated 13 times > Dec 13 10:02:21 archive last message repeated 18 times > Dec 13 10:06:21 archive last message repeated 36 times > Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 > packets/sec > Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec > Dec 13 10:08:21 archive last message repeated 17 times > Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to > 200 packets/sec > Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec > Dec 13 10:10:21 archive last message repeated 17 times > Dec 13 10:12:21 archive last message repeated 18 times > Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 > packets/sec > Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 > packets/sec > Dec 13 10:14:21 archive last message repeated 17 times > Dec 13 10:16:21 archive last message repeated 18 times sysctl net.inet.icmp.icmplim_output=0, or increase the ICMP limit, if you want to help the port scanners. :-) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 05:01:39PM +0200, Konstantin Belousov wrote: > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > SMAP type=01 base= len=00099c00 > > SMAP type=02 base=00099c00 len=6400 > > SMAP type=02 base=000e len=0002 > > SMAP type=01 base=0010 len=7906b000 > > SMAP type=02 base=7916b000 len=00936000 > > SMAP type=04 base=79aa1000 len=00509000 > > SMAP type=02 base=79faa000 len=02056000 > > SMAP type=01 base=0001 len=001f8000 > > SMAP type=02 base=7c00 len=1400 > > SMAP type=02 base=fed1c000 len=00029000 > > SMAP type=02 base=ff00 len=0100 > > XXX1 > > YYY1 > > ZZZ1 > > Ok, please do exactly the same testing with the following patch. KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=00099c00 SMAP type=02 base=00099c00 len=6400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=7906b000 SMAP type=02 base=7916b000 len=00936000 SMAP type=04 base=79aa1000 len=00509000 SMAP type=02 base=79faa000 len=02056000 SMAP type=01 base=0001 len=001f8000 SMAP type=02 base=7c00 len=1400 SMAP type=02 base=fed1c000 len=00029000 SMAP type=02 base=ff00 len=0100 TTT1 0xf8207ff0 0xf8207fb8 10 > If the patched kernel boots succesfully, or if the patched kernel > boots further, I will provide one more, last patch, to test. please, next time point what verion of source need to patch: vanila or already patched. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Log spam: Limiting * response from 1 to 200 packets/sec
Any hints as to why all of my -current equipment is complaining like below. Is there a sysctl to moderate/turn this off? Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:00:21 archive last message repeated 13 times Dec 13 10:02:21 archive last message repeated 18 times Dec 13 10:06:21 archive last message repeated 36 times Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200 packets/sec Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:08:21 archive last message repeated 17 times Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to 200 packets/sec Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:10:21 archive last message repeated 17 times Dec 13 10:12:21 archive last message repeated 18 times Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200 packets/sec Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200 packets/sec Dec 13 10:14:21 archive last message repeated 17 times Dec 13 10:16:21 archive last message repeated 18 times Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 05:34:01PM +0300, Slawa Olhovchenkov wrote:
> On Tue, Dec 13, 2016 at 05:11:14PM +0300, Slawa Olhovchenkov wrote:
>
> > On Tue, Dec 13, 2016 at 03:57:59PM +0200, Konstantin Belousov wrote:
> >
> > > On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote:
> > > > > Boot with NUMA enabled and interleave off.
> > > >
> > > > Already with patched kernel
> > > >
> > > > > Patch kernel with the 'if (1 || ...)' patch.
> > > > > Reboot, enter BIOS setup and enable interleave there.
> > > > > Try to boot - does it boot ?
> > > >
> > > > No.
> > > >
> > > > > If it did not booted, power machine off for 10 minutes.
> > > >
> > > > OK
> > > >
> > > > > Power it on, try to boot (with the same patched kernel).
> > > > > Does the machine boot now ?
> > > >
> > > > Don't boot.
> > >
> > > I am really puzzled. In other words, touching all memory causes the
> > > msgbuf to not hang.
> >
> > yes
> >
> > > Can you try one more experiment ?
> > > Take the patch below, apply it.
> > > >From the config where interleave is disabled, install new kernel.
> > > Reboot, enter BIOS setup and enable interleave.
> > > Set late_console to zero in loader.
> > > Do not enable memory test.
> > > Boot the patched kernel.
> > > Kernel must hang, according to your previous reports.
> > > I want to see the console log.
> >
> > Hmm. I am [already] show output from ddb, and guess kernel will be
> > hang at first wirte to *mbp, i.e. you don't see any in console log.
> >
> > OK, anyway I am try this pacth.
>
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> SMAP type=01 base= len=00099c00
> SMAP type=02 base=00099c00 len=6400
> SMAP type=02 base=000e len=0002
> SMAP type=01 base=0010 len=7906b000
> SMAP type=02 base=7916b000 len=00936000
> SMAP type=04 base=79aa1000 len=00509000
> SMAP type=02 base=79faa000 len=02056000
> SMAP type=01 base=0001 len=001f8000
> SMAP type=02 base=7c00 len=1400
> SMAP type=02 base=fed1c000 len=00029000
> SMAP type=02 base=ff00 len=0100
> XXX1
> YYY1
> ZZZ1
Ok, please do exactly the same testing with the following patch.
If the patched kernel boots succesfully, or if the patched kernel
boots further, I will provide one more, last patch, to test.
diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c
index f275aef3b4f..1be7a629f65 100644
--- a/sys/kern/subr_msgbuf.c
+++ b/sys/kern/subr_msgbuf.c
@@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size)
mbp->msg_ptr = ptr;
mbp->msg_size = size;
mbp->msg_seqmod = SEQMOD(size);
+printf("YYY1\n");
msgbuf_clear(mbp);
+printf("YYY2\n");
mbp->msg_magic = MSG_MAGIC;
mbp->msg_lastpri = -1;
mbp->msg_flags = 0;
+printf("YYY3\n");
bzero(&mbp->msg_lock, sizeof(mbp->msg_lock));
mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN);
+printf("YYY4\n");
}
+
/*
* Reinitialize a message buffer, retaining its previous contents if
* the size and checksum are correct. If the old contents cannot be
@@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size)
{
u_int cksum;
- if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
+ if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
+printf("XXX1\n");
msgbuf_init(mbp, ptr, size);
+printf("XXX2\n");
return;
}
mbp->msg_seqmod = SEQMOD(size);
@@ -117,10 +124,12 @@ void
msgbuf_clear(struct msgbuf *mbp)
{
+printf("ZZZ1\n");
bzero(mbp->msg_ptr, mbp->msg_size);
mbp->msg_wseq = 0;
mbp->msg_rseq = 0;
mbp->msg_cksum = 0;
+printf("ZZZ2\n");
}
/*
diff --git a/sys/kern/subr_prf.c b/sys/kern/subr_prf.c
index e78863830c7..435412d55ea 100644
--- a/sys/kern/subr_prf.c
+++ b/sys/kern/subr_prf.c
@@ -998,6 +998,8 @@ msgbufinit(void *ptr, int size)
char *cp;
static struct msgbuf *oldp = NULL;
+printf("TTT1 %p %p %x\n", ptr, (char *)ptr + size - sizeof(*msgbufp), size);
+bzero(ptr, size);
size -= sizeof(*msgbufp);
cp = (char *)ptr;
msgbufp = (struct msgbuf *)(cp + size);
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 05:11:14PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 03:57:59PM +0200, Konstantin Belousov wrote: > > > On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote: > > > > Boot with NUMA enabled and interleave off. > > > > > > Already with patched kernel > > > > > > > Patch kernel with the 'if (1 || ...)' patch. > > > > Reboot, enter BIOS setup and enable interleave there. > > > > Try to boot - does it boot ? > > > > > > No. > > > > > > > If it did not booted, power machine off for 10 minutes. > > > > > > OK > > > > > > > Power it on, try to boot (with the same patched kernel). > > > > Does the machine boot now ? > > > > > > Don't boot. > > > > I am really puzzled. In other words, touching all memory causes the > > msgbuf to not hang. > > yes > > > Can you try one more experiment ? > > Take the patch below, apply it. > > >From the config where interleave is disabled, install new kernel. > > Reboot, enter BIOS setup and enable interleave. > > Set late_console to zero in loader. > > Do not enable memory test. > > Boot the patched kernel. > > Kernel must hang, according to your previous reports. > > I want to see the console log. > > Hmm. I am [already] show output from ddb, and guess kernel will be > hang at first wirte to *mbp, i.e. you don't see any in console log. > > OK, anyway I am try this pacth. KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=00099c00 SMAP type=02 base=00099c00 len=6400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=7906b000 SMAP type=02 base=7916b000 len=00936000 SMAP type=04 base=79aa1000 len=00509000 SMAP type=02 base=79faa000 len=02056000 SMAP type=01 base=0001 len=001f8000 SMAP type=02 base=7c00 len=1400 SMAP type=02 base=fed1c000 len=00029000 SMAP type=02 base=ff00 len=0100 XXX1 YYY1 ZZZ1 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 03:57:59PM +0200, Konstantin Belousov wrote:
> On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote:
> > > Boot with NUMA enabled and interleave off.
> >
> > Already with patched kernel
> >
> > > Patch kernel with the 'if (1 || ...)' patch.
> > > Reboot, enter BIOS setup and enable interleave there.
> > > Try to boot - does it boot ?
> >
> > No.
> >
> > > If it did not booted, power machine off for 10 minutes.
> >
> > OK
> >
> > > Power it on, try to boot (with the same patched kernel).
> > > Does the machine boot now ?
> >
> > Don't boot.
>
> I am really puzzled. In other words, touching all memory causes the
> msgbuf to not hang.
yes
> Can you try one more experiment ?
> Take the patch below, apply it.
> >From the config where interleave is disabled, install new kernel.
> Reboot, enter BIOS setup and enable interleave.
> Set late_console to zero in loader.
> Do not enable memory test.
> Boot the patched kernel.
> Kernel must hang, according to your previous reports.
> I want to see the console log.
Hmm. I am [already] show output from ddb, and guess kernel will be
hang at first wirte to *mbp, i.e. you don't see any in console log.
OK, anyway I am try this pacth.
> diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c
> index f275aef3b4f..1be7a629f65 100644
> --- a/sys/kern/subr_msgbuf.c
> +++ b/sys/kern/subr_msgbuf.c
> @@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size)
> mbp->msg_ptr = ptr;
> mbp->msg_size = size;
> mbp->msg_seqmod = SEQMOD(size);
> +printf("YYY1\n");
> msgbuf_clear(mbp);
> +printf("YYY2\n");
> mbp->msg_magic = MSG_MAGIC;
> mbp->msg_lastpri = -1;
> mbp->msg_flags = 0;
> +printf("YYY3\n");
> bzero(&mbp->msg_lock, sizeof(mbp->msg_lock));
> mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN);
> +printf("YYY4\n");
> }
>
> +
> /*
> * Reinitialize a message buffer, retaining its previous contents if
> * the size and checksum are correct. If the old contents cannot be
> @@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size)
> {
> u_int cksum;
>
> - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
> + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
> +printf("XXX1\n");
> msgbuf_init(mbp, ptr, size);
> +printf("XXX2\n");
> return;
> }
> mbp->msg_seqmod = SEQMOD(size);
> @@ -117,10 +124,12 @@ void
> msgbuf_clear(struct msgbuf *mbp)
> {
>
> +printf("ZZZ1\n");
> bzero(mbp->msg_ptr, mbp->msg_size);
> mbp->msg_wseq = 0;
> mbp->msg_rseq = 0;
> mbp->msg_cksum = 0;
> +printf("ZZZ2\n");
> }
>
> /*
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote:
> > Boot with NUMA enabled and interleave off.
>
> Already with patched kernel
>
> > Patch kernel with the 'if (1 || ...)' patch.
> > Reboot, enter BIOS setup and enable interleave there.
> > Try to boot - does it boot ?
>
> No.
>
> > If it did not booted, power machine off for 10 minutes.
>
> OK
>
> > Power it on, try to boot (with the same patched kernel).
> > Does the machine boot now ?
>
> Don't boot.
I am really puzzled. In other words, touching all memory causes the
msgbuf to not hang.
Can you try one more experiment ?
Take the patch below, apply it.
>From the config where interleave is disabled, install new kernel.
Reboot, enter BIOS setup and enable interleave.
Set late_console to zero in loader.
Do not enable memory test.
Boot the patched kernel.
Kernel must hang, according to your previous reports.
I want to see the console log.
diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c
index f275aef3b4f..1be7a629f65 100644
--- a/sys/kern/subr_msgbuf.c
+++ b/sys/kern/subr_msgbuf.c
@@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size)
mbp->msg_ptr = ptr;
mbp->msg_size = size;
mbp->msg_seqmod = SEQMOD(size);
+printf("YYY1\n");
msgbuf_clear(mbp);
+printf("YYY2\n");
mbp->msg_magic = MSG_MAGIC;
mbp->msg_lastpri = -1;
mbp->msg_flags = 0;
+printf("YYY3\n");
bzero(&mbp->msg_lock, sizeof(mbp->msg_lock));
mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN);
+printf("YYY4\n");
}
+
/*
* Reinitialize a message buffer, retaining its previous contents if
* the size and checksum are correct. If the old contents cannot be
@@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size)
{
u_int cksum;
- if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
+ if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
+printf("XXX1\n");
msgbuf_init(mbp, ptr, size);
+printf("XXX2\n");
return;
}
mbp->msg_seqmod = SEQMOD(size);
@@ -117,10 +124,12 @@ void
msgbuf_clear(struct msgbuf *mbp)
{
+printf("ZZZ1\n");
bzero(mbp->msg_ptr, mbp->msg_size);
mbp->msg_wseq = 0;
mbp->msg_rseq = 0;
mbp->msg_cksum = 0;
+printf("ZZZ2\n");
}
/*
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On Sun, Dec 11, 2016 at 12:07 AM, Andrey V. Elsukov wrote: > Hi All, > > I am pleased to announce that projects/ipsec, that I started several > months ago is ready for testing and review. > The main goals were: > * rework locking to make IPsec code more friendly for concurrent > processing; > * make lookup in SADB/SPDB faster; > * revise PFKEY implementation, remove stale code, make it closer > to RFC; > * implement IPsec VTI (virtual tunneling interface); > * make IPsec code loadable as kernel module. > > I've got a very simple configuration (static key),but I like the performance improvement brings by projects/ipsec :-) A simple packet-per-second using null encryption should be enough for benching the improvement, but my IPSec lab (using Equilibrium methodology) did a little more. https://github.com/ocochard/netbenches/blob/master/AMD_GX- 412TC_4Cores_Intel_i210AT/ipsec/results/fbsd12.projects- ipsec.equilibrium/graph.png Thanks for your work! Olivier ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 01:23:40PM +0200, Konstantin Belousov wrote: > On Tue, Dec 13, 2016 at 02:14:37PM +0300, Slawa Olhovchenkov wrote: > > On Tue, Dec 13, 2016 at 01:05:35PM +0200, Konstantin Belousov wrote: > > > > > On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > > > > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > > > > > > > Try the debugging patch below, which unconditionally disables > > > > > import of > > > > > previous buffer. To test, you would need to boot, then frob > > > > > options in > > > > > BIOS, reboot, again frob etc. > > > > > >>> > > > > > >>> still need test patch? if yes, with BIOS options? > > > > > >> Yes, please test the patch. I explained the procedure above. > > > > > > > > > > > > sorry, i don't know 'frob'. > > > > > > what exactly options combination I need test and what about memory > > > > > > test? > > > > > > > > > > > > > > > > > > > > > The idea is that when rebooting, stale memory contents remain, but are > > > > > corrupted due to interleave. > > > > > > > > > > "Frob" basically means "mess with". So apply patch, test kernel, > > > > > reboot, change NUMA option, reboot again, see if it works, and so on. > > > > > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > > > > > interleave=on, etc etc. > > > > > > > > NUMA=on interleave=off booted > > > > NUMA=on interleave=on hang > > > > > > > > I think different combination whatever? > > > > > > Do you mean, that both patched kernel, and unpatched kernel with the > > > memory test enabled, hang when NUMA and interleave options enabled ? > > > > Unpatched kernel boot with the memory test enabled when NUMA and > > interleave options enabled -- I am already reported this. > > > > patched kernel with the memory test enabled boot too. ^^ > > i.e. memory test enabled allow boot in any situation. > Then what about was the statement above ? About unpatched kernel https://lists.freebsd.org/pipermail/freebsd-current/2016-December/064069.html patched and test I am test now, and wrote in previos mail ^^^ > You said that NUMA and interleave > on caused hang. Was that on the patched kernel ? patched w/o memory test > > > > > Could you enable the options, power down the machine for 10-20 minutes, > > > and try to boot ? > > > > For with kernel and bios options and boot options? > > I am have two day befor server put in production for any expirements, > > but please, be more clear in what combination need to test. > > Boot with NUMA enabled and interleave off. Already with patched kernel > Patch kernel with the 'if (1 || ...)' patch. > Reboot, enter BIOS setup and enable interleave there. > Try to boot - does it boot ? No. > If it did not booted, power machine off for 10 minutes. OK > Power it on, try to boot (with the same patched kernel). > Does the machine boot now ? Don't boot. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD_amd64_gcc - Build #1731 - Still Failing
FreeBSD_HEAD_amd64_gcc - Build #1731 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1731/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1731/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1731/console Change summaries: 310018 by mizhka: [gpiospi] add clock delay to avoid smashing of bits Submitted by: Hiroki Mori Reviewed by:loos, ray, mizhka MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D8749 310017 by mizhka: [spi] reformat message and ar5315_spi minor fix This commit corrects print of nomatch (newline was too early) and fix unit number for new child in ar5315_spi (was 0, now is -1 to calculate it according to actual system state) Submitted by: Hiroki Mori Reviewed by:ray, loos, mizhka MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D8749 310014 by ed: Remove the only user of sysctl_add_oid(). My plan is to change this function's prototype at some point in the future to add a new label argument, which can be used to export all of sysctl as metrics that can be scraped by Prometheus. Switch over this caller to use the macro wrapper counterpart. 310013 by cperciva: Check that blkfront devices have a non-zero number of sectors and a non-zero sector size. Such a device would be a virtual disk of zero bytes; clearly not useful, and not something we should try to attach. As a fortuitous side effect, checking that these values are non-zero here results in them not *becoming* zero later on the function. This odd behaviour began with r309124 (clang 3.9.0) but is challenging to debug; making any changes to this function whatsoever seems to affect the llvm optimizer behaviour enough to make the unexpected zeroing of the sector_size variable cease. PR: 215209 Security: The potential for variables to unexpectedly become zero has worrying consequences for security in general, but not so much in this particular context. 310012 by gonzo: [iMX6] Add compatibility string for GPT timer on i.MX6 Dual Up until r295436 GPT timer in i.MX6 Dual dts used the same compatiblity string as i.MX6 Quad. After the sync up with Linux in r295436, GPT timer stopped getting attached on the i.MX6 Dual MFC after: 3 days 31 by loos: Remove a too strict test and instead, just filter the passed flags with the supported capabilities. Spotted by: yamori...@yahoo.co.jp (Hiroki Mori) MFC after: 2 weeks 30 by gonzo: [iMX6] Fix platform compatibility string for i.MX6 Dual i.MX6 Dual boot was broken since r308533 because ofw_bus_node_is_compatible is more strict than fdt_is_compatible and does not accept partial matches 309998 by dteske: It's completely pointless to replace newlines with space (this is done automatically for you upon shell expansion) 309997 by dteske: The flags of a WLAN need to be quoted (they contain things like brackets) 309996 by dteske: Simplify single-line if statements 309995 by dteske: Simplify loop by moving predicate to clause 309994 by dteske: Wordsmithing 309993 by dteske: Why test $? when you can test the command 309992 by dteske: Restore previous comment 309991 by dteske: Both simplify bringup of interface after changes and catch errors in debug 309990 by dteske: Calculate proper size of menu list dialog 309989 by dteske: There's an API function for catching errors and displaying them or logging them to debug output 309988 by dteske: There's an API function for displaying pauses 309987 by dteske: There's an API function for displaying yes/no dialogs 309986 by dteske: There's an API function for displaying errors 309985 by dteske: Comment 309984 by dteske: Whitespace alignment 309983 by dteske: Relying on dialog auto-sizing (width/height/rows = 0) is a mistake Use the provided API for calculating the appropriate size of menus 309982 by dteske: Remove unnecessary quotes 309981 by dteske: Add missing quotes 309980 by dteske: In awk, if you're going to append a newline to your printf AND you're going to print only the argument, just use print 309979 by dteske: This statement has too many backslashes 309978 by dteske: Neither printf (and as is commonly known) nor print need parens in awk 309977 by dteske: Whitespace and alignment 309976 by dteske: You don't need parentheses for awk's printf 309975 by dteske: Continued resolution of conveluted statement We shouldn't be coding things like "x || (x && x) || x || x || x ..." 309974 by dteske: These two error messages have always been backwards since inception 309973 by dteske: Why use $? when you can use the command itself 309972 by dteske: If the first ping succeeded, why on Earth should we ping it again? 309971 by dteske: Start deconstructing a conveluted hunk of code 309970 by dteske: Remove completely unnecesary parentheses 309969 by dteske: Why repeat yourself when you can send stde
Help
Hi FreeBSD Current Team, I need help with a few things: 1. I tried getting help from all kinds of irc chats but still no dice. 2. I cannot get my soundcard to work on FreeBSD. It is the Soundblaster Z(SB1500, SB1502) with the CA0132 codec. 3.Also i tried to get pipelight to work but doesnt work well on 64 bit and for some reason firefox wont detect pipelight plugins version 50.0.2 newest version available from ports. 4. Another potential problem with usb drive detection as well. Usb ports work just fine in something like windows and linux but not FreeBSD. I really LOVE FreeBSD i use it for workstation applications and professional use as well. Is there any way i could be referred to someone to can code the drivers needed to work with my hardware?? And possibly someone who could help me with my software problems. Thank you, FreeBSD Supporter ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 02:14:37PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 01:05:35PM +0200, Konstantin Belousov wrote: > > > On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > > > > > Try the debugging patch below, which unconditionally disables > > > > import of > > > > previous buffer. To test, you would need to boot, then frob > > > > options in > > > > BIOS, reboot, again frob etc. > > > > >>> > > > > >>> still need test patch? if yes, with BIOS options? > > > > >> Yes, please test the patch. I explained the procedure above. > > > > > > > > > > sorry, i don't know 'frob'. > > > > > what exactly options combination I need test and what about memory > > > > > test? > > > > > > > > > > > > > > > > > The idea is that when rebooting, stale memory contents remain, but are > > > > corrupted due to interleave. > > > > > > > > "Frob" basically means "mess with". So apply patch, test kernel, > > > > reboot, change NUMA option, reboot again, see if it works, and so on. > > > > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > > > > interleave=on, etc etc. > > > > > > NUMA=on interleave=off booted > > > NUMA=on interleave=on hang > > > > > > I think different combination whatever? > > > > Do you mean, that both patched kernel, and unpatched kernel with the > > memory test enabled, hang when NUMA and interleave options enabled ? > > Unpatched kernel boot with the memory test enabled when NUMA and > interleave options enabled -- I am already reported this. > > patched kernel with the memory test enabled boot too. > > i.e. memory test enabled allow boot in any situation. Then what about was the statement above ? You said that NUMA and interleave on caused hang. Was that on the patched kernel ? > > > Could you enable the options, power down the machine for 10-20 minutes, > > and try to boot ? > > For with kernel and bios options and boot options? > I am have two day befor server put in production for any expirements, > but please, be more clear in what combination need to test. Boot with NUMA enabled and interleave off. Patch kernel with the 'if (1 || ...)' patch. Reboot, enter BIOS setup and enable interleave there. Try to boot - does it boot ? If it did not booted, power machine off for 10 minutes. Power it on, try to boot (with the same patched kernel). Does the machine boot now ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 01:05:35PM +0200, Konstantin Belousov wrote: > On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > > > Try the debugging patch below, which unconditionally disables import > > > of > > > previous buffer. To test, you would need to boot, then frob options > > > in > > > BIOS, reboot, again frob etc. > > > >>> > > > >>> still need test patch? if yes, with BIOS options? > > > >> Yes, please test the patch. I explained the procedure above. > > > > > > > > sorry, i don't know 'frob'. > > > > what exactly options combination I need test and what about memory test? > > > > > > > > > > > > > The idea is that when rebooting, stale memory contents remain, but are > > > corrupted due to interleave. > > > > > > "Frob" basically means "mess with". So apply patch, test kernel, > > > reboot, change NUMA option, reboot again, see if it works, and so on. > > > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > > > interleave=on, etc etc. > > > > NUMA=on interleave=off booted > > NUMA=on interleave=on hang > > > > I think different combination whatever? > > Do you mean, that both patched kernel, and unpatched kernel with the > memory test enabled, hang when NUMA and interleave options enabled ? Unpatched kernel boot with the memory test enabled when NUMA and interleave options enabled -- I am already reported this. patched kernel with the memory test enabled boot too. i.e. memory test enabled allow boot in any situation. > Could you enable the options, power down the machine for 10-20 minutes, > and try to boot ? For with kernel and bios options and boot options? I am have two day befor server put in production for any expirements, but please, be more clear in what combination need to test. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > Try the debugging patch below, which unconditionally disables import of > > previous buffer. To test, you would need to boot, then frob options in > > BIOS, reboot, again frob etc. > > >>> > > >>> still need test patch? if yes, with BIOS options? > > >> Yes, please test the patch. I explained the procedure above. > > > > > > sorry, i don't know 'frob'. > > > what exactly options combination I need test and what about memory test? > > > > > > > > > The idea is that when rebooting, stale memory contents remain, but are > > corrupted due to interleave. > > > > "Frob" basically means "mess with". So apply patch, test kernel, > > reboot, change NUMA option, reboot again, see if it works, and so on. > > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > > interleave=on, etc etc. > > NUMA=on interleave=off booted > NUMA=on interleave=on hang > > I think different combination whatever? Do you mean, that both patched kernel, and unpatched kernel with the memory test enabled, hang when NUMA and interleave options enabled ? Could you enable the options, power down the machine for 10-20 minutes, and try to boot ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
