- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

uart throughput
by Muni Sekhar April 6, 2018

April 6, 2018

Hi All, I’ve an uart hardware implemented on Xilinx FPGA image and it connects to host CPU(Intel based chip) on PCIe bus in Linux platform. The following parameters were fixed or varied when measuring the UART throughput in internal loopback mode(UART_RX and UART_TX pins were internally connected): • Uart baud rate • Parity Bit • Stop Bit(s) The primary factor affecting UART throughput is the baud rate, apart from this any other factors affect the UART throughput? For 4000000 bps uart baud rate, what should be the theoretical peak data throughput? -- Thanks, Sekhar

3 2

[sparc64] number of processors in a LDOM
by Anatoly Pugachev April 5, 2018

April 5, 2018

Hello! Can someone tell me or suggest why does getconf returns total available to a physical machine cpu count, and not LDOM allocated processor/vcpu count ? ttip$ getconf -a | grep PROCESSORS _NPROCESSORS_CONF 256 _NPROCESSORS_ONLN 16 i believe, nproc (from coreutils) use getconf as well : ttip$ nproc --all 256 ttip$ nproc 16 But this LDOM is defined as following (16 vcpus allocated): # ldm list NAME STATE FLAGS CONS VCPU MEMORY UTIL NORM UPTIME ttip active -n---- 5004 16 32G 0.0% 0.0% 3h 1m Just to compare, if we take power systems (ppc64) LPAR, it reports only LPAR allocated CPU count (not physical machine available cpu/core count). I'm raising this issue, because some userspace tools use nproc to run parallel make for example. And starting from 4.15+ (but not on 4.14) kernel overcommited CPU usage (for example, using make -j256 on a LDOM with 16 vcpus allocated) gets me to the following (reproducible): Message from syslogd@ttip at Apr 3 14:53:15 ... kernel:[ 942.850499] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 36s! Apr 03 14:53:15 ttip kernel: BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 36s! Apr 03 14:53:15 ttip kernel: Showing busy workqueues and worker pools: Apr 03 14:53:15 ttip kernel: workqueue mm_percpu_wq: flags=0x8 Apr 03 14:53:15 ttip kernel: pwq 16: cpus=8 node=0 flags=0x0 nice=0 active=1/256 Apr 03 14:53:15 ttip kernel: pending: vmstat_update Apr 03 14:53:15 ttip kernel: workqueue xfs-sync/dm-0: flags=0x4 Apr 03 14:53:15 ttip kernel: pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 Apr 03 14:53:15 ttip kernel: pending: xfs_log_worker [xfs] ^C Message from syslogd@ttip at Apr 3 14:53:45 ... kernel:[ 972.929725] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 66s! Message from syslogd@ttip at Apr 3 14:54:15 ... kernel:[ 1003.008979] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 96s! Message from syslogd@ttip at Apr 3 14:54:46 ... kernel:[ 1033.088189] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 126s! Message from syslogd@ttip at Apr 3 14:55:16 ... kernel:[ 1063.166574] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 156s! Message from syslogd@ttip at Apr 3 14:55:46 ... kernel:[ 1093.244982] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 186s! This messages occasionally lead to machine/LDOM being unstable, i.e. with some lockups to processes. filtered dmesg output: ttip$ dmesg | egrep -i "cpu|smp" [ 0.000073] Linux version 4.16.0-05456-g17dec0a94915 (mator@ttip) (gcc version 7.3.0 (Debian 7.3.0-14)) #659 SMP Wed Apr 4 12:16:32 MSK 2018 [ 0.037199] PLATFORM: max-cpus [1024] [ 0.194415] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32] [ 0.194525] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit,fmaf,vis3] [ 0.194630] CPU CAPS: [hpc,ima,pause,cbcond,aes,des,kasumi,camellia] [ 0.194731] CPU CAPS: [md5,sha1,sha256,sha512,mpmul,montmul,montsqr,crc32c] [ 0.237948] percpu: Embedded 12 pages/cpu @ (ptrval) s56584 r8192 d33528 u131072 [ 0.238199] pcpu-alloc: s56584 r8192 d33528 u131072 alloc=1*4194304 [ 0.238209] pcpu-alloc: [0] 000 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 [ 0.238363] pcpu-alloc: [0] 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 062 063 [ 0.238515] pcpu-alloc: [0] 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 [ 0.238668] pcpu-alloc: [0] 096 097 098 099 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 [ 0.238820] pcpu-alloc: [0] 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 [ 0.238973] pcpu-alloc: [0] 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 [ 0.239125] pcpu-alloc: [0] 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 [ 0.239278] pcpu-alloc: [0] 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 [ 0.239873] SUN4V: Mondo queue sizes [cpu(131072) dev(16384) r(8192) nr(256)] [ 0.242373] log_buf_len individual max cpu contribution: 4096 bytes [ 0.242438] log_buf_len total cpu_extra contributions: 1044480 bytes [ 0.516414] smp: Bringing up secondary CPUs ... [ 0.548006] smp: Brought up 1 node, 16 CPUs

