[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53445660.1010908@archlinux.org>
Date: Tue, 08 Apr 2014 22:04:48 +0200
From: Thomas Bächler <thomas@...hlinux.org>
To: Matt Fleming <matt@...sole-pimps.org>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
CC: matt.fleming@...el.com, ak@...ux.intel.com,
viro@...iv.linux.org.uk, geert@...ux-m68k.org,
akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
linux-kernel@...r.kernel.org, tpowa@...hlinux.org, hpa@...or.com
Subject: Re: 3.13: <module> disagrees about version of symbol <symbol>
Am 08.04.2014 20:57, schrieb Thomas Bächler:
>>>> Thomas, you mention you're running in a 32-bit vm earlier in this
>>>> thread. Any chance you're using ovmf because that would make it much
>>>> easier to track this down?
>>>>
>>>
>>> I'm not familiar with UEFI boot, but it could happen because what
>>> I experienced with BIOS boot was an address dependent behavior.
>>>
>>> https://lkml.org/lkml/2013/9/4/188
>>
>> OK, that's a pretty good clue, thanks Tetsuo.
>>
>> Thomas, could you try this patch? It seems the use of code32_start in
>> the EFI boot stub was totally wrong for the case where the boot stub
>> relocates the kernel - you're likely to hit this path if using the EFI
>> boot stub directly from the EFI shell or gummiboot.
>>
>> It was pointing at the start of the kernel image and not the protected
>> mode code.
>
> Hello Matt,
>
> I am unable to backport this to 3.14 for lack of assembler magic. While
> I can test this with git master, I eventually still need a version that
> is backported to 3.14. Any chance you could provide that, too?
Hello again Matt,
with linux.git master, I cannot reproduce the problem at all (with or
without your patch). In fact, all the 0x0 CRCs on symbols are gone, and
those were the symbols that were broken after all.
FWIW, with your patch the kernel still boots.
Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)
Powered by blists - more mailing lists