Fedora 21 terminal based application slow response - fedora

I have recently updated to Fedora 21 Beta, and updated all packages. As the final release is scheduled early next month, I don't expect anything big to change. So I think the problem I am facing may well persist into the production release.
The problem is that when using some terminal based applications, the terminal responses very slowly. For example, say I edit a file with Vim in terminal, after a few minutes, it becomes increasingly difficult to use. Every time I hit a keystroke, the cursor will wait like a second to respond. Edit the same file (which is of only a dozen of lines) in GVim, everything works as smoothly as expected. Other terminal based applications shows the same slow response. However, using the terminal itself as an interactive shell has no problem at all.
I understand it is very hard to come by an answer to why it is experiencing this kind of slow response based only on my vague description. However, if anyone can point to where I should look for diagnostics of the problem, some log files etc., it will highly appreciated.
Below are some more details of the system.
The computer is a Dell T3500 workstation with Xeon W3550 CPU, NVIDIA Quadro 2000 GPU. I am using the latest NVIDIA binary driver (both the long live version 340.58 as well as the beta series 346.16 are tried). The open-source driver was uninstalled and its kernel module were blacklisted (lsmod | grep nouveau shows nothing, as expected). The desktop environment is GNOME Classic.

I believe the issue is with the Nvidia driver configuration. I know this question is old, but I was looking for a solution to the same problem in Fedora 22. I experienced this issue when I was using Fedora 21, but I mostly put up with it.
The solution for me was to uncheck Sync to VBlank in the Nvidia X Server settings.

Are you running in a VM whose storage grows as you need it? Perhaps the problem is that the VM is taking time to allocate space as your storage needs grow. If that's the case, after a while you won't have the problem anymore, as your virtual disk will have grown as big as it needs to be.
As for diagnostics, try running "top", look for paging activity and resident set size.
Maybe something has a memory leak. It might not be in the terminal, but in one of its dependencies.

Related

Windows XP Mode on QEmu on Linux

In this tutorial you can see how to extract the VHD image file of the Windows XP contained in the "Windows XP Mode".
The tutorial also explains how to run it on VirtualBox and it works nicely (no special parameter, you just add the disk).
But I want to run it on QEmu and there I get a blue screen.
This is the command I'm using:
qemu-system-i386 -m 1G --enable-kvm -drive file=VirtualXP.vhd
I tried to convert the image to qcow2, raw, ... same issue.
I tried x86_64... same issue.
I tried without --enable-kvm... same issue but the blue screen is covered partly by a black rectangle.
After the blue screen it restarts and allows me to choose safe mode. But all options give this identical blue screen.
When I boot the image with VirtualBox I noticed that the VM has already a driver installed to allow the use of the host's mouse cursor. I suspect that this image has VM guest drivers installed that are not compatible with QEmu and maybe make it crashes.
Important note: I don't have a Windows XP CD-ROM to help me.
Here is a screen shot of the blue screen (I suppose it will be the exact same error on all machines):
This might have to do with the drivers windows expects, there are various results using search engines to fix/repair this issue I found but they mostly boil down to:
Install standard IDE drivers
Registery edit to add these IDE drivers
If BSOD 0xCE
Remove Intelppm driver
Edit registery to reflect the removal of this CPU driver
I like the idea of a Windows XP image converted to another, for qemu. And it sounded awesome if this was a legal way. And I now know how they solved this. There is a 30 days trail period and after this, our downloaded image will nolonger boot. (unless you redo all your steps on a fresh copy that never has been started).
Sources to help you (and I ) anyway: https://learn.microsoft.com/en-us/windows/client-management/troubleshoot-inaccessible-boot-device
wich was to me very cryptic and what to do?
But it was also reverenced by the following more helpfull article, and i was almost capable of making a bootable harddisk image for qemu because of this: http://0x0badc0de.blogspot.com/2013/05/converting-windows-virtual-machine-from.html
But after some hours back and forth, I wasnt fully successful and even the author mentions the 30day trial. legal, maybe, but still troublesome.
There is however a key included and if you where to acquire a XP install disk, maybe able to obtain a successful install of windows XP with the same 30 days trial. Hope this answer helps you or any traveler to decide their own story.

Fedora 28 is not starting: "acpi MST0101:00: platform device creation failed"

