M. Koehrer wrote: > Hi! > > After a couple of over-night test runs, I finally got an NMI watchdog > detected lockup with the sporadic freeze option. > I started the system with the argument nmi_watchdog=1 (also isolcpus=1). > See the code below. As I have not connected a serial console, I have attached > a screen shot in a fairly > bad quality as jpg file... However, it is good enough to be able to read > everything... > The lockup is in function rpi_pop [xeno_nucleus]. > It is called from gatekeeper_thread and from default_wake_function. > See the attached jpg for details.
Looks like we are stuck on rpilock, Philippe. And when looking at the holders of rpilock, I think one issue could be that we hold that lock while calling into xnpod_renice_root [1], ie. doing a potential context switch. Was this checked to be save? Furthermore, that code path reveals that we take nklock nested into rpilock [2]. I haven't found a spot for the other way around (and I hope there is none), but such nesting is already evil per se... Mathias, already tried your test case with our old friend "priority coupling" switched off? *If* this lock-up is actually due to rpilock brokenness, switching the feature off should make it disappear. Jan [1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/shadow.c?v=SVN-trunk#435 [2]http://www.rts.uni-hannover.de/xenomai/lxr/source/include/nucleus/pod.h?v=SVN-trunk#308
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
