Re: Running FreeBSD on M.2 SSD
On Wed, Feb 26, 2020, 8:54 PM Mario Olofo wrote: > Hello Mark, > > Yes, I think that it's related to the WD Green SSD. > Today I found this bug on FreeBSD's bugzilla: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225666 > > Tried to reinstall and recompile the kernel with the patch but it didn't > work, I continue to see corrupted data. > I think that the only way to be really sure about the corrupted data is to > reinstall again but already boot with the quirks configured, but the > kern.cam.ada.X.quirks don't seems to exists on FreeBSD 12, > so I have a probability of corruption between installation and compilation > of the patched kernel... > > Don't know what more to do... > What happens if you disable TRIM? Warner > > Mario > > Em qua., 26 de fev. de 2020 às 20:48, Mark Linimon > escreveu: > > > On Tue, Feb 25, 2020 at 08:18:51PM -0300, Mario Olofo wrote: > > > the ZFS already shows corrupted data... > > > > Although this may have already been stated in the thread and I missed it, > > I have not had similar problems with the NVME chips I have used (first an > > HP, and now a Samsung). I am really starting to wonder if this is > > hardware- > > specific. > > > > mcl > > > ___ > 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-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: Running FreeBSD on M.2 SSD
Hello Mark, Yes, I think that it's related to the WD Green SSD. Today I found this bug on FreeBSD's bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225666 Tried to reinstall and recompile the kernel with the patch but it didn't work, I continue to see corrupted data. I think that the only way to be really sure about the corrupted data is to reinstall again but already boot with the quirks configured, but the kern.cam.ada.X.quirks don't seems to exists on FreeBSD 12, so I have a probability of corruption between installation and compilation of the patched kernel... Don't know what more to do... Mario Em qua., 26 de fev. de 2020 às 20:48, Mark Linimon escreveu: > On Tue, Feb 25, 2020 at 08:18:51PM -0300, Mario Olofo wrote: > > the ZFS already shows corrupted data... > > Although this may have already been stated in the thread and I missed it, > I have not had similar problems with the NVME chips I have used (first an > HP, and now a Samsung). I am really starting to wonder if this is > hardware- > specific. > > mcl > ___ 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: ntp problems stratum 2 to 14?
On 2020-Feb-26 16:37:43 +1100, Dewayne Geraghty
wrote:
>I usually run ntpd with both aslr and as user ntpd. While testing I
>noticed that my server with a direct network cable to my main time keeper,
>jumped from the expected stratum 2 to 14 as follows (I record the date so I
>can synch with the debug log, also below):
>
>vm.loadavg={ 0.09 0.10 0.18 }
>
>Wed 26 Feb 2020 15:16:38 AEDT
> remote refid st t when poll reach delay offset
> jitter
>==
> 10.0.7.6203.35.83.2422 u 44 64 3770.147 -227.12 33.560
>*127.127.1.1 .LOCL. 14 l 59 128 3770.0000.000 0.000
>26 Feb 15:03:40 ntpd[8772]: LOCAL(1) 901a 8a sys_peer <== bad
Why is this bad? You've specified that this is a valid clock source so
ntpd is free to use it if it decides it is the best source of time.
>server 127.127.1.1 minpoll 7 maxpoll 7
>fudge 127.127.1.1 stratum 14
Synchronizing to the local clock (ie using 127.127.1.x as a reference) is
almost never correct. What external (to NTP) source is being used to
synchronize the local clock?
>I'm also very surprised that the jitter on the server (under testing) is so
>poor. The internet facing time server is
>*x.y.z.t .ATOM. 1 u 73 5127 23.776 34.905 95.961
>but its very old and not running aslr.
The 23ms distance to the peer suggests that this is over the Internet. What
sort of link do you have to the Internet and how heavily loaded is it? The
NTP protocol includes the assumption that the client-server path delay is
symmetric - this is often untrue for SOHO connections. And SOHO connections
will often wind up saturated in one direction - which skews the apparent
timestamps and shows up as high jitter values.
> /usr/local/sbin/ntpd -c /etc/ntp.conf -g -g -u ntpd --nofork
...
>I get similar results with /usr/sbin/ntpd, I've been testing both and
>happened to record details for the port ntpd.
It's probably not relevant but it would be useful for you to say up front
which ntpd you are having problems with and which version of the port you
have installed.
--
Peter Jeremy
signature.asc
Description: PGP signature
FreeBSD CI Weekly Report 2020-02-23
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-02-23 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-02-17 to 2020-02-23. During this period, we have: * 1969 builds (87.7% (-3.0) passed, 12.3% (+3.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. * 307 test runs (66.8% (+6.7) passed, 30.3% (+0.8) unstable, 2.9% (-7.5) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 50 doc and www builds (96% (-3.0) passed, 4.0% (+3.0) failed) Test case status (on 2020-02-23 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | -- | -- | -- | --- | | head/amd64 | 7699 (-39) | 7601 (-45) | 6 (+6) | 92 (0) | | head/i386 | 7697 (-39) | 7593 (-47) | 6 (+6) | 98 (+2) | | 12-STABLE/amd64 | 7501 (-42) | 7444 (-50) | 0 (0) | 57 (+8) | | 12-STABLE/i386 | 7499 (-42) | 7450 (-34) | 0 (0) | 49 (-8) | | 11-STABLE/amd64 | 6878 (+7) | 6831 (+7) | 0 (0) | 47 (0) | | 11-STABLE/i386 | 6876 (+7) | 6824 (+4) | 0 (0) | 52 (+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-20200223 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## News * FreeBSD-head-sparc64-build has been disabled since 2020-02-20 * Default amd64 GCC build job has been swtich to https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build which uses devel/amd64-gcc6, https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build uses devel/amd64-gcc has been deprecated. ## Failed and Fixed tests * sys.file.flock_test.main panics kernel after [r358153, r358170] https://bugs.freebsd.org/244250 ## Regressions * fusefs tests fail when mac_bsdextended.ko is loaded https://bugs.freebsd.org/244229 * `dtrace -c` causes program dumps core after somewhere between (r357694, r357701] https://bugs.freebsd.org/244053 * 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)) * (test case) sys.geom.class.multipath.misc.fail_on_error (on 12-STABLE) https://bugs.freebsd.org/244158 ## 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 3670 tests (0), 2290 success (0), 574 failures (0), 806 skipped (0) ## 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 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * 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 *
Re: Forgotten MFC related to if_tuntap
On Wed, Feb 26, 2020 at 2:18 AM Pavel Timofeev wrote: > > Hi, > Looking at 12-STABLE I found that r354060 missed one more change (i. > e. https://svnweb.freebsd.org/base?view=revision=347515 from > HEAD): > Whoops, good catch- fixed in r358331. Thanks! Kyle Evans ___ 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"
Forgotten MFC related to if_tuntap
Hi, Looking at 12-STABLE I found that r354060 missed one more change (i. e. https://svnweb.freebsd.org/base?view=revision=347515 from HEAD): r347515 | markj | 2019-05-13 04:18:17 +0300 (Mon, 13 May 2019) | 4 lines Catch up with r347241. MFC with: r347241 Index: head/sys/mips/conf/std.AR_MIPS_BASE === --- head/sys/mips/conf/std.AR_MIPS_BASE (revision 347514) +++ head/sys/mips/conf/std.AR_MIPS_BASE (revision 347515) @@ -21,8 +21,8 @@ # .. And no sysctl strings optionsNO_SYSCTL_DESCR -makeoptionsMODULES_OVERRIDE+="gpio ar71xx if_gif if_vlan if_gre if_tap" -makeoptionsMODULES_OVERRIDE+="if_tun if_bridge bridgestp usb" +makeoptionsMODULES_OVERRIDE+="gpio ar71xx if_gif if_vlan if_gre if_tuntap" +makeoptionsMODULES_OVERRIDE+="if_bridge bridgestp usb" makeoptionsMODULES_OVERRIDE+="alq" # Random - required during early boot! ___ 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"
