Hi,
Am 12.01.2015 um 18:42 schrieb aTc atc@k-n-p.org:
On 01/12/2015 01:13 PM, Grazvydas Ignotas wrote:
On Sun, Jan 11, 2015 at 2:18 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
And I see a long time known problem with Xorg that it might segfault if the touch/mouse is moved rapidly. This was traced back to an older Xorg. Notaz did recompile it and ED could use it for demos.
Not really, we saw this at least both with Xorg from debian stable and testing (whatever version was in testing around summer 2014). The workaround is to recompile Xorg with ARM instructions only (thumb2 disabled) without any source code changes.
, and make when compiling a kernel (takes a while to show up there, but when resuming the compile everything works fine)
This might actually be the same problem as with Xorg, I think I saw it once too. I suspect mainline kernels might be missing some errata workarounds for the (very) early revision of Cortex-A15 that's in OMAP5. Attempting to debug the Xorg problem showed "impossible" situation so it looks something hardware related (misconfigured hardware or missing workarounds for hardware bugs).
Please test the latest 3.19-rc3 if it still makes any compile problems.
Yeah it would be good to know if mainline is still affected, I saw multiple fixes that affect OMAP5 (like disabling deeper power save modes as they are broken in OMAP5 hardware).
Thing is, using the https://github.com/RobertCNelson/armv7-lpae-multiplatform 3.18 kernel, things are a lot more stable with the plain debian xorg. So they might have some patches/config settings in there that may point to the real source of the problem.
The gta04 kernel is very unstable with the debian xorg, but very solid with the patched (compiled with -marm) one. Im not entirely sure if it's just the kernel, since I did have the ocasional xorg problem with it, but that might have been just me messing about. I've never seen a kernel compile fail with theirs though.
I just tried a kernel compile on the gta 3.19.0-rc3, and kernel compiling failed with the usual
Makefile:1098: recipe for target 'modules' failed make: *** [modules] Segmentation fault make: INTERNAL: Exiting with 1 jobserver tokens available; should be 2!
Place it happens is pretty random of course, but it's very rare that it'll go through the entire compile in one go. Compiling with only 1 thread does seem to make it more stable, but I haven't done any serious tests with that.
The kernel compiling also fails when the patched xorg is running.
I did the following: * boot EVM from my 8GB SD card * with BOE panel attached and installed * showing LXDE desktop
Here the commands (edited from bash history):
155 apt-get install git 156 git clone http://git.goldelico.com/gta04-kernel.git 159 cd gta04-kernel/ 162 git checkout 3.19-rc4 163 gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14' --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 --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14) 165 time make gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules /bin/sh: 1: bc: not found make[3]: *** [kernel/time/timeconst.h] Error 127 make[2]: *** [kernel/time] Error 2 make[1]: *** [kernel] Error 2 make: *** [__build_one_by_one] Error 2
real 7m38.197s user 4m13.890s sys 0m33.050s
166 apt-get install bc 169 time make gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules
here would be the standard compile log. Nothing significant, except that I have seen at least 4 [-Wuninitialized] likethis:
ipc/shm.c:1310:59: warning: ‘file’ may be used uninitialized in this function [-Wuninitialized]
real 72m29.449s user 42m58.220s sys 5m2.280s root@gta04:~/gta04-kernel# ls -l arch/arm/boot total 17312 drwxr-xr-x 2 root root 4096 Jan 12 21:18 bootp drwxr-xr-x 2 root root 4096 Jan 13 06:20 compressed drwxr-xr-x 3 root root 69632 Jan 13 06:20 dts -rwxr-xr-x 1 root root 9062600 Jan 13 06:20 Image -rw-r--r-- 1 root root 1648 Jan 12 20:09 install.sh -rw-r--r-- 1 root root 3148 Jan 12 20:09 Makefile -rw-r--r-- 1 root root 4265464 Jan 13 06:20 uImage -rwxr-xr-x 1 root root 4265400 Jan 13 06:20 zImage root@gta04:~/gta04-kernel# ls -l /boot/uImage -rwxr-xr-x 1 root root 4322896 Jan 12 16:03 /boot/uImage root@gta04:~/gta04-kernel# uname -a Linux gta04 3.19.0-rc4-gta04+ #958 SMP Mon Jan 12 11:33:17 CET 2015 armv7l GNU/Linux root@gta04:~/gta04-kernel# cat /etc/debian_version 7.7
So it works and is stable (on Wheezy 7.7). I just had to install ‘bc’.
Compiling the kernel needs ~60 Minutes on a class 10 SD card and fills it to ~75%.
Interestingly, the binary is a little smaller than my cross-compiled one.
But I also see ca. 4 [-Wuninitialized] warnings.
One of them in ipc/shm and I think Xorg is using shared memory for communication?
I have also copied the new kernel into /boot and installed the new dtb and modules, rebooted and have not yet seen any difference.
I was even able to make clean and compile the kernel again using the newly compiled one.
So to summarize: on my EVM (with Pyra development hardware) it works and is stable (except the known Xorg segfault if the mouse is moved rapidly).
I must admit that I have no idea where your make-segfault problems are coming from.
Some random thoughts what might differ between your and my setup: * system library linked by make * a bug in gcc * one of the uninitialized things in the kernel * some dangling pointer elsewhere * a hardware difference of the boards (which might depend on clock frequency settings by different kernels so that I would not say the gta04-kernel is unstable but it reveals some other instability)
BR, Nikolaus
...
Let’s say it this way: it depends on what you want.
If you want a rock solid kernel with a lot of missing functions: use kernel.org
Unfortunately this is often only true for x86 and maybe for something like PowerPC, mainline tends to be broken on other platforms.. Although the situation might be improving, the ARM maintainers now have a huge farm of test boards (which fortunately includes OMAP5), so boards are at least tested to boot nowadays.
It's a lot worse than that, even the TI official kernels for the board have a lot of missing features, and are very picky about which compiler they're compiled with.
On the other side I think Notaz wants to do optimizations that never will be accepted by linus/master. So this still needs a separate tree.
Yeah, we'll want overclocking at least, which is forbidden in mainline. We'll also want hardware virtualization support, which needs PAE enabled in kernel, and PAE kernels can only run on Cortex-A15 or newer, which means one-uImage-for-everyone is not possible here.
We might also need aufs patched in. The current dbp system relies on aufs, and some aufs features might have some problems moving to overlayfs easily. Of course it's still very early stages for that, so overlayfs could still be a possibility. Issue is mostly that overlayfs only became available in mainline kernels very recently, so slaeshjag couldn't really test it.
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel