I want to have a fixed size integer of 64 bits in linux kernel.

My questions:

1. If I use unsigned long, then it may be 64-bit on one architecture and 32-bit on another. Right?
2. What would be the data type the for fixed 64-bit integer?

I am specifically referring to linux kernel

I have a websocket service. it's strage that have error:"too many open files", but i have set the system configure:

/etc/security/limits.conf
*               soft    nofile          65000
*               hard    nofile          65000

/etc/sysctl.conf
net.ipv4.ip_local_port_range = 1024 65000

ulimit -n
//output 6500

So i think my system configure it's right.

My service is manage by supervisor, it's possible supervisor limits?

check process start by supervisor:

cat /proc/815/limits
Max open files            1024                 4096                 files 

check process manual start:

cat /proc/900/limits
Max open files            65000                 65000                 files 

The reason is used supervisor manage serivce. if i restart supervisor and restart child process, it's "max open files" ok(65000) but wrong(1024) when reboot system supervisor automatically start.

May be supervisor start level is too high and system configure does not work when supervisor start?

edit:

system: ubuntu 12.04 64bit

It's not supervisor problem, all process auto start after system reboot are not use system configure(max open files=1024), but restart it's ok.

update

Maybe the problem is:

• https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/938669
• http://bryanmarty.com/blog/2012/02/10/setting-nofile-limit-upstart/
• Increase max open files for Ubuntu/Upstart (initctl)

Now the question is, how to set a global nofile limit because i don't want to set nofile limit in every upstart script which i need.

I am new to linux kernel programming. I am developing a simple Loadable Kernel Module which needs info whenever there is a change in scheduler runqueue (say rq_rt only). So I need to send a signal or interrupt to my kernel module (say a interrupt or signal handler in my module ) from the scheduler's functions (enqueue_rt, dequeue_rt, current_premept etc....).

Can anyone suggest a method how to send such signals or interrupts?

I have a vmlinuz EFL image file. I need to get the kernel version from the image file without disassembling it. Is it possible to get kerenel version from offsets of that compressed image file? The file is ELF 64-bit MSB executable, statically linked, not stripped.

I'm currently writing a PCIe kernel driver for linux kernel 4.19.
A FPGA (Arria 10) running an Intel DMA IP is connected to the Linux CPU (i7-6700TE) via PCIe Gen 2.
I want to run an upstream DMA transfer from FPGA to CPU RAM.
First the PCIe driver is initialized. I'm using the following instructions in order:

1. pci_enable_device
2. pci_set_master
3. pci_set_mwi
4. pci_set_dma_mask DMA_BIT_MASK(64)
5. pci_alloc_consistent

After allocation I push the physical address into the DMA configuration and start the transfer. After finishing I post a MSI, which is received and handeled.
The problem I have is that when reading the DMA data using the virtual address I only read zeros, while not writing any zeros via DMA.
I also tested the memory region by first writing a ramp to memory via CPU, then starting the DMA, then reading again and the ramp remained unchanged, thus I'm quite convinced, that no memory accesses to the specified region happened.
Why does the MSI transfer work (address space CPU), but the RAM access doesn't?
Do you have an idea what to do next?
Thanks in advance for your help.

I am doing performance analysis on a multi-threaded program that uses all the memory that is available in the system. My OS is Ubuntu 18.04. I'm trying to limit the available memory to e.g 32GB even though my server may have 128GB of memory available. Haven't been able to find a reliable solution. Seems like ulimit is not exactly doing what I'm looking for. I can also clog up memory by another process (e.g a controllable process that will consume 64GB of RAM). But even for that purpose I'm not sure how to reliably clog up the memory.

Would appreciate your thoughts.

/*
 * If any of p's children has a different mm and is eligible for kill,
 * the one with the highest oom_badness() score is sacrificed for its
 * parent.  This attempts to lose the minimal amount of work done while
 * still freeing memory.
 */

First and foremost I have little experience with custom built hardware. So far I've only designed Linux kernel modules on complete systems out of the box, so this may be a silly problem, but I can't solve it.

