tsoome: more than one chain_disk isn't supported by the loader menu?

(is this documented anywhere?)

you can add them into <pool>/boot/menu.lst

the main menu entry is just one.

im not sure if man was updated with it or not.... should document it...

would be even better if there was a menu that lets you select a disk/partition for chainloading :)

heh:)

jbk Is it normal that page 3 and 4 that are related to the format device page and rigid disk geometry page are not able to be read that the scsci option from format? reading the code I understand that those pages are used to set the geometry of the disk so fdisk could work on those. I'm still finding out why virtio-scsi cannot be format

i don't know offhand

keep in mind vioscsi (as far as illumos is concerned) is just another model of HBA

you give it SCSI packets and the device (in this case the hypervisor) figures out how to deliver them to the actual device

so if those pages aren't present, that's something with the disk emulation in the hypervisor

or sd.c is sending the wrong SCSI commands... though given it works with pretty much every other type of SCSI disk out there, it seems less likely though still possible

(I do recall we had an issue with I think a certain model SSD at Joyent where something with the power management commands sd.c was using led to the device not being online

something like that

so it's not unheard of

jbk thanks, so those pages should always present, this disk a paravirtualized one I don't know if that makes any difference, at least I know a little more of scsi

paulf: Regarding execvpe is that something you'd find useful if it was finished up?

no not expecially, I maintain Valgrind and I've been looking for a patch that allows valgrind to be started from within gdb

at a patch

and I was checking compatibility with FreeBSD and Illumos/Solaris

Gotcha. OK.

sommerfeld: I have suffered with .KEEP_STATE at a high level and being broken before. I have a workspace which greatly increases our build parallelism (for moderate gains), and can't integrate because make just loses completely if you build debug and -nd at the same time under nightly.

.make.state writes out targets with no dependencies

so yes, fraught with peril.

(and I have never figured out why)

Does anyone happen to have some mlxcx sitting around that can help with testing something out for me?

maybe... they're probably checked out to someone, but might be able to sneak in depending on what's needed

rmustacc: any particular model?

nahamu: Any supported.

I'm just looking to test the MAC_PROP_MEDIA changes on it.

do you need it booted on a modified kernel?

Yes. There are bits pre-built in question.

Hopefully someone else has one for you, but if not I might be able to get access to one for a bit.

@rmustacc I have a customer who can test it out (but they'll have to merge it with some mlxcx work I had to do for them, oddly enough involving your changes for that driver too).

tl;dr ==> more sources for your changes are now available in ConnectX-6 parts.

Ah, I see.

Well if something wants to land I can try to rebase across it and extend it I guess.

It's not ready for landing. I think YOUR stuff should land first. I just wanted you to know that if I test it, i'll be pulling it in on top of the aforementioned draft PR.

danmcd: is that for all connectx-6 cards, or just certain ones?

I *think* certain ones, but honestly I'm not sure. Basically there was a 32-bit vector of bits which indicated both speed AND link type. An additional 32-bits got added with CX-6 (or at least some models?!?).

What I *should* do is pull rmustacc's whole wad into the `mlxcx` branch of illumos-joyent, and then make my changes over those.

Thanks, I needed to type that out loud, but I'd been thinking that for a week or more.

//nick rubberduck

Heh heh heh.

andyf: so, 2023c is a straight backout identical to 2023a, without attempts to deal with the mess in the middle, so that's good I think?

(there's now a thread where people point out the gap in the middle problem, and seem to be wanting a d that fixes _that_?)

Still needs to be built, but this commit: TritonDataCenter/illumos-joyent #444/commits/546ab52c44b3a4386d18a00ea03811e5b96d0035

is the post IPD 39 version of my CX-6 extended media bits work. I'll note some media types aren't in your current set, but I might not understand what Mell^H^H^H^HnVidia means by some of those new link types.

@rmustacc ^^^ still needs to build built (happening now) and tested (will need a customer's help for the CX-6 part).

rmustacc: I have a few ConnectX-6 Dx machines that aren't in production yet, but I don't know if that's what you're after for testing

Smithx10: I just want basic verification that dladm with my change present is showing things that we expect.

So hopefully pretty fast/quick.

I'll happily boot up an image and run some things for you, but as @danmcd mentioned these cards weren't getting the proper speed set until he pushed some changes

CX-6 has some extended bits to show other speeds and media, not available in current mlxcx.

Smithx10's pre-this-fix driver showed 0 for the existing bits, and therefore reported speed == 0.

@Smithx10 you'll love this in that you get dladm to show you the link type (xxxBaseT, xxx_FX, etc).

(That's the IPD 39 work, not anything I did...)

The above commit is broken, best to look at it in context: TritonDataCenter/illumos-joyent #444