00:31:08 https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/gssapi/mechs/krb5/crypto/keyhash_provider/k_hmac_md5.c#L9 - what don't you know? 00:35:55 oh, I guess that came from MIT: https://github.com/krb5/krb5/blob/krb5-1.3/src/lib/crypto/keyhash_provider/hmac_md5.c 01:50:34 heh.. i wonder how painful it'd be to update the kerberos bits in illumos-gate 01:50:58 i suspect at some point it might be needed if only for smb 05:22:27 jbk those are a bit scattered, but I don't think its hopeless. 05:32:21 They certainly appear to know in https://github.com/krb5/krb5/blob/master/src/lib/crypto/builtin/hash_provider/hash_md5.c :) 05:35:48 the export control situation was very different when most of that code was being written.... 07:18:49 right... 11:27:53 https://www.androidpolice.com/android-15-linux-terminal-app/ 11:28:17 I don't know how it works, the hype says it's some sort of vm 11:28:50 if it's a full vm maybe omnios can boot on it soon :) 11:28:53 lol 11:30:14 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) 11:33:00 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 11:41:11 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. 12:11:09 I would suspect it is rather vendor specific 12:19:32 should port https://en.wikipedia.org/wiki/Hw.sensors or alternative;) 12:42:37 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 https://www.openbsd.org/papers/asiabsdcon2009-sensors-slides.pdf 12:54:01 https://illumos.org/man/9E/ksensor ? 12:55:30 wiedi awesome, thanks!, an apropos sensor should found that one. 13:36:00 yea, the framework is there, cpu sensors are connected, but the voltage etc are from motherboard (if available) 15:02:06 From what I understand, a driver like OpenBSD lm(4) should be created and expose the voltage,fans,etc through the ksensor api. 15:07:18 I was reading this RFD https://rfd.shared.oxide.computer/rfd/0291 that is not related with the same problem but is relevant. 15:18:39 Anyone able to run Windows Server 2025 on bhyve? 15:25:33 neirac: Depending on what kind of board you have, a lot of that is exposed via impi. 15:25:51 Which can then be plumbed into topo which is kind of the what is the route to all of the sensors. 15:26:10 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. 15:26:44 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. 15:31:56 rmustacc thank for the clarification, I will check ipmi in the board. 15:57:53 Smithx10: not exactly what you're asking but I recently successfully set up Windows 11 Home. 16:39:37 What hurdles would there be with building the illumos-gate with the GNU linker in place of the native linker? 17:01:51 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. 17:02:32 Is there something in particular you're trying to do? 17:13:15 Thanks. Not one thing in particular. I'm trying to better understand the interplay and limitations between these two linkers and the system 17:14:32 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? 17:20:53 The general suggestion is if you're building a program on illumos, you use the native linker. 17:21:08 Specifically on illumos, for illumos. 17:21:37 If you're cross-compiling to a totally different non-illumos host triple, then you will need a different linker. 17:37:41 Noted. Thanks! 18:26:37 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? 18:26:56 i'm looking at the zfs code, and I don't see an obvious way, but not sure i haven't missed something 18:27:50 (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) 18:27:55 I thought it sniffed for which was fastest? 18:27:58 or something. 18:28:12 oh, that's exactly what I was about to suggest 18:28:41 yeah, the problem is without the above fix, it'll probably chose an implementation that uses the FPU 18:28:53 well with or without the fix, it'll probably choose that implementation 18:29:24 just without the fix for 17062, it can panic if lwp0 decides it needs to do some i/o on zfs 18:29:44 presumably the non-fpu verisons would avoid it if there was a way to force them 18:51:13 jbk: did you try patching fletcher_4_impl_chosen and fletcher_4_initialized in /etc/system ? 18:51:22 or does that happen too late? 18:53:25 but what is a hold on 17062? 18:55:18 gerrit lists it as integrated? 18:58:11 I imagined this is racktop backport hell? 18:58:19 ah, indeed 18:58:21 yeah, but any number of things can prevent you from upgrading to the latest bits. 19:01:40 There's a way to force the selection, I'm sure.. 19:05:22 As sommerfeld says, fletcher_4_impl_chosen = 2 should lock it to the superscalar4 implementation, other values choose others. 19:06:11 You should need to touch fletcher_4_initialized though 19:06:15 *shouldn't 19:11:36 it looked like when it does it's tests, it'll overwrite that 19:20:55 oh hrm.. it's setting then restoring it... 19:20:59 i missed that earlier 20:23:11 Is the mutex_init interface different from Solaris? 20:24:41 do you mean kernel or userland? 20:25:24 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 20:25:33 (if it is, definitely want details) 20:27:24 paulf: what's going wrong? 20:27:54 there have been changes in userland related to robustness, and other things. 20:33:48 userland, trying to see why Valgrind thread tools are having issues with pthread_mutex_init 20:39:12 ok, well only the behaviour in some corner cases is different 20:39:21 that I remember at least 20:44:06 I think I see the problem 20:45:09 Valgrind has wrappers for pthread_mutex_init and (Solaris and Illumos only) for mutex_init 20:47:45 paulf: A bunch of things changed for https://www.illumos.org/issues/16200. 20:47:46 → BUG 16200: posix NORMAL lock is required to deadlock (Closed) | https://code.illumos.org/c/illumos-gate/+/3255 20:48:34 With OI it looks like those are both public, so now Valgrind intercepts two calls 20:49:46 oh, oh, I forgot the structuring there 20:50:28 Both pthreads and C11 mutex initialization will call the mutex_init() entry point which is public in libc. 20:50:43 on the Solaris side, the only change to pthread_mutex_init was the equivalent of https://www.illumos.org/issues/9959 20:50:44 → BUG 9959: pthread_mutex_init should initialize mutex appropriately for robust mutex_init (Closed) 20:51:58     Prior to the change         return (mutex_init((mutex_t *)mutex, type, &prioceiling)); might have been a sibling call 20:54:55 only redirecting mutex_init fixes 4 testcases on OI, I need to check if that breaks things on Solaris 21:05:41 time fir bed, but getting close to having DRD functional again