X300 PCIe issues

GNU Radio
1

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/wiki/NI_USRP_RIO_Linux

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

2

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

3

Okay, I thought that was it. I will back off to 13.XX LTS for now.

Bob

4

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

5

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

6

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.

7

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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

8

On 04/27/2014 05:32 PM, Sylvain M. 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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

9

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

10

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

11

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

12

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/wiki/NI_USRP_RIO_Linux

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

13

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 <

14

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