IPSEC stop works after r285336
Hello, I'm having the same problem with IPSec, running -current with r285794. Don't know if this helps, but "netstat -s -p esp" shows packets dropped; bad ilen. ___ 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_HEAD-tests - Build #1226 - Unstable
/unix_seqpacket_test:sendrecv_128k_nonblocking -> passed [0.301s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_16k -> passed [0.434s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_16k_nonblocking -> passed [0.482s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_32k -> passed [0.306s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_32k_nonblocking -> passed [0.162s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_64k -> passed [0.551s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_64k_nonblocking -> passed [0.366s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_8k -> passed [0.320s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_8k_nonblocking -> passed [0.457s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendto_recvfrom -> passed [0.745s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send -> failed: 2 checks failed; see output for more details [0.371s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send_sigpipe -> failed: 2 checks failed; see output for more details [0.553s] [192.168.10.2] out: sys/kern/execve/execve_test:bad_interp_len -> passed [0.846s] [192.168.10.2] out: sys/kern/execve/execve_test:empty -> passed [0.343s] [192.168.10.2] out: sys/kern/execve/execve_test:good_aout -> passed [0.798s] [192.168.10.2] out: sys/kern/execve/execve_test:good_script -> passed [0.272s] [192.168.10.2] out: sys/kern/execve/execve_test:non_exist -> passed [0.361s] [192.168.10.2] out: sys/kern/execve/execve_test:non_exist_shell -> passed [0.557s] [192.168.10.2] out: sys/kern/execve/execve_test:script_arg -> passed [0.361s] [192.168.10.2] out: sys/kern/execve/execve_test:script_arg_nospace -> passed [0.188s] [192.168.10.2] out: sys/kern/execve/execve_test:sparse_aout -> passed [0.387s] [192.168.10.2] out: sys/kern/execve/execve_test:trunc_aout -> passed [0.224s] [192.168.10.2] out: sys/kqueue/kqueue_test:main -> passed [11.706s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest1 -> passed [0.780s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest2 -> passed [0.519s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest3 -> passed [0.924s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest4 -> passed [0.622s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest5 -> passed [0.449s] [192.168.10.2] out: sys/netinet/fibs_test:arpresolve_checks_interface_fib -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:default_route_with_multiple_fibs_on_same_subnet -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:loopback_and_network_routes_on_nondefault_fib -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:same_ip_multiple_ifaces -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:same_ip_multiple_ifaces_fib0 -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:subnet_route_with_multiple_fibs_on_same_subnet -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:udp_dontroute -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/opencrypto/runtests:main -> passed [0.420s] [192.168.10.2] out: sys/vm/mmap_test:main -> passed [0.312s] [192.168.10.2] out: [192.168.10.2] out: Results file id is usr_tests.20150727-193158-909842 [192.168.10.2] out: Results saved to /root/.kyua/store/results.usr_tests.20150727-193158-909842.db [192.168.10.2] out: [192.168.10.2] out: 4335/4337 passed (2 failed) [192.168.10.2] out: Warning: run() received nonzero return code 1 while executing 'kyua test'! [192.168.10.2] run: kyua report --verbose --results-filter passed,skipped,xfail,broken,failed --output test-report.txt [192.168.10.2] run: kyua report-junit --output=test-report.xml [192.168.10.2] run: shutdown -p now [192.168.10.2] out: Shutdown NOW! [192.168.10.2] out: shutdown: [pid 68219] [192.168.10.2] out: 00 broadcast 192.168.10.255 kyuatestprompt # lock order reversal: 1st 0xfe007b2cc490 bufwait (bufwait) @ /builds/FreeBSD_HEAD/sys/kern/vfs_bio.c:3121 2nd 0xf800077e7a00 dirhash (dirhash) @ /builds/FreeBSD_HEAD/sys/ufs/ufs/ufs_dirhash.c:281 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0096fab400 witness_checkorder() at witness_checkorder+0xe7a/frame 0xfe0096fab480 _sx_xlock() at _sx_xlock+0x75/frame 0xfe0096fab4c0 ufsdirhash_ad
Re: duration of buildworld
On Mon, Jul 27, 2015 at 09:40:39PM +0200, Matthias Apitz wrote: > El d'ia Monday, July 27, 2015 a las 10:34:10PM +0300, Slawa Olhovchenkov > escribi'o: > > > > This pointed in the right direction. I have had 6x 1 GByte additional > > > swap partitions to plain files mounted (because I needed this to get > > > the eclipse port compiled within poudriere). After changing the fstab and > > > reboot, the 'make buildkernel' takes only half an hour. > > > > > > Why is this? > > > > swap to ZFS volume don't work some time ago (don't know about current > > status). > > May be swap to file on ZFS don't work also? > > I do not use ZFS. No idea. May be someone know about current status swap in file on UFS. This is work for me some time ago. ___ 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: duration of buildworld
El día Monday, July 27, 2015 a las 10:34:10PM +0300, Slawa Olhovchenkov escribió: > > This pointed in the right direction. I have had 6x 1 GByte additional > > swap partitions to plain files mounted (because I needed this to get > > the eclipse port compiled within poudriere). After changing the fstab and > > reboot, the 'make buildkernel' takes only half an hour. > > > > Why is this? > > swap to ZFS volume don't work some time ago (don't know about current > status). > May be swap to file on ZFS don't work also? I do not use ZFS. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ ☎ +49-176-38902045 No! Nein! ¡No! Όχι! -- Ευχαριστούμε! ___ 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: duration of buildworld
On Mon, Jul 27, 2015 at 08:47:04PM +0200, Matthias Apitz wrote: > El d'ia Monday, July 27, 2015 a las 03:00:06PM +0300, Slawa Olhovchenkov > escribi'o: > > > On Mon, Jul 27, 2015 at 07:58:04AM +0200, Matthias Apitz wrote: > > > > > > > > Hello, > > > > > > Yesterday I grabbed r285885 from SVN and launched a > > > > > > # make -j2 buildworld > > > > > > which is still running after 19 hours on a server of 2 CPU of the type > > > Intel(R) Core(TM)2 Extreme CPU X9100 @ 3.06GHz and 4 GByte memory. > > > > > > Last time in January with r276659 on the same host it took only some 8 > > > hours, IIRC. > > > > > > Is there anything wrong of what could cause this change of the build > > > time? > > > > May be swap trashing on clang compilation? > > This pointed in the right direction. I have had 6x 1 GByte additional > swap partitions to plain files mounted (because I needed this to get > the eclipse port compiled within poudriere). After changing the fstab and > reboot, the 'make buildkernel' takes only half an hour. > > Why is this? swap to ZFS volume don't work some time ago (don't know about current status). May be swap to file on ZFS don't work also? ___ 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: duration of buildworld
El día Monday, July 27, 2015 a las 03:00:06PM +0300, Slawa Olhovchenkov escribió: > On Mon, Jul 27, 2015 at 07:58:04AM +0200, Matthias Apitz wrote: > > > > > Hello, > > > > Yesterday I grabbed r285885 from SVN and launched a > > > > # make -j2 buildworld > > > > which is still running after 19 hours on a server of 2 CPU of the type > > Intel(R) Core(TM)2 Extreme CPU X9100 @ 3.06GHz and 4 GByte memory. > > > > Last time in January with r276659 on the same host it took only some 8 > > hours, IIRC. > > > > Is there anything wrong of what could cause this change of the build > > time? > > May be swap trashing on clang compilation? This pointed in the right direction. I have had 6x 1 GByte additional swap partitions to plain files mounted (because I needed this to get the eclipse port compiled within poudriere). After changing the fstab and reboot, the 'make buildkernel' takes only half an hour. Why is this? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ ☎ +49-176-38902045 No! Nein! ¡No! Όχι! -- Ευχαριστούμε! ___ 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: FreeBSD Quarterly Status Report - Second Quarter 2015
On 7/27/15 10:32 PM, Willem Jan Withagen wrote: On 27/07/2015 16:25, Glen Barber wrote: On Mon, Jul 27, 2015 at 04:14:54PM +0200, Willem Jan Withagen wrote: On 27/07/2015 04:39, Benjamin Kaduk wrote: * Separated email services (and single-point-of-failure cases) from the machine that has been handling this task for over 18 years, to new, single-purpose service installations Hi, This sort of sounds like the system that a former company (IAE) donated to Jordan when he was here in Arnhem at a FreeBSD meeting organized by Wilco Bulte. I think it was called freefall?? There used to be pictures of the meeting online, but I can't seem to find them. Would be nice to know if that is the case, because then I'm really impressed with the life time of that system... Does anybody know if this is actually the case? Based on what I've recently learned of the machine's history, it was originally freefall, then became known as 'hub'. You have any idea what is/was actual the hardware that was in the box? If I remember correctly we gave Jordan a check for like 5000 guilders. Which I guess would be 2500 us$ at that time. Which was not an enormous amount of money, so even more impressive that the system lasted 18 years :) I think it was a bit like my grandfather's axe.. A really great axe. we replaced the handle 3 times, the head four times and put in a couple of new wedges, but it's a great axe that one! --WjW ___ 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_HEAD - Build #3012 - Fixed
FreeBSD_HEAD - Build #3012 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3012/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3012/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3012/console Change summaries: 285914 by marius: - Move the remainder of host controller capability registers reading from xhci_start_controller() to xhci_init(). These values don't change at run- time so there's no point of acquiring them on every USB_HW_POWER_RESUME instead of only once during initialization. In r276717, reading the first couple of registers in question already had been moved as a prerequisite for the changes in that revision. - Identify ASMedia ASM1042A controllers. - Use NULL instead of 0 for pointers. MFC after: 3 days 285913 by marius: - Fix compilation after r285909 with USB_DEBUG defined. - Regenerate usb.conf. 285912 by marius: - Use __FBSDID(). - Const'ify cons_to_vga_colors. - Fix line wrapping. MFC after: 3 days 285911 by marius: - Nuke dupe $FreeBSD$. - Fix whitespace. MFC after: 3 days 285910 by ed: Make shutdown() return ENOTCONN as required by POSIX, part deux. Summary: Back in 2005, maxim@ attempted to fix shutdown() to return ENOTCONN in case the socket was not connected (r150152). This had to be rolled back (r150155), as it broke some of the existing programs that depend on this behavior. I reapplied this change on my system and indeed, syslogd failed to start up. I fixed this back in February (279016) and MFC'ed it to the supported stable branches. Apart from that, things seem to work out all right. Since at least Linux and Mac OS X do the right thing, I'd like to go ahead and give this another try. To keep old copies of syslogd working, only start returning ENOTCONN for recent binaries. I took a look at the XNU sources and they seem to test against both SS_ISCONNECTED, SS_ISCONNECTING and SS_ISDISCONNECTING, instead of just SS_ISCONNECTED. That seams reasonable, so let's do the same. Test Plan: This issue was uncovered while writing tests for shutdown() in CloudABI: https://github.com/NuxiNL/cloudlibc/blob/master/src/libc/sys/socket/shutdown_test.c#L26 Reviewers: glebius, rwatson, #manpages, gnn, #network Reviewed By: gnn, #network Subscribers: bms, mjg, imp Differential Revision: https://reviews.freebsd.org/D3039 ___ 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_HEAD_i386 - Build #687 - Fixed
FreeBSD_HEAD_i386 - Build #687 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/687/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/687/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/687/console Change summaries: 285913 by marius: - Fix compilation after r285909 with USB_DEBUG defined. - Regenerate usb.conf. 285912 by marius: - Use __FBSDID(). - Const'ify cons_to_vga_colors. - Fix line wrapping. MFC after: 3 days 285911 by marius: - Nuke dupe $FreeBSD$. - Fix whitespace. MFC after: 3 days 285910 by ed: Make shutdown() return ENOTCONN as required by POSIX, part deux. Summary: Back in 2005, maxim@ attempted to fix shutdown() to return ENOTCONN in case the socket was not connected (r150152). This had to be rolled back (r150155), as it broke some of the existing programs that depend on this behavior. I reapplied this change on my system and indeed, syslogd failed to start up. I fixed this back in February (279016) and MFC'ed it to the supported stable branches. Apart from that, things seem to work out all right. Since at least Linux and Mac OS X do the right thing, I'd like to go ahead and give this another try. To keep old copies of syslogd working, only start returning ENOTCONN for recent binaries. I took a look at the XNU sources and they seem to test against both SS_ISCONNECTED, SS_ISCONNECTING and SS_ISDISCONNECTING, instead of just SS_ISCONNECTED. That seams reasonable, so let's do the same. Test Plan: This issue was uncovered while writing tests for shutdown() in CloudABI: https://github.com/NuxiNL/cloudlibc/blob/master/src/libc/sys/socket/shutdown_test.c#L26 Reviewers: glebius, rwatson, #manpages, gnn, #network Reviewed By: gnn, #network Subscribers: bms, mjg, imp Differential Revision: https://reviews.freebsd.org/D3039 ___ 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: FreeBSD Quarterly Status Report - Second Quarter 2015
On 27/07/2015 16:42, Glen Barber wrote: > On Mon, Jul 27, 2015 at 04:32:34PM +0200, Willem Jan Withagen wrote: >> On 27/07/2015 16:25, Glen Barber wrote: >>> On Mon, Jul 27, 2015 at 04:14:54PM +0200, Willem Jan Withagen wrote: On 27/07/2015 04:39, Benjamin Kaduk wrote: > * Separated email services (and single-point-of-failure cases) from > the machine that has been handling this task for over 18 years, to > new, single-purpose service installations Hi, This sort of sounds like the system that a former company (IAE) donated to Jordan when he was here in Arnhem at a FreeBSD meeting organized by Wilco Bulte. I think it was called freefall?? There used to be pictures of the meeting online, but I can't seem to find them. Would be nice to know if that is the case, because then I'm really impressed with the life time of that system... Does anybody know if this is actually the case? >>> >>> Based on what I've recently learned of the machine's history, it was >>> originally freefall, then became known as 'hub'. >> >> You have any idea what is/was actual the hardware that was in the box? >> >> If I remember correctly we gave Jordan a check for like 5000 guilders. >> Which I guess would be 2500 us$ at that time. Which was not an enormous >> amount of money, so even more impressive that the system lasted 18 years :) >> > > The physical hardware did not last this long, and I do not recall the > physical specs of the recently deprecated hardware, but as far as > "handling this task for 18 years", that could have been clarified a bit > more (my fault). The system moved chassis several times, but was never > reinstalled (as far as we can tell) - it was originally a FreeBSD > 2-STABLE install, and was upgraded constantly throughout its lifetime, > and finally ran 11-CURRENT before being decommissioned. Right, that makes more sense. And I'm sort of more "relaxed" that there is not that much commodity hardware capable to survive that long running 24*7 ... The oldest servers here in the basement are like 10 years old, and on the brink of being thrashed... --WjW ___ 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: E1000 mbuf leaks
On Monday, July 27, 2015, Hans Petter Selasky wrote: > Hi, > > I'm currently doing some busdma work, and possibly stepped over some > driver bugs. When "bus_dmamap_load_mbuf_sg()" returns ENOMEM the mbuf chain > is not freed. Is there some magic in "bus_dmamap_load_mbuf_sg()" for that > error code or is there a possible memory leak in all E1000 drivers? See > attached patch. Would this explain the high mbuf usage seen on pfsense when using the igb(4) or em(4) Intel NIC drivers? https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#Intel_igb.284.29_and_em.284.29_Cards Regards, Ben -- -- From: Benjamin Woods woods...@gmail.com ___ 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_HEAD - Build #3011 - Failure
FreeBSD_HEAD - Build #3011 - Failure:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3011/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3011/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3011/console
Change summaries:
285909 by marius:
- Probe UICLASS_CDC/UISUBCLASS_ABSTRACT_CONTROL_MODEL/0xff again. This
variant of Microsoft RNDIS, i. e. their unofficial version of CDC ACM,
has been disabled in r261544 for resolving a conflict with umodem(4).
Eventually, in r275790 that problem was dealt with in the right way.
However, r275790 failed to put probing of RNDIS devices in question
back.
- Initialize the device prior to querying it, as required by the RNDIS
specification. Otherwise already determining the MAC address may fail
rightfully.
- On detach, halt the device again.
- Use UCDC_SEND_ENCAPSULATED_{COMMAND,RESPONSE}. While these macros are
resolving to the same values as UR_{CLEAR_FEATURE,GET_STATUS}, the
former set is way more appropriate in this context.
- Report unknown - rather: unimplemented - events unconditionally and
not just in debug mode. This ensures that we'll get some hint of what
is going wrong instead of the driver silently failing.
- Deal with the Microsoft ActiveSync requirement of using an input buffer
the size of the expected reply or larger - except for variably sized
replies - when querying a device.
- Fix some pointless NULL checks, style bugs etc.
This changes allow urndis(4) to communicate with a Microsoft-certified
USB RNDIS test token.
MFC after: 3 days
Sponsored by: genua mbh
285908 by ed:
Add a futex implementation for CloudABI.
Summary:
CloudABI provides two different types of futex objects: read-write locks
and condition variables. There is no need to provide separate support
for once objects and thread joining, as these are efficiently simulated
by blocking on a read-write lock. Mutexes simply use read-write locks.
Condition variables always have a lock object associated to them. They
always know to which lock a thread needs to be migrated if woken up.
This allows us to implement requeueing. A broadcast on a condition
variable will never cause multiple threads to be woken up at once. They
will be woken up iteratively.
This implementation still has lots of room for improvement. Locking is
coarse and right now we use linked lists to store all of the locks and
condition variables, instead of using a hash table. The primary goal of
this implementation was to behave correctly. Performance will be
improved as we go.
Test Plan:
This futex implementation has been in use for the last couple of months
and seems to work pretty well. All of the cloudlibc and libc++ unit
tests seem to pass.
Reviewers: dchagin, kib, vangyzen
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D3148
285907 by ed:
Regenerate system call table.
285906 by ed:
Sync in latest upstream system call definitions.
Futex object scopes have been renamed from using their own constants to
simply reusing the existing CLOUDABI_MAP_{PRIVATE,SHARED} flags, as they
are more accurate in this context.
The end of the build log:
[...truncated 295972 lines...]
--- x86emu.o ---
ctfconvert -L VERSION -g x86emu.o
--- x86bios.ko.debug ---
ld -d -warn-common -r -d -o x86bios.ko.debug x86bios.o x86emu.o
ctfmerge -L VERSION -g -o x86bios.ko.debug x86bios.o x86emu.o
:> export_syms
awk -f /builds/FreeBSD_HEAD/sys/conf/kmod_syms.awk x86bios.ko.debug
export_syms | xargs -J% objcopy % x86bios.ko.debug
--- x86bios.ko.symbols ---
objcopy --only-keep-debug x86bios.ko.debug x86bios.ko.symbols
--- x86bios.ko ---
--- all_subdir_usb ---
--- all_subdir_uhso ---
ctfconvert -L VERSION -g uhso.o
--- all_subdir_x86bios ---
objcopy --strip-debug --add-gnu-debuglink=x86bios.ko.symbols x86bios.ko.debug
x86bios.ko
--- dmmisc.o ---
cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I.
-I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float -fno-asynchronous-unwind-tables -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror
/builds/FreeBSD_HEAD/sys/dev/pms/RefTisa/discovery/dm/dmmisc.c
-Wunused-variable -Woverflow -Wparentheses -w
--- modules-all ---
--- all_subdir_usb ---
--- uhso.ko.debug ---
ld -d -warn-common -r -d -o uhso.ko.debug uhso.o
ctfmerge -L VERSION -g -o uhso.ko.debug uhso.o
:> export_syms
Re: FreeBSD Quarterly Status Report - Second Quarter 2015
On Mon, Jul 27, 2015 at 04:32:34PM +0200, Willem Jan Withagen wrote: > On 27/07/2015 16:25, Glen Barber wrote: > > On Mon, Jul 27, 2015 at 04:14:54PM +0200, Willem Jan Withagen wrote: > >> On 27/07/2015 04:39, Benjamin Kaduk wrote: > >>> * Separated email services (and single-point-of-failure cases) from > >>> the machine that has been handling this task for over 18 years, to > >>> new, single-purpose service installations > >> > >> Hi, > >> > >> This sort of sounds like the system that a former company (IAE) donated > >> to Jordan when he was here in Arnhem at a FreeBSD meeting organized by > >> Wilco Bulte. I think it was called freefall?? > >> There used to be pictures of the meeting online, but I can't seem to > >> find them. > >> > >> Would be nice to know if that is the case, because then I'm really > >> impressed with the life time of that system... > >> Does anybody know if this is actually the case? > >> > > > > Based on what I've recently learned of the machine's history, it was > > originally freefall, then became known as 'hub'. > > You have any idea what is/was actual the hardware that was in the box? > > If I remember correctly we gave Jordan a check for like 5000 guilders. > Which I guess would be 2500 us$ at that time. Which was not an enormous > amount of money, so even more impressive that the system lasted 18 years :) > The physical hardware did not last this long, and I do not recall the physical specs of the recently deprecated hardware, but as far as "handling this task for 18 years", that could have been clarified a bit more (my fault). The system moved chassis several times, but was never reinstalled (as far as we can tell) - it was originally a FreeBSD 2-STABLE install, and was upgraded constantly throughout its lifetime, and finally ran 11-CURRENT before being decommissioned. Glen pgpFpDzeggXeu.pgp Description: PGP signature
Re: FreeBSD Quarterly Status Report - Second Quarter 2015
On 27/07/2015 16:25, Glen Barber wrote: > On Mon, Jul 27, 2015 at 04:14:54PM +0200, Willem Jan Withagen wrote: >> On 27/07/2015 04:39, Benjamin Kaduk wrote: >>> * Separated email services (and single-point-of-failure cases) from >>> the machine that has been handling this task for over 18 years, to >>> new, single-purpose service installations >> >> Hi, >> >> This sort of sounds like the system that a former company (IAE) donated >> to Jordan when he was here in Arnhem at a FreeBSD meeting organized by >> Wilco Bulte. I think it was called freefall?? >> There used to be pictures of the meeting online, but I can't seem to >> find them. >> >> Would be nice to know if that is the case, because then I'm really >> impressed with the life time of that system... >> Does anybody know if this is actually the case? >> > > Based on what I've recently learned of the machine's history, it was > originally freefall, then became known as 'hub'. You have any idea what is/was actual the hardware that was in the box? If I remember correctly we gave Jordan a check for like 5000 guilders. Which I guess would be 2500 us$ at that time. Which was not an enormous amount of money, so even more impressive that the system lasted 18 years :) --WjW ___ 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: FreeBSD Quarterly Status Report - Second Quarter 2015
On Mon, Jul 27, 2015 at 04:14:54PM +0200, Willem Jan Withagen wrote: > On 27/07/2015 04:39, Benjamin Kaduk wrote: > > * Separated email services (and single-point-of-failure cases) from > > the machine that has been handling this task for over 18 years, to > > new, single-purpose service installations > > Hi, > > This sort of sounds like the system that a former company (IAE) donated > to Jordan when he was here in Arnhem at a FreeBSD meeting organized by > Wilco Bulte. I think it was called freefall?? > There used to be pictures of the meeting online, but I can't seem to > find them. > > Would be nice to know if that is the case, because then I'm really > impressed with the life time of that system... > Does anybody know if this is actually the case? > Based on what I've recently learned of the machine's history, it was originally freefall, then became known as 'hub'. Glen pgpogDHlOBRn6.pgp Description: PGP signature
Re: FreeBSD Quarterly Status Report - Second Quarter 2015
On 27/07/2015 04:39, Benjamin Kaduk wrote: > * Separated email services (and single-point-of-failure cases) from > the machine that has been handling this task for over 18 years, to > new, single-purpose service installations Hi, This sort of sounds like the system that a former company (IAE) donated to Jordan when he was here in Arnhem at a FreeBSD meeting organized by Wilco Bulte. I think it was called freefall?? There used to be pictures of the meeting online, but I can't seem to find them. Would be nice to know if that is the case, because then I'm really impressed with the life time of that system... Does anybody know if this is actually the case? --WjW ___ 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_HEAD_i386 - Build #686 - Failure
FreeBSD_HEAD_i386 - Build #686 - Failure:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/686/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/686/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/686/console
Change summaries:
285909 by marius:
- Probe UICLASS_CDC/UISUBCLASS_ABSTRACT_CONTROL_MODEL/0xff again. This
variant of Microsoft RNDIS, i. e. their unofficial version of CDC ACM,
has been disabled in r261544 for resolving a conflict with umodem(4).
Eventually, in r275790 that problem was dealt with in the right way.
However, r275790 failed to put probing of RNDIS devices in question
back.
- Initialize the device prior to querying it, as required by the RNDIS
specification. Otherwise already determining the MAC address may fail
rightfully.
- On detach, halt the device again.
- Use UCDC_SEND_ENCAPSULATED_{COMMAND,RESPONSE}. While these macros are
resolving to the same values as UR_{CLEAR_FEATURE,GET_STATUS}, the
former set is way more appropriate in this context.
- Report unknown - rather: unimplemented - events unconditionally and
not just in debug mode. This ensures that we'll get some hint of what
is going wrong instead of the driver silently failing.
- Deal with the Microsoft ActiveSync requirement of using an input buffer
the size of the expected reply or larger - except for variably sized
replies - when querying a device.
- Fix some pointless NULL checks, style bugs etc.
This changes allow urndis(4) to communicate with a Microsoft-certified
USB RNDIS test token.
MFC after: 3 days
Sponsored by: genua mbh
The end of the build log:
[...truncated 188891 lines...]
--- if_ipheth.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 -mno-aes -mno-avx -std=iso9899:1999 -c
/usr/src/sys/modules/usb/ipheth/../../../dev/usb/net/if_ipheth.c -o if_ipheth.o
--- all_subdir_wlan_rssadapt ---
--- wlan_rssadapt.ko.debug ---
ld -Bshareable -d -warn-common -o wlan_rssadapt.ko.debug wlan_rssadapt.kld
--- wlan_rssadapt.ko.symbols ---
objcopy --only-keep-debug wlan_rssadapt.ko.debug wlan_rssadapt.ko.symbols
--- wlan_rssadapt.ko ---
objcopy --strip-debug --add-gnu-debuglink=wlan_rssadapt.ko.symbols
wlan_rssadapt.ko.debug wlan_rssadapt.ko
--- all_subdir_wlan ---
--- ieee80211_ratectl_none.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 -mno-aes -mno-avx -std=iso9899:1999 -c
/usr/src/sys/modules/wlan/../../net80211/ieee80211_ratectl_none.c -o
ieee80211_ratectl_none.o
--- ieee80211_ratectl.o ---
ctfconvert -L VERSION -g ieee80211_ratectl.o
--- all_subdir_usb ---
--- all_subdir_urndis ---
===> usb/urndis (all)
--- all_subdir_wlan ---
--- ieee80211_ratectl_none.o ---
ctfconvert -L VERSION -g ieee80211_ratectl_none.o
--- all_subdir_wlan_tkip ---
ctfconvert -L VERSION -g ieee80211_crypto_tkip.o
--- all_subdir_usb ---
--- if_urndis.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 -mno-aes -mno-avx -std=iso9899:1999 -c
/usr/src/sys/modules/usb/urndis/../../../de
Re: E1000 mbuf leaks
On Mon, Jul 27, 2015 at 01:02:32PM +0200, Hans Petter Selasky wrote: > Hi, > > I'm currently doing some busdma work, and possibly stepped over some > driver bugs. When "bus_dmamap_load_mbuf_sg()" returns ENOMEM the mbuf > chain is not freed. Is there some magic in "bus_dmamap_load_mbuf_sg()" > for that error code or is there a possible memory leak in all E1000 > drivers? See attached patch. I don't think it's an mbuf leak since lem(4) just prepend the mbuf to the if sendq(driver will retry it later). But I think your patch looks more correct in bus_dma(9) perspective. If bus_dmamap_load_mbuf_sg(9) returned an error except EFBIG, it would be correct for lem(4) to free the mbuf chains rather than restarting the bus_dmamap_load_mbuf_sg(9) later which shall fail again with ENOMEM. ___ 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: duration of buildworld
On Mon, Jul 27, 2015 at 01:06:15PM +0100, David Chisnall wrote: > On 27 Jul 2015, at 13:00, Slawa Olhovchenkov wrote: > > > > May be swap trashing on clang compilation? > > 4GB ought to be enough for building clang with -j2. A few of the > template-heavy files can use 500+MB of RAM compiling and linking > with BFD ld can easily hit 1GB (a lot more for a debug build - don't > try this on a 32-bit system!). I am try building 9.x with lot of memory and see about 1GB consumption when comiling (not linking) four clang library. I am don't know how clang in head consumption memory with self-compilation. And we don't know about available memory at this system (may be firefox runing?) ___ 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: duration of buildworld
On Mon, Jul 27, 2015 at 07:58:04AM +0200, Matthias Apitz wrote: > > Hello, > > Yesterday I grabbed r285885 from SVN and launched a > > # make -j2 buildworld > > which is still running after 19 hours on a server of 2 CPU of the type > Intel(R) Core(TM)2 Extreme CPU X9100 @ 3.06GHz and 4 GByte memory. > > Last time in January with r276659 on the same host it took only some 8 > hours, IIRC. > > Is there anything wrong of what could cause this change of the build > time? May be swap trashing on clang compilation? ___ 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: duration of buildworld
Hi! On 7/27/15, Matthias Apitz wrote: > > Hello, > > Yesterday I grabbed r285885 from SVN and launched a > > # make -j2 buildworld > > which is still running after 19 hours on a server of 2 CPU of the type > Intel(R) Core(TM)2 Extreme CPU X9100 @ 3.06GHz and 4 GByte memory. > > Last time in January with r276659 on the same host it took only some 8 > hours, IIRC. On my desktop system (Core i5-4670) takes only 50 minutes the buildworld + buildkernel with DEBUG kernel. > > Is there anything wrong of what could cause this change of the build > time? > > Thanks > > matthias > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ ☎ > +49-176-38902045 > No! Nein! ¡No! Όχι! -- Ευχαριστούμε! > ___ > 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"
E1000 mbuf leaks
Hi,
I'm currently doing some busdma work, and possibly stepped over some
driver bugs. When "bus_dmamap_load_mbuf_sg()" returns ENOMEM the mbuf
chain is not freed. Is there some magic in "bus_dmamap_load_mbuf_sg()"
for that error code or is there a possible memory leak in all E1000
drivers? See attached patch.
Index: if_em.c
===
--- if_em.c (revision 284591)
+++ if_em.c (working copy)
@@ -2027,9 +2027,6 @@
/* Try it again, but only once */
remap = 0;
goto retry;
- } else if (error == ENOMEM) {
- adapter->no_tx_dma_setup++;
- return (error);
} else if (error != 0) {
adapter->no_tx_dma_setup++;
m_freem(*m_headp);
Index: if_igb.c
===
--- if_igb.c(revision 284591)
+++ if_igb.c(working copy)
@@ -1905,9 +1905,6 @@
goto retry;
} else
return (error);
- case ENOMEM:
- txr->no_tx_dma_setup++;
- return (error);
default:
txr->no_tx_dma_setup++;
m_freem(*m_headp);
Index: if_lem.c
===
--- if_lem.c(revision 284591)
+++ if_lem.c(working copy)
@@ -1693,6 +1693,8 @@
}
} else if (error != 0) {
adapter->no_tx_dma_setup++;
+ m_freem(*m_headp);
+ *m_headp = NULL;
return (error);
}
--HPS
Index: if_em.c
===
--- if_em.c (revision 284591)
+++ if_em.c (working copy)
@@ -2027,9 +2027,6 @@
/* Try it again, but only once */
remap = 0;
goto retry;
- } else if (error == ENOMEM) {
- adapter->no_tx_dma_setup++;
- return (error);
} else if (error != 0) {
adapter->no_tx_dma_setup++;
m_freem(*m_headp);
Index: if_igb.c
===
--- if_igb.c (revision 284591)
+++ if_igb.c (working copy)
@@ -1905,9 +1905,6 @@
goto retry;
} else
return (error);
- case ENOMEM:
- txr->no_tx_dma_setup++;
- return (error);
default:
txr->no_tx_dma_setup++;
m_freem(*m_headp);
Index: if_lem.c
===
--- if_lem.c (revision 284591)
+++ if_lem.c (working copy)
@@ -1693,6 +1693,8 @@
}
} else if (error != 0) {
adapter->no_tx_dma_setup++;
+ m_freem(*m_headp);
+ *m_headp = NULL;
return (error);
}
___
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: IPSEC stop works after r285336
27.07.2015 10:23, Alexandr Krivulya пишет: > 26.07.2015 21:39, George Neville-Neil пишет: >> >> On 25 Jul 2015, at 1:51, Alexandr Krivulya wrote: >> >>> 25.07.2015 00:38, John-Mark Gurney пишет: Alexandr Krivulya wrote this message on Thu, Jul 23, 2015 at 10:38 +0300: > I have IPSEC tunnel inside l2tp tunnel via mpd. After r285536 I see > only > outgoing esp packets on ng interface: This change is -stable, not -current, but the change referenced below is -current... Which one are you running? Also, the only ipsec related change after r285535 is r285770, though that probably won't effect it... Could you possibly narrow the change that broke things? > root@thinkpad:/usr/src # tcpdump -i ng0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > listening on ng0, link-type NULL (BSD loopback), capture size > 262144 bytes > 10:35:27.331886 IP 10.10.10.2 > 10.10.10.1: > ESP(spi=0x03081e58,seq=0x9a5), length 140 > 10:35:28.371707 IP 10.10.10.2 > 10.10.10.1: > ESP(spi=0x03081e58,seq=0x9a6), length 140 > 10:35:29.443536 IP 10.10.10.2 > 10.10.10.1: > ESP(spi=0x03081e58,seq=0x9a7), length 140 > 10:35:30.457370 IP 10.10.10.2 > 10.10.10.1: > ESP(spi=0x03081e58,seq=0x9a8), length 140 > 10:35:31.475606 IP 10.10.10.2 > 10.10.10.1: > ESP(spi=0x03081e58,seq=0x9a9), length 140 > 10:35:31.622315 IP 10.10.10.1.isakmp > 10.10.10.2.isakmp: isakmp: > phase > 2/others ? inf[E] > 10:35:31.622544 IP 10.10.10.2.isakmp > 10.10.10.1.isakmp: isakmp: > phase > 2/others ? inf[E] > 10:35:31.622658 IP 10.10.10.2.isakmp > 10.10.10.1.isakmp: isakmp: > phase > 2/others ? inf[E] > 10:35:31.623933 IP 10.10.10.1.isakmp > 10.10.10.2.isakmp: isakmp: > phase > 2/others ? inf[E] > 10:35:32.492349 IP 10.10.10.2 > 10.10.10.1: > ESP(spi=0x03081e58,seq=0x9aa), length 140 > 10:35:33.509346 IP 10.10.10.2 > 10.10.10.1: > ESP(spi=0x03081e58,seq=0x9ab), length 140 > 10:35:34.527187 IP 10.10.10.2 > 10.10.10.1: > ESP(spi=0x03081e58,seq=0x9ac), length 140 > 10:35:35.539600 IP 10.10.10.2 > 10.10.10.1: > ESP(spi=0x03081e58,seq=0x9ad), length 140 > > With r285535 all works fine. >>> >>> Right commit is in subject - r285336. >> There were two IPsec related commits after 285336. >> >> Either 285347 or 285526 could be the fix. If you're OK after those >> two commits then the system is in correct working order. > I have 285833 on my laptop now (world+kernel full rebuild), but problem > still exists. With IPSEC_DEBUG enabled I have a lot of messages: kernel: esp_output: skip 20 hlen 24 rlen 76 padding 4 alen 20 blksd 16 kernel: esp_output: skip 20 hlen 24 rlen 160 padding 16 alen 20 blksd 16 kernel: esp_output: skip 20 hlen 24 rlen 30 padding 2 alen 20 blksd 16 kernel: esp_output: skip 20 hlen 24 rlen 161 padding 15 alen 20 blksd 16 ___ 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: duration of buildworld
El día Monday, July 27, 2015 a las 07:58:04AM +0200, Matthias Apitz escribió: > > Hello, > > Yesterday I grabbed r285885 from SVN and launched a > > # make -j2 buildworld > > which is still running after 19 hours on a server of 2 CPU of the type > Intel(R) Core(TM)2 Extreme CPU X9100 @ 3.06GHz and 4 GByte memory. > > Last time in January with r276659 on the same host it took only some 8 > hours, IIRC. > > Is there anything wrong of what could cause this change of the build > time? It terminated right now after nearly 24h. I never saw such a long build. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ ☎ +49-176-38902045 No! Nein! ¡No! Όχι! -- Ευχαριστούμε! ___ 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: FreeBSD_HEAD_amd64_gcc4.9 - Build #247 - Failure
On Mon, Jul 27, 2015 at 08:31:18 +0200, Baptiste Daroussin wrote: > On Mon, Jul 27, 2015 at 02:28:16PM +0800, Li-Wen Hsu wrote: > > On Mon, Jul 27, 2015 at 08:23:47 +0200, Baptiste Daroussin wrote: > > > On Mon, Jul 27, 2015 at 02:07:31PM +0800, Li-Wen Hsu wrote: > > > > On Mon, Jul 27, 2015 at 1:40 PM, Li-Wen Hsu wrote: > > > > > On Mon, Jul 27, 2015 at 10:55 AM, wrote: > > > > >> FreeBSD_HEAD_amd64_gcc4.9 - Build #247 - Failure: > > > > >> > > > > >> Build information: > > > > >> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/247/ > > > > >> Full change log: > > > > >> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/247/changes > > > > >> Full build log: > > > > >> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/247/console > > > > > > > > > > ... > > > > > > > > > >> The end of the build log: > > > > > > > > > > ... > > > > > > > > > >> + sudo pkg install -y devel/amd64-xtoolchain-gcc > > > > >> Updating FreeBSD repository catalogue... > > > > >> Fetching meta.txz: . done > > > > >> Fetching packagesite.txz: .. done > > > > >> Processing entries: .. done > > > > >> FreeBSD repository update completed. 24303 packages processed. > > > > >> pkg: No packages available to install matching > > > > >> 'devel/amd64-xtoolchain-gcc' have been found in the repositories > > > > > > > > > > I tried `pkg install -y devel/amd64-xtoolchain-gcc` in a newly > > > > > installed 10.1-RELEASE amd64 VM, it does not find > > > > > devel/amd64-xtoolchain-gcc either. While 11-CURRENT works. Is this a > > > > > package building issue? Is there anyone get different result? > > > > > > > > Sorry for the noise, I just found this commit: > > > > > > > > https://svnweb.freebsd.org/changeset/ports/392873 > > > > > > > > I'll disable this job first and see what we can do. > > > > > > > > Li-Wen > > > > > > A sorry I was not aware you were using it. I can readd it if you want it. > > > > That might be the fastest way, or do you have any other recommended > > alternative of it? > > > Given you are building directly on amd64 you can use the regular gcc ports, > no? Probably, I did not work on this job and might overlook something. > Anyway I'll readd the amd64 xtoolchain after I manage to fix it with gcc5 Thanks, before it backing to pkg.freebsd.org again, I'll just skip the step of installing it. Li-Wen -- Li-Wen Hsu http://lwhsu.org pgpZTRKVgPzPf.pgp Description: PGP signature
FreeBSD_HEAD_amd64_gcc4.9 - Build #248 - Fixed
FreeBSD_HEAD_amd64_gcc4.9 - Build #248 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/248/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/248/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/248/console Change summaries: No changes ___ 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: IPSEC stop works after r285336
26.07.2015 21:39, George Neville-Neil пишет: > > > On 25 Jul 2015, at 1:51, Alexandr Krivulya wrote: > >> 25.07.2015 00:38, John-Mark Gurney пишет: >>> Alexandr Krivulya wrote this message on Thu, Jul 23, 2015 at 10:38 >>> +0300: I have IPSEC tunnel inside l2tp tunnel via mpd. After r285536 I see only outgoing esp packets on ng interface: >>> This change is -stable, not -current, but the change referenced below >>> is -current... Which one are you running? >>> >>> Also, the only ipsec related change after r285535 is r285770, though >>> that probably won't effect it... Could you possibly narrow the change >>> that broke things? >>> root@thinkpad:/usr/src # tcpdump -i ng0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ng0, link-type NULL (BSD loopback), capture size 262144 bytes 10:35:27.331886 IP 10.10.10.2 > 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a5), length 140 10:35:28.371707 IP 10.10.10.2 > 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a6), length 140 10:35:29.443536 IP 10.10.10.2 > 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a7), length 140 10:35:30.457370 IP 10.10.10.2 > 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a8), length 140 10:35:31.475606 IP 10.10.10.2 > 10.10.10.1: ESP(spi=0x03081e58,seq=0x9a9), length 140 10:35:31.622315 IP 10.10.10.1.isakmp > 10.10.10.2.isakmp: isakmp: phase 2/others ? inf[E] 10:35:31.622544 IP 10.10.10.2.isakmp > 10.10.10.1.isakmp: isakmp: phase 2/others ? inf[E] 10:35:31.622658 IP 10.10.10.2.isakmp > 10.10.10.1.isakmp: isakmp: phase 2/others ? inf[E] 10:35:31.623933 IP 10.10.10.1.isakmp > 10.10.10.2.isakmp: isakmp: phase 2/others ? inf[E] 10:35:32.492349 IP 10.10.10.2 > 10.10.10.1: ESP(spi=0x03081e58,seq=0x9aa), length 140 10:35:33.509346 IP 10.10.10.2 > 10.10.10.1: ESP(spi=0x03081e58,seq=0x9ab), length 140 10:35:34.527187 IP 10.10.10.2 > 10.10.10.1: ESP(spi=0x03081e58,seq=0x9ac), length 140 10:35:35.539600 IP 10.10.10.2 > 10.10.10.1: ESP(spi=0x03081e58,seq=0x9ad), length 140 With r285535 all works fine. >> >> >> Right commit is in subject - r285336. > > There were two IPsec related commits after 285336. > > Either 285347 or 285526 could be the fix. If you're OK after those > two commits then the system is in correct working order. I have 285833 on my laptop now (world+kernel full rebuild), but problem still exists. ___ 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_HEAD-tests - Build #1225 - Fixed
FreeBSD_HEAD-tests - Build #1225 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1225/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1225/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1225/console Change summaries: No changes ___ 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"
