On August 23, 2025 8:08:25 PM UTC, David Niklas <[email protected]> wrote:
>On Wed, 20 Aug 2025 18:07:10 +0200
>"Frantisek Rysanek" <[email protected]> wrote:
>>
>> Hello David,
>>
>> initially I wondered if some data type could possibly overflow in
>> Grub :-) Your volume of RAM is not necessarily all that mainstream...
>>
>> I second Felix Miata's pointer to the launchpad bug entry.
>> It does contain interesting tips.
>>
>> I'm not sure if Grub is a 32bit beast, or 64bit.
>> Its UEFI interface should be ready for 64bit operation, IMO...
>> because almost all modern UEFI "firmwares" are 64bit nowadays.
>> Now... it would be interesting to take a look at your "e820 memory
>> map". Which may be difficult to get, if you cannot boot Linux.
>> Can you, actually?
>> Can you at least start the installer of some distro, and get a copy
>> of the early dmesg?
>
>As this is my main PC, I can't reboot a bunch at this time, but I'd
>certainly be willing to do so in time. But how would I do that?
>
>> Ahh... Google is telling me that the UEFI Shell contains the MEMMAP
>> command - see here:
>>
>> https://support.hpe.com/hpesc/public/docDisplay?docId=sd00002251en_us&;
>> page=GUID-D7147C7F-2016-0901-0A6D-0000000009DD.html
>
>Hmm, IDR seeing a UEFI shell option, so I'll have to find a UEFI shell
>file to test with. Do you know of a good option? I'm rather hesitant to
>just google it as it's a big security risk to use random SW from the
>internet.
>
Iirc: The Arch Linux install ISO also has the UEFI shell. So putting the
installer on a USB stick and selecting "EFI shell" in the boot menu of the
installer should do the trick. That should give you an EFI shell with the most
important commands.
Otherwise you can of course always compile the UEFI shell yourself, but that is
a bit tedious in my opinion.
>> Actually it is wrong to still call this the "e820 memory map", as
>> this is a legacy real-mode BIOS service number. The UEFI equivalent
>> is BootServices->GetMemoryMap().
>>
>> https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/15_System_Address_Map_In
>> terfaces/int-15h-e820h---query-system-address-map.html
>>
>> https://wiki.osdev.org/Detecting_Memory_(x86)#What_about_on_UEFI?
>>
>> Apparently, in Linux booting in UEFI mode, you still get e820
>> mentioned on the lines related to the memory map :-)
>
>lol
>
>> Why I'm asking about the memory map:
>> to this day, there seems to be a magical boundary at 4 GB (the 32bit
>> address space).
>> The physical memory space contains not only DRAM, but also many
>> memory-mapped peripheral devices. Such as the IOMEM windows of
>> graphical cards, bits related to the inner workings of PCI and PCI-e,
>> and whatnot. During the years of evolution, the summary volume of
>> memory space needed for these devices keeps growing.
>> Traditionally, this was mapped under 4 GB (from the top of the memory
>> space creeping down). Last time I investigated this, I've seen
>> machines, about 8th-gen Core or thereabouts, that ended up booting
>> with about 2 GB of available DRAM under 4 GB, the rest of the 32bit
>> space being taken for various "IO resources", mostly coming from
>> PCI-e. The rest of your physical DRAM gets mapped in one big chunk
>> above 4 GB.
>> Looking forward, it makes good sense to map the various IO resources
>> above 4 GB, thus making more DRAM accessible under 4 GB (or in fact
>> the 4GB boundary becomes irrelevant / no longer a boundary).
>> Which is a problem for some OS and maybe bootloaders, that are still
>> 32bit. I cannot give you a good example now - most of these could
>> only boot in legacy BIOS mode anyway, and with the departure of the
>> CSM, this would apper no longer to be a relevant issue...
>>
>> What I'm hinting at: even on 64bit x86 PC's, which is almost all
>> nowadays, you can still sometimes find an option in the BIOS/UEFI
>> setup, to boot with resources mapped under 4 GB of physical address
>> space (avoid mapping IOMEM resources above 4 GB = reachable to 64b
>> capable software only). If you can find this in your BIOS, it might
>> make a difference.
>
>There is no CSM on this system, although I have seen that before.
>
>> Then again, if your machine is UEFI-only, perhaps that option is no
>> longer there...
>>
>> Actually, I've just downloaded a BIOS manual for your motherboard
>> (the absolute URL is about 6 lines, not pasting it here).
>> https://www.asus.com/cz/motherboards-components/motherboards/tuf-gamin
>> g/tuf-gaming-z890-plus-wifi/helpdesk_manual?model2Name=TUF-GAMING-Z890
>> -PLUS-WIFI
>>
>> On page 59, chapter 6.3, there's an entry labeled
>> System Agent (SA) Configuration
>> Memory Configuration
>> Memory Remap
>> Enable/Disable Memory Remap above 4GB
>>
>> ... might be improper wording. They probably actually mean PCI IOMEM
>> resources, rather than DRAM. The point should be, for you to decide,
>> whether the drivers in your OS can cope with PCI-e IOMEM windows
>> mapped above 4 GB. If not, and you allow the high mapping, your
>> kernel probably won't boot. Probably because it's compiled for 32bit
>> mode :-)
>
>I'll try changing that. My kernel is 64 bit.
>
>> If you have a 64b kernel, and you permit mapping of IOMEM resources
>> above 4GB, you should end up with more contiguous DRAM mapped *under*
>> 4 GB. Or just the system memory map being stacked in a different way,
>> more casually. Which may or may not alleviate your issue.
>
>Exercises in futility are always fun. ;)
>
>> I recall reading a note, at the link mentioned by Mr. Miata, that
>> GRUB is not good at looking for a bigger chunk of RAM available. That
>> the catch really is, that the UEFI memory map contains some smaller
>> chunks available at the start of the list, that happen to be too
>> small for Grub + initrd... Which would be just a pesky algorithmic
>> laziness, and could bite you even with loads of free RAM and even if
>> your software is all 64bit -- provided that the UEFI happens to map a
>> small chunk at the start of its "map" (a listing of memory blocks).
>>
>> Would you consider trying rEFInd ?
>> https://sourceforge.net/projects/refind/
>> Apparently it can load a kernel directly = doesn't need grub...
>>
>> Frank
>
>I'll try that and get back to you.
>
>Thanks,
>David
>
>PS: Felix, "grub loading initial ramdisk error out of memory" was my
>search string on DDG. It makes a big difference what you search with
>sometimes.
>
