sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
_whitelogger has joined #m-labs
<GitHub108> [artiq] sbourdeauducq commented on issue #627: You could have just done print(loop).... https://git.io/v1KkX
<GitHub79> [smoltcp] whitequark pushed 1 new commit to master: https://git.io/v1Km6
<GitHub79> smoltcp/master dea581f whitequark: Implement an ARP LRU cache.
<GitHub6> [artiq] sbourdeauducq commented on issue #640: Are you sure you want to do that, and not simply set the lowest priority on your long experiment that calls ``pause`` in a loop (so if there are any other experiments in the pipeline, they would always get executed when there's a pause, and it would finally reach your ``flush=True`` experiment)? Note that ARTIQ supports an arbitrary number of priority levels. https://git.io/v1KYw
<GitHub4> [artiq] sbourdeauducq commented on issue #640: And if you really want that, you can write this function yourself and put it into the experiment. This will come in handy: https://m-labs.hk/artiq/manual-release-2/management_system.html#artiq.master.scheduler.Scheduler.get_status https://git.io/v1KY9
<GitHub64> [artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/v1K3q
<GitHub64> artiq/master cbc49ea Sebastien Bourdeauducq: set asyncio loop earlier in controllers (#627)
<GitHub64> artiq/master 3743633 Sebastien Bourdeauducq: Revert "pc_rpc: use ProactorEventLoop on Windows (#627)"...
<GitHub161> [artiq] sbourdeauducq pushed 2 new commits to release-2: https://git.io/v1K3m
<GitHub161> artiq/release-2 2962c95 Sebastien Bourdeauducq: set asyncio loop earlier in controllers (#627)
<GitHub161> artiq/release-2 b823e91 Sebastien Bourdeauducq: Revert "pc_rpc: use ProactorEventLoop on Windows (#627)"...
sb0 has quit [Quit: Leaving]
<bb-m-labs> build #262 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/262
<bb-m-labs> build #1159 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1159 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<GitHub188> [artiq] sbourdeauducq closed issue #627: Thorlabs Tdc error with artiq 2.0 https://git.io/v1vjN
<GitHub52> [artiq] sbourdeauducq commented on issue #627: Fixed. https://git.io/v1KZ7
sb0 has joined #m-labs
<GitHub13> [artiq] sbourdeauducq pushed 1 new commit to release-2: https://git.io/v1KnI
<GitHub13> artiq/release-2 453b29a Sebastien Bourdeauducq: RELEASE_NOTES: 2.1
<GitHub38> [artiq] sbourdeauducq tagged 2.1 at release-2: https://git.io/v1KnL
<sb0> bb-m-labs: force build --branch=release-2 artiq
<bb-m-labs> build forced [ETA 23m37s]
<bb-m-labs> I'll give a shout when the build finishes
<sb0> bb-m-labs: force build --props=package=artiq-kc705-nist_qc2 --branch=release-2 artiq-board
<bb-m-labs> build forced [ETA 16m07s]
<bb-m-labs> I'll give a shout when the build finishes
<sb0> bb-m-labs: force build --props=package=artiq-pipistrello-nist_qc1 --branch=release-2 artiq-board
<bb-m-labs> The build has been queued, I'll give a shout when it starts
<bb-m-labs> build #263 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/263
<bb-m-labs> build forced [ETA 19m05s]
<bb-m-labs> I'll give a shout when the build finishes
<bb-m-labs> build #264 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/264
rohitksingh has joined #m-labs
<sb0> bb-m-labs: force build --props=package=artiq-kc705-nist_qc1 --branch=release-2 artiq-board
<bb-m-labs> The build has been queued, I'll give a shout when it starts
<sb0> surprisingly, the previous qc1 package was still downloaded
<whitequark> sb0: hm?
<bb-m-labs> build #265 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/265
<bb-m-labs> build forced [ETA 16m47s]
<bb-m-labs> I'll give a shout when the build finishes
<bb-m-labs> build #266 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/266
<bb-m-labs> build #390 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/390
<bb-m-labs> build #1160 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1160
rohitksingh has quit [Ping timeout: 258 seconds]
<sb0> whitequark, yes?
rohitksingh has joined #m-labs
<GitHub110> [smoltcp] whitequark pushed 1 new commit to master: https://git.io/v1K4R
<GitHub110> smoltcp/master 2fbf820 whitequark: Implement ARP replies.
cr1901 has quit [Ping timeout: 258 seconds]
cr1901 has joined #m-labs
<sb0> whitequark, could there be some rogue DMA engine (misconfigured analyzer?) that trashes lwip memory and produces the crashes?
<sb0> you changed the memory map and rewrote the analyzer code...
<whitequark> hm
<whitequark> let base_addr = &mut BUFFER.data[0] as *mut _ as usize;
<whitequark> let last_addr = &mut BUFFER.data[BUFFER_SIZE - 1] as *mut _ as usize;
<whitequark> this would crash if I made an out-of-bounds access
<whitequark> would analyzer ever write beyond dma_last_address ?
<whitequark> e.g. in case of misaligned address or something like that
<sb0> hm, possibly
<sb0> if you give it a misaligned address it realigns it by setting its LSBs to 0
<sb0> and then writes a whole DRAM word at that address
<sb0> (512 bits on KC705)
<whitequark> ok, let me check
<sb0> I think you can easily disable the analyzer
<sb0> just with the csr
<whitequark> I'll just not arm it
<sb0> yes
<whitequark> I wonder why objdump doesn't sort symbols by address
<whitequark> they implemented a hundred superfluous bullshit features but not this...
<whitequark> sb0: the analyzer buffer is about 0x100 before the lwip data structures so unlikely
<whitequark> there's uart in the way
<whitequark> I mean I'll still check
<whitequark> sb0: nope, still crashes
<GitHub31> [artiq] sbourdeauducq pushed 6 new commits to master: https://git.io/v1KVT
<GitHub31> artiq/master 1c74249 Sebastien Bourdeauducq: runtime: reset local DRTIO state
<GitHub31> artiq/master 9a048c2 Sebastien Bourdeauducq: drtio: order resets wrt writes
<GitHub31> artiq/master ac792ec Sebastien Bourdeauducq: RELEASE_NOTES: 2.1
sb0 has quit [Ping timeout: 250 seconds]
sb0 has joined #m-labs
<bb-m-labs> build #267 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/267
rohitksingh has quit [Quit: Leaving.]
<GitHub121> [migen] sbourdeauducq pushed 1 new commit to master: https://git.io/v1Kov
<GitHub121> migen/master db79467 Sebastien Bourdeauducq: sim: support for AsyncResetSynchronizer
<sb0> bb-m-labs, stop build artiq network bug
<bb-m-labs> build 1161 interrupted
<bb-m-labs> build #1161 of artiq is complete: Exception [exception interrupted] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1161 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs> build #125 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/125
<bb-m-labs> build #184 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/184
<GitHub51> [artiq] sbourdeauducq pushed 3 new commits to master: https://git.io/v1K64
<GitHub51> artiq/master 4b61020 Sebastien Bourdeauducq: drtio: reset more local state
<GitHub51> artiq/master d99e64e Sebastien Bourdeauducq: drtio: clear any stale FIFO space reply
<GitHub51> artiq/master 4c59c0f Sebastien Bourdeauducq: Revert "drtio: order resets wrt writes"...
sb0 has quit [Quit: Leaving]
sandeepkr has joined #m-labs
<bb-m-labs> build #268 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/268
<bb-m-labs> build #1162 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1162
<bb-m-labs> build #1163 of artiq is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1163 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
attie has quit [Remote host closed the connection]
attie has joined #m-labs
mithro has quit []
mithro has joined #m-labs
flaviusb has quit [Ping timeout: 258 seconds]
sb0 has joined #m-labs
<GitHub75> [artiq] jordens pushed 1 new commit to master: https://git.io/v16E5
<GitHub75> artiq/master c63fa46 Robert Jordens: Merge branch 'phaser2'...
<sb0> i'd name the target kc705_phaser for consistency
<sb0> all other targets have the board name
<rjo> i'd like to leave it as a codename. with the other targets the reason was that the codenamed hardware adapters could go with different boards.
<GitHub68> [artiq] jordens pushed 1 new commit to master: https://git.io/v162A
<GitHub68> artiq/master 03d13d3 Robert Jordens: phaser: dma/drtio changes
<bb-m-labs> build #1164 of artiq is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1164 blamelist: Robert Jordens <rj@m-labs.hk>
<bb-m-labs> build #1165 of artiq is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1165 blamelist: Robert Jordens <rj@m-labs.hk>
<GitHub124> [artiq] jmizrahi commented on issue #615: @cr1901 Thanks for the help. I tested the patch today. For individual 32 bit transfers, it worked correctly. All the SPI transfers I attempted worked fine.... https://git.io/v16MR
<sb0> rjo, what about kc705_drtio with paser?
<sb0> *phaser
<rjo> sb0: it would be kc705_ad9154 (if codenames are a no-go, in line with the other names)
<GitHub152> [artiq] dleibrandt commented on issue #640: I have set the lowest priority on my long (main) experiment, and the calibration experiments still never run. I believe this is because `scheduler.check_pause()` only looks for experiments that have finished prepare and doesn't look for experiments that are waiting for the queue to flush. I assume the same is true for `scheduler.pause()`. However, my calibration experiments cannot finish prepare unti
rohitksingh has joined #m-labs
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
rohitksingh has quit [Client Quit]
cr1901 has quit [Ping timeout: 260 seconds]
<GitHub192> [smoltcp] whitequark pushed 3 new commits to master: https://git.io/v1iO9
<GitHub192> smoltcp/master a1587fe whitequark: Implement IPv4 representation parsing and emission.
<GitHub192> smoltcp/master a4e3605 whitequark: Implement ARP snooping.
<GitHub192> smoltcp/master f2104eb whitequark: Implement IPv4 packet support.
cr1901 has joined #m-labs
<GitHub93> [artiq] cr1901 commented on issue #615: @jmizrahi Yea, I noticed this too in my waveforms. The SPI Machine is reversing the timing of the shift/sample signals during clock edges after that glitch. Naturally, the test suite is still passing :).... https://git.io/v1iGy
cr1901 has quit [Ping timeout: 260 seconds]
sandeepkr has quit [Ping timeout: 268 seconds]
flaviusb has joined #m-labs
<GitHub94> [smoltcp] whitequark pushed 2 new commits to master: https://git.io/v1i1n
<GitHub94> smoltcp/master 8204502 whitequark: Implement ICMPv4 echo request/reply representation parsing and emission.
<GitHub94> smoltcp/master e82e744 whitequark: Implement ICMPv4 echo request/reply packet support.
<GitHub151> [smoltcp] whitequark pushed 2 new commits to master: https://git.io/v1i9M
<GitHub151> smoltcp/master 4da6b0b whitequark: Implement ICMPv4 echo replies.
<GitHub151> smoltcp/master 5863997 whitequark: Actually commit ARP snooping.