Re: slow USB 3.0 on -current
On 2020-07-13 03:02, John-Mark Gurney wrote: MB means megabytes.. I would use Mbps for bits... so, on Win10 and NetBSD, I'm able to get 100 MBytes/sec on Win10/NetBSD, and FreeBSD, I'm only getting a tenth the capability of gige at 9-10 MBytes/sec... I'll note that fetch reports numbers of MBps, which is one of the tools I've been using for testing. Hi, Could you have a look at the traffic pattern, when using iperf? usbdump -i usbusX -f Y Where X and Y are the numbers after ugen . Many of the network USB drivers are single buffered, because that's what older USB host controllers support. Then the IRQ rate 8000 for USB 2.0/3.0 and 1000 for USB 1.0, limits the number of packets per second. --HPS ___ 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: slow USB 3.0 on -current
On 2020-Jul-12, at 21:51, John-Mark Gurney wrote: > Mark Millard wrote this message on Sun, Jul 12, 2020 at 18:26 -0700: >> John-Mark Gurney jmg at funkthat.com wrote on >> Sat Jul 11 22:44:36 UTC 2020 : >> >>> I'm having issues getting good ethernet performance from a USB ethernet >>> adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's an >>> AMD PRO A10-8700B based system using the AMD A78 FCH chipset. >>> >>> Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB >>> adapter only gets around 10MB/sec performance. During the transfer, >>> the CPU usage is only around 3-5%, so it's definitely not CPU bound. >>> >>> I have tested Windows 10 and NetBSD 9.0 performance, and both provide >>> 100MB/sec+ w/o troubles. >>> >>> I have attached dmesg from both FreeBSD -current and NetBSD 9.0. >>> >>> Any hints on how to fix this? >>> >>> This may be related, but I'm also having issues w/ booting when I have >>> both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. >>> >>> If I move the SD card reader to USB 2.0, the umass device will attach >>> and work. I have also attached a clip of the dmesg from that >>> happening. >>> >>> Has anyone else seen this issue? Ideas or thoughts on how to resolve >>> the performance issues? >> >> It might prove useful to use iperf3 with >> >> # iperf3 -s >> >> on one machine and doing >> >> # iperf3 -c ADDR >> . . . >> # iperf3 -R -c ADDR >> . . . >> >> on the other. (That last swaps the >> sender/receiver status.) >> >> All 3 commands will have output. The >> -s one will produce output for each of >> the -c ones. >> >> The outputs for the sender(s) will include Cwnd >> (congestion window size) information that may >> be relevant. It will report bit rate and >> retry count sampling (and overall figures). > > Here is the results for FreeBSD w/ USB3 ure. .80 is the USB3 > adapter side: > gold,pts,/home/jmg,502$iperf3 -c 192.168.0.80 > Connecting to host 192.168.0.80, port 5201 > [ 5] local 192.168.0.2 port 50042 connected to 192.168.0.80 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 8.94 MBytes 75.0 Mbits/sec 931 15.5 KBytes > [ 5] 1.00-2.00 sec 9.98 MBytes 83.7 Mbits/sec 919 27.3 KBytes > [ 5] 2.00-3.00 sec 9.95 MBytes 83.5 Mbits/sec 954 5.71 KBytes > [ 5] 3.00-4.00 sec 9.97 MBytes 83.7 Mbits/sec 939 28.7 KBytes > [ 5] 4.00-5.00 sec 9.97 MBytes 83.6 Mbits/sec 951 17.3 KBytes > [ 5] 5.00-6.00 sec 9.99 MBytes 83.8 Mbits/sec 913 31.5 KBytes > [ 5] 6.00-7.00 sec 9.96 MBytes 83.5 Mbits/sec 956 20.1 KBytes > [ 5] 7.00-8.00 sec 10.0 MBytes 83.9 Mbits/sec 913 33.0 KBytes > [ 5] 8.00-9.00 sec 9.97 MBytes 83.6 Mbits/sec 945 24.4 KBytes > [ 5] 9.00-10.00 sec 9.99 MBytes 83.8 Mbits/sec 916 34.4 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 98.7 MBytes 82.8 Mbits/sec 9337 sender > [ 5] 0.00-10.25 sec 98.7 MBytes 80.8 Mbits/sec receiver > > iperf Done. > gold,pts,/home/jmg,503$iperf3 -R -c 192.168.0.80 > Connecting to host 192.168.0.80, port 5201 > Reverse mode, remote host 192.168.0.80 is sending > [ 5] local 192.168.0.2 port 51024 connected to 192.168.0.80 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 9.69 MBytes 81.3 Mbits/sec > [ 5] 1.00-2.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 2.00-3.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 3.00-4.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 4.00-5.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 5.00-6.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 6.00-7.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 7.00-8.00 sec 10.4 MBytes 87.6 Mbits/sec > [ 5] 8.00-9.00 sec 10.7 MBytes 89.9 Mbits/sec > [ 5] 9.00-10.00 sec 10.7 MBytes 89.8 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 106 MBytes 88.9 Mbits/sec 1381 sender > [ 5] 0.00-10.00 sec 106 MBytes 88.7 Mbits/sec receiver > > iperf Done. The "iperf3 -s" should have had output with the Cwnd figures for the "Reverse mode" case above (and the distribution for the 1381 Retr total). They might not match when the earlier figures that you did report for the non-Reverse mode. > As you can see, it matches what I measured earlier. > > And just to prove that the machine CAN move 100MB/sec, I've run iperf3 > using the onboard wired ethernet... I need multiple interfaces, which is > why I'm bothering trying to get USB3 ethernet working. > > This is using the onboard bge interface. It's IP is .79: > gold,pts,/home/jmg,507$iperf3 -c 192.168.0.79 > Connecting to host 192.168.0.79, port 5201 > [ 5] local 192.168.0.2 port 61500 connected to
Re: arm64 panic: reaper-related?
On Mon, Jul 13, 2020 at 01:58:21PM +, Glen Barber wrote: > Hi, > > This morning, one of our arm64 build machines panicked. It looks like > it is somehow reaper-related, but I am not entirely sure. Backtrace > follows. Any thoughts? I'm not quite sure where to go from here... > Thanks in advance for any input. > > db> set $lines 0 > db> bt > Tracing pid 11 tid 13 td 0xfd0001634000 > db_trace_self() at db_stack_trace+0xf8 > pc = 0x0075fdac lr = 0x00103e78 > sp = 0x00011eca89b0 fp = 0x00011eca89e0 > > db_stack_trace() at db_command+0x228 > pc = 0x00103e78 lr = 0x00103af0 > sp = 0x00011eca89f0 fp = 0x00011eca8ad0 > > db_command() at db_command_loop+0x58 > pc = 0x00103af0 lr = 0x00103898 > sp = 0x00011eca8ae0 fp = 0x00011eca8b00 > > db_command_loop() at db_trap+0xf4 > pc = 0x00103898 lr = 0x00106c0c > sp = 0x00011eca8b10 fp = 0x00011eca8d30 > > db_trap() at kdb pc = 0x00106c0c lr = 0x00463b0c > sp = 0x00011eca8d40 fp = 0x00011eca8df0 > > kdb_trap() at do_el1h_sync+0xf4 > pc = 0x00463b0c lr = 0x0077b448 > sp = 0x00011eca8e00 fp = 0x00011eca8e30 > > do_el1h_sync() at handle_el1h_sync+0x78 > pc = 0x0077b448 lr = 0x00762878 > sp = 0x00011eca8e40 fp = 0x00011eca8f50 > > handle_el1h_sync() at kdb_enter+0x34 > pc = 0x00762878 lr = 0x00463168 > sp = 0x00011eca8f60 fp = 0x00011eca8ff0 > > kdb_enter() at vpanic+0x1b0 > pc = 0x00463168 lr = 0x00417a74 > sp = 0x00011eca9000 fp = 0x00011eca90b0 > > vpanic() at panic+0x44 > pc = 0x00417a74 lr = 0x004178c0 > sp = 0x00011eca90c0 fp = 0x00011eca9140 > > panic() at __stack_chk_fail+0x10 > pc = 0x004178c0 lr = 0x0044ab6c > sp = 0x00011eca9150 fp = 0x00011eca9150 > > __stack_chk_fail() at putchar+0x2bc > pc = 0x0044ab6c lr = 0x00469ce8 > sp = 0x00011eca9160 fp = 0x00011eca91e0 > > putchar() at 0x106 > pc = 0x00469ce8 lr = 0x0106 > sp = 0x00011eca91f0 fp = 0x > > db> show proc 11 > Process 11 (idle) at 0xfd000163: > state: NORMAL > uid: 0 gids: 0 > parent: pid 0 at 0x010fae40 > ABI: null > reaper: 0x010fae40 reapsubtree: 11 > sigparent: 20 > vmspace: 0x01109200 >(map 0x01109200) >(map.pmap 0x011092c0) >(pmap 0x01109320) > threads: 48 > 13 Run CPU -1 [idle: cpu0] > 14 Run CPU 1 [idle: cpu1] > 15 Run CPU 2 [idle: cpu2] > 16 Run CPU 3 [idle: cpu3] > 17 Run CPU 4 [idle: cpu4] > 18 Run CPU 5 [idle: cpu5] > 19 Run CPU 6 [idle: cpu6] > 100010 Run CPU 7 [idle: cpu7] > 100011 Run CPU 8 [idle: cpu8] > 100012 CanRun [idle: cpu9] > 100013 Run CPU 10 [idle: cpu10] > 100014 Run CPU 11 [idle: cpu11] > 100015 Run CPU 12 [idle: cpu12] > 100016 Run CPU 13 [idle: cpu13] > 100017 Run CPU 14 [idle: cpu14] > 100018 Run CPU 15 [idle: cpu15] > 100019 Run CPU 16 [idle: cpu16] > 100020 Run CPU 17 [idle: cpu17] > 100021 Run CPU 18 [idle: cpu18] > 100022 Run CPU 19 [idle: cpu19] > 100023 Run CPU 20 [idle: cpu20] > 100024 Run CPU 21 [idle: cpu21] > 100025 Run CPU 22 [idle: cpu22] > 100026 Run CPU 23 [idle: cpu23] > 100027 Run CPU 24 [idle: cpu24] > 100028 Run CPU 25 [idle: cpu25] > 100029 Run CPU 26 [idle: cpu26] > 100030 CanRun [idle: cpu27] > 100031 Run CPU 28
arm64 panic: reaper-related?
Hi, This morning, one of our arm64 build machines panicked. It looks like it is somehow reaper-related, but I am not entirely sure. Backtrace follows. Any thoughts? I'm not quite sure where to go from here... Thanks in advance for any input. db> set $lines 0 db> bt Tracing pid 11 tid 13 td 0xfd0001634000 db_trace_self() at db_stack_trace+0xf8 pc = 0x0075fdac lr = 0x00103e78 sp = 0x00011eca89b0 fp = 0x00011eca89e0 db_stack_trace() at db_command+0x228 pc = 0x00103e78 lr = 0x00103af0 sp = 0x00011eca89f0 fp = 0x00011eca8ad0 db_command() at db_command_loop+0x58 pc = 0x00103af0 lr = 0x00103898 sp = 0x00011eca8ae0 fp = 0x00011eca8b00 db_command_loop() at db_trap+0xf4 pc = 0x00103898 lr = 0x00106c0c sp = 0x00011eca8b10 fp = 0x00011eca8d30 db_trap() at kdb pc = 0x00106c0c lr = 0x00463b0c sp = 0x00011eca8d40 fp = 0x00011eca8df0 kdb_trap() at do_el1h_sync+0xf4 pc = 0x00463b0c lr = 0x0077b448 sp = 0x00011eca8e00 fp = 0x00011eca8e30 do_el1h_sync() at handle_el1h_sync+0x78 pc = 0x0077b448 lr = 0x00762878 sp = 0x00011eca8e40 fp = 0x00011eca8f50 handle_el1h_sync() at kdb_enter+0x34 pc = 0x00762878 lr = 0x00463168 sp = 0x00011eca8f60 fp = 0x00011eca8ff0 kdb_enter() at vpanic+0x1b0 pc = 0x00463168 lr = 0x00417a74 sp = 0x00011eca9000 fp = 0x00011eca90b0 vpanic() at panic+0x44 pc = 0x00417a74 lr = 0x004178c0 sp = 0x00011eca90c0 fp = 0x00011eca9140 panic() at __stack_chk_fail+0x10 pc = 0x004178c0 lr = 0x0044ab6c sp = 0x00011eca9150 fp = 0x00011eca9150 __stack_chk_fail() at putchar+0x2bc pc = 0x0044ab6c lr = 0x00469ce8 sp = 0x00011eca9160 fp = 0x00011eca91e0 putchar() at 0x106 pc = 0x00469ce8 lr = 0x0106 sp = 0x00011eca91f0 fp = 0x db> show proc 11 Process 11 (idle) at 0xfd000163: state: NORMAL uid: 0 gids: 0 parent: pid 0 at 0x010fae40 ABI: null reaper: 0x010fae40 reapsubtree: 11 sigparent: 20 vmspace: 0x01109200 (map 0x01109200) (map.pmap 0x011092c0) (pmap 0x01109320) threads: 48 13 Run CPU -1 [idle: cpu0] 14 Run CPU 1 [idle: cpu1] 15 Run CPU 2 [idle: cpu2] 16 Run CPU 3 [idle: cpu3] 17 Run CPU 4 [idle: cpu4] 18 Run CPU 5 [idle: cpu5] 19 Run CPU 6 [idle: cpu6] 100010 Run CPU 7 [idle: cpu7] 100011 Run CPU 8 [idle: cpu8] 100012 CanRun [idle: cpu9] 100013 Run CPU 10 [idle: cpu10] 100014 Run CPU 11 [idle: cpu11] 100015 Run CPU 12 [idle: cpu12] 100016 Run CPU 13 [idle: cpu13] 100017 Run CPU 14 [idle: cpu14] 100018 Run CPU 15 [idle: cpu15] 100019 Run CPU 16 [idle: cpu16] 100020 Run CPU 17 [idle: cpu17] 100021 Run CPU 18 [idle: cpu18] 100022 Run CPU 19 [idle: cpu19] 100023 Run CPU 20 [idle: cpu20] 100024 Run CPU 21 [idle: cpu21] 100025 Run CPU 22 [idle: cpu22] 100026 Run CPU 23 [idle: cpu23] 100027 Run CPU 24 [idle: cpu24] 100028 Run CPU 25 [idle: cpu25] 100029 Run CPU 26 [idle: cpu26] 100030 CanRun [idle: cpu27] 100031 Run CPU 28 [idle: cpu28] 100032 Run CPU 29 [idle: cpu29] 100033 Run CPU 30 [idle: cpu30] 100034 Run CPU 31 [idle: cpu31] 100035
CFT for vendor openzfs - week 2 reminder
On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The current *tentative* merge date is August 10th. I hope it's not terribly controversial to point out that it really rests with users of non amd64 platforms to test to avoid any unpleasant surprises the next time they update their trees following the merge. == NB: Do NOT zpool upgrade unless you are willing to live without the ability to ever rollback to the legacy zfs kmod. Checkout updated HEAD: % git clone https://github.com/mattmacy/networking.git -b projects/openzfs_vendor freebsd Checkout updated openzfs in to sys/contrib: % git clone https://github.com/zfsonfreebsd/ZoF.git -b projects/openzfs_vendor freebsd/sys/contrib/openzfs Build world and kernel with whatever your usual configuration is. Where possible the openzfs kmod is backward compatible with the cmd utils in HEAD so common operations work with existing tools and the new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries are backward compatible with the zfs kmod in HEAD. Although ideally one would test this in a separate boot environment, the interoperability should allow one to rollback without too much difficulty. Thanks in advance for your time. -M ___ 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 CI Weekly Report 2020-07-12
FreeBSD CI Weekly Report 2020-07-12 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-07-06 to 2020-07-12. During this period, we have: * 1964 builds (95.7% (+0.0) passed, 4.3% (+0.0) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 225 test runs (86.7% (-4.7) passed, 13.3% (+6.1) unstable, 0.0% (-1.4) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 36 doc and www builds (100% (+4.3) passed) Test case status (on 2020-07-12 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | - | - | --- | | head/amd64 | 7859 (+2) | 7767 (+5) | 0 (0) | 92 (-3) | | head/i386 | 7857 (+2) | 7758 (+5) | 0 (0) | 99 (-3) | | 12-STABLE/amd64 | 7617 (0) | 7557 (+1) | 0 (0) | 60 (-1) | | 12-STABLE/i386 | 7615 (0) | 7547 (+1) | 0 (0) | 68 (-1) | | 11-STABLE/amd64 | 6912 (0) | 6861 (0) | 0 (0) | 51 (0) | | 11-STABLE/i386 | 6910 (0) | 6854 (-3) | 0 (0) | 56 (+3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200712 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcomed. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandlerCursesGUI.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Regressions * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 https://bugs.freebsd.org/246537 * lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import https://bugs.freebsd.org/244732 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) Fix in review: https://reviews.freebsd.org/D25284 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3749 tests, 2277 success, 647 failures, 825 skipped ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 *
Re: CFT for vendor openzfs - week 2 reminder
On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy wrote: > > On Wednesday, July 8th I issued the initial call for testing for the > update to HEAD to vendored openzfs. We'd like to give users roughly a > month to test before merging. The current *tentative* merge date is > August 10th. I hope it's not terribly controversial to point out that > it really rests with users of non amd64 platforms to test to avoid any > unpleasant surprises the next time they update their trees following > the merge. > I've had no problems with this on a couple amd64 systems; I did note that my loader.conf's needed a good s/vfs.zfs.arc_max/vfs.zfs.arc.max/ but I'm told a compat sysctl is on the TODO list to ease the transition. Thanks, Kyle Evans ___ 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: slow USB 3.0 on -current
Mark Millard wrote this message on Mon, Jul 13, 2020 at 00:44 -0700: > On 2020-Jul-12, at 21:51, John-Mark Gurney wrote: > > > Mark Millard wrote this message on Sun, Jul 12, 2020 at 18:26 -0700: > >> John-Mark Gurney jmg at funkthat.com wrote on > >> Sat Jul 11 22:44:36 UTC 2020 : > >> > >>> I'm having issues getting good ethernet performance from a USB ethernet > >>> adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's an > >>> AMD PRO A10-8700B based system using the AMD A78 FCH chipset. > >>> > >>> Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB > >>> adapter only gets around 10MB/sec performance. During the transfer, > >>> the CPU usage is only around 3-5%, so it's definitely not CPU bound. > >>> > >>> I have tested Windows 10 and NetBSD 9.0 performance, and both provide > >>> 100MB/sec+ w/o troubles. > >>> > >>> I have attached dmesg from both FreeBSD -current and NetBSD 9.0. > >>> > >>> Any hints on how to fix this? > >>> > >>> This may be related, but I'm also having issues w/ booting when I have > >>> both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. > >>> > >>> If I move the SD card reader to USB 2.0, the umass device will attach > >>> and work. I have also attached a clip of the dmesg from that > >>> happening. > >>> > >>> Has anyone else seen this issue? Ideas or thoughts on how to resolve > >>> the performance issues? > >> > >> It might prove useful to use iperf3 with > >> > >> # iperf3 -s > >> > >> on one machine and doing > >> > >> # iperf3 -c ADDR > >> . . . > >> # iperf3 -R -c ADDR > >> . . . > >> > >> on the other. (That last swaps the > >> sender/receiver status.) > >> > >> All 3 commands will have output. The > >> -s one will produce output for each of > >> the -c ones. > >> > >> The outputs for the sender(s) will include Cwnd > >> (congestion window size) information that may > >> be relevant. It will report bit rate and > >> retry count sampling (and overall figures). [...] > The "iperf3 -s" should have had output with the Cwnd > figures for the "Reverse mode" case above (and the > distribution for the 1381 Retr total). They might > not match when the earlier figures that you did report > for the non-Reverse mode. If you can tell how the Cwnd figures would help you figure out how to make the USB3 bus run faster, I'll spend the time to retest and give you the numbers, but I don't see how they can... [...] > > As you can see, both match approximately what I measured other methods, > > so, it's definitely not the way I measured performance. > > > >> My observation would be that neither type > >> of USB3 Ethernet adapter that I've tried > > > > What is the chipset that you tried? One of the earlier ones that I > > tried was an axe iirc, and was limited to around 500Mbps or so... > > Hmm. I only seem to be able to find one type. Its been a > while since I've used the other and I do not know where > it is at. For what I found: > > ugen0.2: at usbus0 > axge0 on uhub0 > axge0: on usbus0 > miibus1: on axge0 > rgephy0: PHY 3 on miibus1 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, > 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > > (I have access to more than one instance of the above.) Yeah, these are the ones that are known to not be able to get close to gige speeds, unlike the RealTek one that I am using now... I forgot that axge is the gigabit version of axe... > The iperf3 output that I reported was for using > of of the above. Note that when the USB3 EtherNet > was reciveing Cwnd was reported as 29.8 KBytes > or smaller for the example run, much like your > output reporting 34.4 KBytes or less for the > example run. They grew to match the speeds that the link could do.. > This may suggest some common constraint across various > USB3 EtherNet devices. The Cwnd figures are probably > too small to get near 900 Mbit/s+. As you can see, the NetBSD results was able to grow the Cwnd large enough to obtain performance... The stats that I provided were from the non-USB3 machine, and for tx'ing to matches the issue I raised in the original post... I could provide the Cwnd, but I don't see how that will debug a USB3 speed issue... The stats show that the Cwnd can grow on other OS's (NetBSD), and on wired (bge) fine. > But, even with a (smaller but) similar Cwnd figure > my example was getting faster transfers than your > example. I got smaller Retr figures as well. It > leaves me wondering if there are packets being > rejected in your context that are not in my > context. ping times to the machine via USB3 is higher than native gige, but that isn't too surprising due to the extra latency introduced by them.. it's: round-trip min/avg/max/stddev = 0.743/0.826/0.963/0.074 ms Where as to a slower machine (PINE A64-LTS, arm64) with a couple extra switches in between: round-trip
Re: CFT for vendor openzfs - week 2 reminder
To help us keep track, please file an issue https://github.com/zfsonfreebsd/zof/issues Thanks. On Mon, Jul 13, 2020 at 3:39 PM Evilham wrote: > > On dl., jul. 13 2020, Kyle Evans wrote: > > > On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy > > wrote: > >> > >> On Wednesday, July 8th I issued the initial call for testing > >> for the > >> update to HEAD to vendored openzfs. We'd like to give users > >> roughly a > >> month to test before merging. The current *tentative* merge > >> date is > >> August 10th. I hope it's not terribly controversial to point > >> out that > >> it really rests with users of non amd64 platforms to test to > >> avoid any > >> unpleasant surprises the next time they update their trees > >> following > >> the merge. > >> > > > > I've had no problems with this on a couple amd64 systems; I did > > note > > that my loader.conf's needed a good > > s/vfs.zfs.arc_max/vfs.zfs.arc.max/ > > but I'm told a compat sysctl is on the TODO list to ease the > > transition. > > > I've also been using this on amd64 for a few days without any > issues, it's even fixed a bug I've been trying to figure out: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247544 > > I have noticed a thing though: > > Previously observed behaviour: > 1. A new zpool is made available (e.g. geli attach) > 2. The zpool is imported > 3. Something happens (e.g. system reboot) and the zpool is not > available anymore but also not exported > 4. The zpool is made available again > 5. The zpool is *still* imported > 6. The zpool must be manually mounted > > With the patches for OpenZFS, number 5 and 6 are instead: > 5. The data zpool is not imported > 6. The zpool must be manually re-imported > > It is different behaviour, but I am very unsure about whether or > not that is to be considered a bug and needs a PR. > -- > Evilham ___ 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: -CURRENT and drm-devel-kmod
On 7/11/20 6:55 AM, Andreas Nilsson wrote: However, when I load i915kms from -devel the console stops refreshing. It only refreshes when I switch (Ctrl+alt+Fx). I see it refresh and display the new content just before switching to the requested console. add hw.i915kms.enable_psr=0 to /boot/loader.conf This is a bug that none of my hardware have and I don't really know what's happening for now. Thanks, setting that fixed the problem! ah thanks for asking this question Andreas (and the pointer Manu)! I've had this issue for a while but have been just blindly typing my login and xinit wrapper. interestingly enough, I've found if I start then exit Xorg the console starts updating again. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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: slow USB 3.0 on -current
On 2020-Jul-13, at 12:03, John-Mark Gurney wrote: > Mark Millard wrote this message on Mon, Jul 13, 2020 at 00:44 -0700: >> On 2020-Jul-12, at 21:51, John-Mark Gurney wrote: >> >>> . . . >> >> Hmm. I only seem to be able to find one type. Its been a >> while since I've used the other and I do not know where >> it is at. For what I found: >> >> ugen0.2: at usbus0 >> axge0 on uhub0 >> axge0: on usbus0 >> miibus1: on axge0 >> rgephy0: PHY 3 on miibus1 >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, >> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, >> 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >> >> (I have access to more than one instance of the above.) > > Yeah, these are the ones that are known to not be able to get close > to gige speeds, unlike the RealTek one that I am using now... Hmm, in one direction anyway? NetBSD current testing on a RPi4 for iperf3 -R -c 192.168.1.120 -B 192.168.1.140 : Server listening on 5201 --- Accepted connection from 192.168.1.140, port 65525 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.140 port 65524 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 33.7 MBytes 282 Mbits/sec0 33.9 KBytes [ 5] 1.00-2.00 sec 96.0 MBytes 805 Mbits/sec2 48.9 KBytes [ 5] 2.00-3.00 sec 111 MBytes 930 Mbits/sec 12 81.9 KBytes [ 5] 3.00-4.00 sec 83.8 MBytes 703 Mbits/sec 18114 KBytes [ 5] 4.00-5.00 sec 83.7 MBytes 702 Mbits/sec 42145 KBytes [ 5] 5.00-6.00 sec 84.8 MBytes 712 Mbits/sec 50178 KBytes [ 5] 6.00-7.00 sec 111 MBytes 929 Mbits/sec 40194 KBytes [ 5] 7.00-8.00 sec 83.6 MBytes 701 Mbits/sec 40194 KBytes [ 5] 8.00-9.00 sec 111 MBytes 930 Mbits/sec 47194 KBytes [ 5] 9.00-10.00 sec 111 MBytes 927 Mbits/sec 50193 KBytes [ 5] 10.00-10.62 sec 68.4 MBytes 929 Mbits/sec 46193 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.62 sec 977 MBytes 772 Mbits/sec 347 sender and as seen on the receiver: # iperf3 -R -c 192.168.1.120 -B 192.168.1.140 Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.140 port 65524 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 87.8 MBytes 736 Mbits/sec [ 5] 1.00-2.00 sec 110 MBytes 924 Mbits/sec [ 5] 2.00-3.00 sec 83.7 MBytes 702 Mbits/sec [ 5] 3.00-4.00 sec 83.6 MBytes 701 Mbits/sec [ 5] 4.00-5.00 sec 84.8 MBytes 711 Mbits/sec [ 5] 5.00-6.00 sec 111 MBytes 931 Mbits/sec [ 5] 6.00-7.00 sec 83.4 MBytes 700 Mbits/sec [ 5] 7.00-8.00 sec 111 MBytes 930 Mbits/sec [ 5] 8.00-9.00 sec 111 MBytes 929 Mbits/sec [ 5] 9.00-10.00 sec 111 MBytes 929 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.62 sec 977 MBytes 772 Mbits/sec 347 sender [ 5] 0.00-10.00 sec 977 MBytes 819 Mbits/sec receiver This is faster than the built-in EtherNet results. (But the built-in is also USB based.) As for iperf3 -c 192.168.1.120 -B 192.168.1.140 it is slower: Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.140 port 65526 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 62.5 MBytes 522 Mbits/sec0 4.00 MBytes [ 5] 1.00-2.01 sec 62.5 MBytes 524 Mbits/sec0 4.00 MBytes [ 5] 2.01-3.01 sec 62.5 MBytes 524 Mbits/sec0 4.00 MBytes [ 5] 3.01-4.01 sec 62.5 MBytes 524 Mbits/sec0 4.00 MBytes [ 5] 4.01-5.01 sec 62.5 MBytes 525 Mbits/sec0 4.00 MBytes [ 5] 5.01-6.01 sec 62.5 MBytes 523 Mbits/sec0 4.00 MBytes [ 5] 6.01-7.01 sec 62.5 MBytes 525 Mbits/sec0 4.00 MBytes [ 5] 7.01-8.01 sec 62.5 MBytes 525 Mbits/sec0 4.00 MBytes [ 5] 8.01-9.01 sec 62.5 MBytes 524 Mbits/sec0 4.00 MBytes [ 5] 9.01-10.01 sec 62.5 MBytes 525 Mbits/sec0 4.00 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.01 sec 625 MBytes 524 Mbits/sec0 sender [ 5] 0.00-10.62 sec 625 MBytes 494 Mbits/sec receiver This is again
Current panics on connecting disks to a LSI-3108 controller
Hi, I have this Supermicro SUPERSERVER®2028TP Which hold four nodes each with a X10DRT-PT motherboard and a LSI-3108 SAS controller connecting to 6 disks. Trying to run the most recent current snapshot on it. # uname -a FreeBSD quadbox-d.digiware.nl 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r363032: Thu Jul 9 04:13:17 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I have installed the OS on a SATA flash DOM. Booting works fine as long as there are no disks connected to LSI-3108 controller. Booting with SAS disks connected results in a panic. Attaching a SAS disk to the LSI-3108 controller give a panic as well. AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd mfi0: port 0x6000-0x60ff mem 0xc730-0xc730,0xc720-0xc72f irq 26 at device 0.0 numa-domain 0 on pci3 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 mfi0: FW MaxCmds = 928, limiting to 128 mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0 . mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started (PCI ID 005d/1000/0809/15d9) pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - Firmware version 4.290.00-4536 I have posted screenshots of the panic at: www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 But basically it crashes in mfi_tbolt_send_frame() +0x132 So is there anybody out there that can help me with analyzing and fixing this panic? Thanx, --WjW ___ 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: Current panics on connecting disks to a LSI-3108 controller
Willem Jan Withagen wrote: Hi, I have this Supermicro SUPERSERVER®2028TP Which hold four nodes each with a X10DRT-PT motherboard and a LSI-3108 SAS controller connecting to 6 disks. Trying to run the most recent current snapshot on it. # uname -a FreeBSD quadbox-d.digiware.nl 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r363032: Thu Jul 9 04:13:17 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I have installed the OS on a SATA flash DOM. Booting works fine as long as there are no disks connected to LSI-3108 controller. Booting with SAS disks connected results in a panic. Attaching a SAS disk to the LSI-3108 controller give a panic as well. AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd mfi0: port 0x6000-0x60ff mem 0xc730-0xc730,0xc720-0xc72f irq 26 at device 0.0 numa-domain 0 on pci3 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 mfi0: FW MaxCmds = 928, limiting to 128 mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0 . mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started (PCI ID 005d/1000/0809/15d9) pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - Firmware version 4.290.00-4536 I have posted screenshots of the panic at: www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 But basically it crashes in mfi_tbolt_send_frame() +0x132 So is there anybody out there that can help me with analyzing and fixing this panic? I guess it's not the answer you are looking for, but you could try the mrsas driver and check if it's behaves better for you, by setting 'set hw.mfi.mrsas_enable=1' from loader prompt. ___ 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: slow USB 3.0 on -current
[Just a correction to a side comment.] On 2020-Jul-13, at 12:46, Mark Millard wrote: > On 2020-Jul-13, at 12:03, John-Mark Gurney wrote: > >> Mark Millard wrote this message on Mon, Jul 13, 2020 at 00:44 -0700: >>> On 2020-Jul-12, at 21:51, John-Mark Gurney wrote: >>> . . . >>> >>> Hmm. I only seem to be able to find one type. Its been a >>> while since I've used the other and I do not know where >>> it is at. For what I found: >>> >>> ugen0.2: at usbus0 >>> axge0 on uhub0 >>> axge0: on usbus0 >>> miibus1: on axge0 >>> rgephy0: PHY 3 on miibus1 >>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, >>> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, >>> 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >>> >>> (I have access to more than one instance of the above.) >> >> Yeah, these are the ones that are known to not be able to get close >> to gige speeds, unlike the RealTek one that I am using now... > > Hmm, in one direction anyway? > > NetBSD current testing on a RPi4 for > iperf3 -R -c 192.168.1.120 -B 192.168.1.140 : > > Server listening on 5201 > --- > Accepted connection from 192.168.1.140, port 65525 > [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.140 port 65524 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 33.7 MBytes 282 Mbits/sec0 33.9 KBytes > [ 5] 1.00-2.00 sec 96.0 MBytes 805 Mbits/sec2 48.9 KBytes > [ 5] 2.00-3.00 sec 111 MBytes 930 Mbits/sec 12 81.9 KBytes > [ 5] 3.00-4.00 sec 83.8 MBytes 703 Mbits/sec 18114 KBytes > [ 5] 4.00-5.00 sec 83.7 MBytes 702 Mbits/sec 42145 KBytes > [ 5] 5.00-6.00 sec 84.8 MBytes 712 Mbits/sec 50178 KBytes > [ 5] 6.00-7.00 sec 111 MBytes 929 Mbits/sec 40194 KBytes > [ 5] 7.00-8.00 sec 83.6 MBytes 701 Mbits/sec 40194 KBytes > [ 5] 8.00-9.00 sec 111 MBytes 930 Mbits/sec 47194 KBytes > [ 5] 9.00-10.00 sec 111 MBytes 927 Mbits/sec 50193 KBytes > [ 5] 10.00-10.62 sec 68.4 MBytes 929 Mbits/sec 46193 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.62 sec 977 MBytes 772 Mbits/sec 347 sender > > and as seen on the receiver: > > # iperf3 -R -c 192.168.1.120 -B 192.168.1.140 > Connecting to host 192.168.1.120, port 5201 > Reverse mode, remote host 192.168.1.120 is sending > [ 5] local 192.168.1.140 port 65524 connected to 192.168.1.120 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 87.8 MBytes 736 Mbits/sec > [ 5] 1.00-2.00 sec 110 MBytes 924 Mbits/sec > [ 5] 2.00-3.00 sec 83.7 MBytes 702 Mbits/sec > [ 5] 3.00-4.00 sec 83.6 MBytes 701 Mbits/sec > [ 5] 4.00-5.00 sec 84.8 MBytes 711 Mbits/sec > [ 5] 5.00-6.00 sec 111 MBytes 931 Mbits/sec > [ 5] 6.00-7.00 sec 83.4 MBytes 700 Mbits/sec > [ 5] 7.00-8.00 sec 111 MBytes 930 Mbits/sec > [ 5] 8.00-9.00 sec 111 MBytes 929 Mbits/sec > [ 5] 9.00-10.00 sec 111 MBytes 929 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.62 sec 977 MBytes 772 Mbits/sec 347 sender > [ 5] 0.00-10.00 sec 977 MBytes 819 Mbits/sec receiver > > This is faster than the built-in EtherNet results. > (But the built-in is also USB based.) The built-in EtherNet does not show in usbdevs output. I got the context wrong for the ()'d note. > As for iperf3 -c 192.168.1.120 -B 192.168.1.140 it is > slower: > > Connecting to host 192.168.1.120, port 5201 > [ 5] local 192.168.1.140 port 65526 connected to 192.168.1.120 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 62.5 MBytes 522 Mbits/sec0 4.00 MBytes > [ 5] 1.00-2.01 sec 62.5 MBytes 524 Mbits/sec0 4.00 MBytes > [ 5] 2.01-3.01 sec 62.5 MBytes 524 Mbits/sec0 4.00 MBytes > [ 5] 3.01-4.01 sec 62.5 MBytes 524 Mbits/sec0 4.00 MBytes > [ 5] 4.01-5.01 sec 62.5 MBytes 525 Mbits/sec0 4.00 MBytes > [ 5] 5.01-6.01 sec 62.5 MBytes 523 Mbits/sec0 4.00 MBytes > [ 5] 6.01-7.01 sec 62.5 MBytes 525 Mbits/sec0 4.00 MBytes > [ 5] 7.01-8.01 sec 62.5 MBytes 525 Mbits/sec0 4.00 MBytes > [ 5] 8.01-9.01 sec 62.5 MBytes 524 Mbits/sec0 4.00 MBytes > [ 5]
Re: slow USB 3.0 on -current
Hans Petter Selasky wrote this message on Mon, Jul 13, 2020 at 10:50 +0200: > On 2020-07-13 03:02, John-Mark Gurney wrote: > > MB means megabytes.. I would use Mbps for bits... so, on Win10 and > > NetBSD, I'm able to get 100 MBytes/sec on Win10/NetBSD, and FreeBSD, > > I'm only getting a tenth the capability of gige at 9-10 MBytes/sec... > > > > I'll note that fetch reports numbers of MBps, which is one of the tools > > I've been using for testing. > > Could you have a look at the traffic pattern, when using iperf? > > usbdump -i usbusX -f Y > > Where X and Y are the numbers after ugen . > > Many of the network USB drivers are single buffered, because that's what > older USB host controllers support. Then the IRQ rate 8000 for USB > 2.0/3.0 and 1000 for USB 1.0, limits the number of packets per second. Hmm... now that I do the math, that sounds very likely what the problem is: 8000 int/s * 1480 bytes/int * 8 bits/byte /1000/1000 == 94.72 Mbps add in the delay to swap buffers... and this is very close to the speed that I'm seeing... I wasn't sure what to look for, but the output is here: https://www.funkthat.com/~jmg/FreeBSD/usb.a78/usbdump.0.4.txt.xz Also, the output does not match what the man page says.. It implies that OUT or IN, but I'm seeing SUBM and DONE instead, and the delimiters between the feels don't make sense... This was running: gold,pts,/home/jmg,521$iperf3 -b 240m -u -c 192.168.0.80 Connecting to host 192.168.0.80, port 5201 [ 5] local 192.168.0.2 port 65117 connected to 192.168.0.80 port 5201 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 28.6 MBytes 240 Mbits/sec 20531 [ 5] 1.00-2.00 sec 28.6 MBytes 240 Mbits/sec 20548 [ 5] 2.00-3.00 sec 28.6 MBytes 240 Mbits/sec 20550 [ 5] 3.00-4.00 sec 28.6 MBytes 240 Mbits/sec 20546 [ 5] 4.00-5.00 sec 28.6 MBytes 240 Mbits/sec 20551 [ 5] 5.00-6.00 sec 28.6 MBytes 240 Mbits/sec 20545 [ 5] 6.00-7.00 sec 28.6 MBytes 240 Mbits/sec 20548 [ 5] 7.00-8.01 sec 28.1 MBytes 234 Mbits/sec 20175 [ 5] 8.01-9.00 sec 29.1 MBytes 246 Mbits/sec 20921 [ 5] 9.00-10.00 sec 28.6 MBytes 240 Mbits/sec 20548 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate JitterLost/Total Datagrams [ 5] 0.00-10.00 sec 286 MBytes 240 Mbits/sec 0.000 ms 0/205463 (0%) sender [ 5] 0.00-10.35 sec 107 MBytes 87.1 Mbits/sec 0.172 ms 128298/205436 (62%) receiver Which is trying to send 240Mbps UDP traffic to the USB3 ethernet machine, and the machine only receives the usual 91Mbps... I have also published: https://www.funkthat.com/~jmg/FreeBSD/usb.a78/umass.debug.txt.xz Which shows the umass issue that I've been having where any umass device on this system almost never attaches... This was takes w/ hw.usb.umass.debug=-1 hw.usb.xhci.debug=17 I set those sysctl's, then attached the umass device (as USB3.0 SD card reader), waited for the five retries.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: CFT for vendor openzfs - week 2 reminder
On dl., jul. 13 2020, Kyle Evans wrote: On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy wrote: On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The current *tentative* merge date is August 10th. I hope it's not terribly controversial to point out that it really rests with users of non amd64 platforms to test to avoid any unpleasant surprises the next time they update their trees following the merge. I've had no problems with this on a couple amd64 systems; I did note that my loader.conf's needed a good s/vfs.zfs.arc_max/vfs.zfs.arc.max/ but I'm told a compat sysctl is on the TODO list to ease the transition. I've also been using this on amd64 for a few days without any issues, it's even fixed a bug I've been trying to figure out: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247544 I have noticed a thing though: Previously observed behaviour: 1. A new zpool is made available (e.g. geli attach) 2. The zpool is imported 3. Something happens (e.g. system reboot) and the zpool is not available anymore but also not exported 4. The zpool is made available again 5. The zpool is *still* imported 6. The zpool must be manually mounted With the patches for OpenZFS, number 5 and 6 are instead: 5. The data zpool is not imported 6. The zpool must be manually re-imported It is different behaviour, but I am very unsure about whether or not that is to be considered a bug and needs a PR. -- Evilham ___ 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: Current panics on connecting disks to a LSI-3108 controller
On 14-7-2020 00:47, Yuri Pankov wrote: Willem Jan Withagen wrote: Hi, I have this Supermicro SUPERSERVER®2028TP Which hold four nodes each with a X10DRT-PT motherboard and a LSI-3108 SAS controller connecting to 6 disks. Trying to run the most recent current snapshot on it. # uname -a FreeBSD quadbox-d.digiware.nl 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r363032: Thu Jul 9 04:13:17 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I have installed the OS on a SATA flash DOM. Booting works fine as long as there are no disks connected to LSI-3108 controller. Booting with SAS disks connected results in a panic. Attaching a SAS disk to the LSI-3108 controller give a panic as well. AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd mfi0: port 0x6000-0x60ff mem 0xc730-0xc730,0xc720-0xc72f irq 26 at device 0.0 numa-domain 0 on pci3 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 mfi0: FW MaxCmds = 928, limiting to 128 mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0 . mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started (PCI ID 005d/1000/0809/15d9) pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - Firmware version 4.290.00-4536 I have posted screenshots of the panic at: www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 But basically it crashes in mfi_tbolt_send_frame() +0x132 So is there anybody out there that can help me with analyzing and fixing this panic? I guess it's not the answer you are looking for, but you could try the mrsas driver and check if it's behaves better for you, by setting 'set hw.mfi.mrsas_enable=1' from loader prompt. That was a great suggestion. And what I read from the manual page, mrsas plays even nicer with CAM which is a plus. I guess that there are reason not to do this by default. So one gets mrsas unless it does not attach to that specific card in the system? --WjW ___ 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: CFT for vendor openzfs - week 2 reminder
Can anyone using the new vendor openzfs let us know if it fixes the "mmp_thread_enter" bug recently MFC'ed to STABLE? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247829 Cheers ___ 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: Current panics on connecting disks to a LSI-3108 controller
On 14/07/2020 03:39, Willem Jan Withagen wrote: > And what I read from the manual page, mrsas plays even nicer with CAM which > is a > plus. If by "nicer" you mean that mfi does not integrate with CAM at all, then you are right :-) Also, last I looked mfi has some pretty serious bugs in its direct interface to GEOM. We've seen all kinds of crashes with mfi at work. Whatever the reason why mrsas is not always preferred over mfi, it must pretty nebulous like POLA for existing users. From technical point of view, mrsas appears to be superior. -- Andriy Gapon ___ 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"
