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
ylamarre has joined #m-labs
cr1901_modern has joined #m-labs
balrog has quit [Remote host closed the connection]
<whitequark> rjo: " Using a VM here at NIST is subject to the same rules as bare metal" wow, that's some ridiculous bureaucracy
balrog has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
fengling has joined #m-labs
_whitelogger_ has joined #m-labs
ylamarre has quit [Quit: ylamarre]
fengling has quit [Ping timeout: 252 seconds]
fengling has joined #m-labs
FabM has joined #m-labs
fengling has quit [Ping timeout: 246 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 248 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
sb0 has joined #m-labs
key2 has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
fengling has joined #m-labs
tija has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
<cr1901_modern> ysionneau: THe torrent is 400 GB, to answer your q *grabs popcorn*
<ysionneau> yep I canceled the download, I don't have this disk space on my laptop :)
<whitequark> Filesystem Size Used Avail Use% Mounted on
<whitequark> /dev/mapper/xxxxxxxxxxx 28T 21T 6.9T 75% /data
<whitequark> any of you want that torrent
<cr1901_modern> I'd love it, but I don't have the space for it (unless you had something else in mind by asking that).
<ysionneau> whitequark: well, I don't have the time to dig in the content of those files, it was just for the "fun" of being part of the sharing (seeding)
<ysionneau> thx for the offer
<cr1901_modern> Everything I could probably find by grepping/html parsing has likely been done better by others already.
fengling has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
fengling has joined #m-labs
olofk has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
_whitelogger_ has quit [Ping timeout: 252 seconds]
_whitelogger_ has joined #m-labs
fengling has joined #m-labs
chiggs has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
bhamilton has joined #m-labs
fengling has joined #m-labs
sb0_ has joined #m-labs
sb0 has quit [Ping timeout: 256 seconds]
fengling has quit [Ping timeout: 252 seconds]
<olofk> Have been playing around a bit with liteSATA and come across some issues that prevents simulations to be run under Icarus
<olofk> Hi _florent_ :)
<_florent_> hi olofk
<olofk> Don't know if you have had this discussion before, but I finally figured out what the issue is
<_florent_> ah interesting
<olofk> _florent_: I actually got the phy_datapath_tb running now with some code changes in litesata
<olofk> So it's possible to work around, bit in some cases it would become damn ugly, so I would prefer this to be fixed in migen
<olofk> ok, so here's the problem
<_florent_> yes, it's better to fix in migen
<_florent_> it becomes very difficult to have a workaround when you connect multiple cores togethers
<olofk> For example in datapath.py there's a mux choosing between ctrl and align_inserter to send to tx
<_florent_> together
<olofk> Inside align_inserter there's another mux
<olofk> These gets converted in to a process each
<olofk> lets say process1 is in align_converter and process2 is the external mux
<olofk> process1 sets the stb, data and charisk signals. This triggers process2. process2 in turn sets the ack, which triggers process1
<olofk> like forever :)
<olofk> So, my workaround for this case was to move ack assignment out of the If() function, so that it becomes a simple assign instead. This breaks the loop, but it's harder to do in other places.
<olofk> Like the SATAArbiter for example. That would require a rewrite
<olofk> So my idea is to somehow make migen move the contradirectional signals out of the process, or have two process. One for each direction
<olofk> Maybe this is what the forked migen already does. I tried to understand the changes, but I couldn't really grasp it
<olofk> I'm surprised that this hasn't turned up in other places. From what I understand, it would just need two combinatorial muxes (with bidirectional signals) after each other
<olofk> ..to trigger the problem, I mean
<_florent_> I really need to have a closer look a that, maybe you have a possible solution with what you are suggesting
<olofk> _florent_: Yeah, I can send over some example snippets when I have time
<olofk> What I did to debug this was to hack verilog.py to print out the current process it's running, to see where the loops are
<_florent_> yes it would be interesting to have snippets
<olofk> Don't ask how long I've spent following wires in the generated verilog :)
<olofk> got to run now. bbl
<_florent_> what would also be interesting is a minimal example hangs the simulation
<_florent_> ok bye, thanks for the feedback
bhamilton has quit [Read error: Connection reset by peer]
bhamilton1 has joined #m-labs
bhamilton1 has quit [Remote host closed the connection]
balrog has joined #m-labs
balrog has quit [Changing host]
balrog has quit [Quit: Bye]
balrog has joined #m-labs
<ysionneau> rjo: is the following shell line supposed to be able to reproduce the lda/hid issue?
<ysionneau> while [ 1 ]; do ARTIQ_LDA_PRODUCT="LDA-102" ARTIQ_LDA_SERIAL="SN:03461" python3.4 ./lda.py; done
<ysionneau> (in artiq/test)
<ysionneau> so far I get sometimes "libusbx: error [handle_events] hotplug pipe read error -1 != 16" but all tests turn out "OK" (environment is linux-64, Ubuntu based distro)
* ysionneau is using self-compiled hidapi-libusb git sha1 d17db57b9
<ysionneau> ah I wasn't up to date, let's try again with latest artiq
<ysionneau> hum, seems to work fine also on HEAD
<ysionneau> hardware_testbench < nice!
ylamarre has joined #m-labs
tija has quit []
ohama has quit [Ping timeout: 256 seconds]
ohama has joined #m-labs
<rjo> whitequark: treating VMs and their hosts or bare metal the same is completely valid. from a risk and vulnerability standpoint there is no real difference.
<rjo> ysionneau: the lda test passes about half the time. the other half the pattern is as described.
<rjo> what is your hidapi version?
<rjo> it might also be a VM-related issue.. usb through windows and virtualbox-host is not the same as native.
<rjo> there is also a libusbx: error [handle_events] hotplug pipe read error -1 != 16 from time to time.
<rjo> timeout for the control message?
<ysionneau> rjo: I cannot reproduce on my linux-64 but on my linux-32 (debian jessie) I can reproduce the same hid error
<rjo> ah. you get that error on native linux? then the vm might just exacerbate the bug.
<ysionneau> (both are native linux)
<ysionneau> linux-64 is my Elementary OS laptop, linux-32 is my Jessie desktop
<rjo> this is on a 64-bit linux vm.
<rjo> debian user: good boy! ;)
<ysionneau> ahah, yes I kind of like Debian
<rjo> hidapi version on the laptop?
<ysionneau> but Elementary OS is "nice" on the macbook (yes ... macbook ...)
<ysionneau> on the laptop (where I cannot reproduce) : d17db57b9
<rjo> from git?
<ysionneau> on the desktop where I reproduce : same sha-1
<ysionneau> yes
<rjo> ah.
<ysionneau> weird
<ysionneau> and on the desktop, I only partially reproduce, I get the HidError : -1: None, but not the queuing mixup
<ysionneau> happens at random i (loop index)
<ysionneau> but does not propagate to the following indexes
<ysionneau> 19:14 < rjo> ysionneau: the lda test passes about half the time. the other half the pattern is as described. < ok, I reproduce with a very lower rate, errors are very rare on my desktop :/
<rjo> i would focus on the initial error. do you know whether there are fast timeouts in the controll mesage stuff in hidapi that could trigger?
<ysionneau> I have to do while [ 1 ] to run lots of tests
<rjo> looks like the libusb call times out
<rjo> whitequark: re VM security: you would not want all the info that NIST has on you on their VMs to become compromised and leak out, would you? ;)
<ysionneau> weird that hid_error() returns None , should return a string describing the error
<ysionneau> knowing that hid_write returned -1 which the API describes as "an error"
<ysionneau> rjo: which device are you testing the lda driver on?
<ysionneau> I'm using LDA-102
<ysionneau> 19:24 < rjo> looks like the libusb call times out < highly possible, passing tests take 0.5 s, failing take 1.5 s
<ysionneau> let's try to analyze with wireshark
<olofk> _florent_: You there?
<olofk> _florent_: You got mail instead. Too much text :)
<ysionneau> rjo: I indeed see some weird stuff happening in wireshark when the bug happens, instead of 1 URB_CONTROL_OUT (type submit) + 1 URB_CONTROL_OUT (type complete) (for set_attenuation) followed by 1 URB submit + 1 URB complete (get_attenuation) then followed by 2 URB_INTERRUPT_IN, when it bugs I get : Submit/complete + submit, no urb complete (yet), then the 2 URB_INTERRUPT_IN, then the USB_CONTROL_OUT (type complete) (being late ?), then 1 ...
<ysionneau> ... message only happening in the bug situation : 2x ( USBHUB CLEAR_TT_BUFFER request followed by USB CONTROL complete)
<ysionneau> hope I'm clear :p
<ysionneau> I can send the pcapng if needed
<ysionneau> rjo: I suspect the device can sometimes respond more slowly (weird that this differs between my two machines...), maybe increasing the timeout for the hid_read_timeout() can help?
<ysionneau> hum ... it's not just a bad timing it seems
<ysionneau> when the URB CONTROL out happens "later", its content is different, instead of having URB Status: success (0), you get URB Status: No such file or directory (-ENOENT) (-2)
<ysionneau> "specified interface or endpoint does not exist or is not enabled"
<ysionneau> weird...
<ysionneau> urb->status
<ysionneau> in this case -2 (ENOENT) means : URB was synchronously unlinked by usb_unlink_urb
<ysionneau> weird, the doc says it's for isochronous urbs ... I don't think I'm doing any isochronous stuff :o
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 244 seconds]
<ysionneau> rjo: ok, even 3000 ms of timeout does not get rid of the bug.
_whitelogger_ has joined #m-labs
<rjo> ah. that IOError if the device product is wrong or not found could use a string with it.
<rjo> i'll grab lunch. see you later.
nicksydney_ has quit [Ping timeout: 244 seconds]
<ysionneau> ah, yes
<ysionneau> good catch
<ysionneau> bon appétit!
<rjo> merci
nicksydney has joined #m-labs
<GitHub81> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vql3O
<GitHub81> misoc/master 0545d49 Florent Kermarrec: liteeth/core: add with_icmp parameter
<olofk> Hmm... this was a bit tricker than I had thought. Looks like verilog.py doesn't know about the direction. Does record.py strip away this info?
ylamarre has quit [Quit: ylamarre]
<rjo> ysionneau: daniel was the one who signed of on the lda driver. i'll ping him whether he want to talk to vaunix or wether the work around is ok.
<ysionneau> all right, thanks!
sb0_ has quit [Read error: Connection reset by peer]
<olofk> _florent_: Started looking at the device mode phy a bit again. Have you found any info on how long time that the host and device should send align patterns?
sb0 has joined #m-labs
<sb0> urgh, the gps chip in my tablet is using this proprietary protocol
<sb0> when I send it stuff from the strace log, that piece of shit is answering
jaeckel has quit [Ping timeout: 252 seconds]
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
jaeckel has joined #m-labs
antgreen has joined #m-labs
<_florent_> olofk: you can probably use these numbers: https://github.com/m-labs/misoc/blob/master/misoclib/mem/litesata/phy/ctrl.py#L18
jaeckel has quit [Ping timeout: 264 seconds]
jaeckel has joined #m-labs
sb0 has quit [Remote host closed the connection]