github.com/illumos/illumos-gate/blo…to/keyhash_provider/k_hmac_md5.c#L9 - what don't you know?

oh, I guess that came from MIT: github.com/krb5/krb5/blob/krb5-1.3/…/crypto/keyhash_provider/hmac_md5.c

heh.. i wonder how painful it'd be to update the kerberos bits in illumos-gate

i suspect at some point it might be needed if only for smb

jbk those are a bit scattered, but I don't think its hopeless.

They certainly appear to know in github.com/krb5/krb5/blob/master/sr…to/builtin/hash_provider/hash_md5.c :)

the export control situation was very different when most of that code was being written....

right...

I don't know how it works, the hype says it's some sort of vm

if it's a full vm maybe omnios can boot on it soon :)

lol

hey, my phone just got elevated to a first class computing platform for my lab and the tensor CPU in the thing probably beats my best Intel CPU by a good margin (I7-8809g)

I will have an alphastation/openvms 7.3 sim on it in a few hours! :) finally it's 2025 and I can carry a vaxcluster in my coat pockrt! lol

I just lost a home machine due to a faulty PSU.Is there an engine in fmadm that has voltage sensors?, the premise is that I could define some min/max threshold of operation to at least sense that something is going on with the psu.

I would suspect it is rather vendor specific

should port en.wikipedia.org/wiki/Hw.sensors or alternative;)

tsoome I could only find coretemp(4D) that has temperatures, seems something like Hw.sensors is missing or at least I could not find an interface where to pull voltage values, like the described here openbsd.org/papers/asiabsdcon2009-sensors-slides.pdf

illumos.org/man/9E/ksensor ?

wiedi awesome, thanks!, an apropos sensor should found that one.

yea, the framework is there, cpu sensors are connected, but the voltage etc are from motherboard (if available)

From what I understand, a driver like OpenBSD lm(4) should be created and expose the voltage,fans,etc through the ksensor api.

I was reading this RFD rfd.shared.oxide.computer/rfd/0291 that is not related with the same problem but is relevant.

Anyone able to run Windows Server 2025 on bhyve?

neirac: Depending on what kind of board you have, a lot of that is exposed via impi.

Which can then be plumbed into topo which is kind of the what is the route to all of the sensors.

It's worth noting, most x86 CPUs aren't connected to that i2c bus that you'd find that on, but this all depends entirely on the board.

And no, the GPIO stuff I did (but don't currently have an i86pc consumer of which is why it's not up) doesn't have anything to do with this.

rmustacc thank for the clarification, I will check ipmi in the board.

Smithx10: not exactly what you're asking but I recently successfully set up Windows 11 Home.

What hurdles would there be with building the illumos-gate with the GNU linker in place of the native linker?

Quite a number of things you'd have to figure out. We definitely leverages features and flags that aren't present there. It also doesn't understand the v2 mapfile syntax we use, IIRC.

Is there something in particular you're trying to do?

Thanks. Not one thing in particular. I'm trying to better understand the interplay and limitations between these two linkers and the system

I've come across some materials suggesting the possibility of linking certain applications against the GNU linker, although I'm not sure of the accuracy of those materials. I didn't have much luck in finding more info on the matter. Could you tell me a bit about when the native linker vs GNU linker might be used?

The general suggestion is if you're building a program on illumos, you use the native linker.

Specifically on illumos, for illumos.

If you're cross-compiling to a totally different non-illumos host triple, then you will need a different linker.

Noted. Thanks!

for illumos#17062, there isn't a way to disable the FPU-ified versions of fletcher4 as a workaround (i.e. to avoid the bug until fix can be applied), is there?

i'm looking at the zfs code, and I don't see an obvious way, but not sure i haven't missed something

(i.e. something that could be easily done via loader -- I suppose you could boot kmdb, alter the array of implementations before zfs inits, and let the system continue, but that's probably a bit too much)

I thought it sniffed for which was fastest?

or something.

oh, that's exactly what I was about to suggest

yeah, the problem is without the above fix, it'll probably chose an implementation that uses the FPU

well with or without the fix, it'll probably choose that implementation

just without the fix for 17062, it can panic if lwp0 decides it needs to do some i/o on zfs

presumably the non-fpu verisons would avoid it if there was a way to force them

jbk: did you try patching fletcher_4_impl_chosen and fletcher_4_initialized in /etc/system ?

or does that happen too late?

but what is a hold on 17062?

gerrit lists it as integrated?

I imagined this is racktop backport hell?

ah, indeed

yeah, but any number of things can prevent you from upgrading to the latest bits.

There's a way to force the selection, I'm sure..

As sommerfeld says, fletcher_4_impl_chosen = 2 should lock it to the superscalar4 implementation, other values choose others.

You should need to touch fletcher_4_initialized though

*shouldn't

it looked like when it does it's tests, it'll overwrite that

oh hrm.. it's setting then restoring it...

i missed that earlier

Is the mutex_init interface different from Solaris?

do you mean kernel or userland?

i don't think the kernel interface has changed in a fairly long time... there's been _some_ changes to the userland mutex stuff IIRC, but it shouldn't be in a manner that breaks existing stuff

(if it is, definitely want details)

paulf: what's going wrong?

there have been changes in userland related to robustness, and other things.

userland, trying to see why Valgrind thread tools are having issues with pthread_mutex_init

ok, well only the behaviour in some corner cases is different

that I remember at least

I think I see the problem

Valgrind has wrappers for pthread_mutex_init and (Solaris and Illumos only) for mutex_init

paulf: A bunch of things changed for illumos.org/issues/16200.

→ BUG 16200: posix NORMAL lock is required to deadlock (Closed) | code.illumos.org/c/illumos-gate/+/3255

With OI it looks like those are both public, so now Valgrind intercepts two calls

oh, oh, I forgot the structuring there

Both pthreads and C11 mutex initialization will call the mutex_init() entry point which is public in libc.

on the Solaris side, the only change to pthread_mutex_init was the equivalent of illumos.org/issues/9959

→ BUG 9959: pthread_mutex_init should initialize mutex appropriately for robust mutex_init (Closed)

    Prior to the change         return (mutex_init((mutex_t *)mutex, type, &prioceiling)); might have been a sibling call

only redirecting mutex_init fixes 4 testcases on OI, I need to check if that breaks things on Solaris

time fir bed, but getting close to having DRD functional again