Re: proposed cpuctl modification
Hello.
I'm sorry for the late of this reply. I was busy for a few weeks.
On 2023/03/03 6:59, Robert Elz wrote:
> This message is about a proposed userland modification, but it seems
> more kernelish to me, hence I am asking here on tech-kern, rather than
> on tech-userlevel
>
> When my system boots (intel cpu) it runs the intel-microcode (from pkgsrc)
> microcode update.
>
> Since it is an Intel cpu, that means running the ioctl to perform the
> microcode update on every core. The cpu has hyperthreading, and while
> I sometimes am inclined to turn that off, I haven't so far.
>
> Naturally, as they're really the same core, while the base core ucode
> update works fine, the hyperthread companion always fails, as there the
> microcode is already up to the expected version (surprise surprise, since
> we just did that).I guess we could look and skip the update on
> the hyperthread companion cores (pseudo-cores) but that's not what I am
> proposing, partly because I'd have to work out how to do that, but also
> because that by itself would only solve half the problem.
>
> My processor also has 8 cores, with no hyperthreading, where it looks as
> if internally, there's just 2 sets of ucode, one for the first 4, and one
> for the second 4.
Alder Lake-N? 4 E-cores share one microcode image. I have i7-12700 and it
has 4 E-cores. Those 4 cores share one microcode image.
> Updates of the other 3 of each group find the ucode
> version already installed, and error out.
>
> So, what I am proposing is to have cpuctl simply ignore EEXIST errors from
> the update the microcode" ioctl. unless the -v option (which already exists)
> is given.
>
> Note that this isn't fixing any real problem - everything works as it is now,
> and everything (from what I can tell) gets updated correctly. The issue is
> more cosmetic - the ucode update currently issues error messages for more than
> half of my (apparent) cores, which looks ugly during the boot process, and
> could lead to people wondering if there is a problem.
I think your idea is the best. Thank you for your commit.
Another solutions is that the kernel returns 0 instead of EEXIST if the
version number is the same as the running microcode's version. I think it's not
good because it hides the information that the running micocode is the latest.
> When I first installed the package from pgksrc to make this happen (a while
> ago now) I immediately disabled it (in rc.conf) so it ran no more, as the
> microcode version offered by the package was what my CPU came equipped with,
> and every core complained about the version not actually being updated.
>
> pkgsrc was updated to a newer version, with newer microcode, I installed
> that, and enabled it again - and now I'm stuck with the ugly errors.
>
> Perhaps someone has a better solution than this, perhaps checking which
> microcode version is installed on each core, and not attemmpting to install
> the update if it is the same version, but that's beyond my knowledge.
> It also seems likely to me that it is simpler to just install anyway, and
> ignore the "already there" error if it happens. Probably.
I agree with you. Since we do not know what kind of sharing scheme future
CPUs will have, I think simple is the best.
Thanks.
> My proposed patch is appended - it builds, installs, and seems to work
> just fine (not too much of a surprise, it is a trivial change).
>
> Opinions?
>
> kre
>
> Index: cpuctl.8
> ===
> RCS file: /cvsroot/src/usr.sbin/cpuctl/cpuctl.8,v
> retrieving revision 1.20
> diff -u -r1.20 cpuctl.8
> --- cpuctl.8 17 May 2019 23:51:35 - 1.20
> +++ cpuctl.8 2 Mar 2023 21:36:06 -
> @@ -72,6 +72,10 @@
> .Op Ar file
> .Xc
> This applies the microcode patch to CPUs.
> +Unless
> +.Fl v
> +was given, errors indicating that the microcode
> +already exists on the CPU in question are ignored.
> If
> .Ar cpu
> is not specified or \-1, all CPUs are updated.
> Index: cpuctl.c
> ===
> RCS file: /cvsroot/src/usr.sbin/cpuctl/cpuctl.c,v
> retrieving revision 1.32
> diff -u -r1.32 cpuctl.c
> --- cpuctl.c 1 Feb 2022 10:45:02 - 1.32
> +++ cpuctl.c 2 Mar 2023 21:36:06 -
> @@ -247,7 +247,7 @@
> cpuset_destroy(cpuset);
> }
> error = ioctl(fd, IOC_CPU_UCODE_APPLY, &uc);
> - if (error < 0) {
> + if (error < 0 && (verbose || errno != EEXIST)) {
> if (uc.fwname[0])
> err(EXIT_FAILURE, "%s", uc.fwname);
> else
>
>
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
Re: building 9.1 kernel with /usr/src elsewhere?
>> Does it make a difference if you set >> NETBSDSRCDIR=/home/abcxyz/netbsd-9.1/usr/src when you run make? > Yes, that appears to make the symptom go away. Also, I can reproduce the problem by setting NETBSDSRCDIR=/infibulated/gonkulator when running make depend even with a source tree in /usr/src. Is this enough of a bug that it's worth sending-pr? Or is this a case of me expecting something that's no longer supported to work? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: building 9.1 kernel with /usr/src elsewhere?
> Date: Wed, 8 Mar 2023 08:58:47 -0500 (EST)
> From: Mouse
>
> Ugh, I hate using build.sh for small things like individual kernels.
> It always (well, far too often, at least) insists on rebuilding make,
> which takes significant time on some machines, like my shark, and
> requires extra writable filesystem space. If there's a reasonably easy
> way to avoid it, I prefer to.
You could just cross-build on a modern machine for your shark...
> I don't squawk much about build.sh because it does bring benefits; the
> biggest one I notice is probably painless cross-compiles. But I'd
> never run into this price before. 5.2 doesn't exhibit the misbehaviour
> at all, so I couldn't've noticed it except at work, and I think I've
> never tried to build a kernel without /usr/src in place before (at work
> or not).
> [...]
> > The problem is that NETBSDSRCDIR cannot be inferred for a randomly
> > located kernel builddir and sys/lib/libkern/Makefile.compiler-rt uses
> > it.
>
> In that case, maybe config(1) should write a suitable setting of
> NETBSDSRCDIR into the Makefile it generates? At least when -s is given
> with an absolute path?
It does put `S=/path/to/src/sys' into the kernel makefile, and _most_
of the kernel makefiles are written to use paths relative to $S, but
it looks like some ${NETBSDSRCDIR} has crept in between 5.2 and 9.1.
It probably wouldn't be wrong to make them use $S instead of
${NETBSDSRCDIR}, but you might be the first person to be affected by
this in years.
Re: building 9.1 kernel with /usr/src elsewhere?
Omnibus reply here. Thank you, everyone; I have a better understanding of the actual problem (admittedly that's a low bar, given how little I understood it before) and two different workarounds. [Brian Buhrow] > hello. I regularly build kernels outside of the /usr/src location. But does /usr/src exist at the time? > My technique is to install the source in some location: > /usr/local/netbsd/src-91, for example, then put my configuration file > in: /usr/local/netbsd/src-91/sys/arch//conf/ > Then > cd /usr/local/netbsd/src-91/sys/arch//conf > config > cd ../compile/ > make -j 4 >& make.log I'd prefer to avoid assuming the user who wants to build the kernel can write into the source directory tree. You may note the source tree was (admittedly only by implication) owned by abcxyz but I was doing the build as mouse. That said, this does appear to work. (Well, I didn't use -j, but then, I practically never do, and the machine I'm doing this on is single-core.) I didn't wait for the whole build, but it doesn't fail fast the way the run that prompted my mail did. [Taylor R Campbell] > Does it make a difference if you set > NETBSDSRCDIR=/home/abcxyz/netbsd-9.1/usr/src when you run make? Yes, that appears to make the symptom go away. (I probably would not have stumbled across that; /usr/src/BUILDING mentions NETBSDSRCDIR only twice, neither time documenting it, only mentioning it in examples. It likely would have taken enough digging to locate the actual culprit for me to discover it. But still, it does seem to work.) > I always build out of my home directory, never /usr/src, but I also > always use build.sh and the make wrapper it creates [...] Ugh, I hate using build.sh for small things like individual kernels. It always (well, far too often, at least) insists on rebuilding make, which takes significant time on some machines, like my shark, and requires extra writable filesystem space. If there's a reasonably easy way to avoid it, I prefer to. That said, if NetBSD wants to desupport building even kernels without using build.sh, that's its choice; what I think of it does't matter. (But I do think that, in that case, config(1) should be documented as an internal tool, not intended for use other than by build.sh.) [Johnny Billquist] > You should build the kernel using build.sh, [...] See above. > Don't try to make things complicated by doing all that stuff by hand. > :-) build.sh _is_ the complicated way, to me. It's a large, complex, and slow tool I find even less understandable than config(1) and make(1). It also has way too much "when we want your opinion we'll give it to you" for my taste. Which I suppose is just another way of saying that NetBSD, having lost interest in users like me, is moving even farther in that same direction. Sic transit gloria mundi. I don't squawk much about build.sh because it does bring benefits; the biggest one I notice is probably painless cross-compiles. But I'd never run into this price before. 5.2 doesn't exhibit the misbehaviour at all, so I couldn't've noticed it except at work, and I think I've never tried to build a kernel without /usr/src in place before (at work or not). [matthew green] >> make[1]: don't know how to make absvdi2.c. Stop > what happens if you run "make USETOOLS=no"? Fast failure, superficially looking like the same one. [Valery Ushakov] > Mail-Followup-To: matthew green , > Mouse , tech-kern@netbsd.org Um, why would you think I'd want people to mail followups to _me_? I would prefer - though admittedly it's a weak preference, weak enough I practically never mention it - that people _not_ mail me when they're already sending to the list. > The problem is that NETBSDSRCDIR cannot be inferred for a randomly > located kernel builddir and sys/lib/libkern/Makefile.compiler-rt uses > it. In that case, maybe config(1) should write a suitable setting of NETBSDSRCDIR into the Makefile it generates? At least when -s is given with an absolute path? > Our makefile spaghetti is a bit out of control. I've felt so often enough myself. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: building 9.1 kernel with /usr/src elsewhere?
On Wed, Mar 08, 2023 at 15:22:11 +1100, matthew green wrote:
> > This completed apparently normally, reporting the build directory and
> > telling me to remember to make depend. I then went to ~/kbuild/GEN91
> > and ran make depend && make. It failed fast - no more than a second or
> > two - with
> >
> > make[1]: don't know how to make absvdi2.c. Stop
>
> what happens if you run "make USETOOLS=no"?
That's orthogonal. The problem is that NETBSDSRCDIR cannot be
inferred for a randomly located kernel builddir and
sys/lib/libkern/Makefile.compiler-rt uses it. I don't know enough
about sys Makefiles, but may be using $S instead of
${NETBSDSRCDIR}/sys will just fix it. But may be will also break
something else. Our makefile spaghetti is a bit out of control.
-uwe
