On Tue, Oct 9, 2012 at 9:04 AM, Konrad Rzeszutek Wilk wrote:
> How do we clean it wrongly?
>> And it only happens when we are trying to map range one by one range
>> separately.
>>
>> After we add checking before clearing the related page table, that panic will
>> not happen anymore.
>
> So we
On Mon, Oct 08, 2012 at 09:39:12PM -0700, Yinghai Lu wrote:
> After we add code use BRK to map buffer for final page table,
.. mention the name of the patch that adds this.
What is 'final page table'? Isn't this just the existing
bootup tables modified to cover more memory.
>
> It should be
On Mon, Oct 08, 2012 at 09:39:12PM -0700, Yinghai Lu wrote:
After we add code use BRK to map buffer for final page table,
.. mention the name of the patch that adds this.
What is 'final page table'? Isn't this just the existing
bootup tables modified to cover more memory.
It should be safe
On Tue, Oct 9, 2012 at 9:04 AM, Konrad Rzeszutek Wilk kon...@kernel.org wrote:
How do we clean it wrongly?
And it only happens when we are trying to map range one by one range
separately.
After we add checking before clearing the related page table, that panic will
not happen anymore.
So
After we add code use BRK to map buffer for final page table,
It should be safe to remove early_memmap for page table accessing.
But we get panic with that.
It turns out we clear the initial page table wrongly for next range that is
separated by holes.
And it only happens when we are trying to
After we add code use BRK to map buffer for final page table,
It should be safe to remove early_memmap for page table accessing.
But we get panic with that.
It turns out we clear the initial page table wrongly for next range that is
separated by holes.
And it only happens when we are trying to
6 matches
Mail list logo
