I have installed dpdk 18.08 on a Centos 7 machine, which has the kernel source installed.
I built dpdk using:
$ make -j T=x86_64-native-linuxapp-gcc install
<snip>
Build complete [x86_64-native-linuxapp-gcc]
Installation cannot run with T defined and DESTDIR undefined
I want to interface dpdk to a HP NIC that uses the Intel X722 chipset. So I then run:
$ /opt/dpdk/dpdk-18.08/usertools/dpdk-devbind.py -b igb_uio `lspci | grep X722 | awk '{print $1}'`
Error - no supported modules(DPDK driver) are loaded
I think that this error means that the DPDK kernel module is not installed.
How can I fix this?
Based on the comment interaction, the reason for missing Kernel Module. Installing igb_uio or vfio-pci has solved the problem.
Related
I'm using an m1 pro macbook pro.
Up until now, I used intel macbook.
My program is written in c/c++ and the target is ubuntu x86_64.
I tried running ubuntu x86 docker (qemu) and it's super slow - to the point it's unusable.
I have linux ubuntu (arm) installed using parallels and would like to compile for x86 target instead of arm.
How do I do it?
On Ubuntu, I would suggest an apt install gcc-x86-64-linux-gnu g++-x86-64-linux-gnu, and then invoking the installed compiler with the x86-64-linux-gnu prefix (for gcc, x86-64-linux-gnu-gcc) to create x86_64 binaries.
Do note that if you target x86_64 you won't be able to run the programs you build natively, but you should be able to package the binaries created for execution on an x86_64 machine.
Install docker-desktop on your mac and run this docker container with the command:
docker container run --platform=linux/amd64 -it -p 6080:6080 -e WIDTH=1920 -e HEIGHT=1080 yoas1/xubuntu-desktop:1.0
Don't forget to create volume to the code directory.
In your browser go to: http://localhost:6080/vnc.html to access the xubuntu desktop
Image on Dockerhub
As stated in the title, I'm trying to use QEMU and GDB to debug xv6 as part of an OS project.
I'm able to make qemu and make qemu-nox perfectly, but when I run
make qemu-gdb or make qemu-nox-gdb the command hangs and the output is like:
qemu-system-i386 -nographic -drive file=fs.img,index=1,media=disk,format=raw -drive file=xv6.img,index=0,media=disk,format=raw -smp 1 -m 512 -S -gdb tcp::25502
with no prompt showing up.
When I try connect using GDB the result is:
localhost:25502: cannot resolve name: nodename nor servname provided, or not known
Anyone able to troubleshoot? Thanks!
Info:
Development OS: Mac OS X Mojave
QEMU: qemu-system-i386 (installed using Homebrew)
GDB: 8.3 (installed using Homebrew)
Cross-compile toolchain: compiled from source code
I am trying to cross compile(for ARM64) DPDK from source as instructed here:
https://doc.dpdk.org/guides/linux_gsg/cross_build_dpdk_for_arm64.html
But when I run make, I see this:
$ make config T=arm64_armv8_linux_gcc
make: Nothing to be done for 'config'.
I have the checkout the main branch, and wondering if compiling through "Makefile" is not supported any more and MESON build system has replaced it ?
I am on top commit of master branch:
https://github.com/DPDK/dpdk/commit/9d620630ea30386d7fc2ff192656a9051b6dc6b5
DPDK version:
21.02.0-rc0
Toolchain version is:
aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (Linaro GCC 7.3-2018.05) 7.3.1 20180425 [linaro- 7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701]
Host machine details are:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.7 LTS
Release: 16.04
Codename: xenial
DPDK has removed the support for Makefile from 20.11. One has to rely on meson-ninja for the same.
Please use the below as guide for your cross build
meson arm64-build --cross-file config/arm/arm64_armv8_linux_gcc
ninja -C arm64-build
DPDK LTS 19.11.6 still uses Makefile.
After I installed gdbserver on my remote machine (Ubuntu 16.04.4 LTS), I tested the following c++ code by making a "cross-platform console application (linux)" project in Visual Studio 2017:
#include <cstdio>
int main()
{
printf("hello from testLinuxDebug!\n");
return 0;
}
I added the connection information (ip address, id, password) of my Ubuntu machine to connection manager and selected "gdbserver" for debugging mode.
Then I started debugging and got the following message:
Unable to start debugging. Unexpected GDB output from command
"-interpreter-exec console "target remote localhost63361"". Remote
connection closed.
Message after starting to debugging (Image captured from VS2017)
By the way, I got the following message from the Linux Console Window of debug menu of Visual Studio 2017:
Process /home/.../projects/testLinuxDebug/bin/x64/Debug/testLinuxDebug.out
created; pid = 29277 Listening on port 4444 Remote debugging from host
127.0.0.1 /build/gdb-9un5Xp/gdb-7.11.1/gdb/gdbserver/regcache.c:264: A problem > internal to GDBserver has been detected. Unknown register ymm0h requested
Message from Linux Console Window (Image captured from VS2017)
Could anybody help me with this problem?
I was having this exact same problem on my Ubuntu 16.04 machine.
I went through the source code on gdbserver, and it appears to be a problem with a processor register (ymm0h) which is only available to i386 processors.
The thing is, I don't know how to fix gdbserver to not use this register in particular, but you can solve the error by upgrading your gdb & gdbserver to version 8.3 on the Ubuntu machine. If my guess is correct, version 8.1 was the one that fixed this issue, but by default, Ubuntu 16.04 has version 7.11.1 for both gdb & gdbserver.
You can run these commands on the linux machine to do that:
wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz"
tar xzf gdb-8.3.tar.gz
cd gdb-8.3
./configure --prefix=/usr --with-system-readline
make
sudo make install
You may need to install some extra packages in order to compile the gdb:
sudo apt-get install libreadline6-dev texinfo
If you still have problems trying to install gdb, try this example from Linux from Scratch.
Good luck!
I encountered the same problem as you, although for me the issue was on Microsoft's Visual Studio Online platform - I couldn't use pwntools' gdb.debug/gdb.attach functionality (that relies on gdbserver) due to this very same error in VSOnline's docker environment.
Leaving this answer here for people who might encounter the same issues that I have.
The issue and the steps are pretty similar to what Canella described - the root of the problem is indeed the old GDB version in the environment (7.12 at the time of writing).
I've compiled my GDB with python3 bindings, and you might want to do that too if you're planning to use GEF or similar GDB extensions.
Here's how to do that in your VSOnline environment's terminal:
# I needed to get rid of the apt-provided gdb for it to work properly
sudo apt remove gdb
# VSOnline has a weird way of handling python versions
# you're better off installing python3 from apt, if it's not installed yet
sudo apt update
sudo apt install libreadline6-dev texinfo python3 python3-dev
wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz"
tar xzf gdb-8.3.tar.gz
cd gdb-8.3
mkdir build && cd build
../configure --prefix=/usr --with-system-readline --with-python=/usr/bin/python3
make
sudo make install
I have virtual machine "CentOS Linux release 7.1.1503 (Core)" , where I can not find cgroups, "/sys/fs/cgroup" directory has nothing in it. I have also installed cgrouplib pakages but still there is nothing.
How I can get cgroups , would be very helpful you anyone can provide the details.
Thanks a lot!!
Centos has cgroups installed under /cgroup.
You can check the enabled cgroups under /proc/cgroups.
cat /proc/mounts | grep ^cgroup will give the location where cgroups are mounted.