I have a module running on my Linux machine and can see it using lsmod command. Now I made some changes (added some printk) to this module, recompiled it and got the .ko.
Now I did rmmod to remove this module (some other modules also which are using this module), did insmod xxx.ko and rebooted the system.
Now where do I see the statements added using printk? I tried to see using
dmesg grep | "SPI RW"
But I couldn't find anything. What am I doing wrong here?
Try vim /var/log/messages or open messages in a text editor to verify.
For enabling /var/log/messages, edit file /etc/rsyslog.d/50-default.conf
Change the following paragraph:
...
#
# Some "catch-all" log files.
#
#*.=debug;\
# auth,authpriv.none;\
# news.none;mail.none -/var/log/debug
#*.=info;*.=notice;*.=warn;\
# auth,authpriv.none;\
# cron,daemon.none;\
# mail,news.none -/var/log/messages
....
to the following:
...
#
# Some "catch-all" log files.
#
*.=debug;\
auth,authpriv.none;\
news.none;mail.none -/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
...
and do restart rsyslog.
Related
I'm trying to build an external tool with AOSP. My OS is Linux, Distribution ArchLinux (i3wm), but to compile AOSP I use Ubuntu in Docker (https://android.googlesource.com/platform/build/+/master/tools/docker)
First step:
# init repo
repo init -u https://android.googlesource.com/platform/manifest -b android-8.0.0_r36 --depth=1
repo sync
. build/envsetup.sh # set up environment
lunch aosp_arm-eng # select target to build
Second step: select tool and build
cd external/selinux
mma -j48
Output:
ninja: error: unknown target 'MODULES-IN-'
15:41:55 ninja failed with: exit status 1
make: *** [run_soong_ui] Error 1
make: Leaving directory `/home/user/aosp'
#### make failed to build some targets (6 seconds) ###
Another tool
cd external/wpa_supplicant_8
mma -j48
Output:
ninja: error: unknown target 'MODULES-IN-external-wpa_supplicant_8'
15:41:55 ninja failed with: exit status 1
make: *** [run_soong_ui] Error 1
make: Leaving directory `/home/user/aosp'
#### make failed to build some targets (2 seconds) ###
This happens with any aosp generic target:
Lunch menu... pick a combo:
1. aosp_arm-eng # fails
2. aosp_arm64-eng # fails
3. aosp_mips-eng # fails
4. aosp_mips64-eng # fails
5. aosp_x86-eng # fails
6. aosp_x86_64-eng # fails
7. full_fugu-userdebug # works
8. aosp_fugu-userdebug # works
9. car_emu_arm64-userdebug # fails
10. car_emu_arm-userdebug # fails
11. car_emu_x86_64-userdebug # fails
12. car_emu_x86-userdebug # fails
13. mini_emulator_arm64-userdebug # fails
14. m_e_arm-userdebug # fails
15. m_e_mips64-eng # fails
16. m_e_mips-userdebug # fails
17. mini_emulator_x86_64-userdebug # fails
18. mini_emulator_x86-userdebug # fails
19. aosp_dragon-userdebug # works
20. aosp_dragon-eng # works
21. aosp_marlin-userdebug # works
22. aosp_marlin_svelte-userdebug # works
23. aosp_sailfish-userdebug # works
24. aosp_angler-userdebug # works
25. aosp_bullhead-userdebug # works
26. aosp_bullhead_svelte-userdebug # works
27. hikey-userdebug # works
I want to compile some binary tools in all arch: arm, arm64, x86 and x86_64.
Why aosp_arm-eng does not work? Or how can I change the CPU architecture from non generic aosp target?
Using tapas does not work.
You probably need to make a full AOSP build before trying to use mm... shortcuts - looks like some build script files were not generated yet.
clear all the binaries from /out dir with make clean command & then try to make a full build
Actually there is no need to do a full build. Just open your Android.mk or Android.bp of the module you want to build, and look for variable MODULE_NAME.
Then from the root of the project make
mm $MODULE_NAME
It should build all the dependencies you need first.
I suggest that use the mmm command for building. Also make sure that the directory you are pointing to contains a Android.bp or Android.mk
mmm /external/selinux
Also I suggest to clean the outputs by remove the out directory or simply run:
make clean
If still you have that problem, remove the --depth=1 argument on repo init and sync it again. that argument limits the commit fetching from remote branch.
Use below commands to compile module from root dir
Goto root dir
make clean
source build/envsetup.sh
lunch "select option"
make "module name" -j8
I added iptables package to my device image, using CORE_IMAGE_EXTRA_INSTALL += "iptables".
I tried to run it on the device and get the following error message:
modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.9.11-1.0.0+gc27010d
iptables v1.6.1: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
Seems like I have missing kernel module.
Need your help in adding standard kernel module to the image (Where can I find all modules files and how should I add and load it to the image).
You must add the iptables module to your kernel. I had the same problem and I could solve it with these steps:
Run bitbake -c menuconfig virtual/kernel
Activate CONFIG_IP_NF_IPTABLES module (you can search its location on that menu typing slash '/').
Save it and run bitbake -c savedefconfig virtual/kernel for saving that file as a defconfig.
Copy defconfig file from returned path to yocto-distro/layer-name/recipes-kernel/linux/files/ (make this directory if it does not exist).
Create a .bbappend file inside yocto-distro/layer-name/recipes-kernel/linux/ with the same name as your original recipe file from meta layer.
Edit your file and append lines below:
SRC_URI += "file://defconfig"
KERNEL_DEFCONFIG = "${WORKDIR}/defconfig"
FILESEXTRAPATHS_prepend := "${THISDIR}/files"
~
Relaunch bitbake your-image-name
It worked on my situation. Btw, I got that info from the following webs:
http://variwiki.com/index.php?title=Yocto_Customizing_the_Linux_kernel
https://www.linuxtopia.org/Linux_Firewall_iptables/x651.html
Have a nice day! :D
I was looking for a way to find out where my program spends time. I read the perf tutorial and tried to profile sleep times as it is described there. I wrote the simplest possible program to profile:
#include <unistd.h>
int main() {
sleep(10);
return 0;
}
then I executed it with perf:
$ sudo perf record -e sched:sched_stat_sleep -e sched:sched_switch -e sched:sched_process_exit -g -o ~/perf.data.raw ./a.out
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.013 MB /home/pablo/perf.data.raw (~578 samples) ]
$ sudo perf inject -v -s -i ~/perf.data.raw -o ~/perf.data
build id event received for [kernel.kallsyms]: d62870685909222126e7070d2bafdf029f7ed3b6
failed to write feature 2
$ sudo perf report --stdio --show-total-period -i ~/perf.data
Error:
The /home/pablo/perf.data file has no samples!
Does anybody know how to avoid these errors? What do they mean? failed to write feature 2 doesn't look too user-friendly...
Update:
$ uname -a
Linux debian 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01) x86_64 GNU/Linux
There is a error message from your second perf command from https://perf.wiki.kernel.org/index.php/Tutorial#Profiling_sleep_times - perf inject -s
$ sudo perf inject -v -s -i ~/perf.data.raw -o ~/perf.data
build id event received for [kernel.kallsyms]: d62870685909222126e7070d2bafdf029f7ed3b6
failed to write feature 2
failed to write feature 2 doesn't look too user-friendly...
... but it was added to perf to made errors more user-friendly: http://lwn.net/Articles/460520/ "perf: make perf.data more self-descriptive (v5)" by Stephane Eranian , 22 Sep 2011:
+static int do_write_feat(int fd, struct perf_header *h, int type, ....
+ pr_debug("failed to write feature %d\n", type);
All features are listed here http://lxr.free-electrons.com/source/tools/perf/util/header.h#L13
15 HEADER_TRACING_DATA = 1,
16 HEADER_BUILD_ID,
So, it sounds like perf inject was not able to write information about build ids (error from function write_build_id() from util/header.c) if I'm not wrong. There are two cases which can lead to error: unsuccessful call to perf_session__read_build_ids() or failing in writing buildid table dsos__write_buildid_table (this is not our case because there is no "failed to write buildid table" error message; check write_build_id)
You may check, do you have all buildids needed for the session. Also it may be useful to clear your buildid cache (rm -rf ~/.debug), and check that you have up-to-date vmlinux with debugging info or kallsyms enabled in your kernel.
UPDATE: in comments Pavel says that his pref record had no any sched:sched_stat_sleep events written to perf.data:
sudo perf record -e sched:sched_stat_sleep -e sched:sched_switch -e sched:sched_process_exit -g -o ~/perf.data.raw ./a.out
As he explains in his answer, his default debian kernel have CONFIG_SCHEDSTATS option disabled with vendor's patch. The redhat did the same thing with the option in release kernels since 3.11, and this is explained in Redhat Bug 1013225 (Josh Boyer 2013-10-28, comment 4):
We switched to enabling that only on debug builds a while ago. It seems that was turned off entirely with the final 3.11.0 build and has remained off since. Internal testing shows the option has a non-trivial performance impact for context switches.
We can turn this on in debug kernels again, but I'm not sure it's worthwhile.
Josh Poimboeuf 2013-11-04 in comment 8 says that performance impact is detectable:
In my tests I did a lot of context switches under various CPU loads. I saw a ~5-10% drop in average context switch speed when CONFIG_SCHEDSTATS was enabled. ...The performance hit only seemed to happen on post-CFS kernels (>= 2.6.23). The previous O(1) scheduler didn't seem to have this issue.
Fedora disabled CONFIG_SCHEDSTAT in non-debug kernels at 12 July 2013 "[kernel] Disable LATENCYTOP/SCHEDSTATS in non-debug builds." by Dave Jones. First kernel with disabled option: 3.11.0-0.rc0.git6.4.
In order to use any perf software tracepoint event with name like sched:sched_stat_* (sched:sched_stat_wait, sched:sched_stat_sleep, sched:sched_stat_iowait) we must recompile kernel with CONFIG_SCHEDSTATS option enabled and replace default Debian, RedHat or Fedora kernels which have no this option.
Thank you, Pavel Davydov.
I finally found out how to make it work. The problem was that the default debian kernel is built without some config options, that perf needs to be able to monitor sleep times. It looks like CONFIG_SCHEDSTATS should be enabled to make kernel collect scheduler statistics. This is told to have some runtime overhead. Also I enabled CONFIG_SCHED_TRACER and some lock tracing options, but I'm not sure if they matter in my case. Anyway, no statistic data is collected in scheduler without CONFIG_SCHEDSTATS (see kernel/sched/ directory of kernel source).
Also, there is a very good article about perf written by Brendan Gregg, with a lot of usefull examples and some kernel options that are needed to make perf work properly.
Update: I checked the history of CONFIG_SCHEDSTATS in debian. I've checked out debian kernel patches and build scripts repo:
svn checkout svn://svn.debian.org/svn/kernel/dists/trunk/linux/debian
And then found CONFIG_SCHEDSTATS option there
$ grep -R CONFIG_SCHEDSTAT config/
config/config:# CONFIG_SCHEDSTATS is not set
This string was added to the repo in commit 10837, on 2008-03-14, with comment "debian/config: Do complete reorganization". Also, in this and this (thanks to osgx) bug reports it is told that CONFIG_LATENCYTOP, CONFIG_SCHEDSTATS options are not enabled because they can affect kernel perfomance. So, I think it just was never switched on in default debian kernels. I haven't found the discussion about scheduler stats option, though. If I do, I will write back here.
This works for me for "perf version 3.11.1" on an "openSUSE 13.1 (x86_64)" box.
Here is the output if you care:
# ========
# captured on: Sun Feb 16 09:49:38 2014
# hostname : *****************
# os release : 3.11.10-7-desktop
# perf version : 3.11.1
# arch : x86_64
# nrcpus online : 8
# nrcpus avail : 8
# cpudesc : Intel(R) Core(TM) i7-3840QM CPU # 2.80GHz
# cpuid : GenuineIntel,6,58,9
# total memory : 32945368 kB
# cmdline : /usr/bin/perf inject -v -s -i perf.data.raw -o perf.data
# event : name = sched:sched_stat_sleep, type = 2, config = 0x48, config1 = 0x0, config2 = 0x
# event : name = sched:sched_switch, type = 2, config = 0x51, config1 = 0x0, config2 = 0x0, e
# event : name = sched:sched_process_exit, type = 2, config = 0x4e, config1 = 0x0, config2 =
# HEADER_CPU_TOPOLOGY info available, use -I to display
# HEADER_NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: cpu = 4, software = 1, tracepoint = 2, uncore_cbox_0 = 6, uncore_cbox_1 = 7,
# ========
#
# Samples: 0 of event 'sched:sched_stat_sleep'
# Event count (approx.): 0
#
# Overhead Period Command Shared Object Symbol
# ........ ............ ....... ............. ......
#
# Samples: 8 of event 'sched:sched_switch'
# Event count (approx.): 80099958776
#
# Overhead Period Command Shared Object Symbol
# ........ ............ ....... ................. .................
#
100.00% 80099958776 bla [kernel.kallsyms] [k] thread_return
|
--- thread_return
thread_return
do_nanosleep
hrtimer_nanosleep
SyS_nanosleep
system_call_fastpath
0x7fbc0dec6570
__GI___libc_nanosleep
(nil)
# Samples: 0 of event 'sched:sched_process_exit'
# Event count (approx.): 0
#
# Overhead Period Command Shared Object Symbol
# ........ ............ ....... ............. ......
#
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
}
When getting list of views in IBM Rational ClearTeam Explorer, it reports the error message"CRMAP7007: Error reading local file area registry." So I cannot retrieve my views list after that message shows. Does any one have idea about how to resolve this problem?
Many Thanks for your kind help!
Problem solved. Delete the .ccase_wvreg_lockfile from C:\Users\username\
Note: the thread "CRMAP7007 Error reading local file area registry" gives a bit more details:
It is interesting because it reminds you of the debug options that exist with CTE:
To get a better idea of why the error is thrown you can look in the workspace log file.
This file is by default <user home>\.Rational\workspace\.metadata\.log
You can also launch CTE in debug mode by creating a .options file in the directory that he executable is in. The content of that file should be as below:
# -------------- CCRC Tracing Options File -----------------
# All line preceeded with a # sign are not evaluated.
# ------Server Tracing-------
# subsystems available:
# CCRC - Core general tracing related to CCRC server operations
# CCWEB- CCWeb(CGI operations)
# SUM - UCM specific
com.ibm.rational.clearcase/server_trace=true
com.ibm.rational.clearcase/server_trace/subsys=CCRC:CCWEB:SUM
com.ibm.rational.clearcase/server_trace/level=4
# ------Client Only Tracing-------
# Parameters available:
# HTTP_CLIENT - Tracing specific to HTTP communications
# CTRC_UI - Tracing specific to the user interface
# CTRC_CORE - For client core tracing
com.ibm.rational.clearcase/client_trace=true
com.ibm.rational.clearcase/client_trace/params=HTTP_CLIENT:4 CTRC_UI:3 CTRC_CORE:3
com.ibm.rational.clearcase/client_trace/output=file
com.ibm.rational.clearcase/client_trace/file_name=C:/temp/cte_debug.out
# -------------- END CCRC Tracing Options File -----------------
With that file created, launch CTE from the command line using the -debug option:
C:\Program Files\IBM\RationalSDLC\ClearCase\RemoteClient>ctexplorer.exe -debug
I'm debugging remotely my project in PhpStorm. IDE shows 'Connected' for a moment and immediately goes into 'Waiting for incoming connection...'
Below is Xdebug log from this session
I: Connecting to configured address/port: X.x.x.x:9000.
I: Connected to client. :-)
> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///xxx/info.php" language="PHP" protocol_version="1.0" appid="4365" idekey="10594"><engine version="2.2.2"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATAhttp://xdebug.org]></url><copyright><![CDATA[Copyright (c) 2002-2013 by Derick Rethans]]></copyright></init>
<- feature_set -i 0 -n show_hidden -v 1
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="0" feature="show_hidden" success="1"></response>
<- feature_set -i 1 -n max_depth -v 1
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="1" feature="max_depth" success="1"></response>
<- feature_set -i 2 -n max_children -v 100
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="2" feature="max_children" success="1"></response>
<- status -i 3
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="status" transaction_id="3" status="starting" reason="ok"></response>
<- step_into -i 4
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="step_into" transaction_id="4" status="stopping" reason="ok"></response>
<- breakpoint_set -i 5 -t line -f file://xxx/info.php -n 3
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="5"><error code="5"><message><![CDATA[command is not available]]></message></error></response>
"
According to Xdebug documentation status "stopping" is
'State after completion of code execution. This typically happens at the end of code execution, allowing the IDE to further interact with the debugger engine (for example, to collect performance data, or use other extended commands).'
So my debugger stops before reaching first breakpoint (set on first line).
Could it be a question of server configuration?
You should go to php.ini and delete a line like this
extension=php_xdebug-...
How did this line was created.
You put a xdebug's file into PHP extensions path like this
.../php5.X.XX/ext/
Now you may turn on this PHP extension by any _AMP UI tools like WAMP, XAMPP etc.
To prevent this painful misfortune you must put the Xdebug file into
.../php5.X.XX/zend_ext/
It'll make Xdebug hidden from any _AMP tool.
And correct your zend_extension parameter too.
zend_extension = .../php5.X.XX/ext/php_xdebug-...
to
zend_extension = .../php5.X.XX/zend_ext/php_xdebug-...
It's common default path for it.
Please, remember!
With PHPStorm, Eclipse, Zend etc., possibly you should consider to correct two php.ini files.
The first one for your web server. Commonly under Apache folder
...\Apache2.X.XX\bin\
The second one is for the direct PHP-script debugging. It lies in the PHP hosting folder:
...\php\php5.X.XX\
In my case, the cause of the "breakpoint_set" / "command is not available" problem was disabled xdebug.extended_info option (it is enabled by default but I disabled it for profiling).
Breakpoints do not work then xdebug.extended_info is disabled.
I have got breakpoints worked after reenabling xdebug.extended_info.
I had same problem under windows, with phpstorm, i was googling many time. Eventually, my decision is the:
in php.ini:
xdebug.remote_mode = "jit"
From phpstorm tutorial, JIT - "Just-In-Time" Mode
https://www.jetbrains.com/help/phpstorm/2016.2/configuring-xdebug.html#d43035e303
UPD
No, this option does not helped me actually. But, i resolve my issue in the end:
I use phpstrom for win 7, and i configured the path mapping this way:
d:\serverroot\vhost\www => d:\serverroot\vhost\www
but in my old config i spied such mapping:
d:\serverroot\vhost\www => d:/serverroot/vhost/www
Finally
On windows machines in path mapping in server configuration replace the \ by /
I think the only reason why this could happen is that your info.php has a syntax error. In that case, there is no code to execute and the script goes directly to "stopping" upon issue of the "step_into".
Zend_Opcache / OPCache can cause this issue as well, if you have it enabled try disabling it.
This error can be emitted when the XDebug extension is compiled into a non-debug build of the PHP runtime. The process will not fail (as it shouldn't), but the XDebug extension will stop doing anything for the duration of that process