I have a Banana PI M2 Zero with a minimal Linux 5.6.0-rx5+ kernel based Ubuntu. I want to create a driver for the ADS1294 SPI analog front-end, so I've started with the most basic kernel file:

#include <linux/init.h>
#include <linux/module.h>

MODULE_LICENSE("GPL");

static int __init test_init(void){
    printk(KERN_INFO "TEST: starting...");
    return 0;
}

static void __exit test_exit(void){
    printk(KERN_INFO "TEST: stopping...");
}

module_init(test_init);
module_exit(test_exit);

with the Makefile:

obj-m := test_mod.o
all:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

After executing make all, the system states that make[1]: *** /lib/modules/5.6.0-rc5+/build: No such file or directory. Stop..

If I list the content of /lib/modules/5.6.0-rc5+/ I get: build kernel modules.alias modules.alias.bin modules.builtin modules.builtin.bin modules.builtin.modinfo modules.dep modules.dep.bin modules.devname modules.order modules.softdep modules.symbols modules.symbols.bin source

Similarly for ls /usr/src/linux-headers-5.6.0-rc5+/ I get an include folder.

From these I have a suspicion that somehow the headers are broken (?), but I'm not sure how to proceed, what to check. If possible I would like to avoid rebuilding the kernel.

I am currently reading Linux Device Drivers Volume 3 by Oreilly, and I had a question regarding file operations are setup for a specific device driver.

My current understanding is that in a character device driver in Linux, the cdev structs need to be allocated initialized in the device driver initialization function and passed to int cdev_add(struct cdev *dev, dev_t num, unsigned int count);.

Once this is all done, the kernel now associates the file operations specified in the struct file_operations with the struct cdev added.

My confusion comes when I try to understand what is happening in the device drivers open(struct inode *, struct file *) function. We are given both a file pointer as well as a inode pointer. Both of these structures contain struct file_operations * field, one in inode -> i_cdev -> ops and file -> f_op.

Are these fields referencing the same file_operations structure per device?

I also realize that I might be able to change the value of the file_operations structure. If I decide to edit a field within the structure, will the change be reflected once I exit the open() function? If so, what is the point of this functionality?

Sorry if I am asking too much within this post. Any help would be greatly appreciated!

As i am reading documents related to this but somewhere it is written that it will free memory for built in drivers not for loadable module i am not able to understand the depth of the words. Is it true that it will free memory only for the built in drivers not for the loadable module??

also i am not able to find in dmesg utility which is the memory free after the initialization of the __init .

Please help me to figure out in this.

Screenshot of dmesg utility

CONFIG_UNIX=m

I know what y and n stand for,but what about m?

I have a vmlinuz ELF image file. I need to get the kernel version from the image file without disassembling it. Is it possible to get kerenel version from offsets of that compressed image file? The file is ELF 64-bit MSB executable, statically linked, not stripped.

I am running a simulated RV64GC core in QEMU and am trying to better understand the virtual memory subsystem and address translation process in RISC-V. My simulated system runs with OpenSBI, the Linux Kernal v5.5, and a minimal rootfs.

In QEMU debug traces, I see that sometimes (most commonly with ecalls) control is passed to the SBI and the addresses change from kernel (virtual?) addresses with an offset of 0xffffffe000000000 into something that looks like real, physical, addresses in RAM. For example,

...

0xffffffe00003a192: 00000073 ecall

...

IN: sbi_ecall_0_1_handler

0x0000000080004844: 00093603 ld a2,0(s2)

0x0000000080004848: 4785 addi a5,zero,1

0x000000008000484a: 00a797b3 sll a5,a5,a0

...

In the RISC-V privileged specification version 1.11, section 4.1.12, the satp CSR (control and state register) is defined to have a MODE field that determines address translation designation. A MODE of 0 means that translation is bare (addresses are considered physical), a MODE of 8 or 9 requires Sv39 or Sv48 page-based virtual addressing, respectively, and any other MODE values are reserved.

Now, both the RISC-V privileged and unprivileged specifications don't seem to mention when satp may be changed (other than with csrrw), so this leads me to the following questions:

