On 05.04.19 15:27, Jan Kiszka wrote:
On 05.04.19 11:42, Jan Kiszka wrote:
On 05.04.19 10:44, cagnulein wrote:
Hi, yes I double checked the patch and it's applied correctly.
Here you can find my config.
CONFIG_DEBUG_STACKOVERFLOW is disabled.
I can't get the uart on this system, is there any other way to catch log in
this scenario?
UART is mandatory for debugging such crashes. Use a PCI extension card if your
board has no UART connector anymore.
Well, you may try to lift Xenomai with KVM inside a KVM VM and catch the UART
output of the first level VM. This is how I'm debugging.
Why should I test the 4.4.y? 4.9.146 works fine on the same system (with the
same guest). Did I miss something?
Well, 4.9 would be as broken as 4.4 currently is. But 4.4 is supported, 4.9 is
discontinued by now. In any case, this indicates we have another difference
caused by changed in 4.14 (and before).
I'll see if I can reproduce by booting Win10 in my nested setup.
Already running the UEFI BIOS triggers something, at least on 4.4. Let's see...
As you will be able to see from the commits, there were a number of further
issues:
https://gitlab.denx.de/Xenomai/ipipe-x86/commits/wip/kvm-4.14
With that, I'm able to start Win10 on the same core as the latency test. But
only in my virtual setup (nested kvm) which may mean that real hw could expose
further issue or latency problems. Please test.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
