Hi there,
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.
Indeed. I suspect that something in the omapfb is different and the plain debian xorg (assuming to be built against kernel 3.2 headers!) is not aware of that. We have one patch in our code so that it provides a “name” entry somewhere in the /sys nodes. Otherwise the stable xorg wouldn’t find anything.
The gta04 kernel is very unstable
please provide bug reports. dmesg traces, other symptoms, error messages etc.
“very unstable” does not help anyone to fix anything. Precise bug reports do :)
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 guess it is a mix between both. Some combinations work and others may have some uninitialized variable or dangling pointer or alignment assumption or whatever is triggering problems.
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!
Is this from the compiler? Which compiler are you using? On which machine are you compiling?
We have not added any code to trigger a segfault in the make command :)
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.
Ah, you are compiling on the EVM as a stress test? So I probably should set up this as well. It is just a git clone away…
I am cross-compiling and did never see that problem during compile or during operation of the EVM. Maybe we should compare uImage binaries? At least the file size. Plain diff fails because the compile date is included somewhere and also makes the CRC differ.
...
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.
That is why I don’t use the TI kernels any more. I think the strategy used with the gta04-kernel is the best we can get (which is still suboptimal of course). We get latest official developments, I can write drivers as soon as hardware becomes available without fighting with incompatible changes of anyone else, and we have a chance to get our things upstream.
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.
Yes, overlayfs is promising and might be the better choice (because it is likely to be maintained). But we will probably run through a learning curve.
BR, Nikolaus