I made a node which contains a USRP_UHD and a GPP (and make sure the ip_address is correct for USRP_UHD). I launched the domain based on this node. However, I got the following error:
UHD Error:
Device discovery error: AssertionError: libusb_init(&_context) == 0
in libusb_session_impl::libusb_session_impl()
at /builddir/build/BUILD/uhd-release_003_005_003/host/lib/transport/libusb1_base.cpp:37
UHD Error:
Device discovery error: AssertionError: libusb_init(&_context) == 0
in libusb_session_impl::libusb_session_impl()
at /builddir/build/BUILD/uhd-release_003_005_003/host/lib/transport/libusb1_base.cpp:37
...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
UHD Warning:
Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
I did get two unallocated (TX/RX for each) tuners, but it is not easy to allocate these two tuners for use for any parameters.
Besides, if I just launch the domain and launch the single device USRP_UHD, or simply run the discover USRP_UHD command via the command line window, I got the same error:
UHD Error:
Device discovery error: AssertionError: libusb_init(&_context) == 0
in libusb_session_impl::libusb_session_impl()
at /builddir/build/BUILD/uhd-release_003_005_003/host/lib/transport/libusb1_base.cpp:37
2016-02-01 16:59:20 WARN USRP_UHD_i:943 - WARNING: NO UHD (USRP) DEVICES FOUND!
Could anybody figure out where this problem is? Thanks in advance!
So, first of all, the good news is that this is happening during autodetection of USB devices, so your N2xx is not inherently affected, but:
UHD 3.5.3 is not only old, it's ancient. You should really uninstall it (If you've got Debian or a derived one [Ubuntu], it'd be sudo apt-get remove uhd-host libuhd003 libuhd-dev), install a new version directly from Ettus (can help you with that, if necessary) and rebuild Redhawk against that version.
Really, really do that. There's been so much improvement in behaviour like failure handling that fixing this without updating isn't really worth it.
Now, if you explicitly specify a device address that allows you to cancel USB-based USRP detection completely, you should be fine. As device address, use type=usrp2 for USRP2, N200 and N210.
I ran into this issue trying to install UHD v3.9.3 in a CentOS 7 Docker container - the error message points to a usb issue, not related to Redhawk. The Redhawk Device, USRP_UHD, is just an abstraction layer on top of the Ettus UHD drivers, so the easiest way to tell whether the problem is Redhawk or something else is to try one of the UHD commands directly from a terminal to generate the same error, like uhd_usrp_probe.
To check if the problem is directly related to the usb drivers try the command lsusb. This should list all usb devices connected to your OS. These are good debug tips to isolate where the problem is.
If you happen to be doing this using Linux containers or Docker you have to give the proper privileges, see docker-any-way-to-give-access-to-host-usb-or-serial-device. Otherwise, assuming you built UHD from source, check the output of make test step - if all the tests passed there shouldn't be anything wrong with the UHD library.
Edit: Also if you're running this inside a VM you have to make sure your host has given network/USB/etc privileges to the hypervisor (ex. VirtualBox) during installation, or that you've attached the correct virtual hardware in the VM configuration.
Related
I installed Bluez and I am trying to scan and get UUID Major, Minor and if possible mac address for nearby ibeacon. I found similar questions and they refer to a script which I found here . When I launch the script I get this error
Set scan parameters failed: Input/output error
Did someone know how to solve the problem or has another solution ?
If I start transmitting with the beacon and then I start the scan I get no result at all and I have to interrupt the script.
You should test that the BlueZ installation is working properly on your Linux machine. Try using the hcitool dev command to see if it lists attached devices properly.
You may want to refer to a BlueZ installation guide like this one for Ubuntu to verify that you have your dongle set up properly.
I have been wanting to work with Vulkan, the new graphics API and have gotten it up and running with no problems on Windows 7. However I can't get Vulkan to work on linux. When I try running any of the LunarG samples, or even my own code, vkEnumeratePhysicalDevices always says that there are no physical devices. Here is my setup:
OS: Ubuntu 16.04 (LTS) [x64]
GPU: Nvidia Geforce GT 730 2GB GDDR5
Driver: NVIDIA Binary driver - version 364.19 from nvidia-364 (open source)
Vulkan SDK: LunarG v1.0.17.0 [ latest version]
I was wondering if maybe there's a file for my GPU that I need to set an environment variable for, but I really don't know. As I said before, this worked on Windows 7 perfectly, but I can't seem to get this to work this the above configuration. I am able to create an instance with the LunarG standard validation layer and the correct extensions, but vkEnumeratePhysicalDevices doesn't find any physical devices. It doesn't give an error, just says it can't find any physical devices. This has really got me stumped and I would really appreciate the help. Thanks!
Depending on your distribution you may have to install the nvidia-utils package. See this issue on my Vulkan repo for details.
If this isn't the case for you check the directories Karl mentioned and check if there is no other ICD (maybe one from Intel) that may cause troubles. If you're on an optimus system with dual GPU you may need to explicitly activate the NVIDIA GPU.
The 730 should work fine on Linux, at least judging from the Linux hardware reports I got on my database like this one.
You shouldn't have to set an environment variable if the driver installed properly.
One way to check for a proper installation is to look for the JSON file that identifies the driver. For example, an nvidia driver will place a file called nvidia_icd.json in /etc/vulkan/icd.d/. /usr/share/vulkan/icd.d/ is another standard, but less common location.
It may also be the case that your GPU does not support Vulkan. Be sure to check your GPU vendor's web pages to confirm support. You may want to download the driver straight from the vendor's site in order to get one that they say has Vulkan support.
And are you sure that using the "Additional Drivers" page is supposed to give you a Vulkan driver?
You can refer to the loader documentation in the docs section at https://vulkan.lunarg.com for more info.
I have dumped a SSD to a raw image file with dd. It is mountable and seems to be working fine. The OS installed is a Windows 7 32bits.
I tried to start a vm on qemu with this image disk as "hda" :
qemu-system-i386 -enable-kvm -hda my_image.001 -m 1024 -vga std &
I tried it with qemu-system-x86_64 too.
When the vm starts, the windows logo appears and a BSOD occurs. I do not have time to read the error message.
When it restarts it says that due to a recent hardware change windows has failed and starts on a windows repair tool.
The windows repair tool fails to fix the problem
Since Windows seems to start booting before crashing, I am guessing this is due to some driver being missing from the disk for windows to load. Is there a way to get the actual error or missing driver?
Thanks for your help.
EDIT :
According to the following link, I need to retrieve the drivers for the qemu emulated hardware and put it on the disk I want to use. I will try copying the drivers from a working VM to the one I want to fix.
http://www.dowdandassociates.com/blog/content/howto-repair-windows-7-install-after-replacing-motherboard/
It was due to drivers being loaded automatically at startup. Disabling the corresponding registry keys of the OS forces Windows to reload new drivers on next boot.
It worked properly.
in "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services"
Set the "Start" value to 0 for Amdide iaStorV and pciide.
I have a device driver that is freezing the OS. The mouse wont even move. I am trying to debug this issue and I believe one good approach is to use gdb with qemu, two things I have never used before. Is there a better approach?
So first I need to compile the kernel with debug symbols which I have done already.
Now, there is a new file that is generated called vmlinux that is located in that same folder as the source. It seems that I also need a bzImage file according to this so I can run the newly compiled kernel using:
qemu-system-i386 -kernel bzImage
or in debug mode
qemu-system-i386 -s -S -kernel bzImage
I cannot locate the bzImage file. Where do I find it or what is missing here? Is the bzImage referring to the OS Image I created using qemu-img create?
Also, what I do not understand is that now the kernel is compiled (vmlinux) how does I run it with qemu? So my question is when I run it with qemu or the debugger is the kernel running as an app in my main OS?
also how can I install my device driver? My understanding the kernel is not Ubuntu so there is no UI?
Also, I installed qemu and when I type qemu I get command not found. I am guessing I have to pick a specific processor emulator as in qemu-system-i386, qemu-system-x86_64, or qemu-x86_64?
How is qemu different or similar to the kvm command?
Thanks.
So, if I understand the problem correctly, you have a kernel module that needs no specific hardware. When you are working with the module, the system freezes but the kernel log contains nothing special.
The following may be helpful.
Getting the log
The symptoms you described may still be a result of a kernel oops or panic. The logging facilities sometimes die before they can output the information about the error to the log file. You may try to output the log via a serial port, this should be more reliable.
As your kernel module does not need any specific hardware, the easiest way is probably to install the same Linux distro as you use to a virtual machine and connect the virtual serial port (COM) of that machine to a pipe on your host system.
This is usually quite easy to do. For example, this blog post contains the detailed instructions in case the host OS and the guest OS are Ubuntu 11.10.
VirtualBox is used there to manage the virtual machines. If you prefer QEMU, this should be possible as well. I suppose it is a bit easier to go with VirtualBox though but it is a matter of personal preference.
Basically, you need to perform the following steps.
Create a virtual machine and install the Linux distro you need as a guest OS there.
Enable a serial port (COM1, ...) in the configuration of the virtual machine and configure it to connect to a special file on the host ("host pipe"), say /tmp/vbox_serial.
Start the guest OS and adjust its boot options: at least, add console=ttyS0,115200 or something like that to the kernel options in the boot loader menu.
On the host, start minicom, socat or whatever else to read from /tmp/vbox_serial.
That is it. Now you should get the kernel log of the guest OS pouring to your host system via /tmp/vbox_serial. If the guest system crashes then, you will get the log even if it is not saved into a file on the guest itself.
To make things easier, you may use socat on your host system rather than minicom that the author of that blog post suggests. The power of minicom is probably not needed here.
This way, you can use socat and tee to save the log to guest.log file while still outputting it to the console:
socat /tmp/vbox_serial - | tee guest.log
If there was a kernel oops or panic, the backtrace in the log usually helps to find out what
has gone wrong.
Detecting Deadlocks
If you have obtained the full log via a serial connection or some other means and still there is nothing suspicious there and you suspect there has been a deadlock in the kernel,
lockdep tool may help. It is included into the kernel (but you may need to rebuild the kernel with CONFIG_LOCKDEP_SUPPORT=y).
Lockdep detects the potential deadlocks and outputs the results to the kernel log. This presentation may help you analyse its output.
Tracing Facilities
If you need tracing of some events in the kernel to debug your system, there are some tools that could be handy.
Kprobes - a kind of breakpoints you can set in almost arbitrary place in the kernel. Can be used to trace function calls among other things, with a moderate performance impact.
SystemTap - a powerful system to analyze what is going on in the kernel. Part of it is based on Kprobes.
Ftrace - a tracing system included into the kernel, incurs less overhead than Kprobes if that matters.
I am trying to fix some error related to a SEGMENTATION FAULT. So when I try to fix the error using by step by step debugging of the code, I got couple of errors:
ERROR: cuda_trace_obj::initialize_cuda_library: Cuda initialize() returned CUDBG_ERROR_INITIALIZATION_FAILURE(20)!
ERROR: cuda_system_status_t::initialize: Error CUDBG_ERROR_UNINITIALIZED(5) getting device count
Any help or pointers regarding the above mentioned errors is appreciated.
This error often occurs when you debug a CUDA application on a computer with a single GPU and an X11 server running.
In a single GPU system, CUDA applications can be used debugged only if no X11 server (on Linux) or no Aqua desktop manager (on Mac OS X) is running on that system.
As far as I know, only the command line debugger CUDA-GDB is able to override this restriction setting software preemption as described in the cuda-gdb documentation, but works only for devices with SM3.5 compute capability and higher.