00:57 <GitHub93> [artiq] philipkent opened issue #888: Installing artiq 3.1 from source fails during rust install https://github.com/m-labs/artiq/issues/888

00:59 <GitHub168> [artiq] whitequark commented on issue #888: Which errors do you get exactly? https://github.com/m-labs/artiq/issues/888#issuecomment-356464648

01:05 <GitHub59> [artiq] philipkent commented on issue #888: cargo:warning=cc: error: ../../libcompiler_builtins/compiler-rt/lib/builtins/absvdi2.c: No such file or directory... https://github.com/m-labs/artiq/issues/888#issuecomment-356465717

01:07 <GitHub37> [smoltcp] whitequark commented on issue #94: > I don't understand the problem with this PR. Is it just because of the has_neighbor related code? Or are there other issues?... https://github.com/m-labs/smoltcp/pull/94#issuecomment-356466052

01:10 <GitHub170> [artiq] philipkent commented on issue #888: I do have three 'libcompiler_bultins' directories but no 'absvdi2.c' file:... https://github.com/m-labs/artiq/issues/888#issuecomment-356466592

01:12 <GitHub184> [artiq] whitequark commented on issue #888: You forgot to run `git submodule update --init` in the Rust sources. https://github.com/m-labs/artiq/issues/888#issuecomment-356466918

01:14 <GitHub129> [artiq] philipkent commented on issue #888: hmm, I'll try it again but I did update the rust submodules. https://github.com/m-labs/artiq/issues/888#issuecomment-356467268

01:24 <GitHub195> [artiq] philipkent commented on issue #888: I tried a second time but I still get the same error. git submodule update --init seemed to go smoothly.... https://github.com/m-labs/artiq/issues/888#issuecomment-356468988

01:25 <GitHub69> [artiq] philipkent commented on issue #888: I tried a second time but I still get the same error. git submodule update --init seemed to go smoothly. Maybe there is something configured incorrectly on my machine?... https://github.com/m-labs/artiq/issues/888#issuecomment-356468988

01:26 <GitHub167> [artiq] whitequark commented on issue #888: Oh! `git submodule update --init --recursive`. https://github.com/m-labs/artiq/issues/888#issuecomment-356469427

01:27 <GitHub33> [artiq] whitequark pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/2009734b3c61...0ce63e7f4ae5

01:27 <GitHub33> artiq/master 0ce63e7 whitequark: doc: Rust uses recursive submodules (brrr)....

01:27 <GitHub33> artiq/master 1683229 whitequark: doc: update Rust version....

01:29 <GitHub115> [artiq] whitequark pushed 2 new commits to release-3: https://github.com/m-labs/artiq/compare/a4337944835d...4f3e7af8d5c4

01:29 <GitHub115> artiq/release-3 4f3e7af whitequark: doc: Rust uses recursive submodules (brrr)....

01:29 <GitHub115> artiq/release-3 3b82c58 whitequark: doc: update Rust version....

01:30 <GitHub169> [artiq] philipkent commented on issue #888: Ah! Will try that, thanks. https://github.com/m-labs/artiq/issues/888#issuecomment-356469999

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

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

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

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

02:25 <GitHub18> [artiq] philipkent commented on issue #888: That fixed the 'absvdi2.c' error, thanks!. Now it's failing for not being able to find llvmconfig. Is that supposed to be installed as apart of the LLVM and Clang build? There were a few directory permission issues on this machine earlier so it may be that llvmconfig is just not visible for my user. I'm going to look into that more tomorrow. https://github.com/m-labs

02:26 <GitHub40> [artiq] philipkent commented on issue #888: That fixed the 'absvdi2.c' error, thanks! Now it's failing for not being able to find llvmconfig. Is that supposed to be installed as apart of the LLVM and Clang build? There were a few directory permission issues on this machine earlier so it may be that llvmconfig is just not visible for my user. I'm going to look into that more tomorrow.... https://github.com/m-la

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

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

02:39 <GitHub170> [artiq] whitequark commented on issue #888: > Is that supposed to be installed as apart of the LLVM and Clang build?... https://github.com/m-labs/artiq/issues/888#issuecomment-356482425

02:42 <whitequark> sb0: http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/684/steps/python_coverage/logs/stdio

02:43 <whitequark> why does this intermittently fail?

02:43 <sb0> dunno. probably some race condition. would help to know what the extra log messages are...

02:44 <sb0> "Mismatch between gateware (3.2+3.g4f3e7af8) and software (3.2+2.g4f3e7af8) versions"

02:44 <sb0> wasn't the board flashed just before?

03:32 <whitequark> huh.

03:32 <whitequark> that's weird.

03:32 <whitequark> how did you get that?

03:35 <GitHub192> [artiq] sbourdeauducq commented on issue #854: @gkasprow ... https://github.com/m-labs/artiq/issues/854#issuecomment-356490293

03:37 <sb0> whitequark, in the log you just posted

