Forum: GNU Radio Problem with linux 2.6.19.1

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3045397bfbb92f92bdbed4b003ecb2c9?d=identicon&s=25 John Clark (Guest)
on 2007-01-25 02:23
(Received via mailing list)
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:
1) Has anyone else used or had problems with 2.6.19.1
2) 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 Clark
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2007-01-25 02:34
(Received via mailing list)
John Clark 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
3045397bfbb92f92bdbed4b003ecb2c9?d=identicon&s=25 John Clark (Guest)
on 2007-01-25 02:47
(Received via mailing list)
Matt Ettus 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 Clark.
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-01-25 03:58
(Received via mailing list)
On Wed, Jan 24, 2007 at 05:00:13PM -0800, John Clark 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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-01-25 04:01
(Received via mailing list)
On Wed, Jan 24, 2007 at 05:50:38PM -0800, John Clark 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
9c2ab60bcd7045e9acc36aa8074a3336?d=identicon&s=25 Philip Balister (Guest)
on 2007-01-25 14:13
(Received via mailing list)
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
3045397bfbb92f92bdbed4b003ecb2c9?d=identicon&s=25 John Clark (Guest)
on 2007-01-25 19:56
(Received via mailing list)
Philip Balister 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.
3045397bfbb92f92bdbed4b003ecb2c9?d=identicon&s=25 John Clark (Guest)
on 2007-01-27 02:49
(Received via mailing list)
Eric Blossom 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 Clark.
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-01-27 04:24
(Received via mailing list)
On Fri, Jan 26, 2007 at 05:53:23PM -0800, John Clark 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 Clark.

Thanks,
Eric
This topic is locked and can not be replied to.