December 2018 - kernelnewbies@kernelnewbies.org

Add IIO example to the kernelnewbies wiki
by Gaston Gonzalez Feb. 21, 2019

Feb. 21, 2019

Hi, I'm testing an AD7746 eval board using a Diolan DLN-2 adapter. I wrote some basic notes about the installation an instanciation process for my own use. But then I thought it could be useful for someone else. So maybe I could put this in the kernel newbies page under the IIO section? If you think is worth it, I would be glad to add it to the wiki page. Best regards, Gaston Notes: The setup ========= AD7746-EVAL BOARD --> Diolan DLN-2 Adapter --> Thinkpad T430 The connection between the AD7746 eval board and adapter is as detailed in [2] I2C Interface Configuration Options, External connection (pag 4). The connection between Diolan DLN-2 and the T430 is USB straighforward. Drivers ======= Both in mainline kernel: - Diolan DLN-2 driver: I2C_DLN2 (prompt Diolan DLN-2 USB I2C adapter) Loc: drivers/i2c/busses/ - AD7746: AD7746 Loc: drivers/staging/iio/cdc/ Bus of interest =============== $ sudo i2cdetect -l We get something like: ... i2c-10 i2c dln2-i2c-1-1.2:1.0-0 I2C adapter ... So our bus is the number 10. Getting the address =================== $ sudo i2cdetect -y -r 10 We get something like: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- 3. Device instantiation: # echo add7746 0x48 > /sys/bus/i2c/devices/i2c-10/new_device We must see something like: $ cd /sys/bus/i2c/devices/i2c-10/10-0048/ $ ls driver iio:device0 modalias name power subsystem uevent $ cd iio:device0 $ ls dev in_capacitance-capacitance_calibbias in_capacitance0_calibbias_calibration in_capacitance-capacitance_sampling_frequency in_capacitance0_calibscale in_capacitance-capacitance_scale in_capacitance0_calibscale_calibration in_capacitance_sampling_frequency in_capacitance0-capacitance2_calibscale in_capacitance_sampling_frequency_available in_capacitance0-capacitance2_offset in_capacitance_scale in_capacitance0-capacitance2_raw in_temp0_input in_capacitance0_offset in_temp1_input in_capacitance0_raw in_voltage0_calibscale_calibration in_capacitance1_calibbias_calibration in_voltage0_raw in_capacitance1_calibscale in_voltage1_supply_raw in_capacitance1_calibscale_calibration in_voltage_sampling_frequency in_capacitance1-capacitance3_calibscale in_voltage_sampling_frequency_available in_capacitance1-capacitance3_offset in_voltage_scale in_capacitance1-capacitance3_raw name in_capacitance1_offset power in_capacitance1_raw subsystem in_capacitance_calibbias uevent Checking the permits: $ ll -r--r--r-- 1 root root 4096 mar 31 09:57 dev --w------- 1 root root 4096 mar 31 09:57 in_capacitance0_calibbias_calibration -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0_calibscale --w------- 1 root root 4096 mar 31 09:57 in_capacitance0_calibscale_calibration -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0-capacitance2_calibscale -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0-capacitance2_offset -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0-capacitance2_raw -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0_offset -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0_raw --w------- 1 root root 4096 mar 31 09:57 in_capacitance1_calibbias_calibration -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1_calibscale --w------- 1 root root 4096 mar 31 09:57 in_capacitance1_calibscale_calibration -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1-capacitance3_calibscale -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1-capacitance3_offset -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1-capacitance3_raw -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1_offset -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1_raw -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance_calibbias -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance-capacitance_calibbias -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance-capacitance_sampling_frequency -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance-capacitance_scale -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance_sampling_frequency -r--r--r-- 1 root root 4096 mar 31 09:57 in_capacitance_sampling_frequency_available -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance_scale -rw-r--r-- 1 root root 4096 mar 31 09:57 in_temp0_input -rw-r--r-- 1 root root 4096 mar 31 09:57 in_temp1_input --w------- 1 root root 4096 mar 31 09:57 in_voltage0_calibscale_calibration -rw-r--r-- 1 root root 4096 mar 31 09:57 in_voltage0_raw -rw-r--r-- 1 root root 4096 mar 31 09:57 in_voltage1_supply_raw -rw-r--r-- 1 root root 4096 mar 31 09:57 in_voltage_sampling_frequency -r--r--r-- 1 root root 4096 mar 31 09:57 in_voltage_sampling_frequency_available -rw-r--r-- 1 root root 4096 mar 31 09:57 in_voltage_scale -r--r--r-- 1 root root 4096 mar 31 09:57 name drwxr-xr-x 2 root root 0 mar 31 09:57 power lrwxrwxrwx 1 root root 0 mar 31 09:57 subsystem -> ../../../../../../../../../../../bus/iio -rw-r--r-- 1 root root 4096 mar 31 09:57 uevent 4. Capacitance According to [2], the capacitive length sensor is connected to CIN2+ and CIN2-. In the driver, the values are mapped to capacitance0. Raw values vs sensor length: Note: (+) values means the sensor was moved to the left, (-) values means the sensor was moved to the right. I.e. +1 cm means the rule was moved 1 to the left, while -1 means the rule was moved 1 cm to the right. Note2: note the raw value for -10 is 8224733, while +10 is -8224726, the difference is because when the rule is moved 10 cm to the left, the is still 2 o 3 cm of dielectric between the plates. The design is obviously thought to move the rule to the right. Length (cm) | Raw Value Cap0 ------------------------------ -10 -8224733 -9 -8224730 -8 -8224728 -7 -8224725 -6 -8224724 -5 -8224722 -4 -8224720 -3 -8224718 -2 -8224716 -1 -8224714 +0 -8224711 +1 -8224711 +2 -8224711 +3 -8224711 +4 -8224713 +5 -8224715 +6 -8224717 +7 -8224719 +8 -8224721 +9 -8224723 +10 -8224726 References ========== [1] http://www.analog.com/media/en/technical-documentation/data-sheets/AD7745_7… [2] http://www.analog.com/media/en/technical-documentation/evaluation-documenta… [3] https://i2c.wiki.kernel.org/index.php/Main_Page [4] https://kernelsense.wordpress.com/2016/01/22/achievement-unlocked-first-iio…

