mirror of
git://slackware.nl/current.git
synced 2024-12-29 10:25:00 +01:00
43 lines
1.5 KiB
Diff
43 lines
1.5 KiB
Diff
|
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)
|