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.
int 0x15, 0xe820 - Potential Problems
- Pype.Clicker
- 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
- 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
- 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
Re:int 0x15, 0xe820 - Potential Problems
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.
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.
Re:int 0x15, 0xe820 - Potential Problems
The 0xE820 function existed before ACPI. The specification for ACPI version 1.0 added 2 memory area types to it: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?
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.
Re:int 0x15, 0xe820 - Potential Problems
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.
I guess all we can do is write code that will account for this stupidity...
Cheers.
Re:int 0x15, 0xe820 - Potential Problems
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.
The person responsible for that should be shot. Maintaining backwards compatibility is not that hard.