00:00:32 So then that's your way forward there jbk. 00:39:34 [illumos-gate] 15884 NVMe driver panics on xcp-ng when trying to enable volatile write cache -- Robert Mustacchi 07:05:55 [illumos-gate] 16300 zoneadmd: 'restrict'-qualified parameter aliases with argument 4 -- Toomas Soome 16:50:50 hi all, how to try to debug UEFI boot process ? 16:51:23 i have reboot if try to boot in UEFI 17:35:31 reboot when exactly? 17:41:29 if you have ok prompt, you can enter: grab_faults and then try to boot and see if you get register dump. if the reboot happens during kernel start, you can try the usual -k -B prom_debug=true,kbm_debug=true 17:59:18 tsoome_: https://paste.dilos.org/?44a0a7dabd58e4a2#TYkxz1tdjJgCYl92MUoEqEvz2QefCfyo0zmlbPykOOk= 17:59:39 i have no ideas about reboots 17:59:52 cycle reboots 18:01:11 em, ok, you get somewhere at the end of dboot, probably blowing up when preparing to or switching to 64-bit mode 18:01:21 so you have no kmdb yet 18:01:40 yes, i have no kmdb 18:01:42 and it is not in loader any more 18:01:51 and legacy boot works as well 18:01:57 uefi failed 18:04:08 your last message is in dboot_startkern.c 18:05:25 so, if it is blowing up there, it means there is an issue about memlists[] array 18:07:26 memlists has 50 slots. 18:11:00 dboot_process_mmap() should blow up if there are more than 50 entries. 18:14:18 you can try this one to see if it will help some, but I doubt it will: https://code.illumos.org/c/illumos-gate/+/2292 18:14:19 → CODE REVIEW 2292: 14890 unix: dboot should use efi memory map if present (NEW) | https://www.illumos.org/issues/14890 18:15:50 tsoome_: it is vmware 18:16:12 what you can do is to check if there is firmware update - if we get planted some unusable memory in middle of bss... 18:16:17 ah, vmware... 18:17:06 tsoome_: it was works as well some time ago and after some latest illumos updates failed with new ISO 18:20:05 well, the loader memmap command will print the efi memory map and we need to confirm there is anything unusual in our kernel memory area 18:21:20 tsoome_: https://paste.dilos.org/?790b72b213cd0db6#Lg2d8ELf8DQKkqcU0fAAU0i/re0aC9T4Aosqmz1floY= 18:21:30 memap output 18:22:11 line 6 is what we can use 18:23:54 um, thats 120MB? 18:24:34 it is vmware esxi 6.7 , UEFI boot option 18:24:48 is it installer iso blowing up? if you install using bios boot, does it blow up on first boot from hdd? 18:25:52 tsoome_: legacy bios works as well, do i need clean disks ? 18:26:17 i just added new SATA drive, no installation yet on this disk 18:26:33 installer does not create ESP? 18:27:50 tsoome_: i didn't try bias yet with new hdd, i tried bios version before and it was fine 18:28:16 i try investigate efi failed boots 18:28:18 I mean, if you install it from bios boot and then use UEFI boot to boot from hdd 18:28:37 i didn't try to do it yet 18:29:30 i wanted to try iso loads 18:29:46 and i see cycle reboots 18:32:03 the problem with UEFI is, till you have to use boot services, you can not really control where from firmware is allocating the memory - and the UEFI API can allocate as it will need. so you can get something planted where our kernel is going to be put. 18:35:06 tsoome_: have to plans integrate your change for dboot? 18:35:37 tsoome_: I spent Friday trying to get Triton's iPXE to supply a FRAMEBUFFER tag and everything essentially went to shit... I hope 14980 might help me a bit (though I expect there's more shit on my end). 18:35:49 (All of this just to get a NUC to boot as a CN. Uggh.) 18:41:07 anyone know if usb tethering from an android phone works in illumos? 18:41:25 igork as usual, need reviewers:) 18:43:20 danieli yes, currently the loader does create the smap like memory map to pass to kernel and dboot will create memlists from it; then I realized that dboot should be able to parse MB2 efi memory maps to support other bootloaders - so I did create that update... 18:43:36 err that was for danmcd, sorry 18:45:42 :) 21:40:58 tsoome_: your proposed update for dboot doesn't fix my uefi issue 21:41:53 tsoome_: i'm able to load legacy bios mode, but EFI not working 21:43:49 as I suspected. so the question still is, can it boot from hdd, after install? 21:55:41 also, if you can add serial port to that vm, vmware may dump registers on it, that may also give some clues. 21:56:59 tsoome_: i'll try hdd boot 21:57:35 tsoome_: i tried serial console, but i posted to paste hat i have on console 21:59:24 it may have been feature only on fusion... 23:07:14 tsoome_: all works with efi boot from hdd 23:07:37 tsoome_: it failed to reboot only if iso boot 23:08:13 i have no ideas why it failed 23:10:47 so the direct cause is likely the size of your "miniroot" - that is boot archive. The problem is, with UEFI, we need to allocate memory for items we load, and that does change the memory maps a lot, especially if we allocate very large chunks. Why exactly do you get the reset - I guess the best option to debug it is with gdb stub. 23:12:14 vmware vm's have option to enable gdb stub and so it is possible to use gdb remote to see what is going on. 23:25:54 tsoome_: ok, i think we need try to found a max memory block for starting of loader