May 2020 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

How to make /dev/ttyACM0 (and friends) exclusive?
by Jeffrey Walton Oct. 11, 2020

Oct. 11, 2020

Hi Everyone, I'm trying to trackdown a problem using my dialup modem. I have a program that opens the modem and watches caller id's. It flashes the hook when a telemarketer calls. It works well until... When another program opens the modem then my program starts reading intermittent responses intended for the other program. I cannot seem to open the device in exclusive mode. The current open is (I also tried with O_EXCL): int modem = open(device_path, O_RDWR | O_NOCTTY | O_SYNC); I'm not sure if it because udev configures the device incorrectly or the kernel driver is configured incorrectly. Or maybe it is impossible to do. Does anyone know how I can make the device exclusive? Thanks in advance.

6 12

Computing resources required for kernel development
by Harsh chopra May 31, 2020

May 31, 2020

Hi everyone, I have been following the Kernel Hacking steps to submit my first patch but I am facing problem in the kernel compilation as its taking more than a day may be due to low computing resources.. I have Ubuntu 20.04 LTS with 4GB DDR3 ram 1 TB HDD, Intel i3 2.GHZ and 4 cores but I have been using virt-manager for the kernel development with CentOS 8.1 (minimal req.) and resources 70 GB storage, 2 GB ram and 2 cores. Thus if anyone could suggest how much computing power to have or any other method so that I could make my development process smooth.

4 4

Re: sdhci_msm issues with cold-plugged SD cards
by Ulf Hansson May 27, 2020

May 27, 2020

+ Bjorn, Sarthak, Veerabhadrarao On Fri, 22 May 2020 at 17:51, Iskren Chernev <iskren.chernev(a)gmail.com> wrote: > > > Hello, > > I'm trying to add SD Card support to a smartphone (Samsung Galaxy S5). After > configuring the sdhci-msm driver through DT, it all seems to work fine except > the case when the phone boots with the SD card inserted. If the card is > re-inserted, or the driver is polling, or the probe code is forcefully executed > a second time the card is properly detected. > > I logged the SD interrupts, commands and responses, and it looks like the > hardware is returning Command Index Error and/or Command End Bit Error via the > Error Interrupt Status Register, which gets converted to -EILSEQ error. On > a second attempt (due to re-insertion, polling or re-execution) these errors > are missing, and the card behaves correctly. > > On the downstream kernel, these errors resulting in EILSEQ do not appear, so it > might be related to setup. Also I see that sdhci-msm driver has hardcoded > a SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk, which might imply that polling > should be used (instead Card Detection GPIO), in which case this issue won't > manifest itself. But polling wastes power, and the Card Detect pin works well, > at least for this device, so I feel it can be made better. > > Any suggestions on how to track this down are appreciated! I think the device is intended to be used with GPIO card detection. Polling mode shouldn't be needed if there is GPIO. Anyway, to me it sounds like the HW/controller isn't properly initialized during ->probe(), but I can't help you much more than that. I have looped in some of the recent active sdhci-msm developers to see if they have some ideas that we can try. Kind regards Uffe

3 2

How to find the wait_queue of a task in TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE state
by William Tambe May 22, 2020

May 22, 2020

How to find the wait_queue of a task in TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE state ?

1 0

sdhci_msm issues with cold-plugged SD cards
by Iskren Chernev May 22, 2020

May 22, 2020

Hello, I'm trying to add SD Card support to a smartphone (Samsung Galaxy S5). After configuring the sdhci-msm driver through DT, it all seems to work fine except the case when the phone boots with the SD card inserted. If the card is re-inserted, or the driver is polling, or the probe code is forcefully executed a second time the card is properly detected. I logged the SD interrupts, commands and responses, and it looks like the hardware is returning Command Index Error and/or Command End Bit Error via the Error Interrupt Status Register, which gets converted to -EILSEQ error. On a second attempt (due to re-insertion, polling or re-execution) these errors are missing, and the card behaves correctly. On the downstream kernel, these errors resulting in EILSEQ do not appear, so it might be related to setup. Also I see that sdhci-msm driver has hardcoded a SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk, which might imply that polling should be used (instead Card Detection GPIO), in which case this issue won't manifest itself. But polling wastes power, and the Card Detect pin works well, at least for this device, so I feel it can be made better. Any suggestions on how to track this down are appreciated! Regards, Iskren Chernev

1 0

__STDC_VERSION__ : What C dialect c89, c99,gnu90 kernel compiies
by Lev R. Oshvang . May 20, 2020

