00:58:39 [illumos-gate] 18165 Want checker for test runner files -- Gordon Ross 17:20:32 [illumos-gate] 14556 TSC calibration from HPET includes too much error -- Bill Sommerfeld 17:56:11 [illumos-gate] 18137 loader: add userboot -- Toomas Soome 18:02:39 heh.. i do wish we had been a bit more consistent in our naming.. 18:02:59 * jbk was scratching his head why 'prom-debug=1' wasn't working... because it's prom_debug 18:03:03 while it's diag-device 19:31:02 jbk: clearly it's a battlefield between fortran_identifier_style and lisp-identifier-style (going back to I think the earliest language to use each style. I may be wrong..) 19:36:47 tsoome: despite the description saying 'BIOS' on UEFI systems, is 'smap' showing all of the UEFI mappings that get passed to the kernel? 19:37:22 it does translate efi memory map to smap 19:37:53 so yes, you will get all conventional memory entries and reserved memory entries. 19:38:06 is there an easy way to see the unmapped values? (not sure if I need it yet) 19:38:35 for some reason, on windows server 2025, we're hanging in clear_boot_mappings() 19:38:40 memmap command will show efi memory map 19:39:23 hyperv? 19:39:28 so i'm adding a bit of verbosity to see if it's a specific mapping (also: I got tired of doing :c) 19:39:31 yeah 19:39:49 omni and our stuff has hyperv gen2 support (still not upstreamed) 19:40:45 though none of that really comes into play at that point of the boot process 19:41:42 memmap can differ a bit from final map, as in loader, we do not own the memory map and even switching off boot services can change memory map. 19:41:51 well.. we have to explicitly add the ISA bus and the framebuffer in the device tree off the root nexus, but we're not to the point of attaching or otherwise messing with device mapping 20:02:16 tsoome: I saw the EFI variables change, I'm not sure if you're involved? 20:02:48 something apparently well known on ARM is EFI firmware that doesn't work unless you set the virtual address mapping (_even if_ you set it to identity mapped) 20:02:57 that firmware (erroneously) doesn't relocate until that call 20:07:21 you mean https://code.illumos.org/c/illumos-gate/+/4800? yes, I have been keeping my eye on it. Yes, I'm aware the need of virtual mapping on ARM. Unfortunately gate has no arm bits, therefore amd64 is basically best we can do for now. 20:07:21 → CODE REVIEW 4800: 15017 efibootmgr for illumos (NEW) | https://www.illumos.org/issues/15017 20:09:41 i looked a bit, but have been on this boot hang all day 20:10:43 the big thing I wanted to confirm was the callign convention (it's the MS callign convention, gcc allows you to annotate a function) and re-checking the UEFI specs on XMM register usage 20:10:56 since those seem to be the big things that could be problematic 20:11:33 (at some point, it'd probably be nicer to move some of the bits into the kernel so you can also issue runtime services calls from the kernel w/o going through the driver) 20:11:53 but that can be left for the future 20:13:28 it is concentrating on variables (specifically on boot manager variables) atm. There are some traps too, linux once did let one to wipe UEFI variables and bricking the system... 20:17:31 jbk yea, I'd imagine time and shutdown/reboot callbacks... 20:18:20 actually one I'd like is if the UEFI implementation advertises support for it, you can mark a block of physical memory as 'don't clear on reset' 20:18:38 on Sparc, there's an I think 8k buffer they do that for dmesg 20:18:47 tsoome: no, I mean, the bug as described to me did not seem like an ARM bug, but a generic bug in some UEFI implementations 20:19:00 so the contents is preserved across reboots 20:19:02 so you should probably set the virtual map explicitly to an identity mapping 20:19:20 which can be _very_ helpful if the system panics without being able to save a crash dump 20:19:30 tsoome: but for some reason I thought it was your change 20:32:09 richlowe hm. https://reviews.freebsd.org/D14677 right. 20:33:13 tsoome: yeah 20:34:38 also 8.4.1 page 236 in UEFI Spec Final 2.11 20:59:02 tsoome: yeah, it says it's going to re-apply relocations etc, but apparently in broken implementations they haven't been applied in the first place :\ 21:07:50 the annoying bit is the offending firmware is probably a copy of edk-ii and they just managed to screw things up 22:19:49 does cmn_err(CE_CONT, "?....\n") buffer output before outputting on the console on a verbose boot? 22:21:49 it might depend on whether /dev/log is up 22:21:54 but I don't know 22:36:48 i wonder if i use a different value if that'll work... 22:46:33 my suspicion is that the htable_t is somehow getting messed up, and clear_boot_mappings() is getting into an infinite loop or going off into the weeds, or it's tripping over invalidating one of the entries 22:53:41 You should be able to get a breakpoint prior to that 22:53:52 and the x86 mdb manages its own paging window, so perhaps even survive it 22:54:25 I don't remember what the x86 boot cleanup does, I was having big problems understanding some stuff 22:54:35 mainly, the page tables get P_BOOTPAGES set, but _don't_ get cleared 22:54:46 and it's not obvious by inspection how that all works out for the best 22:55:04 (for the record, if they _did_ get cleared, that would screw you over exactly as you just hypothesized) 22:59:13 i can set a breakpoint a clear_boot_mappings() (and when I was stepping prior, it hangs after callign it and not after it returns)... which is why i'm focused on it.. 23:00:18 i tried to do `::bp -c ' but then mdb gets rather unhappy 23:00:32 after a while 23:00:45 and seems to trip an internal mdb assert 23:01:00 that might mean the tables are screwed and mdb can't operate its window 23:02:22 yeah, which seems like fun to figure out 23:02:25 see hat_kdi 23:02:29 for mdb's window 23:02:47 the mdb support for the x86 is visibly broken, unfortunately 23:03:08 so be careful about trusting things in i86mmu.c 23:03:20 (it also seems to be specific to at least windows server 2025 -- older versions boot just fine) 23:04:05 and while you can i guess issue hypercalls (kinda like xen) to do mapping stuff, we don't and just treat it like a regular MMU 23:04:19 at perhaps the cost of a bit of performance... 23:04:47 it's ::report_maps that's visibly busted, so perhaps the bits you need are ok 23:05:26 jbk: it is useful to write down your page table addresses while things aren't yet broken (::htables, print the ht_pfn) 23:06:02 when they become broken, is cr3 still right? are the page tables still where we think they'll be? are the page tables smashed? 23:07:48 you might be able to set write watchpoints on all the page tables, too, but it's not obvious to me if that'd necessarily work on x86 or how badly mdb would take it