Re: [PATCH] Re: Profiling broken on x86?
On Fri, Jul 08, 2022 at 12:17:25PM +, Emmanuel Dreyfus wrote: > On Fri, Jul 08, 2022 at 11:55:13AM +0200, Manuel Bouyer wrote: > > I think it's more than this; it's to use the right instruction on the > > right CPU. But I don't remember the details > > This tests a CPU features at boot time, and replaces a generic implementation > by a CPU-optimized one. > > Indeed it brings maximum performance because there is no CPU feature test > at runtime, but it comes with a price. Profilig and debugging are broken, > for instance. that's not the only story. See the Opteron workaround for example. It enables SMAP if available, too. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: [PATCH] Re: Profiling broken on x86?
On Fri, Jul 08, 2022 at 11:55:13AM +0200, Manuel Bouyer wrote: > I think it's more than this; it's to use the right instruction on the > right CPU. But I don't remember the details This tests a CPU features at boot time, and replaces a generic implementation by a CPU-optimized one. Indeed it brings maximum performance because there is no CPU feature test at runtime, but it comes with a price. Profilig and debugging are broken, for instance. -- Emmanuel Dreyfus m...@netbsd.org
Re: questions about undocumented USB drivers
On Fri, Jul 08, 2022 at 09:18:47AM +, nia wrote: > I'd like to know more about these drivers so I can write man pages > for them, so any input is welcome. > ~ ~ > sys/dev/usb/slurm.c > > This one caught my eye because it doesn't have the "u" prefix. > Log message, from jakllsch@ in 2013: > "Add slurm(4), a radio(4) driver for USB FM radio modules based > on the Silicon Labs reference design." > I can get a rough idea of the driver's capabilities by reading > the code. It seems much better than udsbr(4), the only USB > radio(4) driver we do document. I'm somewhat of the belief that the 'u' prefix denotes a USB "class device" driver; and there's no USB class number or specification for these devices, and as such the 'u' prefix isn't strongly suggested. Plus, that reasoning allowed me to make a reference to pop culture. The hardware I developed against is an Instant FM Music, model RDX-155, from ADS Tech. I still have it around. A slurm(4) page should reference uaudio(4), as there's always/often no other way to get the audio signal out of the device.
Re: [PATCH] Re: Profiling broken on x86?
On Fri, Jul 08, 2022 at 09:10:54AM +, Emmanuel Dreyfus wrote: > On Thu, Jul 07, 2022 at 12:53:33AM +, Emmanuel Dreyfus wrote: > > This is NetBSD 9.2_STABLE on amd64. If the kernel is built with > > profiling (either config -p, or makeoptions PROF="-pg" and options > > GPROF), it crashes at boot with this panic: > > > > panic: patchfunc: sizes do not match (from=0x80f0d720) > > Here is a workaround, but perhaps the concept of patching the > binary is to be questioned. Is it just to save the performance > of a boolean test? I think it's more than this; it's to use the right instruction on the right CPU. But I don't remember the details -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
questions about undocumented USB drivers
I'd like to know more about these drivers so I can write man pages for them, so any input is welcome. sys/dev/usb/udsir.c Committed in 2013 by kiyohara@, log message was "Add KingSun/DonShine IRDA dongle." However, the copyright is 2001 dsainty@, perhaps copypasted from ustir(4)? I think this only supports one type of IRDA dongle and is based on the ustir(4) code. sys/dev/usb/udl.c Driver for DisplayLink DL-1x0/1x5 based USB LCDs and USB-VGA adapters, ported from OpenBSD, easy enough. Committed in 2009 by tsutsui@ with a dire message that the MI wscons API isn't yet ready for this device driver. There were a few minor changes to the driver since by nat@, but some kinda nasty hacks remain in the code. Is it usable yet? It sounds interesting :) sys/dev/usb/slurm.c This one caught my eye because it doesn't have the "u" prefix. Log message, from jakllsch@ in 2013: "Add slurm(4), a radio(4) driver for USB FM radio modules based on the Silicon Labs reference design." I can get a rough idea of the driver's capabilities by reading the code. It seems much better than udsbr(4), the only USB radio(4) driver we do document.
[PATCH] Re: Profiling broken on x86?
On Thu, Jul 07, 2022 at 12:53:33AM +, Emmanuel Dreyfus wrote: > This is NetBSD 9.2_STABLE on amd64. If the kernel is built with > profiling (either config -p, or makeoptions PROF="-pg" and options > GPROF), it crashes at boot with this panic: > > panic: patchfunc: sizes do not match (from=0x80f0d720) Here is a workaround, but perhaps the concept of patching the binary is to be questioned. Is it just to save the performance of a boolean test? --- sys/arch/x86/x86/cpu.c 2 Aug 2020 07:33:38 - 1.171.2.3 +++ sys/arch/x86/x86/cpu.c 8 Jul 2022 09:08:04 - @@ -68,8 +68,9 @@ #include "opt_mpbios.h"/* for MPDEBUG */ #include "opt_mtrr.h" #include "opt_multiprocessor.h" #include "opt_svs.h" +#include "opt_gprof.h" #include "lapic.h" #include "ioapic.h" @@ -700,9 +701,9 @@ struct cpu_info *ci; kcpuset_t *cpus; u_long i; -#ifndef XEN +#if !defined(XEN) && !defined(GPROF) /* Now that we know the number of CPUs, patch the text segment. */ x86_patch(false); #endif -- Emmanuel Dreyfus m...@netbsd.org
