01:29:32 also.. anyone know if there's any gotchas with bumping the size of the kernel's message buffer? 01:30:00 this panic produced so much output that ::msgbuf lost the beginning of it (I'm thinking because of the # of cpus) 02:06:31 https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/i86pc/sys/apix.h#L98-L99 probably harmless, but I feel like that cast is too soon (i.e. mask off the bits, then cast isntead of cast, then mask) 08:51:27 It's been a while but I'm getting back into Zig's support for Illumos. The code for doing stack dumps was rewritten and can unwind via unwind tables or the frame pointer. I'm debating whether to always use fp unwinding on Illumos since it works better than unwind tables. 08:52:24 Are there any Illumos distros that use `-fforce-omit-frame-pointer`? From what I've seen this isn't true. 15:36:28 i don't believe so 15:38:08 just because things like pstack, mdb, and dtrace rely on frame pointers for stack traces (it's less complicated than winding code, so fewer opportunities for errors, and with 64-bit, you can usually spare the register) 17:25:19 is aarch64 support within reach? 17:30:59 toasterking - only for compiling specific artefacts like BIOS ROMs. As jbk said, we value debugging a bit to much otherwise. 17:32:44 rpz recently bumped the version of zig in omnios to 0.15.1 if you wanted/needed a starting point for anything 17:33:17 makr - there is a functional, but still experimental, aarch64 port. I'm using it for a few things on Raspberry Pi 4s though. 17:35:17 thanks andyf 17:35:56 We keep some ready to go images at https://downloads.omnios.org/media/braich/ which can be booted under qemu or on a rpi4. 17:41:08 (Where "We" is the OmniOS project) 17:44:44 https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4887 - I've just assumed this will work on illumos too, not actually tested it 17:45:14 oh great, i got it running, thank you! 17:46:23 /dev/null is a symlink? o_O 17:46:44 lrwxrwxrwx 1 root root 27 Oct 17 2018 /dev/null -> ../devices/pseudo/mm@0:null 17:46:54 ohh interesting 17:47:11 on Solaris, pretty much everything under /dev is a symlink to the actual device in /devices 17:47:49 ah. does the "mm@0" have a meaning? 17:48:13 (with some exceptions, like /dev/fd being a mount point for a special filesystem type) 17:48:50 I'm sure it does, but I don't remember it off hand 17:50:23 mm - memory driver, and it's instance 0. It has minor nodes for the /dev/null, /dev/zero and /dev/full devices. 17:52:48 and /dev/mem, /dev/kmem.. which is presumably the origin of its name 17:54:29 that's neat 17:57:58 more of a dumping ground for miscellaneous pseudo-devices 17:59:32 sommerfeld - I was inferring from "/dev/mem" being first in its list, and it being called the "memory driver". But it's certainly where I'd stick any future similar devices :) - /dev/full was a late addition. 19:49:06 well if nothing else, i've leared more about the low level details on how interrupts work on this... 19:49:35 though all the casting and mixing of signed and unsigned types gives me some heartburn :) 19:50:52 like in some places we pass a uint32_t to a function that's expecting an int, etc. 19:56:56 jbk: the promotion/etc rules make that ok in 99.9% of cases 19:57:02 even worse 19:57:45 rmustacc and less so others have been trying to be very careful about all that 19:57:53 but any code older than that, obviously, is what it is 19:58:27 yeah, i'm pretty sure this is all stuff that hasn't been touched since the sun days 19:58:32 we have several wireless drivers where, I suppose, a code reviewer said "Use fixed size types", and they used `int8_t *` for strings 19:58:36 illumos contains multitudes 19:58:37 just now that i'm trying to piece together how things work 20:00:26 and one thing I wasn't sure of is this system has 2 CPUs (64 cores ea).. the x2apic ids on the 2nd cpu start at 512 20:01:02 which means: x2apic mode and not apic mode should be enabled by the bios normally (seems like that's the case) 20:01:20 but also, you obviously have apic ids > 255 20:01:57 which I wonder might be an issue -- i've not looked at this before, so I don't know if that was something common enough that even on higher core machines was something we've encountered before or not... 20:03:35 there's not too much hw in the system itself -- 2 mellanox cx-6 cards (2 ports ea) and an HPE branded megaraid card, plus the typical built-in bits (USB, iLO) 20:05:04 but the most recent example... apix_pci_msi_enable_vector() -- target_apic_id is int, but is being passed in a uint32_t (and should probably just be a uint32_t) 20:05:13 or that somewhat dubious cast I found yesterday 20:28:35 illumos mentioned! https://hachyderm.io/@cliffle/115429703942334462 20:29:50 and it was better than the Solaris mention elsewhere in the thread: https://hachyderm.io/@alanc/115442314555656670 20:32:14 I remember talking about this crap with someone 20:32:18 jclulow you? 20:34:08 illumos 17030 (fenix)? 20:34:49 issue '17030' not found... 20:35:18 https://www.illumos.org/issues/17030 20:45:05 I think the infra must be suffering again 20:46:53 Have you heard about this? https://gx.do/ is this still alive? 20:56:43 we apparently fixed it when ADI was being triggered on the reads past the end of the allocated buffers 21:13:20 some day, I will free my mind enough to really concentrate on the equivalent arm features 21:15:24 except for TBI, for which my mind may never be free enough 21:16:33 (do we tag .dynamic, and then set the as limits etc on exec? is there more?) 21:28:22 and then maybe, just maybe, you'll get to do it again for x86: https://www.osnews.com/story/143601/intel-amd-to-bring-memory-tagging-to-x86-at-some-point/ 22:50:19 https://techhub.social/@fosdembsd⊙bc/115442760816869102 talks about illumos at FOSDEM