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