2 2

Understanding memory fragmentation in Linux kernel
by Amit Agarwal Jan. 13, 2019

Jan. 13, 2019

Hi All, I am trying to understand memory fragmentation and how to understand and/or analyze the same. Is there some detailed documentation on pagetypeinfo and buddyinfo files present in the proc directory? Am I looking at right files to understand if the memory is fragmented. Problem Description: One of the applications does a few 200-300Mb calloc's during start-up. On one of the production servers, the application does not start up although there should be enough RAM available for application to start. I am suspecting that this is because of fragmentation and would like to confirm the same. -- Thanks, -aka

3 5

How to signal kernel that shared library is not in use by any process anymore ?
by Lev Olshvang Jan. 8, 2019

Jan. 8, 2019

Hi All, I have an executable (C++) which is the exclusive user of the some shared library that it uses only during the initialization phase. I would like to free memory used by this shared library, because I am running on embedded system. How can I achieve this? I know that dlopen() will load shared library, and hope that following dlclose() will free this lib memory. 1. Still I do not know what method should be used to make dynamic linker look again into executable and resolve symbols of the newly appeared symbols ? 2. And how to tell the dynamic linker ld-linux.so to postpone the symbol resolution until dlopen() will load the library? 3. Whether to compile and link executable with this library or leave unresolved symbols? Waiting for your advises, Lev.

4 6

why are some stat.h "S_*" perm macros not exported via uapi?
by Robert P. J. Day Jan. 1, 2019

Jan. 1, 2019

more pedantry ... just noticed this snippet in include/linux/stat.h: ... #include <uapi/linux/stat.h> #define S_IRWXUGO (S_IRWXU|S_IRWXG|S_IRWXO) #define S_IALLUGO (S_ISUID|S_ISGID|S_ISVTX|S_IRWXUGO) #define S_IRUGO (S_IRUSR|S_IRGRP|S_IROTH) #define S_IWUGO (S_IWUSR|S_IWGRP|S_IWOTH) #define S_IXUGO (S_IXUSR|S_IXGRP|S_IXOTH) ... given that all of the other S_ perm macros are exported in include/uapi/linux/stat.h, as in: #define S_IRWXU 00700 #define S_IRUSR 00400 #define S_IWUSR 00200 #define S_IXUSR 00100 #define S_IRWXG 00070 #define S_IRGRP 00040 #define S_IWGRP 00020 #define S_IXGRP 00010 and so on, is there a reason those few combination perm macros are not exported as well? or is the userspace stat.h so well-defined at this point that cosmetic changes like this are frowned upon? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 2

