I just updated github to match the current shipping kernel (from last
week) See the e100-3.0-pm-2-bugfixes branch. In particular, I added some
code to do some range checking on the values passed to the ioctl in:
Ah thanks. I just built a new kernel using that patch (i.e. from the
e100-3.0-pm-2-bugfixes branch). I hope that was the right one, the
usrp_e driver looks ok but is only at version 0.2 as opposed to the
one from the e100-3.0-pm-2-fixes-from-review branch which is at
version 0.3. I still get a segfault / kernel NULL pointer dereference
as soon as I modprobe usrp_e though.
cheers
Stefan O.
Communication and Distributed Systems
Institute of Computer Science and Applied Mathematics
University of Bern
Just curious, have you had a chance to look at this?
Also, in the meantime I tried using your kernel tree
(e100-3.0-pm-2-fixes-from-review) which seems to have a newer version
of the usrp_e driver, built with the kernel configuration that I took
from a working USRP image. However, when trying to modprobe the usrp-e
module, I get:
This seems to happen in usrp_e.c on line 854: atomic_set(&p->mapped,
0); - I assume that, for some reason, “p” isn’t properly initialized.
You wouldn’t by any chance have some idea about what might be wrong
there?
Furthermore, sorry for the nagging
cheers
Stefan O.
Communication and Distributed Systems
Institute of Computer Science and Applied Mathematics
University of Bern
Ah thanks. I just built a new kernel using that patch (i.e. from the
e100-3.0-pm-2-bugfixes branch). I hope that was the right one, the
usrp_e driver looks ok but is only at version 0.2 as opposed to the
one from the e100-3.0-pm-2-fixes-from-review branch which is at
version 0.3. I still get a segfault / kernel NULL pointer dereference
as soon as I modprobe usrp_e though.
Sorry about that, I had some sort of mess and tried the wrong kernel
again. With the e100-3.0-pm-2-bugfixes branch it seems to basically
work (i.e. I can load the module and uhd_find_devices shows the E100)
but uhd_usrp_probe aborts:
uhd_usrp_probe
linux; GNU C++ version 4.6.1; Boost_104800; UHD_003.003.002-unknown
– Opening device node /dev/usrp_e0…
I will try again with the latest development version of uhd and report
back.
cheers & sorry for the noise
Stefan O.
Communication and Distributed Systems
Institute of Computer Science and Applied Mathematics
University of Bern
Sorry about that, I had some sort of mess and tried the wrong kernel
cheers & sorry for the noise
OK, so instead of crashing, it just aborts. This suggests my check on
ioctl arguments is working. We need to poke around uhd and see what is
passing to the kernel.
Yup, seems your changes helped! Just FYI, the situation doesn’t change
regardless of whether I use uhd 3.3.2, 3.4.0, git master or git next.
I’ll try to have a closer look at the ioctls (I’m not particularly
good / experienced at this) to see whether I can find anything that’s
different on my installation when compared to the shipped microSD
cards. In particular I think it would be interesting to try my kernel
with your cards to see what happens, i.e. to figure out whether the
problem is on the kernel side or in the user-space tools.
I’ll report back when I find something new.
cheers
Stefan O.
Communication and Distributed Systems
Institute of Computer Science and Applied Mathematics
University of Bern
again. With the e100-3.0-pm-2-bugfixes branch it seems to basically
cheers & sorry for the noise
OK, so instead of crashing, it just aborts. This suggests my check on
ioctl arguments is working. We need to poke around uhd and see what is
passing to the kernel.
