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

jbk: doesn't look like there's a straightforward way to override #rows in kmdb

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)

since there isn't a text output, the problem is trying to use kmdb and several lines scroll off the screen

(as i mentioned, the ahci emulation this VM is using is triggering a panic when booting off an ISO)

it's generating an error, and something in the error handling appears to be clobbering the state, which is then triggering the panic later

ahh.. it looks like i might be able to set the # of rows from loader... will need to try that tomorrow...

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...

would you stll need to use the membar ops to ensure visibility to other threads?

(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)

(or is it really just strictly needed where you need to guarantee the visibility of things in an explicit order)

jbk: as a practical matter it is quite likely that every cpu will eventually run scheduler code which will almost certainly do a membar.

(as a side effect of taking or releasing a lock..)

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.

[illumos-gate] 18001 remove sparc-specific code from mpt_sas -- Hans Rosenfeld <rosenfeld⊙gho>

if _I_ need it visible to other threads I would barrier (or have a lock that effectively did it for me)

but I also find it very easy to get paranoid about that

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

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...

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

(so also a problem if you're tryting to boot an illumos ISO in the HV)

(somewhat amusingly, the old ATA code does this after firmware updates, but sata doesn't do it at all)

what was the pre-srmmu mmu?

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?

the media isn't produced as often I don't think

I don't know the answer beyond that, you need andyf or hadfl or #omnios

okay

but you can pkg update

my OmniOS CE installation my currently be broken. I have to redo it on my new PC

so just want to download currently

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

i may still have the zpool. That's a bit tricky sometimes

i think I remember something to select. Maybe just my boot manager got messed up

or maybe I just haven't booted them in a while. I think at least one needs reinstalling

i mostly use Slackware & FreeBSD for desktop but install other things just to try a little and learn, and Illumos is one of those

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

but I maybe just ran MATE. I wasn't a fan of GNOME but at least that old fork is faster now