2 1

specifying in the kernel command line
by Kevin Wilson April 4, 2018

April 4, 2018

Hello, I have an x86_64 host with 4GB of Physical RAM running Fedora 25. I have a question about hugepages allocation on this host. In: https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt I see that you can use "hugepages=N" kernel parameter (in grub) for specifying the number of hugepages you want to allocate at boot time. The default hugepage size on this host is 2MB. For example, I am thinking of using hugepagesz=2MB hugepages=4096 in the kernel command line. So my question is: How it the number of hugepages related to the physical memory ? or more specifically, I want to allocate 4096 2MB pages on this host which has 4 GB physical RAM. Is it possible at all ? because 4096*2 gives 8192MB, which is about 8GB, and if it is about the full size of the physical memory on this host. I doubt whether the host can boot at all with such a command line ? Or is this calculation is not related to the physical memory but to virtual memory ? Regards, Kevin

2 1

[sparc64] number of processors in a LDOM
by Anatoly Pugachev April 4, 2018

April 4, 2018

Hello! Can someone tell me or suggest why does getconf returns total available to a physical machine cpu count, and not LDOM allocated processor/vcpu count ? ttip$ getconf -a | grep PROCESSORS _NPROCESSORS_CONF 256 _NPROCESSORS_ONLN 16 i believe, nproc (from coreutils) use getconf as well : ttip$ nproc --all 256 ttip$ nproc 16 But this LDOM is defined as following (16 vcpus allocated): # ldm list NAME STATE FLAGS CONS VCPU MEMORY UTIL NORM UPTIME ttip active -n---- 5004 16 32G 0.0% 0.0% 3h 1m Just to compare, if we take power systems (ppc64) LPAR, it reports only LPAR allocated CPU count (not physical machine available cpu/core count). I'm raising this issue, because some userspace tools use nproc to run parallel make for example. And starting from 4.15+ (but not on 4.14) kernel overcommited CPU usage (for example, using make -j256 on a LDOM with 16 vcpus allocated) gets me to the following (reproducible): Message from syslogd@ttip at Apr 3 14:53:15 ... kernel:[ 942.850499] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 36s! Apr 03 14:53:15 ttip kernel: BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 36s! Apr 03 14:53:15 ttip kernel: Showing busy workqueues and worker pools: Apr 03 14:53:15 ttip kernel: workqueue mm_percpu_wq: flags=0x8 Apr 03 14:53:15 ttip kernel: pwq 16: cpus=8 node=0 flags=0x0 nice=0 active=1/256 Apr 03 14:53:15 ttip kernel: pending: vmstat_update Apr 03 14:53:15 ttip kernel: workqueue xfs-sync/dm-0: flags=0x4 Apr 03 14:53:15 ttip kernel: pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 Apr 03 14:53:15 ttip kernel: pending: xfs_log_worker [xfs] ^C Message from syslogd@ttip at Apr 3 14:53:45 ... kernel:[ 972.929725] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 66s! Message from syslogd@ttip at Apr 3 14:54:15 ... kernel:[ 1003.008979] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 96s! Message from syslogd@ttip at Apr 3 14:54:46 ... kernel:[ 1033.088189] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 126s! Message from syslogd@ttip at Apr 3 14:55:16 ... kernel:[ 1063.166574] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 156s! Message from syslogd@ttip at Apr 3 14:55:46 ... kernel:[ 1093.244982] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0 nice=0 stuck for 186s! This messages occasionally lead to machine/LDOM being unstable, i.e. with some lockups to processes. filtered dmesg output: ttip$ dmesg | egrep -i "cpu|smp" [ 0.000073] Linux version 4.16.0-05456-g17dec0a94915 (mator@ttip) (gcc version 7.3.0 (Debian 7.3.0-14)) #659 SMP Wed Apr 4 12:16:32 MSK 2018 [ 0.037199] PLATFORM: max-cpus [1024] [ 0.194415] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32] [ 0.194525] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit,fmaf,vis3] [ 0.194630] CPU CAPS: [hpc,ima,pause,cbcond,aes,des,kasumi,camellia] [ 0.194731] CPU CAPS: [md5,sha1,sha256,sha512,mpmul,montmul,montsqr,crc32c] [ 0.237948] percpu: Embedded 12 pages/cpu @ (ptrval) s56584 r8192 d33528 u131072 [ 0.238199] pcpu-alloc: s56584 r8192 d33528 u131072 alloc=1*4194304 [ 0.238209] pcpu-alloc: [0] 000 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 [ 0.238363] pcpu-alloc: [0] 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 062 063 [ 0.238515] pcpu-alloc: [0] 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 [ 0.238668] pcpu-alloc: [0] 096 097 098 099 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 [ 0.238820] pcpu-alloc: [0] 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 [ 0.238973] pcpu-alloc: [0] 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 [ 0.239125] pcpu-alloc: [0] 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 [ 0.239278] pcpu-alloc: [0] 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 [ 0.239873] SUN4V: Mondo queue sizes [cpu(131072) dev(16384) r(8192) nr(256)] [ 0.242373] log_buf_len individual max cpu contribution: 4096 bytes [ 0.242438] log_buf_len total cpu_extra contributions: 1044480 bytes [ 0.516414] smp: Bringing up secondary CPUs ... [ 0.548006] smp: Brought up 1 node, 16 CPUs

