[illumos-gate] 15949 want bounded version of topo_mod_clean_str() -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 15951 want Zen specific CPU topology mapping -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 15956 need spd decoding library -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 15957 Want common topo DIMM module -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16016 bhyve suspend exits could note source -- Patrick Mooney <pmooney⊙pc>

[illumos-gate] 16053 bhyve rtc fumbles periodic interrupts -- Patrick Mooney <pmooney⊙pc>

tangentially related to this, can kernel threads migrate between cpus?

i'm not sure this is part of the problem i'm chasing down, but investigating brought up a question with that

kcf uses a per-cpu reference count .. in essence `mutex_enter(&lock[CPU_SEQID]; foo->refcnt[CPU_SEQID]++; mutex_exit(&lock[CPU_SEQID]);`

seems like you'd need to stash the cpu value at the start so it's consistent...

or let the reference counts go negative and sum them (???)

[illumos-gate] 16067 zfs-tests: unneeded sudo in import_rewind_config_changed.ksh -- Toomas Soome <tsoome⊙mc>

jbk: pretty sure they can

Pretty sure unless you have done something with kpreempt_disable(), at least, that there are no guarantees about staying in the same place

jbk yesterday I tested smartos in oracle cloud, and pit was working without forcing it pitisbroken with kmdb , the only thing that vioscsi problem is still there, but at least have mdb access now. I started check the ::sd dcmd to find out what the problem was.

sounds like maybe they fixed their emulation then...

i forget what the vioscsi problem was...

i've been busy dealing with my own issues w/ vendor's seemingly non-standard devices :)

jbk the vioscsi problem was when trying to run fdisk, it failed with a Error in ioctl DKIOCGMBOOT: I/O error and every other operation in the disk, also other operations like zpool create fail.

jbk got this as well Illegal request during format ASC: 0x20 ASCQ: 0x0

0x20 is just 'invalid operation code'

sounds like their scsi emulation leaves much to be desired

So what closed binaries are left in illumos?

jbk yes, they should fix that as they the pit stuff.

is it possible to get a conn_t data from a sonode_t object?, checking the code I don't see that possible, just asking to be sure

seems mdb always have some gold nuggets src.illumos.org/source/xref/illumos…odules/genunix/vfs.c?r=892ad162#784

rmustacc: thanks

yuripv: welcome back, and expect a push notification here in<=1hr's time.

(Precise time determined by Ryzen 3700X + 128GB RAM vs. on-disk-but-big-slog illumos-gate from-scatch build.)

How long does that take danmcd? That's been my workstation setup for a few years

40mins 0-to-illumos (both DEBUG and non-DEBUG, and with both smatch and gcc7 shadowing).

NIGHTLY_OPTIONS="-ADCmnprft"; export NIGHTLY_OPTIONS

(And obvs gcc7 shadowing turned on.)

copec: Been my HDC since 2020: kebe.com/blog/?p=502

[illumos-gate] 15979 kernel heap corruption detected during disk pulls on HPE appliance -- Yuri Pankov <ypankov⊙tc>

yuripv: ^^^

so what does "Console login service(s) cannot run" mean when trying to install openindiana

where is 'struct __sock_lower_handle' defined ? trying to get a conn_t from a sonode* type I'm getting error invalid use of undefined type 'struct __sock_lower_handle' , I already have sys/socket_proto.h

It's explicitly an opaque typ.

*type

What code are you writing?

That is, where are you specifically? Are you in sockfs?

rmustacc I'm trying to get a conn_t for a sonode type so->so_proto_handle->conn_tcp, I'm in lx code

Yeah, the whole point of the abstraction is that code that isn't in the implementing logic doesn't know what it is.

That is, the modules that implement the lower handles, e.g. tcp, udp, etc. will cast it to something that it knows.

So if you're trying to cast the so_proto_handle_member somewhere outside of that to me suggests this is probably not the right design.

The lx code may be cheating and encode that info, I'd have to look, but the general rule of thumb is if you're not the impl, you're not the protocol and in the context of a downcall, you don't get to know what it is.

rmustacc thank you very much, now I understand. I'll check more of the lx code to find out if it's possible to fetch the tcp data I need.

I suspect you're going to need to ask the protocol to fill it in.

Because there's no other way to deal with the locking.