May 20, 2020

Hi All, I am building out of tree kernel module. I am trying to include user-space lib into kernel module This API gives me the following warning : "__STDC_VERSION__" is not defined, evaluates to 0 But continues and resulted module works, I see from https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html that _STDC_VERSION__ is a built-in gcc macro, so I think that evenh kernel compilation should be able to see it. Please comment Lev.

3 2

Check for preemption only when returning from interrupt ?
by Taeung Song May 20, 2020

May 20, 2020

Hi, After reading arch/x86/entry/entry_64.S I think preemption is checked only when returning from interrupt (not exception like syscall) Is is right ? (based on x86) All scenario of checking for preemption in my opinion: (1) check kernel preemption after interrupt https://github.com/torvalds/linux/blob/master/arch/x86/entry/entry_64.S#L672 (2) check user preemption after interrupt https://github.com/torvalds/linux/blob/master/arch/x86/entry/entry_64.S#L620 prepare_exit_to_usermode() -> exit_to_usermode_loop() -> if (cached_flags & _TIF_NEED_RESCHED) schedule(); Thanks, Taeung

1 0

Estimating total memory usage in any Linux system
by Pintu Agarwal May 20, 2020

May 20, 2020

Hi, I was just trying to manually calculate the total memory available in a system to match up the MemTotal shown in /proc/meminfo I know "free -m" command will give the vary high level usage, but I wanted to breakdown the MemTotal numbers to see usage in each category. I am looking for a common formula that should match on almost all systems. So, I came up with below fields from meminfo to closely match the total. ~Total = {MemFree + Active + Inactive + Shmem + Mapped + Slab + KernelStack + PageTables + (init freed) + (Boot Diff) + (low watermarks)} But I am not sure if these fields are correct at least for arm32 system. In some boards I could able to match up these figures, but some not. So I have some doubts: * Is "Mapped" (NR_MAPPED_PAGES) already part of Active pages ? * Is Kernel allocation (alloc_pages, etc.) accounted somewhere ? Is it part of Anon pages ? * What about vmalloc / ioremap pages ? Do we also need to consider VmallocUsed ? ==> In my opinion vmalloc internally used kmalloc and page tables, so I guess it should be already part of Slab or PageTables ?? Below are some data taken from a small embedded arm32 device with 512MB RAM: Kernel Boot Logs: Memory: 99244K/254976K available (10720K kernel code, 1336K rwdata, 4792K rodata, 400K init, 1602K bss, 135252K reserved, 20480K cma-reserved) Total = 99244 + 400 (init) + 20480 (cma) = 120124 Boot Diff = 121204 - 120124 => 1080 kB MemTotal: 121204 kB MemFree: 2540 kB MemAvailable: 51924 kB Buffers: 0 kB Cached: 47492 kB SwapCached: 0 kB Active: 42604 kB Inactive: 24308 kB Active(anon): 19476 kB Inactive(anon): 92 kB Active(file): 23128 kB Inactive(file): 24216 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 8 kB Writeback: 0 kB AnonPages: 19452 kB Mapped: 12644 kB Shmem: 148 kB Slab: 27560 kB SReclaimable: 7224 kB SUnreclaim: 20336 kB KernelStack: 3104 kB PageTables: 1896 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 60600 kB Committed_AS: 1576740 kB VmallocTotal: 777216 kB VmallocUsed: 53696 kB VmallocChunk: 689148 kB -------------------- These are my calculations from the above fields. --------------------- MemFree 2540 Active 42604 Inactive 24308 Mapped 12644 Slab 27560 KernelStack 3104 PageTables 1896 Shmem 148 init freed 400 Diff from boot total 1080 min_free_kbytes 1384 user_reserve_kbytes 3537 My Total ==> 121205 (add all the above) As you can see "My Total" closely matches with the MemTotal from /proc/meminfo But on some systems it does not match. So, I wanted to understand if there is something wrong in my calculation, or there is something wrong in the system itself (like leaks etc,) Note: I don't want to use any tools or utilize for these, but I wanted to manually understand it. I am also trying to explore every vm counter that populates these fields. But if you have any other opinion about it please let me know. Thanks, Pintu

2 5

Crash dump?
by Subhashini Rao Beerisetty May 19, 2020

May 19, 2020

Hi all, In Kernel, what needs to be configured to get the crash dump? Can someone clarify me with the sequence of steps to get the crash dump.. Thanks,