03:37 <sb0> whitequark, anyway. how is allaki?

03:50 <GitHub80> [artiq] sbourdeauducq deleted master+rtio-sed at c503542: https://github.com/m-labs/artiq/commit/c503542

04:05 <sb0> bb-m-labs, force build --branch=sed-merge artiq

04:05 <bb-m-labs> build forced [ETA 41m12s]

04:05 <bb-m-labs> I'll give a shout when the build finishes

04:05 <GitHub167> [artiq] sbourdeauducq created sed-merge (+1 new commit): https://github.com/m-labs/artiq/commit/dc593ec0f043

04:05 <GitHub167> artiq/sed-merge dc593ec Sebastien Bourdeauducq: Merge branch 'rtio-sed' into sed-merge

04:15 <sb0> bb-m-labs, stop build artiq pebkac

04:15 <bb-m-labs> build 1923 interrupted

04:15 <sb0> bb-m-labs, force build --branch=sed-merge artiq

04:15 <bb-m-labs> build #1923 of artiq is complete: Exception [exception interrupted] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1923

04:15 <bb-m-labs> build forced [ETA 41m12s]

04:15 <bb-m-labs> I'll give a shout when the build finishes

04:15 <GitHub118> [artiq] sbourdeauducq pushed 1 new commit to sed-merge: https://github.com/m-labs/artiq/commit/94d51d1364ee4e0b3cf42004231c45c812814a47

04:15 <GitHub118> artiq/sed-merge 94d51d1 Sebastien Bourdeauducq: firmware: fix drtio_dbg module syntax

04:16 <dlrobertson> whitequark: wow... sorry... got into implementing the ops impls and you're definitely right about the u32

04:17 <dlrobertson> don't know why it took so long to click lol

04:28 <sb0> rohitksingh_work, ping

04:29 <rohitksingh_work> sb0: pong

04:31 <sb0> rohitksingh_work, any update?

04:33 <rohitksingh_work> sb0: sorry I haven't been able to fine time to work on mor1kx modification due to the sydney trip. Good news is that, Julius Baxter (who wrote the prontoespresso TCM module) is also arriving, so I can directly ask him my questions.

04:33 <rohitksingh_work> sb0: _florent_ is also coming, so it would be great! I can flood him with all my doubts :p

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

04:57 <bb-m-labs> build #685 of artiq-win64-test is complete: Warnings [warnings python_coverage] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/685

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

05:15 <GitHub14> [artiq] sbourdeauducq pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/0ce63e7f4ae5...6d58c4390bdf

05:15 <GitHub14> artiq/master 6d58c43 Sebastien Bourdeauducq: Merge branch 'sed-merge'

05:15 <GitHub14> artiq/master 04b2fd3 Sebastien Bourdeauducq: sayma: fix AD9154NoSAWG ramp clock domain

05:18 <GitHub14> [artiq] sbourdeauducq deleted sed-merge at 94d51d1: https://github.com/m-labs/artiq/commit/94d51d1

05:18 <GitHub62> [artiq] sbourdeauducq deleted rtio-sed at f3f8317: https://github.com/m-labs/artiq/commit/f3f8317

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

05:47 <bb-m-labs> build #686 of artiq-win64-test is complete: Warnings [warnings python_coverage] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/686 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>

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

06:49 <sb0> today's new cool bug: vivado startup crashes Xvnc

07:35 <cr1901_modern> Try Xpra?

07:40 <sb0> deleting ~/.Xilinx worked around it

08:11 <sb0> _florent_, shouldn't you set TXOUTCLKSEL to TXPLLREFCLK_DIV2 and not DIV1?

08:11 <sb0> in DRTIO

08:12 <sb0> for artix7

08:50 <GitHub126> [misoc] sbourdeauducq pushed 2 new commits to ethdebug: https://github.com/m-labs/misoc/compare/8286be43c9e5...ab9d2890649d

08:50 <GitHub126> misoc/ethdebug ab9d289 Sebastien Bourdeauducq: a7_1000basex: fix rx_mmcm_reset

08:50 <GitHub126> misoc/ethdebug 3b6e9e7 Sebastien Bourdeauducq: a7_1000basex: fix TXOUTCLKSEL

08:52 <GitHub169> [misoc] sbourdeauducq pushed 2 new commits to master: https://github.com/m-labs/misoc/compare/5a19315e76a1...00573fc42f2e

08:52 <GitHub169> misoc/master 5daaacd Sebastien Bourdeauducq: a7_1000basex: fix TXOUTCLKSEL

08:52 <GitHub169> misoc/master 00573fc Sebastien Bourdeauducq: a7_1000basex: fix rx_mmcm_reset

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

09:54 <rjo> sb0: i don't have a SFP loopback. but doesn't the transciever have an equivalent loopback option?

09:54 <rjo> sb0: there are low cost smp-sma pigtails around

09:58 <rjo> sb0: don't know what broke kasli. i'll check tomorrow

