When building the runtime using LLD 14 (maybe even 13), also get:
artiq.coredevice.comm_kernel.LoadError: cannot load kernel: symbol lookup error: __artiq_personality
Looking into…
@fanmingyu212 Okay, many thanks for the tests, that confirms my suspicion (and explains why it doesn't occur on Nix), which gives me a handle on reproducing the issue. Will look into fixing our…
Can't reproduce on 303863980 mentioned in the forum thread on kc705_nist_clock either (though with gateware defc69d) .
@fanmingyu212 Would you mind preparing an ELF file with the dummy variable workaround as well? This does seem likely to be related to the toolchain, and I don't have a Windows box ready to test.
Can't reproduce on 3d25092cbd on Kasli tester either; thousands of artiq_run iterations proceed fine.
Can't reproduce this on a custom Oxford-local target based on defc69d9c with the below example – will need to try this using the actual builds from the reports.
from artiq.experiment…
Given how the compiler is implemented currently, returning a string from a kernel can't work, and neither for any other "allocated" type (arrays/lists), as the backing allocation for the elements…
I can't seem to reproduce the print() crash on current master, though – unless you can, we can probably close the remaining issue as a duplicate of #1497/#1677.
Yes, ext0_synth0_125to125 is what we've switched too (after I fixed the clocking setup code). Still no idea what exactly causes the quality of the Si5324 bypass path to be so bad.
Regarding the particular case that @pmldrmota mentioned above, it appears that this might have in fact been related to some glitches coupled in through the external clock input, i.e. appears to be…
The issue here is that the alignment padding isn't skipped when advancing to the next array element.
Should we work around this in gateware by just triggering one acquisition on reset?
Should be fixed (without a degradation in the behaviour for this) in 530f67f4cd.
https://github.com/m-labs/artiq/pull/1976…
Oh, just checked the Git history, and apparently I did write the offending test myself two years ago – how embarassing (in fairness, I was probably just copying test_steps() without thinking…
Certainly seems to be, but I don't know how that order could be defined more rigidly.
I haven't looked into what this particular test would require, but for testing Scheduler.idle (which we…
Could this just be a timing/event ordering issue? I haven't had a look at this particular test, but some of them do rely on implicitly defining order via sleeps.
I think I just saw the same problem, but either adding the user to trusted-users or the substitutors globally, both in /etc/nix/nix.conf fixed it.
Edit: Just saw that this was in single-user…
I guess you need to call self.core.break_realtime()?
If I understand Tom correctly, submitting the event at time 0, which should only be further in the past than now_mu() - 1000000,…