Ok, I’ve been setting up a system which is based on the Linux kernel
2.6.19.1
and now have tried using the USRP device…
Well, if it worked I wouldn’t be posting… the device is seen in a
2.6.17 kernel,
however, not in the 2.6.19.1.
I see a dmesg output which indicates that the device is detected at some
level,
but the python script cacs on ‘Unable to find USRP #0’, even thought
when
I use USBVIEW it is seen and correctly identified as the USRP device.
The questions are:
- Has anyone else used or had problems with 2.6.19.1
- What configurations, and or modules need to be in, or loaded in, to
work correctly.
Given that I see dmesg output when the device is plug in, out, or even
accessed by
the python-usrp calls, it seem that most of USB stuff is there. Are
there any options
config files, etc for ‘hotplugging’ that may be getting in the way?
Thanks
John C.
John C. wrote:
but the python script cacs on ‘Unable to find USRP #0’, even thought when
there any options
config files, etc for ‘hotplugging’ that may be getting in the way?
Does it work if you run as root? Something in udev might have gotten
messed up.
Matt
Matt E. schrieb:
I see a dmesg output which indicates that the device is detected at
accessed by
the python-usrp calls, it seem that most of USB stuff is there. Are
there any options
config files, etc for ‘hotplugging’ that may be getting in the way?
Does it work if you run as root? Something in udev might have gotten
messed up.
Unlike most people… I always run as root… what me worry…
A couple of items…
I’m using the debian apt-get package. Which I just did another ‘apt-get
install’ on.
I did create a ‘usrp.rules’ file and put it in to the /etc/udev… and
when I unplug and
replug the device I see an entry under /dev/bus/usb/005/… which has
‘usrp’ as the group
name. So it looks like udev is seeing the event and creating/modifying a
node at some
level.
If I need to do a build from svn sources, I think everything is up to a
usable level
outside of ‘gnuradio/usrp’.
And of course it is working under the 2.6.17 kernel that is sort of my
absolute last fall back
kernel…
John C…
On Wed, Jan 24, 2007 at 05:00:13PM -0800, John C. wrote:
but the python script cacs on ‘Unable to find USRP #0’, even thought when
I use USBVIEW it is seen and correctly identified as the USRP device.
Sounds like a problem in libusb and/or a changed interface to usbfs.
Eric
On Wed, Jan 24, 2007 at 05:50:38PM -0800, John C. wrote:
Unlike most people… I always run as root… what me worry…
I guess that means you’re not a subscriber to the “principle of least
privilege”.
Kids, don’t try this at home 
Eric
I’ve run a USRP connected to my EFIKA (powerpc) board. The kernel is
based off 2.7.19-rc6.
I realize this kernel may be different than a more “mainstream”
kernel, but I wouldn’t expect any dramatic differences in interfaces.
Maybe there is a kernel config change?
Philip
Philip B. schrieb:
I’ve run a USRP connected to my EFIKA (powerpc) board. The kernel is
based off 2.7.19-rc6.
I realize this kernel may be different than a more “mainstream”
kernel, but I wouldn’t expect any dramatic differences in interfaces.
Maybe there is a kernel config change?
I’ve tried it with a 2.6.18.1 kernel, and things work. So now I’m
looking at
the config setup for both kernels… which should be ‘identical’ in this
regard.
I also got libusb-1.1.2 and so I have a chunk of code that I can easily
step through.
What the symptom seems to be is that when the libusb code which ‘opens’
the device
having found it via /dev/bus/usb/XXX, I see a disconnect and then a
reconnect with a new
instance number from the usb kernel code.
I don’t know what that ‘means’, being unfamiliar with the details of the
usb code. My natural
habitat in the kernel is in the networking and old ‘scsi’ stack and
drivers… as opposed to making
every thing look like a scsi device…
If its a simple config option that is required that seems to have
escapted notice, I’ll note that.
If there is some problem with the 19.1 kernel I’ll try to characterize
what conditions lead
to the problem…
John.
Eric B. schrieb:
I see a dmesg output which indicates that the device is detected at some
level,
but the python script cacs on ‘Unable to find USRP #0’, even thought when
I use USBVIEW it is seen and correctly identified as the USRP device.
Sounds like a problem in libusb and/or a changed interface to usbfs.
While I don’t have an exact explanation, when I disable the USB ‘USB
selective suspend/resume and wakeup’ option of
the kernel USB driver configuration, I’m able to use the USRP in the
2.6.19.1 kernel. I checked that against
the setup in the 2.6.18.1 kernel, and although this option is enabled in
the 2.6.18.1 setup, it does
not seem to have the same failing result.
I checkd it by turning the option off… compling, installing, booting,
running the GNURadio program we developed
without failure, then turning the option back on… testing, seeing
failure… then turning the option back off and seen correct
operation…
So, I think there is some problem here… but I can’t identify further
exactly what…
John C…
On Fri, Jan 26, 2007 at 05:53:23PM -0800, John C. wrote:
selective suspend/resume and wakeup’ option of
the kernel USB driver configuration, I’m able to use the USRP in the
2.6.19.1 kernel. I checked that against
the setup in the 2.6.18.1 kernel, and although this option is enabled in
the 2.6.18.1 setup, it does
not seem to have the same failing result.
Thanks John, for the great troubleshooting! There’s been all kinds of
traffic on the linux-usb-devel list about suspend/resume. It appears
that either it’s not all sorted out, or that our firmware doesn’t
behave in a 100% compliant way with the new world order.
I checkd it by turning the option off… compling, installing, booting,
running the GNURadio program we developed
without failure, then turning the option back on… testing, seeing
failure… then turning the option back off and seen correct
operation…
So, I think there is some problem here… but I can’t identify further
exactly what…
John C…
Thanks,
Eric