On 04/08/15 at 10:41am, Xishi Qiu wrote: > On 2015/4/8 10:18, Baoquan He wrote: > > > On 04/08/15 at 09:59am, Xishi Qiu wrote: > >> On 2015/4/8 9:46, Dave Young wrote: > >> > >>>>> > >>>>> - /* Mark all kernel nodes. */ > >>>>> + /* > >>>>> + * Mark all kernel nodes. > >>>>> + * > >>>>> + * In case booting with mem=nn[kMG] or in kdump kernel, > >>>>> numa_meminfo > >>>> > >>>> Hi Dave, > >>>> > >>>> It should both set mem=xx and numa=off, then numa_meminfo may not > >>>> include all > >>>> the memblock.reserved memory, right? > >>> > >>> Yasuaki Ishimatsu suggests to remove numa=off in comment because in > >>> theory there's such > >>> possiblity that it may happen even without numa=off. Just consider the > >>> non-snb board.. > >>> > >>> Thanks > >>> Dave > >>> > >> > >> Hi Dave, > >> > >> I made a mistake, when numa is on, numa_meminfo is from SRAT, but it will > >> be cut > >> in numa_cleanup_meminfo(), so the bug is not related to numa on/off. Your > >> comment > >> is right. > > > > Hi Xishi, > > > >>From code flow it's exact as you said. And if remove numa=off bug should > > be reproduced alwasy. I talked to Dave, he said error didn't occur when > > he remove numa=off. That is too weird. > > > > Hi Baoquan, > > May be it wrote over end of numa mask bitmap, but the stack can still run, > so there is no Call Trace. > How about add some printk to see if it has written over?
Oops, Redhat kdump always add numa=off in 2nd kernel commandline, but I did not notice I removed it during test. So yes, the issue does not depend on numa=off. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