When control is handed to the SBI (as with the ecall above), does the satp MODE change to 0? If yes, does this mean the satp mode should be reset on a u/s/mret instruction? Are there other instances (other than csrrw) where satp is supposed to change?

If not, is there some other mechanism by which the addresses are interpreted and designated as physical? Or are the addresses (the 0x80XXXXXX addresses above) instead considered virtual and should go through the usual virtual address translation process (as outlined in section 4.3.2 of the RISC-V privileged specification)? If this is the case, when are page table entries created for this?

I'm trying to boot a compressed kernel (vmlinuz) with a custom bootloader on a switch containing a MIPS 24KEc processor. I didn't write this bootloader, it is present in NOR flash on the product and the source code was provided by the vendor in their GPL archive.

The bootloader reads a header from a fixed location in flash containing:

1. Header magic (SPIM)
2. Kernel load address
3. Length of data to load
4. Kernel entry address

It then copies num_bytes following the header to the kernel load address and jumps to the entry address specified. The boot command line and initrd are compiled into the kernel image (via CONFIG_CMDLINE and CONFIG_INITRAMFS_SOURCE).

Uncompressed kernel images (vmlinux) boot normally. When I try to boot a compressed kernel, I do not have any output from the decompressor or kernel.

I noticed that the Linux kernel saves the argument registers before clearing BSS and jumping to the decompressor (from arch/mips/boot/compressed/head.S):

start:    /* Save boot rom start args */    move    s0, a0    move    s1, a1    move    s2, a2    move    s3, a3

I am new to MIPS assembly, but I know that the above move statements are saving argument registers to saved registers. The saved registers are restored after the kernel is decompressed but before jumping to the kernel entry point:

    move    a0, s0    move    a1, s1    move    a2, s2    move    a3, s3    PTR_LI  k0, KERNEL_ENTRY

I looked at the u-boot source code and I'm wondering if this call in boot_jump_linux corresponds to the "boot rom start args" mentioned above:

kernel(linux_argc, (ulong)linux_argv, (ulong)linux_env,            linux_extra);

I could not find any kernel documentation explaining what arguments the kernel is expecting the boot rom to pass to it in registers a0, a1, a2, and a3.

Can't install any linux driver (kde neon 5.18)

example:

root@Casual-PC:/home/casual/veikk-linux-driver# make all installmake -C /lib/modules/5.3.0-42-generic/buildM=/home/casual/veikk-linux-driver modules make[1]: Entering directory'/usr/src/linux-headers-5.3.0-42-generic'   Buildingmodules, stage 2.   MODPOST 1 modules make[1]: Leaving directory'/usr/src/linux-headers-5.3.0-42-generic' make -C/lib/modules/5.3.0-42-generic/build M=/home/casual/veikk-linux-drivermodules_install make[1]: Entering directory'/usr/src/linux-headers-5.3.0-42-generic'   INSTALL/home/casual/veikk-linux-driver/veikk.ko At main.c:160:- SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:72- SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:79 sign-file: certs/signing_key.pem: No suchfile or directory   DEPMOD  5.3.0-42-generic Warning: modules_install:missing 'System.map' file. Skipping depmod. make[1]: Leavingdirectory '/usr/src/linux-headers-5.3.0-42-generic' modprobeveikk modprobe: FATAL: Module veikk not found in directory/lib/modules/5.3.0-42-generic Makefile:14: recipe for target'install' failed make: *** [install] Error 1 

All commands are tested in Raspberry Pi 3 with Raspbian OS. keyctl from keyutils-1.6.1 (Built 2020-03-25). Linux raspberrypi 4.19.108-v7+.

First I run following command in LXTerminal (CTRL+ALT+T):

