[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190405055421.GA7087@infradead.org>
Date: Thu, 4 Apr 2019 22:54:21 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Anup Patel <Anup.Patel@....com>
Cc: Palmer Dabbelt <palmer@...ive.com>,
Albert Ou <aou@...s.berkeley.edu>,
Atish Patra <Atish.Patra@....com>,
Christoph Hellwig <hch@...radead.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Mike Rapoport <rppt@...ux.ibm.com>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] RISC-V: Fix Maximum Physical Memory 2GiB option for
64bit systems
On Fri, Apr 05, 2019 at 05:49:34AM +0000, Anup Patel wrote:
> The Maximum Physical Memory 2GiB option for 64bit systems is currently
> broken because kernel hangs at boot-time when this option is enabled
> and the underlying system has more than 2GiB memory.
>
> This issue can be easily reproduced on SiFive Unleashed board where
> we have 8GiB of memory.
>
> This patch fixes above issue by removing unusable memory region in
> setup_bootmem().
>
> Signed-off-by: Anup Patel <anup.patel@....com>
> Reviewed-by: Christoph Hellwig <hch@....de>
Btw, what is the rationale behind even offering the 2GiB option and
the medlow model on 64-bit? Do we reall have use cases where the
slightly more effient generated code matters so much to keep up
the support burden of this mostly unused and unusual configuration?
Powered by blists - more mailing lists