um, I had plain local zone install, then added nfs/server package, but starting service did end up "maintenance 16:51:01 svc:/network/nfs/server:default" and apparently the reason is "svcprop: Pattern 'svc:/network/ipfilter:default' doesn't match any entities". I guess, the network services should depend on ipfilter package?

tsoome: That sounds more like a bug in a method script?

I had a look at: docs.openindiana.org/dev/graphics-stack/#hardware-matrix – which states that the 8th gen Intel onboard graphics is not yet supported by OI illumos. My question is: When will the 8th gen Intel onboard graphics be supported? Thanks.

jclulow or that, yes.

anyhow, after installing ipfilter, I can clear nfs/server service

I guess, it is time to file an issue

ah, it is already there. illumos.org/issues/15560

→ BUG 15560: network/nfs/server fails with svcprop: Pattern 'svc:/network/ipfilter:default' doesn't match any entities (New)

jclulow btw, did you intend to review code.illumos.org/c/illumos-gate/+/2314 too? I would like to get it on RTI process soon.

→ CODE REVIEW 2314: 14919 tem: implement xenl (NEW) | illumos.org/issues/14919

Seems like MS Windows 10 is using iSCS target , served form SmartOS GZ, just fine. Just Linux initiator can't see it at all (not using andy authentication and username/password still)

does it have view?

tsoome, on Linux, iscsiadm -m discovery -t st -p IP_address , does not give anything but timeouts

yes, but did you verify if you have made it visible at server side?

I use this in script upon start to run target and make it available: bpa.st/VLAQ works fine on Win10

stmfadm list-view -l is All All

I would recommend to read docs.oracle.com/cd/E37838_01/html/E61015/fmvcd.html#scrolltoc and once done, especially docs.oracle.com/cd/E37838_01/html/E61015/gkgnr.html#scrolltoc -- because you do not want to mix different systems and their luns. please note that in that last ur, the example is based on FC connection, with iscsi, you need respective iqn's.

so illumos serving the luns, not connecting, correct?

(we just encountered a device the presents invalid IQNs -- at least unless you're using metric months :P -- and illumos won't connect to it without a patch to relax the IQN validation

hrm..

the pkgsrc autotools/automake/... seem to work with tpm2-tss, but the omnios ones have that confounding M4 errors (though I suppose that is somewhat redundant)

sometimes that's caused by e.g. not having libtool installed and you're missing some .m4 files

no, the omnios VM has libtool installed, but something's wrong..

the only external runtime deps though they have are openssl and json-c, so at least it'd be easy enough to just bundle things together at least for testing

i still need to finish the TAB support, but that wouldn't impact kicking the tires on things

that's mostly about 'virtualizing' the TPM (loosely speaking.. basically multiple clients accessing it so there's some state swapping in/out and object id mapping that has to happen)

[illumos-gate] 14919 tem: implement xenl -- Toomas Soome <tsoome⊙mc>

tsoome: so more specifically, your branch isn't outputting on the serial console, but it is at least allowing things to boot...

ou.

thats on azure?

yeah

fbsd though seems to be ok -- i can see and interact w/ loader on there

ok, thats good to know.

it may be, we are touching some settings it does not like.

need to compare those two sources...

i put 'set console=text,ttya' (as well as entries for boot_kmdb and a few others when I wasn't sure yet where the problem was) into boot/loader.rc

well added (before calling beastie-start)

so it should be mirroring out the console

the fb screenshots look like you'd expect

ah, ok so you have some output and input afterall?

show ttya-mode is making sense?

not from loader.. just after the OS starts booting

ou, ok. what is ttya-mode in prtconf -v ?

i can check in a bit -- i'm building a new image to fix an unrelated issue with our installer

ofc, np

@pmooney in particular may have this in L1 cache... is there an AMD public document mentioning which CPU models (or newer) contain which MSRs ?

hahaha, nothing of the sort

the documentation is such a hodge-podge

MSRs which were introduced in an old model, and still exist today, being totally absent from newer docs

a deep well of sadness

Damn.

The morbidly curious should see: smartos.topicbox.com/groups/smartos…73c3f1cf4-M830f40f6375617e69b161db0

(Turion CPU vs. modern BHYVE loses GPFs at MSR used by ( fenix ) illumos#15467

BUG 15467: bhyve needs TSC frequency control (Closed)

↳ illumos.org/issues/15467 | code.illumos.org/c/illumos-gate/+/2711

I can probably dig through some things if helpful.

Don't.

The Turion is K10 AIUI, so there's a whole generation (Bulldozer, right?) between it and Zen.

(oops, Turion II) I have no idea how set for virtualization Bulldozer is, but I'm guessing K10 is no longer treated as supportable by AMD.

There are multiple generations, but yeah.

[illumos-gate] 16208 Update AMD microcode to 20240116 -- Andy Fiddaman <illumos⊙fn>

danmcd: Do you have the stack of the dump?

Yes I do.

Mind dming it to me?

I think there should be cpuid bits that cover whatever this is.

A quick glance at the AMD docs mentioned something about an indicator. Lemme see if I can find it really quickly...

ah

so we check for it in some places

but the restoration of that value is unconditional

(which is wrong)

I can take care of this

CPUID Fn8000_000A_EDX[TscRateMsr] =1 indicates support for the TSC Ratio MSR. See

Section 3.3, “Processor Feature Identification,” on page 71 for more information on using the CPUID instruction.

Oh wow.

It's an actual bug then? Cool, I guess.

yeah

we check for the feature if/when userspace attempts to set TSC scaling

but just blindly restore the scaling value on exit

sorry about that, I should have caught it in review

Do you want to follow up on the thread there Dan or should one of us?

I've followed up on the thread.

Once one of you two files an illumos bug I'll further-further followup on it.

I'll file the bug in a minute

fenix illumos#16393

BUG 16393: bhyve should take more care with MSR_AMD_TSC_RATIO (In Progress)

↳ illumos.org/issues/16393

danmcd: Yo, saw your email Re: crash - wasn't on #illumos :)

jzu: look at the archives from literally a minute or two before you joined going back to about an hour ago.

e.g. fenix illumos#16393

BUG 16393: bhyve should take more care with MSR_AMD_TSC_RATIO (In Progress)

↳ illumos.org/issues/16393

danmcd: thanks! that box I have is way past it's prime, but still does it's job as NAS at home =)

funnily enough I started creating a VM for Solaris 11 so I could netinstall a T2000 remotely (it's 2000 miles away at family cottage)

that's when I got caught in crash loop, managed to tackle it by being quick enough to SSH into the box and setting autoboot to false for the Bhyve Zone.

I'm not too concerned if I'd have to go back to latest PI before the change, that box is really due for replacement before it catches fire ;)

but sure - I won't complain if the logic will be implemented to get around it.

It needs to be fixed, even if the CPUs impacted by it are few and far between at this point

:)

I missed the inconsistency by not checking for other uses of that MSR apart from the one in your kernel panic.

pmooney: if you need I can test the fix once you have PI build ready.

I don't have SmartOS build machine around anymore, but danmcd can probably cut a PI for you when the proposed fix is posted

Once I see patches I can spin. Easy-peasy.

jzu: are you disk-booting so you can just use piadm(8)?

danmcd: sadly no, I installed this host +10 years ago so it's USB which I'm updating (usually with platform-upgrade script)

jzu: let's move to #smartos then

Thank you for figuring it out, pmooney and rmustacc! I have to leave now, but might be back late-night US/Eastern.