Re: RCTL and VIMAGE for 11.0-RELEASE
> On 23 Jan 2016, at 06:41 , Ernie Luzar wrote: > > Bjoern A. Zeeb wrote: >>> On 24 Aug 2015, at 19:08 , Mark Felder wrote: >>> >>> What is preventing RCTL from being enabled right now? Any known/serious >>> blockers? >> It’s enabled in GENERIC. >>> And the same for VIMAGE? I know there were issues with some firewalls, >>> but I'm not sure where that stands today. Does it degrade network >>> performance in a measurable way? >> Ignoring performance for a second, there is more than just firewalls that >> needs to be done. I started writing a plan for the next 4 months > yesterday. Most of this was done a few years ago and never made it to HEAD. > It needs to be re-validated. If my plan comes together we’ll have another 4 > month window before the 11 release cycle will start. >> /bz > > It's been 5 months since the above was posted. What is the status of VIMAGE > as part of base in 11.0-RELEASE? There is ongoing work; it was slightly delayed to the original plan. Hope it all hits HEAD before early/mid March. Expect more patches soon. /bz ___ 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: Too low PTHREAD_STACK_MIN value?
For what it's worth, I agree with David. This looks like definite misuse of the constant. If app X requires min size of stack of Y, it's fullish of it if to expect our PTHREAD_STACK_MIN somehow accommodate that. It should be really using MAX(PTHREAD_STACK_MIN, Y) to set its stack instead. Should be easy to patch and it needs to be reported to the upstream vendor(s) instead. Don't forget that bumping this limit, no matter how small, will get multiplied by the number of threads running, which could be in many thousands. On Fri, Jan 22, 2016 at 4:09 AM, David Chisnall wrote: > On 21 Jan 2016, at 16:02, Ed Maste wrote: > > > > I found that lang/polyml uses PTHREAD_STACK_MIN for a trivial signal > > handler thread it creates[1]. They found it was too small and > > implemented a 4K minimum bound to fix polyml on FreeBSD[2]. Even if > > this isn't really the intended use of PTHREAD_STACK_MIN it suggests > > the 2K x86 minimum may indeed be too low. > > > > I ran into this while trying LLVM's libunwind, which requires more > > stack space. 2K is certainly too low with LLVM libunwind. Is it > > reasonable to just increase it to say 8K? > > I don’t really like this solution. PTHREAD_STACK_MIN is the size for a > stack that does not do anything. You should never use it without adding > the amount that you are going to need (which might be nothing if you are > running code from a language that does not use a conventional C-style > stack, but still wants to use OS threads). Making it larger because a > specific kind of thing that some consumers want to do with it needs more > space is definitely against the spirit of the value and potentially harmful > as it means that people using it correctly will be using a lot more memory > per thread. > > David > > ___ > 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" > -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sa...@sippysoft.com Skype: SippySoft ___ 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_gcc4.9 - Build #1038 - Fixed
FreeBSD_HEAD_amd64_gcc4.9 - Build #1038 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1038/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1038/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1038/console Change summaries: 294621 by dchagin: Remove obsolete comment. MFC after: 3 days 294620 by dchagin: Fix a typo. MFC after: 3 days 294617 by adrian: Now that the flashmap code knows about SPI flash, add it in builds. PR: kern/206227 Submitted by: Stanislav Galabov 294616 by adrian: Teach the flashmap code about the SPI flash. PR: kern/206227 Submitted by: Stanislav Galabov 294615 by araujo: Add an IOCTL rr_limit to let users fine tuning the number of packets to be sent using roundrobin protocol and set a better granularity and distribution among the interfaces. Tuning the number of packages sent by interface can increase throughput and reduce unordered packets as well as reduce SACK. Example of usage: # ifconfig bge0 up # ifconfig bge1 up # ifconfig lagg0 create # ifconfig lagg0 laggproto roundrobin laggport bge0 laggport bge1 \ 192.168.1.1 netmask 255.255.255.0 # ifconfig lagg0 rr_limit 500 Reviewed by:thompsa, glebius, adrian (old patch) Approved by:bapt (mentor) Relnotes: Yes Differential Revision: https://reviews.freebsd.org/D540 294613 by fanf: Fix a regression in the .de and .dk whois special cases Ensure the special cases trigger whether we come via a referral or via the -c option. Match host names case-insensitively. Use the default character set supported by .de (UTF-8) since that is more compatible with the modern world than ISO 8859-1. Persuade them to give us a useful answer whether an internationalized domain name is given in UTF-8 or in punycode. 294611 by fanf: A lot of the cleverness in whois is no longer needed! The IANA whois server has the right referral information for domain names, IP addresses, and AS numbers, so whois does not need to be able to choose servers itself (except for a few cases where referrals do not work). We can delete a chunk of code, which is always fun. This change improves the referral handling to be less sensitive to all the various formats, and to allow multi-hop referral chains, such as IANA -> registry -> registrar. ARIN queries have the "+" flag added if no flags are present, so we get full details if the query matches multiple objects. The Verisign anti-spam logic is also now suppressed if the user provided a non- trivial query string. Uninformative rubric is now trimmed by default. The -S option turns off trimming, and disables query fettling. The -i option is back to its traditional pre-1999 hostname, since whois.internic.net is more useful than whois.networksolutions.com. Note that the old fallback/default server whois.crsnic.net is an alias for whois.internic.net. The manual is more informative about query syntax. 294610 by np: Fix for iWARP servers that listen on INADDR_ANY. The iWARP Connection Manager (CM) on FreeBSD creates a TCP socket to represent an iWARP endpoint when the connection is over TCP. For servers the current approach is to invoke create_listen callback for each iWARP RNIC registered with the CM. This doesn't work too well for INADDR_ANY because a listen on any TCP socket already notifies all hardware TOEs/RNICs of the new listener. This patch fixes the server side of things for FreeBSD. We've tried to keep all these modifications in the iWARP/TCP specific parts of the OFED infrastructure as much as possible. Submitted by: Krishnamraju Eraparaju @ Chelsio (with design inputs from Steve Wise) Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D4801 294608 by emaste: Use MAN= to specify that no man page is provided NO_MAN is deprecated. Reviewed by:imp 294600 by avos: tools/tools/ath/ath_ee_v4k_print: reflect changes from r220589 Fix printf() arguments + sort includes Approved by:adrian (mentor) Differential Revision: https://reviews.freebsd.org/D4045 294598 by kib: In tty_dealloc(), clear the queues. See the comment for a scenario which explains why ttydev_leave() cleanup might not happen. Submitted by: bde MFC after: 3 weeks 294597 by wblock: Add a standards compliance note for strtok_r as suggested by cpercival. Reviewed by:cpercival MFC after: 1 week 294596 by kib: The struct file f_advice member is overlaid with the devfs f_cdevpriv data. If vnode bypass for devfs file failed, vn_read/vn_write are called and might try to dereference f_advice. Limit the accesses to f_advice to VREG vnodes only, which is the type ensured by posix_fadvise(). The f_advice for regular files is protected by mtxpool lock. Recheck that f_advice is not NULL after lock is taken. Reported and tested by: bde Sponsored by: The FreeBSD Foundation MFC after: 3 weeks 294595 by kib: When
Re: Too low PTHREAD_STACK_MIN value?
On 23 Jan 2016, at 08:58, Maxim Sobolev wrote: > > For what it's worth, I agree with David. This looks like definite misuse of > the constant. If app X requires min size of stack of Y, it's fullish of it if > to expect our PTHREAD_STACK_MIN somehow accommodate that. It should be really > using MAX(PTHREAD_STACK_MIN, Y) to set its stack instead. Should be easy to > patch and it needs to be reported to the upstream vendor(s) instead. Don't > forget that bumping this limit, no matter how small, will get multiplied by > the number of threads running, which could be in many thousands After talking to Ed, I’m not sure I was correct in my initial assessment. The code in pthread’s thread exit routine is calling the unwinder, and that’s what’s exhausting the stack space. This means that a thread function that just does return 0 will run out of stack space. That said, existing values of PTHREAD_STACK_MIN are part of the ABI and if we’re going to bump it then we need to make sure that we do something clever with existing binaries to ensure that, when they ask for 2KB of stack, we give them more (which can be problematic if they’re allocating their own stack). I’d much prefer a solution where we don’t expose the HP unwind interfaces from libeh (it’s fine to do so from a separate libunwind) and we don’t allocate that much space in the unwinder. David ___ 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: libcrypto.so.7 not found, needed (?) for X server
> > root@amelia:~ # pkg info -f xserver > > Shared object "libssl.so.7" not found, required by "pkg" > > What happened here? Bug in new FreeBSD? > This is explained by the UPDATING entry of October 2015: > 20151030: > The OpenSSL has been upgraded to 1.0.2d. Any binaries requiring > libcrypto.so.7 or libssl.so.7 must be recompiled. > -Dimitry I found this but not on the first attempt. Why the #$%^&* couldn't the message have said how to find which binaries require a certain shared library? It's not obvious! pkg shows only those shared libraries that come from added packages but not from base OS. I notice on this list there was a possible plan to make the whole base OS into a package, maybe for FreeBSD 12? Now I could follow the example given under "man ldd". I have updated many of the old ports but have many more to go, don't want to rebuild those already done. I can't find any options/flags in pkg or portmaster to show those ports/packages installed after or before a specified date. I believe portupgrade had such a facility. Tom ___ 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: HPN and None options in OpenSSH
Julian Elischer writes: > what is the internal window size in the new ssh? 64 kB. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: HPN and None options in OpenSSH
On Sat, Jan 23, 2016 at 7:55 AM, Dag-Erling Smørgrav wrote: > Julian Elischer writes: > > what is the internal window size in the new ssh? > > 64 kB. > > DES > -- > Dag-Erling Smørgrav - d...@des.no Are you sure of this? I have not looked at the code, but my former colleagues at the high performance research network ESnet claim at http://fasterdata.es.net/data-transfer-tools/say-no-to-scp/ that the internal buffers and effective window size have recently been increased from 64KB to 1MB an allow for transfer rates of up to 140 Mbps over a link with 53 ms. latency. With the HPN patches, they report 1.2 Gbps, making HPN patches still significant over high latency paths. That said, scp still performed poorly when compared to other technologies (i.e. GridFTP) for bulk data transfer over high-latency high-bandwidth links. (ESnet provides links of up to 400 Gbps between the US and Europe as well as within the US, so this sort of thing is quite important to them.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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"
[Bug 194744] [PATCH] allow to specify custom keymap when kbdmux used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 Oliver Pinter changed: What|Removed |Added Flags||mfc-stable10? -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: HPN and None options in OpenSSH
Kevin Oberman writes: > Dag-Erling Smørgrav writes: > > Julian Elischer writes: > > > what is the internal window size in the new ssh? > > 64 kB. > Are you sure of this? Sorry, I was thinking of 6.6 (in stable/10). The buffer code in 7.1 supports dynamically-sized buffers with a hard limit of 128 MB. The default window size for client sessions is 2 MB, or 1 MB if associated with a tty. I'm not sure what the maximum size is. Note that scp, sftp etc. count as client sessions. X11 and agent forwarding use different (smaller) windows which improve latency at the cost of throughput. > [...] scp still performed poorly when compared to other technologies scp is a horrible protocol, use sftp or (preferably) rsync over ssh. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: HPN and None options in OpenSSH
On 01/23/16 09:15, Kevin Oberman wrote: > Are you sure of this? I have not looked at the code, but my former > colleagues at the high performance research network ESnet claim at > http://fasterdata.es.net/data-transfer-tools/say-no-to-scp/ that the > internal buffers and effective window size have recently been increased > from 64KB to 1MB an allow for transfer rates of up to 140 Mbps over a link > with 53 ms. latency. With the HPN patches, they report 1.2 Gbps, making HPN > patches still significant over high latency paths. DES wrote: > The buffer code in 7.1 > supports dynamically-sized buffers with a hard limit of 128 MB. The > default window size for client sessions is 2 MB, or 1 MB if associated > with a tty. I'm not sure what the maximum size is. I'll try to do some cross-country or trans-Atlantic testing this weekend or next week, using a mix of ssh versions and HPN-patched versus not (and CentOS vs. FreeBSD vs. possibly Debian unstable with the 4.2+ kernel as yet another degree of freedom). I'll see what basic results I can get and we can update fasterdata.es.net as necessary. > That said, scp still performed poorly when compared to other technologies > (i.e. GridFTP) for bulk data transfer over high-latency high-bandwidth > links. (ESnet provides links of up to 400 Gbps between the US and Europe as > well as within the US, so this sort of thing is quite important to them.) That it is! > scp is a horrible protocol, use sftp or (preferably) rsync over ssh. I still think over ssh transport is lousy for bulk-data transfers, but it is the one thing that's generally installed by default on every OS and and is allowed by many firewalls. And, of course, it encrypts in flight. Certainly gridFTP, aspera (if you can afford it!) and other packages optimized for bulk data transfer will work better. michael ESnet ___ 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_i386 - Build #2184 - Failure
FreeBSD_HEAD_i386 - Build #2184 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2184/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2184/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2184/console Change summaries: 294654 by pfg: Fix comment. 294653 by pfg: Rename some directory index constants. Directory index was introduced in ext3. We don't always use the prefix to denote the ext2 variant they belong to but when we do we should try to be accurate. 294652 by pfg: ext2: Initialize i_flag after allocation. We use i_flag to carry some flags like IN_E4INDEX which newer ext2fs variants uses internally. fsck.ext3 rightfully complains after our implementation tags non-directory inodes with INDEX_FL. Initializing i_flag during allocation removes the noise factor and quiets down fsck. Patch from: Damjan Jovanovic PR: 206530 The end of the build log: [...truncated 188553 lines...] --- modules-all --- --- all_subdir_ex --- ctfconvert -L VERSION -g if_ex_pccard.o --- if_ex.kld --- ld -d -warn-common -r -d -o if_ex.kld if_ex.o if_ex_isa.o if_ex_pccard.o ctfmerge -L VERSION -g -o if_ex.kld if_ex.o if_ex_isa.o if_ex_pccard.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_ex.kld export_syms | xargs -J% objcopy % if_ex.kld --- if_ex.ko.full --- ld -Bshareable -d -warn-common -o if_ex.ko.full if_ex.kld --- if_ex.ko.debug --- objcopy --only-keep-debug if_ex.ko.full if_ex.ko.debug --- if_ex.ko --- objcopy --strip-debug --add-gnu-debuglink=if_ex.ko.debug if_ex.ko.full if_ex.ko --- all_subdir_em --- --- e1000_mbx.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/em/../../dev/e1000 -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/em/../../dev/e1000/e1000_mbx.c -o e1000_mbx.o --- e1000_vf.o --- ctfconvert -L VERSION -g e1000_vf.o --- all_subdir_drm2 --- --- radeon_gem.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -I/usr/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon -c /usr/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/radeon_gem.c -o radeon_gem.o --- hwregs.o --- ctfconvert -L VERSION -g hwregs.o --- modules-all --- --- radeon_irq_kms.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -I/usr/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon -c /usr/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/radeon_irq_kms.c -o radeon_irq_kms.o --- radeon_gart.o --- ctfconvert -L VERSION -g radeon_gart.o --- all_subdir_em --- --- e1000_mbx.o --- ctfconvert -L VERSION -g e1000_mbx.o --- e1000_i210.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/em/../../dev/e1000 -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/s
FreeBSD_HEAD_i386 - Build #2185 - Fixed
FreeBSD_HEAD_i386 - Build #2185 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2185/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2185/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2185/console Change summaries: 294655 by pfg: ext2: rename some directory index constants. Missed from r294653. Pointyhat: me ___ 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"
