Re: Cannot find announcement that min supported i386 CPU is now i686
15.09.2020 9:42, Eugene Grosbein wrote: >> I tried that on my workstation (dual Xeon, lots of RAM) but couldn't get >> it to compile for i586 - various things kept bailing out. Note that I use multiple WITHOUT_XXX knobs documented in src.conf(5) to decrease both build time and size of resulting image, maybe some excluded code really has problems for i386, can't tell. For CONF_BUILD (addition to src.conf for buildworld): WITHOUT_KERNEL_SYMBOLS= WITHOUT_DEBUG_FILES= WITHOUT_TESTS= MODULES_WITH_WORLD= WITHOUT_ACCT= WITHOUT_AMD= WITHOUT_APM= WITHOUT_ASSERT_DEBUG= WITHOUT_ATM= WITHOUT_AUDIT= WITHOUT_AUTHPH= WITHOUT_AUTOFS= WITHOUT_BHYVE= WITHOUT_BOOTPARAMD= WITHOUT_BOOTPD= WITHOUT_BSDINSTALL= WITHOUT_BSNMP= WITHOUT_CALENDAR= WITHOUT_CCD= #WITHOUT_CDDL= WITHOUT_CLANG_FULL= WITHOUT_CPP= WITHOUT_CTM= WITHOUT_DEBUG_FILES= WITHOUT_DICT= WITHOUT_EXAMPLES= WITHOUT_FLOPPY= WITHOUT_FREEBSD_UPDATE= WITHOUT_GAMES= WITHOUT_GCOV= WITHOUT_GDB= WITHOUT_GROFF= WITHOUT_HAST= WITGOUT_HESIOD= WITHOUT_HTML= WITHOUT_HYPERV= WITHOUT_IPFILTER= WITHOUT_IPX= WITHOUT_ISCSI= WITHOUT_JAIL= WITHOUT_KERNEL_SYMBOLS= WITHOUT_LLDB= WITHOUT_LLVM_TARGET_ALL= WITH_LLVM_TARGET_X86= WITHOUT_LOCATE= WITHOUT_LS_COLORS= WITHOUT_MAN= WITH_MAN_UTILS= WITHOUT_NCP= WITHOUT_NDIS= WITHOUT_NETCAT= WITHOUT_NIS= WITHOUT_NLS= WITHOUT_NLS_CATALOGS= WITHOUT_NS_CACHING= WITH_OPENSSH_NONE_CIPHER= WITHOUT_PC_SYSINSTALL= WITHOUT_PF= WITHOUT_PKGTOOLS= WITHOUT_PMC= WITHOUT_PORTSNAP= WITHOUT_PPP= WITHOUT_PROFILE= WITHOUT_QUOTAS= WITHOUT_RBOOTD= WITHOUT_RCS= WITHOUT_RESCUE= WITHOUT_ROUTED= WITHOUT_SHAREDOCS= WITHOUT_SVNLITE= WITHOUT_TALK= WITHOUT_SYSINSTALL= WITHOUT_TESTS= WITHOUT_TEXTPROC= WITHOUT_TIMED= WITHOUT_VT= MODULES_OVERRIDE=cryptodev zfs opensolaris And: CONF_INSTALL=" $CONF_BUILD WITHOUT_BINUTILS= WITHOUT_CLANG= WITHOUT_CLANG_FULL= WITHOUT_CXX= WITHOUT_TOOLCHAIN= WITHOUT_INSTALLLIB= " >> It would compile i386 for i686, but not i586. Have you tried it with 11.4? Not sure what you meant here. ARCH may be i386 (32 bit) or amd64 (64 bit), however i586 is not a name for ARCH but for CPUTYPE only (not same thing). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot find announcement that min supported i386 CPU is now i686
14.09.2020 12:08, Charles Lecklider via freebsd-stable wrote: > On 2020-09-14 04:41, Eugene Grosbein wrote: >> Build time for modern FreeBSD version is too gross and needs way too much >> memory, >> so I stopped building image for my i586 hardware "in place" quite long ago. > > It would take about a week to compile, but since it was stable <11.4 I > didn't really care. > >> I use my i7-based desktop to build NanoBSD image for its upgrade, it works >> just fine >> by default setting ARCH/TARGET_ARCH to i386 and correct CPUTYPE. > > I tried that on my workstation (dual Xeon, lots of RAM) but couldn't get > it to compile for i586 - various things kept bailing out. It would > compile i386 for i686, but not i586. Have you tried it with 11.4? Just updated that my i586 AMD Geode system upto latest 11.4-STABLE, all went OK. I build it with standard nanobsd(8) utility in base system, my build configuration contains: NANO_PMAKE="make -j3" NANO_KERNEL=GWOLD CONF_BUILD=' TARGET=i386 TARGET_ARCH=i386 NANO_ARCH=i386 CPUTYPE?=k6-3 ... ' And kernel configuration has: machine i386 cpu I586_CPU cpu I686_CPU options CPU_GEODE options CPU_SOEKRIS options SCHED_4BSD ... For UP system, I find SCHED_4BSD behave better than default SCHED_ULE. >>> Don't try -Os or -Oz (which really do help on a real i586) - ZFS will >>> wedge quickly. >> >> Currently i586-class CPU needs as many speed improvements as possible >> and I was told that -Os might drop performance comparing with -O2, >> so why bother? > > It depends on your workload. This machine spends most of its life > running rsync over ssh, so having more useful code in L2 cache makes a > difference even if it takes a few more clock cycles to run. The > bottleneck is IO - mainly disc, but also network (way better with > polling - don't know why it's not in GENERIC) so those extra clock > cycles aren't as important. > > If you're doing real number-crunching stuff with it, a) why?!, Isn't ssh encryption/decryption "real" number-crunching? My i586 system did IPSec encryption for tunnels and despite of having AES-CBC-128 onboard hardware accelerator suitable for IPSec, it was quite limited by CPU horsepower, so I used hmac-md5 instead of SHA variants to speed-up things a bit and still, it was able to saturate 100Mbps with unencrypted PPPoE+ipfw nat but only 33Mbps with IPSec AES+MD5 and less with SHA. > and b) yes, -O2 would be better. > >>> 11.4 i386 doesn't honour `vfs.zfs.arc_max` in any meaningful way >>> resulting in one of the `find`s in periodic security wedging ZFS. >> >> Been there, seen that. The problem pre-dates 11.x series and appeared in >> 10.x. >> It was much better in times of 9.x, though. > > Yes, I've also seen it before, but 11.4 is particularly egregious with > its disregard on i386 - amd64 is behaving itself on everything I've tried. > >>> options KSTACK_PAGES=4 >> >> This is default for 12.x/i386 but was not merged to stable/11. > > That's good to know. > >> You might find useful these also: >> >> vfs.zfs.vdev.cache.size="8M" >> vfs.zfs.prefetch_disable="1" > > Prefetch is disabled on i386 by default; I played with the vdev cache > size too but it made no discernable difference. > >> And for kernel config: >> >> options KVA_PAGES=512 >> >> This makes ZFS more stable giving it bigger kernel virtual area with less >> utilization for it. > > Yes, that's the theory, but when I tried it on earlier versions the > kernel would just blow up on boot. I may try it again next time I update > the kernel. It worked for me with KVA_PAGES=768 even, so kernel and ZFS had 3GB for virtual area and only 1GB for userland but that was i386 virtual machine with 512M or 1GB RAM only (cheapest hoster provided some years ago), so 1GB for userland was just fine :-) >>> TL;DR: I'd avoid 11.4 i386 as it doesn't appear to have been tested on >>> i486/i586 at all. >> >> Finally I gave up running ZFS for vmem-contrained systems, >> e.g. I moved my i386 virtual machines that benefit from ZFS compression to >> amd64. > > Oh, sure - I'd never dream of doing anything fancy with ZFS on this > machine - it just does backups. > > My point was that 11.4 doesn't "feel" right - it doesn't seem to have > been tested on of FreeBSD since 2.x - some "feel" right, some "feel" dodgy (5.3, 6.x, > some 8.x IIRC). On amd64 it "feels" great, but I don't really trust it > on i386. Can't see any difference with early 11.x versions but I build it all by myself for many major releases. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
CFT: update to if_ure driver
Hello, I have committed an update to the ure driver on the stable/11 branch. I don't have any 8152 devices to test with, so I'd greatly appreciate any feedback on if this works or doesn't work. Also, if you have a spare 8152 that you could part with and send to me, it'd make testing changes like these easier. On stable/11, 8153 devices are attached via the cdce devices, and so will not be affected by this change. - Forwarded message from John-Mark Gurney - Date: Tue, 15 Sep 2020 00:22:30 + (UTC) From: John-Mark Gurney To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-sta...@freebsd.org, svn-src-stable...@freebsd.org Subject: svn commit: r365738 - stable/11/sys/dev/usb/net Author: jmg Date: Tue Sep 15 00:22:30 2020 New Revision: 365738 URL: https://svnweb.freebsd.org/changeset/base/365738 Log: MFC r365623: Don't clear reserved bits per RealTek This is a direct commit as the driver is significantly different. Modified: stable/11/sys/dev/usb/net/if_ure.c Modified: stable/11/sys/dev/usb/net/if_ure.c == --- stable/11/sys/dev/usb/net/if_ure.c Mon Sep 14 23:51:14 2020 (r365737) +++ stable/11/sys/dev/usb/net/if_ure.c Tue Sep 15 00:22:30 2020 (r365738) @@ -710,7 +710,9 @@ ure_init(struct usb_ether *ue) ~URE_RXDY_GATED_EN); /* Set Rx mode. */ - rxmode = URE_RCR_APM; + rxmode = ure_read_4(sc, URE_PLA_RCR, URE_MCU_TYPE_PLA); + rxmode &= ~URE_RCR_ACPT_ALL; + rxmode |= URE_RCR_APM; /* If we want promiscuous mode, set the allframes bit. */ if (ifp->if_flags & IFF_PROMISC) - End forwarded message - -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD CI Weekly Report 2020-09-13
FreeBSD CI Weekly Report 2020-09-13 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-09-07 to 2020-09-13. During this period, we have: * 2533 builds (94.0% (+2.0) passed, 6.0% (-2.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. * 296 test runs (87.8% (+45.2) passed, 9.8% (-14.7) unstable, 2.4% (-30.5) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 26 doc and www builds (100% passed) Test case status (on 2020-09-13 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | - | - | --- | | head/amd64 | 7881 (+2) | 7791 (+2) | 0 (0) | 90 (0) | | head/i386 | 7879 (+2) | 7771 (+2) | 0 (0) | 108 (0) | | 12-STABLE/amd64 | 7626 (0) | 7569 (+3) | 0 (0) | 57 (-3) | | 12-STABLE/i386 | 7624 (0) | 7556 (0) | 0 (0) | 68 (0) | | 11-STABLE/amd64 | 6912 (0) | 6861 (0) | 0 (0) | 51 (0) | | 11-STABLE/i386 | 6910 (0) | 6857 (0) | 0 (0) | 53 (0) | (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-20200913 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/ There are still mutiple errors when building with gcc6, error log available at https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/lastCompletedBuild/console See also: https://lists.freebsd.org/pipermail/svn-src-all/2020-September/202307.html ## 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 Needs to check if llvm11 import fixes this. * 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 committed as https://svnweb.freebsd.org/changeset/base/364220 , needs more verification. * lib.libbe.be_create.* and sbin.bectl.bectl_test.* https://bugs.freebsd.org/249055 & https://bugs.freebsd.org/249229 OpenZFS' zfs.ko can't be loaded in non-64bit platforms ## 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 * common.ip.t_dtrace_contrib.tst_ipv4localsctp_ksh * common.ip.t_dtrace_contrib.tst_localsctpstate_ksh * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * Total 681 tests, 524 success, 47 failures, 110 skipped, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3749 tests, 2289 success, 647 failures, 813 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 Workaround committed and need to verify. * 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 *
