Cubox - segmentation fault compiling the standard kernel

[WarheadsSE]

Hello

I'm trying to compile the kernel 3.5 for the cubox. The default kernel doesn't come with TUN enabled.

Packages:
core/linux-cubox 3.5.0-1
core/linux-headers-cubox 3.5.0-1

Sources from git not modified. Just a configuration option changed.

Steps I've taken (all executed on the Cubox, with ssh)

1) I've got PKGBUILDs / core / linux-cubox using git clone;

2) I've run makepkg -s on the core / linux-cubox / dirrectory

3) Using the nmenuconfig option, I've selected Y for network ->drivers -> TUN

4) The compilation starts well, but fails with:
$this->bbcode_second_pass_code('', '
...
CC mm/slub.o
CC mm/memcontrol.o
mm/memcontrol.c: In function ‘__mem_cgroup_try_charge.constprop.47’:
mm/memcontrol.c:2379:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.archlinux.org/ for instructions.
make[1]: ** [mm/memcontrol.o] Error 1
make: ** [mm] Error 2
==> ERROR: build() failed
Aborting
')

I have also tried to compile rabeh's kernel and the previous version of the kernel. All segfaulted somewhere. I have an external SATA HD with plenty of space. I've followed the Archlinux installation from the instructions. The filesystem is ext4 fr the HD.

I'm not using distcc (because I'm kind of new to the ARM world).

So, do you guys have any ideas?

PS-> They didn't accept this report as a bug report, so Do you think it might be something missing in my configuration? I can compile other things, there are no complaints of missing things and the error is not in the source that it is being compiled...

[Ascomar]

Hi slashproc,
I have got the same problem here. Random segmentation faults that sometimes go away if you issue the compilation command again. Excluding random HW errors, the fault happen when the cubox tries to complie very big c files.
In that situation almost all of the phisycal memory is used (I have also a big swap area, as I run the system from a big e-sata disk). It seems that, for some reasons, the system tries to allocate some memory already used by another subsystem.
In this respect it appears quite suspicious the information you get from the "free" command:
$this->bbcode_second_pass_code('', '[root@Cubox btrfs]# free
total used free shared buffers cached
Mem: 701664 206348 495316 0 24796 70824
-/+ buffers/cache: 110728 590936
Swap: 4954108 0 4954108
')
Given that the cubox has 1GB of memory and that 384 MB are allocated to the video subsystem, the total amount should be 640 MB not 701 (even considering the conversion from 1000 and 1024 kB in 1 MB).

Regards

raffaele

[slashproc]

Ok, it seems reasonable...But in your case, there was plenty of swap space available. Is this a bug with GCC?

[kmihelich]

This is very much Cubox-centric, as the toolchain works flawlessly on every other v7 platform. There is likely an deeper issue elsewhere such as the kernel.

If you want things enabled in the kernel but are unable to do it yourself, submit an issue on our github tracker requesting it. Or better yet, give me a pull request with the change already made so you save me even more time.