blob: ee5ad8bca9052c2d37ee5b29613409cb264bd29e (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
From Sl4ck3ver on LQ:
http://www.linuxquestions.org/questions/slackware-14/[patch]-found-a-nasty-lilo-bug-with-a-2-line-fix-for-14-2-a-4175577969/
Every BIOS-e820 entry contains start and size of the area as 64-bit value
and is shifted right 10 bits (1024) with "shrd" while searching for the
largest "usable" memory range entry.
Finally the found values are converted back into real addresses by shifting
left 10 bits...
BUT this is done the wrong only using a 32-bit register so the high dword is lost!!!
0x000000027fffffff gets 0x000000007fffffff :-(
Every EXISTING system which happens to work fine just happens to
have an entry which just contains "usable" memory at that address.
Often in the form of an entry like:
BIOS-e820: [mem 0x0000000000100000-0x00000000fxxxxxxx] usable
Virtually all systems have "usable" memory at that position, so until
now this bug was not noticed!
HERE IS THE FIX, A 2-LINER:
===========================
Ignore any usable memory range not starting below 4GB and
so avoid the truncation, really just a work around :-)
--- ./src/second.S.orig 2016-04-21 15:12:57.155456806 -0500
+++ ./src/second.S 2016-04-21 15:15:08.918466313 -0500
@@ -2975,6 +2975,8 @@
shrd memmap+8,eax,#10 ; convert to 1k
cmp dword memmap,#1024 ; below 1M
jb e8go2 ; below 1M, no interest
+ cmp dword memmap,#4*1024*1024 ; above 4G
+ jae e8go2 ; above 4G, no interest
cmp esi,memmap+8 ; check size
ja e8go2 ; want largest
mov edx,memmap ; start (in 1k)
|
