GNU GRUB - Bugs: bug #64471, grub efi memory allocation...
You are not allowed to post comments on this tracker with your current authentication level.
bug #64471: grub efi memory allocation (efi/mm) does not work on every machine
Submitter: | Alexey Kuznetsov <axet> | ||
Submitted: | Tue 25 Jul 2023 06:04:05 PM UTC | ||
Category: | Booting | Severity: | Major |
Priority: | 5 - Normal | Item Group: | Software Error |
Status: | None | Privacy: | Public |
Assigned to: | None | Originator Name: | |
Open/Closed: | Open | Release: | other |
Release: | Reproducibility: | Every Time | |
Planned Release: | None |
Jump to the original submission
Fri 28 Jul 2023 01:33:42 PM UTC, comment #24: |
Alexey Kuznetsov <axet> |
Fri 28 Jul 2023 01:31:50 PM UTC, comment #23: What I understand from Paging is that I had to request memory from efi using allocate_pages then check if pages table contains this virtual address, so it was mapped correctly by the efi.
|
Alexey Kuznetsov <axet> |
Thu 27 Jul 2023 08:28:58 PM UTC, comment #22: Ok. I simplified the patch, now it does not change grub_efi_allocate_pages_real. Wild guess does it fix a) issue, since grub_efi_mm_add_regions only affecting grub_malloc?
|
Alexey Kuznetsov <axet> |
Thu 27 Jul 2023 08:20:51 PM UTC, comment #21:
|
Vladimir Serbinenko <phcoder> |
Thu 27 Jul 2023 08:03:16 PM UTC, comment #20: Ok I understand now.
|
Alexey Kuznetsov <axet> |
Thu 27 Jul 2023 07:37:52 PM UTC, comment #19:
|
Vladimir Serbinenko <phcoder> |
Thu 27 Jul 2023 06:45:41 PM UTC, comment #18:
|
Alexey Kuznetsov <axet> |
Thu 27 Jul 2023 06:28:52 PM UTC, comment #17:
|
Vladimir Serbinenko <phcoder> |
Thu 27 Jul 2023 06:20:29 PM UTC, comment #16:
|
Alexey Kuznetsov <axet> |
Thu 27 Jul 2023 05:57:27 PM UTC, comment #15: Where do you check the page table? |
Vladimir Serbinenko <phcoder> |
Thu 27 Jul 2023 05:35:17 PM UTC, comment #14: Desktop e820 with 32GB output.
|
Alexey Kuznetsov <axet> |
Thu 27 Jul 2023 05:05:00 PM UTC, comment #13: I made it work by adding smart memory patch as I described below in comment 9. Here is a code. It working!
|
Alexey Kuznetsov <axet> |
Thu 27 Jul 2023 04:52:19 PM UTC, comment #12: When I said "no patches" I mean grub 2.06+argon2 patches+new grub2.12 memory patches. no bigmem (4GB+) patches. |
Alexey Kuznetsov <axet> |
Thu 27 Jul 2023 04:37:16 PM UTC, comment #11: Without any patches (<4GB usage range). On desktop Grub corrupt screen when trying to allocate a lot of memory. Looks like it touching the regions of memory it should not touch. Photo attached. |
Alexey Kuznetsov <axet> |
Thu 27 Jul 2023 04:08:25 PM UTC, comment #10: I had to install 4GB into my machine here is a dmesg for 4GB.
|
Alexey Kuznetsov <axet> |
Wed 26 Jul 2023 02:51:52 PM UTC, comment #9: I guess we need smi-automatic GRUB_EFI_MAX_USABLE_ADDRESS variable.
|
Alexey Kuznetsov <axet> |
Wed 26 Jul 2023 12:44:46 PM UTC, comment #8: base_addr = 0x0, length = 0x92000, available RAM
|
Alexey Kuznetsov <axet> |
Wed 26 Jul 2023 10:53:41 AM UTC, comment #7: Can you post complete map from desktop as well? |
Vladimir Serbinenko <phcoder> |
Wed 26 Jul 2023 10:51:27 AM UTC, comment #6: On desktop the only memory segment larger than 1GB is at
|
Alexey Kuznetsov <axet> |
Wed 26 Jul 2023 10:32:19 AM UTC, comment #5: I have secure boot disabled all the time. Since I compile grub manually for argon2id |
Alexey Kuznetsov <axet> |
Wed 26 Jul 2023 10:25:18 AM UTC, comment #4: You are right. Not every EFI works with GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffULL. My laptop won't boot if I change it. Grub simply unable to open drive (ssd) and unlock the key. Not sure what is going on.
|
Alexey Kuznetsov <axet> |
Wed 26 Jul 2023 08:21:42 AM UTC, comment #3: It's not that simple. Some firmwares fail to map memory above 4GiB and attempt to use it will lead to a bad crash. We need to parse mapping table to be sure that those are safe to use. Can you attach your EFI memory map? Does disabling secure boot makes a difference? It increases heap usage a lot |
Vladimir Serbinenko <phcoder> |
Wed 26 Jul 2023 07:16:51 AM UTC, comment #2: My laptop wont boot with GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffULL (asus), but desktop works fine (gigabyte).
|
Alexey Kuznetsov <axet> |
Tue 25 Jul 2023 07:53:28 PM UTC, comment #1: GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffULL
|
Alexey Kuznetsov <axet> |
Tue 25 Jul 2023 06:04:05 PM UTC, original submission:
Hello!
|
Alexey Kuznetsov <axet> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 8 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2023-07-27 | axet | Attached File | - | Added smartmem.patch, #54987 | |
2023-07-27 | axet | Attached File | - | Added smartmem.patch, #54986 | |
2023-07-27 | axet | Attached File | - | Added 2023-07-27@19.30.45.jpg, #54985 | |
2023-07-25 | axet | Attached File | - | Added lsmmap2.jpg, #54969 | |
Attached File | - | Added lsmmap3.jpg, #54970 | |||
2023-07-25 | axet | Attached File | - | Added grub_malloc1G-1.jpg, #54966 | |
Attached File | - | Added grub_malloc1G-3.jpg, #54967 | |||
Attached File | - | Added lsmmap1.jpg, #54968 |
Powered by Savane 3.13-02a9.
Corresponding source code
One thing to ask? Did grub has any code related to reading / parsing paging tables? Looks like it dosn't.
How to read physical memory? Is here grub_ method for that? Or should I switch to some protected mode back and forth using asm code?