I have never experienced issues with my fedora 28 in my laptop, until recently, after not using my laptop for two-three weeks.
Now every time I start the laptop, I received the following error when the OS is loading:
failed to claim resource 1: [nen0xfed40000-oxfed40ff]
[ 0.123896] acpi MST0101:00: platform device creation failed:
-16
generating /run/initramfs/rdsosreport.txt
Note that It stops in a very limited terminal session. Hence, I cannot find the way to mount a usb key to copy the above mentioned file (my lack of experience).
I started the system using a borrowed usb key with Ubuntu, and have no problems at all, so I discard any hardware issue.
Still, the above mentioned file does not exists, or perhaps is removed when I started using the usb key?
Anyway, if you can help me or refer me to any source to fix the problem, and be able to use my Fedora again I will really appreciate it.
I do not want to install the OS again, and lose my installed programs and configuration.

"no CUDA-capable device is detected" with CUDA-capable GPU installed Win7

I have installed cuda.7.0.28 into my laptop. I tried to run one of the sample file. I ran deviceQuery project and got this message:
cudaGetDeviceCount returned 38
-> no CUDA-capable device is detected
Result = FAIL
Then, I ran nvidia-smi.exe file and got this message:
As you see, it is written that "Not Supported". What should I do?
nvidia-smi returning 'not supported' does not necessarily mean that your GPU does not have the ability to run CUDA code. It means that you don't have the ability to see the active CUDA process name using nvidia-smi.
Cuda-z might be of help here. Take a look at what it is here: http://cuda-z.sourceforge.net/
Also, I have to say I had quite a few problems getting CUDA running on Windows. If you really need to run it on Windows, make sure you go through this first: http://docs.nvidia.com/cuda/cuda-getting-started-guide-for-microsoft-windows/#axzz3cNkYKZDP
Have you tried to run it on linux on the same machine? It was much easier to get it workinge.
NVIDIA now provide a toolkit to install CUDA on windows (Linux or Mac also). It does a handy check of your system, to see if it meets necessary requirements for CUDA if you are unsure about your GPU
https://developer.nvidia.com/cuda-80-ga2-download-archive
I've noticed that when my nvidia driver is updated during the system package update process (on Ubuntu) that I'll get this message. It is resolved by a reboot, or likely an X restart although I haven't tried that.
This was disconcerting the first time it happened since it was one of those "Hey! My code just ran fine. WTF happened?" moments.

Python3: How do I get a warning that server memory is running out?

I'm writing a program that manages data entered by users. I plan to open a test version to the public and have no idea how many users there may be.
I want my program to test when memory is getting low so that I know when to buy more server space and so that I can automatically restrict data entry when necessary. What's a good way to detect memory shortage? Allocate garbage space temporarily to get the exception? Is there a better way?
This may be best accomplished outside of your application using a performance monitoring tool. Windows Server can be configured to do this for you; see this question. There are other tools out there that help you monitor your servers, and I advise you to use an existing system unless you absolutely have to do this with Python.
If you must absolutely do this using Python, then have a look at the psutil library:
psutil (python system and process utilities) is a cross-platform
library for retrieving information on running processes and system
utilization (CPU, memory, disks, network) in Python. It is useful
mainly for system monitoring, profiling and limiting process resources
and management of running processes. It implements many
functionalities offered by command line tools such as: ps, top, lsof,
netstat, ifconfig, who, df, kill, free, nice, ionice, iostat, iotop,
uptime, pidof, tty, taskset, pmap. It currently supports Linux,
Windows, OSX, FreeBSD and Sun Solaris, both 32-bit and 64-bit
architectures, with Python versions from 2.4 to 3.4. Pypi is also
known to work.
You may combine this with the email package to send the alerts.

GPGPU CUDA debug server

I have access to a server machine, with 3 CUDA enabled GPUs in it, and I would like to use NVidia Parallel Nsight, to remotly debug on the machine.
This works just find.
Now, is it possibble, to start another debug session (possibbly by another developer), on the same machine, but on another GPGPU?
Is it possibble, to do this, if I use gdb on linux?
Thanks,
krisy
Krisy, yes this is possible.
However this case/scenario that you mentioned has not been actively tested internally by the Nsight team yet. I tried this our real quick on a system with a similar setup as the one you mentioned and I was able to debug 2 different instances of CUDA app simulataneously (provided each app runs on a different unique device that is not connected to any output display).
The stability of this is not guaranteed. From what I've tried so far, this worked for me and it should work in theory as well but there were instances where I experienced sluggish behavior on my system.
For other developers who are interested to know more about this, please take a look at: http://forums.nvidia.com/index.php?showtopic=201211