Searched hist:"7677 b2ef6c0c4fddc84f6473f3863f40eb71821b" (Results 1 – 2 of 2) sorted by relevance
/linux/arch/x86/kernel/ |
H A D | aperture_64.c | diff 7677b2ef6c0c4fddc84f6473f3863f40eb71821b Tue Apr 15 05:40:37 CEST 2008 Yinghai Lu <yhlu.kernel.send@gmail.com> x86_64: allocate gart aperture from 512M
because we try to reserve dma32 early, so we have chance to get aperture from 64M.
with some sequence aperture allocated from RAM, could become E820_RESERVED.
and then if doing a kexec with a big kernel that uncompressed size is above 64M we could have a range conflict with still using gart.
So allocate gart aperture from 512M instead.
Also change the fallback_aper_order to 5, because we don't have chance to get 2G or 4G aperture.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
H A D | pci-dma.c | diff 7677b2ef6c0c4fddc84f6473f3863f40eb71821b Tue Apr 15 05:40:37 CEST 2008 Yinghai Lu <yhlu.kernel.send@gmail.com> x86_64: allocate gart aperture from 512M
because we try to reserve dma32 early, so we have chance to get aperture from 64M.
with some sequence aperture allocated from RAM, could become E820_RESERVED.
and then if doing a kexec with a big kernel that uncompressed size is above 64M we could have a range conflict with still using gart.
So allocate gart aperture from 512M instead.
Also change the fallback_aper_order to 5, because we don't have chance to get 2G or 4G aperture.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|