01:01:28 jbk: see SUPPORTED_TERMS list in usr/src/cmd/mdb/Makefile.kmdb; the relevent bits of terminfo for those terminal types is compiled into the kernel for use by kmdb 01:22:44 jbk: doesn't look like there's a straightforward way to override #rows in kmdb 01:25:35 perhaps find kmdb's 'mdb.m_promif.pif_wsz' and patch it if you like playing with fire. (see usr/src/cmd/mdb/common/kmdb/kmdb_promif.c) 02:03:34 since there isn't a text output, the problem is trying to use kmdb and several lines scroll off the screen 02:04:07 (as i mentioned, the ahci emulation this VM is using is triggering a panic when booting off an ISO) 02:07:44 it's generating an error, and something in the error handling appears to be clobbering the state, which is then triggering the panic later 03:42:45 ahh.. it looks like i might be able to set the # of rows from loader... will need to try that tomorrow... 15:45:46 maybe a dumb question... if you have a thread that sets a flag (not a read-modify-update, just set to explicit value) that needs to _eventually_ be seen by other threads (so don't need to cv_wait() or such).. and no ordering with other variables... 15:46:05 would you stll need to use the membar ops to ensure visibility to other threads? 15:46:38 (i know on x86. the answer is probably 'no' just because of it's stronger guarantees, but not sure if that'd still hold for arm or such) 15:50:06 (or is it really just strictly needed where you need to guarantee the visibility of things in an explicit order) 16:41:37 jbk: as a practical matter it is quite likely that every cpu will eventually run scheduler code which will almost certainly do a membar. 16:43:00 (as a side effect of taking or releasing a lock..) 16:44:43 but on systems with loose memory ordering I would not be surprised if there were corner cases in kernel code where the 'eventually' might be longer than you'd like. 17:31:02 [illumos-gate] 18001 remove sparc-specific code from mpt_sas -- Hans Rosenfeld 19:10:46 if _I_ need it visible to other threads I would barrier (or have a lock that effectively did it for me) 19:11:13 but I also find it very easy to get paranoid about that 19:12:04 that was my feeling as well.. others feel it's unnecessary and it seems enough of a corner case that I couldn't convince myself it's not necessary 19:13:40 I think I asked this before, but if anyone has run into issues with qemu/kvm based HVs causing a panic when running illumos as a guest... I think I should have a fix soon... 19:14:33 tl;dr at least some variants appear to implement a rather old ATA feature PUIS which requires an explicit spin up before you can even do an identify/identify packet device 19:14:56 (so also a problem if you're tryting to boot an illumos ISO in the HV) 19:15:33 (somewhat amusingly, the old ATA code does this after firmware updates, but sata doesn't do it at all) 19:49:49 what was the pre-srmmu mmu? 23:26:16 someone mentioned OmniOS CE bloody version (or commits?) are updated every week or two unless frozen for stable release. Often I haven't seen that updated on website for longer, such as now. Can I maybe rsync the current bloody version from somewhere and make my own .ISO/.IMG? 23:29:18 the media isn't produced as often I don't think 23:29:33 I don't know the answer beyond that, you need andyf or hadfl or #omnios 23:29:36 okay 23:30:00 but you can pkg update 23:31:53 my OmniOS CE installation my currently be broken. I have to redo it on my new PC 23:32:01 so just want to download currently 23:32:23 i have to figure out how to make a zpool and then be able to install and select both Tribblix and OmniOS CE in it 23:32:33 i may still have the zpool. That's a bit tricky sometimes 23:32:46 i think I remember something to select. Maybe just my boot manager got messed up 23:33:00 or maybe I just haven't booted them in a while. I think at least one needs reinstalling 23:33:34 i mostly use Slackware & FreeBSD for desktop but install other things just to try a little and learn, and Illumos is one of those 23:37:44 i did learn enough I briefly ran X Window System in Illumos, maybe even the same user (on a ZFS) that I use daily... and it works! I know some don't recommend that as you may get plugin breakage (like in XFCE) if different UNIX/GNU/Linux have different paths that get saved in ~/.config 23:38:14 but I maybe just ran MATE. I wasn't a fan of GNOME but at least that old fork is faster now