12:29:24 tsoome: more than one chain_disk isn't supported by the loader menu? 12:29:29 (is this documented anywhere?) 12:30:00 you can add them into /boot/menu.lst 12:30:10 the main menu entry is just one. 12:31:04 im not sure if man was updated with it or not.... should document it... 12:31:51 would be even better if there was a menu that lets you select a disk/partition for chainloading :) 12:34:34 heh:) 13:35:48 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 14:06:40 i don't know offhand 14:07:03 keep in mind vioscsi (as far as illumos is concerned) is just another model of HBA 14:07:30 you give it SCSI packets and the device (in this case the hypervisor) figures out how to deliver them to the actual device 14:08:26 so if those pages aren't present, that's something with the disk emulation in the hypervisor 14:09:35 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 14:11:20 (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 14:11:39 something like that 14:12:25 so it's not unheard of 14:25:20 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 16:13:30 paulf: Regarding execvpe is that something you'd find useful if it was finished up? 16:14:50 no not expecially, I maintain Valgrind and I've been looking for a patch that allows valgrind to be started from within gdb 16:14:59 at a patch 16:15:27 and I was checking compatibility with FreeBSD and Illumos/Solaris 16:16:07 Gotcha. OK. 16:16:20 https://bugs.kde.org/show_bug.cgi?id=434057 17:30:58 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. 17:31:04 .make.state writes out targets with no dependencies 17:31:09 so yes, fraught with peril. 17:31:33 (and I have never figured out why) 18:02:11 Does anyone happen to have some mlxcx sitting around that can help with testing something out for me? 18:03:16 maybe... they're probably checked out to someone, but might be able to sneak in depending on what's needed 18:05:02 rmustacc: any particular model? 18:08:25 nahamu: Any supported. 18:08:45 I'm just looking to test the MAC_PROP_MEDIA changes on it. 18:10:35 do you need it booted on a modified kernel? 18:10:56 Yes. There are bits pre-built in question. 18:15:02 Hopefully someone else has one for you, but if not I might be able to get access to one for a bit. 19:03:27 @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). 19:04:49 https://github.com/TritonDataCenter/illumos-joyent/pull/439 19:06:15 tl;dr ==> more sources for your changes are now available in ConnectX-6 parts. 19:06:52 Ah, I see. 19:07:06 Well if something wants to land I can try to rebase across it and extend it I guess. 19:11:53 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. 19:18:28 danmcd: is that for all connectx-6 cards, or just certain ones? 19:34:41 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?!?). 19:35:22 What I *should* do is pull rmustacc's whole wad into the `mlxcx` branch of illumos-joyent, and then make my changes over those. 19:35:47 Thanks, I needed to type that out loud, but I'd been thinking that for a week or more. 19:37:42 //nick rubberduck 19:40:40 Heh heh heh. 20:35:09 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? 20:36:50 (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_?) 20:54:38 Still needs to be built, but this commit: https://github.com/TritonDataCenter/illumos-joyent/pull/444/commits/546ab52c44b3a4386d18a00ea03811e5b96d0035 20:55:25 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. 20:56:08 @rmustacc ^^^ still needs to build built (happening now) and tested (will need a customer's help for the CX-6 part). 21:09:10 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 21:09:43 Smithx10: I just want basic verification that dladm with my change present is showing things that we expect. 21:09:53 So hopefully pretty fast/quick. 21:12:36 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 21:13:59 CX-6 has some extended bits to show other speeds and media, not available in current mlxcx. 21:14:20 Smithx10's pre-this-fix driver showed 0 for the existing bits, and therefore reported speed == 0. 21:15:10 @Smithx10 you'll love this in that you get dladm to show you the link type (xxxBaseT, xxx_FX, etc). 21:22:16 (That's the IPD 39 work, not anything I did...) 21:24:28 The above commit is broken, best to look at it in context: https://github.com/TritonDataCenter/illumos-joyent/pull/444