1 0

LKCAMP - Linux Kernel Study Group - English subtitles
by Helen Fornazier April 3, 2018

April 3, 2018

Hi kernelnewbies community, First I would like to say thanks for your support helping answering questions from the LKCAMP group. We are recording the talks from our group, and I would like to inform that for those who don't speak Portuguese, we are have really awesome volunteers who wrote subtitles in English for the videos to facilitate remote participation (Thanks Lucas Magalhães and Andrew Chuang). So if you want to get started in Linux Kernel development, check out our study group: M1 - https://youtu.be/YKARS9Sz-Cc M2 - https://youtu.be/T4QNorHHkbk More information about the group: https://goo.gl/Y4zVUZ Regards Helen Koike -- LKCAMP is a Linux Kernel study group organized at University of Campinas (Unicamp) to help anyone to get started in kernel development. Meetings every Tuesday night at 19h GMT-3 (Sao Paulo Brazil). Live stream at the University YouTube channel: https://www.youtube.com/channel/UCraCE6iWUcFCJSp-vmO1D3A We don't grant that we will have the English subtitles as soon as the video is released (we are volunteers), but we are going to announce at the mailing list lkcamp(a)lists.libreplanetbr.org (most messages are in portuguese, sorry about that, if several people from all over the world start to participate we can change that). Instructions to subscribe at this list is written in the document above.

3 4

V4l2 Sensor driver and V4l2 ctrls
by MUHAMMED ASAD P T April 3, 2018

April 3, 2018

Hi All, In reference sensor drivers, they used the V4L2_CID_DV_RX_POWER_PRESENT v4l2 ctrl. It is a standard ctrl and created using v4l2_ctrl_new_std(). The doubts are: 1. Whether in our sensor driver, we need to create this Control Id or not. How to take the decision on this. Since this is the standard ctrl. When we need to use these standard ctrls?? 2. In Sensor driver, the ctrls creation is anything depends on the bridge driver. Based on bridge driver, whether we need to create any ctrls in Sensor driver. This question belongs to design of the sensor driver. Thanks & Regards - Asad IQ Root Technologies

2 2

Difference between atomic context and interrupt context.
by Madhu K April 2, 2018

April 2, 2018

Hi All, what is the difference between atomic context and interrupt context. are they both same? regards, Madhu

2 1

Set SO_TCP_NODELAY (disabling the Nagle Algorithm)
by Naruto Nguyen April 1, 2018

April 1, 2018

Hello everyone, As I know we have a socket option SO_TCP_NODELAY to disable Nagle Algorithm, and I found it is implemented in TCP/IP stack at https://elixir.bootlin.com/linux/v4.4.90/source/net/ipv4/tcp.c#L2401 . However, I do not know where the source code the Nagle Algorithm is implemented in kernel. If you know, could you please help me? Brs, Naruto

2 1

Why are the PAGE_SIZE and the physical page frame size different in x86_64 kernel?
by Hao Lee March 30, 2018

March 30, 2018

Hi, I'm confused about the meaning of the PAGE_SIZE macro in x86_64 kernel. Its value is 4KB and I once thought it was the size of a physical page frame, but now I think I'm wrong. I find that most of the physical address space is mapped by PMD entries, which means the actual physical page frame size is 2MB. Could someone explain why the PAGE_SIZE is not 2MB in x86_64 kernel? Thanks! Regards, Hao Lee

2 2

V4l2 Sensor driver and Bridge Driver
by MUHAMMED ASAD P T March 30, 2018

March 30, 2018

Hi All, Need to write the Sensor driver. I have the below doubts: 1. What are the dependencies between the bridge driver and Sensor driver? 2. To write the sensor driver, what are the things, we need to look in bridge driver? 3. What are the Sensor driver functions called from bridge driver. 4 . What are the things the bridge driver expect from Sensor driver? -Thanks. Thanks & Regards - Asad IQ Root Technologies

1 0