SCTP changes needed
Hi Michael,
As a followup to:
https://svnweb.freebsd.org/changeset/base/275358
Please find attached a separate SCTP patch as requested.
The attached patch re-enables flowids in the SCTP code as before. Until
this patch is committed the SCTP code will not take full advantage of
the multiple-transmit capabilities as found in many network adapters.
--HPS
Index: sys/netinet/sctp_indata.c
===
--- sys/netinet/sctp_indata.c (revision 275354)
+++ sys/netinet/sctp_indata.c (working copy)
@@ -2296,7 +2296,7 @@
struct sockaddr *src, struct sockaddr *dst,
struct sctphdr *sh, struct sctp_inpcb *inp,
struct sctp_tcb *stcb, struct sctp_nets *net, uint32_t * high_tsn,
-uint8_t use_mflowid, uint32_t mflowid,
+uint8_t mflowtype, uint32_t mflowid,
uint32_t vrf_id, uint16_t port)
{
struct sctp_data_chunk *ch, chunk_buf;
@@ -2391,7 +2391,7 @@
stcb->sctp_ep->last_abort_code = SCTP_FROM_SCTP_INDATA + SCTP_LOC_19;
sctp_abort_association(inp, stcb, m, iphlen,
src, dst, sh, op_err,
-use_mflowid, mflowid,
+mflowtype, mflowid,
vrf_id, port);
return (2);
}
@@ -2406,7 +2406,7 @@
stcb->sctp_ep->last_abort_code = SCTP_FROM_SCTP_INDATA + SCTP_LOC_19;
sctp_abort_association(inp, stcb, m, iphlen,
src, dst, sh, op_err,
-use_mflowid, mflowid,
+mflowtype, mflowid,
vrf_id, port);
return (2);
}
@@ -2475,7 +2475,7 @@
m, iphlen,
src, dst,
sh, op_err,
- use_mflowid, mflowid,
+ mflowtype, mflowid,
vrf_id, port);
return (2);
}
Index: sys/netinet/sctp_input.c
===
--- sys/netinet/sctp_input.c (revision 275354)
+++ sys/netinet/sctp_input.c (working copy)
@@ -86,7 +86,7 @@
struct sockaddr *src, struct sockaddr *dst, struct sctphdr *sh,
struct sctp_init_chunk *cp, struct sctp_inpcb *inp,
struct sctp_tcb *stcb, int *abort_no_unlock,
-uint8_t use_mflowid, uint32_t mflowid,
+uint8_t mflowtype, uint32_t mflowid,
uint32_t vrf_id, uint16_t port)
{
struct sctp_init *init;
@@ -101,7 +101,7 @@
if (ntohs(cp->ch.chunk_length) < sizeof(struct sctp_init_chunk)) {
op_err = sctp_generate_cause(SCTP_CAUSE_INVALID_PARAM, "");
sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
- use_mflowid, mflowid,
+ mflowtype, mflowid,
vrf_id, port);
if (stcb)
*abort_no_unlock = 1;
@@ -113,7 +113,7 @@
/* protocol error... send abort */
op_err = sctp_generate_cause(SCTP_CAUSE_INVALID_PARAM, "");
sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
- use_mflowid, mflowid,
+ mflowtype, mflowid,
vrf_id, port);
if (stcb)
*abort_no_unlock = 1;
@@ -123,7 +123,7 @@
/* invalid parameter... send abort */
op_err = sctp_generate_cause(SCTP_CAUSE_INVALID_PARAM, "");
sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
- use_mflowid, mflowid,
+ mflowtype, mflowid,
vrf_id, port);
if (stcb)
*abort_no_unlock = 1;
@@ -133,7 +133,7 @@
/* protocol error... send abort */
op_err = sctp_generate_cause(SCTP_CAUSE_INVALID_PARAM, "");
sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
- use_mflowid, mflowid,
+ mflowtype, mflowid,
vrf_id, port);
if (stcb)
*abort_no_unlock = 1;
@@ -143,7 +143,7 @@
/* protocol error... send abort */
op_err = sctp_generate_cause(SCTP_CAUSE_INVALID_PARAM, "");
sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
- use_mflowid, mflowid,
+ mflowtype, mflowid,
vrf_id, port);
if (stcb)
*abort_no_unlock = 1;
@@ -155,7 +155,7 @@
op_err = sctp_generate_cause(SCTP_BASE_SYSCTL(sctp_diag_info_code),
"Problem with AUTH parameters");
sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
- use_mflowid, mflowid,
+ mflowtype, mflowid,
vrf_id, port);
if (stcb)
*abort_no_unlock = 1;
@@ -186,7 +186,7 @@
op_err = sctp_generate_cause(SCTP_BASE_SYSCTL(sctp_diag_info_code),
"No listener");
sctp_send_abort(m, iphlen, src, dst, sh, 0, op_err,
- use_mflowid, mflowid,
+ mflowtype, mflowid,
vrf_id, port);
}
goto outnow;
@@ -200,7 +200,7 @@
SCTPDBG(SCTP_DEBUG_INPUT3, "sctp_handle_init: sending INIT-ACK\n");
sctp_send_initiate_ack(inp, stcb, m, iphlen, offset, src, dst,
sh, cp,
- use_mflowid, mflowid,
+ mflowtype, mflowid,
vrf_id, port,
((stcb == NULL) ? SCTP_HOLDS_LOCK : SCTP_NOT_LOCKED));
}
@@ -434,7 +434,7 @@
struct sockaddr *src, struct sockaddr *dst, struct sctphdr *sh,
struct sctp_init_ack_chunk *cp, struct sctp_tcb *stcb,
struct sctp_nets *net, int *abort_no_unlock,
-uint8_t use_mflowid, uint32_t mflowid,
+uint8_t mflowtype, uint32_t mflowid,
uint32_t
Re: SCTP changes needed
On 01 Dec 2014, at 12:47, Hans Petter Selasky wrote: > Hi Michael, > > As a followup to: > https://svnweb.freebsd.org/changeset/base/275358 > > Please find attached a separate SCTP patch as requested. > > The attached patch re-enables flowids in the SCTP code as before. Until this > patch is committed the SCTP code will not take full advantage of the > multiple-transmit capabilities as found in many network adapters. OK. Thanks. I'll commit them ASAP. Still need to integrate some other changes upstream to get them synced. I'll ping you once the stuff is committed. Best regards Michael > > --HPS > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCTP changes needed
Hi, We also need to figure out what we can do with SCTP and flowid. The way SCTP is using the mbuf field in said mbufs is going to collide with hardware and RSS flowids. :( -adrian On 1 December 2014 at 04:20, Michael Tuexen wrote: > On 01 Dec 2014, at 12:47, Hans Petter Selasky wrote: > >> Hi Michael, >> >> As a followup to: >> https://svnweb.freebsd.org/changeset/base/275358 >> >> Please find attached a separate SCTP patch as requested. >> >> The attached patch re-enables flowids in the SCTP code as before. Until this >> patch is committed the SCTP code will not take full advantage of the >> multiple-transmit capabilities as found in many network adapters. > OK. Thanks. I'll commit them ASAP. Still need to integrate some other changes > upstream > to get them synced. I'll ping you once the stuff is committed. > > Best regards > Michael >> >> --HPS >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On 30 Nov 2014, at 19:57, Dmitry Marakasov wrote: > > * Dimitry Andric (d...@freebsd.org) wrote: > >> We're working on updating llvm, clang and lldb to 3.5.0 in head. >> This is quite a big update again, and any help with testing is >> appreciated. > > Well, of 4 error logs from exp-run I've checked (one my port and 3 > unmaintained ports) two had basically the same problem and it seems > to be libc++ related, so I ask: was new version of libc++ imported > along with clang/llvm? No, I really prefer to do this after the 3.5.0 import. This is already a very big import job, and I'd rather like to avoid importing too many different components at once. > Past experience show that libc++ should be > updated along with clang, as it may have bugs new clang versions > are not tolerable to. In this case, there is a fairly simple fix: http://llvm.org/viewvc/llvm-project?view=revision&revision=209785 I have pulled this into head in r275366, and also merged it to the clang350-import project branch in r275367. Please try again after that revision. It should be enough to just rebuild lib/libc++ and install it. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: witness and modules.
On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote: > Do we need to compile all modules with witness definitions when > linking with a kernel compiled with witness? > This was true at one stage but I remember some work was done to make > them compatible. You should not need this. modules always call functions in the kernel for lock operations and this functions are what invoke WITNESS. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFT: Please help testing the llvm/clang 3.5.0 import
* Dimitry Andric (d...@freebsd.org) wrote: > >> We're working on updating llvm, clang and lldb to 3.5.0 in head. > >> This is quite a big update again, and any help with testing is > >> appreciated. > > > > Well, of 4 error logs from exp-run I've checked (one my port and 3 > > unmaintained ports) two had basically the same problem and it seems > > to be libc++ related, so I ask: was new version of libc++ imported > > along with clang/llvm? > > No, I really prefer to do this after the 3.5.0 import. This is already > a very big import job, and I'd rather like to avoid importing too many > different components at once. > > > > Past experience show that libc++ should be > > updated along with clang, as it may have bugs new clang versions > > are not tolerable to. > > In this case, there is a fairly simple fix: > http://llvm.org/viewvc/llvm-project?view=revision&revision=209785 > > I have pulled this into head in r275366, and also merged it to the > clang350-import project branch in r275367. Please try again after that > revision. It should be enough to just rebuild lib/libc++ and install > it. Sorry, I haven't tested the branch myself, only seen exp-run results. Would be nice to have another exp-run. Btw, is it possible to merge the patch into stable/10 as well? It will make it possible to use clang35 there. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: External toolchain support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 29.11.2014 18:04, Baptiste Daroussin wrote: > mips cannot be tested because upstream gcc never heard of FreeBSD > running on mips, and I did not receive any patches for mips. I'm afraid, arm has same problem. I was need to patch arm-for-uC toolchain to be able built it on ARM host, and this fix is very cross-specific. As far as I know, gcc for freebsd-arm target needs patches too, but different ones. At least to configure scripts & gcc host-drivers. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUfKyGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP8ZsP/jIWqU+9ACCR4/Rdf5A7SaGc msCsofot9YrClKNJWPdjL0V2jMtKAURJVFf3OpRi6jXY9HJKzjIjHAoXDfwr97qP 9VyLgfvtNn+ffNuFuwUalwkiFcyzqvsADTHxFqFmCnhAAnjnHzn0CzushzKSRKYN 9yEhQphipCZ1DuP1cTE8z9/BOPAfXNjgjavfAYpnJARm+XZzPn2XG83rFnlLcZFo UcByyuZznxfImH6hxoNsRVkdj5yvuGmzxQJQf+ilipiI3pDZk5/Q+ZWzWGap/gC/ 0k2zWqyKO2O5pSNb8i8vsW2J+zg++BmMnO0VAt3pjxd4dqbrV5qk/g4oXiuxB2uX 8YnvbDJuLKzvI31GCrjOOa462yZlmoCBHRoqjUBZxeHh5QQSJyZjDc0ClRGbdfi/ FNLTx/jPhouxh1vEC1nV44FGS2v5Go9urKa1OhWYRrf+NyNlt7Ao5VutujgfQlvF sLo663/Ja9W2MzLHmPanHMJcPl/Y7v9S7Mwh/EPCIe8Fd8VeYUPhOlT349Z7FnhT e7Nu4zcnY82PJ4fU/yREHxZWsEwtRxx5vr1YrLClt8R7nx8ZXzq8A9JBLjqt/RfK 4BOe0D1t8zMARroiw9RaYFm8Md8nybWp+Q++ouME51jWWPgDxV9BbKaIx6Y4r+6V RO63nTfg3A8uT/D60bIA =aiOJ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On 01 Dec 2014, at 18:54, Dmitry Marakasov wrote: > > * Dimitry Andric (d...@freebsd.org) wrote: > We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. >>> >>> Well, of 4 error logs from exp-run I've checked (one my port and 3 >>> unmaintained ports) two had basically the same problem and it seems >>> to be libc++ related, so I ask: was new version of libc++ imported >>> along with clang/llvm? >> >> No, I really prefer to do this after the 3.5.0 import. This is already >> a very big import job, and I'd rather like to avoid importing too many >> different components at once. >> >> >>> Past experience show that libc++ should be >>> updated along with clang, as it may have bugs new clang versions >>> are not tolerable to. >> >> In this case, there is a fairly simple fix: >> http://llvm.org/viewvc/llvm-project?view=revision&revision=209785 >> >> I have pulled this into head in r275366, and also merged it to the >> clang350-import project branch in r275367. Please try again after that >> revision. It should be enough to just rebuild lib/libc++ and install >> it. > > Sorry, I haven't tested the branch myself, only seen exp-run results. > Would be nice to have another exp-run. Yes, but we first need to fix another issue, which is more important: several of the lang/gcc ports don't work properly, e.g. bootstrap stage comparison fails. There is also something fishy going on with gcc in base, which may or may not be related: building the devel/binutils ports with it causes cc1plus to segfault while compiling gold's archive.cc. I am still searching for the root cause; any help in this area would be greatly appreciated, as the maintainer has not responded yet. > Btw, is it possible to merge the patch into stable/10 as well? > It will make it possible to use clang35 there. Yes, this is also why I prefer to cherry-pick; I have set an MFC timeout of 3 days. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
$DISPLAY not set
I have installed freeBSD & have it running. I was trying to install MATE & KDE4, but I'm getting an error. everytime I try to run exec startkde it logs me out with this message: $DISPLAY is not set or cannot connect to xserver echo $DISPLAY says DISPLAY: undefined variable I was using this guide to set everything up: https://cooltrainer.org/a-freebsd-desktop-howto/#with-radeon-intel-or-otherwise am I missing something? I do have an /etc/X11/xorg.conf, I did do the X -configure. -- Paul Cartwright Registered Linux User #367800 and new counter #561587 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: $DISPLAY not set
[Replies redirected to a more appropriate list.] Paul Cartwright writes: > I have installed freeBSD & have it running. I was trying to install MATE > & KDE4, but I'm getting an error. > everytime I try to run exec startkde it logs me out with this message: > > $DISPLAY is not set or cannot connect to xserver > > > echo $DISPLAY says > DISPLAY: undefined variable > > I was using this guide to set everything up: > https://cooltrainer.org/a-freebsd-desktop-howto/#with-radeon-intel-or-otherwise > > am I missing something? Well, you're missing the FreeBSD documentation, which is a lot better than a random Google result. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11.html Or you might want to try PCBSD (www.pcbsd.org) which will require a lot less understanding of what is going on (at the cost, as usual, of giving you a lot less choice, at least initially). The "exec startkde" is supposed to go in your .xinitrc file, in which case you would start X with the "startx" command. > I do have an /etc/X11/xorg.conf, I did do the X -configure. Usually unnecessary, and not a great idea unless it is necessary. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: $DISPLAY not set
On 12/01/2014 01:41 PM, Lowell Gilbert wrote: >> > am I missing something? > Well, you're missing the FreeBSD documentation, which is a lot better > than a random Google result. > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11.html right, I should have followed that first.. > > Or you might want to try PCBSD (www.pcbsd.org) which will require a lot > less understanding of what is going on (at the cost, as usual, of giving > you a lot less choice, at least initially). no,no, I've used UNIX in the past, but it has been linux for the last 10 years.. just a little rusty.. > > The "exec startkde" is supposed to go in your .xinitrc file, in which > case you would start X with the "startx" command. right, I understand the .xinitrc, but I wanted it to work first.. > >> > I do have an /etc/X11/xorg.conf, I did do the X -configure. > Usually unnecessary, and not a great idea unless it is necessary. > > ok, I'll check out the freebsd pages, and I'll let you know. thanks! -- Paul Cartwright Registered Linux User #367800 and new counter #561587 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: witness and modules.
On 12/1/14, 11:39 PM, John Baldwin wrote: On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote: Do we need to compile all modules with witness definitions when linking with a kernel compiled with witness? This was true at one stage but I remember some work was done to make them compatible. You should not need this. modules always call functions in the kernel for lock operations and this functions are what invoke WITNESS. that's what I thought but empirical evidence disagrees. I'll try some more cases. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: External toolchain support
> On Nov 29, 2014, at 8:04 AM, Baptiste Daroussin wrote: > > Hi all, > > It is now possible to use an external toolchain to build the kernel and base > (tested with gcc 4.9.1 and latest binutils) > > Of course a lot of work is needed to make it build cleanly (aka lots of > warning > to fix). > > What have been tested so far: > - sparc64 kernel + world > - amd64 kernel + world > - powerpc64 kernel + world > > mips cannot be tested because upstream gcc never heard of FreeBSD running on > mips, and I did not receive any patches for mips. I have patches for 4.8 or so knocking around somewhere... > for amd64, in the kernel two things had to be removed from the build: > - aesni: (it request a header which is compiler specific and on recent gcc > will end up including stdlib.h which gives errors because kernel version of > free > and malloc are not compatible with the version defined in stdlib.h) > - hptmv: I had to remove it from GENERIC and kernel building. > > The result is: > > $ sysctl kern.ostype kern.osrelease kern.osrevision kern.compiler_version > > kern.ostype: FreeBSD > kern.osrelease: 11.0-CURRENT > kern.osrevision: 199506 > kern.compiler_version: gcc version 4.9.1 (FreeBSD Ports Collection for amd64) > > so yes it boots and runs > > How to do you own testing: > in the ports tree/packages (the amd64 version will appear in packages next > week) > install: > amd64-xtoolchain-gcc or powerpc64-xtoolchain-gcc or sparc64-xtoolchain-gcc > > if your source tree: > make CROSS_TOOLCHAIN=amd64-gcc -j8 buildkernel > or > make CROSS_TOOLCHAIN=powerpc64-gcc -j8 buildkernel > or > make CROSS_TOOLCHAIN=sparc64-gcc -j8 buildkernel > > To build world: > same operation with buildworld. Please note that for world you will need to > add > define NO_WERROR (world will also require a change in share/mk/bsd.lib.mk: > s/--fatal-warnings/--no-fatal-warnings/) > > also notes that for the kernel a lots of warnings are disabled in > share/sys/kern.mk so do not hesitate to remove yourself those -Wno-error= and > fix the issue they are hidding! Cool. Please coordinate with me before removing the -Wno-error because they vary by architecture. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
compiling failed with RSS enabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 current failed to compile due to queues uninitialized at line 2883 in if_igb.c. from the context I guess it should be n_queues instead of queues. Index: sys/dev/e1000/if_igb.c === - --- sys/dev/e1000/if_igb.c(revision 275391) +++ sys/dev/e1000/if_igb.c (working copy) @@ -2880,7 +2880,7 @@ #ifdef RSS /* If we're doing RSS, clamp at the number of RSS buckets */ - - if (queues > rss_getnumbuckets()) + if (n_queues > rss_getnumbuckets()) queues = rss_getnumbuckets(); #endif Eric -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlR9WmoACgkQSfBQu3oOwYxnrQD6Ah1uhoNaM3YTXHdOpOA7hw4j vZUCA9VU6n/jhUEneVkBALETmBfQudmEz9/eqnmsmer8RbulQdqIKTa8InSvE2yw =jLcf -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