stylistically, IS_ERR() versus IS_ERR_VALUE()?
by Robert P. J. Day Dec. 31, 2018

Dec. 31, 2018

poking around error handling in the kernel, and noticed the following ... in include/linux/err.h, we have IS_ERR() unsurprisingly defined in terms of IS_ERR_VALUE(): #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= \ (unsigned long)-MAX_ERRNO) ... snip ... static inline bool __must_check IS_ERR(__force const void *ptr) { return IS_ERR_VALUE((unsigned long)ptr); } fair enough, and the above suggests that it's technically equivalent to use either one, but if i search under drivers/ for each: $ git grep -w IS_ERR -- drivers | wc -l 14048 $ $ git grep -w IS_ERR_VALUE -- drivers | wc -l 48 $ so IS_ERR() is pretty clearly the call of choice, and the invocations of IS_ERR_VALUE() are concentrated in a small number of files -- heck, 15 of those calls are in the single file drivers/net/ethernet/freescale/ucc_geth.c. is there any non-obvious reason for driver code to use the latter? superficially, they *seem* to be equivalent, but i've been surprised before. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

Listing Supported Kernel Parameters?
by Henry C Dec. 31, 2018

Dec. 31, 2018

Hi, I am looking for a command (or alike) to list all the supported kernel parameters based on my current kernel. If such command doesn't exist, it would still be great to see a complete list like this one: https://www.kernel.org/doc/html/v4.15/admin-guide/kernel-parameters.html But I can't find anything (reliable) for v3.10. Thanks.

2 4

8 bytes reserved at the top of the stack in arm
by ksourav Dec. 28, 2018

Dec. 28, 2018

Hi, In arm linux, kernel stack is 8KB(two consecutive pages). struct pt_regs lie at the top of the stack and thread_info lie at the bottom of the stack. In arch/arm/include/asm/processor.h #define task_pt_regs(p) \ ((struct pt_regs *)(THREAD_START_SP + task_stack_page(p)) - 1) In arch/arm/include/asm/threadinfo.h #define THREAD_START_SP (THREAD_SIZE - 8) Why are 8 bytes reserved at the top ? Also, seeing similar thing in arch/arm/include/asm/ptrace.h #define current_pt_regs(void) ({ (struct pt_regs *) \ ((current_stack_pointer | (THREAD_SIZE - 1)) - 7) - 1; \ }) (current_stack_pointer | (THREAD_SIZE - 1) It will get the top of stack and the we are subtracting 7 from it ? Why are these bytes reserved ? Thanks & Regards

1 0

In a process context kernel_read returns -EINTR, how to proceed?
by Lev Olshvang Dec. 23, 2018

Dec. 23, 2018

Hi All, I use kernel_read to read file in chunks of 4K size in a process context On several files, like libc, libm, I got -EINTR error. Then I repeated the attempt limited number of times but still on every read attempt I got -EINTR I do not understand who may interrupt such a small read, I suppose these libraries are already mapped in other processes so no real I/O should be done. In a user space it is recommended to repeat syscall, what is the proper course of action in kernel. As I stated, this code is not in a kernel thread or atomic context, it is in a process context so a tried before next attempt yield() but to no success. Waiting for your advises. Thx, Lev

3 6

How to detect slab memory leak
by Naruto Nguyen Dec. 21, 2018

Dec. 21, 2018

Hi everyone, When using slabtop to display the cache size growing, I see that kmalloc-1024 and kmalloc-256 are increasing about 200MB after 1 hour. Is there any way to detect which kernel components cause this slab increase? Thanks a lot, Brs, Naruto

3 4

Kernelnewbies, In support of your website ranking
by jameson＠myownphrases.com Dec. 20, 2018

Dec. 20, 2018

Hi Kernelnewbies! Every online business owner when starting out makes some mistakes, and these mistakes can hold back their campaigns and end up costing much more money. We can give you a possibility to try a new method of your web page optimization. It can be easily performed for your website to place on top of major search engines with no extra rules and much money. Forget PPC and all other models and join us to take a maximum of your web page optimization. If you really wish to follow our advice, then: First, visit our website and see the demo. Second, fill it with your website kernelnewbies org and keywords. Third, improve your website rank and stay always on top. See you shortly, Jameson Chandler

1 0