Forum: GNU Radio X300 PCIe issues

E16be4811324adf8f26be26d77e9d29d?d=identicon&s=25 Robert McGwier (Guest)
on 2014-04-25 23:39
(Received via mailing list)
I have my new x300's.  The NI ExpressCard-8360B is recognized by my
Intel
5, Lenovo, 64 bit machine running U 14.04 LTS.

I naively assumed that given the way things had gone before, that this
would be a low impact out of the box experience.  uhd_find_devices finds
nothing.

So I go and dig and find I need to do some things first.

http://code.ettus.com/redmine/ettus/projects/uhd/w...

The installer:


sudo niusrprio-installer/INSTALL

appears to work, but something is missing still.

Unfortunately,  the enabling and disabling usage lines don't work
because
some module the device is looking for has NOT been added to the kernel,
much less done with automated update for the next kernel.

Anyone who has faced and solved this issue, and gotten their PCIe
interface
to the x300 to work, please email, because I cannot afford to waste the
weekend looking at TV.

Bob
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2014-04-26 00:29
(Received via mailing list)
You are using ubuntu 14.4 which has  a new kernel.   It will take us a
little while to get our kernel module working with it.  In the mean
time,
going to an older kernel or distribution will fix it.   This does not
affect ethernet connections.

Matt
E16be4811324adf8f26be26d77e9d29d?d=identicon&s=25 Robert McGwier (Guest)
on 2014-04-26 18:03
(Received via mailing list)
Okay, I thought that was it.  I will back off to 13.XX LTS for now.

Bob
E16be4811324adf8f26be26d77e9d29d?d=identicon&s=25 Robert McGwier (Guest)
on 2014-04-26 19:31
(Received via mailing list)
Tim and I are going to swap back to 12.04.4 LTS.  I suggest that some
note
to the installation for x3x0 say which versions of Ubuntu, kernels, etc.
are supported currently.

Thanks for your time.

Bob
E16be4811324adf8f26be26d77e9d29d?d=identicon&s=25 Robert McGwier (Guest)
on 2014-04-27 20:47
(Received via mailing list)
Backing off to Ubuntu 12.04.4 LTS was successful in getting the PCIe
Express interface to build, dkms the kernel module, start and
uhd_find_device sees the USRP x300.

Now for the fun part.... using it.

Finally:

To all those entertaining PCIe interfacing,  do not install a later
version
of kernel or distro than is KNOWN to support the interface.  PCIe is
most
decidely NOT USB or GigE.  Ettus would not be using a proprietary
interface
from NI with known working support for various kernels if it were not
necessary.  Having done multiple projects at work with PCIe,  you use it
when it is necessary and NEVER when it isn't.  My application for the
x3x0
series requires it.  I find all the pieces of the needed documentation
to
make it all work NOT in one place.  I will give a short summary today
after
I get my first app going using the device.

Thanks,
Bob
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2014-04-27 21:55
(Received via mailing list)
On 04/27/2014 02:45 PM, Robert McGwier wrote:
>  PCIe is most decidely NOT USB or GigE.  Ettus would not be using a
>
>
I'll chime in as an occasional kernel and driver developer.  Developing
code, like drivers or kernel extensions, that runs inside the kernel is
   a *royal pain in the posterior* in Linux.  While the "top side" API
is very stable so that applications hardly *ever* experience API changes
   that require on-going tedious maintenance, the same cannot be said of
code that runs in the kernel. Quite the contrary.  Linus and friends
   *routinely and regularly* change critical APIs within the kernel,
sometimes even across minor version revs of the same codebase.  This
makes
   maintaining drivers and other kernel code a complete and utter
nightmare, and which is why often drivers are only guaranteed to work
   for specific kernel versions or kernel version series.  It's serious
challenge, and it's not a road that should be gone down lightly....




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2014-04-27 23:33
(Received via mailing list)
> While the "top side" API is
> very stable so that applications hardly *ever* experience API changes
>   that require on-going tedious maintenance, the same cannot be said of code
> that runs in the kernel. Quite the contrary.  Linus and friends
>   *routinely and regularly* change critical APIs within the kernel,
> sometimes even across minor version revs of the same codebase.

Come on, it's not _that_ bad ...

Kernel API are stable inside the maintenance release, so they can only
change like every 2 month at most.

And when they change, finding the relevant commit is pretty easy with
git and it will show exactly what need to be changed in your driver
(because that commit fixed every other driver in-tree for the same
change). And searching LKML will also give all the gory details. It's
like half a day or one day of work at the most.

So 1 day of code maintenance every 2 month to keep your codebase
current is not what I'd call a nightmare.
And if you want to avoid even that, just get your module merged
upstream, it will be adapted for you free of charge when APIs change.

And wrt to maintaining the same code building for several kernel,
that's just the wrong approach. Just maintain different version in
different branches. When the code is well written, the driver specific
part will be decoupled enough from the kernel api part that there will
hardly be any conflicts. And when your driver "core function" doesn't
change (and for the NI driver, it seems it hasn't changed it's
functionality for a while AFAICT, just added new kernel support, but I
could be wrong on that), then it's even easier to just release a new
code for each new kernel.

