On Wed, Jul 10, 2013 at 10:39:43AM -0400, Josh Boyer wrote:
> On Wed, Jul 10, 2013 at 10:17:22AM -0400, Dave Anderson wrote:
> >
> >
> > > > while yum updating
> > > >
> > > > Installing :
> > > > kernel-3.11.0-0.rc0.git2.1.fc20.x86_64
> > > > 1/1 depmod:
> > > > WARNING: /lib/modules/3.11.0-0.rc0.git2.1.fc20.x86_64/kernel/drivers/char/crash.ko
> > > > needs unknown symbol page_is_ram Verifying :
> > > > kernel-3.11.0-0.rc0.git2.1.fc20.x86_64
> > > Thanks. Someone else reported this yesterday as well. It shouldn't
> > > cause any problems for most Fedora users, as it will only impact those
> > > using the crash tool.
> > >
> > > josh
> >
> > OK, but for those of us who use it, the change that presumably causes this
> > would be this part of this commit:
> >
> > commit c5a130325f13b219438cb100e2da71a3e31199f3
> > Author: Chen Gong <gong.chen@xxxxxxxxxxxxxxx>
> > Date: Thu Jun 6 15:20:51 2013 -0700
> >
> > ACPI/APEI: Add parameter check before error injection
> >
> > When param1 is enabled in EINJ but not assigned with a valid
> > value, sometimes it will cause the error like below:
> >
> > APEI: Can not request [mem 0x7aaa7000-0x7aaa7007] for APEI EINJ Trigger registers
> >
> > It is because some firmware will access target address specified in
> > param1 to trigger the error when injecting memory error. This will
> > cause resource conflict with regular memory. So It must be removed
> > from trigger table resources, but incorrect param1/param2
> > combination will stop this action. Add extra check to avoid
> > this kind of error.
> >
> > Signed-off-by: Chen Gong <gong.chen@xxxxxxxxxxxxxxx>
> > Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx>
> >
> > diff --git a/kernel/resource.c b/kernel/resource.c
> > index d738698..77bf11a 100644
> > --- a/kernel/resource.c
> > +++ b/kernel/resource.c
> > @@ -409,6 +409,7 @@ int __weak page_is_ram(unsigned long pfn)
> > {
> > return walk_system_ram_range(pfn, 1, NULL, __is_ram) == 1;
> > }
> > +EXPORT_SYMBOL_GPL(page_is_ram);
> >
> > void __weak arch_remove_reservations(struct resource *avail)
> > {
> >
> >
> > where the additional EXPORT_SYMBOL_GPL(page_is_ram) above now makes
> > it available from both kernel/resource.c and arch/x86/mm/ioremap.c.
> > Why would that make it an unknown symbol?
>
> I don't see it in arch/x86/mm/ioremap.c at all. It's defined as __weak
> in kernel/resource.c, so I'm guessing some kind of interaction there is
> going wrong with the linking?
Oh, yeah I see why I didn't see it in arch/x86/mm/ioremap.c. I was
looking at the upstream kernel, not one patched with the crash driver
patches. Sigh.
Maybe someone could take a poke at upstreaming that again so stuff like
this doesn't happen during rebases?
josh
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel
