Hi Everybody,
Today I was trying to build 3.15.2 on AMD64 from kernel 3.14.8 and get this:
CC fs/mbcache.o
fs/mbcache.c: In function ?__spin_lock_mb_cache_entry?:
fs/mbcache.c:134: error: SSE register return with SSE disabled
make[1]: *** [fs/mbcache.o] Error 1
google doesn't reveal much except that floating point shouldn't be used
in the kernel, but I am not experienced enough to see how or what is
going on here.
Any help appreciated.
Please cc me.
Nick
--
"A bug in the code is worth two in the documentation."
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
On Sat, Jun 28, 2014 at 10:52:24AM +0100, Nick Warne wrote:
> Hi Everybody,
>
> Today I was trying to build 3.15.2 on AMD64 from kernel 3.14.8 and get this:
>
> CC fs/mbcache.o
> fs/mbcache.c: In function ‘__spin_lock_mb_cache_entry’:
> fs/mbcache.c:134: error: SSE register return with SSE disabled
> make[1]: *** [fs/mbcache.o] Error 1
I can't trigger that here.
Please send your .config. Also, before building, did you clean up your
source tree properly by saving the .config somewhere else and doing
"make mrproper"?
If not, do that too.
HTH.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 28/06/14 11:12, Borislav Petkov wrote:
> On Sat, Jun 28, 2014 at 10:52:24AM +0100, Nick Warne wrote:
>> Hi Everybody,
>>
>> Today I was trying to build 3.15.2 on AMD64 from kernel 3.14.8 and get this:
>>
>> CC fs/mbcache.o
>> fs/mbcache.c: In function ‘__spin_lock_mb_cache_entry’:
>> fs/mbcache.c:134: error: SSE register return with SSE disabled
>> make[1]: *** [fs/mbcache.o] Error 1
>
> I can't trigger that here.
>
> Please send your .config. Also, before building, did you clean up your
> source tree properly by saving the .config somewhere else and doing
> "make mrproper"?
Thanks for prompt reply.
I always do a mrproper followed by grabbing current .config from /proc
and issuing make oldconfig.
Attached is my config file.
Also, for what it is worth:
gcc version 4.8.2 (GCC)
Nick
--
"A bug in the code is worth two in the documentation."
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
On 28/06/14 11:26, Nick Warne wrote:
>
> On 28/06/14 11:12, Borislav Petkov wrote:
>> On Sat, Jun 28, 2014 at 10:52:24AM +0100, Nick Warne wrote:
>>> Hi Everybody,
>>>
>>> Today I was trying to build 3.15.2 on AMD64 from kernel 3.14.8 and get this:
>>>
>>> CC fs/mbcache.o
>>> fs/mbcache.c: In function ‘__spin_lock_mb_cache_entry’:
>>> fs/mbcache.c:134: error: SSE register return with SSE disabled
>>> make[1]: *** [fs/mbcache.o] Error 1
>>
>> I can't trigger that here.
>>
>> Please send your .config. Also, before building, did you clean up your
>> source tree properly by saving the .config somewhere else and doing
>> "make mrproper"?
>
> Thanks for prompt reply.
>
> I always do a mrproper followed by grabbing current .config from /proc
> and issuing make oldconfig.
>
> Attached is my config file.
>
> Also, for what it is worth:
>
> gcc version 4.8.2 (GCC)
Whoops - that is WRONG (too many ssh terminals)
gcc version 4.2.4
Nick
--
"A bug in the code is worth two in the documentation."
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
On Sat, Jun 28, 2014 at 11:55:07AM +0100, Nick Warne wrote:
> Whoops - that is WRONG (too many ssh terminals)
>
> gcc version 4.2.4
That's some old compiler. Anyway, I can't trigger it here with gcc 4.6
and 4.9.
Can you do
$ make clean
$ make V=1 fs/mbcache.i >>w.log 2>&1
$ make V=1 fs/mbcache.s >>w.log 2>&1
and zip and send me fs/mbcache.i, fs/mbcache.s and w.log.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 28/06/14 13:23, Borislav Petkov wrote:
> On Sat, Jun 28, 2014 at 11:55:07AM +0100, Nick Warne wrote:
>> Whoops - that is WRONG (too many ssh terminals)
>>
>> gcc version 4.2.4
>
> That's some old compiler. Anyway, I can't trigger it here with gcc 4.6
> and 4.9.
>
> Can you do
>
> $ make clean
> $ make V=1 fs/mbcache.i >>w.log 2>&1
> $ make V=1 fs/mbcache.s >>w.log 2>&1
>
> and zip and send me fs/mbcache.i, fs/mbcache.s and w.log.
OK, fs/mbcache.s didn't appear.
logs attached.
Thanks,
Nick
--
"A bug in the code is worth two in the documentation."
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
On 28/06/14 14:09, Nick Warne wrote:
>
>
> On 28/06/14 13:23, Borislav Petkov wrote:
>> On Sat, Jun 28, 2014 at 11:55:07AM +0100, Nick Warne wrote:
>>> Whoops - that is WRONG (too many ssh terminals)
>>>
>>> gcc version 4.2.4
>>
>> That's some old compiler. Anyway, I can't trigger it here with gcc 4.6
>> and 4.9.
>>
>> Can you do
>>
>> $ make clean
>> $ make V=1 fs/mbcache.i >>w.log 2>&1
>> $ make V=1 fs/mbcache.s >>w.log 2>&1
>>
>> and zip and send me fs/mbcache.i, fs/mbcache.s and w.log.
>
> OK, fs/mbcache.s didn't appear.
>
> logs attached.
OK, I just spent three months building GCC 4.7.4 today (thank god the
world cup is on to watch instead) and 3.15.2 built fine, and server is
up and running great.
This then is an old(er) version of GCC issue (but I dunno what).
Sorry for the noise and thanks.
Nick
--
"A bug in the code is worth two in the documentation."
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
On Sun, Jun 29, 2014 at 08:06:36PM +0100, Nick Warne wrote:
> OK, I just spent three months building GCC 4.7.4 today (thank god the
> world cup is on to watch instead)
Yep, the world cup helps a lot with tedious debugging work. :-)
> and 3.15.2 built fine, and server is up and
> running great.
>
> This then is an old(er) version of GCC issue (but I dunno what).
Right, so the error points at
__spin_lock_mb_cache_entry(struct mb_cache_entry *ce)
{
spin_lock(bgl_lock_ptr(mb_cache_bg_lock, <---
(hash_64((unsigned long)ce, __builtin_log2(8)))));
}
somewhere here and I'd guess that old gcc is issuing some lib function
which uses SSE. And after we disabled all FPU stuff in the kernel with
b399fe355b30 ("x86: Disable generation of traditional x87 instructions")
that would issue such an error.
And I was about to point at that __builtin_log2 thing which looked
suspicious and found this by chance:
http://lkml.kernel.org/r/[email protected]
You could test this patch with that old gcc 4.2.x as it looks like a
good candidate for a fix for your issue.
:-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 29/06/14 20:44, Borislav Petkov wrote:
>> This then is an old(er) version of GCC issue (but I dunno what).
>
> Right, so the error points at
>
> __spin_lock_mb_cache_entry(struct mb_cache_entry *ce)
> {
> spin_lock(bgl_lock_ptr(mb_cache_bg_lock, <---
> (hash_64((unsigned long)ce, __builtin_log2(8)))));
> }
>
> somewhere here and I'd guess that old gcc is issuing some lib function
> which uses SSE. And after we disabled all FPU stuff in the kernel with
> b399fe355b30 ("x86: Disable generation of traditional x87 instructions")
> that would issue such an error.
>
> And I was about to point at that __builtin_log2 thing which looked
> suspicious and found this by chance:
>
> http://lkml.kernel.org/r/[email protected]
>
> You could test this patch with that old gcc 4.2.x as it looks like a
> good candidate for a fix for your issue.
Thanks Boris, but unfortunately I had to trash GCC 4.2.4 to build the
new 4.7.4 version - so I can't test the patch :(
At least this issue is now on record so others will not need to go to
penalties.
Many thanks,
Nick
--
"A bug in the code is worth two in the documentation."
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
On Sun, Jun 29, 2014 at 10:05:29PM +0100, Nick Warne wrote:
> Thanks Boris, but unfortunately I had to trash GCC 4.2.4 to build the
> new 4.7.4 version - so I can't test the patch :(
>
> At least this issue is now on record so others will not need to go to
> penalties.
I hope so.
Btw, I thought you had that gcc 4.2.x from some distro or so. Because if
it is in some ancient distro, one could install it in kvm and test and
play with it.
Maybe I should go dig some old distro and play with it nevertheless -
issues like that tend to pop up off and on.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Sun, Jun 29, 2014 at 11:24:23PM +0200, Borislav Petkov wrote:
> Btw, I thought you had that gcc 4.2.x from some distro or so. Because
> if it is in some ancient distro, one could install it in kvm and test
> and play with it.
Ok, I did dig out an ancient debian I had lying around here with gcc
4.1.2. The patch I pointed you at does really fix the issue. So all is
fine and solved now. :-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 30/06/14 14:26, Borislav Petkov wrote:
> On Sun, Jun 29, 2014 at 11:24:23PM +0200, Borislav Petkov wrote:
>> Btw, I thought you had that gcc 4.2.x from some distro or so. Because
>> if it is in some ancient distro, one could install it in kvm and test
>> and play with it.
>
> Ok, I did dig out an ancient debian I had lying around here with gcc
> 4.1.2. The patch I pointed you at does really fix the issue. So all is
> fine and solved now. :-)
Ummm, interesting.
But is it solved?
Suppose developer a.n.other submits a patch that works with his/her GCC
version but doesn't with some other GCC version. I guess this will be
picked up in GIT build tests, but that only then tells everybody to
upgrade GCC or find a patch that fixes the issue (like you did, but I
couldn't find it).
Is there a document or something that stipulates what is the minimum
version[s] of GCC to build a particular version of the kernel? If not,
perhaps this is something that needs addressing.
Nick
--
"A bug in the code is worth two in the documentation."
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
On Mon, Jun 30, 2014 at 07:51:00PM +0100, Nick Warne wrote:
> Ummm, interesting.
>
> But is it solved?
>
> Suppose developer a.n.other submits a patch that works with his/her GCC
> version but doesn't with some other GCC version. I guess this will be
> picked up in GIT build tests, but that only then tells everybody to upgrade
> GCC or find a patch that fixes the issue (like you did, but I couldn't find
> it).
Well, this is generally something that will have to get fixed when
someone reports it. That's why I wanted to have an ancient environment
to build kernels in - just for that purpose. We have a bunch of people
who do test latest kernels on ancient hw and sw but as it is always the
case with testing, we cannot have total coverage.
So yes, in such cases, we aim at having the kernel build with all
supported gcc versions. Which brings me to your question below...
> Is there a document or something that stipulates what is the minimum
> version[s] of GCC to build a particular version of the kernel? If not,
> perhaps this is something that needs addressing.
#if GCC_VERSION < 30200
# error Sorry, your compiler is too old - please upgrade it.
#endif
... yes, so we do support gcc versions >= 3.2 and the kernel has to be
buildable with those.
So, long story short, people should report such issues to lkml so that
they get addressed.
Ok?
:-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--