<_florent_>
sb0: IIRC rtio and rtio_tx are using the same clock, just that we are generating different resets for rtio_tx
<sb0>
hm. do those different resets need to be there? they were not needed for GTX
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
mumptai_ has quit [Quit: Verlassend]
<_florent_>
sb0: from what i remember it's more related to havint multiple lane. But i'm reworking the init sequence and will see if we can avoid that.
<whitequark>
dlrobertson: because the trait was a basic version of a ManagedMap, and we'll need ManagedMap elsewhere
<whitequark>
i.e. the trait represented a map, but we needed more fields for a map
<GitHub5>
[artiq] whitequark commented on issue #877: @jonaskeller Could you please run flterm to see if there are any messages on the console? This seems like the runtime panicking, and seeing the panic message would be very helpful. https://github.com/m-labs/artiq/issues/877#issuecomment-353300094
<GitHub51>
[smoltcp] whitequark commented on issue #97: This is not actually a bug, but a side effect of the fact that `server.rs` never reads from `tcp:6969`. As a result, the TCP in your kernel is ever trying (unsuccessfully) to push the rest of the data sent by curl in. Since `server.rs` also never aborts the connection (it only closes its half-connection) this can go on indefinitely. There is no off-by-one involved.... h
<GitHub153>
[smoltcp] whitequark commented on issue #97: This is not actually a bug, but a side effect of the fact that `server.rs` never reads from `tcp:6969`. As a result, the TCP in your kernel is ever trying (unsuccessfully) to push the rest of the data sent by curl in. Since `server.rs` also never aborts the connection (it only closes its transmit half-connection) this can go on indefinitely. There is no off-by-one involve
<GitHub184>
smoltcp/master d1e2292 whitequark: Panic on an attempt of subtracting sequence numbers with underflow....
<GitHub113>
[smoltcp] whitequark commented on issue #62: @pothos I'm finally making progress on this—see d1e2292 for one method I'm using to expose underlying bugs. I am afraid that your fix is hiding one of them. https://github.com/m-labs/smoltcp/issues/62#issuecomment-353340310
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
<travis-ci>
m-labs/smoltcp#497 (master - d1e2292 : whitequark): The build passed.
rjo1 has quit [Read error: Connection reset by peer]
rjo2 has joined #m-labs
rjo2 has quit [Read error: Connection reset by peer]
rjo3 has joined #m-labs
<GitHub102>
[artiq] whitequark commented on issue #879: I believe the purpose of this is setting the path to proxy bitstreams. Since we now build packages exclusively on the buildbot it is no longer necessary. https://github.com/m-labs/artiq/issues/879#issuecomment-353417306
<GitHub125>
[artiq] whitequark commented on issue #879: I believe the purpose of this is setting the environment variable containing the path to proxy bitstreams. Since we now build packages exclusively on the buildbot it is no longer necessary. https://github.com/m-labs/artiq/issues/879#issuecomment-353417306
rohitksingh has quit [Ping timeout: 248 seconds]
rohitksingh1 has joined #m-labs
rohitksingh1 has quit [Read error: Connection reset by peer]
<GitHub53>
[artiq] enjoy-digital commented on issue #856: @sbourdeauducq: i should have fix timing on RTM design (a false path was missing). It seems I'm not able to reproduce easily the issue.... https://github.com/m-labs/artiq/issues/856#issuecomment-353484600
<GitHub150>
[artiq] enjoy-digital commented on issue #856: @sbourdeauducq: i should have fixed timing on RTM design (a false path was missing). It seems I'm not able to reproduce easily the issue.... https://github.com/m-labs/artiq/issues/856#issuecomment-353484600