06:34:08 jbk ouch.. 11:27:19 is there any way to just download a proposed changed file from gerrit? 11:28:54 every link I've tried so far is obfuscated in some way 11:44:33 If you click on the name of the file in the view, it will just show you the diff for that individual file, and the download button on that page allows you to download just the old or new version of the file 11:46:02 It does give you a zip file with a horrendously named file, but unzip -c allows you to just see it 11:51:05 yeh that's what I mean by obfuscated, I just want to grab the file, but I guess I'll have to workaround 11:53:41 Actually, unzip -qc 12:17:21 I usually do click on download and select either cherry-pick or something like and get my branch for the change 12:17:59 (and [re]name it accordingly, git branch -m or such) 14:48:07 if I have freed memory (from ::whatis fffffe0c031b3d18 is freed from kmem_alloc_160), is there still information where from it was allocated? 15:04:53 tsoome: efiserialio.c is missing a `void comc_ini(void)` function 15:05:05 which appears to be what adds the console entries to consoles 15:11:21 but even just adding the tty[a-d] structs to consoles in that, it still shows device is not present 15:11:30 for all 4 of them 15:11:46 (I'd figure if the port ids are shifted by one, then at least ttyb would show up instead of ttya) 15:13:45 yes, right, that was added when I did change from static list to dynamic. 15:15:30 but not sure how it's making the determination it's not there 15:15:48 I should find out why this stupid pointer is not removed from list of backchannel connections, then i can celebrate great success by poking loader bits:D 15:16:32 (to speed up testing, i'm testing on a win2019 server system first) 15:19:34 they have used list_t with clnt_clts.c but not with clnt_cots.c ... I wonder why... 15:23:30 ... though this is odd... i think we recognize the serial io protocol guid as 'serial io' in lsefi, but this VM with a serial port configured doesn't seem to show up in lsefi 15:26:40 though i see additional handle w/ both 'simple text input' and 'simple text output' protocols 15:26:48 but not sure how to get more details on that... 15:27:08 (this is in addition to the handles w/ stdin and stdout) 15:28:36 I just remembered, I do have something prepared, see if this is any help: https://github.com/tsoome/illumos-gate/tree/efiserialio 15:31:01 (it did turn out to be quite a bit more complicated because of different io protocols invented over the time;) 17:08:39 tsoome: my recollection is that DEBUG kernels set a bunch of kmem_flags; KMF_AUDIT enables tracking who last did something with a buffer but at first glance it only stores the last transaction (free or alloc). 17:09:37 (though maybe I'm wrong about that?) 17:12:56 it seems so, yes 17:29:10 tsoome: looks like that doesn't see the serial ports either 17:30:20 lsefi did list them, but ports do not get configured? 17:32:20 well i see a handle (aside from the ones w/ stdin and stdout) with simple text input and simple text output 17:32:26 but i don't know how to see anything else about them 17:32:55 and the serialio protocol is listed with this handle? 17:32:57 i'm assuming because there's 1 serial port configured in this VM that that is probably it 17:33:01 no 17:33:09 just simple text input and simple text output 17:33:53 does it print device path? probably not... 17:34:27 https://pasteboard.co/1cdwxgsjlZ8v.png 17:34:42 i see 17:35:07 that VenHW line is device path for this handle 17:35:24 just a moment... 17:43:19 ok, cant find that guid.... can you paste outputs from efi-show -g global -v ConIn and also ConInDev, and ConOut, ConOutDev 17:46:20 https://pasteboard.co/9aWnmHXiwPFH.png 17:46:38 presumably that's the text console 17:52:22 ConIn and ConOut are current setup, *Dev is list of possible devices. But problem with hose VenHw devices is that those are generally not documented... 18:02:07 those guids are from windows 11 hyper-v? what does azure provide? 18:02:23 I can't interact with azure 18:02:54 i was hoping if I got loader talking through the serial port on win 11, then i'd at least have a chance of doing something on azure 18:03:13 because building and then booting an image with azure adds at least another 30 minutes to each test 18:03:56 with all of the fiddling to take the blob, create an image from it, provision a vm, and then try to boot (this could all be automated, but that usually happens after everything is working) 18:05:29 the only way you can interact with the console on azure is through the serial port, hence the problem :) 18:06:17 reading/writing to the IO ports directly works for a bit until it does something that resets the VM 18:07:25 you can get screenshots from the text console, but no interaction 18:09:17 ok, so, can you test with fbsd image?;) 18:10:16 we only need confirmation of which protocol is present there. 18:12:01 hrm... the only fbsd image i can find is gen1 18:18:47 which works fine 18:18:56 except for the glacial boot disk issue 18:22:00 right, yes. because gen1 is working ok:D 18:24:46 well, ok, we can make an intelligent assumption that serialio is available there, and in that case you can verify your binary with any system with serialio protocol present. 18:25:20 oh wait.. finally found a gen2 fbsd image.. let me spin that up and see what i can see 18:25:32 :) 18:31:47 and wow.. provisioning is slow 18:35:52 it seems to have booted at least.. 18:36:19 (this is a fbsd 14 image) 18:38:08 hrm.. 18:38:36 it goes by so quick i can't escape at the loader prom 18:38:42 actually i don't think it even pauses 18:38:50 let me see if I can login and change that... 18:41:08 hrm.. autoboot_delay="-1" -- i thought that disabled the countdown timer 18:42:00 or i guess what value will let it sit at the loader prompt? 18:44:19 hrm.. this doesn't seem to have a show-efi command 19:09:58 I'm glad to see I'm not the only one who gets chatty doing these things. :) 19:14:31 but efi-show? 19:15:33 yes, i think they did kill timeouts for cloud images or something like that:) 19:22:23 it said it didn't recognize the command 19:22:35 it looks like it's maybe the loader using lua instead of forth? 19:26:01 um, efi-show should be there still 19:28:19 hrm.. i wonder if i fat fingered it earlier.. the ansi emulation on this isn't the greatest 19:29:08 or does the arrow keys not work as expected in this version? 19:30:05 https://pasteboard.co/95XtT3kHWD5G.png 19:30:15 (I think it was the arrow keys that were the problem) 19:32:14 hrm.. so this is different from the win2019 server output 19:34:11 jperkin: Gerrit is just a git remote, so I usually just pull down changes; e.g., see https://illumos.org/docs/contributing/gerrit/#5-interact-with-gerrit-using-more-advanced-git-tools 19:53:34 yeh I just wanted to grab a couple of individual patched files directly like I can with github/gitlab/etc, no matter, done now. 19:54:04 tsoome: so, that branch works on azure, but serial port doesn't work on win server unless you access the ports directly :P 19:54:07 so fun 19:59:27 jperkin: just do the "git fetch" from gerrit, then git show FETCH_HEAD:usr/src/uts/whatever.c 20:15:57 (or git cat-file blob ${rev}:${path} ) 20:37:21 jperkin: If you know the commit ID, you might also be able to point gitiles at it; e.g., https://code.illumos.org/plugins/gitiles/illumos-gate/+/f0a0e649e131c030d22a7aac9fa1cdca3f6cf31c%5E!/ 20:38:41 or a shorthand url, e.g., https://code.illumos.org/~diff/f0a0e649e 20:56:49 jbk sigh 22:20:35 i'm less concerned about the win server bits -- since kmdb and such will still work, but it is incredibly annoying 22:20:42 (what MS is doing here)