<GitHub72>
[smoltcp] whitequark commented on pull request #110 5883ec7: You're making the same mistake here as with `Mul`, but it's more subtle. In principle, `Duration / Duration` is a meaningful operation (unlike `Duration * Duration`, which returns a physically nonsensical quantity, this returns the ratio of the two durations), but it's not *especially* useful. Instead, this should be an `impl ops::Div<u32> for Duration`.
<GitHub34>
[smoltcp] whitequark commented on pull request #110 5883ec7: No, _this_ should be an unsigned value. Consider a function `fn sleep(Duration)`; how can it possibly sleep for, say, minus one minute? https://github.com/m-labs/smoltcp/pull/110#discussion_r160108274
<GitHub53>
[smoltcp] whitequark commented on pull request #110 5883ec7: This doesn't make sense... Consider the units. You're multiplying `self` (seconds) by `rhs` (also seconds), so you get seconds squared. But you return seconds!... https://github.com/m-labs/smoltcp/pull/110#discussion_r160107965
<GitHub57>
[smoltcp] whitequark commented on pull request #110 5883ec7: This test and the other overflow test above would fail on `cargo test --release` since that doesn't include overflow checks and you don't explicitly use checked operations. I suggest simply removing them, and letting the default Rust arithmetic rules apply to time manipulation, since 64-bit signed overflows and underflows are really not important in this
<GitHub76>
[smoltcp] whitequark commented on pull request #110 5883ec7: You're making the same mistake here as with `Mul`, but it's more subtle. In principle, `Duration / Duration` is a meaningful operation (unlike `Duration * Duration`, which returns a physically nonsensical quantity, this returns the ratio of the two durations), but it's not *especially* useful. The mistake is that the returned quantity has the units of se
<rjo>
whitequark: s*s is exactly as "physically meaningful" as s/s
<rjo>
whitequark: (nitpick)
FabM has quit [Ping timeout: 260 seconds]
_florent_ has quit [Read error: Connection reset by peer]
_florent_ has joined #m-labs
<sb0>
rjo, been busy with other things (accounting, shenzhen trip, fxqi workshop), will look into it tonight/tomorrow
<sb0>
rjo, is the si5324 acting up with the artiq code?
<rjo>
sb0: no idea. artiq is blocked by #886
<sb0>
rjo, just flash the misoc bios (i.e. replace the binary)
<sb0>
I've done that to work around the same issue on sayma before ...
<rjo>
i'd still have to hack the artiq compilation to skip the bios.
<sb0>
yeah, 1 line to comment out
<rjo>
to test anything si5324-releated in artiq there are more changes to be done (i2c switch config for one). not just one line.
<sb0>
I was answering to "i'd still have to hack the artiq compilation to skip the bios."
<sb0>
that's 1 line
<rjo>
sure.
<rjo>
you also asked about the si5324. getting that into artiq-on-kasli is further down on my list. just making sure the HW is ok.
<rjo>
and i wanted to check the SFP modules but the no-name ones I got apparently don't do i2c, or i2c is broken. but they and the fiber works fine otherwise in a sufficiently ignorant switch.
<sb0>
rjo, on which SFP is the Ethernet connected?
<rjo>
sfp0
<sb0>
ok, and it's SFP1 that has the routing issue?
<rjo>
yes
<sb0>
btw who had a full-chain RF setup working out of sayma (amc + rtm + allaki)? was it _florent_ ?
<rjo>
i am not aware of anyone who had that working. but maybe i missed it.
<_florent_>
sb0: not sure i looked the output (we probably spoke about that, but was waiting sawg to be integrated)
<sb0>
but someone got RF output right? was that directly from the SMP connectors on the RTM?
<sb0>
either way, with allaki the attenuator needs to be set up from artiq, with -31.5dB attenuation any signal would be drowned in noise
<sb0>
(depending on time of the day and nearby EMI...)
<rjo>
sb0: just for kicks i also connected sfp2 to the switch.
<GitHub6>
[smoltcp] phil-opp commented on issue #94: Sorry for the delay! I renamed `sockets` to `filter` and the generic parameter for `PacketFilter` from `P` to `F`, and I changed the return type of `process_tcp`.... https://github.com/m-labs/smoltcp/pull/94#issuecomment-355951779
<whitequark>
rjo: yes, badly phrased i guess
<whitequark>
there's no useful quantity denoted by s*s that i'm aware of in our context is what i meant
rohitksingh_work has quit [Read error: Connection reset by peer]
<rjo>
whitequark: absolutely. anyway, smoltcp is not the place to build a unit system...
<whitequark>
rjo: a limited unit system for time is exactlcy what I want in smoltcp
<whitequark>
time being juts u64 has already caused several bugs, one of them took weeks to find
<whitequark>
well, I didn't find it, one of the contributors did
<sb0>
whitequark, you wanted to put another patch onto 3.2
<sb0>
waiting on that now...
<sb0>
smoltcp update with bugfixes iirc
<sb0>
there is also #885
<whitequark>
I believe I did, let me check
<whitequark>
ah no, I didn't, let me do that
<sb0>
whitequark, and what about #885?
<sb0>
if I understand correctly, 885 is a regression between 3.0 and 3.1?
<whitequark>
that makes no sense
<sb0>
hm, no, between 3.1 and current release-3
<sb0>
there were all those rust upgrades...
<sb0>
it would be generally good if we can avoid major changes like that on release branches, but you wanted that for the smoltcp update...
<whitequark>
oh.... I know what happened
<whitequark>
I removed the -g flag because of a compiler bug
<GitHub>
conda-recipes/master e913c6d whitequark: rustc, rust-core-or1k: bump version to 1.23.0.
<sb0>
so yes, there is #885 and that smoltcp update you wanted, then we're good for 3.2 I believe. other issues reported are either non-reproducible or need the 3.2 backtrace feature.
<whitequark>
bb-m-labs: force build --props=package=rustc conda-lin64
<bb-m-labs>
build forced [ETA 1m24s]
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
rjo, iirc the technosystem quotes expired on Jan 1st because they were planning a production run shortly after
<rjo>
sb0: yes. i coordinated that with greg.
<rjo>
certainly DIO_BNC
<whitequark>
okay, artiq builds and runs with rustc 1.23.0
<whitequark>
... but only with -g1. either -g0 or -g2 cause an LLVM assertion failure
<whitequark>
this is one of the more bizarre compiler bugs I've seen
<whitequark>
something's seriously fucked in the way rustc emits debug info and/or the way llvm parses it, that's for sure. it's been very fragile for several versions
<GitHub197>
[smoltcp] whitequark commented on pull request #94 17ea66e: This is quite confusing. A packet not being accepted by any raw socket is not an error condition; this is how `process_raw` is different from e.g. `process_tcp`. Why not just use `Result<bool>` for the return value of this function? Then it'd just be `Ok(handled)`...... https://github.com/m-labs/smoltcp/pull/94#discussion_r160139473
<GitHub128>
[smoltcp] whitequark commented on issue #94: > I'm not sure what to do about the EthernetPacket in egress. We can't lock it down to a single type, since the function is invoked with UDP, TCP, ICMP, and raw packets. So we need some kind of packet enum. Instead of reusing EthernetPacket, we could move these four variants to a more general Packet type, but I'm not sure if it's worth it. What do you think, @whitequark?.
<whitequark>
ugh, out of RAM
<whitequark>
that's with 2G RAM / 1G swap
<whitequark>
rustc release notes promised a 5-10% reduction in memory use! why the hell does it fail to build
<whitequark>
oh, hm
<whitequark>
it didn't inflate to 3g I think
<whitequark>
bb-m-labs: force build --props=package=rustc conda-lin64
<bb-m-labs>
build forced [ETA 1m24s]
<bb-m-labs>
I'll give a shout when the build finishes
rohitksingh has quit [Read error: Connection reset by peer]
<GitHub47>
[smoltcp] phil-opp commented on pull request #94 17ea66e: Hmm… I don't think that variant 2 is worth the additional complexity. We can still implement it later if someone has a need for it. For me, variant 1 sounds most reasonable. However, my use case for smoltcp has all no_std features enabled, so I'm not in a good position to make this decision. https://github.com/m-labs/smoltcp/pull/94#discussion_r160168
<rjo>
sorry. i was messing with the board for the last few minutes. will stop now.
<rjo>
fyi, there is a novogorny connected to eem0, 1000-BX SFPs to the switch on SFP0 and SFP2, jtag patched.
<rjo>
messing with pyftdi unfortunately disappears the serial port devices. will reset.
<sb0>
does unloading/reloading ftdi_sio fix it?
<rjo>
/sys/bus/usb/devices/1-8/authorized
<sb0>
okay, openocd works
<GitHub144>
[smoltcp] phil-opp commented on issue #94: I pushed a new version. Rebasing/merging led to a lot of conflicts, so I decided to implement it again instead. I added a `PacketEmitter` type and addressed your comments on `process_raw` and `process_icmpv4`.... https://github.com/m-labs/smoltcp/pull/94#issuecomment-356002541
<sb0>
the GTP RX section is failing...
<sb0>
rjo, reloading the fpga seems to output some junk into the UART
<rjo>
junk != misoc bios banner, i guess
<rjo>
iirc i have seen the first couple of lines converted into garbage quite a while ago. no idea how that happens.
<sb0>
yes, i'm reloading a small test design
<sb0>
direct by jtag
<rjo>
if you get around to assinging mac, ip, hostname: 00:0a:35:6c:f6:14, 10.0.16.12, lauda.ber.quartiq.de
<sb0>
the first microscope invokation after a fpga reload breaks. doesn't happen on kc705, nor (for once!) on sayma.
<rjo>
at least on kasli and so far for me the bus powered ftdi section works fine (can cold book kasli without any usb hiccups).
<GitHub84>
[smoltcp] whitequark commented on pull request #94 d2d553f: Let's go with variant 1 for now, then. Since a `socket-udp` feature would always depend on `proto-udp` we can backwards compatibly update to 2 if it's ever needed. https://github.com/m-labs/smoltcp/pull/94#discussion_r160230824
<GitHub24>
[smoltcp] whitequark commented on issue #94: > I'm not sure about the code related to has_neighbor (see the second commit). For now I added the method to the emitter trait, but I'm not sure if this is the best solution.... https://github.com/m-labs/smoltcp/pull/94#issuecomment-356101425
<whitequark>
dlrobertson: no change of seconds vs milliseconds
<whitequark>
what I'm talking about is you're returning seconds squared (or milliseconds squared, if you want) as a Duration, and Duration has the base unit of seconds, not seconds squared
<dlrobertson>
Yeah, that makes sense... I guess, I'm thinking of the user that just runs Duration::from_millis(some_duration * 5) since most everything else works that way