3 2

general protection fault vs Oops
by Subhashini Rao Beerisetty May 18, 2020

May 18, 2020

Hi all, In my Linux box, I see that kernel crashes for a known test case. In the first attempt when I run that test case I landed into “general protection fault: 0000 [#1] SMP" .. Next I rebooted and ran the same test , but now it resulted the “Oops: 0002 [#1] SMP". In both cases the call trace looks exactly same and RIP points to “native_queued_spin_lock_slowpath+0xfe/0x170".. So, can some one clarify me , what are the difference between “general protection fault: 0000 [#1] SMP" & “Oops: 0002 [#1] SMP". In which scenario kernel throws “Oops: 0002 [#1] SMP" Or “general protection fault: 0000 [#1] SMP".. May 16 12:06:17 test-pc kernel: [96934.528114] general protection fault: 0000 [#1] SMP May 16 12:06:17 test-pc kernel: [96934.528990] Modules linked in: dbg(OE) mcore(OE) osa(OE) cfg80211 ppdev intel_rapl intel_soc_dts_iosf intel_powerclamp coretemp kvm irqbypass punit_atom_debug cdc_acm mei_txe mei lpc_ich shpchp parport_pc mac_hid parport tpm_infineon 8250_fintek ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel i915 aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd igb drm_kms_helper dca syscopyarea ptp sysfillrect sysimgblt pps_core fb_sys_fops i2c_algo_bit drm ahci libahci fjes video [last unloaded: osa] May 16 12:06:17 test-pc kernel: [96934.537343] CPU: 2 PID: 5457 Comm: multi/complete Tainted: G OE 4.4.0-66-generic #87-Ubuntu May 16 12:06:17 test-pc kernel: [96934.538715] Hardware name: Supermicro Super Server/X10SDV-TLN4F, BIOS 1.0b 09/09/2015 May 16 12:06:17 test-pc kernel: [96934.540146] task: ffff880139d02640 ti: ffff880034fe0000 task.ti: ffff880034fe0000 May 16 12:06:17 test-pc kernel: [96934.541632] RIP: 0010:[<ffffffff810cafee>] [<ffffffff810cafee>] native_queued_spin_lock_slowpath+0xfe/0x170 May 16 12:06:17 test-pc kernel: [96934.543224] RSP: 0018:ffff880034fe3e08 EFLAGS: 00010002 May 16 12:06:17 test-pc kernel: [96934.544837] RAX: 0000000000002be1 RBX: 0000000000000082 RCX: 0004b8107b8cc138 May 16 12:06:17 test-pc kernel: [96934.546511] RDX: ffff88013fd17900 RSI: 00000000000c0000 RDI: ffff8800b35fbb88 May 16 12:06:17 test-pc kernel: [96934.548213] RBP: ffff880034fe3e08 R08: 0000000000000101 R09: 0000000180200019 May 16 12:06:17 test-pc kernel: [96934.549949] R10: ffff8800340c9680 R11: 0000000000000001 R12: ffff8800b35fbb88 May 16 12:06:17 test-pc kernel: [96934.551713] R13: 0000000000000246 R14: 0000000000000001 R15: ffff8800340c9d00 May 16 12:06:17 test-pc kernel: [96934.553501] FS: 0000000000000000(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000 May 16 12:06:17 test-pc kernel: [96934.555346] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b May 16 12:06:17 test-pc kernel: [96934.557216] CR2: 00007ffe8614d938 CR3: 00000000b35ef000 CR4: 00000000001006e0 May 16 12:06:17 test-pc kernel: [96934.559146] Stack: May 16 12:06:17 test-pc kernel: [96934.561081] ffff880034fe3e20 ffffffff8183c427 ffff8800b35fbb70 ffff880034fe3e50 May 16 12:06:17 test-pc kernel: [96934.563133] ffffffffc0606812 ffff880035581cc0 ffff8800b1eb5ec8 0000000000000246 May 16 12:06:17 test-pc kernel: [96934.565220] ffff8800b1eb5ef0 ffff880034fe3e60 ffffffffc06aa2a4 ffff880034fe3ea May 16 12:06:17 test-pc kernel: [96934.567347] Call Trace: May 16 12:06:17 test-pc kernel: [96934.569475] [<ffffffff8183c427>] _raw_spin_lock_irqsave+0x37/0x40 May 16 12:06:17 test-pc kernel: [96934.571686] [<ffffffffc0606812>] event_raise+0x22/0x60 [osa] May 16 12:06:17 test-pc kernel: [96934.573935] [<ffffffffc06aa2a4>] multi_q_completed_one_buffer+0x34/0x40 [mcore] May 16 12:06:17 test-pc kernel: [96934.576236] [<ffffffffc06a919e>] complete_thread+0x7e/0x110 [mcore] May 16 12:06:17 test-pc kernel: [96934.578567] [<ffffffffc0606a10>] ? thread_should_stop+0x10/0x10 [osa] May 16 12:06:17 test-pc kernel: [96934.580934] [<ffffffffc0606a26>] thread_func+0x16/0x50 [osa] May 16 12:06:17 test-pc kernel: [96934.583326] [<ffffffffc0606a10>] ? thread_should_stop+0x10/0x10 [osa] May 16 12:06:17 test-pc kernel: [96934.585762] [<ffffffff810a0ba8>] kthread+0xd8/0xf0 May 16 12:06:17 test-pc kernel: [96934.588219] [<ffffffff810a0ad0>] ? kthread_create_on_node+0x1e0/0x1e0 May 16 12:06:17 test-pc kernel: [96934.590724] [<ffffffff8183c98f>] ret_from_fork+0x3f/0x70 May 16 12:06:17 test-pc kernel: [96934.593251] [<ffffffff810a0ad0>] ? kthread_create_on_node+0x1e0/0x1e0 May 16 12:06:17 test-pc kernel: [96934.595822] Code: 87 47 02 c1 e0 10 85 c0 74 38 48 89 c1 c1 e8 12 48 c1 e9 0c 83 e8 01 83 e1 30 48 98 48 81 c1 00 79 01 00 48 03 0c c5 40 75 f3 81 <48> 89 11 8b 42 08 85 c0 75 0d f3 90 8b 42 08 85 c0 74 f7 eb 02 May 16 12:06:17 test-pc kernel: [96934.601479] RIP [<ffffffff810cafee>] native_queued_spin_lock_slowpath+0xfe/0x17 May 16 12:06:17 test-pc kernel: [96934.604306] RSP <ffff880034fe3e08> May 16 12:06:17 test-pc kernel: [96934.617229] ---[ end trace 0b60bd63d72bdffa ]--- May 16 12:59:22 test-pc kernel: [ 3011.360710] BUG: unable to handle kernel paging request at 0000000000017900 May 16 12:59:22 test-pc kernel: [ 3011.361623] IP: [<ffffffff810cafee>] native_queued_spin_lock_slowpath+0xfe/0x170 May 16 12:59:22 test-pc kernel: [ 3011.362547] PGD May 16 12:59:22 test-pc kernel: [ 3011.363419] Oops: 0002 [#1] SMP May 16 12:59:22 test-pc kernel: [ 3011.364298] Modules linked in: dbg(OE) mcore(OE) osa(OE) cfg80211 ppdev intel_rapl intel_soc_dts_iosf intel_powerclamp coretemp kvm irqbypass punit_atom_debug cdc_acm mei_txe mei lpc_ich shpchp parport_pc mac_hid parport tpm_infineon 8250_fintek ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel i915 aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd igb drm_kms_helper dca syscopyarea ptp sysfillrect sysimgblt pps_core fb_sys_fops i2c_algo_bit drm ahci libahci fjes video [last unloaded: osa] May 16 12:59:22 test-pc kernel: [ 3011.373097] CPU: 1 PID: 4103 Comm: multi/complete Tainted: G OE 4.4.0-66-generic #87-Ubunt May 16 12:59:22 test-pc kernel: [ 3011.374622] Hardware name: Supermicro Super Server/X10SDV-TLN4F, BIOS 1.0b 09/09/2015 May 16 12:59:22 test-pc kernel: [ 3011.376203] task: ffff8800b3b972c0 ti: ffff8800b1cb0000 task.ti: ffff8800b1cb0000 May 16 12:59:22 test-pc kernel: [ 3011.377825] RIP: 0010:[<ffffffff810cafee>] [<ffffffff810cafee>] native_queued_spin_lock_slowpath+0xfe/0x170 May 16 12:59:22 test-pc kernel: [ 3011.379575] RSP: 0018:ffff8800b1cb3e08 EFLAGS: 00010006 May 16 12:59:22 test-pc kernel: [ 3011.381324] RAX: 0000000000000e8c RBX: 0000000000000082 RCX: 000000000001790 May 16 12:59:22 test-pc kernel: [ 3011.383141] RDX: ffff88013fc97900 RSI: 0000000000080000 RDI: ffff88013a347b88 May 16 12:59:22 test-pc kernel: [ 3011.384997] RBP: ffff8800b1cb3e08 R08: 0000000000000101 R09: 0000000180200003 May 16 12:59:22 test-pc kernel: [ 3011.386878] R10: ffff880034fb4580 R11: 0000000000000001 R12: ffff88013a347b88 May 16 12:59:22 test-pc kernel: [ 3011.388792] R13: 0000000000000246 R14: 0000000000000001 R15: ffff880034fb4100 May 16 12:59:22 test-pc kernel: [ 3011.390726] FS: 0000000000000000(0000) GS:ffff88013fc80000(0000) knlGS:0000000000000000 May 16 12:59:22 test-pc kernel: [ 3011.392722] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b May 16 12:59:22 test-pc kernel: [ 3011.394738] CR2: 0000000000017900 CR3: 0000000001e0a000 CR4: 00000000001006e0 May 16 12:59:22 test-pc kernel: [ 3011.396819] Stack: May 16 12:59:22 test-pc kernel: [ 3011.398896] ffff8800b1cb3e20 ffffffff8183c427 ffff88013a347b70 ffff8800b1cb3e50 May 16 12:59:22 test-pc kernel: [ 3011.401093] ffffffffc0604812 ffff8800b49f46c0 ffff880034a238c8 0000000000000246 May 16 12:59:22 test-pc kernel: [ 3011.403327] ffff880034a238f0 ffff8800b1cb3e60 ffffffffc06b72a4 ffff8800b1cb3ea8 May 16 12:59:22 test-pc kernel: [ 3011.405602] Call Trace: May 16 12:59:22 test-pc kernel: [ 3011.407892] [<ffffffff8183c427>] _raw_spin_lock_irqsave+0x37/0x40 May 16 12:59:22 test-pc kernel: [ 3011.410256] [<ffffffffc0604812>] event_raise+0x22/0x60 [osa] May 16 12:59:22 test-pc kernel: [ 3011.412652] [<ffffffffc06b72a4>] multi_q_completed_one_buffer+0x34/0x40 [mcore] May 16 12:59:22 test-pc kernel: [ 3011.415103] [<ffffffffc06b619e>] complete_thread+0x7e/0x110 [mcore] May 16 12:59:22 test-pc kernel: [ 3011.417584] [<ffffffffc0604a10>] ? thread_should_stop+0x10/0x10 [osa] May 16 12:59:22 test-pc kernel: [ 3011.420113] [<ffffffffc0604a26>] thread_func+0x16/0x50 [osa May 16 12:59:22 test-pc kernel: [ 3011.422654] [<ffffffffc0604a10>] ? thread_should_stop+0x10/0x10 [osa] May 16 12:59:22 test-pc kernel: [ 3011.425241] [<ffffffff810a0ba8>] kthread+0xd8/0xf0 May 16 12:59:22 test-pc kernel: [ 3011.427857] [<ffffffff810a0ad0>] ? kthread_create_on_node+0x1e0/0x1e0 May 16 12:59:22 test-pc kernel: [ 3011.430511] [<ffffffff8183c98f>] ret_from_fork+0x3f/0x70 May 16 12:59:22 test-pc kernel: [ 3011.433185] [<ffffffff810a0ad0>] ? kthread_create_on_node+0x1e0/0x1e0 May 16 12:59:22 test-pc kernel: [ 3011.435915] Code: 87 47 02 c1 e0 10 85 c0 74 38 48 89 c1 c1 e8 12 48 c1 e9 0c 83 e8 01 83 e1 30 48 98 48 81 c1 00 79 01 00 48 03 0c c5 40 75 f3 81 <48> 89 11 8b 42 08 85 c0 75 0d f3 90 8b 42 08 85 c0 74 f7 eb 02 May 16 12:59:22 test-pc kernel: [ 3011.441870] RIP [<ffffffff810cafee>] native_queued_spin_lock_slowpath+0xfe/0x170 May 16 12:59:22 test-pc kernel: [ 3011.444858] RSP <ffff8800b1cb3e08> May 16 12:59:22 test-pc kernel: [ 3011.447817] CR2: 000000000001790 May 16 12:59:22 test-pc kernel: [ 3011.460906] ---[ end trace 0337c6fc94b1cb3d ]--- Thanks

4 6