Thank you, on Monday morning I will fire it up! :) R. Il ven 5 apr 2019, 20:29 Jan Kiszka <jan.kis...@siemens.com> ha scritto:
> 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 >
