Setting TTL on() in startup kernel results in invalid message type error

[dnadlinger]

Running this as a startup kernel on 2.0 (KC705)

from artiq.experiment import *

class Startup(EnvExperiment):
    def build(self):
        self.setattr_device("core")
        self.setattr_device("extOverride")

    @kernel
    def run(self):
        self.core.reset()
        self.extOverride.on()

results in

ERROR: received invalid message type (12) from kernel CPU

extOverride is just a TTL channel, and the value in parens is umsg->type (I've patched that in for debugging).

12 is MESSAGE_TYPE_RPC_BATCH, but the IR doesn't seem to show anything out of the ordinary:

define void @__modinit__(i8* nocapture readnone %.1) #0 personality i32 (...)* @__artiq_personality !dbg !3 {
entry:
  call void @rtio_init(), !dbg !17
  %UNN.6.i.i = call i64 @rtio_get_counter(), !dbg !20, !tbaa !21
  %UNN.7.i.i = add i64 %UNN.6.i.i, 125000, !dbg !20
  store i64 %UNN.7.i.i, i64* @now, align 4, !dbg !24
  %val.LOC.self.4.FLD.extOverride.i = load %I.artiq.coredevice.ttl.TTLOut.237*, %I.artiq.coredevice.ttl.TTLOut.237** getelementptr inbounds (%I.artiq_run_startupExperiment.Startup.241, %I.artiq_run_startupExperiment.Startup.241* @O.2, i32 0, i32 2), align 4, !dbg !25, !invariant.load !6, !unconditionally_dereferenceable !26
  %ptr.LOC.self.FLD.channel.i.i.i = getelementptr inbounds %I.artiq.coredevice.ttl.TTLOut.237, %I.artiq.coredevice.ttl.TTLOut.237* %val.LOC.self.4.FLD.extOverride.i, i32 0, i32 1, !dbg !27
  %val.LOC.self.FLD.channel.i.i.i = load i32, i32* %ptr.LOC.self.FLD.channel.i.i.i, align 4, !dbg !27, !invariant.load !6
  call void @rtio_output(i64 %UNN.7.i.i, i32 %val.LOC.self.FLD.channel.i.i.i, i32 0, i32 1), !dbg !30, !tbaa !21
  %UNN.12.i.i.i = getelementptr inbounds %I.artiq.coredevice.ttl.TTLOut.237, %I.artiq.coredevice.ttl.TTLOut.237* %val.LOC.self.4.FLD.extOverride.i, i32 0, i32 2, !dbg !31
  store i64 %UNN.7.i.i, i64* %UNN.12.i.i.i, align 4, !dbg !31
  ret void
}

Surely I'm just missing something obvious? Needless to say, setting that TTL worked just fine on 1.x.

[whitequark]

The "batch" message type is sent by the attribute_writeback function in ksupport.c, in this case, but I'm not sure why it is unexpected. This seems like a race condition.

[jordens]

It's unexpected because it is not essential. startup_kernels and idle_kernels shouldn't do them or they should be ignored.

[whitequark]

Ah, I completely missed the startup kernel part.

@klickverbot This is rather easily fixed, but also should be inconsequential in this case.

[dnadlinger]

Okay, good to know. I stumbled across this while trying to figure out what broke during our upgrade to ARTIQ 2 and why, and wasn't sure whether it is relevant.

Probably it would be easiest to just ignore these for the startup kernel or log a message that writebacks are ignored? It rather unintuitive to see an ERROR in the logs when everything is in fact okay.

[whitequark]

Ideally artiq_compile would not emit any typeinfo tables, which would also make the startup kernels smaller, but I'm not sure if any more 2.x releases are planned.

[jordens]

sure.