[illumos-gate] 18072 SMB client to support version 3.1.1 -- Alexander Stetsenko <astetsenko⊙rc>

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?

FEATURE 17903: loader: expose addresses of firmware tables in loader env (Closed)

↳ illumos.org/issues/17903 | code.illumos.org/c/illumos-gate/+/4590

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.

is the kernel panicing, or loader?

kernel panics because loader is seeing weirdness on certain HW and passing the weirdness along to the kernel.

I have HW that tickles the weirdness.

ahh..

I wonder my NUC11 is relatively unique, or if there's a larger set of HW that tickles this?

is it UEFI or BIOS? (or both)

Respinning SmartOS right now and will be pushing a yank-from-gate relatively soon.

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.

[illumos-gate] Revert "17903 loader: expose addresses of firmware tables in loader env" -- Dan McDonald <danmcd⊙ei>

[illumos-gate] 17993 devfsadm: enable smatch and fix issues -- Andy Fiddaman <illumos⊙fn>

danmcd: what's the damage look like?

unfortunately my own hw was not revealing the issue.

kernel won't boot during init time. A pre-SmartOS-20260402 PI (which has some illumos changes in anticipation of 17903) will actually boot.

If you follow along on smartos-discuss, someone not us found this too by upgrading pre-email. :)

(To be fair, that SHOULD NOT be an issue, but it was this time.)

right, but "won't boot" covers a lot of ground

but lemme see the list archive

the direct cause for panic was psm_map_phys_new() thinking the page to be mapped is free page.

ugh

err, message was from hat_devload().

yeah, but that's how map_phys loads the mapping

I get you :)

"loading a mapping to free page"

is the memory map from UEFI missing the smbios pages?

no, loader itself was able to extract the smbios data to smbios.* variables.

Something in the wad of changes included in smartos-20260402 is where it's failing, I think, based on loader's bad information.

A community member can boot 20260319 EVEN WITH THE BROKEN LOADER.

Maybe this? illumos/illumos-gate 606e536

→ GitHub commit 606e536: 17902 unix: get firmware addresses from bootloader env (committed)

the SM3 anchor was at 0x41576000, thats about 1GB

so it fits in a native ptr too

hrmph

yep. well, its a bit of digging now to understand the cause.

at least I know where to look for test machine;)

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

which, yeah, you try to map memory that isn't.

:\

tsoome: are you doing it with the anchor and not from efi?

I don't think you and dan ever cleared up what the firmware is

uefi loader gets it from systab, yes.

acpi and smbios pointers are coming from systab.

by too much info, you mean lots of entries in map?

more types than we need

though it will also become horrific if it's heavily fragmented

because we have a static pool for early lists, unfortunately.

I keep meaning to look at what x86 does :)

so I guess I'm here because I was going to steal the code you broke? :)

tbh, I do think, we should be aware of more types than installed, reserved and pci memory;)

but granted, it needs some work....

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

right, but for instance you don't care about most of UEFI's memory

and I think we end up reserving/telling you about all of EFI, even though we're going to unmap it, etc.

rather than just the runtime bits

we have 10 lists, basically, and I would suspect we need 5

obvious "new" thing is uefi runtime memory which is needed for accessing RT callbacks.

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

(you also can define your own memory type as a sort of private interface between your bootloader and kernel)

tsoome: we have a branch where runtime services not only survive, but we use them for stuff if we want

I believe michael prototyped an EFIRT-based tod driver, for eg

oh nice...

being able to access UEFI boot variables would be rather handy

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)

(very handy on a panic and you've not setup dumps, or the dump device ends up too small)

(with a large enough system, you could give up some physmem as your dump device and have it always)

I mean, before that became economically questionable

telling the CTO I need one extra dimm in each machine in case it crashes in the first 8 seconds

and a second one in case it crashes twice..

.oO gcc.gnu.org/gcc-16/changes.html

the first Caveat there is the thing we were talking about in the bug

but I think ptribble misunderstood me completely :(

-gsctf looks interesting

fenix: illumos#16523?

BUG 16523: int8_t should explicitly be signed char (New)

↳ illumos.org/issues/16523

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

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.

so distribution can say "If you ... you should pin the ... package" on upgrade

and on the g++ package to say "if you build C++ you should know..."

(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?)

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

discard it you can add it to free memory.

Solaris calls it "deferred dump" when you save the dump in RAM and wait until after reboot to write to disk

one of the things that was invented when the SPARC org decided the world needed large diskless servers

because why not use iSCSI, even if your boot prom has no way to support iSCSI directly?

the problem is I think zfs makes that effectively untenable

that's a software problem, hardware design teams don't need to worry about those

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

heh

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

(there's a context structure which is like 100+ bytes and almost none of the fields align to byte boundaries)

so you can have a 16-bit value that starts at like bit 5 of byte 43 or things like that

(and rmustacc: thank you very much for already dealing with that insanity :P)