andyf: could you give omnios a bulk build with the code.illumos.org/c/illumos-gate/+/2601 bits? (I'm emailing jperkin the same request, since he needs binaries)

→ CODE REVIEW 2601: 15260 ld crashes if group members are stripped by -s (NEW) | illumos.org/issues/15260

richlowe: I assume jperkin will cover your request due to pkgsrc. I can build smartos-live with this if you wish.

Actually, fuck it, I'm doing it anyway.

we'll do it (smartos-)live!

:P

:P indeed. Also, I think the REAL test for me would be to update a PI with this change on it and then do a full build-strap-too build. We use platform ld for at least some of the strap build too.

So I'm building a PI with the change now. I have ssh+pwait combos waiting to install THAT PI onto another CN, which in turn will reboot, and which in turn will, once I'm able, to build a gcc10-primary which automatically does a strap build also.

indeed

used that to good effect this weekend

gcc10...how far we've come

gcc 4.4.4.4lyfe

rzezeski: but default is still gcc7, baby!! :) :) :)

richlowe will do.

gcc10 is also in testing in OI so gcc7 is not for that long

rzezeski: on irc via his starlink lol

gcc10 is waiting for andyf to have time, basically, as I understand it

I... suppose so. As far as I'm concerned, we should make the switch. It probably just needs someone to write up the proposal and get agreement.

I agree, for IPD purposes, probably.

and remember shrink to fit, you don't have to write a novel

obviously I'm using gcc10 almost exclusively these last few months, which doesn't exactly count, but must mean something.

and omnios has been on gcc10 for a good while now

Have we seen any Real Oddities with gcc10?

ISTR there were some nasty corner-cases in the 4 -> 7 jump.

the 4-7 stuff was mostly shrink wrapping and stuff like that

and some new inter-procedural crud

andy's testing has been, if anything, more extensive than necessary though.

noticing the inlining policy changes and such.

There has been one regression from gcc10 that I know of, which I think danmcd found, and tsoome promptly fixed (illumos 14948 fenix)

BUG 14948: loader: do_cpuid does corrupt memory when built with gcc 10 (Closed)

↳ illumos.org/issues/14948 | code.illumos.org/c/illumos-gate/+/2332

otherwise, illumos 14421 has links to the other stuff I've found and fixed, or accepted. (fenix)

FEATURE 14421: use GCC 10 as default primary compiler (In Progress)

↳ illumos.org/issues/14421

on balance, the remaining thing there (use -ftoplevel-reorder) is not something I think we should do, even though it would eliminate unused statics for us - variables too though, through constant folding, and some of those are supposed to be tuneables.

So close fenix illumos 14749 as will not fix?

FEATURE 14749: gcc10 build should use -ftoplevel-reorder (New)

↳ illumos.org/issues/14749

yes, I'll close that one as wontfix or whatever we have

with some commentary

We've been spinning gcc10 releases (albeit DEBUG only) for some time, but not using them as much as perhaps we should. We have smartos.org/bugview/OS-8327 for our downstream tracking of this.

→ OS-8327: Switch default compiler to gcc10 for SmartOS (Open)

Anyone familiar with AMD CPUs and fan control? The Wraith Prism fan that came with my AMD Ryzen 7 3700x CPU seems to either have failed, or just was never up to the job in the first place.

The fan has a 3-pin cable on it. It seems to turn on and off, but I don't think it's doing variable speed.

gwr: ISTR some of the AMD motherboards I've dealt with having different modes for fan control based on whether they were 4-pin ("native" PWM) or 3-pin (where they'd PWM the power line to the fan)

The motherboard supports 4 and 6 pin fan connectors (1:gnd, 2:pwr, 3:speed, 4:control, 5:sensor, 6:nc)

I'm geting frequent reports of the CPU going over 95 deg. C. Not good.

Is the Wraith Prism just garbage?

Or maybe the AsRock board is not controlling it correctly?

considering the boost behavior of modern chips, a better cooler probably isn't a bad investment

I have queries out to both outfits. :)

I'm remembering why we pay people to integrate systems

the chips will use thermal headroom you give 'em

Is the OS involved in controlling the CPU fan speed?

If so, how can I look at what it's doing, or adjust things?

I put a Noctua on my 3700X, gwr.

I did that w/o realizing the 3700x came with one. Now I think my paranoia was justified.

gwr: If your system has a BMC I would expect the BMC to be doing fan control

I would think so too. I've asked the Asrock folks about compatibility, etc. for fans.

danmcd: the X722 fix never got merged rifht

Nope. Needs LOTS of testing nobody has full cycles for.

just checking as i am rearraging some network things

(or full hardware for)

gwr: Can you get your IPMI sensor stuff? e.g., for an SMCI box I have: gist.github.com/jclulow/409f0bebb11705e1b79952f03325eb0b

yeah, lots of different hardware, shame it's onboard

yeah, the IPMI shows lots of sensor data

I've turned it off for now (so I don't cook the thing) until I can resolve the cooling issues.

Well when it's on, it might help to see what it thinks the temperatures are there, and the fan RPMs

Hopefully the silk screens on the board match up with the IPMI labels there ... but I would not assume they do

rmustacc: did you have solutions for building the same tests twice on x86 (for 32bit), but not adding a whole-ass copy?

I ask because I think you asked me this before

at the very least it'd be nice to know what my answer was :)

An FAQ entry on the noctua.at site indocates that 3-pin fan cables are non-PWM and 4-pin fan cables are PWM.

that's what pmooney said earlier

That wasn't clear. I thought he was saying the 3-pin were controlled differently, not that they can't do variable speed.

also, questions wise: people with cstyle opinions (but, please, only directly related ones). If I need to __attribute__ some stuff, and it's more stuff than usual, where would you like the line-break in the variable definition?

or the whole thing organized basically, I have one of everything attached to this variable, and I need to line-wrap it, and everything I do looks less good than I'd like

i think the 3-Pin noctua do sort of vary depending on voltage but you dont get accurate control or speed reading

at least the tiny 20x20x10 in my switch run slower

they stall on startup if it's too low though

richlowe: Same test source code, but build a 32-bit / 64-bit copy of it?

If so yeah, I do have solutions for that all over usr/src/test.

yeah, I took what you did, I just thought there was maybe something tidier

because our makefile's don't make building 32 64 together the most wholesome experience

but it was enough

dm me which version you took and I'll see if I can think of something tidier or know of which one I did?