14:19:05 [illumos-gate] 18072 SMB client to support version 3.1.1 -- Alexander Stetsenko 15:31:20 If anyone is seeing kernel panics on machines that boot with fenix illumos#17903, please share what HW you booted with that induced the panic? 15:31:21 FEATURE 17903: loader: expose addresses of firmware tables in loader env (Closed) 15:31:21 ↳ https://www.illumos.org/issues/17903 | https://code.illumos.org/c/illumos-gate/+/4590 15:32:08 We're backing it out of -gate within an hour... at least one known NUC (Intel NUC 11, at least mine) acts wrongly with that loader change. 15:42:40 is the kernel panicing, or loader? 15:43:00 kernel panics because loader is seeing weirdness on certain HW and passing the weirdness along to the kernel. 15:43:27 I have HW that tickles the weirdness. 15:43:36 ahh.. 15:44:26 I wonder my NUC11 is relatively unique, or if there's a larger set of HW that tickles this? 15:44:48 is it UEFI or BIOS? (or both) 15:44:50 Respinning SmartOS right now and will be pushing a yank-from-gate relatively soon. 15:45:55 UEFI AFAICT. If there's BIOS-boot that does this I would like to know about it as well. My NUCs have nothing but UEFI, and the newer alder-lake one boots just fine with 17903 in it. 16:05:06 [illumos-gate] Revert "17903 loader: expose addresses of firmware tables in loader env" -- Dan McDonald 16:15:30 [illumos-gate] 17993 devfsadm: enable smatch and fix issues -- Andy Fiddaman 19:06:38 danmcd: what's the damage look like? 19:06:57 unfortunately my own hw was not revealing the issue. 19:07:36 kernel won't boot during init time. A pre-SmartOS-20260402 PI (which has some illumos changes in anticipation of 17903) will actually boot. 19:07:55 If you follow along on smartos-discuss, someone not us found this too by upgrading pre-email. :) 19:08:04 (To be fair, that SHOULD NOT be an issue, but it was this time.) 19:08:17 right, but "won't boot" covers a lot of ground 19:08:27 but lemme see the list archive 19:08:29 the direct cause for panic was psm_map_phys_new() thinking the page to be mapped is free page. 19:08:52 ugh 19:09:00 err, message was from hat_devload(). 19:09:12 yeah, but that's how map_phys loads the mapping 19:09:15 I get you :) 19:09:16 "loading a mapping to free page" 19:13:19 is the memory map from UEFI missing the smbios pages? 19:15:00 no, loader itself was able to extract the smbios data to smbios.* variables. 19:15:32 Something in the wad of changes included in smartos-20260402 is where it's failing, I think, based on loader's bad information. 19:15:52 A community member can boot 20260319 EVEN WITH THE BROKEN LOADER. 19:18:07 Maybe this? https://github.com/illumos/illumos-gate/commit/606e5369b416d40cdf4740c4883fa46af86e748f 19:18:07 → GitHub commit 606e536: 17902 unix: get firmware addresses from bootloader env (committed) 19:18:20 the SM3 anchor was at 0x41576000, thats about 1GB 19:21:02 so it fits in a native ptr too 19:21:10 hrmph 19:21:46 yep. well, its a bit of digging now to understand the cause. 19:22:30 at least I know where to look for test machine;) 19:26:04 on arm we pass way too much info about memory into the kernel, but I only broke it like this when I was fixing our notion of installed/avail memory 19:26:16 which, yeah, you try to map memory that isn't. 19:26:19 :\ 19:27:11 tsoome: are you doing it with the anchor and not from efi? 19:27:30 I don't think you and dan ever cleared up what the firmware is 19:27:40 uefi loader gets it from systab, yes. 19:28:08 acpi and smbios pointers are coming from systab. 19:30:22 by too much info, you mean lots of entries in map? 19:34:52 more types than we need 19:35:02 though it will also become horrific if it's heavily fragmented 19:35:15 because we have a static pool for early lists, unfortunately. 19:35:27 I keep meaning to look at what x86 does :) 19:35:47 so I guess I'm here because I was going to steal the code you broke? :) 19:35:58 tbh, I do think, we should be aware of more types than installed, reserved and pci memory;) 19:36:35 but granted, it needs some work.... 19:37:28 yes.. uefi has more types, but most of our code is more assumes a BIOS system, and tries to fit UEFI into that (due to history) than the other way around 19:39:49 right, but for instance you don't care about most of UEFI's memory 19:40:34 and I think we end up reserving/telling you about all of EFI, even though we're going to unmap it, etc. 19:40:41 rather than just the runtime bits 19:40:58 we have 10 lists, basically, and I would suspect we need 5 19:47:32 obvious "new" thing is uefi runtime memory which is needed for accessing RT callbacks. 19:52:10 yeah, for the most part it's memory available for use, memory that has errors, memory that shouldn't be touched, MMIO addresses, and possibly memory free to use, but have to wait until after ACPI is running 19:53:08 (you also can define your own memory type as a sort of private interface between your bootloader and kernel) 19:53:10 tsoome: we have a branch where runtime services not only survive, but we use them for stuff if we want 19:53:23 I believe michael prototyped an EFIRT-based tod driver, for eg 19:54:02 oh nice... 19:54:12 being able to access UEFI boot variables would be rather handy 19:55:27 also, at least on some systems, we could do the SPARC thing where dmsg persists between reboots (the 8-16k chunk of memory sits at a fixed physical and virtual address, and firmware doesn't clear that bit of memory during a reboot) 19:57:42 (very handy on a panic and you've not setup dumps, or the dump device ends up too small) 20:11:33 (with a large enough system, you could give up some physmem as your dump device and have it always) 20:11:50 I mean, before that became economically questionable 20:12:24 telling the CTO I need one extra dimm in each machine in case it crashes in the first 8 seconds 20:14:25 and a second one in case it crashes twice.. 20:25:46 .oO https://gcc.gnu.org/gcc-16/changes.html 20:27:17 the first Caveat there is the thing we were talking about in the bug 20:27:22 but I think ptribble misunderstood me completely :( 20:27:55 -gsctf looks interesting 20:27:56 fenix: illumos#16523? 20:27:57 BUG 16523: int8_t should explicitly be signed char (New) 20:27:57 ↳ https://www.illumos.org/issues/16523 20:28:25 the problem is that, as they (and I, haha) say it breaks the ABI, but also they kinda broke it _for us_ so we don't have much choice 20:28:56 so we should probably do it, but bump sonames if we have to, and maybe even get a diff of the symbol tables after a bulk build so that you can write package release notes. 20:29:13 so distribution can say "If you ... you should pin the ... package" on upgrade 20:29:52 and on the g++ package to say "if you build C++ you should know..." 20:30:40 (this is what I tried to say in the bug, so if you read the bug and you think I said something else, like I think peter did, please help me fix that?) 20:52:46 richlowe: I think I recall some discussion at Sun of how to speed up boot time in large-memory systems by deferring the boot time memory test to run mostly after the kernel was booted, using dynamic reconfiguration hooks to bring in memory as it passed the test. in-memory savecore could do the same sort of thing - firmware/previous kernel tells you free memory is from A to B, dump is from B to C; once you've pulled the dump out or decided to 20:52:46 discard it you can add it to free memory. 21:21:26 Solaris calls it "deferred dump" when you save the dump in RAM and wait until after reboot to write to disk 21:22:03 one of the things that was invented when the SPARC org decided the world needed large diskless servers 21:22:36 because why not use iSCSI, even if your boot prom has no way to support iSCSI directly? 21:23:09 the problem is I think zfs makes that effectively untenable 21:23:43 that's a software problem, hardware design teams don't need to worry about those 21:23:50 even with using a separate vmem arena for data, the zfs metadata isn't separated out from the rest of the kernel state, and it can get _very_ large 21:24:37 heh 21:25:02 i feel like intel's ice design team felt the same about about a number of aspects of this card (as I work on the driver) :P 21:25:58 (there's a context structure which is like 100+ bytes and almost none of the fields align to byte boundaries) 21:26:20 so you can have a 16-bit value that starts at like bit 5 of byte 43 or things like that 21:27:10 (and rmustacc: thank you very much for already dealing with that insanity :P)