pi@raspberrypi:~ $ dd if=/dev/urandom bs=1 count=32 status=none | keyctl padd user kmk-user @upi@raspberrypi:~ $ keyctl show @sKeyring 711830815 --alswrv      0     0  keyring: _ses 689584228 ----s-rv      0     0   \_ user: invocation_idpi@raspberrypi:~ $ keyctl show @uKeyring 142645230 --alswrv   1000 65534  keyring: _uid.1000 170877083 --alswrv   1000  1000   \_ user: kmk-userpi@raspberrypi:~ $ sudo cat /proc/keys02223a7e I--Q---     3 perm 3f030000     0     0 keyring   _ses: 102e2fd7a I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1603137436 I--Q---    10 perm 3f030000     0     0 keyring   _ses: 103c45b9a I--Q---     6 perm 3f030000     0     0 keyring   _ses: 1043a718f I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1604855c3e I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1606c8d5ce I--Q---     1 perm 1f3f0000     0 65534 keyring   _uid_ses.0: 107dae18e I------     1 perm 1f0f0000     0     0 keyring   .evm: empty0a1c9f48 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 10a940c2a I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 160b5947e4 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 160c83497b I--Q---     2 perm 3f030000     0     0 keyring   _ses: 1102c5f8b I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 161118e26c I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1613a9715d I------     1 perm 1f0b0000     0     0 keyring   .builtin_regdb_keys: 117363ba9 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 11852c597 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1618e604fd I--Q---     3 perm 3f030000     0     0 keyring   _ses: 11a9930b2 I--Q---     3 perm 3f030000     0     0 keyring   _ses: 11bf02ecc I------     1 perm 1f030000     0     0 asymmetri sforshee: 00b28ddf47aef9cea7: X509.rsa []1cbdf5d8 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 161d233ce9 I------     1 perm 1f030000     0     0 asymmetri ubuntu: wenxinleong signing key: dd43951113bd9ec66ddb6ad015eff35ee35a8f86: X509.rsa e35a8f86 []1d383e5a I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty1da9b1f1 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 161e534ab8 I------     1 perm 1f030000     0     0 keyring   .id_resolver: empty1e5dd4c7 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 11e776974 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 16284217fa I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 16289e20f2 I------     1 perm 1f030000     0     0 asymmetri IMA-CA: IMA/EVM certificate signing key: 3b8cf3d4f9513632582ad63be7decf9309c225cd: X509.rsa 09c225cd []28d21b03 I------     1 perm 1f0f0000     0     0 keyring   .ima: 1291a3864 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 16295e58d1 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 129b44fb0 I--Q---     2 perm 1f3f0000     0 65534 keyring   _uid.0: empty29e4eaed I--Q---     2 perm 3f030000     0     0 keyring   _ses: 12a6dad1f I--Q---    72 perm 3f030000     0     0 keyring   _ses: 12b2743a6 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 162dd82fe5 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 162ee89ece I--Q---     1 perm 3f030000     0     0 keyring   _ses: 1321d5477 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 133876f00 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 16347e4a12 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 135ae3569 I--Q---     3 perm 3f030000     0     0 keyring   _ses: 136182ec8 I------     1 perm 1f0b0000     0     0 keyring   .builtin_trusted_keys: 136a71fe9 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 16372bbf0d I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1639306e49 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 13995d96e I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1639f0e35d I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 163b16bd06 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 13da6e172 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 163e2beeb6 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 163e3050f0 I--Q---     3 perm 3f030000     0     0 keyring   _ses: 13ea1d4f3 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 1

Then following command in tty1 (CTRL+ALT+F1)

