Bug 44931 - Kernel fails to build on Processor family=386
Kernel fails to build on Processor family=386
Status: RESOLVED OBSOLETE
Product: Platform Specific/Hardware
Classification: Unclassified
Component: i386
All Linux
: P1 normal
Assigned To: platform_i386
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-19 11:11 UTC by Mario Gzuk
Modified: 2015-03-01 14:29 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.4.x
Tree: Mainline
Regression: No


Attachments
Kernel Konfig for 3.4.5 (81.20 KB, text/plain)
2012-07-19 11:11 UTC, Mario Gzuk
Details
CMPXCHG8B software emulation patch (6.35 KB, patch)
2012-12-15 07:53 UTC, Michael Shigorin
Details | Diff

Description Mario Gzuk 2012-07-19 11:11:29 UTC
Created attachment 75771 [details]
Kernel Konfig for 3.4.5

Hi,
if I change the Processor family to 386 the following errors start with building the kernel:
make CC=gcc HOSTCC=gcc ARCH=i386
SEVERAL:
include/linux/llist.h: In function 'llist_add':
include/linux/llist.h:160:11: warning: initialization makes pointer from integer without a cast [enabled by default]
include/linux/llist.h:160:11: warning: initialization makes pointer from integer without a cast [enabled by default]
The buld dies @:
  CC      arch/x86/kernel/irq_work.o
In file included from include/linux/irq_work.h:4:0,
                 from arch/x86/kernel/irq_work.c:8:
include/linux/llist.h: In function 'llist_add':
include/linux/llist.h:160:11: error: 'boot_cpu_data' undeclared (first use in this function)
include/linux/llist.h:160:11: note: each undeclared identifier is reported only once for each function it appears in
include/linux/llist.h:160:11: warning: initialization makes pointer from integer without a cast [enabled by default]
include/linux/llist.h:160:11: warning: initialization makes pointer from integer without a cast [enabled by default]
make[2]: *** [arch/x86/kernel/irq_work.o] Error 1
make[1]: *** [arch/x86/kernel] Error 2
make: *** [arch/x86] Error 2


If I changed the processor type to something other (e.g. 486 or any other) the build runs fine.
This happens to all kernel versions 3.4.x


The gcc used (ubuntu 12.04 i386)
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 

Attached is the kernel config for family 486 -> if you change this to i386 the build fails with the above error.

Thank you
Comment 1 Mario Gzuk 2012-11-27 10:48:44 UTC
Hi,
same issue with 3.5.x and 3.6.x.

What am I doing wrong?
Comment 2 H. Peter Anvin 2012-11-27 10:51:47 UTC
Do you actually care about 386?  If so, why?  The reason I'm asking is that we are seriously considering ripping out the remains of 386 (as opposed to 486) support...
Comment 3 H. Peter Anvin 2012-11-27 10:56:19 UTC
The problem is that the llist code uses cmpxchg() unconditionally, and the 386-specific fallback code doesn't seem to actually get picked up properly.
Comment 4 Mario Gzuk 2012-11-27 11:02:39 UTC
Hi Peter Anvin,
this config is used in the project uranos.sf.net. The kernel is used in a boot environment which has to be the possibilities to deploy windows (and do also other stuff e.g. like offline virus scanning) on a wide range of machine types which should be also compatible with i486, i586 or i686 too.
The main problem we have is that if we changed the machine type to i486 (or i586/i686) the kernel build runs fine, but if we try to boot that kernel via PXE (or CD via syslinux) the last message I see is:
"booting the kernel"
and the system stays @ 100% CPU load and do nothing (VBOX). 

So I actually dont know if this is related to the 386. But I think if there is a possibility to use i386, it should also compile with this option?!

All versions in the 3.2.x are working fine and also boot via syslinux.

Thank you for your time!
Comment 5 H. Peter Anvin 2012-11-27 11:18:46 UTC
An issue with 486+ would be totally unrelated and needs to be discovered separately.  I would recommend doing a "git bisect" from the last known working version.
Comment 6 Mario Gzuk 2012-11-27 11:39:08 UTC
So I should do that like decribed here:
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html ?
From the 3.2.34 to the next version which is not working? Or the latest version not working?
Comment 7 H. Peter Anvin 2012-11-27 11:41:14 UTC
From 3.2 assuming it is working to the first mainline (two-digit) version which is not working.
Comment 8 Mario Gzuk 2012-11-28 06:40:17 UTC
Sorry for asking again. I never checked out any thing with git. Finding the right place from http://git.kernel.org/ seems to be very hard. Can you write me s short (as possible) howto do that? Thank you!
Comment 9 H. Peter Anvin 2012-11-28 17:04:05 UTC
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Comment 10 Mario Gzuk 2012-11-28 20:14:05 UTC
So as you removed the code from the kernel, I think you dont need the bisect things... So you may want to close this report... Thanks for your time.

Cheers Mario
Comment 11 H. Peter Anvin 2012-11-28 20:17:50 UTC
I still care about the OTHER bug you reported:

"The main problem we have is that if we changed the machine type to i486 (or
i586/i686) the kernel build runs fine, but if we try to boot that kernel via
PXE (or CD via syslinux) the last message I see is:
"booting the kernel" and the system stays @ 100% CPU load and do nothing (VBOX). "

That is the one I would really like to find the answer to.
Comment 12 Mario Gzuk 2012-11-29 11:25:53 UTC
Oh. Thank you. I have tested now the 3.2.34 with i386 switch to i686 and all works fine. I never got a kernel from 3.[456] booting via syslinux/pxelinux. Maybe I have to check the .config again, but as far as I can see all the settings which affects this are correct. I will give it a try again with 3.6.8 and the config from the working 3.2.34 (i686). If there are some news I will let you know. Cheers
Comment 13 Mario Gzuk 2012-11-29 14:27:46 UTC
Hi,
the last test runs fine with 3.6.8 (i686) - I am now able to boot via PXE (also syslinux from iso). Maybe I had a wrong config which was not working. Thank you for your time! Cheers
Comment 14 Michael Shigorin 2012-12-15 07:53:25 UTC
Created attachment 89271 [details]
CMPXCHG8B software emulation patch

(In reply to comment #3)
> The problem is that the llist code uses cmpxchg() unconditionally, and the
> 386-specific fallback code doesn't seem to actually get picked up properly.
BTW there's a pentium_emu patch by Alexander Chumachenko that provides i586 instructions emulation for i486 (e.g. eBox 2300SX, we hit those with ALT Linux Terminal distro) -- attaching just in case, sorry if that's spam here, willing to post separately if found somewhat useful.
Comment 15 Alan 2015-02-19 16:30:49 UTC
This bug relates to a very old kernel. Closing as obsolete.
Comment 16 ysangkok 2015-02-28 13:21:19 UTC
Isn't 3.4 still maintained? I have this problem with 3.4.106. AFAIK, this is the most recent kernel with support for the i386. It's sad that it doesn't work; it makes it hard for people with legacy emulators or legacy hardware to find the latest kernel that will work for them.
Comment 17 Alan 2015-03-01 14:29:05 UTC
If you want 386 support then the only way it will happen is if someone (ie you) wants to do the *huge* amount of work required to update 386 support and keep it working. The 386 requires a huge amount of additional nasty and complex code that is not needed from 486 onwards.

Note You need to log in before you can comment on or make changes to this bug.