# X300 PCIe issues

**URL:** <https://www.ruby-forum.com/t/x300-pcie-issues/240697>\
**Category:** GNU Radio\
**Created:** [April 25, 2014, 11:39pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697 "2014-04-25T23:39:01Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\
**Post date:** [April 25, 2014, 11:39pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/1 "2014-04-25T23:39:01Z")

</div>

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](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

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 26, 2014, 12:29am UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/2 "2014-04-26T00:29:08Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 26, 2014, 6:03pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/3 "2014-04-26T18:03:06Z")

</div>

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

Bob

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 26, 2014, 7:31pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/4 "2014-04-26T19:31:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 27, 2014, 8:47pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/5 "2014-04-27T20:47:21Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 27, 2014, 11:33pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/6 "2014-04-27T23:33:31Z")

</div>

> 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.

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 27, 2014, 9:55pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/7 "2014-04-27T21:55:22Z")

</div>

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

> **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org)**
>
> Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami.

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 27, 2014, 11:49pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/8 "2014-04-27T23:49:30Z")

</div>

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

> **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org)**
>
> Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami.

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 28, 2014, 12:27am UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/9 "2014-04-28T00:27:56Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 28, 2014, 4:40pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/10 "2014-04-28T16:40:37Z")

</div>

* * *

Discuss-gnuradio mailing list  
removed\_email\_address@domain.invalid  
[https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 28, 2014, 1:27pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/11 "2014-04-28T13:27:43Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 28, 2014, 7:09pm UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/12 "2014-04-28T19:09:42Z")

</div>

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](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

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 29, 2014, 3:54am UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/13 "2014-04-29T03:54:22Z")

</div>

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 \<

---

<div class="post-metadata">

**Author:** ![Robert\_McGwier](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@Robert\_McGwier](https://www.ruby-forum.com/u/Robert_McGwier)\
**Post date:** [April 29, 2014, 11:40am UTC](https://www.ruby-forum.com/t/x300-pcie-issues/240697/14 "2014-04-29T11:40:13Z")

</div>

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