pi@raspberrypi:~ $ dd if=/dev/urandom bs=1 count=32 status=none | keyctl padd user kmk-user1 @upi@raspberrypi:~ $ keyctl show @sKeyring 759741276 --alswrv   1000  1000  keyring: _ses 142645230 --alswrv   1000 65534   \_ keyring: _uid.1000 963002826 --alswrv   1000  1000       \_ user: kmk-user1 170877083 --alswrv   1000  1000       \_ user: kmk-userpi@raspberrypi:~ $ keyctl show @uKeyring 142645230 --alswrv   1000 65534  keyring: _uid.1000 963002826 --alswrv   1000  1000   \_ user: kmk-user1 170877083 --alswrv   1000  1000   \_ user: kmk-userpi@raspberrypi:~ $ sudo cat /proc/keys02223a7e I--Q---     3 perm 3f030000     0     0 keyring   _ses: 102e2fd7a I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1603137436 I--Q---     6 perm 3f030000     0     0 keyring   _ses: 103c45b9a I--Q---     6 perm 3f030000     0     0 keyring   _ses: 1043a718f I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1604855c3e I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1606c8d5ce I--Q---     1 perm 1f3f0000     0 65534 keyring   _uid_ses.0: 107dae18e I------     1 perm 1f0f0000     0     0 keyring   .evm: empty088097ee I--Q---     3 perm 1f3f0000  1000 65534 keyring   _uid.1000: 20a1c9f48 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 10a2f609b I--Q---     1 perm 3f010000  1000  1000 user      kmk-user: 320a940c2a I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 160b5947e4 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 160c83497b I--Q---     2 perm 3f030000     0     0 keyring   _ses: 1102c5f8b I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 161118e26c I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1613a9715d I------     1 perm 1f0b0000     0     0 keyring   .builtin_regdb_keys: 117363ba9 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 11852c597 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1618e604fd I--Q---     3 perm 3f030000     0     0 keyring   _ses: 11a9930b2 I--Q---     3 perm 3f030000     0     0 keyring   _ses: 11bf02ecc I------     1 perm 1f030000     0     0 asymmetri sforshee: 00b28ddf47aef9cea7: X509.rsa []1cbdf5d8 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 161d233ce9 I------     1 perm 1f030000     0     0 asymmetri ubuntu: wenxinleong signing key: dd43951113bd9ec66ddb6ad015eff35ee35a8f86: X509.rsa e35a8f86 []1d383e5a I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty1da9b1f1 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 161e534ab8 I------     1 perm 1f030000     0     0 keyring   .id_resolver: empty1e5dd4c7 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 11e776974 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 16284217fa I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 16289e20f2 I------     1 perm 1f030000     0     0 asymmetri IMA-CA: IMA/EVM certificate signing key: 3b8cf3d4f9513632582ad63be7decf9309c225cd: X509.rsa 09c225cd []28d21b03 I------     1 perm 1f0f0000     0     0 keyring   .ima: 1291a3864 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 16295e58d1 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 129b44fb0 I--Q---     2 perm 1f3f0000     0 65534 keyring   _uid.0: empty29e4eaed I--Q---     2 perm 3f030000     0     0 keyring   _ses: 12a6dad1f I--Q---    53 perm 3f030000     0     0 keyring   _ses: 12b2743a6 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 162d48bb5c I--Q---    25 perm 3f030000  1000  1000 keyring   _ses: 12dd82fe5 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 162ee89ece I--Q---     1 perm 3f030000     0     0 keyring   _ses: 1321d5477 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 133876f00 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 16347e4a12 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 135ae3569 I--Q---     3 perm 3f030000     0     0 keyring   _ses: 136182ec8 I------     1 perm 1f0b0000     0     0 keyring   .builtin_trusted_keys: 136a71fe9 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 16372bbf0d I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1639306e49 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 1396641ca I--Q---     1 perm 3f010000  1000  1000 user      kmk-user1: 323995d96e I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 1639f0e35d I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 163b16bd06 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 13da6e172 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 163e2beeb6 I--Q---     1 perm 0b0b0000     0     0 user      invocation_id: 163e3050f0 I--Q---     3 perm 3f030000     0     0 keyring   _ses: 13ea1d4f3 I--Q---     2 perm 3f030000     0     0 keyring   _ses: 1

Two questions:

1. Why keyring: _ses in LXTerminal is uid:0 (root) and keyring: _uid.1000 become detached from @s; but in tty1 is uid:1000 (pi), and keyring: _uid.1000 is attached to @s. Can I change LXTerminal to have a default @s uid:1000?
2. Why sudo cat /proc/keys in LXTerminal only shows items with uid:0. But in tty1 all users are shown.

