Re: HEADS-UP: OpenSSL 1.1.1 in 12.0
On 11 Oct, Don Lewis wrote: > On 11 Oct, Don Lewis wrote: >> On 11 Oct, freebsd.curr...@clogic.com.ua wrote: >>> On 2018-10-10 06:14, Michael Butler wrote: On 10/9/18 5:34 PM, Glen Barber wrote: > OpenSSL has been updated to version 1.1.1 as of r339270. > > It is important to rebuild third-party packages before running: > > # make -C /usr/src delete-old && make -C /usr/src delete-old-libs > > Thank you for your patience while this work was in progress, and thank > you to all involved for their hard work in getting things ready for > this > update. So far, I've found two ports that will no longer build. They are: net-mgmt/net-snmp security/opencryptoki I simply chose those that were linked to /usr/lib/libssl.so.8 where the openssl update creates libssl.so.9. There may be more I haven't found yet, imb >>> >>> You always can add DEFAULT_VERSIONS+=ssl=openssl to /etc/make.conf to >>> use openssl from ports. >>> Anyway, I think apps from ports need to use openssl from ports. >> >> I've been doing this for a long time, but I still see a fair amount of >> breakage with the new base OpenSSL. I suspect that some ports are >> incorrectly stumbling across the new bits in base even though they >> shouldn't be looking there. > > security/p5-Net-SSLeay is hardwired to use base OpenSSL, so changing the > default version can't be done to unbreak p5-IO-Socket-SSL. > > devel/libsoup appears to allow the OpenSSL version to be set, but doesn't > have an option for GSSAPI, so it attempts to use base GSSAPI with ports > OpenSSL which is not a valid combo. > > emulators/virtualbox-ose is hardwired to use base OpenSSL. I now think the problem with virtualbox-ose is not the port. Rather it is the fact that that the base libssl.so and the libssl.so installed by the security/openssl have the same shared library version number even though they are radically different OpenSSL versions. ___ 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"
OpenSSL 1.1.1 libssl.so version number
Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
/usr/lib/libssl.so.8. The security/openssl port (1.0.2p) installed
${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
(1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11. After the import, the
base OpenSSL library is /usr/lib/libssl.so.9. Now if you build ports
with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
is ambiguous because there are now two different versions of libssl.so
(1.0.2p and 1.1.1) with the same shared library version number.
I stumbled across this when debugging a virtualbox-ose configure
failure. The test executable was linked to the ports version of
libssl.so but rtld chose the base libssl.so at run time.
___
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: nginx introduces extra delay when talking to slow backend (probably FreeBSD kevent specific)
* Dmitry Marakasov (amd...@amdmi3.ru) wrote:
I've gathered ktrace dumps for both cases, and it really looks that
the problem is related to kevent. After nginx sends response back
to client, it calls kevent(2) on client fd (which is 5).
When there is a bug (FreeBSD 11.2), the following happens:
49365 nginx3.099362 CALL
kevent(0x7,0x8022a2000,0,0x8023005c0,0x200,0x7fffe598)
49365 nginx3.099419 STRU struct kevent[] = { }
49365 nginx3.194695 STRU struct kevent[] = { { ident=5,
filter=EVFILT_WRITE, flags=0x20, fflags=0, data=0xbf88,
udata=0x8023633d1 } }
49365 nginx3.194733 RET kevent 1
...
49365 nginx3.194858 CALL
kevent(0x7,0x8022a2000,0,0x8023005c0,0x200,0x7fffe598)
49365 nginx3.194875 STRU struct kevent[] = { }
49365 nginx3.835259 STRU struct kevent[] = { { ident=5,
filter=EVFILT_READ, flags=0x8020, fflags=0, data=0,
udata=0x802346111 } }
49365 nginx3.835299 RET kevent 1
E.g. read and write events come separately, both with huge delays.
On FreeBSD-CURRENT which doesn't experience the problem, kdump looks this way:
8049 nginx3.081367 CALL
kevent(0x7,0x8012d1b40,0,0x8012da040,0x200,0x7fffe598)
8049 nginx3.081371 STRU struct kevent[] = { }
8049 nginx3.081492 STRU struct kevent[] = { { ident=5,
filter=EVFILT_WRITE, flags=0x20, fflags=0, data=0xbf88,
udata=0x801341f11 }
{ ident=5, filter=EVFILT_READ, flags=0x8020,
fflags=0, data=0, udata=0x801324e51 } }
8049 nginx3.081498 RET kevent 2
E.g. both events come immediately and at the same time.
Not sure if that's problem of kevent or something it relies on or the
way nginx uses it.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: https://github.com/AMDmi3
___
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"
nginx introduces extra delay when talking to slow backend (probably FreeBSD kevent specific)
Hi! I've noticed strange behavior of nginx with slow uwsgi backend (turned out to not be uwsgi specific, and acually reproduces with any backend) on FreeBSD 11.2 If backend replies in less than a second, nginx doesn't introduce any additional latency and replies in the same time. However if backend replies no more than around 1.2 seconds, nginx introduces an extra delay and replies in around 2.2 seconds. I've gathered some details here, including the graph of nginx reply time vs. backend reply time: https://github.com/AMDmi3/nginx-bug-demo It reproduces on FreeBSD 11.2 and around year old -CURRENT, but not the recent -CURRENT, so I suspect this may be FreeBSD specific (probably kevent-related) and already fixed. Still, I'm posting to both related nginx and FreeBSD lists for this problem to be known. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: https://github.com/AMDmi3 ___ 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: Good motherboard for Ryzen (first-gen)
On Thu, Oct 11, 2018 at 11:40 PM, Eric van Gyzen wrote: On 9/21/18 9:53 PM, Eric van Gyzen wrote: I would like to build a Ryzen desktop. Can anyone recommend a good motherboard? I'm planning on a first-gen, because the second-gen has similar stability problems as the first-gen had, and AMD hasn't released errata for the second-gen yet (as far as I know...I would love to be wrong). I would like to be a cool kid with a Threadripper, but I can't justify the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 cores. :) Ideally, I want an Intel NIC, ECC memory support, and a 3-year warranty. Thanks for all the responses. They were very helpful. Here is what I ended up building: Mobo: ASUS Prime X470-Pro CPU: Ryzen 7 2700X 3.7GHz 8-Core RAM: Corsair Vengeance LPX 2 x 16GB DDR4-2666 PC4-21300 C16 Video: ASUS GeForce GTX 1060 6GB Disk: Samsung 970 EVO 500GB TLC NAND M.2 2280 PCIe NVMe 3.0 x4 PSU: EVGA SuperNOVA G3 750 Watt 80 Plus Gold ATX Fan: Cooler Master Hyper 212 EVO Universal CPU Cooler It's running FreeBSD head. BIOS version is 4018 (2018-07-12). So far, it has been perfectly stable. No crashes, no lockups. It has been my work-from-home desktop for just over a week now. I'm overclocking the memory a little, but nothing else. The NIC works. The sound works, though I've only tested the rear analog output. The video card works with the nvidia-driver, currently 390.87. It's driving two 2560x1440 monitors over HDMI. The only problem so far: I can't get NUMA enabled. I've set Memory Interleave to "off", but the BIOS still doesn't generate an ACPI SRAT table. I'm still working on this. You won't ever get NUMA enabled. Because Ryzen 7 2700X is not a NUMA processor! :) Only Threadripper and EPYC are. Desktop Ryzen has a "slightly NUMA-like" thing going on, it's recognized as 'cache groups' in the line: FreeBSD/SMP: 1 package(s) x 2 cache groups x 4 core(s) x 2 hardware threads But it's not actual NUMA. ___ 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: 10G performance regression / difference cxl and ix RELENG11 vs HEAD
On 10/12/2018 12:52 PM, Navdeep Parhar wrote: > > The number of retries (the "Retr" column) should have been 0 in a > controlled test like this. Is this the default stack with all default > parameters or have you tuned TCP and/or sockets in any way? No tuning at all. After a reboot and one test, I am seeing a bunch of overflows. I am going to netboot back to RELENG_11 to confirm sysctl -a dev.cxl.1.stats dev.cxl.1.stats.rx_tls_octets: 0 dev.cxl.1.stats.rx_tls_records: 0 dev.cxl.1.stats.tx_tls_octets: 0 dev.cxl.1.stats.tx_tls_records: 0 dev.cxl.1.stats.rx_trunc3: 0 dev.cxl.1.stats.rx_trunc2: 12 dev.cxl.1.stats.rx_trunc1: 0 dev.cxl.1.stats.rx_trunc0: 0 dev.cxl.1.stats.rx_ovflow3: 0 dev.cxl.1.stats.rx_ovflow2: 58 dev.cxl.1.stats.rx_ovflow1: 0 dev.cxl.1.stats.rx_ovflow0: 0 dev.cxl.1.stats.rx_ppp7: 0 dev.cxl.1.stats.rx_ppp6: 0 dev.cxl.1.stats.rx_ppp5: 0 dev.cxl.1.stats.rx_ppp4: 0 dev.cxl.1.stats.rx_ppp3: 0 dev.cxl.1.stats.rx_ppp2: 0 dev.cxl.1.stats.rx_ppp1: 0 dev.cxl.1.stats.rx_ppp0: 0 dev.cxl.1.stats.rx_pause: 0 dev.cxl.1.stats.rx_frames_1519_max: 0 dev.cxl.1.stats.rx_frames_1024_1518: 6169625 dev.cxl.1.stats.rx_frames_512_1023: 473 dev.cxl.1.stats.rx_frames_256_511: 133 dev.cxl.1.stats.rx_frames_128_255: 150 dev.cxl.1.stats.rx_frames_65_127: 1015832 dev.cxl.1.stats.rx_frames_64: 4 dev.cxl.1.stats.rx_runt: 0 dev.cxl.1.stats.rx_symbol_err: 0 dev.cxl.1.stats.rx_len_err: 0 dev.cxl.1.stats.rx_fcs_err: 0 dev.cxl.1.stats.rx_jabber: 0 dev.cxl.1.stats.rx_too_long: 0 dev.cxl.1.stats.rx_ucast_frames: 7186215 dev.cxl.1.stats.rx_mcast_frames: 0 dev.cxl.1.stats.rx_bcast_frames: 2 dev.cxl.1.stats.rx_frames: 7186217 dev.cxl.1.stats.rx_octets: 9437149499 dev.cxl.1.stats.tx_ppp7: 0 dev.cxl.1.stats.tx_ppp6: 0 dev.cxl.1.stats.tx_ppp5: 0 dev.cxl.1.stats.tx_ppp4: 0 dev.cxl.1.stats.tx_ppp3: 0 dev.cxl.1.stats.tx_ppp2: 0 dev.cxl.1.stats.tx_ppp1: 0 dev.cxl.1.stats.tx_ppp0: 0 dev.cxl.1.stats.tx_pause: 222 dev.cxl.1.stats.tx_drop: 0 dev.cxl.1.stats.tx_frames_1519_max: 0 dev.cxl.1.stats.tx_frames_1024_1518: 5409152 dev.cxl.1.stats.tx_frames_512_1023: 11968 dev.cxl.1.stats.tx_frames_256_511: 162 dev.cxl.1.stats.tx_frames_128_255: 26 dev.cxl.1.stats.tx_frames_65_127: 3095205 dev.cxl.1.stats.tx_frames_64: 210 dev.cxl.1.stats.tx_error_frames: 0 dev.cxl.1.stats.tx_ucast_frames: 8516714 dev.cxl.1.stats.tx_mcast_frames: 0 dev.cxl.1.stats.tx_bcast_frames: 9 dev.cxl.1.stats.tx_frames: 8516945 dev.cxl.1.stats.tx_octets: 8434330861 dev.cxl.1.stats.tx_parse_error: 0 > Regards, > Navdeep > > > -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ 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: 10G performance regression / difference cxl and ix RELENG11 vs HEAD
On 10/12/18 9:52 AM, Navdeep Parhar wrote: > The number of retries (the "Retr" column) should have been 0 in a retransmits, not retries. ___ 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: 10G performance regression / difference cxl and ix RELENG11 vs HEAD
On 10/12/18 8:37 AM, Mike Tancsa wrote: > I was doing a quick iperf test with r339328 GENERIC-NODEBUG amd64, and > noticed I can no longer saturate a 10G nic with iperf3. I tried first > with the ix adapter, but was not sure if it was the driver or not. I > tried as well with a Chelsio and got similar numbers. > > # iperf3 -c 192.168.242.3 > Connecting to host 192.168.242.3, port 5201 > [ 5] local 192.168.242.2 port 50474 connected to 192.168.242.3 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 997 MBytes 8.36 Gbits/sec 717 175 > KBytes > [ 5] 1.00-2.00 sec 975 MBytes 8.18 Gbits/sec 668 41.1 > KBytes > [ 5] 2.00-3.00 sec 880 MBytes 7.38 Gbits/sec 846 25.6 > KBytes > [ 5] 3.00-4.00 sec 523 MBytes 4.39 Gbits/sec 802 59.8 > KBytes > [ 5] 4.00-5.00 sec 520 MBytes 4.36 Gbits/sec 882 48.4 > KBytes > [ 5] 5.00-6.00 sec 543 MBytes 4.55 Gbits/sec 838 56.9 > KBytes > [ 5] 6.00-7.00 sec 556 MBytes 4.66 Gbits/sec 850 11.4 > KBytes > [ 5] 7.00-8.00 sec 538 MBytes 4.51 Gbits/sec 795 39.9 > KBytes > [ 5] 8.00-9.00 sec 540 MBytes 4.53 Gbits/sec 853 57.0 > KBytes > [ 5] 9.00-10.00 sec 503 MBytes 4.22 Gbits/sec 814 59.8 > KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 6.42 GBytes 5.52 Gbits/sec 8065 > sender > [ 5] 0.00-10.00 sec 6.42 GBytes 5.52 Gbits/sec > receiver The number of retries (the "Retr" column) should have been 0 in a controlled test like this. Is this the default stack with all default parameters or have you tuned TCP and/or sockets in any way? Regards, Navdeep ___ 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"
Strange panic at boot with vmm in loader.conf vs manually loading it
I am guessing this does not have anything to do with vmm being loaded, but hardware being initialized in a particular order? If I load vmm in loader.conf, the box panics at boot up. However, manually loading it all seems to work. Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G RAM. FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG Leading up to the crash, I see ugen0.1: <0x1022 XHCI root HUB> at usbus0 ugen1.1: <0x1b21 XHCI root HUB> at usbus1 Trying to mount root from zfs:zroot/ROOT/default []... uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2 Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 usbus1 usbus0 uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2 uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 uhub2: 4 ports with 4 removable, self powered uhub1: 8 ports with 8 removable, self powered uhub0: 22 ports with 22 removable, self powered Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x398 fault code = supervisor write data, page not present instruction pointer = 0x20:0x8273d776 stack pointer = 0x28:0xfe0075d55230 frame pointer = 0x28:0xfe0075d55270 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1 (kernel) [ thread pid 1 tid 12 ] Stopped at rrw_enter_read_impl+0x36: lock cmpxchgq %r14,0x18(%rbx) db> bt Tracing pid 1 tid 12 td 0xf8000567d580 rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfe0075d55270 zfs_mount() at zfs_mount+0x7b2/frame 0xfe0075d55400 vfs_domount() at vfs_domount+0x5b2/frame 0xfe0075d55630 vfs_donmount() at vfs_donmount+0x930/frame 0xfe0075d556d0 kernel_mount() at kernel_mount+0x3d/frame 0xfe0075d55720 parse_mount() at parse_mount+0x451/frame 0xfe0075d55860 vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfe0075d559f0 start_init() at start_init+0x27/frame 0xfe0075d55a70 fork_exit() at fork_exit+0x83/frame 0xfe0075d55ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0075d55ab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- db> On a normal boot, the next line would be atrtc0 uhub0: Root mount waiting for: usbus2ugen2.1: <0x1022 XHCI root HUB> at usbus2 <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 usbus1 usbus0uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 uhub2: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2 uhub1: 4 ports with 4 removable, self powered uhub2: 8 ports with 8 removable, self powered uhub0: 22 ports with 22 removable, self powered atrtc0: providing initial system time start_init: trying /sbin/init Setting hostuuid: c3297ba0-3f01-11e7-8725-6045cba08a84. Setting hostid: 0x094fa67e. Starting file system checks: Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/perl5/5.26/mach/CORE 32-bit compatibility ldconfig path: /usr/lib32 Setting hostname: ryzenbsd12.sentex.ca. Manually loading it, dmesg shows AMD-Vi: IVRS Info VAsize = 64 PAsize = 48 GVAsize = 2 flags:0 driver bug: Unable to set devclass (class: ppc devname: (unknown)) ivhd0: on acpi0 ivhd0: Flag:b0 ivhd0: Features(type:0x11) MsiNumPPR = 0 PNBanks= 2 PNCounters= 0 ivhd0: Extended features[31:0]:22294ada HATS = 0x2 GATS = 0x0 GLXSup = 0x1 SmiFSup = 0x1 SmiFRC = 0x2 GAMSup = 0x1 DualPortLogSup = 0x2 DualEventLogSup = 0x2 ivhd0: Extended features[62:32]:f77ef Max PASID: 0x2f DevTblSegSup = 0x3 MarcSup = 0x1 ivhd0: supported paging level:7, will use only: 4 ivhd0: device range: 0x0 - 0x ivhd0: PCI cap 0x190b640f@0x40 feature:19 and loading it manually with boot.verbose set pci0: driver added found-> vendor=0x1022, dev=0x1451, revid=0x00 domain=0, bus=0, slot=0, func=2 class=08-06-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) MSI supports 4 messages, 64 bit pci0:0:0:2: reprobing on driver added found-> vendor=0x1022, dev=0x790b, revid=0x59 domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0403, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0:0:20:0: reprobing on driver added pci1: driver added pci2: driver added pci3: driver added pci4: driver added pci5: driver added pci6: driver added pci7: driver added pci8: driver added pci9: driver added found-> vendor=0x1425, dev=0x5501, revid=0x00 domain=0, bus=9, slot=0, func=5 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
10G performance regression / difference cxl and ix RELENG11 vs HEAD
I was doing a quick iperf test with r339328 GENERIC-NODEBUG amd64, and noticed I can no longer saturate a 10G nic with iperf3. I tried first with the ix adapter, but was not sure if it was the driver or not. I tried as well with a Chelsio and got similar numbers. # iperf3 -c 192.168.242.3 Connecting to host 192.168.242.3, port 5201 [ 5] local 192.168.242.2 port 50474 connected to 192.168.242.3 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 997 MBytes 8.36 Gbits/sec 717 175 KBytes [ 5] 1.00-2.00 sec 975 MBytes 8.18 Gbits/sec 668 41.1 KBytes [ 5] 2.00-3.00 sec 880 MBytes 7.38 Gbits/sec 846 25.6 KBytes [ 5] 3.00-4.00 sec 523 MBytes 4.39 Gbits/sec 802 59.8 KBytes [ 5] 4.00-5.00 sec 520 MBytes 4.36 Gbits/sec 882 48.4 KBytes [ 5] 5.00-6.00 sec 543 MBytes 4.55 Gbits/sec 838 56.9 KBytes [ 5] 6.00-7.00 sec 556 MBytes 4.66 Gbits/sec 850 11.4 KBytes [ 5] 7.00-8.00 sec 538 MBytes 4.51 Gbits/sec 795 39.9 KBytes [ 5] 8.00-9.00 sec 540 MBytes 4.53 Gbits/sec 853 57.0 KBytes [ 5] 9.00-10.00 sec 503 MBytes 4.22 Gbits/sec 814 59.8 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 6.42 GBytes 5.52 Gbits/sec 8065 sender [ 5] 0.00-10.00 sec 6.42 GBytes 5.52 Gbits/sec receiver If I do a parallel transfer I get closer to the max. However, on RELENG11 I could do pretty close to a full 10G no problem with just a single stream. This is with a GENERIC-NODEBUG kernel using a couple of T520s back to back t5iov1@pci0:9:0:1: class=0x02 card=0x1425 chip=0x50011425 rev=0x00 hdr=0x00 vendor = 'Chelsio Communications Inc' device = 'T520-CR Unified Wire Ethernet Controller' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xf668, size 524288, enabled bar [18] = type Memory, range 64, base 0xf660, size 524288, enabled bar [20] = type Memory, range 64, base 0xf688a000, size 8192, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 8 messages, 64 bit, vector masks cap 10[70] = PCI-Express 2 endpoint max data 512(2048) FLR RO NS link x8(x8) speed 8.0(8.0) -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ 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"
iflib_timer hits hung label; never recovers
My firewall is running head at r338402 (30 Aug). It has three I211 NICs (PCI dev 0x1539). About 24 hours ago, it said: Oct 11 22:29:03 asbestos kernel: igb1: TX(1) desc avail = 42, pidx = 524 Oct 11 22:29:03 asbestos kernel: Link state changed to down Oct 11 22:29:03 asbestos kernel: core: link state changed to DOWN It keeps saying this periodically: Oct 12 09:46:05 asbestos kernel: igb1: TX(1) desc avail = 1024, pidx = 0 $ dmesg | uniq -c 2455 igb1: TX(1) desc avail = 1024, pidx = 0 I can panic the box and get a vmcore, but what other information should I get before then? I tried to attach kgdb to the running kernel, but it failed. :( I grabbed sysctl dev.igb.1 and dropped it here: http://vangyzen.net/FreeBSD/igb.hang/ I haven't tried manually recovering with ifconfig because I want to diagnose why the driver couldn't do it automatically. I imagine it's hard to test this code path. :) Eric ___ 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: PKGBase installs openssl with pkg install -g 'FreeBSD-*'
On 12/10/18 15:45, Johan Hendriks wrote: > I am testing pkg base on a 12 current system, and all went fine, but > after the update to ALPHA9 the system keeps installing openssl-1.0.2p_1,1 > > I do a make buildworld && make buildkernel Then make packages. > Then i upgrade the package tree so to say with pkg update -r FreeBSD-base > > And then i do a pkg install -g 'FreeBSD-*' > > root@builder:/usr/src # pkg install -g 'FreeBSD-*' > Updating FreeBSD repository catalogue... > FreeBSD repository is up to date. > Updating FreeBSD-base repository catalogue... > FreeBSD-base repository is up to date. > All repositories are up to date. > Checking integrity... done (0 conflicting) > The following 333 package(s) will be affected (of 0 checked): > > New packages to be INSTALLED: > openssl: 1.0.2p_1,1 [FreeBSD] > > Installed packages to be UPGRADED: > FreeBSD-acct: 12.0.s20181011130928 -> 12.0.s20181012122202 > [FreeBSD-base] > FreeBSD-acct-debug: 12.0.s20181011130928 -> 12.0.s20181012122202 > [FreeBSD-base] > FreeBSD-acpi: 12.0.s20181011130928 -> 12.0.s20181012122202 > [FreeBSD-base] > > ... SNIP . > > FreeBSD-vi-debug: 12.0.s20181011130928 -> 12.0.s20181012122202 > [FreeBSD-base] > FreeBSD-zfs: 12.0.s20181011130928 -> 12.0.s20181012122202 [FreeBSD-base] > > Installed packages to be REINSTALLED: > pkg-1.10.5_3 [FreeBSD] (options changed) > > Number of packages to be installed: 1 > Number of packages to be upgraded: 331 > Number of packages to be reinstalled: 1 > > The process will require 11 MiB more space. > > Then the system is installing openssl and reinstalls pkg but after a > reboot pkg is not working anymore. > And gives me the following error. > root@builder:/usr/src # pkg > ld-elf.so.1: Shared object "libssl.so.8" not found, required by "pkg" > > What can i do to get out of this cycle. > Use pkg-static until you have a new pkg package linked to the new libssl to upgrade pkg to. Another option is preserving a copy of libssl.so.8 (and the related libcrypto too most probably) before pkg upgrade -- Guido Falsi ___ 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"
PKGBase installs openssl with pkg install -g 'FreeBSD-*'
I am testing pkg base on a 12 current system, and all went fine, but after the update to ALPHA9 the system keeps installing openssl-1.0.2p_1,1 I do a make buildworld && make buildkernel Then make packages. Then i upgrade the package tree so to say with pkg update -r FreeBSD-base And then i do a pkg install -g 'FreeBSD-*' root@builder:/usr/src # pkg install -g 'FreeBSD-*' Updating FreeBSD repository catalogue... FreeBSD repository is up to date. Updating FreeBSD-base repository catalogue... FreeBSD-base repository is up to date. All repositories are up to date. Checking integrity... done (0 conflicting) The following 333 package(s) will be affected (of 0 checked): New packages to be INSTALLED: openssl: 1.0.2p_1,1 [FreeBSD] Installed packages to be UPGRADED: FreeBSD-acct: 12.0.s20181011130928 -> 12.0.s20181012122202 [FreeBSD-base] FreeBSD-acct-debug: 12.0.s20181011130928 -> 12.0.s20181012122202 [FreeBSD-base] FreeBSD-acpi: 12.0.s20181011130928 -> 12.0.s20181012122202 [FreeBSD-base] ... SNIP . FreeBSD-vi-debug: 12.0.s20181011130928 -> 12.0.s20181012122202 [FreeBSD-base] FreeBSD-zfs: 12.0.s20181011130928 -> 12.0.s20181012122202 [FreeBSD-base] Installed packages to be REINSTALLED: pkg-1.10.5_3 [FreeBSD] (options changed) Number of packages to be installed: 1 Number of packages to be upgraded: 331 Number of packages to be reinstalled: 1 The process will require 11 MiB more space. Then the system is installing openssl and reinstalls pkg but after a reboot pkg is not working anymore. And gives me the following error. root@builder:/usr/src # pkg ld-elf.so.1: Shared object "libssl.so.8" not found, required by "pkg" What can i do to get out of this cycle. regards ___ 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: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
On 18. 10. 12., Harry Schmalzbauer wrote:
> Am 12.10.2018 um 07:41 schrieb Dag-Erling Smørgrav:
>> Jung-uk Kim writes:
>>> I forgot to patch one more file, i.e., Makefile.inc1. Please try the
>>> attached patch instead.
>> Thanks, I missed that too.
>>
>> DES
>
> Even with 339326 (adjusting Makefile.inc1) I get the foollowing build
> error (compiling 339326-amd64 on stable/11-amd64):
> building shared library libprivateldns.so.5
> cc -target x86_64-unknown-freebsd12.0
> --sysroot=/usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src
>
> /amd64.amd64/tmp
> -B/usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src/amd64.amd64/tmp/usr/bin
> -f
> stack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings
> -Wl,--warn-shared-textrel -o libprivateldns.so.5.full -Wl,-soname,libp
> rivateldns.so.5 `NM='nm' NMFLAGS='' lorder buffer.pico dane.pico
> dname.pico dnssec.pico dnssec_sign.pico dnssec_verify.pico dnsse
> c_zone.pico duration.pico error.pico higher.pico host2str.pico
> host2wire.pico keys.pico net.pico packet.pico parse.pico radix.pico
> rbtree.pico rdata.pico resolver.pico rr.pico rr_functions.pico
> sha1.pico sha2.pico str2host.pico tsig.pico update.pico util.pico
> wire2host.pico zone.pico b64_ntop.pico b64_pton.pico | tsort -q` -lssl
> -lcrypto
> /usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src/amd64.amd64/tmp/usr/bin/ld:
> error: unable to fi
> nd library -lssl
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [libprivateldns.so.5.full] Error code 1
https://docs.freebsd.org/cgi/mid.cgi?d218a9de-bfac-3a66-6197-4b58d5a78a94
The remaining patch is attached.
Jung-uk Kim
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 339326)
+++ Makefile.inc1 (working copy)
@@ -2631,9 +2631,10 @@ lib/librtld_db__L: lib/libprocstat__L
_secure_lib_libcrypto= secure/lib/libcrypto
_secure_lib_libssl= secure/lib/libssl
lib/libradius__L secure/lib/libssl__L: secure/lib/libcrypto__L
+secure/lib/libcrypto__L: lib/libthr__L
.if ${MK_LDNS} != "no"
_lib_libldns= lib/libldns
-lib/libldns__L: secure/lib/libcrypto__L
+lib/libldns__L: secure/lib/libssl__L
.endif
.if ${MK_OPENSSH} != "no"
_secure_lib_libssh= secure/lib/libssh
signature.asc
Description: OpenPGP digital signature
Re: careless commits disrupt
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: > Julian H. Stacey writes: > > Stefan Esser writes: > > > You should also delete old files: > > > > > > cd /usr/src > > > make delete-old > > > make delete-old-libs > > I just ran that. It deleted lots of stuff. & I'd only run it 2 days ago. > > I should have run it just before buildworld though. > > It's not suggested in the top of > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > > just at base of page. > > That's because you should *never* run delete-old or delete-old-libs from > a source tree that is newer than your installed system. It may delete > files which have been obsoleted by changes you haven't yet built and > installed, to the point where you may be unable to build and install > those changes. Arg ! So obviously true - in retrospect ! Yet I did it. Could we add a comment to the Makefile please ? It could save others. Maybe incorporate something from Stefan's (arrived while I was writing) > In this particular case, it will, at the very least, > break ssh and svn / svnlite. (Fortunately I'm running local inside a wall, & always keep both rlogin & ssh going to insure against foot shooting ) Thanks Dag-Erling ! Cheers, Julian -- Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich Brexit: 3,700,000 stolen votes in 1st referendum inc. 700,000 from Brits in EU Campaign lies & criminal funding, economy & pound down: New referendum needed. http://exitbrexit.ukhttps://www.peoples-vote.uk/petition ___ 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: careless commits disrupt
Am 12.10.18 um 07:39 schrieb Dag-Erling Sm�rgrav: > Julian H. Stacey writes: >> Stefan Esser writes: >>> You should also delete old files: >>> >>> cd /usr/src >>> make delete-old >>> make delete-old-libs >> I just ran that. It deleted lots of stuff. & I'd only run it 2 days ago. >> I should have run it just before buildworld though. >> It's not suggested in the top of >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html >> just at base of page. > > That's because you should *never* run delete-old or delete-old-libs from > a source tree that is newer than your installed system. It may delete > files which have been obsoleted by changes you haven't yet built and > installed, to the point where you may be unable to build and install > those changes. In this particular case, it will, at the very least, > break ssh and svn / svnlite. Yes, sorry, running make delete-old-libs before buildworld is no good idea, unless the old libraries have been copied to /usr/lib/compat before. The advice to run "make delete-old-libs" came from the following message from Glen Barber: https://lists.freebsd.org/pipermail/freebsd-current/2018-October/071581.html But the advice was not to delete old files before make buildworld, but only before starting the required port upgrades ... I might have mentioned, that I always preserve old shared libraries in /usr/lib/compat before running "make delete-old-libs". This allows to run old binaries, but prevents linking of new binaries against these libraries (should not matter for make buildworld, but for building ports, which I do at in the same script that invokes buildworld for critical kernel modules that are to be built from ports). No binary or library should reference a library whose path contains /compat/ after all upgrades have been performed, obviously ... Regards, STefan ___ 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: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
On Fri, 12 Oct 2018 09:59+0200, Raúl wrote: > (also deleted obj) I do that whenever sys/sys/param.h changes. My builder wipes obj unconditionally every Monday in addition to the above. -- Trond. ___ 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: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
El 12/10/18 a las 7:30, Dag-Erling Smørgrav escribió: > Alex, Julian and others are seeing linker failures in libcrypto, long > before libldns. I have the exact same issue on i386 but not amd64; I Same here on amd64, to follow head I was building on other box and tarballing src and obj. Then I saw Glen's Heads-up and I tried (also deleted obj). It built fine and that's why I suggested following Glen's heads-up. This same box built this night from r339293 to r339318 without patches nor glitches. Raúl. ___ 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: Dell latitude 7490 touchpad support?
On Thu, Oct 11, 2018 at 08:20:13PM -0400, Hyun Hwang wrote: > On Saturday, September 29, 2018, 8:48 PM (UTC+0100), Johannes Lundberg > wrote: > > Hi > > > > I just got a new work laptop and the touchpad does not work. Some > > information points to that this machine has a Microsoft precision touchpad. > > I can't see any USB device so I'm wondering if this is an I2C device? I think I have the same problem with Dell Precision 3520 under 12-current: https://lists.freebsd.org/pipermail/freebsd-questions/2018-April/281490.html Anton ___ 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: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
Am 12.10.2018 um 07:41 schrieb Dag-Erling Smørgrav: Jung-uk Kim writes: I forgot to patch one more file, i.e., Makefile.inc1. Please try the attached patch instead. Thanks, I missed that too. DES Even with 339326 (adjusting Makefile.inc1) I get the foollowing build error (compiling 339326-amd64 on stable/11-amd64): building shared library libprivateldns.so.5 cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src /amd64.amd64/tmp -B/usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src/amd64.amd64/tmp/usr/bin -f stack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libprivateldns.so.5.full -Wl,-soname,libp rivateldns.so.5 `NM='nm' NMFLAGS='' lorder buffer.pico dane.pico dname.pico dnssec.pico dnssec_sign.pico dnssec_verify.pico dnsse c_zone.pico duration.pico error.pico higher.pico host2str.pico host2wire.pico keys.pico net.pico packet.pico parse.pico radix.pico rbtree.pico rdata.pico resolver.pico rr.pico rr_functions.pico sha1.pico sha2.pico str2host.pico tsig.pico update.pico util.pico wire2host.pico zone.pico b64_ntop.pico b64_pton.pico | tsort -q` -lssl -lcrypto /usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src/amd64.amd64/tmp/usr/bin/ld: error: unable to fi nd library -lssl cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libprivateldns.so.5.full] Error code 1 Thanks, -harry ___ 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"
