osmosdr: Failure to send samples. about bladerf HOT 6 CLOSED

So I am getting a very similar error except on the read side.

jsmnsr@ubuntu:~/erepo/gqrx$ osmocom_fft
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-121-gaa5e5d23

gr-osmosdr v0.1.0-7-g9dfe3a63 (0.1.1git) gnuradio v3.7.0-82-g179a2d78
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf
Using nuand LLC bladeRF #0 SN 0000000000000000 FW v1.0 FPGA v0.0
Failed to read samples: File or device I/O failure
Using Volk machine: avx_64_mmx_orc

A power cycle does NOT fix this issue.

I am using the same bladeRF and osmosdr head. I am, however, running the 3.5 kernel

Read through the CLI seems to work fine.

from bladerf.

My issue appears to be fixed in the latest commit

from bladerf.

jsmnsr - thanks for confirming! :)

biovore - based upon the date you listed, it looks like I pushed a driver change just after your last pull? Could you verify whether or not you're still seeing this as of: 465b96e

    linux_driver: Increased periperhal access timeout

    This value was previously set to 1 ms, which is currently too
    small for the required window of time (even with 3 retries) to
    receive a response from the FPGA.

If you could kindly let me know your situation, we might be able to mark this closed. If by chance you continue to see issues, could you try sprinkling some dev_err() / prinkt() calls wherever you see -ETIMEDOUT conditions or functions that time out (e.g., usb_bulk_msg()) -- this would hopefully give us another clue or two.

Thanks folks!

from bladerf.

Lastest head now just gives connection timeout error=110. Happens for TX and RX with osmocom tools.
See forums for system setup and install procedures used.. http://forums.nuand.com/forums/viewtopic.php?f=9&t=2804

I have talk to several other folks on IRC that are experiencing the same problem..

from bladerf.

I didn't haven't seem these timeouts since 465b96e. Just tested via rx'ing & tx'ing in the CLI, osmo_fft, and osmo_siggen (with a 5MHz sample rate.)

Confirmed that there's sometimes a conjugate when transmitting. This came and went when closing and restarting osmo_siggen.

FX3 Image: http://www.nuand.com/~bpadalino/bladeRF.img
FX3 Image MD5sum: 34c158b08f89f7cec614f2fc603f0e6b
FPGA: x40 image from 2012-07-16 (http://nuand.com/fpga/)

from bladerf.

Those where the magic spice needed here..
Appears to be working now..

output seems to be dropping some samples still.. But thats probably a hole other problem.

from bladerf.