Unknown Symbol fc20

[Josh Boyer]

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 at linux.intel.com>
> > 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 at linux.intel.com>
> >     Signed-off-by: Tony Luck <tony.luck at intel.com>
> > 
> > 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