00:01:11 <arekinath> jclulow: part of me wonders if we should keep the actual definition of `struct ilstr` and `ilstr_flag` out of the "not-public public" `sys/ilstr.h`?
00:01:53 <arekinath> oh I guess it's not being built into a .so anyway is it
00:01:54 <jclulow> arekinath: I want to be able to drop one on the stack
00:01:57 <arekinath> so binary compat isn't a big deal
00:01:59 <arekinath> yeah ok
00:02:00 <jclulow> right
00:02:08 <jclulow> that's why it's like list.o not libcustr.so
08:21:07 <neuroserve> do we have AMD EPYC "Rome" support?
08:32:12 <jclulow> neuroserve: Yes.
08:33:05 <jclulow> We make relatively extensive use of modern AMD CPUs (both consumer and enterprise parts) at Oxide.  They work well.
08:47:30 <neuroserve> just asking 'cause im sitting through an AMD roadshow right now - we're using "Milan" right now and it seems that "Genoa" or "Bergamo" might be next
09:09:50 <sjorge> bhyve pci passthru doesnt work on them though, or did that get fixed?
09:41:37 <jclulow> Not sure.  We're not doing any of that at the moment 
12:27:21 <neirac> I'm trying to trace ipc calls but I don't see shmget  in the list of probes with dtrace -l  , this old post also checks for shmget https://dtrace-discuss.opensolaris.narkive.com/rgr5fjgm/dtrace-and-shared-memory-id to migrate this script to illumos which provider do I need ?
13:11:51 <tsoome> you can use just function names; probes are good to get specific information from inside of function (variable values etc)
13:13:00 <tsoome> shmget is definitely there: https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/shm.c?r=86ef0a63#829
13:15:10 <neirac> tsoome thanks!
13:16:10 <neirac> tsoome do you have any experience booting illumos under tiano core? I'm still debugging on oci how to boot smartos and clearly, it enters exitbootservices call but never returns
13:17:00 <tsoome> tiano core like edk2?
13:17:22 <neirac> tsoome yes that's right
13:18:26 <tsoome> I have used qemu (cueerntly UTM)
13:18:32 <tsoome> currently*
13:20:00 <neirac> I removed extibootservices to shutdown(1) to get back to efi and as expected I get back to the efi shell, but calling Exitbootservices never returns 
13:20:05 <tsoome> exit boot services needs correct memory key
13:20:35 <neirac> how do I check if I have the correct memory key? that's being return be efi_get_mmap I think
13:20:57 <tsoome> well, normally exit boot services should complain if the key is not ok
13:21:18 <tsoome> and yes, you get it with memory map
13:21:29 <tsoome> let me see...
13:21:49 <tsoome> what system is using this tiano core?
13:22:23 <neirac> tsoome I'm trying to boot using ipxe on oracle cloud
13:22:34 <tsoome> ah, oracle cloud.
13:22:45 <tsoome> thats x86?
13:23:01 <tsoome> not aarch64?
13:23:40 <tsoome> ExitBootServices is using image handle and key, if key is ok, perhaps the image handle is corrupted?
13:25:12 <tsoome> I did work for ampere to fix edk2 used with their aarch64, that one was booting fbsd loader however.
13:26:26 <neirac> tsoome oh, I have not check the img_handle I'll try to print it before the call 
13:26:56 <neirac> is there a magic header to check if it's corrupted?
13:27:08 <tsoome> anyhow, I'd suggest to try out illumos loader64.efi 
13:27:31 <tsoome> um, not idea really:) 
13:27:52 <tsoome> have had no reason to check whats inside there
13:31:56 <tsoome> I mean, if illumos loader seems to work, it means ipxe has something oing on. if both are bad, then there is a problem... 
13:33:50 <tsoome> how positive you are that ExitBootServices does not return?
13:38:06 <tsoome> I'm asking because, if your console output in ipxe is done with SimpleTextOutput protocol, then you can not print anything out after ExitBootServices. loader does set has_boot_services = false and is using software rendering on framebuffer to get output (if needed - normally we get next output from kernel already)
13:39:43 <tsoome> if serial console is used with Serial IO, you have the same proble,
13:39:49 <neirac> I compiled ipxe with debug messages, so there is debug message when bootservices fails and one after is called to print the return status
13:40:33 <neirac> oh, so after calling exitbootservices I won't see any messages printed? 
13:40:59 <tsoome> but if ExitBootServices did not fail and you attempt to use BS-> functions, your system most likely will hung
13:42:49 <neirac> after ExitBootservices just multiboot2_bounce is called 
13:43:38 <tsoome> that just trampoline to switch to 32-bit protected mode and jump to dboot?
13:44:49 <neirac> I'll to check the multiboo2_bounce call implementation, at least I don't see it in the ipxe code
13:46:50 <tsoome> loader does relocate kernel and modules to final location, then does switch to 32-bit mode and jumps to kernel. relocation is needed because when BS active, we can read kernel only into allocated memory.
13:56:51 <neirac> tsoome thanks, I'm just learning this as I tried to boot smartos on oci.
14:04:16 <tsoome> yw
14:31:53 <neirac> tsoome I was wondering on what you told me about messages and now I just tested using serial console ( I was using vnc), and found out that was crashing, in vnc I never saw this.https://paste.ec/paste/CkHm3VpB#42-aIbq3o0Mtt7Ae4JQjir1FXFfKLASO886KjgVs2Ms seems is the image handler could be wrong? 
14:52:25 <tsoome> ah, it is quite common that exceptions are dumping output on serial port and not on video
14:54:03 <neirac> tsoome that exception means the image handler was incorrect?
14:54:47 <tsoome> from entry address you can see if this exception (invalid opcode) is happening in ipxe or in firmware
14:55:25 <tsoome> seems rather low for our kernel (unix entry address is 0xc00000)
14:56:22 <tsoome> but may it be this exception is result from your debug printout, no?
14:58:18 <neirac> I removed the printfs, thinking that could the cause, I'll compile without debug
15:26:58 <neirac> tsoome this is awesome, but sad because I spend like a week in vnc without seeing this https://paste.ec/paste/x54TT8Xo#XGMQ5zUMY1YB1d6BrCl+OMlKMgmF7+eVofKyt-SrOAn
15:27:21 <neirac> do_bop_phys_alloc is  the kernel right?
15:27:54 <neirac> well I learned not to use vnc to troubleshoot things at least
15:29:27 <jbk> https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/i86pc/os/fakebop.c?r=2af7a84a&mo=5669&fi=199#199
15:32:42 <neirac> jbk I could use mdb or is too early in the boot process ?
15:35:31 <jbk> i think if you load kmdb at boot, you might be able to
15:36:01 <jbk> i've not messed with that before though, so not sure if so or if you'd have to resort to printf() debugging
15:52:41 <kebe> OS-7748
15:53:02 <kebe> https://smartos.org/bugview/OS-7748
15:53:21 <kebe> jlevon fixed this in our ipxe a while ago.
15:53:22 <neirac> jbk, is to early for kmdb, is says loading kmdb then panics
15:53:43 <kebe> (I was having problems booting a VMware guest over the network and we discovered this.)
15:56:25 <neirac> kebe is pxe  causing that we are not able to boot then?, I'll check if that fix is on the pxe version I used
15:56:40 <kebe> ipxe not pxe
15:57:08 <kebe> It was fixed in April 2022
15:57:10 <kebe> oops
15:57:12 <kebe> April 2020
15:57:17 <kebe> (uggh, typing!
15:57:23 <kebe> )
15:59:25 <kebe> I *do* seem to recall John saying it could still happen even after this fix, given the "right" memory layout for a given EFI.
15:59:38 <neirac> but seems the error message is different, it goes out of memory on the multiboot2 code, here is this is case is booting the kernel but panics on do_bop_phys_alloc, maybe I'm confused and is the issue is related 
16:01:11 <neirac> kebe the fix is there ab25dde3d656adfccecb04882b60849655e36be2  in ipxe
16:01:32 <kebe> Yes. Correct.
16:11:19 <neirac> kebe this has more information https://smartos.org/bugview/OS-8138 , that explains more things 
16:13:29 <kebe> Oh yes.  You're attempting a SmartOS boot so this fix (which may need to be upstreamed?) is there, right?
16:13:54 <kebe> Sorry that's all paging back into my head now.
16:15:23 <neirac> kebe yes, commit ab25dde3d656adfccecb04882b60849655e36be2 in ipxe has all those tickets
16:17:26 <kebe> And you're booting into SmartOS, not another distro, right?
16:18:11 <neirac> kebe yes, I'm booting smartos using netboot.smartos.org/smartos.ipxe
16:18:33 <kebe> Okay, so it's not, "Shit my distro needs this fix."
16:19:44 <neirac> to do that I just copied the  triton ipxe I compiled from github that according to gitlog has those fixes, then in the ipxe shell chain netboot.smartos.org/smartos.ipxe and choose the latest image from the menu
16:20:49 <kebe> I'm assuming earlier images from the menu ALSO fail?  (because if any of them succeed clearly there's a recent problem, even if it's something like "feature X bloats memory too much".)
16:21:00 <kebe> I expect any image to fail, but it's a good test to run.
16:21:06 <jlevon> there are multiple ways it could still fail :/
16:21:27 <kebe> Thank you for confirming my memory of our conversations from 2020.
16:22:10 <kebe> (See 1059 US/Eastern comment...)
16:23:23 <neirac> kebe let me try old images from the menu
16:31:11 <neirac> kebe image  20221103T001803Z also failed, well this just seems to happen in oracle cloud if triton usually uses pxe to boot
16:31:45 <kebe> Okay.  I was kinda hoping the old ones would fail equally.  Means we don't have to regression-hunt.
16:50:22 <tsoome> the dboot/early kernel memory allocations happen from memory after kernel+modules, I'm not whet the upper limit there is (memory hole/io space or something?)
17:15:57 <dangergrrl> okay so, illumos is not the system V I worked on at all
17:16:13 <dangergrrl> some of the userspace is likely close to the same
17:18:07 <kebe> AIUI (and I didn't join Sun until the last days of 2.5.1 development), SunOS 5.0 branched from SysV once it was released under "Solaris 2".
17:18:13 <kebe> (i.e. 1991)
17:19:26 <dangergrrl> aha, i worked for IBM in 1993, DEC in 1995, Tandem in 1996 and a couple of others in between
17:19:46 <dangergrrl> Tandem swore we were using SVR4 code
17:19:59 <dangergrrl> TLB2 i think they called it
17:20:20 <dangergrrl> but it was really close to unixware code i worked on in other projects
17:20:57 <dangergrrl> but kebe that would explain it
17:21:59 <dangergrrl> the yacc code i still haven't fixed looks like it's barely fixed from 1970s yacc
17:22:51 <dangergrrl> the locking code is much modernized
17:22:59 <dangergrrl> like much less locking
17:23:33 <dangergrrl> KS_HOLD0LOCKS() was a common svr4 kernel thing
17:23:56 <dangergrrl> (kernel space, i hold no locks)
17:25:03 <dangergrrl> anyway the code looks much nicer
17:25:24 <dangergrrl> and att/novell code never had documentation
17:25:51 <dangergrrl> you had to ask random people if they understood what you were working on
17:31:34 <dangergrrl> this is actually much nicer than when I was at Intel, *someone* usually understands what I am working on
17:31:51 <neirac> kebe I made a change to test and now seems that is booting
17:32:11 <dangergrrl> neirac, yay for booting!
17:32:35 <dangergrrl> any progress on getting risc-v hardware to this project?
17:32:35 <neirac> dangergrrl :) 
17:32:53 <neirac> kebe I'll try kmdb now as pit is broken in oci
17:33:19 <dangergrrl> neirac, I wasn't joking, risc-v would be perfect for illumos but i can't afford the stuff
17:33:30 <dangergrrl> the linux laptop is like $2k
17:34:11 <dangergrrl> and there was the announcement of 128 core server risc-v chips
17:34:30 <dangergrrl> i can do assembly!
17:34:52 <dangergrrl> someone needs to donate hardware even if it's in sweden
17:35:49 <dangergrrl> btw, this software is barely less complicated than old AIX
17:36:50 <dangergrrl> anyway, dropping sparc, maybe a good idea, dropping portability is not
17:37:27 <rmustacc> I don't think anyone has suggested we drop portability.
17:37:40 <rmustacc> However, just because you ask in the ether for other people to do work doesn't mean it will happen.
17:37:43 <dangergrrl> rmustacc, sparc was dropped
17:38:02 <rmustacc> Correct, we did, but not because of portability.
17:38:09 <dangergrrl> i'm not asking for anyone to port to anything
17:38:31 <dangergrrl> i just don't have the hardware for another suitable target
17:38:35 <dangergrrl> ARM is not
17:38:37 <rmustacc> Use a VM.
17:38:50 <rmustacc> You can use qemu just fine to get going if it's something you actually care about.
17:39:15 <rmustacc> Get to the point that the overhead of binary translation is actually a problem.
17:39:15 <dangergrrl> I actually have a Zedboard
17:39:31 <dangergrrl> but i don't think it will run rv64
17:39:53 <dangergrrl> I just don't have enough gates
17:39:59 <dangergrrl> on my fpga
17:41:07 <dangergrrl> i don't want this to be flatlined just because x64 dominates the market right now
17:41:38 <dangergrrl> rv64 is the future of OSS
17:42:25 <dangergrrl> so, port to qemu? just like i am a hardware dev... that's an option
17:42:31 <rmustacc> I'm not trying to flatline it. Just trying to point out that you asking folks to do itdoesn't make it happen.
17:42:51 <rmustacc> If you want to, then great.
17:43:16 <rmustacc> Using emulation is the classic approach fwiw. Even was true of unix ports a long time ago.
17:43:30 <dangergrrl> this is unix
17:44:25 <dangergrrl> i have classic differences with sun
17:44:32 <dangergrrl> but this is unix
17:45:19 <rmustacc> not sure how that's relevant?
17:45:28 <dangergrrl> i will run away and run linux if you ask
17:46:01 <dangergrrl> emulation is the classic approach and you win
17:46:25 <rmustacc> All I was trying to do was point out an approach to make progress on something you wanted to do.
17:46:40 <dangergrrl> and i wasn't asking you to port to rv64
17:46:42 <rmustacc> This isn't a contest about winning, losing, or telling you what to do.
17:47:02 <rmustacc> you asked if the project had done it and with a tone of well why not.
17:47:11 <dangergrrl> just trying to figure out i can iwth the limited resources i have
17:47:35 <rmustacc> I'd recommend getting to know the existing system, fix some bugs, and actually use it.
17:47:41 <dangergrrl> ok, i suggested you might want to
17:47:49 <dangergrrl> i use it
17:47:56 <dangergrrl> i have posted bugs
17:48:10 <dangergrrl> i have not fixed the bug in yacc i was assigned
17:48:19 <dangergrrl> ok, accepted
17:49:33 <dangergrrl> I use it
17:49:47 <dangergrrl> it doesn't perform over linux for me
17:50:02 <dangergrrl> but linux has 10G people
17:50:07 <dangergrrl> i am patient
17:50:38 <rmustacc> If it doesn't perform the way you want, there's a great place to dig in and improve things.
17:50:59 <dangergrrl> the non canonical stuff bothers me but linux is more noncanonical
17:51:26 <dangergrrl> i like the init replacement better than systemd
17:51:42 <rmustacc> Our goal isn't to be a canonical unix.
17:51:47 <neirac> ok is related to OS-8138 , I modified the 1gb limit and smartos boots but hangs on the pit issue, but I cannot use kmdb because If I do it it does not boot or takes so long that  
17:52:34 <dangergrrl> danke
17:53:14 <dangergrrl> but unix was something i helped make when i was young so i will always be attached to it
17:54:10 <dangergrrl> forgive me
17:56:22 <dangergrrl> i have not read this projects goals
17:56:33 <dangergrrl> so perhaps i should
17:56:57 <rmustacc> There's nothing to forgive, don't worry about it.
17:57:26 <dangergrrl> is there a link, please or should i just google it?
17:59:53 <dangergrrl> if i don't know the goals, i don't know if i align with them, i just saw really cool software that i helped create and i volunteered
18:00:59 <dangergrrl> this is mostly a really good server OS except it fails with modern windows and OSX
18:01:56 <dangergrrl> the guy who was doing that work was caught in a war... that sucks
18:02:45 <dangergrrl> can i have his bug/defect?
18:02:57 <rmustacc> I would start at https://illumos.org/docs/about/ and you can read from there.
18:03:18 <rmustacc> What issue number are you referring to?
18:20:21 <rmustacc> neirac: OK, so we're back to the point where getting something in as an exception for whatever is going on for the pit would help?
18:24:18 <neirac> rmustacc now booting using pxe works, if I modify the 1GB limit for allocation for ipxe to 512mb I just tested with an arbitrary number  https://smartos.org/bugview/OS-8138, the thing is that now illumos boots but is stuck as pit is broken , but I still cannot go into kmdb because choosing that option from the pxe menu it does not loads the kernel is frozen, I'll try using a smartos.ipxe image that has pit_is_broken hardcoded to 1
18:30:58 <neirac> rmustacc just to rule out that is stuck by other reason but at least there is progress 
18:51:31 <jclulow> neirac: can I ask why you're using PXE here and not just pushing a regular cloud disk image of some kind?
18:52:34 <neirac> jclulow sure, I'm on the free tier and cannot use custom images
18:52:43 <jclulow> Ahh
18:53:01 <jclulow> What a ridiculous restriction 
18:54:05 <neirac> jclulow yes, things would be easier, I think the idea is to force the move to a paid account instead of just using the free one
18:54:08 <kebe> Wouldn't expect anything less from ORCL...
18:54:24 <jclulow> Probably I would boot an existing Linux image and just dd my disk image over the contents and reboot then haha
18:54:25 <kebe> And honestly a free-tier from ANYONE is gonna do things like that.
18:54:51 <jclulow> kebe: Only at places that don't respect open source developers trying to do platform enablement work
18:55:06 <neirac> jclulow we tried dd the iso to the disk, but the smartos installer fails when doing so
18:55:24 <neirac> it complains about the partitions
18:55:32 <jclulow> neirac: I wouldn't dd the ISO, I would prepare an installed system image somewhere else
18:55:43 <kebe> jclulow beat me to the punch.
18:55:47 <jclulow> And dd that onto the disk
18:56:04 <kebe> Esp. SmartOS with a bootable `zones`,  you need to do that.
18:56:15 <jclulow> After finding some blog post about how to pivot root a Linux system so that you can unmount / and overwrite it
19:04:36 <neirac> I just saw one of openbsd, but they imply dd to the disk as susual, is just smartos complains on partitions when the installer is going to create the pool
19:08:25 <kebe> I take it this VM boots EFI not BIOS?
19:08:45 <neirac> kebe yes efi
19:09:19 <kebe> So the disk-bootable zones pool needs to have been created with `zpool create -B`, which the modern SmartOS installer will do.
19:10:05 <kebe> Josh's advice applies, just make sure you grab the whole disk.
19:11:03 <kebe> For this example 32GB bootable zones pool disk:
19:11:16 <kebe> * Partition  Tag  Flags      Sector       Count      Sector  Mount Directory 
19:11:20 <kebe>        0     12    00          256      524288      524543 
19:11:24 <kebe>        1      4    00       524544    66567903    67092446 
19:11:30 <kebe>        8     11    00     67092447       16384    67108830 
19:12:01 <kebe> partition 0 from prtvtoc(8) is the EFI System Partition (ESP).
19:16:09 <neirac> so I could just dd smartos, the. go to a shell and type zpool create -B 
19:20:47 <kebe> You also need to make sure OUR loader is in the ESP, though.  This is all stuff `piadm bootable -e` does.
19:52:00 <jclulow> If you make a SmartOS disk image that works in, say, QEMU
19:52:06 <jclulow> booting with UEFI on the serial port etc
19:52:32 <jclulow> And then you take that whole disk image and dd it to /dev/sda or whatever the whole disk device is in your Linux
19:52:47 <jclulow> I suspect it will work about as well as anything else
19:53:23 <jclulow> I would probably either match the size of the target disk with the image that is being created, or zero the parts of the disk that your image does not cover
19:53:45 <jclulow> (there are backup UEFI labels at the end of the device that you'll want to either overwrite or clear out that could confuse things)
20:16:46 <neirac> jclulow thanks I'll try that, I'll try omnios also I have not tried that
21:25:59 <tsoome> um, have I missed something about RTI of 15227 and 15255 or are people just busy otherwise?:)
21:27:17 <dangergrrl> hi tsoome and thank you for your contributions to illumos this year
21:27:27 <dangergrrl> sorry, i know it's off topic
21:27:33 <tsoome> ou, thanks:)
21:27:55 <dangergrrl> it's my favorite foss project
21:28:13 <tsoome> .oO same procedure as every year..
21:28:35 <dangergrrl> i want to tank jclulow and danmcd  too
21:29:01 <tsoome> fortunately foss is something you can spend whole life on;)
21:29:03 <dangergrrl> tsoome, i hope i am allowed to thank people for the holidays
21:29:20 <gitomat> [illumos-gate] 15222 pcieadm pcie.slotctl.pwrflt description is misleading -- Robert Mustacchi <rm⊙fo>
21:29:25 <dangergrrl> tsoome, unless you are larry ellison
21:29:27 <tsoome> I'm sure you are:)
21:29:57 <tsoome> ok, lets see why those acl tests are failing...
21:30:08 <dangergrrl> sorry but he seems like the grinch
21:30:25 <dangergrrl> you won't even discuss him :)
21:30:40 <tsoome> na, if you cant change it, no need to worry about it;)
21:33:12 <dangergrrl> well, i didn't work there and i hate larry dor what he did to other teams
21:34:30 <rmustacc> tsoome: I'll go look.
21:35:04 <tsoome> thanks!:)
21:35:12 <dangergrrl> lol
21:35:43 <dangergrrl> my friend suggests we destroy larry by having him buy twitter at 20BN
21:35:59 <dangergrrl> sorry but it was funny
21:36:29 <tsoome> then there would be poll about if he should step back....
21:36:45 <rmustacc> tsoome: On 15227, wasn't sure if kebe was planning to follow up or not. 15255 replied to.
21:37:32 <tsoome> yep, thanks, I just have to verify if I actually have that patch built+installed already:)
21:44:31 <kebe> jinni illumos 15227
21:44:44 <kebe> fenix illumos 15227
21:44:45 <fenix> BUG 15227: libsmb: variable is used uninitialized (Pending RTI)
21:44:45 <fenix> ↳ https://www.illumos.org/issues/15227 | https://code.illumos.org/c/illumos-gate/+/2539
21:46:49 <kebe> Sorry about that tsoome...
21:47:03 <tsoome> no worries!
21:47:24 <kebe> You have new mail.
21:48:49 <dangergrrl> i need gugs
21:49:04 <dangergrrl> my buyout of oracle failed
21:49:13 <tsoome> thanks!:) 
21:49:27 <dangergrrl> oops
21:49:32 <dangergrrl> sorry
21:49:45 <tsoome> I still have my side of work to be done with few others:)
21:50:02 <dangergrrl> i will apologize and keep humor limited
21:51:14 <gitomat> [illumos-gate] 15227 libsmb: variable is used uninitialized -- Toomas Soome <tsoome⊙mc>
21:59:30 <gitomat> [illumos-gate] 15255 loader: replace nbsp in forth scripts by space -- Toomas Soome <tsoome⊙mc>
22:14:24 <tsoome> https://code.illumos.org/c/illumos-gate/+/2518  is still needing reviews, then all libdladm cleanups are reviewed:)
22:14:25 <fenix> → CODE REVIEW 2518: 15196 libdladm: comparison of integers of different signs (NEW) | https://www.illumos.org/issues/15196
23:00:34 <veg> hey there! are there any plans to sync with OpenZFS? 
23:06:18 <richlowe> it happens as things are wanted/desired/time permits
23:06:29 <richlowe> faster for bug fixes etc, usually.