int 0x15, 0xe820 - Potential Problems

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
GenX

int 0x15, 0xe820 - Potential Problems

Post by GenX »

Hey,

I have just been looking at some linux source (not sure of the version) and noticed that in the memory map detection code comments it talks about possible problems with the map returned, like overlapping ranges, zero length ranges, etc... Does anyone know why this isn't in Ralph Browns Interrupt List?

Anyway, if two ranges do overlap, how do you determine which range should get the overlapping area? I would think that it is safe to assume that if it was between system (type 1) memory and something else that the other type would get the memory, but what priority should be given to the others, say if it was between ACPI Reclaim (type 3) and ACPI NVS (type 4)?? The comments in the code suggest that the greater the type id, the higher the priority... what do you guys think?

I haven't looked into ACPI so I am not familiar with it, but I want to be able to write this memory detection code properly and not have to worry about it again, if thats even possible... ::)

Cheers. :)
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:int 0x15, 0xe820 - Potential Problems

Post by Pype.Clicker »

- zero-length areas: these should be fairly simple to support (e.g. ignore them)
- overlapping areas: i'd be tempted to use one of the following policies:
a) tell the user there's something odd with its BIOS and that he should mail you a bug report
b) assume the 'most constraining' properties for the overlapping area (e.g. if it's reported both Free and Reserved, don't touch it)


In the case of Linux, of course, people try to have it working on as much machines as possible, even if that mean they should have ugly hacks in the source to have those machines supported (as long as it doesn't prevent other machines to work) ...

It would be interresting, though, to get a look at BIOS specifications and see if that's something that could arise or if it's clearly a firmware error that should be corrected by flashing your BIOS... and to report the result on the FAQ
GenX

Re:int 0x15, 0xe820 - Potential Problems

Post by GenX »

Hey Pype,

Thats pretty much what I was thinking.

I just checked out what the FAQ says about memory and noticed some notes about ACPI 3.0, I am glad that I found that little note it will definately alter my memory detection code...

When it comes to ACPI, do I need to read all the specifcation releases, or will 3.0 tell me everything I need to know about it?

Cheers. :)
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re:int 0x15, 0xe820 - Potential Problems

Post by Brendan »

GenX wrote:I just checked out what the FAQ says about memory and noticed some notes about ACPI 3.0, I am glad that I found that little note it will definately alter my memory detection code...

When it comes to ACPI, do I need to read all the specifcation releases, or will 3.0 tell me everything I need to know about it?
The 0xE820 function existed before ACPI. The specification for ACPI version 1.0 added 2 memory area types to it:

Type 3: ACPI reclaimable memory
Type 4: ACPI NVS memory

For ACPI version 2.0, the 0xE820 function is identical (no changes).

For ACPI version 3.0 they stuffed it up extended it, as noted in the FAQ page.

The problem with the ACPI 3.0 extension is that all current OSs only use 20 byte entries, so if the BIOS uses the extended attributes to indicate that the entire entry should be ignored, then most OSs won't ignore the entry.

I'm hoping BIOS manufacturers will be smart enough to set the size of the memory region to zero too, so that it doesn't cause problems if the OS doesn't check the "ignore this entry" extended attribute flag.

If the BIOS manufacturers aren't smart, then they could tell the OS there's 1 GB of usable RAM and then use the "ignore me" flag so that existing OSs think there's RAM where there isn't, and crash because of it.


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
GenX

Re:int 0x15, 0xe820 - Potential Problems

Post by GenX »

Hey Brendan, thanks for that. Somehow I think that BIOS manufacturers will be stupid enough to similar things to what you have mentioned, just look at the evolution of hardware already... some pretty stupid mistakes have been made.

I guess all we can do is write code that will account for this stupidity...

Cheers. :)
tom1000000

Re:int 0x15, 0xe820 - Potential Problems

Post by tom1000000 »

Who the hell designed the ACPI 3.0 extension to the e820 map?

The person responsible for that should be shot. Maintaining backwards compatibility is not that hard.
Post Reply