I have two questions;1. I know in the 32 bit Linux machine, the virtual address of a process is divided into 2, 3GB for Userspace and 1 GB for Krnel. Is it the same for x86_64/Linux 64 machine?2. The objdump of a linux executable shows the _init starts approximately from the address 0x400000. Why the exe adress starts from around 0x400000?

bash-4.2$ objdump -S a.out       a.out:     file format elf64-x86-64       Disassembly of section .init:       0000000000400390 <_init>:       400390:       48 83 ec 08             sub    $0x8,%rsp

Currently using imx6ul board with yocto build system, My requirement is to copy files from windows PC to Linux devices using USB cable, Please help me on how to copy files and which software using for this requirement in windows PC and Linux board.

Regards,Nk

I enter these command on i.Mx6Q (Buildroot) with qt5

# export QT_QPA_EGLFS_INTEGRATION=eglfs_viv# CinematicExperience-demo -platform eglfs

The demo app run normally, but it shows:

qt.qpa.egldeviceintegration: Failed to load EGL device integration "eglfs_viv"

I found this said this error means I don't have graphics acceleration on your board.

And this said that I need to turn on

kernel-module-imx-gpu-vivlibgles2-mx6libegl-mx6

Finally, I found this said the kernel version have to from 3.10.x to 4.1.x.So I change it to 4.1.15 like this in menuconfig (original version is 4.14.14):

Kernel version (Custom Git repository)(git://git.freescale.com/imx/linux-imx.git)URL of custom repository(rel_imx_4.1.15_2.0.0_ga)Custom repository version(imx_v7_mfg)Defconfig name(board/freescale/imx6-sabresd/linux_qt5.fragment)Additional configuration fragment filesKernel binary format(zImage)[*]Build a Device Tree Blob(DTB)(imx6q-sabresd)Device Tree Source file names

It compile successfully, but when I deploy on SD Card and try to run QT demo it shows:

qt.qpa.egldeviceintegration: Failed to load EGL device integration "eglfs_viv"MESA-LOADER: failed to retrieve device informationgbm: failed to open any driver (search paths /usr/lib/dri)gbm: Last dlopen error: File not foundfailed to load driver: vivantedrmModeGetResources failedSegmentation fault

Questions:

How to turn on graphics acceleration on i.Mx6Q (Buildroot)?Does turn on 'kernel-module-imx-gpu-viv' is the right step? If it's right, than how to set the kernel to lower version to run QT demo successfully?

In the /proc directory a custom module should create two directories lkm and mem to get a hierarchy like /proc/lkm/mem.

A simple refactoring now broke what was working without obvious reason.

After the refactoring the module is not creating the hierarchy /proc/lkm/mem anymore. It only creates lkm and then stops. There're no messages in the Kernel Ring Buffer. I was wondering what did I break with that refactoring? I hope you can help me finding the issue.

Manual tests have been run with a fresh started VM and with usual insmod/rmmod and following versions:

• Kernel: 5.3.0 (x86_64)
• GCC: 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
• Distribution: Ubuntu 19.10, eoan

In the following you can see the original and the refactored code. At the bottom I put the a minimum source file and the Makefile. There is also a repository, an issue and the breaking commit. Of course I could revert that commit, but other refactorings are coming and I want to know the reason, before I break something similar.

Thanks in advance :)

Original code prior to refactoring

