<sb0>
whitequark, I still don't understand how the DMA core hanging produces the "interrupted" message
<whitequark>
sb0: well, the entire kernel hangs
<sb0>
whitequark, does this also break when a different RTIO channel (ttl) is used in each DMA sequence? I want to avoid the possibility of e.g. a mishandled RTIO sequence error
<sb0>
whitequark, if the kernel hangs then why does @kernel return?
<whitequark>
I don't know, it's probably something about the testbench
<sb0>
hmm
FabM has quit [Ping timeout: 246 seconds]
<whitequark>
I haven't tried different channels
<sb0>
whitequark, I'm not convinced. this looks like a runtime bug.
<sb0>
this is the first time the DMA code is called, it only calls record() (no gateware)
<sb0>
and it prints this "interrupted a running kernel" message.
<whitequark>
sb0: then explain why the minimized example fails.
<whitequark>
including if I hack it to not involve any runtime code at all
<sb0>
there can be several bugs
<whitequark>
I'm not convinced this *is* a runtime bug
<whitequark>
but sure, I can waste some time figuring out exactly why the testsuite fails like that
<sb0>
you do this:
<sb0>
@kernel
<sb0>
def nested(self):
<sb0>
with self.core_dma.record(self.trace_name):
<sb0>
pass
<sb0>
with self.core_dma.record(self.trace_name):
<sb0>
and it prints "Interrupted a running kernel"
<sb0>
well. let me check if this is actually DMA related, or due to the test_watchdog test run before it
<bb-m-labs>
build #1419 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1419 blamelist: Chris Ballance <chris.ballance@physics.ox.ac.uk>