From: Mike Rapoport <rppt@linux.ibm.com>
To: Matt Turner <mattst88@gmail.com>
Cc: Michael Cree <mcree@orcon.net.nz>,
linux-mm@kvack.org, linux-alpha <linux-alpha@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Regression bisected to fa3354e4ea39 (mm: free_area_init: use maximal zone PFNs rather than zone sizes)
Date: Tue, 27 Jul 2021 23:41:05 +0300 [thread overview]
Message-ID: <YQBvYUupT/jgDMqI@linux.ibm.com> (raw)
In-Reply-To: <CAEdQ38G+ZfXmc01iZTc+q4dYpRqQJUz0KNFCPwTQ25AYqJVbMA@mail.gmail.com>
On Tue, Jul 27, 2021 at 12:24:26PM -0700, Matt Turner wrote:
> On Mon, Jul 26, 2021 at 11:43 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> >
> > On Mon, Jul 26, 2021 at 02:23:20PM -0700, Matt Turner wrote:
> > > On Mon, Jul 26, 2021 at 1:06 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > > >
> > > > Hi Matt,
> > > >
> > > > On Mon, Jul 26, 2021 at 12:27:50PM -0700, Matt Turner wrote:
> > > > > Reply-To:
> > > > >
> > > > > Hi Mike!
> > > > >
> > > > > Since commit fa3354e4ea39 (mm: free_area_init: use maximal zone PFNs rather
> > > > > than zone sizes), I get the following BUG on Alpha (an AlphaServer ES47 Marvel)
> > > > > and loading userspace leads to a segfault:
> > > > >
> > > > > (I didn't notice this for a long time because of other unrelated regressions,
> > > > > the pandemic, changing jobs, ...)
> > > >
> > > > I suspect there will be more surprises down the road :)
> > > >
> > > > > BUG: Bad page state in process swapper pfn:2ffc53
> > > > > page:fffffc000ecf14c0 refcount:0 mapcount:1 mapping:0000000000000000 index:0x0
> > > > > flags: 0x0()
> > > > > raw: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > raw: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > page dumped because: nonzero mapcount Modules linked in:
> > > > > CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-03841-gfa3354e4ea39-dirty #26
> > > > > fffffc0001b5bd68 fffffc0001b5be80 fffffc00011cd148 fffffc000ecf14c0
> > > > > fffffc00019803df fffffc0001b5be80 fffffc00011ce340 fffffc000ecf14c0
> > > > > 0000000000000000 fffffc0001b5be80 fffffc0001b482c0 fffffc00027d6618
> > > > > fffffc00027da7d0 00000000002ff97a 0000000000000000 fffffc0001b5be80
> > > > > fffffc00011d1abc fffffc000ecf14c0 fffffc0002d00000 fffffc0001b5be80
> > > > > fffffc0001b2350c 0000000000300000 fffffc0001b48298 fffffc0001b482c0
> > > > > Trace:
> > > > > [<fffffc00011cd148>] bad_page+0x168/0x1b0
> > > > > [<fffffc00011ce340>] free_pcp_prepare+0x1e0/0x290
> > > > > [<fffffc00011d1abc>] free_unref_page+0x2c/0xa0
> > > > > [<fffffc00014ee5f0>] cmp_ex_sort+0x0/0x30
> > > > > [<fffffc00014ee5f0>] cmp_ex_sort+0x0/0x30
> > > > > [<fffffc000101001c>] _stext+0x1c/0x20
> > > > >
> > > > > I haven't tried reproducing this on other machines or QEMU, but I'd be glad to
> > > > > if that helps.
> > > >
> > > > If it's reproducible on QEMU I can debug it locally.
> > > >
> > > > > Any ideas?
> > > >
> > > > It seems like memory map is not properly initialized. Can you enable
> > > > CONFIG_DEBUG_MEMORY_INIT and add mminit_debug=4 to the command line. The
> > > > interesting part of the log would be before "Memory: xK/yK available ..."
> > > > line.
> > > >
> > > > Hopefully it'll give some clues.
> > >
> > > Sure thing. Please find attached.
> >
> > > aboot: loading uncompressed vmlinuz-5.7.0-03841-gfa3354e4ea39-dirty...
> > > aboot: loading compressed vmlinuz-5.7.0-03841-gfa3354e4ea39-dirty...
> > > aboot: PHDR 0 vaddr 0xfffffc0001010000 offset 0xc0 size 0x17c5ae0
> > > aboot: bss at 0xfffffc00027d5ae0, size 0xe4ea0
> > > aboot: zero-filling 937632 bytes at 0xfffffc00027d5ae0
> > > aboot: loading initrd (5965252 bytes/5825 blocks) at 0xfffffc05ff2cc000
> > > aboot: starting kernel vmlinuz-5.7.0-03841-gfa3354e4ea39-dirty with arguments ro panic=5 domdadm root=/dev/md1 console=srm mminit_debug=4
> > > Linux version 5.7.0-03841-gfa3354e4ea39-dirty (mattst88@ivybridge) (gcc version 11.1.0 (Gentoo 11.1.0-r2 p3), GNU ld (Gentoo 2.36.1 p3) 2.36.1) #26 SMP Sun Jul 25 18:20:06 PDT 2021
> > > printk: bootconsole [srm0] enabled
> > > Booting on Marvel variation Marvel/EV7 using machine vector MARVEL/EV7 from SRM
> > > Major Options: SMP EV67 VERBOSE_MCHECK DEBUG_SPINLOCK MAGIC_SYSRQ
> > > Command line: ro panic=5 domdadm root=/dev/md1 console=srm mminit_debug=4
> > > memcluster 0, usage 1, start 0, end 1984
> > > memcluster 1, usage 0, start 1984, end 1048576
> > > memcluster 2, usage 1, start 2097152, end 2097224
> > > memcluster 3, usage 0, start 2097224, end 3145728
> > > Initial ramdisk at: 0x(____ptrval____) (5965252 bytes)
> > > Found an IO7 at PID 0
> > > Initializing IO7 at PID 0
> > > FIXME: disabling master aborts
> > > FIXME: disabling master aborts
> > > FIXME: disabling master aborts
> > > FIXME: disabling master aborts
> > > SMP: 2 CPUs probed -- cpu_present_mask = 3
> > > Zone ranges:
> > > DMA [mem 0x0000000000f80000-0x00000fffffffdfff]
> > > Normal empty
> > > Movable zone start for each node
> > > Early memory node ranges
> > > node 0: [mem 0x0000000000f80000-0x00000001ffffffff]
> > > node 0: [mem 0x0000000400090000-0x00000005ffffffff]
> >
> > I think that the issue is that memory marked as used in memcluster is never
> > added to memblock and it skews node/zone sizing calculations.
>
> Thanks, this patch fixes it. With the patch applied, I see
>
> Zone ranges:
> DMA [mem 0x0000000000000000-0x00000fffffffdfff]
> Normal empty
> Movable zone start for each node
> Early memory node ranges
> node 0: [mem 0x0000000000000000-0x00000001ffffffff]
> node 0: [mem 0x0000000400000000-0x00000005ffffffff]
> Initmem setup node 0 [mem 0x0000000000000000-0x00000005ffffffff]
>
> If you want to send me this patch with your S-o-b I'll take it through
> my alpha git tree.
The patch is on its way :)
Now I'm really curios how commit e7793e53901b ("arc: update comment about
HIGHMEM implementation") will work out.
> Thanks Mike!
> Matt
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2021-07-27 20:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-26 19:27 Regression bisected to fa3354e4ea39 (mm: free_area_init: use maximal zone PFNs rather than zone sizes) Matt Turner
2021-07-26 20:06 ` Mike Rapoport
2021-07-26 21:23 ` Matt Turner
2021-07-27 6:43 ` Mike Rapoport
2021-07-27 19:24 ` Matt Turner
2021-07-27 20:41 ` Mike Rapoport [this message]
2021-07-30 19:53 ` Matt Turner
2021-07-31 9:19 ` Mike Rapoport
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=YQBvYUupT/jgDMqI@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mattst88@gmail.com \
--cc=mcree@orcon.net.nz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.