Re: 3.13: <module> disagrees about version of symbol <symbol>

[Andi Kleen <ak@linux.intel.com>]

On Mon, Apr 07, 2014 at 10:10:46PM +0200, Thomas Bächler wrote:
> Am 07.04.2014 19:46, schrieb Thomas Bächler:
> > Am 07.04.2014 19:30, schrieb Andi Kleen:
> >>>> Do you have a specific config?
> >>>> Specific compiler version?
> >>>
> >>> Using gcc 4.8 from Arch Linux with the configuration at [1] and Linux 3.14.
> >>
> >> I tested this configuration (with gcc 4.8 on FC20/19) and it loads
> >> ext4 and all the other modules without any problems.
> >>
> >> Base tree: 
> >>
> >> commit e06df6a7eae1ab1ef4deb076aeeaed90e948e5c0
> >> Merge: c0fc3cb 9dd721c
> >> Author: Linus Torvalds <torvalds@linux-foundation.org>
> >> Date:   Mon Mar 31 12:34:49 2014 -0700
> >>
> >> Must be something really archlinux specific. Please do some debugging.
> >> Also please double check that all your test procedures are correct.
> > 
> > Tetsuo was so kind to install Arch Linux and reproduce the exact
> > procedure I use to create the kernel (which includes the automated
> > creation of a pristine build environment) - his kernel booted just fine.
> > I will do more tests today on two of my own computers to narrow this down.
> 
> I think I found out why nobody could reproduce the problem.
> 
> I did a few more tests and it turns out that the problem only occurs
> when I boot the kernel with UEFI (using Gummiboot+EFISTUB). Now, except
> for OVMF virtual machines, there are barely any 32 Bit UEFI machines
> around, so nobody noticed. When I boot the kernel with 32 Bit BIOS, it
> boots fine.
> 
> Just to clarify: As mentioned in my first mail, some symbols still get a
> 0x0 CRC (which I still think is wrong), but the mismatch does not occur
> in BIOS mode.
> 
> On x86_64, the problem does not occur at all.

Thanks.

This sounds like the UEFI boot corrupts some memory? 

Copying some UEFI experts.

Maybe we need some CRC checksum checking in the kernel?

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only