Re: atkbd_timeout() period?
On Wed, Jan 5, 2022 at 9:39 AM Warner Losh wrote: > > > On Tue, Jan 4, 2022 at 10:42 PM Alexander Motin wrote: > >> Hi, >> >> As I see, one of the most active threaded callouts on idle VMware VM and >> some hardware is atkbd_timeout(), called 10 times per second. Plus it >> is also one of few remaining non-MP-safe callouts. According to the >> comment it seems to be only a workaround for some lost interrupts. That >> makes me thing: is it really needed to run so often and so accurate, or >> may be we could reduce it to 1-2 times per second? Or may be it can be >> avoided somehow 20 years later? >> > > Yea, we can likely just trash it and wait for people to complain about the > keyboard being hung. I doubt we'll get any complaints because Xaccel 2.1 > was quite a long time ago... It is no longer relevant and the original > conditions > that caused the lost interrupts are likely long gone... > > And if they aren't, we'll get a reproducible test case to judge what the > right workaround > should be. > > Warner > If "10" in " atkbd_timeout(), called 10 times per second " can be defined by a control variable , then it may not be necessary to remove its call , and polling rate may be set with respect to the suitable needs . Mehmet Erol Sanliturk
Re: atkbd_timeout() period?
On Tue, Jan 4, 2022 at 10:42 PM Alexander Motin wrote: > Hi, > > As I see, one of the most active threaded callouts on idle VMware VM and > some hardware is atkbd_timeout(), called 10 times per second. Plus it > is also one of few remaining non-MP-safe callouts. According to the > comment it seems to be only a workaround for some lost interrupts. That > makes me thing: is it really needed to run so often and so accurate, or > may be we could reduce it to 1-2 times per second? Or may be it can be > avoided somehow 20 years later? > Yea, we can likely just trash it and wait for people to complain about the keyboard being hung. I doubt we'll get any complaints because Xaccel 2.1 was quite a long time ago... It is no longer relevant and the original conditions that caused the lost interrupts are likely long gone... And if they aren't, we'll get a reproducible test case to judge what the right workaround should be. Warner
atkbd_timeout() period?
Hi, As I see, one of the most active threaded callouts on idle VMware VM and some hardware is atkbd_timeout(), called 10 times per second. Plus it is also one of few remaining non-MP-safe callouts. According to the comment it seems to be only a workaround for some lost interrupts. That makes me thing: is it really needed to run so often and so accurate, or may be we could reduce it to 1-2 times per second? Or may be it can be avoided somehow 20 years later? -- Alexander Motin
Re: observations on Ryzen 5xxx (Zen 3) processors
Next thing to try is I guess to turn hyperthreading off -- J. signature.asc Description: PGP signature
Re: observations on Ryzen 5xxx (Zen 3) processors
On Tue, Jan 04, 2022 at 07:20:08PM -0500, mike tancsa wrote: I would for sure try a clean src.conf first and use that as a baseline. Also, someome mentioned trying machdep.idle=spin In /boot/loader.conf But removing your src.conf optimizations would be the first place to try Yeah, tried this just now but it made no difference. No src.conf or make.conf and GENERIC (so, as -current, debugging kernel) it's as vanilla as I can make it. Some ports will build (ports-mgmt/dialog4ports) but lang/perl5.32 and devel/llvm13 won't. All the dependencies build - there's a lot of python there too, for llvm. They build and install fine. perl installed as a pkg installs fine. I've not tried it but expect llvm13 to install from pkg fine. They (perl5.32 & llvm13) won't build from ports, though. But they will on a vm of the same version, just a different cpu (xenon) -- J. signature.asc Description: PGP signature
Re: observations on Ryzen 5xxx (Zen 3) processors
On 1/4/2022 11:56 AM, tech-lists wrote: On Tue, Jan 04, 2022 at 02:06:43PM +, tech-lists wrote: Hello, On Wed, Dec 22, 2021 at 02:42:48PM +0200, Andriy Gapon wrote: There have been some reports on strange / unexpected things with Ryzen 5xxx processors. I think I have seen 5950X, 5900X and 5800X mentioned, not sure about others. Thanks for this. I'm evaluating a ryzen 5600G. Here's hwinfo: https://bsd-hardware.info/?probe=e67007df20 I've noticed a couple of oddities: 1. some ports won't build, but world builds and installs just fine (current/14) Can't build lang/perl5.32. I have many vms running perl5.32 and they're not seeing any issues. There's nothing in bugs suggesting there's an issue with this port right now. I would for sure try a clean src.conf first and use that as a baseline. Also, someome mentioned trying machdep.idle=spin In /boot/loader.conf But removing your src.conf optimizations would be the first place to try ---Mike
Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?
Alexander Leidinger wrote: > Rick Macklem wrote: [stuff snipped] > > > > Other than testing diskless NFS root file systems, I do not have a > > strong opinion w.r.t. whether the default should change. > > > > If the default stays as NFSv3, a fallback to NFSv4 could be done, which > > would handle the NFSv4 only server case. (No one uses NFSv2 any more, > > so the fallback to NFSv2 is almost irrelevant, imho.) > > As you particiate in interoperability tests, would it make sense to > check how those other implementations handle this case? I naively > assume you have some contacts or a mailinglist you could use for that. Not sure what you are asking, but... The only other client I am familiar with is the Linux one. It does NFSv4, then NFSv3 (I think they have dropped NFSv2 support). Linux also does handle NFSv4 root file systems. The other clients I know of (VMware and Windows) do not paticipate in the IETF Working group's interoperability testing, unfortunately. (And I have no contact with either of these groups.) rick Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
Re: observations on Ryzen 5xxx (Zen 3) processors
On Tue, Jan 04, 2022 at 02:06:43PM +, tech-lists wrote: Hello, On Wed, Dec 22, 2021 at 02:42:48PM +0200, Andriy Gapon wrote: There have been some reports on strange / unexpected things with Ryzen 5xxx processors. I think I have seen 5950X, 5900X and 5800X mentioned, not sure about others. Thanks for this. I'm evaluating a ryzen 5600G. Here's hwinfo: https://bsd-hardware.info/?probe=e67007df20 I've noticed a couple of oddities: 1. some ports won't build, but world builds and installs just fine (current/14) Can't build lang/perl5.32. I have many vms running perl5.32 and they're not seeing any issues. There's nothing in bugs suggesting there's an issue with this port right now. The context is 14.0-CURRENT #0 main-n252119-dfa5a74357f amd64 1400046 1400046 with a nodebug kernel. The sources were built with these (/etc/src.conf): KERNCONF=RYZEN5 WITH_CCACHE_BUILD="TRUE" CCACHE_PREFIX=/usr/local/bin CPUTYPE?=znver3 TARGET_CPU_ARCH=znver3 WITH_MALLOC_PRODUCTION= WITH_LLVM_TARGET_ALL= WITH_LLVM_BINUTILS= WITH_KERNEL_RETPOLINE= # WITH_PIE=yes WITH_BIND_NOW=yes WITH_RETPOLINE=yes WITH_SSP=yes # WITH_OPENSSL_KTLS= I'm going to try building a new world next, this time with no /etc/src.conf, or a minimal one. But for now, I'm seeing unexpected failures with ports that compile fine on other systems: 1. portstree last updated: Tue Jan 4 17:03:38 2022 +0100 version: 570114 2. no /etc/make.conf 3. in /usr/ports/lang/perl5.32: [i] make clean && make distclean && make rmconfig && make rmconfig-recursive [ii] make MAKE_JOBS_UNSAFE=yes -j1 fails here: 98 warnings generated. cc -pthread -Wl,-E -fstack-protector-strong -L/usr/local/lib -o miniperl opmini.o perlmini.o gv.o toke.o perly.o pad.o regcomp.o d ump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o tim e64.o miniperlmain.o -lpthread -lm -lcrypt -lutil ld: error: undefined symbol: __dtraceenabled_perl___op__entry >>> referenced by perlmini.c >>> perlmini.o:(perl_destruct) >>> referenced by perlmini.c >>> perlmini.o:(perl_destruct) >>> referenced by perlmini.c >>> perlmini.o:(perl_parse) >>> referenced 8 more times ld: error: undefined symbol: __dtrace_perl___sub__entry >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_call) ld: error: undefined symbol: __dtrace_perl___sub__return >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_call) ld: error: undefined symbol: __dtrace_perl___loading__file >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_load) ld: error: undefined symbol: __dtrace_perl___loaded__file >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_load) ld: error: undefined symbol: __dtrace_perl___op__entry >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_op) >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_op) ld: error: undefined symbol: __dtrace_perl___phase__change >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_phase) ld: error: undefined symbol: __dtraceenabled_perl___sub__entry >>> referenced by pp_hot.c >>> pp_hot.o:(Perl_pp_leavesub) >>> referenced by pp_hot.c >>> pp_hot.o:(Perl_pp_entersub) >>> referenced by pp_ctl.c >>> pp_ctl.o:(Perl_cx_popsub) >>> referenced 6 more times cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [lib/buildcustomize.pl] Error code 1 make[2]: stopped in /usr/ports/lang/perl5.32/work/perl-5.32.1 1 error make[2]: stopped in /usr/ports/lang/perl5.32/work/perl-5.32.1 *** [do-build] Error code 1 make[1]: stopped in /usr/ports/lang/perl5.32 1 error make[1]: stopped in /usr/ports/lang/perl5.32 *** [stage] Error code 2 make: stopped in /usr/ports/lang/perl5.32 1 error make: stopped in /usr/ports/lang/perl5.32 -- J. signature.asc Description: PGP signature
Re: observations on Ryzen 5xxx (Zen 3) processors
Hello, On Wed, Dec 22, 2021 at 02:42:48PM +0200, Andriy Gapon wrote: There have been some reports on strange / unexpected things with Ryzen 5xxx processors. I think I have seen 5950X, 5900X and 5800X mentioned, not sure about others. Thanks for this. I'm evaluating a ryzen 5600G. Here's hwinfo: https://bsd-hardware.info/?probe=e67007df20 I've noticed a couple of oddities: 1. some ports won't build, but world builds and installs just fine (current/14) 2. sometimes it "lags" a bit, but am not sure if it's the cpu, the board, the board+cpu, the connection (it's offsite) or all three. Please let me know if there are tests you'd like me to run. -- J. signature.asc Description: PGP signature
