<GitHub43>
[artiq] sbourdeauducq commented on issue #711: The problematic packages (chardet, prettytable, aiohttp) are now in conda-forge, and the conda-forge versions (which do not have the problem) should be used instead of ours. I will move ours into an ``obsolete`` label so that conda won't easily find them. https://github.com/m-labs/artiq/issues/711#issuecomment-338852429
<sb0>
bb-m-labs, force build --branch=master+rtio-sed artiq
<bb-m-labs>
build forced [ETA 1h38m44s]
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
2017.2
<rjo>
by the way. i still don't understand xilinx licensing. all the licenses we have should be either expired and not applicable to 2017.2 or are single-device eval. still i can build for the big chips...
<rjo>
sb0: just to check, to test this, i am taking master+rio-sed and building/flashing/using nist_clock. that's it?
<sb0>
yes, I'm just trying to run that right now on the buildbot
<sb0>
I'm not sure if the buildbot ever ran master+rtio-sed. I only saw the bug on rtio-sed. it's whitequark who created master+rtio-sed
<sb0>
another thing I was suggesting whitequark checks is the time, using the analyzer, between a rtio_log right before the dma trigger and the first DMA write attempt by the DMA core
<sb0>
iirc the analyzer should log this information
<rjo>
sb0: i want to exclude the migen changes. i'll let you and whitequark play with that other test.
<sb0>
also: disconnect the underflow report input from the DMA core, pulse a TTL via DMA, and check if the pulse is emitted. if it is, it means it's not a real underflow, just something is hallucinating
<sb0>
okay, I'll do it
<sb0>
whitequark, you also saw something about rtio_get_counter() returning bogus information. the first call right after a runtime reboot, both on rtio-sed and master, is that correct?
<sb0>
if the RTIO counter is not properly transfered into the system clock domain for some reason, that could also generate bogus underflow
<rjo>
that's why i want to exclude changes in timing constraints.
<sb0>
the funny thing is, it doesn't happen when the CPU accesses the RTIO core, and according to whitequark it is a _runtime_ reboot (not bitstream reload) that triggers the get_counter() call to fail. could be some nasty issue with internal FPGA crosstalk, weird synthesized circuit or something like that, maybe
<rjo>
sb0: no. same errors with the timing constraint changes reverted.
<rjo>
whitequark, sb0: do you have a repro for the rtio_counter issue?
<GitHub153>
[smoltcp] whitequark commented on pull request #61 943ab8f: Same as above. https://git.io/vdj5i
<GitHub149>
[smoltcp] whitequark commented on pull request #61 943ab8f: This common initialization code can be taken out of the tests and into a setup function. https://git.io/vdj5P
<GitHub105>
[smoltcp] whitequark commented on pull request #61 943ab8f: Since we are not testing the packet parsing/construction routines here, do you think you could use `EthernetFrame`/`IpRepr`/`ArpRepr`/etc to construct the bytewise representations? That would make tests much easier to understand and write. https://git.io/vdj5K
<GitHub185>
[smoltcp] whitequark commented on pull request #61 943ab8f: A better way to express this would be:... https://git.io/vdj5o
<GitHub114>
[smoltcp] whitequark commented on pull request #61 943ab8f: Same as above. https://git.io/vdj56
sb0 has quit [Ping timeout: 255 seconds]
sb0 has joined #m-labs
<GitHub138>
[smoltcp] whitequark commented on issue #49: Superseded by #57 I think. https://git.io/vdjbB
<GitHub42>
[smoltcp] whitequark closed pull request #49: Move device-specific parts of `EthernetInterface` to new `EthernetDevice` type (master...split-ethernet-interface) https://git.io/vd4Jm
<GitHub106>
[smoltcp] whitequark commented on pull request #57 b74258b: I'm curious, is this really the only way to write this? Or would direct access to `self.device` and `self.inner` also work? No objection to this pattern anyway. https://git.io/vdjAG
<GitHub165>
[smoltcp] whitequark commented on issue #59: Sorry for the delay. https://git.io/vdjAw
<GitHub183>
[smoltcp] whitequark closed issue #58: Add the ability to set the TTL value for a UDP/TCP socket https://git.io/vd1We
<GitHub69>
[smoltcp] whitequark closed pull request #59: Implement set_ttl for Tcp and Udp sockets (master...add_ttl) https://git.io/vd16o
<GitHub22>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/vdjAr
<GitHub22>
smoltcp/master fea4628 Dan Robertson: Implement set_ttl for Tcp and Udp sockets...
<travis-ci>
m-labs/smoltcp#335 (master - fea4628 : Dan Robertson): The build passed.
<GitHub186>
[smoltcp] dlrobertson commented on issue #59: No problem https://git.io/vdjp2
<GitHub139>
[smoltcp] dlrobertson commented on pull request #61 943ab8f: This would definitely be feasible for the ARP tests. I'm not sure about how feasible it would be for this test since the protocol type is a protocol that isn't in `IpProtocol`. https://git.io/vdjpd
<GitHub107>
[smoltcp] dlrobertson commented on pull request #61 943ab8f: Good point https://git.io/vdjpb
<GitHub166>
[smoltcp] whitequark commented on pull request #60 4429f93: Please don't reformat files, this makes it hard to review diffs. https://git.io/vFeeU
<GitHub28>
[smoltcp] whitequark commented on pull request #60 4429f93: The above is just an example, you don't need to add every conceivable error condition. https://git.io/vFeeT
<GitHub18>
[smoltcp] whitequark commented on pull request #60 4429f93: Is there any reason to care about report version? Will you ever emit V1 report packets? If no and no, you should drop this field. https://git.io/vFeet
<GitHub37>
[smoltcp] whitequark commented on pull request #60 4429f93: This is completely unrelated to IGMP, and should not exist in its current form anyhow. https://git.io/vFeek
<GitHub78>
[smoltcp] whitequark commented on pull request #60 4429f93: Missing indent. Also, I sort enums by their numeric value. https://git.io/vFeeI
<GitHub2>
[smoltcp] whitequark commented on pull request #60 4429f93: You can just leave this one check, it implies `len < field::CHECKSUM.end`. https://git.io/vFeeq
<GitHub159>
[smoltcp] whitequark commented on pull request #60 4429f93: `addr.1` also works. https://git.io/vFeev
<GitHub160>
[smoltcp] whitequark commented on pull request #60 4429f93: Maybe check if `eth_frame.dst_addr()` is multicast before trying to do a hash lookup? https://git.io/vFeeJ
<GitHub17>
[smoltcp] whitequark commented on pull request #60 4429f93: Should probably be extracted into a function like `keep_ethernet_frame`; we also currently ignore all IPv4 broadcast packets, which is I think a bug. https://git.io/vFeef
<GitHub72>
[smoltcp] whitequark commented on pull request #60 4429f93: This is unused. https://git.io/vFeeY