static int __init lkm_mem_init(void){    lkm_proc_parent = proc_mkdir(LKM_PROC_PARENT, NULL);    if (lkm_proc_parent == NULL) {        printk(KERN_ERR "lkm_mem: Failed to create parent /proc/%s for lkm.\n",        LKM_PROC_PARENT);        return 1;    }    mem_proc_parent = proc_mkdir(LKM_MEM_PROC_PARENT, lkm_proc_parent);    if (mem_proc_parent == NULL) {        printk(KERN_ERR"lkm_mem: Failed to create parent /proc/%s/%s for mem.\n",        LKM_PROC_PARENT, LKM_MEM_PROC_PARENT);        return 1;    }    // ...}

Refactored code

static int __init lkm_mem_init(void){    lkm_proc_mkdir(lkm_proc_parent, LKM_PROC_PARENT, NULL);    lkm_proc_mkdir(mem_proc_parent, LKM_MEM_PROC_PARENT, lkm_proc_parent);    // ...}void lkm_proc_mkdir(struct proc_dir_entry *entry, const char *name,            struct proc_dir_entry *parent){    entry = proc_mkdir(name, parent);    if (entry == NULL) {        printk(KERN_ERR"lkm_mem: Failed to create parent %s in proc.\n",               name);        // todo: How to abort loading module in gentle way?    }}// ...

Minimum source code

#include <linux/init.h>#include <linux/kernel.h>#include <linux/mm.h>#include <linux/module.h>#include <linux/proc_fs.h>#include <linux/seq_file.h>MODULE_LICENSE("GPL");MODULE_AUTHOR("Thomas Piekarski");MODULE_DESCRIPTION("Exposing separated memory and swap statistics to /proc");MODULE_VERSION("0.1");#define LKM_PROC_PERMISSION 0444#define LKM_PROC_PARENT "lkm"#define LKM_MEM_PROC_PARENT "mem"#define LKM_MEM_PROC_TOTAL_ENTRY "total"#define LKM_MEM_PROC_FREE_ENTRY "free"struct sysinfo si;struct proc_dir_entry *lkm_proc_parent;struct proc_dir_entry *mem_proc_parent;struct proc_dir_entry *mem_proc_total_entry;struct proc_dir_entry *mem_proc_free_entry;static int lkm_value_show(struct seq_file *seq, void *v){    seq_put_decimal_ull(seq, "", *(unsigned long *)seq->private);    seq_putc(seq, '\n');    return 0;}void lkm_proc_create_single_data(struct proc_dir_entry *entry,                 unsigned long *value, const char *name){    entry = proc_create_single_data(name, LKM_PROC_PERMISSION,                    mem_proc_parent, lkm_value_show, value);    if (entry == NULL) {        printk(KERN_ERR "lkm_mem: Failed to create /proc/%s/%s/%s.\n",               LKM_PROC_PARENT, LKM_MEM_PROC_PARENT, name);    }}void lkm_proc_mkdir(struct proc_dir_entry *entry, const char *name,            struct proc_dir_entry *parent){    entry = proc_mkdir(name, parent);    if (entry == NULL) {        printk(KERN_ERR"lkm_mem: Failed to create parent %s in proc.\n",               name);    }}void lkm_remove_proc_entry(struct proc_dir_entry *entry, const char *name,               struct proc_dir_entry *parent){    if (entry != NULL) {        remove_proc_entry(name, parent);    }}static int __init lkm_mem_init(void){    lkm_proc_mkdir(lkm_proc_parent, LKM_PROC_PARENT, NULL);    lkm_proc_mkdir(mem_proc_parent, LKM_MEM_PROC_PARENT, lkm_proc_parent);    si_meminfo(&si);    lkm_proc_create_single_data(mem_proc_total_entry, &si.totalram,                    LKM_MEM_PROC_TOTAL_ENTRY);    lkm_proc_create_single_data(mem_proc_free_entry, &si.freeram,                    LKM_MEM_PROC_FREE_ENTRY);    return 0;}static void __exit lkm_mem_exit(void){    lkm_remove_proc_entry(mem_proc_total_entry, LKM_MEM_PROC_TOTAL_ENTRY,                  mem_proc_parent);    lkm_remove_proc_entry(mem_proc_free_entry, LKM_MEM_PROC_FREE_ENTRY,                  mem_proc_parent);    lkm_remove_proc_entry(mem_proc_parent, LKM_MEM_PROC_PARENT,                  lkm_proc_parent);    lkm_remove_proc_entry(lkm_proc_parent, LKM_PROC_PARENT, NULL);}module_init(lkm_mem_init);module_exit(lkm_mem_exit);

Makefile

ccflags-y := -Wallobj-m += lkm_device.o lkm_mem.o lkm_parameters.o lkm_proc.o lkm_sandbox.o lkm_skeleton.oall:    $(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) modulesclean:    $(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Edits - Added URLs to repository, issue and commit