So then that's your way forward there jbk.

[illumos-gate] 15884 NVMe driver panics on xcp-ng when trying to enable volatile write cache -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16300 zoneadmd: 'restrict'-qualified parameter aliases with argument 4 -- Toomas Soome <tsoome⊙mc>

hi all, how to try to debug UEFI boot process ?

i have reboot if try to boot in UEFI

reboot when exactly?

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

tsoome_: paste.dilos.org/?44a0a7dabd58e4a2#T…JgCYl92MUoEqEvz2QefCfyo0zmlbPykOOk=

i have no ideas about reboots

cycle reboots

em, ok, you get somewhere at the end of dboot, probably blowing up when preparing to or switching to 64-bit mode

so you have no kmdb yet

yes, i have no kmdb

and it is not in loader any more

and legacy boot works as well

uefi failed

your last message is in dboot_startkern.c

so, if it is blowing up there, it means there is an issue about memlists[] array

memlists has 50 slots.

dboot_process_mmap() should blow up if there are more than 50 entries.

you can try this one to see if it will help some, but I doubt it will: code.illumos.org/c/illumos-gate/+/2292

→ CODE REVIEW 2292: 14890 unix: dboot should use efi memory map if present (NEW) | illumos.org/issues/14890

tsoome_: it is vmware

what you can do is to check if there is firmware update - if we get planted some unusable memory in middle of bss...

ah, vmware...

tsoome_: it was works as well some time ago and after some latest illumos updates failed with new ISO

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

tsoome_: paste.dilos.org/?790b72b213cd0db6#L…DQKkqcU0fAAU0i/re0aC9T4Aosqmz1floY=

memap output

line 6 is what we can use

um, thats 120MB?

it is vmware esxi 6.7 , UEFI boot option

is it installer iso blowing up? if you install using bios boot, does it blow up on first boot from hdd?

tsoome_: legacy bios works as well, do i need clean disks ?

i just added new SATA drive, no installation yet on this disk

installer does not create ESP?

tsoome_: i didn't try bias yet with new hdd, i tried bios version before and it was fine

i try investigate efi failed boots

I mean, if you install it from bios boot and then use UEFI boot to boot from hdd

i didn't try to do it yet

i wanted to try iso loads

and i see cycle reboots

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.

tsoome_: have to plans integrate your change for dboot?

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).

(All of this just to get a NUC to boot as a CN. Uggh.)

anyone know if usb tethering from an android phone works in illumos?

igork as usual, need reviewers:)

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...

err that was for danmcd, sorry

:)

tsoome_: your proposed update for dboot doesn't fix my uefi issue

tsoome_: i'm able to load legacy bios mode, but EFI not working

as I suspected. so the question still is, can it boot from hdd, after install?

also, if you can add serial port to that vm, vmware may dump registers on it, that may also give some clues.

tsoome_: i'll try hdd boot

tsoome_: i tried serial console, but i posted to paste hat i have on console

it may have been feature only on fusion...

tsoome_: all works with efi boot from hdd

tsoome_: it failed to reboot only if iso boot

i have no ideas why it failed

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.

vmware vm's have option to enable gdb stub and so it is possible to use gdb remote to see what is going on.

tsoome_: ok, i think we need try to found a max memory block for starting of loader