sb0 changed the topic of #m-labs to: https://m-labs.hk :: Mattermost https://chat.m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
X-Scale has joined #m-labs
forrestv has quit [Ping timeout: 256 seconds]
forrestv has joined #m-labs
airwoodix95 has joined #m-labs
airwoodix9 has quit [Ping timeout: 246 seconds]
airwoodix95 is now known as airwoodix9
forrestv has quit [Quit: ZNC - http://znc.sourceforge.net]
forrestv has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
Gurty has joined #m-labs
Gurty has quit [Changing host]
Gurty has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> @sb10q I thought it was too good to be true that Sayma booted fine on the first try. Any idea why the RTM panics?
<mtrbot-ml> [mattermost] <hartytp> are there any non-obvious things i need to do to get Sayma to boot (dip switches, jumpers, etc)?
<mtrbot-ml> [mattermost] <pkulik> dip switch above fpga - 2nd and 3rd switch to on
<mtrbot-ml> [mattermost] <pkulik> jtag programmer may stop fpga from booting
<mtrbot-ml> [mattermost] <hartytp> @pkulik thanks. I'll add a note on the wiki. but, 1001 is how it shipped to me so looks fine
<mtrbot-ml> [mattermost] <pkulik> in what way does it not boot?
<mtrbot-ml> [mattermost] <hartytp> @pkulik https://github.com/m-labs/artiq/issues/1457
<mtrbot-ml> [mattermost] <hartytp> RTM Si5324 does not ACK
<mtrbot-ml> [mattermost] <pkulik> hmm, I've seen this problem but I didn't have time to investigate
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 265 seconds]
<mtrbot-ml> [mattermost] <sb10q> No I don't know. There was a similar issue on metlino but this was because of the MMC, which can't be a problem here, correct?
<mtrbot-ml> [mattermost] <sb10q> I have not seen it on my boards
<mtrbot-ml> [mattermost] <hartytp> @pkulik okay, good to know it's not just me. Probably coincidence but this is (superficially at least) identical to the issue I had on Kasli v2.0
<mtrbot-ml> [mattermost] <hartytp> This is currently blocking me from doing any more work on Sayma, so do let me know if you can think of anything i can do
<mtrbot-ml> [mattermost] <pkulik> @hartytp one thing you could try is to unplug and replug rtm to amc
<mtrbot-ml> [mattermost] <pkulik> (when powered off of course)
<mtrbot-ml> [mattermost] <hartytp> ok
<mtrbot-ml> [mattermost] <hartytp> why would that help???
<mtrbot-ml> [mattermost] <pkulik> I don't have any theory behind this
<mtrbot-ml> [mattermost] <hartytp> done, but no change
<mtrbot-ml> [mattermost] <hartytp> :(
<mtrbot-ml> [mattermost] <hartytp> I don't know if it's just working outside my normal lab, but things have been a pain recently. Even to the point where Kasli v1.1 wouldn't give me a link on ethernet at all. Eventually @dpn suggested plugging ethernet directly into my laptop rather than going through an ethernet switch, which fixed the problem which fixed things (@sb10q any idea why that is?). Just lots of small unexpected issues which are eatin
<mtrbot-ml> [mattermost] <sb10q> 100Mbit/s switch?
<mtrbot-ml> [mattermost] <hartytp> DES-108
<mtrbot-ml> [mattermost] <hartytp> aah, is Kasli GB only?
<mtrbot-ml> [mattermost] <sb10q> The DES-108 8-Port Fast Ethernet Unmanaged Desktop Switch is a 8-port 10/100 Mbps
<mtrbot-ml> [mattermost] <sb10q> so yes that's not going to work
<mtrbot-ml> [mattermost] <sb10q> most things SFP/RJ45 are 1Gbps only
<mtrbot-ml> [mattermost] <hartytp> right, that explains things. I'd forgotten to check.
<rjo> SFP/RJ45 is definitely not "1 Gbps only". On the contrary: many GBICs are 10/100/1000 autonegotiating which is incompatible.
<rjo> Kasli/Sayma is 1000Base only
<mtrbot-ml> [mattermost] <hartytp> I did know that somewhere in the back of my mind, but it didn't occur to me as a potential source of this issue.
<mtrbot-ml> [mattermost] <sb10q> I haven't seen many that support the lower data rates
<mtrbot-ml> [mattermost] <sb10q> there are some, yes
<rjo> They are very common. And people hit that issue. Joe, did for example.
<mtrbot-ml> [mattermost] <pkulik> me too, when I started with artiq on kasli
<mtrbot-ml> [mattermost] <hartytp> Well, common or not, it's definitely something we've hit more than once and has wasted a non-negligible amount of staff time here
<mtrbot-ml> [mattermost] <hartytp> is it documented clearly somewhere? If not, I'll open and issue and submit a doc PR when I have time
<mtrbot-ml> [mattermost] <sb10q> what's the protocol on the FPGA side?
<mtrbot-ml> [mattermost] <sb10q> and yes it's in the manual, quoting: "For Kasli, insert a SFP/RJ45 transceiver (normally included with purchases from M-Labs and QUARTIQ) into the SFP0 port and connect it to a gigabit Ethernet port in your network. It is necessary that the port be gigabit - 10/100 ports cannot be used. If you need to interface Kasli with 10/100 network equipment, connect them through a gigabit switch."
<mtrbot-ml> [mattermost] <hartytp> Okay, thanks for pointing that out. I wonder if there is a way we can emphasise it a bit, since it is easily missed...
<mtrbot-ml> [mattermost] <hartytp> anyway, back to Sayma, @pkulik I'm not sure what else I can do to debug this right now so I'll wait to hear suggestions from you. Happy to try with different binaries/hardware if you send them to me
<mtrbot-ml> [mattermost] <pkulik> @hartytp you could try different combinations of amc+rtm, but at this point it's just guessing from my side
<mtrbot-ml> [mattermost] <hartytp> okay, I'll try that next time I can get a care package out of the lab. But, it does sound like there is an issue somewhere that needs to be addressed before Sayma is ready for deployment
<mtrbot-ml> [mattermost] <hartytp> I'll let you know how that works out. Otherwise, shall I send the pair I have to you for debugging?
Stormwind_mobile has quit [Ping timeout: 246 seconds]
<mtrbot-ml> [mattermost] <pkulik> no
<mtrbot-ml> [mattermost] <pkulik> in my experience it's not a permanent issue and usually power cycles helped
<mtrbot-ml> [mattermost] <pkulik> so it's most probable that I won't see this issue once you send us the hardware
Stormwind_mobile has joined #m-labs
<mtrbot-ml> [mattermost] <dpn> @sb10q: Silly question, but as I still don't find Nix best practices exactly intuitive, could you point me in the right direction regarding depending on your nix-scripts from a separate repository? I want to add some client-only derivations for macOS, plus some Oxford-internal dependencies, but use your derivations for all the various toolchain dependencies. One option would just be to pull in m-labs/nix-scripts as
<mtrbot-ml> [mattermost] <sb10q> You can import the artiq-fast and artiq-full channels
<mtrbot-ml> [mattermost] <sb10q> E.g. assume that the user already set those up and do import <artiq-fast> { inherit pkgs; }
<mtrbot-ml> [mattermost] <sb10q> Okay it seems the protocol is sgmii on those sfp that have 10/100
<mtrbot-ml> [mattermost] <sb10q> And it's basically a few extra auto negotiation features + repeat the bits when on 10 or 100 after auto negotiation
<mtrbot-ml> [mattermost] <sb10q> So there's no xilinx transceiver involvement, shouldn't be a big deal to implement
X-Scale` has joined #m-labs
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` is now known as X-Scale
Getorix_ has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
<mtrbot-ml> [mattermost] <dpn> Ah, right, `{ inherit pkgs; }` – I'll give it a try, thanks
<mtrbot-ml> [mattermost] <dpn> And +1 for 10/100 support being a very useful addition – one of the great things about 1000BASE-T from a user's perspective was that autonegotiation became mandatory, so things not "just working" almost feels like a violation of some implicit contract
Stormwind_mobile has quit [Ping timeout: 260 seconds]
Stormwind_mobile has joined #m-labs
<rjo> I don't think that implies that 10/100 need to be supported. Autonegotiation can also just fail.
miek has quit [Quit: miek]
miek has joined #m-labs
Getorix has joined #m-labs