April 2018 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Softlockup and Hardlockup sample test module
by Ivid Suvarna April 15, 2018

April 15, 2018

Hi All, Could you please provide some sample test module for causing a Softlockup and Hardlockup in latest kernel for SMP for only testing purposes. I assume there are some Kconfigs to be enabled as well for this. I had tried with the module where I put a busy loop inside spinlock but was not able to cause any lockups. Maybe this is because of SMP which schedule the job to other CPU. "How do I make a task to run on single CPU only?" I only get RCU stalls sometimes instead of softlockup when I use busy loop inside a spinlock. Is there any explanation for difference between these stalls and softlockup. Thanks, IVID

1 0

non-coherence DMA run-time detection
by Matwey V. Kornilov April 14, 2018

April 14, 2018

Hi, I am suffering from performance issue similar to that is supposed to be fixed by 3e0ac6717b0a ("[media] media: Fix a UVC performance problem on systems with non-coherent DMA") https://github.com/torvalds/linux/commit/3e0ac6717b0a2593243ef3850025a42cb1… The patch operates with CONFIG_DMA_NONCOHERENT compile-time option which is present only for mips and sh architectures. At the same time, some ARM platforms are also DMA non-coherent that leads to the similar memcpy() performance issues as mentioned in the patch. However, we learn whether we run with coherent or non-coherent DMA at run-time while parsing FDT in case of ARM platforms. This happens in of_dma_configure() function. I would like to find a way to re-implement the patch for the case of ARM platforms, but unfortunately I could not find preferred way to check DMA coherency in run-time. Could you please advice? p.s. Frankly speaking, the patch looks to be redundant for me. I have no idea why DMA coherency could be really required for USB Isochronous input buffer. At the host side there is only reading operation, that means that single barrier would have been sufficient here.

1 0

Set Location Counter to a new value in ld linker script
by Hao Lee April 9, 2018

April 9, 2018

Hi, I'm confused about the location counter, especially when setting it to a new value in the output section. I write a simple program and a linker script to make my question more clear. The code is as follows: -----test.s--------- section .text .globl _start _start: movq $1, %rax movq $0, %rbx int $0x80 ------test.lds------ SECTIONS { . = 0x10; label_1 = .; custom_section : { . = 0x20; label_2 = . ; label_3 = ABSOLUTE(.) ; *(.text) ; } } After linking, use nm command to print symbol addresses: 0000000000000010 T label_1 0000000000000030 T label_2 0000000000000030 A label_3 0000000000000030 T _start I can't understand why lable_2 is 0x30. As the LD documentation says[1], if '.' is used inside a section description, it refers to the byte offset from the start of that section, not an absolute address. In the custom_section, '.' is set to 0x20 which is a relative offset, so I think label_2 should also be 0x20. The value of label_3 is reasonable because it's an absolute address. Could someone please explain why label_2 is 0x30? Thanks! [1] https://sourceware.org/binutils/docs-2.30/ld/Location-Counter.html#Location… Regards, Hao Lee

2 1

V4L2 configuration doubt
by MUHAMMED ASAD P T April 7, 2018

April 7, 2018

Hi All, Need to configure below parameter: Color Format: RGB888 Color Depth: 8 Pixels Per Clock: 2 Is there any macro available for this configuration like MEDIA_BUS_FMT_RGB888_1X24? How to configure pixel per clock in device tree and driver file? Thanks & Regards - Asad

1 0

sensor driver configuration
by MUHAMMED ASAD P T April 7, 2018

April 7, 2018

Hi All, How to configure the below parameters: Color Format: YUV_422 Color Depth: 12 Pixels Per Clock: 2 In Sensor driver and device tree, how to configure these values. In Sensor driver, we may use the macro like this MEDIA_BUS_FMT_UYVY8_1X16. But have the doubts on this. How to specify this Pixels per clock?? Thanks & Regards - Asad

1 0

Block device handling from other module
by Rupesh Kumar April 6, 2018

April 6, 2018

In case of sudden power loss, my custom board will get an interrupt and will have few milliseconds of back up power. To improve upon SSD life span I need to save ssd data and issue STANDBY IMMEDIATE command as soon as power loss interrupt is received. I have already implemented the interrupt part but not sure how to handle SSD command. Any suggestions on how shall this be implemented ? My question is : Can STANDBY IMMEDIATE command be issued directly to SSD device ? How can I achieve it in most efficient way ? BR Rupesh

2 1

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