I am trying to run an application on a Debian Machine. The application is written in C and is using DirectFb. But the directfb part is not working. It gives an error saying "Could not set the gamma ramp --> Invalid argument".I have attached the screen shot.
Try to run your application with different arguments , It will provide you the actual reason , why It is giving segmentation fault:
./tkcoda -c /var/tk/tk.conf -d --dfb:pixelformat=ARGB,system=fbdev,depth=16,mode=1024x768
you can check differnt pixelformat e.g. ARGB , RGB32 etc, for system fbdev , omap etc, for depth=32 , 16 etc , mode is your display width e.g. 640x480 etc.
Try to check your Font directory also , your font file is present or not at specified location .
Related
When I try to run a simulation in SE mode in gem5 I get the following output:
warn: No dot file generated. Please install pydot to generate the dot file and pdf. build/RISCV/mem/mem_interface.cc:791: warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes) 0: system.remote_gdb: listening for remote gdb on port 7000 build/RISCV/sim/simulate.cc:194: info: Entering event queue # 0. Starting simulation... build/RISCV/sim/mem_state.cc:443: info: Increasing stack size by one page. build/RISCV/sim/mem_state.cc:99: panic: Someone allocated physical memory at VA 0x4000000000000000 without creating a VMA! Memory Usage: 619616 KBytes Program aborted at tick 2222000
I'm using the ELF-linux cross compiler. Compiling with the Newlib-ELF cross compiler simulates just fine, but the thing is that I need to use pthreads(openmp) and the Newlib compilation doesn't support it. To get a grip on things I tried to simulate in x86, and found out that it wont work either with a simple gnu/gcc compilation. Then I complied replicating what the test-progs folder did with docker and then it worked fine. Is this the way to go? Since the error says there are problems with physical memory, would compiling with docker help out, or am I missing an obviuos fix? How would go about compiling RISCV with docker (I couldn't find examples of docker+RISCV)?
I'm working on an IP camera of mine and trying to get into single user mode. I have tried init=bin/bash, init=bin/sh, single 1, etc. When I change the bootargs and go to boot, it just boots up like normal, not even recognizing the commands.
What am I doing wrong?
Here is a printout of my original printenv:
bootcmd=sf probe 0;sf read 84000000 770000 10000;logoload 84000000;decjpg;sf read 82000000 30000 400000;squashfsload 82000000;bootm 0x82000000
bootdelay=1
baudrate=115200
bootfile="uImage"
restore=1
bootargs=mem=96M console=ttyAMA0,115200 root=1f01 rootfstype=squashfs mtdparts=hi_sfc:192K(boot),1984K(romfs),3776K(usr),1664K(custom),64K(logo),512K(mtd)
I am using v4l2-ctl from command line to change exposure values of usb camera but I cannot change the device from built in webcam
When I am using v4l2-ctl d /dev/video1 - it gives no error but it does nothing at all
You might be using the wrong cmd.
First of all, you need to specify -d to select a different device (mind the --prefix; it is missing in the Q).
but simply running v4l2-ctl -d /dev/video1 will not do anything with the device (you don't specify what to do)
So you also need to tell v4l2-ctl to change the exposure-time (or whatever you want to do) with the -c <ctrl>=<val> switch
So your command should look like:
v4l2-ctl -d /dev/video1 -c exposure_absolute=3000
but then, your device simply may not support setting the exposure time and simply ignore any requests (it should not announce support for setting the exposure if it cannot change it, but often device drivers are a bit easygoing)
I've been able to hack an Xscreensaver to where I'm getting my desired look (big thanks to luser droog for his aid). I added in some Cairo code because it was difficult to implement what I wanted with Xlib alone. Since this is just a hack for me I don't intend on distributing it.
Anyway, when I preview Fuzzyflakes in a window it looks fine, yet when I preview it fullscreen (like any good screensaver) it gives me this error:
X error in fuzzyflakes:
X Error of failed request: BadMatch (invalid parameter attribute)
Major Optcode of failed request: 139 (RENDER)
Minor optcode of failed request: 4 (RenderCreatePicture)
Serial number of failed request: 528
Current serial number in output stream: 1654
Here's some further information. I'm using Linux Mint 14, 64-bit edition. I'm using the nVidia proprietary drivers, version 304.88. I had to hack the Makefile generated by the xscreensaver configure script. I changed line 800 of the Makefile to this:
fuzzyflakes: fuzzyflakes.o $(HACK_OBJS)
$(CC_HACK) `pkg-config --cflags cairo` -g -o $# $#.o $(HACK_OBJS) $(HACK_LIBS) -lcairo -lm
For the full source code you can look here.
From a quick look, it seems like you are feeding cairo with invalid information:
flake->Fluff.gradient_image_background =
cairo_xlib_surface_create(flake->dpy,
flake->DB.b, DefaultVisual(flake->dpy, 0),
flake->XGWA.width, flake->XGWA.height);
This claims that the drawable DB.p uses the display's first screen's default visual. However, the actual window seems to be an argument to fuzzyflakes_init() and thus could be using another visual.
From another quick look, please try replacing DefaultVisual(flake->dpy, 0) with flake->XGWA.visual.
I am using OpenSearchServer v1.2.4 rc3.
In the first few days it's working fine.
But when its Index size reached 1.0GB I got this error
"Error (java.lang.NullPointerException)"
when I start my crawler. The crawler works fine for some time and then stops with this error
"Error (java.lang.NullPointerException)".
What's wrong?
Depending of the size of your index, a memory parameter must be added. By default, OpenSearchServer is setup to run on small server with the default RAM value provided by the Java Virtual Machine (from 64MB to 512MB only).
For large indexes, you must set up a higher value. On a Unix/Linux server, just create an /etc/opensearchserver file with the following content:
CATALINA_OPTS="-Xms2G -Xmx2G -server"
export CATALINA_OPTS
On a Windows server, edit the start.bat files. Add the following line just after :okExec
set CATALINA_OPTS="-Xms2G -Xmx2G -server"
Replace 2G (which mean 2 GB) by the size of the memory you want to allocate to OpenSearchServer.
In a 32 bits version, the memory is limited to 2.5GB. You can use more memory with a 64 bits operating system using the following lines (on Unix/Linux):
CATALINA_OPTS="-Xms12G -Xmx12G -d64 -server"
for Window 64bits:
set CATALINA_OPTS="-Xms12G -Xmx12G -d64 -server"
After restarting OpenSearchServer, just check in the Runtime tab panel that you have the correct size of memory available.
Regarding the error details, it is more useful to have the full stack trace. You can find it in the log file (data/logs/oss.log), or in the Runtime/Logs tab panel.