NetBSD

GNU Radio
1

Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the
following message:

usb_control_msg failed: error sending control message: Input/output
error

It doesn’t seem to stop the program from running, but it’s a little
annoying.

Anyone know what it means?

Thanks,

/jordan

2

Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the
following message:

usb_control_msg failed: error sending control message: Input/output
error

I haven’t tracked this down, but I’d be interested in fixing it. I
suspect it’s either something missing in NetBSD or some OS-dependent
code that isn’t properly abstracted. I think it might be coming from
libusb, but I really don’t know - the error message is a bit lame. If
you can figure out the call chain that results in the error (perhaps
with ktrace on the simplest program that provokes it), that would be
helpful.

BTW if you run -current instead of 3.1, the USRP should do 16 MB/s
each way instead of 4 MB/s that you probably get on 3.1. The
improvements were committed sometime this summer.

3

On Sunday 03 December 2006 07:42, Jordan H. wrote:

Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the
following message:

usb_control_msg failed: error sending control message: Input/output
error

It doesn’t seem to stop the program from running, but it’s a little
annoying.

Anyone know what it means?

This was raised previously in following thread

http://www.nabble.com/USRP-on-NetBSD-p1964955.html

No fix has surfaced since then.

cheerio Berndt

4

On Sat, Dec 02, 2006 at 03:02:54PM -0800, Jordan H. wrote:

Ok, I put a few printfs in there. You’re right: the error message comes
from libusb, but the “usb_control_msg” part comes from
usrp/host/lib/usrp_prims.cc in the function write_cmd() and the args are
rType=8 val=87 index=0 len=1 and so that’s VRQ_I2C_WRITE so i’m gonna
guess that this is the usrp_eeprom_write() call that includes this code:

I doubt it’s coming from usrp_eeprom_write() since almost nobody
calls that. Depending on the daughterboard, it could be code that’s
setting up the daughterboard.

To find out for sure, set a breakpoint with gdb and get a backtrace.

Eric

5

usb_control_msg failed: error sending control message: Input/output
error

I haven’t tracked this down, but I’d be interested in fixing it. I
suspect it’s either something missing in NetBSD or some OS-dependent
code that isn’t properly abstracted. I think it might be coming from
libusb, but I really don’t know - the error message is a bit lame. If
you can figure out the call chain that results in the error (perhaps
with ktrace on the simplest program that provokes it), that would be
helpful.

Ok, I put a few printfs in there. You’re right: the error message comes
from libusb, but the “usb_control_msg” part comes from
usrp/host/lib/usrp_prims.cc in the function write_cmd() and the args are
rType=8 val=87 index=0 len=1 and so that’s VRQ_I2C_WRITE so i’m gonna
guess that this is the usrp_eeprom_write() call that includes this code:

// The simplest thing that could possibly work:
// all writes are single byte writes.
//
// We could speed this up using the page write feature,
// but we write so infrequently, why bother…

while (len-- > 0){
cmd[0] = eeprom_offset++;
cmd[1] = *p++;
bool r = usrp_i2c_write (udh, i2c_addr, cmd, sizeof (cmd));
mdelay (10); // delay 10ms worst case write time
if (!r)
return false;
}

That’s a single byte write …

Now: why this is failing and the rest of everything still works, that’s
up to someone else …

/jordan

6

Thanks, i’ll try to look into this.

–
Greg T. [email protected]

7

To find out for sure, set a breakpoint with gdb and get a backtrace.

#0 write_cmd (udh=, request=8, value=87, index=0,
bytes=0xbfbfd3cb “”, len=1) at usrp_prims.cc:450
#1 0xbb19dd07 in usrp_i2c_write (udh=0x84e6e00, i2c_addr=87,
buf=0xbfbfd3cb,
len=1) at usrp_prims.cc:960
#2 0xbb19dd44 in usrp_eeprom_read (udh=0x84e6e00, i2c_addr=87,
eeprom_offset=0, buf=0xbfbfd424, len=32) at usrp_prims.cc:1124
#3 0xbb19dddc in read_dboard_eeprom (udh=0x84e6e00,
slot_id=, buf=0xbfbfd424 “\n”) at
usrp_prims.cc:1293
#4 0xbb19de49 in usrp_read_dboard_eeprom (udh=0x84e6e00, slot_id=3,
eeprom=0xbfbfd47c) at usrp_prims.cc:1317
#5 0xbb19ba9e in usrp_basic_rx::probe_rx_slots (this=0x8698000,
verbose=false)
at usrp_basic.cc:721
#6 0xbb19c5ca in usrp_basic_rx (this=0x8698000, which_board=0,
fusb_block_size=4096, fusb_nblocks=16, fpga_filename=@0xbfbfd540,
firmware_filename=@0xbfbfd534) at usrp_basic.cc:467
#7 0xbb1a1784 in usrp_standard_rx (this=0x8698000, which_board=0,
decim_rate=64, nchan=1, mux=839922192, mode=0, fusb_block_size=4096,
fusb_nblocks=16, fpga_filename=@0xbfbfd5c0,
firmware_filename=@0xbfbfd5c4)
at usrp_standard.cc:158
#8 0xbb1a1ea7 in usrp_standard_rx::make (which_board=0, decim_rate=64,
nchan=1, mux=839922192, mode=0, fusb_block_size=4096,
fusb_nblocks=16,
fpga_filename=@0xbfbfd63c, firmware_filename=@0xbfbfd638)
at usrp_standard.cc:228
#9 0xbb15c584 in usrp1_source_base (this=0x804c740, name=@0xbfbfd6c0,
output_signature=@0xbfbfd6b0, which_board=0, decim_rate=64, nchan=1,
mux=839922192, mode=0, fusb_block_size=4096, fusb_nblocks=16,
fpga_filename=@0xbfbfd6bc, firmware_filename=@0xbfbfd6b8)
at usrp1_source_base.cc:56
#10 0xbb15cba9 in usrp1_source_c (this=0x804c740, which_board=0,
decim_rate=64, nchan=1, mux=839922192, mode=0, fusb_block_size=4096,
fusb_nblocks=16, fpga_filename=@0xbfbfd720,
firmware_filename=@0xbfbfd724)
at usrp1_source_c.cc:73
#11 0xbb15d125 in usrp1_make_source_c (which_board=0, decim_rate=64,
nchan=1,
mux=839922192, mode=0, fusb_block_size=4096, fusb_nblocks=16,
fpga_filename=@0xbfbfd7dc, firmware_filename=@0xbfbfd7d8)
at usrp1_source_c.cc:55