For only a few revisions appart, you might be ok with #ifdef, but if
you're trying to go back to ancient times, like the NI module which
seems to support 2.6.0 (that's  11 years ago !!!!), yeah there is
going to be some serious changes ...

Cheers,

   Sylvain


PS: and yeah, for 2 years or so, I maintained an in-house PCIe driver
for a FPGA board, so I did experience that.
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2014-04-27 23:49
(Received via mailing list)
On 04/27/2014 05:32 PM, Sylvain Munaut wrote:
>
>
> For only a few revisions appart, you might be ok with #ifdef, but if
> for a FPGA board, so I did experience that.
>
So, would we accept an applications-layer API that changed roughly every
two months?  I would argue, no, we wouldn't.  But
   people developing in kernel land seem to accept it as some kind of
necessary gospel.   I reject that notion.

Just because kernel-land is where "all the kewl kids play" is not a good
reason to break things on a regular basis.

Anyway, this thread is now going fairly far afield....


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2014-04-28 00:27
(Received via mailing list)
Hi,


> So, would we accept an applications-layer API that changed roughly every two
> months?  I would argue, no, we wouldn't.  But
>   people developing in kernel land seem to accept it as some kind of
> necessary gospel.

For the kernel, the "application layer API" is the user space
interface and that's _very_ stable.

The module API is more akin to something internal. AFAIK The general
design and philosophy is that the goal of every kernel module should
be to get merged upstream. Long term maintenance of an out-of-tree
driver is _not_ a supported / recommended use case, so they just don't
care about it. It might work, but if you go that way, you have to deal
with it.


> I reject that notion.

Feel free to fork the kernel and do all the same enhancement and new
stuff that comes with each kernel version with no changes whatsoever
to the internal APIs and without any additional work.

Maintaining stuff stable is kind of the model they had with the
2.0/2.2/2.4 series, where the large changes were only in the
inter-series. But for 2.6 (and 3.0 which is really just 2.6
continuation, nothing major changed between 2.6.39 and 3.0, Linus just
felt '40' was too high), they changed the development model to be more
fluid and allow faster evolution and AFAIH, most people are pleased
with the results, both kernel dev that can get their stuff merged
faster and more predictably and the users that get new stuff earlier.


> Just because kernel-land is where "all the kewl kids play" is not a good reason
to break things on a regular basis.

They don't break it for the pleasure of breaking it. They break it
when it technically makes sense to do so.


Cheers,

   Sylvain
E16be4811324adf8f26be26d77e9d29d?d=identicon&s=25 Robert McGwier (Guest)
on 2014-04-28 13:27
(Received via mailing list)
It needed to be said,  but my only goal is to

ACCEPT AND LOVE 10GigE until and unless you demand the low latency
afforded
by the PCIe interface.  The things I am working on demand that we meet
the
tight timing requirements of open specification waveforms.  PCIe was
required.  The x3x0 series are major accomplishments for Ettus and
should
they just get past the major changes that 14.04 LTS and then BE EXPLICIT
about which kernels they will support, etc. They should be good until
the
next LTS comes out.

Bob
00829417ed328095434afb665145b0c5?d=identicon&s=25 Lapointe, Benjamin - 1008 - MITLL (Guest)
on 2014-04-28 16:40
(Received via mailing list)
Attachment: smime.p7s (5 KB)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
3e80620fe492d92901b7a29b28655d63?d=identicon&s=25 Ben Hilburn (Guest)
on 2014-04-28 19:09
(Received via mailing list)
Hi all -

Just to clarify, it isn't the *version of OS* that matters, but rather
the *version
of the kernel provided by the OS*, that matters.

At the top of our instructions for installing the USRP RIO kernel
module,
it lists the maximum kernel version we currently support:

"*NOTE: The latest supported kernel version is 3.12.X.*"

http://code.ettus.com/redmine/ettus/projects/uhd/w...


I'll make that text bigger so that it is easier to see. We apologize for
any confusion regarding this.

The driver team is working on kernel support for kernels 3.13 and 3.14.
As
soon as it is available, we will update our instructions and posted
software appropriately.

Cheers,
Ben
E16be4811324adf8f26be26d77e9d29d?d=identicon&s=25 Robert McGwier (Guest)
on 2014-04-29 03:54
(Received via mailing list)
I suspect that 10GigE works just fine.  It is PCIe and PCIe express that
will have the "unique to a kernel release" issues.

Again, as I said before, if you have no idea why you would need PCIe,
DON'T
DO IT.  Use 10 GigE.


On Mon, Apr 28, 2014 at 10:39 AM, Lapointe, Benjamin - 1008 - MITLL <
Bc7e5a4798b9bb4e311a26b41dce2fbc?d=identicon&s=25 Ian Buckley (Guest)
on 2014-04-29 11:40
(Received via mailing list)
Ben,
That card is very mainstream and uses an Intel driver so I'd expect good
support from the get go on 14.04.
-Ian
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.