Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386

2017-05-28 Thread Andriy Gapon
On 28/05/2017 01:09, Kamil Czekirda wrote: > In initial revision I noticed, that I'm not sure it should be default > behavior. > In a lot of installations pxeloader can base on the cache and doesn't require > second, full request with the same answer. In that situation we can switch off > bootp()

Re: [panic] netmap(4) and if_lagg(4)

2017-05-28 Thread Vincenzo Maffione
Hi Harry, 2017-05-26 14:22 GMT+02:00 Harry Schmalzbauer : > Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 11:06 (localtime): > > Yes, it should integrate and compile out of the box, I've done that > > several times with FreeBSD-11.0 and 10.3. > > Impressive, it needed just a small addit

Re: [panic] netmap(4) and if_lagg(4)

2017-05-28 Thread Harry Schmalzbauer
Bezüglich Vincenzo Maffione's Nachricht vom 28.05.2017 09:46 (localtime): >> >> I also recomplied vale-ctl, but I get the following error when trying to >> add em0 (lagg-unrelated): >> 389.083433 [ 835] netmap_obj_malloc netmap_ring request size >> 65792 too large >> 389.091593 [1693] netma

Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386

2017-05-28 Thread Rodney W. Grimes
> On 28/05/2017 01:09, Kamil Czekirda wrote: > > In initial revision I noticed, that I'm not sure it should be default > > behavior. > > In a lot of installations pxeloader can base on the cache and doesn't > > require > > second, full request with the same answer. In that situation we can switch

Problem reports for freebsd-net@FreeBSD.org that need special attention

2017-05-28 Thread bugzilla-noreply
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and ob

Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386

2017-05-28 Thread Andriy Gapon
On 28/05/2017 18:38, Rodney W. Grimes wrote: >> On 28/05/2017 01:09, Kamil Czekirda wrote: >>> In initial revision I noticed, that I'm not sure it should be default >>> behavior. >>> In a lot of installations pxeloader can base on the cache and doesn't >>> require >>> second, full request with th

[Bug 219625] Can't connect to Internet with Realtek 8111E/8168 Ethernet: both 11.0-STABLE and CURRENT

2017-05-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219625 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org --- Comment

[Bug 205592] TCP processing in IPSec causes kernel panic

2017-05-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205592 Eugene Grosbein changed: What|Removed |Added CC||eu...@freebsd.org --- Comment #6

[Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)

2017-05-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136 Eugene Grosbein changed: What|Removed |Added CC||eu...@freebsd.org --- Comment #1

[Bug 203422] mpd/ppoe not working with re(4) with revision 285177

2017-05-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203422 Eugene Grosbein changed: What|Removed |Added CC||eu...@freebsd.org Resolu

[Bug 219625] Re: Can't connect to Internet with Realtek 8111E/8168 Ethernet: both 11.0-STABLE and CURRENT

2017-05-28 Thread Thomas Mueller
--- Comment #1 from Mark Linimon --- Is this problem also in FreeBSD 10? This problem was in FreeBSD 10 but was fixed somewhere around the time of 10.2. As for possible relapse, I can't say, because I no longer have 10.x-STABLE on hard drive: updated to 11.0-STABLE. Tom __

Re: Basic support for IEEE 802.3ae clause 45 phys?

2017-05-28 Thread Sebastian Huber
On 24/05/17 10:21, Sebastian Huber wrote: Hello, is there some basic support for IEEE 802.3ae clause 45 phys planned in FreeBSD? It seems there was some activity in this area: https://reviews.freebsd.org/D4607 However, I cannot find any uses of the MDIO_READEXTREG and MDIO_WRITEEXTREG met

OCD window scaling behavior on local network.

2017-05-28 Thread Zaphod Beeblebrox
so... I have some really OCD window scaling behavior on a GigE local network. The protocol is BGP, this is one session recorded. Nearly every payload packet is answered by both an 'ACK' and a 2nd window scaling packet. I have examined the packet counters: no errors reported by the box or the man