From: Aaro Koskinen <aaro.koskinen@iki.fi>
To: Paul Burton <paul.burton@mips.com>
Cc: "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: MIPS/CI20: BUG: Bad page state
Date: Fri, 31 May 2019 02:23:05 +0300 [thread overview]
Message-ID: <20190530232305.GB4285@darkstar.musicnaut.iki.fi> (raw)
In-Reply-To: <20190528233715.GB24195@darkstar.musicnaut.iki.fi>
Hi,
On Wed, May 29, 2019 at 02:37:15AM +0300, Aaro Koskinen wrote:
> On Wed, Apr 24, 2019 at 08:50:31PM +0000, Paul Burton wrote:
> > On Wed, Apr 24, 2019 at 11:40:55PM +0300, Aaro Koskinen wrote:
> > > On Wed, Apr 24, 2019 at 07:29:29PM +0000, Paul Burton wrote:
> > > > On Wed, Apr 24, 2019 at 09:20:12PM +0300, Aaro Koskinen wrote:
> > > > > I have been trying to get GCC bootstrap to pass on CI20 board, but it
> > > > > seems to always crash. Today, I finally got around connecting the serial
> > > > > console to see why, and it logged the below BUG.
> > > > >
> > > > > I wonder if this is an actual bug, or is the hardware faulty?
> > > > >
> > > > > FWIW, this is 32-bit board with 1 GB RAM. The rootfs is on MMC, as well
> > > > > as 2 GB + 2 GB swap files.
> > > > >
> > > > > Kernel config is at the end of the mail.
> > > >
> > > > I'd bet on memory corruption, though not necessarily faulty hardware.
> > > >
> > > > Unfortunately memory corruption on Ci20 boards isn't uncommon... Someone
> > > > did make some tweaks to memory timings configured in the DDR controller
> > > > which improved things for them a while ago:
> > > >
> > > > https://github.com/MIPS/CI20_u-boot/pull/18
> > > >
> > > > Would you be up for testing with those tweaks? I'd be happy to help with
> > > > updating U-Boot if needed.
>
> I did some testing with CI20_u-boot ef995a1611f0, plus the timing fix
> cherry picked. Didn't help, I still get random crashes (every time
> different).
I have now ran memtester with 900M allocation for 10 hours (around 10
loops), then with two processes using 450M allocation each for 24 hours
(some 20 loops or so), and no errors or other issues are encountered.
I would guess if the timings were wrong, memtester would have failed
by now?
When trying GCC bootstrap the systems fails reliably... Usually within
few hours, but sometimes even within 30 minutes.
Maybe the issue is not memory/hardware. Since I build, and have also
swap, on MMC/SDcard perhaps we have some buggy code in the MMC or DMA
driver that results in memory corruption?
A.
prev parent reply other threads:[~2019-05-30 23:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 18:20 Aaro Koskinen
2019-04-24 19:18 ` Matthew Wilcox
2019-04-24 19:29 ` Paul Burton
2019-04-24 20:40 ` Aaro Koskinen
2019-04-24 20:50 ` Paul Burton
2019-05-28 23:37 ` Aaro Koskinen
2019-05-30 23:23 ` Aaro Koskinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190530232305.GB4285@darkstar.musicnaut.iki.fi \
--to=aaro.koskinen@iki.fi \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paul.burton@mips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox