03:20 <whitequark> sb0: hm, so idle/startup kernens seem to be basically broken right now

03:27 <GitHub> [artiq] whitequark closed issue #710: artiq_compile of kernel using print() should error out https://github.com/m-labs/artiq/issues/710

03:27 <GitHub> [artiq] whitequark opened issue #716: Idle/startup kernels are broken https://github.com/m-labs/artiq/issues/716

03:56 <bb-m-labs> build #513 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/513

04:05 <bb-m-labs> build #456 of artiq-win64-test is complete: Warnings [warnings python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/456 blamelist: whitequark <whitequark@whitequark.org>

04:05 <bb-m-labs> build #1454 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1454

10:33 <GitHub> [artiq] cjbe commented on issue #712: In addition, the replay function is very slow - the run-time of `self.core_dma.replay("test")` is ~1.3 ms! This is 2 or 3 orders of magnitude longer than certain DMA sequence durations. https://github.com/m-labs/artiq/issues/712#issuecomment-293218102

15:50 <GitHub> [artiq] whitequark commented on issue #712: That stems out of a similar design decision--every DMA replay first requests the address from the comms CPU, which performs a cache flush (even two, really). I do not see any especially good way to work around that. It might be possible to write a hack. https://github.com/m-labs/artiq/issues/712#issuecomment-293307368

15:54 <GitHub> [artiq] cjbe commented on issue #712: Sharing recorded DMA sequences between kernel runs is a much lower priority to me than having fast DMA recording and low-latency DMA playback.... https://github.com/m-labs/artiq/issues/712#issuecomment-293308553

15:59 <GitHub> [artiq] whitequark commented on issue #712: > Would removing the persistance of DMA sequences between kernels allow us to solve these speed issues?... https://github.com/m-labs/artiq/issues/712#issuecomment-293310243

16:13 <GitHub> [artiq] cjbe commented on issue #712: Assuming that the time taken to record a DMA sequence is comparable to the time taken to directly output these events, these do not seem like problematic issues - this means that for any sequence fragment that one wants to replay more than a handful of times per kernel, it is cheaper to record it and play it back than it is to directly output the events each time.... https://github.com/m-labs/artiq/issues/712#i

16:14 <GitHub> [artiq] whitequark commented on issue #712: > Assuming that the time taken to record a DMA sequence is comparable to the time taken to directly output these events... https://github.com/m-labs/artiq/issues/712#issuecomment-293314778

16:26 <sb0> whitequark, can't the kernel CPU access the sequence name → DMA address directly in memory?

16:26 <sb0> it doesn't really need to ask the comms CPU

16:27 <sb0> that structure is also modified only during calls to record() or delete() so clearing the caches there only is sufficient

16:35 <GitHub> [artiq] sbourdeauducq pushed 1 new commit to release-2: https://github.com/m-labs/artiq/commit/90e2e22765d005c4fa9cbeba5674e4b4f041e86d

16:35 <GitHub> artiq/release-2 90e2e22 whitequark: artiq_compile: make print() write to core log, not an invalid op....

16:36 <whitequark> sb0: no, it cannot

16:36 <sb0> why?

16:36 <whitequark> if it has to insert a record, it needs access to the comms CPU allocator, to which it does not have exclusive access

16:37 <sb0> why would it insert a record during playback?

16:37 <whitequark> it wouldn't

16:37 <sb0> ok, so doing what I propose would solve the playback performance issue

16:37 <whitequark> that wouldn't solve the record performance issue

16:38 <sb0> yes, for the record performance issue, preparing batches and sending them to the comms CPU sounds like the right option, as discussed before

16:39 <whitequark> that's still not "approximately as fast as just outputting to RTIO" though

16:39 <whitequark> which is what cjbe requests

16:43 <GitHub> [artiq] sbourdeauducq pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/296dc3b0c42d...c5cd77f1775b

16:43 <GitHub> artiq/master c5cd77f Sebastien Bourdeauducq: manual: add DRTIO intro

16:43 <GitHub> artiq/master 598533a Sebastien Bourdeauducq: manual: add DMA to tutorial

16:44 <sb0> whitequark, the buildbot VMs didn't restart automatically

16:44 <sb0> well the windows ones didn't

16:45 <sb0> $ sudo xl create /var/vms/win7-buildbot.cfg

16:45 <sb0> Parsing config from /var/vms/win7-buildbot.cfg

16:45 <sb0> libxl: error: libxl_create.c:881:initiate_domain_create: cannot make domain: -3

16:45 <sb0> libxl: error: libxl_create.c:537:libxl__domain_make: domain creation fail: Invalid argument

16:47 <whitequark> hm

16:49 <sb0> mh, is there some BIOS option that needs to be enabled again?

16:50 <whitequark> did it reset setup? if so yes

16:50 <whitequark> enable VT-x and VT-d

