While checking the u-boot source, I saw the following code snippet to caliculate GENERATED_GBL_DATA_SIZE value in lib/asm-offsets.c.
(sizeof(struct global_data)+15) & ~15)
Can you tell me why we are adding 15 and doing bitwise-AND operation with ~15. I am referring "2014.07" U-boot source.
Thanks in advance.
Related
How can I change the circled value? (5CB4F8B3h)
I am not a professional, but it is vital for me to influence this value.
Treat it with understanding :)
Using a hex editor, locate the sector containing the hex value you need to modify, and change it. TimeDateStamp is in epoch time, so you should get the timestamp in epoch time and convert it to hexadecimal (you may use a calculator in "programming mode", type the decimal timestamp and you will get its hex value.
After some googling, I found that a tool called PE Explorer can modify the timestamp of PE executables, which is the thing you're attempting to do, so this could be a better solution for a no professional. The instructions are here. I'm in no way affiliated to this product, I just thought it may be useful for your needs.
Modify these values in IDA with idc function PatchDword:
success PatchDword(long ea,long value);
This function changes a dword (4 bytes) at address ea to value.
You want to change 3 values at 0x14010D484, 0x14010D4A0 and 0x14010D4BC.
In IDA run "File->IDC command..." and enter this script with newValue1, newValue2 and newValue3 set to new values for these addresses:
if( !PatchDword(0x14010D484, newValue1) || !PatchDword(0x14010D4A0, newValue2) || !PatchDword(0x14010D4BC, newValue3))
Message("Failed to patch!\n");
Click OK and check the output window - there should be no error messages.
Generate DIF file - "File->Produce File->Create DIF file...". The DIF file is a text file with a list of patched bytes. Each line looks like:
0005A827: 5D BB
In this example 0005A827 is an offset in the binary on the disk, 5D is the original value, BB is the new value.
Apply this DIF file with some patch applyer or do it manually in a hex editor - move to the offsets from the DIF file and change the values of the bytes.
Your binary can use checksum checking. In this case it will not run after the patch. The checksum fix depends on the checksum type used.
I am trying to determine how fio (github.com/axboe/fio) determines if there is a write error when using the libaio ioengine.
From the post at linux kernel aio functionality, I see an example of error checking in the callback function, work_done(), which examines the events returned by io_getevents().
But I cannot find any similar error checking in the fio_libaio_getevents() function from libaio.c (https://github.com/axboe/fio/blob/master/engines/libaio.c#L145).
I have written to the mailing list (fio#vger.kernel.org) from https://github.com/axboe/fio/blob/fio-2.17/README#L77, but the mail bounces. So any help would be much appreciated.
Thanks in advance.
The errors are returned as res and res2 in struct iocb. In that fio code, you can see the iocb array passed in here, as ld->aio_events + events.
r = io_getevents(ld->aio_ctx, actual_min,
max, ld->aio_events + events, lt);
The actual error is checked earlier in the file, in the function fio_libaio_event.
I am trying to use the arDetectMarker function from arToolKit to detect markers in an image. I read the image from disk in the following way:
cv::Mat image;
cv::Mat temp;
image = cv::imread(path, CV_LOAD_IMAGE_COLOR);
cv::cvtColor(image, temp, CV_RGB2BGR);
and converted to ARUint8* format using:
dataPtr = (ARUint8 *) ((IplImage) temp).imageData;
I am sure that the data is correctly converted to dataPtr since I saved the image to check. Unfortunately, when I call arDetectMarker, a "segmentation fault" happens and I don't know the reason (I think it is due to the pixel format). I've read in the documentation:
http://artoolkit.sourceforge.net/apidoc/ar_8h.html#b2868d9587c68fb7255d4f270bcf878f
and it says that the format is in general ABGR. But I am using Ubuntu 14.04 and I think that I have v4l drivers, although I am not sure since I am not working with videos. I tried to convert the image loaded to ABGR or BGRA, but I am not sure if I did it correctly, or if this is really a requirement.
Also, I did the calibration procedure before.
Anybody can help me?
Thanks!
Marcelo.
I am trying to run a classifier in WEKA, using a J48 classifier using the following command line:
$ java -Xmx2048m -cp /home/weka-3-7-9/weka.jar weka.classifiers.trees.J48 -t input.arff -i -k -d J48-data.model &
Although the size of my arff is 43.8 M, and I aumented the heap space to 2048m,
I still received the following errors:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.ArrayList.<init>(ArrayList.java:132)
at weka.core.Instances.initialize(Instances.java:196)
at weka.core.Instances.<init>(Instances.java:177)
at weka.classifiers.trees.j48.ClassifierSplitModel.split(ClassifierSplitModel.java:252)
at weka.classifiers.trees.j48.ClassifierTree.buildTree(ClassifierTree.java:159)
at weka.classifiers.trees.j48.C45PruneableClassifierTree.buildClassifier(C45PruneableClassifierTree.java:126)
at weka.classifiers.trees.J48.buildClassifier(J48.java:249)
at weka.classifiers.evaluation.Evaluation.evaluateModel(Evaluation.java:1485)
at weka.classifiers.Evaluation.evaluateModel(Evaluation.java:649)
at weka.classifiers.AbstractClassifier.runClassifier(AbstractClassifier.java:297)
at weka.classifiers.trees.J48.main(J48.java:1062)
Does someone know if I am doing something incorrectly? Or can point me to a different solution to increase the heap?
Thank you in advance.
Quick instruction for the Ubuntu-Users: The heap can be set by changing the line MEMORY="256m" in the file /usr/bin/weka with your favored editor.
Weka's instructions state that the "-Xmx..." command will not work from the simple command line interface. I believe you should increase the heap size by editing the RunWeka.ini file. The link I provided should point you in the right direction.
In terminal use this command
sudo gedit /usr/bin/weka
Change the size in the line
MEMORY="256m"
If you are lucky when your kernel module crashes, you would get an oops with a log with a lot of information, such as values in the registers etc. One such information is the stack trace (The same is true for core dumps, but I had originally asked this for kernel modules). Take this example:
[<f97ade02>] ? skink_free_devices+0x32/0xb0 [skin_kernel]
[<f97aba45>] ? cleanup_module+0x1e5/0x550 [skin_kernel]
[<c017d0e7>] ? __stop_machine+0x57/0x70
[<c016dec0>] ? __try_stop_module+0x0/0x30
[<c016f069>] ? sys_delete_module+0x149/0x210
[<c0102f24>] ? sysenter_do_call+0x12/0x16
My guess is that the +<number1>/<number2> has something to do with the offset from function in which the error has occurred. That is, by inspecting this number, perhaps looking at the assembly output I should be able to find out the line (better yet, instruction) in which this error has occurred. Is that correct?
My question is, what are these two numbers exactly? How do you make use of them?
skink_free_devices+0x32/0xb0
This means the offending instruction is 0x32 bytes from the start of the function skink_free_devices() which is 0xB0 bytes long in total.
If you compile your kernel with -g enabled, then you can get the line number inside functions where the control jumped using the tool addr2line or our good old gdb
Something like this
$ addr2line -e ./vmlinux 0xc01cf0d1
/mnt/linux-2.5.26/include/asm/bitops.h:244
or
$ gdb ./vmlinux
...
(gdb) l *0xc01cf0d1
0xc01cf0d1 is in read_chan (include/asm/bitops.h:244).
(...)
244 return ((1UL << (nr & 31)) & (((const volatile unsigned int *) addr)[nr >> 5])) != 0;
(...)
So just give the address you want to inspect to addr2line or gdb and they shall tell you the line number in the source file where the offending function is present
See this article for full details
EDIT: vmlinux is the uncompressed version of the kernel used for debugging and is generally found # /lib/modules/$(uname -r)/build/vmlinux provided you have built your kernel from sources. vmlinuz that you find at /boot is the compressed kernel and may not be that useful in debugging
For Emacs users, here's is a major mode to easily jump around within the stack trace (uses addr2line internally).
Disclaimer: I wrote it :)
regurgitating this answer you need to use faddr2line
In my case I had the following truncated call trace:
[ 246.790938][ T35] Call trace:
[ 246.794075][ T35] __switch_to+0x10c/0x180
[ 246.798348][ T35] __schedule+0x278/0x6e0
[ 246.802531][ T35] schedule+0x44/0xd0
[ 246.806368][ T35] rpm_resume+0xf4/0x628
[ 246.810463][ T35] __pm_runtime_resume+0x94/0xc0
[ 246.815257][ T35] macb_open+0x30/0x2b8
[ 246.819265][ T35] __dev_open+0x10c/0x188
and ran the following in the mainline linux kernel:
./scripts/faddr2line vmlinux macb_open+0x30/0x2b8
giving the output
macb_open+0x30/0x2b8:
pm_runtime_get_sync at include/linux/pm_runtime.h:386
(inlined by) macb_open at drivers/net/ethernet/cadence/macb_main.c:2726