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.
...
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.