16:50 <sb0> yes, it could have done some idiotic thing like that

16:50 <sb0> sigh

16:51 <sb0> instead of making things just work and booting, the ASUS BIOS blocked the machine until I connected a screen and keyboard and entered the BIOS

16:51 <sb0> then after that it served me the UEFI bullshit until I disabled secure boot

16:52 <whitequark> oh, it sounds like it reset setup precisely because you changed CPU

16:53 <sb0> yes, sounds like it

16:53 <whitequark> maybe it's not certain in its ability to boot again without flipping all features to default

16:53 <sb0> the message was something like "New CPU installed, press F1 to enter BIOS"

16:53 <whitequark> yes I've seen the screen copy

16:54 <sb0> I sent you the UEFI one, there was another one before

16:54 <whitequark> oh

16:54 <sb0> anyway, I'll enable the BIOS virtualization options next time

16:55 <whitequark> are you not in the lab?

16:55 <sb0> not anymore

16:55 <whitequark> ok

16:55 <whitequark> this will break our tests

16:59 <sb0> whitequark, are you installing something?

17:00 <sb0> E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)

17:00 <whitequark> yes, I'm updating the syste

17:00 <whitequark> m

17:00 <whitequark> it's not been updated in ages, not sure why unattended-upgrades failed

17:02 <sb0> well is there any chance I can enable the BIOS option via efivar?

17:03 <whitequark> it requires reboot

17:03 <whitequark> also, do not mess with efivarfs

17:03 <sb0> yes, but reboot can be done remotely too

17:03 <whitequark> there is a chance that you will irreparably break the motherboard

17:03 <whitequark> well, unless you want to manually tinker with the SPI flash or something.

17:04 <whitequark> on top of that, setup is buggy enough, and there is no guarantee it actually interperts the values in efivarfs the same way as linux

17:04 <whitequark> for example, on this laptop, they absolutely do not agree, and writing to efivarfs directly just messes them up

17:05 <sb0> ok

17:05 <bb-m-labs> build #514 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/514

17:07 <sb0> so, the build time from the bitstream went from 19:41 to 13:37

17:07 <sb0> *for

17:09 <whitequark> that's quite a bit better

17:09 <whitequark> is this a top-of-the-line CPU?

17:09 <sb0> i7-4771

17:09 <sb0> the fastest you can put on that mobo without reflashing the BIOS

17:10 <whitequark> excellent

17:32 <GitHub> [artiq] hartytp commented on issue #712: > @cjbe Sharing recorded DMA sequences between kernel runs is a much lower priority to me than having fast DMA recording and low-latency DMA playback.... https://github.com/m-labs/artiq/issues/712#issuecomment-293337774

17:37 <GitHub> [artiq] cjbe commented on issue #712: I think sharing state between different experiments and different kernels is a pain to manage for the user. I think it is much better for each kernel to explictly record the sequences it needs. The only reason not to do this is if there is too much overhead, either in the compile / upload step, or the run-time of the kernel DMA recording is too large. https://github.com/m-labs/artiq/issues/712#issuecomment-2933

17:52 <GitHub> [artiq] jordens commented on issue #712: Veto.... https://github.com/m-labs/artiq/issues/712#issuecomment-293345059

17:55 <sb0> whitequark, how long does it take to look up the DMA address given the name?

17:55 <sb0> (just for the data structure access)

18:01 <whitequark> it's a btreemap, so depends on how large the map is

18:44 <GitHub> [artiq] klickverbot commented on issue #709: A shot in the dark without even looking at the IR: Does the compiler use `[10240 x i32]` internally somewhere as a value type, for example when passing parameters, or to `load` from and store into another pointer? We had similar issues in LDC a while back; `[a x b]` is rather deeply ingrained as meaning "a collection of registers" in LLVM, and loading to then store to another pointer, as mentioned before, wi

19:14 <whitequark> sb0: ok, lab. is updated

20:14 <whitequark> sb0: [26516.818046] xhci_hcd 0000:00:14.0: WARN Event TRB for slot 5 ep 2 with no TDs queued?

20:14 <whitequark> can we turn that message off somehow

20:14 <whitequark> sb0: also, I've confirmed VT-x and VT-d are disabled in BIOS

20:14 <whitequark> $ sudo xl dmesg

22:46 <whitequark> sb0: ha, CRC Handbook has a section on bayard-alpert gauges

22:46 <whitequark> we should get one for the lab too

22:46 <whitequark> it's ridiculously useful

23:02 <ohsix> that book is cool

23:03 <ohsix> there's an engineering mini notebook that i dig that is similar, but that handbook looks like the mini notebook x 500

23:05 <ohsix> doh that's not the name, so much for how much i love it; https://en.wikipedia.org/wiki/Pocket_Ref

23:06 <ohsix> it's very good, iirc it even has information about cpr and medical care in a lab/diy setting