bugGNU GRUB - Bugs: bug #39861, Grub2 collapses unknown e820...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #39861: Grub2 collapses unknown e820 memory types to reserved

Submitter:  Andrew Lutomirski <amluto>
Submitted:  Fri 23 Aug 2013 10:56:39 PM UTC
   
 
Category:  Booting Severity:  Major
Priority:  5 - Normal Item Group:  Action Request
Status:  Fixed Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Closed Release:  other
Release:  Reproducibility:  Every Time
Planned Release:  None

Jump to the original submission

Fri 18 Oct 2013 11:26:11 PM UTC, comment #10: 

Now it works:

[    0.000000] BIOS-e820: [mem 0x0000000480000000-0x00000004ffffffff] type 12

Thanks!

(And thanks for the hint about configure.ac.  That wasn't the problem, but it made it more obvious what was going on.)

Andrew Lutomirski <amluto>
Fri 18 Oct 2013 11:02:20 PM UTC, comment #9: 

Please repull latest trunk: there was one other place where it was sanitized.

Vladimir Serbinenko <phcoder>
Group administrator
Fri 18 Oct 2013 09:39:41 PM UTC, comment #8: 

You can change version in configure.ac and then it will appear over the menu.

Vladimir Serbinenko <phcoder>
Group administrator
Fri 18 Oct 2013 06:43:23 PM UTC, comment #7: 

This appears not to have worked, but that may just mean that I'm not actually running the new, fixed version.  Is there an easy way to tell from the grub prompt that I'm running the correct version of grub?

Andrew Lutomirski <amluto>
Mon 14 Oct 2013 02:36:42 PM UTC, comment #6: 

Committed fix. It wasn't that easy since it had to play well with badmem and int13h hook. Please test current trunk.

Vladimir Serbinenko <phcoder>
Group administrator
Thu 19 Sep 2013 03:20:41 PM UTC, comment #5: 

While the specs for e820 do indeed say that you should treat unknown types as reserved (in the sense of not touching the memory they refer to), that doesn't mean you should rewrite the table to change those unknown values to reserved.  While for GRUB's purposes it should treat any unknown type as reserved and not touch the memory, if it has to touch the e820 values for any reason, it should preserve the original values for forward compatibility with software that might know what the types mean.

Josh Triplett <joshtriplett>
Mon 26 Aug 2013 08:24:51 PM UTC, comment #4: 

I have the spec, but it's under NDA.

I'm not asking grub to implement the spec, though -- I just don't want it getting in the way.

Andrew Lutomirski <amluto>
Mon 26 Aug 2013 07:32:29 PM UTC, comment #3: 

Do you have a link to relevant spec?

Vladimir Serbinenko <phcoder>
Group administrator
Mon 26 Aug 2013 07:06:41 PM UTC, comment #2: 

My board has an NVDIMM, and BIOS reports the NVDIMM mapping as e820 type 12.  Stock Linux kernels treat unknown e820 types the same as reserved, and an NVDIMM-enabled kernel will see type 12 memory and use the NVDIMM.  Syslinux passes type 12 straight through, but grub2 changes type 12 to type 2, breaking the whole mechanism.

Andrew Lutomirski <amluto>
Sat 24 Aug 2013 11:21:40 AM UTC, comment #1: 

What do these values represent? What are they? Why do you need them? According to ACPI spec treating unknown values differently than reserved is incorrect.

Vladimir Serbinenko <phcoder>
Group administrator
Fri 23 Aug 2013 10:56:39 PM UTC, original submission:  

I have a BIOS which reports some nonstandard e820 memory types.  Grub2 changes them all to "reserved".  Please preserve them so that the OS can use them intelligently.

Andrew Lutomirski <amluto>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by joshtriplett (Posted a comment)
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by amluto (Submitted the item)
  •  

    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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-14 phcoder StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code