10:46 <sb0> rjo, yes there are loopback options, but at least the PCS loopback had the side effect of hiding a clocking bug...

10:52 <sb0> _florent_, the ftdi-chip on sayma2 seems thorougly borked. did you hit ctrl-c while openocd was running?

10:52 <sb0> doing this usually crashes the ftdi chip until the USB cable is unplugged and replugged, and the board is power-cycled

10:57 <whitequark> you actually have to *power-cycle* it?

10:57 <whitequark> not re-enumerate?

11:00 <sb0> whitequark, how do you re-enumerate?

11:06 <rjo> bin/unbind the driver is one option. sometimes authorized/deauthorized works as well.

11:13 <whitequark> ^

11:20 <sb0> nope

11:20 <sb0> needs physical replugging

11:28 <whitequark> that's impressively fucked

13:00 <sb0> speaking of fucked things, connecting a MMCM on the recovered clock of xilinx transceiver garbage is also something

13:01 <sb0> xilinx can't make PLLs that relock by themselves after being exposed to an unstable clock

13:01 <sb0> xilinx can't make CDRs that tell you when they are locked

13:02 <sb0> their wizard's solution? assume the "typical" CDR lock time from the datasheet (50k UI) after a transceiver reset, and start the PLL from there

13:02 <sb0> nevermind that the datasheet also specifies a maximum lock time of 2.3M UI, or that it won't lock at all if the input signal is flaky

13:02 <sb0> YOLO

13:23 <GitHub166> [misoc] sbourdeauducq pushed 3 new commits to master: https://github.com/m-labs/misoc/compare/00573fc42f2e...8e2210101c17

13:23 <GitHub166> misoc/master d7e6ef3 Sebastien Bourdeauducq: a7_1000basex: expose TX/RXRESETDONE

13:23 <GitHub166> misoc/master a9f060d Sebastien Bourdeauducq: a7_1000basex: reorganize transceiver parameters

13:23 <GitHub166> misoc/master 8e22101 Sebastien Bourdeauducq: a7_1000basex: start MMCMs earlier

13:27 <bb-m-labs> build #340 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/340

13:50 <GitHub95> [misoc] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/misoc/commit/0ed85de7f410c6a3cb24cd8293376208451aedde

13:50 <GitHub95> misoc/master 0ed85de Sebastien Bourdeauducq: a7_1000basex: do not use TXPLLREFCLK divider...

13:55 <bb-m-labs> build #341 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/341

14:09 <sb0> thanks to secureip, you have to guess why the transceiver simulation model is acting up instead of looking into its internal signals

14:09 <sb0> xilinx found that their stuff wasn't sucky enough, they had to deliberately cripple it

15:00 <sb0> _florent_, I'm seeing this right now: https://framapic.org/ZO9Gn1evm5Mn/AwGsW4u80sS6.png

15:00 <sb0> have you experienced bugs like this before?

15:01 <sb0> this is with the simulation model, I cannot access the hardware right now

15:02 <sb0> it would seem, this completely undocumented "RXOSCAL" step takes forever

15:18 <sb0> https://forums.xilinx.com/t5/7-Series-FPGAs/Artix-7-GTP-RXPMARESETDONE-not-behaving-as-described-in-UG482-v1/td-p/684649

15:19 <sb0> just run it longer...?

15:19 <sb0> ok...

15:33 <sb0> rjo, can I get root on the quartiq PC? I want to try resetting JTAG

15:33 <sb0> for kasli

15:41 <GitHub54> [misoc] sbourdeauducq pushed 5 new commits to ethdebug: https://github.com/m-labs/misoc/compare/ab9d2890649d...664d7ec0b31e

15:41 <GitHub54> misoc/ethdebug e0a761e Sebastien Bourdeauducq: a7_1000basex: reorganize transceiver parameters

15:41 <GitHub54> misoc/ethdebug 953c1c3 Sebastien Bourdeauducq: a7_1000basex: expose TX/RXRESETDONE

15:41 <GitHub54> misoc/ethdebug 64e53dd Sebastien Bourdeauducq: a7_1000basex: start MMCMs earlier

15:42 <GitHub90> [misoc] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/misoc/commit/f33006857160bc97f4d0e2d76925f4318d88e117

15:42 <GitHub90> misoc/master f330068 Sebastien Bourdeauducq: a7_gtp: fix typo

15:49 <bb-m-labs> build #342 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/342

15:51 <rjo> sb0: i already tried.

15:52 <rjo> sb0: and i think i mentioned that the xilinx cable is not connected to kasli.

20:21 <GitHub100> [sinara] gkasprow pushed 1 new commit to master: https://git.io/vNOT9

20:21 <GitHub100> sinara/master bf89ef1 Greg: DIO-BNC v1.2 rc

23:04 <GitHub82> [sinara] gkasprow pushed 1 new commit to master: https://git.io/vNOBV

23:04 <GitHub82> sinara/master a731e65 Greg: Urukul v1.1 initial commit