Pay for driving on toll road, invoice #00435890
Notice to Appear, You have not paid for driving on a toll road. Please service your debt in the shortest possible time. You can find the invoice is in the attachment. Yours faithfully, Glenn Lutz, E-ZPass Support. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199478] tools/regression/sockets/unix_cmsg fails on 10.1-STABLE/11-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199478 --- Comment #1 from commit-h...@freebsd.org --- A commit references this bug: Author: ngie Date: Thu Apr 16 06:06:46 UTC 2015 New revision: 281588 URL: https://svnweb.freebsd.org/changeset/base/281588 Log: Update comments Don't install/test unix_cmsg because it's broken [1] PR: 199478 Changes: user/ngie/more-tests/tests/sys/socket/Makefile -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199478] tools/regression/sockets/unix_cmsg fails on 10.1-STABLE/11-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199478 Garrett Cooper,425-314-3911 changed: What|Removed |Added CC||freebsd-net@FreeBSD.org, ||pluk...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
The problem here is that the intersection between "people running large scale ALTQ" and "people contributing back to FreeBSD and driving development for ALTQ" is very minimal. It's at least pfsense/netgate, and maybe a couple of others. It's certainly not a very large group. -adrian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
pxeboot with newer Intel NICs
I am having trouble using pxeboot with new-ish Intel NICs. We have been using pxeboot with Intel NICs as part of our infrastructure for a while successfully. Recently, I got some new 2x10G (ixgbe) cards as well as a motherboard with built-in 4x1G (igb). Neither will work with pxeboot. If I install an older 4x1G PCI card in the same server, then it will boot with pxeboot just fine. It fails at the point that it tries to load the kernel over NFS: PXE version 2.1, real mode entry point @94ee:0106 BIOS 619kB/1983288kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (r...@releng1.nyi.freebsd.org, Tue Nov 11 20:57:26 UTC 2014) pxe_open: server addr: 10.2.16.3 pxe_open: server path: /usr/tftpboot/mfg_FXT5000_WIP / It just sticks there indefinitely. I took a packet capture on the dhcp/tftp/nfs server (limited to the ip address I know this client is getting). The initial tftp download of the pxeboot program goes through. Then I see more dhcp packets (which I assume are from pxeboot program). Then it sends a portmapper request to get the port for the mount program. The packet capture on the server shows a proper response, but I assume the client is not accepting it, because it seems to retry the portmapper request repeatedly. 2 2.018066 10.2.15.238 -> 10.2.16.3TFTP Read Request, File: pxeboot, Transfer type: octet, tsize\000=0\000 66 3 2.02581310.2.16.3 -> 10.2.15.238 TFTP Option Acknowledgement, tsize\000=231424\000 57 4 2.025869 10.2.15.238 -> 10.2.16.3TFTP Error Code, Code: Not defined, Message: TFTP Aborted 60 5 2.026980 10.2.15.238 -> 10.2.16.3TFTP Read Request, File: pxeboot, Transfer type: octet, blksize\000=1456\000 71 6 2.03440810.2.16.3 -> 10.2.15.238 TFTP Option Acknowledgement, blksize\000=1456\000 57 7 2.034462 10.2.15.238 -> 10.2.16.3TFTP Acknowledgement, Block: 0 60 8 2.03454410.2.16.3 -> 10.2.15.238 TFTP Data Packet, Block: 1 1502 9 2.034675 10.2.15.238 -> 10.2.16.3TFTP Acknowledgement, Block: 1 60 10 2.03469910.2.16.3 -> 10.2.15.238 TFTP Data Packet, Block: 2 1502 11 2.034829 10.2.15.238 -> 10.2.16.3TFTP Acknowledgement, Block: 2 60 .. clipped a bunch of uninteresting data packets .. 324 2.05898910.2.16.3 -> 10.2.15.238 TFTP Data Packet, Block: 159 1422 325 2.059115 10.2.15.238 -> 10.2.16.3TFTP Acknowledgement, Block: 159 60 326 2.124531 10.2.15.238 -> 10.2.16.3DHCP DHCP Discover - Transaction ID 0x2005fe90 590 327 2.638748 10.2.15.238 -> 10.2.16.3DHCP DHCP Request - Transaction ID 0x2005fe90 590 328 2.657297 10.2.15.238 -> 10.2.16.3Portmap V2 GETPORT Call MOUNT(15) V:3 UDP 118 329 2.65739810.2.16.3 -> 10.2.15.238 Portmap V2 GETPORT Reply (Call In 328) Port:644 70 330 4.293463 10.2.15.238 -> 10.2.16.3Portmap [RPC retransmission of #328]V2 GETPORT Call (Reply In 329) MOUNT(15) V:3 UDP 118 331 4.29353610.2.16.3 -> 10.2.15.238 Portmap [RPC duplicate of #329]V2 GETPORT Reply (Call In 328) Port:644 70 332 8.138219 10.2.15.238 -> 10.2.16.3Portmap [RPC retransmission of #328]V2 GETPORT Call (Reply In 329) MOUNT(15) V:3 UDP 118 333 8.13830110.2.16.3 -> 10.2.15.238 Portmap [RPC duplicate of #329]V2 GETPORT Reply (Call In 328) Port:644 70 334 14.179978 10.2.15.238 -> 10.2.16.3Portmap [RPC retransmission of #328]V2 GETPORT Call (Reply In 329) MOUNT(15) V:3 UDP 118 335 14.18008410.2.16.3 -> 10.2.15.238 Portmap [RPC duplicate of #329]V2 GETPORT Reply (Call In 328) Port:644 70 I did notice that these new cards have newer versions of the "Intel Boot Agent" firmware. Here is a summary of the versions I tried: Intel Boot Agent XE v2.3.04 (10G) -> FAILED Intel Boot Agent GE v1.5.12 (1G) -> FAILED Intel Boot Agent XE v2.1.60 (10G) -> WORKS Intel Boot Agent GE v1.3.51 (1g) -> WORKS Also, the 1G that works is an 82580, while the one that fails is an i350. The working and failed 10G NICs are both 82599EB. My assumption is that there is some incompatibility between the PXE firmware on the newer cards and the pxeboot program. However, these are very widely used NICs and if this is really the problem it's a little hard to believe other people haven't hit this. Are other people using newer Intel 10G (ixgbe) or 1G (igb) NICs with pxeboot successfully? Jeremiah Lott Avere Systems ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136 --- Comment #6 from y...@rawbw.com --- There is also option called TAP_VMNET there. This is for now unused (?) VMWare VM. 'downonclose' variable works in a very similar way, but without the need to morph of tapN into vmnetN. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136 --- Comment #5 from y...@rawbw.com --- This is the application that practically benefits from this: https://github.com/yurivict/freebsd-vbox-to-tor -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136 --- Comment #4 from y...@rawbw.com --- > can you use some of IFF_LINK flags to implement the needed feature? You mean one of IFF_LINK[0-2]? I guess this is possible, but this would require someone setting such flag on tapN interface. The way with sysctl variable is more in line with existing "uponopen" variable (similar, but for close event). Also it introduces the new default that better corresponds to the needs of most apps (I believe). So I think sysctl variable is better. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199174] em tx and rx hang
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 m...@sentex.net changed: What|Removed |Added CC||m...@sentex.net --- Comment #6 from m...@sentex.net --- Just out of curiosity, try disabling TSO on the interface as a work around. The symptoms are similar to what I saw in https://lists.freebsd.org/pipermail/freebsd-stable/2014-September/080081.html -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
On Wed, Apr 15, 2015 at 5:26 AM, Gleb Smirnoff wrote: > On Wed, Apr 15, 2015 at 09:38:23AM +0200, Luigi Rizzo wrote: > L> > With the new ifnet KPI, that is now being developed in > projects/ifnet, > L> > the ALTQ will need some tweaking. It is discontinued by initial author > L> > for a decade now, and it has already experienced direct commits in > L> > our tree. Thus, I see no good reasons to continue keeping it in > contrib. > L> > In NetBSD they have it in sys/altq. > L> > > L> > I'd prefer to move it to sys/net/altq. > L> > > L> > Any objections or better ideas? > L> > L> my first question is what is the expected residual lifetime of altq ? > > If I get it working properly in projects/ifnet, I see no reasons to > remove it. It is going to be a plugin into network stack and will no > longer require editing drivers. It will run on drivers that aren't > supported by ALTQ now. However in the latter case the ALTQ will sit > on top of interface own queue, and will start to work only when > interface's own queue overflows. But if we later add a new interface > method to modify length of own queue at runtime, this issue will > go away. > For what its worth, I maintain 300+ systems acting as PF+ALTQ routers, among other things. I've been doing this for the last 8 years or so (since 7.2 and now running 10.1), and have dealt with all the issues and workarounds surrounding lack of multiqueue support and driver compatibility, but at the end of the day ALTQ still does the job despite its performance issues. I would be in bad shape if it were simply removed at some point in the future. The changes you propose to not only keep it around officially, but make it more driver-agnostic and possibly behave better with multiqueue, sound absolutely fantastic. Thank you. > L> If it is destined to be removed soon (and probably that is not > L> unlikely given its unmaintained state, the absence of multiqueue > L> support etc.) maybe we could live for the next > L> couple of years just leaving it where it is now and avoid the > L> repo churn. > L> > L> If we really plan to relocate the code, I guess the options are > L> > L> sys/altq as in netbsd > L> > L> sys/netaltq this would be an alternative location to > L> the above one, justified by the fact that > L> we have already a bunch of net* subdirs > L> > L> sys/net/altq as you propose, i guess to stay close to > L> the rest of the ifnet code (and perhaps > L> as a first step in cleaning up sys/net > L> by putting stuff in various subdirs) > L> > L> In any case my preference would really be to leave it where it is. > > I don't like to keep in contrib a code maintained and edited by the > project. Especially I don't like tautological path of contrib/altq/altq. > I don't like extra glue in Makefiles, especially modyfing CFLAGS for the > whole kernel build. > I'm not a major committer other than the occasional patch submission for various things, but the contrib/altq location has always perplexed me. I don't see it as a contribution. > If it is a regular piece of kernel code, let it be like the rest of > kernel code. > > -- > Totus tuus, Glebius. > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136 Andrey V. Elsukov changed: What|Removed |Added CC||a...@freebsd.org --- Comment #3 from Andrey V. Elsukov --- Hello, can you use some of IFF_LINK flags to implement the needed feature? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199287] Missing TCP retransmit timer reset
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199287 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199174] em tx and rx hang
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136 Mark Linimon changed: What|Removed |Added Keywords||patch Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel em (82574L and 82573L) problems: stopping on high network and cpu load (Watchdog timeout)
On Wed, 15-Apr-2015 at 10:18:12 -0400, Mike Tancsa wrote: > On 4/15/2015 1:42 AM, Andre Albsmeier wrote: > > On Tue, 14-Apr-2015 at 10:01:16 -0400, Mike Tancsa wrote: > >> On 4/14/2015 1:54 AM, Andre Albsmeier wrote: > >>> > >>> Is this an em specific issue or should one avoid TSO generally > >>> at the moment? That is, should I disable it on machines with > >>> msk (and maybe other) interfaces as well? > >> > >> em specific I think. This thread has some info on what might be going on > >> > >> https://lists.freebsd.org/pipermail/freebsd-stable/2014-September/080081.html > > > > Very interesting, thanks. Until now (and without TSO), the problem > > did not re-occur but I didn't hit the NFS heavily yet. > > Hi, > Just to be clear, the network hang has returned ? Or its still problem > free ? Since I started to use -tso the problem did not come back (until now, hope it stays like this). So it seems to be the correct workaround. -Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel em (82574L and 82573L) problems: stopping on high network and cpu load (Watchdog timeout)
On 4/15/2015 1:42 AM, Andre Albsmeier wrote: On Tue, 14-Apr-2015 at 10:01:16 -0400, Mike Tancsa wrote: On 4/14/2015 1:54 AM, Andre Albsmeier wrote: Is this an em specific issue or should one avoid TSO generally at the moment? That is, should I disable it on machines with msk (and maybe other) interfaces as well? em specific I think. This thread has some info on what might be going on https://lists.freebsd.org/pipermail/freebsd-stable/2014-September/080081.html Very interesting, thanks. Until now (and without TSO), the problem did not re-occur but I didn't hit the NFS heavily yet. Hi, Just to be clear, the network hang has returned ? Or its still problem free ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
On Wed, Apr 15, 2015 at 03:02:03PM +0200, Luigi Rizzo wrote: L> > L> Then if you do sys/net/altq/ do you also plan to split the current L> > L> content of sys/net/ into separate subdirectories ? L> > L> L> > L> We currently have quite a few separate things in sys/net/, such as L> > L> - various bpf files L> > L> - generic ifnet support (including raw sockets) L> > L> - various libraries (compression and hash functions) L> > L> - routing code L> > L> - bridging code L> > L> - a ton of special ifnets, (tun, tap, epair, gif, ) L> > L> - bridging code L> > L> that could benefit from a bit of partitioning L> > L> > I definitely agree that a) special interfaces b) lagg+lacp L> > c) generic libraries should be separated. I don't mind if anyone does L> > this job :) L> > L> > But I personally would prefer is this is done after the lifetime L> > of the projects/ifnet branch, since if stuff is moved while I work L> > on projects/ifnet, my merging will become a nightmare. I already have L> > conflicts quite often. L> > L> L> sure, there is no rush. L> I was just trying to understand why your preference is for sys/net/altq L> instead of sys/netaltq as we have for other components. I think that dropping everything into sys/ is historical. Perfectly, protoctols should live in net/ as well, like net/inet and net/inet6, but of course no one would support that move. The most recent network related subdir in sys/ is netpfil. Frankly speaking I didn't like the name, and that word wasn't my, but Bjoern's. But, if I advocated for net/pfil, then the argument would be that pfil hooks reside in sys/netinet and in sys/netinet6, not in sys/net, thus moving that into net/pfil is wrong. At the time I really wanted to gather or pfil consumers in one place, and move pf out of contrib, so I accepted name suggested by Bjoern without arguing. -- Totus tuus, Glebius. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
On Wed, Apr 15, 2015 at 2:59 PM, Gleb Smirnoff wrote: > On Wed, Apr 15, 2015 at 02:53:34PM +0200, Luigi Rizzo wrote: > L> Then if you do sys/net/altq/ do you also plan to split the current > L> content of sys/net/ into separate subdirectories ? > L> > L> We currently have quite a few separate things in sys/net/, such as > L> - various bpf files > L> - generic ifnet support (including raw sockets) > L> - various libraries (compression and hash functions) > L> - routing code > L> - bridging code > L> - a ton of special ifnets, (tun, tap, epair, gif, ) > L> - bridging code > L> that could benefit from a bit of partitioning > > I definitely agree that a) special interfaces b) lagg+lacp > c) generic libraries should be separated. I don't mind if anyone does > this job :) > > But I personally would prefer is this is done after the lifetime > of the projects/ifnet branch, since if stuff is moved while I work > on projects/ifnet, my merging will become a nightmare. I already have > conflicts quite often. > sure, there is no rush. I was just trying to understand why your preference is for sys/net/altq instead of sys/netaltq as we have for other components. thanks again luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
On Wed, Apr 15, 2015 at 02:53:34PM +0200, Luigi Rizzo wrote: L> > L> > With the new ifnet KPI, that is now being developed in projects/ifnet, L> > L> > the ALTQ will need some tweaking. It is discontinued by initial author L> > L> > for a decade now, and it has already experienced direct commits in L> > L> > our tree. Thus, I see no good reasons to continue keeping it in contrib. L> > L> > In NetBSD they have it in sys/altq. L> > L> > L> > L> > I'd prefer to move it to sys/net/altq. L> > L> > L> > L> > Any objections or better ideas? L> > L> L> > L> my first question is what is the expected residual lifetime of altq ? L> > L> > If I get it working properly in projects/ifnet, I see no reasons to L> > remove it. It is going to be a plugin into network stack and will no L> > longer require editing drivers. It will run on drivers that aren't L> > supported by ALTQ now. However in the latter case the ALTQ will sit L> > on top of interface own queue, and will start to work only when L> > interface's own queue overflows. But if we later add a new interface L> > method to modify length of own queue at runtime, this issue will L> > go away. L> > L> > L> If it is destined to be removed soon (and probably that is not L> > L> unlikely given its unmaintained state, the absence of multiqueue L> > L> support etc.) maybe we could live for the next L> > L> couple of years just leaving it where it is now and avoid the L> > L> repo churn. L> > L> L> > L> If we really plan to relocate the code, I guess the options are L> > L> L> > L> sys/altq as in netbsd L> > L> L> > L> sys/netaltq this would be an alternative location to L> > L> the above one, justified by the fact that L> > L> we have already a bunch of net* subdirs L> > L> L> > L> sys/net/altq as you propose, i guess to stay close to L> > L> the rest of the ifnet code (and perhaps L> > L> as a first step in cleaning up sys/net L> > L> by putting stuff in various subdirs) L> > L> L> > L> In any case my preference would really be to leave it where it is. L> > L> > I don't like to keep in contrib a code maintained and edited by the L> > project. Especially I don't like tautological path of contrib/altq/altq. L> > I don't like extra glue in Makefiles, especially modyfing CFLAGS for the L> > whole kernel build. L> > L> > If it is a regular piece of kernel code, let it be like the rest of L> > kernel code. L> L> ok thanks for the clarification. L> L> Then if you do sys/net/altq/ do you also plan to split the current L> content of sys/net/ into separate subdirectories ? L> L> We currently have quite a few separate things in sys/net/, such as L> - various bpf files L> - generic ifnet support (including raw sockets) L> - various libraries (compression and hash functions) L> - routing code L> - bridging code L> - a ton of special ifnets, (tun, tap, epair, gif, ) L> - bridging code L> that could benefit from a bit of partitioning I definitely agree that a) special interfaces b) lagg+lacp c) generic libraries should be separated. I don't mind if anyone does this job :) But I personally would prefer is this is done after the lifetime of the projects/ifnet branch, since if stuff is moved while I work on projects/ifnet, my merging will become a nightmare. I already have conflicts quite often. -- Totus tuus, Glebius. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
On Wed, Apr 15, 2015 at 2:26 PM, Gleb Smirnoff wrote: > On Wed, Apr 15, 2015 at 09:38:23AM +0200, Luigi Rizzo wrote: > L> > With the new ifnet KPI, that is now being developed in projects/ifnet, > L> > the ALTQ will need some tweaking. It is discontinued by initial author > L> > for a decade now, and it has already experienced direct commits in > L> > our tree. Thus, I see no good reasons to continue keeping it in contrib. > L> > In NetBSD they have it in sys/altq. > L> > > L> > I'd prefer to move it to sys/net/altq. > L> > > L> > Any objections or better ideas? > L> > L> my first question is what is the expected residual lifetime of altq ? > > If I get it working properly in projects/ifnet, I see no reasons to > remove it. It is going to be a plugin into network stack and will no > longer require editing drivers. It will run on drivers that aren't > supported by ALTQ now. However in the latter case the ALTQ will sit > on top of interface own queue, and will start to work only when > interface's own queue overflows. But if we later add a new interface > method to modify length of own queue at runtime, this issue will > go away. > > L> If it is destined to be removed soon (and probably that is not > L> unlikely given its unmaintained state, the absence of multiqueue > L> support etc.) maybe we could live for the next > L> couple of years just leaving it where it is now and avoid the > L> repo churn. > L> > L> If we really plan to relocate the code, I guess the options are > L> > L> sys/altq as in netbsd > L> > L> sys/netaltq this would be an alternative location to > L> the above one, justified by the fact that > L> we have already a bunch of net* subdirs > L> > L> sys/net/altq as you propose, i guess to stay close to > L> the rest of the ifnet code (and perhaps > L> as a first step in cleaning up sys/net > L> by putting stuff in various subdirs) > L> > L> In any case my preference would really be to leave it where it is. > > I don't like to keep in contrib a code maintained and edited by the > project. Especially I don't like tautological path of contrib/altq/altq. > I don't like extra glue in Makefiles, especially modyfing CFLAGS for the > whole kernel build. > > If it is a regular piece of kernel code, let it be like the rest of > kernel code. ok thanks for the clarification. Then if you do sys/net/altq/ do you also plan to split the current content of sys/net/ into separate subdirectories ? We currently have quite a few separate things in sys/net/, such as - various bpf files - generic ifnet support (including raw sockets) - various libraries (compression and hash functions) - routing code - bridging code - a ton of special ifnets, (tun, tap, epair, gif, ) - bridging code that could benefit from a bit of partitioning cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
On Wed, Apr 15, 2015 at 02:38:21PM +0200, Ermal Luçi wrote: E> > projects/ifnet, E> > L> > the ALTQ will need some tweaking. It is discontinued by initial author E> > L> > for a decade now, and it has already experienced direct commits in E> > L> > our tree. Thus, I see no good reasons to continue keeping it in E> > contrib. E> > L> > In NetBSD they have it in sys/altq. E> > L> > E> > L> > I'd prefer to move it to sys/net/altq. E> > L> > E> > L> > Any objections or better ideas? E> > L> E> > L> my first question is what is the expected residual lifetime of altq ? E> > E> > If I get it working properly in projects/ifnet, I see no reasons to E> > remove it. It is going to be a plugin into network stack and will no E> > longer require editing drivers. It will run on drivers that aren't E> > supported by ALTQ now. However in the latter case the ALTQ will sit E> > on top of interface own queue, and will start to work only when E> > interface's own queue overflows. But if we later add a new interface E> > method to modify length of own queue at runtime, this issue will E> > go away. E> > E> E> I would be interested on your approach on this as well. E> Also i can remind you that dragonflybsd has made some work on it to support E> multiqueue. E> IIRC they even mapped the queues directly the hardware queues so it might E> be interesting to look at their approach if it applies. The latter is definitely a better design. However, it requires much more work. My plan for now is just keep the ALTQ supported with removal of 'struct ifqueue' from 'struct ifnet' and at the same time provide a proof of concept code, that demonstrates that a shaping system can be a plugin shim in place of if_transmit method. Actually, I've been told that Yandex already had such a shaping system, so proof of concept already exists, but not open sourced. -- Totus tuus, Glebius. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
On Wed, Apr 15, 2015 at 2:26 PM, Gleb Smirnoff wrote: > On Wed, Apr 15, 2015 at 09:38:23AM +0200, Luigi Rizzo wrote: > L> > With the new ifnet KPI, that is now being developed in > projects/ifnet, > L> > the ALTQ will need some tweaking. It is discontinued by initial author > L> > for a decade now, and it has already experienced direct commits in > L> > our tree. Thus, I see no good reasons to continue keeping it in > contrib. > L> > In NetBSD they have it in sys/altq. > L> > > L> > I'd prefer to move it to sys/net/altq. > L> > > L> > Any objections or better ideas? > L> > L> my first question is what is the expected residual lifetime of altq ? > > If I get it working properly in projects/ifnet, I see no reasons to > remove it. It is going to be a plugin into network stack and will no > longer require editing drivers. It will run on drivers that aren't > supported by ALTQ now. However in the latter case the ALTQ will sit > on top of interface own queue, and will start to work only when > interface's own queue overflows. But if we later add a new interface > method to modify length of own queue at runtime, this issue will > go away. > I would be interested on your approach on this as well. Also i can remind you that dragonflybsd has made some work on it to support multiqueue. IIRC they even mapped the queues directly the hardware queues so it might be interesting to look at their approach if it applies. > > L> If it is destined to be removed soon (and probably that is not > L> unlikely given its unmaintained state, the absence of multiqueue > L> support etc.) maybe we could live for the next > L> couple of years just leaving it where it is now and avoid the > L> repo churn. > L> > L> If we really plan to relocate the code, I guess the options are > L> > L> sys/altq as in netbsd > L> > L> sys/netaltq this would be an alternative location to > L> the above one, justified by the fact that > L> we have already a bunch of net* subdirs > L> > L> sys/net/altq as you propose, i guess to stay close to > L> the rest of the ifnet code (and perhaps > L> as a first step in cleaning up sys/net > L> by putting stuff in various subdirs) > L> > L> In any case my preference would really be to leave it where it is. > > I don't like to keep in contrib a code maintained and edited by the > project. Especially I don't like tautological path of contrib/altq/altq. > I don't like extra glue in Makefiles, especially modyfing CFLAGS for the > whole kernel build. > > If it is a regular piece of kernel code, let it be like the rest of > kernel code. > > -- > Totus tuus, Glebius. > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > -- Ermal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
On Wed, Apr 15, 2015 at 09:38:23AM +0200, Luigi Rizzo wrote: L> > With the new ifnet KPI, that is now being developed in projects/ifnet, L> > the ALTQ will need some tweaking. It is discontinued by initial author L> > for a decade now, and it has already experienced direct commits in L> > our tree. Thus, I see no good reasons to continue keeping it in contrib. L> > In NetBSD they have it in sys/altq. L> > L> > I'd prefer to move it to sys/net/altq. L> > L> > Any objections or better ideas? L> L> my first question is what is the expected residual lifetime of altq ? If I get it working properly in projects/ifnet, I see no reasons to remove it. It is going to be a plugin into network stack and will no longer require editing drivers. It will run on drivers that aren't supported by ALTQ now. However in the latter case the ALTQ will sit on top of interface own queue, and will start to work only when interface's own queue overflows. But if we later add a new interface method to modify length of own queue at runtime, this issue will go away. L> If it is destined to be removed soon (and probably that is not L> unlikely given its unmaintained state, the absence of multiqueue L> support etc.) maybe we could live for the next L> couple of years just leaving it where it is now and avoid the L> repo churn. L> L> If we really plan to relocate the code, I guess the options are L> L> sys/altq as in netbsd L> L> sys/netaltq this would be an alternative location to L> the above one, justified by the fact that L> we have already a bunch of net* subdirs L> L> sys/net/altq as you propose, i guess to stay close to L> the rest of the ifnet code (and perhaps L> as a first step in cleaning up sys/net L> by putting stuff in various subdirs) L> L> In any case my preference would really be to leave it where it is. I don't like to keep in contrib a code maintained and edited by the project. Especially I don't like tautological path of contrib/altq/altq. I don't like extra glue in Makefiles, especially modyfing CFLAGS for the whole kernel build. If it is a regular piece of kernel code, let it be like the rest of kernel code. -- Totus tuus, Glebius. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
panic: SACK scoreboard must not be empty
Seen during i386 stress tests. db_trace_self_wrapper(c11e20fc,0,c11b79d4,1eb,e47578e0,...) at db_trace_self_wrapper+0x2a/frame 0xe47578b0 kdb_backtrace(c139e637,2,c120851d,e4757984,e4757940,...) at kdb_backtrace+0x2d/frame 0xe4757918 vpanic(c155b86a,100,c120851d,e4757984,e4757984,...) at vpanic+0x11d/frame 0xe4757954 kassert_panic(c120851d,0,8,164,16,...) at kassert_panic+0xe6/frame 0xe4757978 tcp_sack_doack(e047d900,e4757a48,e9eeab30,5f8,c15a9298,...) at tcp_sack_doack+0x405/frame 0xe47579f0 tcp_do_segment(df801720,e047d900,40,0,0,...) at tcp_do_segment+0x21c2/frame 0xe4757aa0 tcp_input(e4757bec,e4757be8,6,0,e4757be8,...) at tcp_input+0xfbc/frame 0xe4757ba0 ip_input(e1cb5800,0,c11f6228,2f0,45,...) at ip_input+0x17c/frame 0xe4757c0c swi_net(c1c25880,c11d6fed,54f,8f6da840,c8a209c8,...) at swi_net+0x1a3/frame 0xe4757c4c intr_event_execute_handlers(c156a310,c8a20980,c11d6fed,54f,0,...) at intr_event_execute_handlers+0xdb/frame 0xe4757c74 ithread_loop(c88d4f50,e4757ce8,c11d6d7c,3dc,0,...) at ithread_loop+0x87/frame 0xe4757cac fork_exit(c0b2c9d0,c88d4f50,e4757ce8) at fork_exit+0x7e/frame 0xe4757cd4 fork_trampoline() at fork_trampoline+0x8/frame 0xe4757cd4 Details: https://people.freebsd.org/~pho/stress/log/kostik794.txt -- Peter ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Network Interface name change
- Original Message - > From: "Sami Halabi" > To: "Raimund Sacherer" > Cc: freebsd-net@freebsd.org > Sent: Monday, April 13, 2015 10:08:22 PM > Subject: Re: Network Interface name change > Hi, > use: ifconfig em0 name em1 > note that if u have em2,3,.. u need to start in descending order 3,2,1... so > u wont have collissions. > Sami Hi Sami, thank you for your help, it worked like a charm, Best Ray ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
On Tue, Apr 14, 2015 at 04:53:46PM +0300, Gleb Smirnoff wrote: > Hi! > > With the new ifnet KPI, that is now being developed in projects/ifnet, > the ALTQ will need some tweaking. It is discontinued by initial author > for a decade now, and it has already experienced direct commits in > our tree. Thus, I see no good reasons to continue keeping it in contrib. > In NetBSD they have it in sys/altq. > > I'd prefer to move it to sys/net/altq. > > Any objections or better ideas? my first question is what is the expected residual lifetime of altq ? If it is destined to be removed soon (and probably that is not unlikely given its unmaintained state, the absence of multiqueue support etc.) maybe we could live for the next couple of years just leaving it where it is now and avoid the repo churn. If we really plan to relocate the code, I guess the options are sys/altqas in netbsd sys/netaltq this would be an alternative location to the above one, justified by the fact that we have already a bunch of net* subdirs sys/net/altqas you propose, i guess to stay close to the rest of the ifnet code (and perhaps as a first step in cleaning up sys/net by putting stuff in various subdirs) In any case my preference would really be to leave it where it is. cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: moving ALTQ out of contrib
On Tue, Apr 14, 2015 at 11:07:49PM +0300, Gleb Smirnoff wrote: > On Tue, Apr 14, 2015 at 04:53:46PM +0300, Gleb Smirnoff wrote: > T> Hi! > T> > T> With the new ifnet KPI, that is now being developed in projects/ifnet, > T> the ALTQ will need some tweaking. It is discontinued by initial author > T> for a decade now, and it has already experienced direct commits in > T> our tree. Thus, I see no good reasons to continue keeping it in contrib. > T> > T> In NetBSD they have it in sys/altq. > T> > T> I'd prefer to move it to sys/net/altq. > T> > T> Any objections or better ideas? > > Suggested diff. > > -- > Totus tuus, Glebius. > Index: ObsoleteFiles.inc > === > --- ObsoleteFiles.inc (revision 281525) > +++ ObsoleteFiles.inc (working copy) > @@ -38,6 +38,21 @@ > # xargs -n1 | sort | uniq -d; > # done > > +# 20150410: ALTQ moved to net/altq > +OLD_FILES+=usr/include/altq/altq_rmclass_debug.h > +OLD_FILES+=usr/include/altq/altq.h > +OLD_FILES+=usr/include/altq/altq_cdnr.h > +OLD_FILES+=usr/include/altq/altq_hfsc.h > +OLD_FILES+=usr/include/altq/altq_priq.h > +OLD_FILES+=usr/include/altq/altqconf.h > +OLD_FILES+=usr/include/altq/altq_classq.h > +OLD_FILES+=usr/include/altq/altq_red.h > +OLD_FILES+=usr/include/altq/if_altq.h > +OLD_FILES+=usr/include/altq/altq_var.h > +OLD_FILES+=usr/include/altq/altq_rmclass.h > +OLD_FILES+=usr/include/altq/altq_cbq.h > +OLD_FILES+=usr/include/altq/altq_rio.h > +OLD_DIRS+=usr/include/altq I wonder if changing location of installed header would break some ports. pgpl9qvmrMWql.pgp Description: PGP signature
