Re: CFT for vendor openzfs - week 4 reminder + memdisk images
On Tue, Jul 28, 2020 at 21:06 Chris wrote: > On Tue, 28 Jul 2020 20:50:33 -0700 Matthew Macy mm...@freebsd.org said > > > On Tue, Jul 28, 2020 at 20:43 Chris wrote: > > > > > On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said > > > > > > > On Tue, Jul 28, 2020 at 8:03 PM Chris > wrote: > > > > > > > > > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org > said > > > > > > > > > > > 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 tentative merge date is August > > > > > > 17th. > > > > > > > > > > > > Again, 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. > > > > > > > > > > > > amd64, i386, and aarch64 memdisk images can be found at: > > > > > > > > > > > > > > > > > > https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/ > > > > > > > > > > Is this in an attempt to replace the opensolaris version used now? > > > > > > > > The word "attempt" is a misnomer. If you search the mail archives > this > > > > has been the PoR for some time. > > > Sure. OK. I caught this thread. But must have missed the announcement > > > of the intent to replace the opensolaris version with openzfs. > > > Do you recall which mailing list that was made to? > > > > > > Thank you for your quick reply, Matthew. > > > > > > > Apart from the 3 previous CFT mails, the initial intent was discussed in > > December 2018. Getting FreeBSD support integrated in to openzfs took a > lot > > more incremental PRs than I anticipated. > > > > > https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html > > Thank you very much, Mathew. Sorry for any bother. > No bother or not much at least. It’s just been a long haul and I’d like to wrap this up. -M > > --Chris > > > > 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: CFT for vendor openzfs - week 4 reminder + memdisk images
On Tue, 28 Jul 2020 20:50:33 -0700 Matthew Macy mm...@freebsd.org said On Tue, Jul 28, 2020 at 20:43 Chris wrote: > On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said > > > On Tue, Jul 28, 2020 at 8:03 PM Chris wrote: > > > > > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said > > > > > > > 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 tentative merge date is August > > > > 17th. > > > > > > > > Again, 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. > > > > > > > > amd64, i386, and aarch64 memdisk images can be found at: > > > > > > > > > https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/ > > > > > > Is this in an attempt to replace the opensolaris version used now? > > > > The word "attempt" is a misnomer. If you search the mail archives this > > has been the PoR for some time. > Sure. OK. I caught this thread. But must have missed the announcement > of the intent to replace the opensolaris version with openzfs. > Do you recall which mailing list that was made to? > > Thank you for your quick reply, Matthew. > Apart from the 3 previous CFT mails, the initial intent was discussed in December 2018. Getting FreeBSD support integrated in to openzfs took a lot more incremental PRs than I anticipated. https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html Thank you very much, Mathew. Sorry for any bother. --Chris 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: CFT for vendor openzfs - week 4 reminder + memdisk images
On Tue, Jul 28, 2020 at 20:43 Chris wrote: > On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said > > > On Tue, Jul 28, 2020 at 8:03 PM Chris wrote: > > > > > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said > > > > > > > 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 tentative merge date is August > > > > 17th. > > > > > > > > Again, 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. > > > > > > > > amd64, i386, and aarch64 memdisk images can be found at: > > > > > > > > https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/ > > > > > > Is this in an attempt to replace the opensolaris version used now? > > > > The word "attempt" is a misnomer. If you search the mail archives this > > has been the PoR for some time. > Sure. OK. I caught this thread. But must have missed the announcement > of the intent to replace the opensolaris version with openzfs. > Do you recall which mailing list that was made to? > > Thank you for your quick reply, Matthew. > Apart from the 3 previous CFT mails, the initial intent was discussed in December 2018. Getting FreeBSD support integrated in to openzfs took a lot more incremental PRs than I anticipated. https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html Cheers. > --Chris > > > > > > > > ___ 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 4 reminder + memdisk images
On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said On Tue, Jul 28, 2020 at 8:03 PM Chris wrote: > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said > > > 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 tentative merge date is August > > 17th. > > > > Again, 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. > > > > amd64, i386, and aarch64 memdisk images can be found at: > > > https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/ > > Is this in an attempt to replace the opensolaris version used now? The word "attempt" is a misnomer. If you search the mail archives this has been the PoR for some time. Sure. OK. I caught this thread. But must have missed the announcement of the intent to replace the opensolaris version with openzfs. Do you recall which mailing list that was made to? Thank you for your quick reply, Matthew. --Chris > ___ 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 4 reminder + memdisk images
On Tue, Jul 28, 2020 at 8:03 PM Chris wrote: > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said > > > 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 tentative merge date is August > > 17th. > > > > Again, 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. > > > > amd64, i386, and aarch64 memdisk images can be found at: > > https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/ > > Is this in an attempt to replace the opensolaris version used now? The word "attempt" is a misnomer. If you search the mail archives this has been the PoR for some time. > > Thanks. > > --Chris > > > ___ > 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-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 4 reminder + memdisk images
On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said 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 tentative merge date is August 17th. Again, 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. amd64, i386, and aarch64 memdisk images can be found at: https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/ Is this in an attempt to replace the opensolaris version used now? Thanks. --Chris ___ 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"
CFT for vendor openzfs - week 4 reminder + memdisk images
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 tentative merge date is August 17th. Again, 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. amd64, i386, and aarch64 memdisk images can be found at: https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/ If you're using a platform not listed above and would be inclined to test if you had an image to work with, let us know. Alternatively, you can still build following the instructions below. The review for merging in to base can be found at: https://reviews.freebsd.org/D25872 == 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. ___ 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"
nvidia-driver-390 fails to find screens
Was there any significant change in the base code, so that Nvidia driver suddenly can't find usable displays upon the update to r363439 ?Error message: NVIDIA(GPU-0): Failed to select a display subsystem. Отправлено из Yahoo Почты для Android ___ 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: major update to if_ure (RPi4B uefi/ACPI booted example's iperf3 output)
I had reason to switch to using the RPi4B, which happens to be booted from ACPI. The only Ethernet connection present for this test is via: Autoloading module: if_ure.ko ure0 on uhub1 ure0: on usbus0 add host 127.0.0.1: gateway lo0 fib 0: route already in table miibus0: on ure0 rgephy0: PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 ue0: Ethernet address: ### . . . ue0: flags=8843 metric 0 mtu 1500 options=68009b ether ### inet 192.168.1.133 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 # iperf3 -c 192.168.1.120 --get-server-output Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.133 port 15954 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 83.6 MBytes 702 Mbits/sec 797 17.1 KBytes [ 5] 1.00-2.00 sec 83.5 MBytes 700 Mbits/sec 797 7.13 KBytes [ 5] 2.00-3.00 sec 83.7 MBytes 702 Mbits/sec 783 1.43 KBytes [ 5] 3.00-4.00 sec 83.3 MBytes 699 Mbits/sec 813127 KBytes [ 5] 4.00-5.00 sec 82.8 MBytes 695 Mbits/sec 806 18.5 KBytes [ 5] 5.00-6.00 sec 83.9 MBytes 704 Mbits/sec 822 38.4 KBytes [ 5] 6.00-7.00 sec 83.7 MBytes 702 Mbits/sec 808 64.2 KBytes [ 5] 7.00-8.00 sec 83.1 MBytes 697 Mbits/sec 787 92.2 KBytes [ 5] 8.00-9.00 sec 83.2 MBytes 698 Mbits/sec 788 51.2 KBytes [ 5] 9.00-10.00 sec 83.1 MBytes 697 Mbits/sec 799 47.1 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 834 MBytes 700 Mbits/sec 8000 sender [ 5] 0.00-10.24 sec 834 MBytes 683 Mbits/sec receiver Server output: Accepted connection from 192.168.1.133, port 18615 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.133 port 15954 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 63.7 MBytes 535 Mbits/sec [ 5] 1.00-2.00 sec 83.3 MBytes 699 Mbits/sec [ 5] 2.00-3.00 sec 83.6 MBytes 701 Mbits/sec [ 5] 3.00-4.00 sec 83.5 MBytes 700 Mbits/sec [ 5] 4.00-5.00 sec 83.4 MBytes 699 Mbits/sec [ 5] 5.00-6.00 sec 83.5 MBytes 700 Mbits/sec [ 5] 6.00-7.00 sec 83.2 MBytes 698 Mbits/sec [ 5] 7.00-8.00 sec 83.5 MBytes 701 Mbits/sec [ 5] 8.00-9.00 sec 83.1 MBytes 697 Mbits/sec [ 5] 9.00-10.00 sec 83.4 MBytes 700 Mbits/sec [ 5] 10.00-10.24 sec 19.6 MBytes 693 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.24 sec 834 MBytes 683 Mbits/sec receiver iperf Done. # iperf3 -R -c 192.168.1.120 --get-server-output Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.133 port 55961 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 111 MBytes 933 Mbits/sec [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec [ 5] 4.00-5.00 sec 111 MBytes 932 Mbits/sec [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.23 sec 1.09 GBytes 914 Mbits/sec 498 sender [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec receiver Server output: --- Server listening on 5201 --- Accepted connection from 192.168.1.133, port 51297 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.133 port 55961 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 87.5 MBytes 734 Mbits/sec 72 1.60 MBytes [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 92 1.60 MBytes [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 96191 KBytes [ 5] 3.00-4.00 sec
FreeBSD CI Weekly Report 2020-07-26
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-07-26 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-07-20 to 2020-07-26. During this period, we have: * 2211 builds (95.7% (+2.4) passed, 4.3% (-2.4) 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. * 261 test runs (90.8% (+2.8) passed, 8.8% (-3.2) unstable, 0.4% (+0.4) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 22 doc and www builds (100% (+0) passed) Test case status (on 2020-07-26 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | -- | -- | - | | | head/amd64 | 7872 (+13) | 7782 (+14) | 0 (0) | 90 (-1) | | head/i386 | 7870 (+13) | 7770 (+11) | 0 (0) | 100 (+2) | | 12-STABLE/amd64 | 7619 (+2) | 7562 (+5) | 0 (0) | 57 (-3) | | 12-STABLE/i386 | 7617 (+2) | 7549 (-1) | 0 (0) | 68 (+3) | | 11-STABLE/amd64 | 6912 (0) | 6858 (-3) | 0 (0) | 54 (+3) | | 11-STABLE/i386 | 6910 (0) | 6857 (+3) | 0 (0) | 53 (-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-20200726 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 ``` From kevans@: one of ncurses' scripts that generates box and a bunch of other symbols is shooting blanks with gcc6, however it seems fine on gcc9. ## 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.or
Re: [CFT] Updated devel/valgrind-devel port
On Mon, Jul 27, 2020 at 09:49:57PM -0500, Kyle Evans wrote: > On Fri, Jul 24, 2020 at 3:24 PM Kyle Evans wrote: > > > > Hello! > > > > Just a little bit ago, I committed an update[0] to the valgrind-devel > > port that updates it to Paul Floyd's branch, where he has rebased us > > forward to 3.17.0 and largely fixed valgrind operation on both 12.x > > and -CURRENT. > > > > He's put in significant effort to get the test suite to pass on > > FreeBSD, the status of which is summarized here: > > - https://github.com/paulfloyd/freebsd_valgrind/wiki/Regtest-status > > > > Some outstanding issues: > > - https://github.com/paulfloyd/freebsd_valgrind/issues > > > > Please go forth and test it! > > > > A quick follow-up to note that the new valgrind-devel > (3.17.0.g20200723,1) is reportedly now available on a pkg mirror near > you for all three FreeBSD branches, for your convenience. I have a low prio suggestion for the port. It seems that when valgrind-devel is built on 11, it does not know about newer syscalls. So when this instance of valgrind is run on 12 or HEAD, it is uncapable of handling new libc. Is it possible (without too much efforts) to make valgrind forward-compatible, hopefully just by enabling HEAD syscalls on all builds, instead of limiting it to the target equal to the build system ? ___ 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: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)
[I figured out how it appeared to go faster than USB2.] On 2020-Jul-27, at 20:07, Mark Millard wrote: > On 2020-Jul-27, at 19:07, Mark Millard wrote: > >> On 2020-Jul-27, at 18:44, John-Mark Gurney wrote: >> >>> Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700: On 2020-Jul-27, at 16:43, Mark Millard wrote: > On 2020-Jul-26, at 18:20, John-Mark Gurney wrote: > >> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: >>> For reference for what applying the patch >>> reported (see Hunk #14): >> >> Ok, updated it to be relative to r363583... >> >> I had made a white spcae commit to if_ure.c, but hadn't made the >> patch relative to it after that commit.. should work now.. > > I updated an old PowerMac G5 (2 sockets/2 cores each) to > head -r363590 with the update patch and tjen plugged in the > USB EtherNet device. The result (extracted from dmesg -a) > was: > > usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > ugen2.2: at usbus2 (disconnected) > uhub_reattach_port: could not allocate new device > > Unfortunately, I'd not tried a PowerMac with the type of > device before the update. I do not know if the above is > new behavior or not. > > The PowerMac is big-endian, which is what got me to think > about trying it there. The PowerMac is also 64-bit running > a 64-bit FreeBSD. Its USB is 2.0. > > (It also has 2 GigaBit EtherNet ports of its own so I'm not > likely to use a USB device outside special testing.) > I tried what normally shows as an axge0, but trying on the PowerMac G5. It got the same sort of messages as above. The problem does not seem to be tied to your patch. It does prevent my testing the patch on the G5. >>> >>> Yeah, I was going to say that the above messages are before any of >>> may changes get run, so it's unlikely a problem w/ my patch... >>> If the USB device can't get an address on the bus, then it can't >>> even ask what type of device it is to load the driver. >>> >>> Thanks for trying though, maybe someone on the -powerpc list knows >>> of a fix for that. >>> >> >> Turns out that having: >> >> hw.usb.xhci.use_polling=1 >> >> in /boot/loader.conf allowed the old PowerMac context to >> get: >> >> ugen2.2: at usbus2 >> ure0 numa-domain 0 on uhub2 >> ure0: on >> usbus2 >> miibus2: numa-domain 0 on ure0 >> rgephy0: PHY 0 on miibus2 >> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseT-FDX, 1000baseT-FDX-master, auto >> ue0: on ure0 >> ue0: Ethernet address: ### >> ue0: link state changed to DOWN >> >> and: >> >> ue0: flags=8843 metric 0 mtu 1500 >> >> options=68009b >> ether ### >> inet 192.168.1.149 netmask 0xff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> nd6 options=29 >> >> So, with that context, . . . >> (the two directions are widely mismatched) >> >> . . . > > The above is very odd for USB2 since USB2 is limited to > 480Mbits/sec, if I understand right. May be it is a mode > of use that is not getting data to send from USB > regularly at all, say internally generated data or > constant/repeated data only loaded from USB once? > > If yes, then comparing to receiving is not useful and > it need not be useful for comparing to data that does > come from USB transfers. > > I suppose another possibility is that it is an error > that it appears to be going as fast as it appears > above. I isolated the problem: it was not really using 192.168.1.149, but instead 192.168.1.145 (the builtin bge0). This is despite the -N and what the output reported. FYI: bge0: flags=8843 metric 0 mtu 1500 options=8009b ### inet 192.168.1.145 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=23 ue0: flags=8843 metric 0 mtu 1500 options=68009b ### inet 192.168.1.149 netmask 0xff
Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)
On 2020-Jul-27, at 19:07, Mark Millard wrote: > On 2020-Jul-27, at 18:44, John-Mark Gurney wrote: > >> Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700: >>> On 2020-Jul-27, at 16:43, Mark Millard wrote: >>> On 2020-Jul-26, at 18:20, John-Mark Gurney wrote: > Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: >> For reference for what applying the patch >> reported (see Hunk #14): > > Ok, updated it to be relative to r363583... > > I had made a white spcae commit to if_ure.c, but hadn't made the > patch relative to it after that commit.. should work now.. I updated an old PowerMac G5 (2 sockets/2 cores each) to head -r363590 with the update patch and tjen plugged in the USB EtherNet device. The result (extracted from dmesg -a) was: usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen2.2: at usbus2 (disconnected) uhub_reattach_port: could not allocate new device Unfortunately, I'd not tried a PowerMac with the type of device before the update. I do not know if the above is new behavior or not. The PowerMac is big-endian, which is what got me to think about trying it there. The PowerMac is also 64-bit running a 64-bit FreeBSD. Its USB is 2.0. (It also has 2 GigaBit EtherNet ports of its own so I'm not likely to use a USB device outside special testing.) >>> >>> I tried what normally shows as an axge0, but >>> trying on the PowerMac G5. It got the same sort >>> of messages as above. The problem does not seem >>> to be tied to your patch. >>> >>> It does prevent my testing the patch on the G5. >> >> Yeah, I was going to say that the above messages are before any of >> may changes get run, so it's unlikely a problem w/ my patch... >> If the USB device can't get an address on the bus, then it can't >> even ask what type of device it is to load the driver. >> >> Thanks for trying though, maybe someone on the -powerpc list knows >> of a fix for that. >> > > Turns out that having: > > hw.usb.xhci.use_polling=1 > > in /boot/loader.conf allowed the old PowerMac context to > get: > > ugen2.2: at usbus2 > ure0 numa-domain 0 on uhub2 > ure0: on > usbus2 > miibus2: numa-domain 0 on ure0 > rgephy0: PHY 0 on miibus2 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT-FDX, 1000baseT-FDX-master, auto > ue0: on ure0 > ue0: Ethernet address: ### > ue0: link state changed to DOWN > > and: > > ue0: flags=8843 metric 0 mtu 1500 > > options=68009b > ether ### > inet 192.168.1.149 netmask 0xff00 broadcast 192.168.1.255 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > > So, with that context, . . . > (the two directions are widely mismatched) > > # iperf3 -c 192.168.1.120 -B 192.168.1.149 --get-server-output > Connecting to host 192.168.1.120, port 5201 > [ 5] local 192.168.1.149 port 31020 connected to 192.168.1.120 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 113 MBytes 949 Mbits/sec 12564 KBytes > [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 98549 KBytes > [ 5] 2.00-3.00 sec 113 MBytes 944 Mbits/sec 94 1.06 MBytes > [ 5] 3.00-4.00 sec 112 MBytes 942 Mbits/sec 96719 KBytes > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 98883 KBytes > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 93439 KBytes > [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 93221 KBytes > [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 96419 KBytes > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 94632 KBytes > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 97175 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 871 sender > [ 5] 0.00
