aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/mod/file2alias.c
diff options
context:
space:
mode:
authorMike Rapoport <[email protected]>2021-02-04 18:12:37 +0000
committerLinus Torvalds <[email protected]>2021-02-04 18:26:53 +0000
commit5c279c4cf206e03995e04fd3404fa95ffd243a97 (patch)
tree746b46f6bab34dc4057d81deda7ea6bed0cc9410 /scripts/mod/file2alias.c
parentMerge tag 'acpi-5.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/ra... (diff)
downloadkernel-5c279c4cf206e03995e04fd3404fa95ffd243a97.tar.gz
kernel-5c279c4cf206e03995e04fd3404fa95ffd243a97.zip
Revert "x86/setup: don't remove E820_TYPE_RAM for pfn 0"
This reverts commit bde9cfa3afe4324ec251e4af80ebf9b7afaf7afe. Changing the first memory page type from E820_TYPE_RESERVED to E820_TYPE_RAM makes it a part of "System RAM" resource rather than a reserved resource and this in turn causes devmem_is_allowed() to treat is as area that can be accessed but it is filled with zeroes instead of the actual data as previously. The change in /dev/mem output causes lilo to fail as was reported at slakware users forum, and probably other legacy applications will experience similar problems. Link: https://www.linuxquestions.org/questions/slackware-14/slackware-current-lilo-vesa-warnings-after-recent-updates-4175689617/#post6214439 Signed-off-by: Mike Rapoport <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'scripts/mod/file2alias.c')
0 files changed, 0 insertions, 0 deletions