[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Problem with linux 2.6.19.1
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Problem with linux 2.6.19.1 |
Date: |
Fri, 26 Jan 2007 19:26:59 -0800 |
User-agent: |
Mutt/1.5.9i |
On Fri, Jan 26, 2007 at 05:53:23PM -0800, John Clark wrote:
> Eric Blossom schrieb:
> >On Wed, Jan 24, 2007 at 05:00:13PM -0800, John Clark wrote:
> >
> >>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.
> >>
> >
> >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.
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