We’ve occasionally encountered cases, while running OpenBTS, where the
USRP code hang up and starts spitting out the following message
repeatedly:
short write xfer: 0 != 3584
In looking at fusb_linux.cc, it looks like USB writes suddenly cease to
complete. Sometimes, the host machine hangs so badly that a reboot is
needed.
I know USB on linux has always had problems. So my questions are:
- Is this problem specific to the USRP or does it have to do with
libusb?
- Is the specific to certain USB controllers?
- Has this bug been addressed in recent updates/releases to gnuradio?
Any help is appreciated. Thanks.
Harvind Samra
Kestrel Signal Processing, Inc.
On Mon, Aug 10, 2009 at 10:48:57AM -0700, Harvind Samra wrote:
I know USB on linux has always had problems. So my questions are:
- Is this problem specific to the USRP or does it have to do with
libusb?
- Is the specific to certain USB controllers?
- Has this bug been addressed in recent updates/releases to gnuradio?
Any help is appreciated. Thanks.
Harvind Samra
Kestrel Signal Processing, Inc.
Hi Harvind!
I’ve never seen this error.
Have you checked the kernel logs?
/var/log/messages is probably a good place to start.
Eric
I’ll check out the /var/log/messages the next time it happens.
— Harvind
Hi Eric,
These messages showed up repeatedly during our tests at Burning Man.
Unfortunately, when they occurred, nothing relevant actually appeared
in /var/log/messages.
Any other ideas?
— Harvind
On Sun, Sep 13, 2009 at 09:26:10AM -0700, Harvind Samra wrote:
Hi Eric,
These messages showed up repeatedly during our tests at Burning Man.
Unfortunately, when they occurred, nothing relevant actually appeared
in /var/log/messages.
Any other ideas?
No, not really. Again, I haven’t ever seen this message on any
h/w I’ve ever used.
Do you see it on more than one machine?
What kind of EHCI controllers do they have? (lspci -v)
Are you running on linux or something else?
Is there any kind of VM involved?
Outside of this, how did everything work out at Burning Man?
Eric
We’ve seen it on a couple of Dell laptops, as well as the Atom boards we
used at Burning Man. I’ll get the EHCI controller information ASAP.
We are using an inband-signaling RBF, inband_1rxhb_1tx.rbf. Could that
be the source of the problem?
All these machines were running Ubuntu 8.x or 9.x. No VM involved
whatsoever.
This was the only gnuradio/USRP hiccup with OpenBTS at Burning Man, we
had to reboot the basestation every few hours. Overall, I think the
system performed fairly well; we fixed a lot of bugs and got about 1300
registered users who made phone calls and text messages. We’re pouring
through the logs this week. We’ll be posting more details at
http://openbts.blogspot.com.
On Mon, Sep 14, 2009 at 11:03:22AM -0700, Harvind Samra wrote:
We’ve seen it on a couple of Dell laptops, as well as the Atom boards we
used at Burning Man. I’ll get the EHCI controller information ASAP.
We are using an inband-signaling RBF, inband_1rxhb_1tx.rbf. Could that
be the source of the problem?
That would be my guess. There are several known problems with it.
Did you guys ever try the version in
gnuradio/branches/developers/ets/inband?
There’s a reason I keep trying to steer you to that particular branch

All these machines were running Ubuntu 8.x or 9.x. No VM involved
whatsoever.
Good.
This was the only gnuradio/USRP hiccup with OpenBTS at Burning Man, we
had to reboot the basestation every few hours. Overall, I think the
system performed fairly well; we fixed a lot of bugs and got about 1300
registered users who made phone calls and text messages. We’re pouring
through the logs this week. We’ll be posting more details at
http://openbts.blogspot.com.
Excellent!
Eric
OK. I’ll try that branch out.