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
<GitHub40> [smoltcp] whitequark commented on pull request #225 09f68be: By definition it's already at `u8::max_value`. https://github.com/m-labs/smoltcp/pull/225#discussion_r194207374
<GitHub139> [smoltcp] whitequark commented on pull request #225 09f68be: An assertion that local_rx_dup_acks doesn't overflow to 0 would be good here. https://github.com/m-labs/smoltcp/pull/225#discussion_r194207639
<GitHub5> [smoltcp] whitequark commented on pull request #225 09f68be: I think it's more useful to say "255+" instead of just "overflowed". https://github.com/m-labs/smoltcp/pull/225#discussion_r194207454
<GitHub179> [smoltcp] whitequark commented on pull request #225 09f68be: Nit: you're setting *timer* for fast retransmit; a better message is something like "starting fast retransmit". https://github.com/m-labs/smoltcp/pull/225#discussion_r194207552
_whitelogger has joined #m-labs
<GitHub22> [smoltcp] barskern commented on pull request #225 09f68be: I agree with this, however the reason for the awkward debug log is that this action doesn't technically send a retransmit, but it sets the socket up to send one. When the timeout expires for a "normal" retransmit it says something similar to this, hence I used the same phrase. https://github.com/m-labs/smoltcp/pull/225#discussion_r194208894
<GitHub135> [smoltcp] barskern commented on pull request #225 09f68be: I agree with this, however the reason for the awkward debug log is that this action doesn't technically send a retransmit, but it sets the socket up to send one. When the timeout expires for a "normal" retransmit it says something similar to this, hence I used the same phrase. https://github.com/m-labs/smoltcp/pull/225#discussion_r194208894
<GitHub116> [smoltcp] barskern commented on pull request #225 e9e5502: I added an assertion that checks this now, but I added it over lines you specified because if it would overflow to 0 it would happen after the `send` on line [3441](https://github.com/m-labs/smoltcp/pull/225/files#diff-d23c2633f4bdb8a9adc8ce0e490bcd12R3441). https://github.com/m-labs/smoltcp/pull/225#discussion_r194209182
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1040: Did you rework the hmc7043 reset and update misoc? https://github.com/m-labs/artiq/issues/1040#issuecomment-395929144
sb0 has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1063: Yes, regular signal handlers have the same unsolvable race condition bug.... https://github.com/m-labs/artiq/issues/1063#issuecomment-395931638
kaolpr has quit [Ping timeout: 265 seconds]
kaolpr has joined #m-labs
<GitHub144> [smoltcp] whitequark commented on pull request #225 e9e5502: I hate to nitpick, but this match statement could be replaced with a `if self.local_rx_dup_acks == u8::max_value() { "+" } else { "" }` in the debug statement below, and then we wouldn't have logic and presentation of debug logging mixed. https://github.com/m-labs/smoltcp/pull/225#discussion_r194212873
<sb0> rjo, I tested the latest misoc, and the #1040 problem is still there
<sb0> so is #1039
<sb0> did you test the new code on the board? am I doing something dumb?
sb0 has quit [Quit: Leaving]
_whitelogger has joined #m-labs
<rjo> sb0: i tested all and couldn't reproduce them. but if it is still broken then i guess i messed up the testing.
hartytp has joined #m-labs
<hartytp> sb0: can we add microscope probes to the sawg output and capture a trace with a few cycles of the output
<hartytp> That would verify that the problem is indeed the sawg
<hartytp> Then add probes to different parts of the signal chain to pin down where the issue is?
<hartytp> (By the way, I really like microscope from my brief play with it yesterday)
hartytp has quit [Ping timeout: 260 seconds]
hartytp has joined #m-labs
<hartytp> Afaict that's easy to do with microscopes buffered probes
<hartytp> rjo: if you let me know what probes you want then I'm happy to give that a go tomorrow
hartytp has quit [Ping timeout: 260 seconds]
<GitHub-m-labs> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/0b086225a9ede6bd6a9fe8b8efe0056251554336
<GitHub-m-labs> artiq/master 0b08622 Robert Jördens: sawg: don't use Cat() for signed signals...
<GitHub9> [smoltcp] barskern commented on pull request #225 e9e5502: Don't worry about nitpicking, I think that is a great way of maintaining a good code standard! And I like getting your feedback because it makes me think twice about how I would write something. Keep on nitpicking 😊 https://github.com/m-labs/smoltcp/pull/225#discussion_r194221448
<GitHub107> [smoltcp] barskern commented on issue #224: @pothos Could you run the same test that generated this issue in the first place? I'm excited to see if it works now :zap: https://github.com/m-labs/smoltcp/issues/224#issuecomment-395957751
<bb-m-labs> build #1635 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1635
<bb-m-labs> build #2438 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2438 blamelist: Robert J?rdens <rj@quartiq.de>
<rjo> sb0: could you try again? i think i identified the wrong change as the one that fixed it. but i still don't get it.
<rjo> while i was running a barely modified test of #1039 the output signal disappeared and subsequent load/start all lead to this. tripped supply, a rework come undone?
<rjo> tried usb resets, the power cycler.
<GitHub-m-labs> [artiq] jbqubit commented on issue #1040: > update misoc... https://github.com/m-labs/artiq/issues/1040#issuecomment-395973896
<GitHub-m-labs> [artiq] jbqubit commented on issue #1039: @jordens Is this still open? cf https://irclog.whitequark.org/m-labs/2018-06-09#22299432; Closed status following commit implies to me that I can reproduce fix by rebuilding. https://github.com/m-labs/artiq/issues/1039#issuecomment-395974403
jbqubit_ has joined #m-labs
jbqubit_ has quit [Client Quit]
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1039: @jbqubit Please try it, the Sayma in HK is currently broken. https://irclog.whitequark.org/m-labs/2018-06-09#1528542903-1528545687; https://github.com/m-labs/artiq/issues/1039#issuecomment-395974582
sb0 has joined #m-labs
<sb0> rjo, just reflashed an older gateware/firmware and same problem. looks like a hardware issue indeed. i haven't physically disturbed the board, so I don't know what happened...
<sb0> we have another RTM but one DAC on it is broken
<sb0> or Joe's board can be used remotely
jbqubit_ has joined #m-labs
<sb0> jbqubit_, can you compile and testing the latest artiq (with https://github.com/m-labs/artiq/commit/0b086225a9ede6bd6a9fe8b8efe0056251554336) on your board?
<sb0> jbqubit_, btw how much crap did the customs give you/Greg when you sent the boards back to PL? did you write anything special on the declaration?
jbqubit_ has quit [Ping timeout: 260 seconds]
jbqubit_ has joined #m-labs
<jbqubit_> I've received two shipments now from Warsaw that breezed through customs. Including the right type of information as to the package contents proved helpful. Here's my latest advice on that front.
<jbqubit_> I'm away from the lab today and powered off my Sayma. So I can build gateware but can't do/host tests until I return to UMD tomorrow.
<sb0> jbqubit_, that's to UMD. I'm asking to Poland.
<jbqubit_> To test current SAWG the RTM with a single working DAC seems sufficient.
<jbqubit_> I've had good experience lately shipping to Technosystem using FedEx. Greg lives near their facility and is able to pickup packages quickly.
<sb0> yeah, but if you check the wrong boxes then there is a big customs tariff
<jbqubit_> I've asked a couple students who might be working today at UMD to cycle power on Sayma board. Will let you know if somebody switches it on.
<jbqubit_> In addition to detailing the contents of the package, indicate that the devices are being returned for repair and that they will be sent back to HK.
<jbqubit_> Might be helpful to ask Technosystem to create a Return Merchandise Authorization (RMA) number or some such official sounding thing.
<sb0> yeah, well, Greg seems blissfully unaware of such things
<sb0> and detailing the contents of the package can backfire. for the Sayma board I sent to Duke, I explained it was a "signal generator" and this resulted in imbecilic customs questions such as "what is the horsepower of the diesel engine inside the generator"
<jbqubit_> For import to USA I've honed the language of shipping-to-umd advice based on experience with such imbecilic questions. Some of the email threads with customs agents have gone on for > 5 back and forth.
<sb0> on the other hand, packages with vague descriptions such as "electronic circuit" are sometimes simply waved through
<jbqubit_> I tried vague sounding contents. It never worked for me. Specific part numbers, manufacturer name, description of part, description of end us of part and comment on potential hazards of part seem to cover the bases.
<reportingsjr> Write "gift". That is the real trick.
<sb0> "gift" works between individuals, but i'm not sure if shipments between companies/universities labeled as "gift" would seem suspicious
<sb0> it also can be considered illegal and get us into trouble.
<reportingsjr> :) I wasn't being serious
<reportingsjr> That's just what 80% of vendor on aliexpress put on packages
<sb0> yeah, in the aliexpress/taobao/etc. world, some companies also let you provide the declared value and give you a "hint for information purposes only" of what the declared value is for packages of similar size taking that route
<sb0> those import/export declarations are just a joke. on several occasions I've exported resistors by certifying that I would use them for the purpose of creating voltages proportional to the current through the resistor.
jbqubit__ has joined #m-labs
jbqubit__ has quit [Client Quit]
jbqubit__ has joined #m-labs
<sb0> why something as commonplace as regular 0603 1% resistors require such a declaration is also a mystery.
jbqubit__ has quit [Client Quit]
jbqubit_ has quit [Ping timeout: 260 seconds]
sb0 has quit [Quit: Leaving]
jbqubit_ has joined #m-labs
jbqubit_ has quit [Client Quit]
jbqubit_ has joined #m-labs
<jbqubit_> UMD Sayma is now powered on, booted and responding to ping.
<jbqubit_> SB has login credentials and instructions
<jbqubit_> Web-based oscilloscope on local subnet is connected to a pair of sawg, one from each DAC chip.
swivel has left #m-labs [#m-labs]
jbqubit_ has quit [Ping timeout: 260 seconds]
Gurty has quit [Excess Flood]
Gurty has joined #m-labs
kristianpaul has quit [Ping timeout: 245 seconds]
Gurty has joined #m-labs
Gurty has quit [Changing host]
kristianpaul has joined #m-labs
mumptai has joined #m-labs
jfng has quit [Ping timeout: 240 seconds]
felix[m] has quit [Ping timeout: 255 seconds]
marbler has quit [Ping timeout: 255 seconds]
<GitHub5> [smoltcp] whitequark commented on issue #225: @m-labs-homu r+ https://github.com/m-labs/smoltcp/pull/225#issuecomment-395990946
<GitHub25> [smoltcp] m-labs-homu commented on issue #225: :pushpin: Commit 0dbfa65 has been approved by `whitequark`
<GitHub16> [smoltcp] m-labs-homu commented on issue #225: :hourglass: Testing commit 0dbfa65ac460ed61a1a0eb4ad9d3b5f6e4a87474 with merge 216c393607927260ca2928648917ed27e75feeff... https://github.com/m-labs/smoltcp/pull/225#issuecomment-395990962
<GitHub28> [smoltcp] m-labs-homu pushed 1 new commit to auto: https://github.com/m-labs/smoltcp/commit/216c393607927260ca2928648917ed27e75feeff
<GitHub28> smoltcp/auto 216c393 Ole Martin Ruud: Fix implementation of fast retransmit (TcpSocket)...
<GitHub90> [smoltcp] whitequark commented on issue #219: Sorry, I didn't notice you updated the PR. It looks good to me now. Can you squash the commits? https://github.com/m-labs/smoltcp/pull/219#issuecomment-395991010
<travis-ci> m-labs/smoltcp#1006 (auto - 216c393 : Ole Martin Ruud): The build passed.
<GitHub160> [smoltcp] m-labs-homu commented on issue #225: :sunny: Test successful - [status-travis](https://travis-ci.org/m-labs/smoltcp/builds/390192451?utm_source=github_status&utm_medium=notification)
<GitHub162> [smoltcp] m-labs-homu closed pull request #225: Fixes bug regarding dup_acks overflow (TcpSocket) (master...bug/fix-dup-acks-overflow) https://github.com/m-labs/smoltcp/pull/225
<GitHub76> [smoltcp] m-labs-homu merged auto into master: https://github.com/m-labs/smoltcp/compare/d6fd91cc59d0...216c39360792
<travis-ci> m-labs/smoltcp#1007 (master - 216c393 : Ole Martin Ruud): The build passed.
ohsix has quit [Ping timeout: 240 seconds]
felix[m] has joined #m-labs
<GitHub121> [smoltcp] ProgVal commented on issue #219: Done! https://github.com/m-labs/smoltcp/pull/219#issuecomment-395999589
jfng has joined #m-labs
marbler has joined #m-labs
<travis-ci> ProgVal/smoltcp#25 (managedmap-routes - f81d902 : Valentin Lorentz): The build passed.
kristianpaul has quit [Quit: Lost terminal]
<GitHub144> [smoltcp] whitequark commented on issue #219: @m-labs-homu r+ https://github.com/m-labs/smoltcp/pull/219#issuecomment-396000178
<GitHub121> [smoltcp] m-labs-homu commented on issue #219: :pushpin: Commit f81d902 has been approved by `whitequark`
<GitHub199> [smoltcp] m-labs-homu pushed 1 new commit to auto: https://github.com/m-labs/smoltcp/commit/06d18130cd8b25edbcad207bbdbb157f1c1203df
<GitHub199> smoltcp/auto 06d1813 Valentin Lorentz: Add support for arbitrarily many routes instead of only gateways....
<GitHub18> [smoltcp] m-labs-homu commented on issue #219: :hourglass: Testing commit f81d9028ac9befe4cc880a658b51f5a36e50371f with merge 06d18130cd8b25edbcad207bbdbb157f1c1203df... https://github.com/m-labs/smoltcp/pull/219#issuecomment-396000193
kristianpaul has joined #m-labs
<GitHub57> [smoltcp] m-labs-homu commented on issue #219: :sunny: Test successful - [status-travis](https://travis-ci.org/m-labs/smoltcp/builds/390228449?utm_source=github_status&utm_medium=notification)
<travis-ci> m-labs/smoltcp#1009 (auto - 06d1813 : Valentin Lorentz): The build passed.
<GitHub1> [smoltcp] m-labs-homu merged auto into master: https://github.com/m-labs/smoltcp/compare/216c39360792...06d18130cd8b
<GitHub113> [smoltcp] m-labs-homu closed pull request #219: Add support for arbitrarily many routes instead of only gateways. (master...managedmap-routes) https://github.com/m-labs/smoltcp/pull/219
<GitHub20> [smoltcp] m-labs-homu commented on issue #178: :umbrella: The latest upstream changes (presumably 06d18130cd8b25edbcad207bbdbb157f1c1203df) made this pull request unmergeable. Please resolve the merge conflicts. https://github.com/m-labs/smoltcp/pull/178#issuecomment-396000642
<travis-ci> m-labs/smoltcp#1010 (master - 06d1813 : Valentin Lorentz): The build passed.
<GitHub174> [smoltcp] jhwgh1968 opened pull request #232: [WIP] TCP Window Scaling Phase 1 (master...tcp-win-scaling-phase-1) https://github.com/m-labs/smoltcp/pull/232
<GitHub131> [smoltcp] ProgVal closed issue #209: RFC: multiple routes https://github.com/m-labs/smoltcp/issues/209
<GitHub143> [smoltcp] ProgVal commented on issue #209: Closed by #219 https://github.com/m-labs/smoltcp/issues/209#issuecomment-396003375
<GitHub193> [smoltcp] ProgVal commented on pull request #232 67c539c: nit: not sure about this repo's coding style, but I personally prefer this: `repr.window_scale = self.remote_win_scale.map(|_| 0)` https://github.com/m-labs/smoltcp/pull/232#discussion_r194240529
<GitHub146> [smoltcp] whitequark commented on pull request #232 67c539c: `.unwrap_or(0)` https://github.com/m-labs/smoltcp/pull/232#discussion_r194240586