01:46:16 [illumos-gate] 17863 libsff_8472 test needs update to libsff_8472.out post-17827 -- Jason King 17:06:25 [illumos-gate] 17855 bhyve: VirtIO devices do not support MSI -- Andy Fiddaman 17:17:35 [illumos-gate] 17869 aio_done: concurrent pollq completions race with aio_cleanup_exit -- Andy Fiddaman 19:00:04 tsoome: https://pasteboard.co/M7aqSd1zk20m.png ever seen that before? 19:02:04 thats a lot of memory to allocate... for contiguous chunk. 19:02:30 uefi? no i have not seen it, but with uefi I would not be too surprised... 19:04:15 oh I didn't check to see if it was doing a UEFI boot or not.. I just sort of assumed it was... 19:04:47 show efi-version 19:07:35 ok it is uefi 19:07:58 let me open up this ISO image and see if I can figure out why the archive was that large.. 19:10:12 memmap will show the current map, but thats more like statistics... we can not do much about it. 19:11:37 hrm.. the boot archive itself is about 200MB.. though that's compressed... 19:12:24 i'm guessing that's probably the uncompressed amount? e.g. loader uncompresses it when it reads it into memory? 19:18:34 uncompressed, yes. because thats how our current "rootfs" image implementation is built. I guess its coming from time where ufs was considered to be good choice there and block level compression was not there at the time;) 19:20:07 or hsfs for that matter... 20:13:27 having to have every go binary have it's own copy of the go runtime probably doesn't help with size :) 20:14:14 hmm.. but even omnios seems to either take a _really_ long time, or is hanging (but it does at least jump into the kernel) 20:14:26 (it's a dell amd box) 20:20:19 why do you have go in your boot archive? 20:20:31 that should be things we need to boot and mount root, exclusively. 20:20:40 (see also why /usr/kernel, even, isn't there) 20:25:11 that depends on the desired outcome, isnt it so;) 20:25:28 sure, that's why I'm asking what the desired outcome is 20:31:01 i mean binaries written in go 20:31:16 me too 20:31:18 whicn includes our isntaller 20:31:25 ok, ok 20:31:30 and our install image 20:31:30 so it's not a boot archive it's a miniroot 20:31:48 pulls lever, moves points, switches tracks 20:32:10 though doesn't seem to matter... even this omnios ISO is hanging after it enumerates the serial ports 20:32:52 and sending an NMI (despite kmdb being set) seems to be acting like the goggles 20:32:57 (does nothing) 20:33:36 can you hit esc fast enough to play around at the prompt? 20:33:53 and then toomas can show you memory maps, etc. 20:34:50 and do your install images contain the boot archive hash? 20:34:56 if we even get far enough to try to check it :( 20:36:21 I think the first thing I would like to know is whether the memory I put the boot archive contents in actually exists 20:36:46 and the second thing is to double check it's actually memory 20:51:45 ... and of course kmdb also doesn't accept keypresses.. 20:52:20 i really need to figure out what the missing bit there... 20:53:01 because like I don't think I've found a server less than 5 years old where kmdb works from whatever BMC's KVM they have 20:53:10 well at least 5 years old... 20:57:04 not the easiest thing, given your debugger and keyboard don't work 20:57:16 but I guess I'd start on where we poll and hope for the best from there 20:57:21 printf and dreams 20:58:17 worth checking whether it never works, or whether `-d` is just too soon, too 21:01:05 dropping on at boot doesn't work at least.. 21:01:07 err in 21:02:38 i'm hoping i can maybe get SOL working 21:02:53 though every vendor makes it more complicated than it probably shuold be 21:03:00 since I think almost no one uses it (but perhaps us) 21:12:19 tsoome: if i change the serial port settings, is tehre a way for loader to 'reread' them? 21:13:07 change where? 21:13:18 in firmware? 21:15:20 well loader spits out one line and then nothing when I setup console redirection 21:16:44 your port is 115200? 21:16:50 yes 21:17:03 booting from disk? 21:17:09 ISO 21:17:12 well trying to at least 21:17:32 does it provide /boot/solaris/bootenv.rc? 21:18:02 i have no idea, i'm trying an omnios iso since it seems to be slimmer 21:18:16 and it can at least load the kernel 21:18:32 it probably does. if the firmware allows, set port to 9600 21:20:08 problem is, bootenv.rc is delivered with port settings 9600,8,n,1,- and it will override what you get from firmware... 21:21:11 (and some systems will hung when you try to do that, and some systems will just lose input till kernel driver is loaded). 21:22:31 i see loading /boot/defaults/loader.conf then nothing 21:22:38 from the serial consoel window 21:23:21 yes, because bootenv.rc does its thing.... 21:24:04 heh.. 21:24:06 yeah, that's what toomas is trying to explain I think 21:24:24 we need defaults that are good and carry through 21:24:28 but ug 21:24:44 so I changed the setting in bios to 9600... still that from loader, but then if I do select ttyb, the kernel actually prints out on ttyb 21:24:51 like, loader should know things, and should tell the OS what it learned, and the OS should trust it 21:24:56 like anything else that goes through the bootinfo 21:24:58 right? 21:25:18 or does x86 have a smarter way to get early console access? 21:25:33 https://code.illumos.org/c/illumos-gate/+/3327 21:25:34 → CODE REVIEW 3327: 16330 loader: SPCR needs better handling (NEW) | https://www.illumos.org/issues/16330 21:26:42 we can make some steps to protect us, but IMO its time to nuke tty lines from bootenv.rc. 21:27:37 right that's what I meant, shouldn't the default be "discovered from loader" 21:27:45 given here in the future, it's not really a predictable thing 21:28:08 9600,8,n,1 is not a great default anymore, and it's not obviously there's a better one 21:28:14 the 8,n,1 are fine I suppose 21:28:20 yep 21:31:15 on the plus side, using bloody seems to get to userland, but then can't find the install media... so progress 21:31:51 (given the stable was dieing after enumerating teh asy devices, I wonder if maybe some of those fixes are the difference) 21:32:42 that sounds plausible 21:32:57 unfortunately, the fixes came before the debugging help 21:33:12 but your console is on serial, so you can not boot -B disable-asy=true ?:) 21:33:31 yeah, I'd still like to figure out what needs to be done for kmdb to work better 21:33:42 on aarch64 we still don't/can't use asy, for unknown reasons 21:33:55 I keep meaning to merge the newer fixes and see if they fix the older fixes 21:34:11 rather than having an Nth copy/paste of that driver 21:35:02 kmdb as started with -kd? 21:35:48 I believe jbk had said so 21:35:57 that's why I asked if `-d` was just too soon to work in that context 21:36:23 I have considered, again on aarch64, adding a separate debug_enter later in boot when we were firing on all cylinders 21:36:30 like, just before sched() 21:36:53 so `-d` was as soon as possible, and a hypothetical `-D` was when everything would definitely work 21:37:08 kmdb does basically rely on keyboard IO port acess, but if the keyboard is usb device and they did stop providing the emulation.... then there is no keyboard for kmdb. 21:37:32 I was pretyt sure kmdb would poll usb in a weird cooperative way 21:37:39 jlevon: memory man? 21:39:43 kmdb loaded with -k may have chance for that, if it will bind itself to usb keyboard (with poll mode available), but -kd can not, usb is not available for i86pc/boot/ bits. 21:41:02 altho, it would be nice if kmdb would continue on its own when started with -kd and there is no usable input device... 21:42:02 I have no memory of kmdb doing usb io stuff. but my memory is ... weak 21:44:22 I thought I'd run into something with polledio in the name that seemed like magic that looked like it was for that, when I was porting 21:44:29 but my memory is no bettter 21:45:06 it does look like there is code that steals cons_polledio and uses it 21:45:13 but as tsoome said, not that early in boot 21:45:22 (which is where my `-D` idea came in, where it could help) 21:47:00 yeah, that exists. just dunno if or how that does usb. only ever explicitly saw it doing port io 21:47:59 yeah, probably need usb to do polling... 21:48:08 well assuming these virtual devices are presented as USB 21:51:21 richlowe: yeah, -D as you describe it makes sense as a pragmatic measure when the console is iffy. 21:51:51 oh to have PCI ID decoding in kmdb :) 21:52:29 while loader seems to dislike the serial port, after tweakign the speed in the BIOS setting, the kernel seems ok with it... 21:52:41 and omnios bloody gets to userland 21:52:53 except that we don't seem to attach any drivers for the virtual cdrom 23:25:34 tsoome: how is loader allocating that memory? is it calling AllocatePool or AllocatePages() ? 23:27:01 for modules? AllocatePages(), see efi/loader/copy.c 23:31:05 but. when we are to jump to kernel, we switch off boot services (so we will "own" the machine - no more memory map changes), we copy kernel in place (fixed location - we need to pray hard its actually usable), followed by modules -- the final location must be below 4GB or dboot will blow us up (32-bit code). 23:38:05 we should fix that 23:38:13 though nothing you can do about the fixed kernel 23:39:20 well, nothing you should do on a whim anyway 23:39:49 a pic kernel is possible, but frustrating to debug. a pie kernel is probably an adventure too far, unless you _really_ need it 23:41:08 there's downsides to all of loader relocating unix, dboot relocating unix, and unix relocating unix 23:41:29 references internal to unix, that is. 23:48:46 better have some sleep... 23:56:54 i kinda want to take the zfs bits from loader and turn it into a UEFI filesystem driver (so you could also for example have zpool / zfs commands from the uefi shell or browse a dataset (read only))