November 2019 - kernelnewbies@kernelnewbies.org

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

I2C bus driver TIMEDOUT because of PM autosuspend
by Primoz Beltram Dec. 3, 2019

Dec. 3, 2019

I am analysing a problem with I2C bus driver where the problem shows up as I2C bus completely blocked. The LX driver in question is /drivers/i2c/busses/i2c-xiic.c. Problem is difficult to reproduce, it happens very rarely. So far I saw that the main precondition is to have very heavy I2C traffic on bus. In my case this is achieved/reproduced via netdev driving SFP LEDs via /sys/class/leds/ (via gpio-pca953x). I generate traffic with iperf3. Network traffic is on 10Gbps EMAC. LX kernel is 4.14.0. What I saw from debugging this problem is that I2C bus get blocked when wait_event_timeout() completes because of timeout. The timeout handling in this driver is probably not robust enough (bus should not remain blocked), but at this moment this are just my speculations (don't know enough details). Looking the driver code and data on oscilloscope, I saw that SCL in single I2C data transfer sequence can be interrupted for very long delays, e.g up to hundredths of usec (SCL is 100kHz). I started to suspect that PM autosuspend delay could play some role here. There are only two delays in driver code, first in wait_event_timeout and second in set autosuspend delay. Case is a bit strange because in very busy I2C traffic, PM autosuspend should not be triggered at all. Additionally, if I lower PM timeout, e.g. from 1000 (default) to 100, I hit the problem sooner (waits for problem hit are in order of n*10minutes). It looks to me that PM autosupend is playing some role here. Power management options in my .config: # CONFIG_SUSPEND is not set # CONFIG_PM is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y I intentionally did not put all detail descriptions of embedded system and test setup here (long list), because the main reason of this post is: The workaround that works for me/customer (at the moment) is to disable PM autosuspend in the driver code, either by incerementing PM delay from 1000 to 10000 or by disabling autosuspend (comment out call to pm_runtime_put_autosuspend() in xiic_xfer()). But, I would like to expose/discuss this issue (maintainer of the code, or others). The reason/source of the problem can be much more complex and in some other place. So my question is who should I contact, is this the M: in the MAINTAINERS list, the MODULE_AUTHOR, ...? How to proceed. WBR Primoz

3 2

Kernel TLS
by Jeffrey Walton Nov. 30, 2019

Nov. 30, 2019

Hi Everyone, I'm trying to run through the example at https://www.kernel.org/doc/html/latest/networking/tls.html#kernel-tls . I'm working on Fedora 31 x86_64 (fully patched). Running my program results in: $ ./ktls setsockopt failed, 2, No such file or directory I observed: $ cat /proc/sys/net/ipv4/tcp_available_ulp $ Is there a way to enable ULP at boot? Or is this a kernel config option? Or maybe I am doing something else wrong? Below is the sample code. Jeff ============================== #include <stdio.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <linux/tls.h> #include <netinet/ip.h> #include <netinet/tcp.h> int main() { int sock = socket(AF_INET, SOCK_STREAM, 0); if (sock == -1) { printf("socket failed, %d, %s\n", errno, strerror(errno)); return 1; } if (setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls")) == -1 ) { printf("setsockopt failed, %d, %s\n", errno, strerror(errno)); return 1; } close (sock); return 0; }

6 14

Interrupt catched in kernel, but not handled
by Ranran Nov. 29, 2019

Nov. 29, 2019

Hello, I installed centos8 , and I use uio_pci_generic, in order to communicate with FPGA (Xilinx) through PCIe in userspace. The cpu is ATOM cpu. I first install the driver: echo "10ee 0007" > /sys/bus/pci/drivers/uio_pci_generic/new_id I use userspace application which wait for interrupt, just as described in code example here: https://www.kernel.org/doc/html/v4.1...uio-howto.html I than trigger an interrupt from FPGA, but no print from the userspace application is given and there is an exception: irq 23: nobody cared (try booting with the "irqpoll" option) [ 91.030760] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.18.16 #6 [ 91.037037] Hardware name: /conga-MA5, BIOS MA50R000 10/30/2019 [ 91.043302] Call Trace: [ 91.045881] <IRQ> [ 91.048002] dump_stack+0x5c/0x80 [ 91.051464] __report_bad_irq+0x35/0xaf [ 91.055465] note_interrupt.cold.9+0xa/0x63 [ 91.059823] handle_irq_event_percpu+0x68/0x70 [ 91.064470] handle_irq_event+0x37/0x57 [ 91.068481] handle_fasteoi_irq+0x97/0x150 [ 91.072758] handle_irq+0x1a/0x30 [ 91.076230] do_IRQ+0x44/0xd0 [ 91.079333] common_interrupt+0xf/0xf [ 91.083154] </IRQ> [ 91.085360] RIP: 0010:cpuidle_enter_state+0x7d/0x220 [ 91.090563] Code: e8 18 1a 45 00 41 89 c4 e8 d0 50 b1 ff 65 8b 3d d9 db e5 5f e8 44 4f b1 ff 31 ff 48 89 c3 e8 ea 61 b1 ff fb 66 0f 1f 44 00 00 <48> b8 ff ff ff ff f3 01 00 00 4c 29 eb ba ff ff ff 7f 48 89 d9 48 [ 91.110283] RSP: 0018:ffffb20e806b7ea8 EFLAGS: 00000286 ORIG_RAX: ffffffffffffffda [ 91.118203] RAX: ffff90133fd214c0 RBX: 00000015316faa09 RCX: 000000000000001f [ 91.125662] RDX: 00000015316faa09 RSI: 0000000000000000 RDI: 0000000000000000 [ 91.133133] RBP: ffff90133fd2b300 R08: 0000011741eb842c R09: 0000000000000006 [ 91.140605] R10: 00000000ffffffff R11: ffff90133fd205a8 R12: 0000000000000001 [ 91.148068] R13: 00000015316f98b9 R14: 0000000000000001 R15: 0000000000000000 [ 91.155523] ? cpuidle_enter_state+0x76/0x220 [ 91.160088] do_idle+0x221/0x260 [ 91.163470] cpu_startup_entry+0x6a/0x70 [ 91.167588] start_secondary+0x1a4/0x1f0 [ 91.171676] secondary_startup_64+0xb7/0xc0 [ 91.176043] handlers: [ 91.178419] [<00000000ec05b056>] uio_interrupt [ 91.183054] Disabling IRQ #23 So, I started debugging this issue in kernel uio_pci_generic.c code, and according to the prints below, it seems that irq is catched but not delivered to userspace: static irqreturn_t irqhandler(int irq, struct uio_info *info) { struct uio_pci_generic_dev *gdev = to_uio_pci_generic_dev(info); printk("i'm here 1\n"); <<--- this is printed if (!pci_check_and_mask_intx(gdev->pdev)) return IRQ_NONE; printk("i'm here 2\n"); <<--- but this is NOT printed /* UIO core will signal the user process. */ return IRQ_HANDLED; } Reading documentation, I see that pci_check_and_mask_intx is actually checking if interrupt bit is set in configuration space. Since it seems to return 0 ,it should mean that it finds that this bit is not enabled. But how can it be that irq is triggered and status bit is not enabled in configuration space ? The device appear as following with lspci -vv: 02:00.0 RAM memory: Xilinx Corporation Default PCIe endpoint ID Subsystem: Xilinx Corporation Default PCIe endpoint ID Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 23 Region 0: Memory at 91200000 (32-bit, non-prefetchable) [size=1M] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [58] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 1, Latency L0s <64ns, L1 <1us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s unlimited ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: uio_pci_generic I also verified that there are no additional irq numbered 23 except for our device. How can it be that irq is catched, but not delivered to userspace ? Thank you for any idea, ranran

1 0

Update: I2C bus driver TIMEDOUT because of PM autosuspend
by Primoz Beltram Nov. 28, 2019

Nov. 28, 2019

I must update my report. It is not PM autosuspend (void calls do nothing, no miracle here). This morning I reproduced the I2C timeout error also with XIIC_PM_TIMEOUT=10000 delay. For several days some other change was misleading me to PM autosuspend conclusion. What looks to me now is that just slight change in driver code (e.g. add or remove dev_info() call) changes the execution timing pattern of driver and this then determine if the problem probability window is hit or not. Probability to hit the problem is very low. The driver timeout error and its result to I2C bus blocked is still a problem. I would still like to let the maintainer aware of this problem.

2 1

How to printk synchronously
by aleave Nov. 28, 2019

Nov. 28, 2019

Hi everyone, I'm modifying kernel code and running into system dead-lock issues. I have printk statements to try to retrieve info about the freeze after I do a hard shutdown, but printk is asynchronous so /var/log/kern.log only shows NULL character gibberish instead (^@^@^@^@). Is there a way to make printk synchronous? I have looked at people using [printk_sync](https://lore.kernel.org/patchwork/patch/671535/) and [printk.synchronous](https://stackoverflow.com/questions/26413750/how-to-avo… variables as recently as 2017, but I don't see any reference to these anymore in the kernel version I have (5.4). Thanks for the help.

4 3

I2C bus driver TIMEDOUT because of PM autosuspend
by Primoz Beltram Nov. 27, 2019

Nov. 27, 2019

I am analysing a problem with I2C bus driver where the problem shows up as I2C bus completely blocked. The LX driver in question is /drivers/i2c/busses/i2c-xiic.c. This driver is for FPGA based I2C controller. Problem is difficult to reproduce, it happens very rarely. So far I saw that the main precondition is to have very heavy I2C traffic on bus. In my case this is achieved/reproduced via netdev driving SFP LEDs via /sys/class/leds/ (via gpio-pca953x). I generate traffic with iperf3. Network traffic is on 10Gbps EMAC. LX kernel is 4.14.0, ARM64, dual core CPU, 2Gbyte mem. What I saw from debugging this problem, is that I2C bus gets in this blocked state when wait_event_timeout() completes because of timeout. The timeout error handling in this driver is probably not robust enough (bus should not remain blocked because of error), but at this moment this are just my speculations (don't know enough details). Looking the data on oscilloscope, I saw that SCL in single I2C data transfer (several messages) sequence can be interrupted for very long delays, e.g up to hundredths of usec (SCL is 100kHz). There are only two delays in driver code, first in wait_event_timeout and second in set autosuspend delay. I started to suspect that PM autosuspend delay could play some role here. Case is a bit strange because in very busy I2C traffic, PM autosuspend should not be triggered at all. Additionally, if I lower PM timeout, e.g. from 1000 (default) to 100, I hit the problem sooner (waits for problem hit are in order of n*10minutes). It looks like PM autosupend is playing some role here. Power management options in my Linux kernel build .config: # CONFIG_SUSPEND is not set # CONFIG_PM is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y It is not logical (PM is not configured, PM runtime calls are void/empty calls), but this case is repeatedly reproduced on my test setup: XIIC_PM_TIMEOUT=1000 (or less) -> I2C timeout error, bus blocked XIIC_PM_TIMEOUT=10000 -> No I2C timeout error I tried also to build i2c-xiic driver with kernel build defaults and without optimizations (ccflags-y += -O0 -g) and also as in-kernel and as loadable module. Always the same test results. The workaround that works at the moment is to change PM delay from 1000 (default) to 10000. Doing so I don't reproduce the problem (24h runs ok), but honestly I don't believe this is fix. More likely the problem is some coincidence timing issue, somewhere. I intentionally did not put all detail descriptions of embedded system and test setup here (long list), because the main reason of this post is: I would like to expose/discuss this issue (maintainer of the code, or others). The reason/source of the problem can be much more complex and in some other place. So my question is who should I contact, is this the M: in the MAINTAINERS list, the MODULE_AUTHOR, ...? How to proceed. WBR Primoz

1 0

Just started w/Linux Kernel (Beginner)
by Benjamin Selormey Nov. 25, 2019

Nov. 25, 2019

Hello, I’m a newbie with Linux kernel and I l want to contribute in security research of the Linux Kernel. I am interested in memory management and devices communication with the kernel. Does anyone have a starter project in mind I can start with? Thank you. Very Respectfully, Ben

2 2

How to add a block into blkio.throttle.io_service*?
by Julio Faracco Nov. 24, 2019

Nov. 24, 2019

Hi everybody, I'm having some problems to understand how to add a block device into blkio.throttle.* . Being more specific, I cannot see my block listed into blkio.throttle.io_serviced. An example... I'm running docker with a loopback device attached: $ docker run -ti --device=/dev/loop16:/dev/loop16 fedora:latest bash I can see it listed and included: $ cat /sys/fs/cgroup/blkio/docker/2db640bc7bb28a3b6bf83dd7b7c0f146b4433e3ed5dfa6899f8498f9a19c52c5/blkio.throttle.io_serviced 7:16 Read 34 7:16 Write 0 7:16 Sync 34 7:16 Async 0 7:16 Discard 0 7:16 Total 34 8:0 Read 417 8:0 Write 0 8:0 Sync 417 8:0 Async 0 8:0 Discard 0 8:0 Total 417 Total 451 But how can I add it properly into my cgroup path? I know that you need to enable block into that cgroup. But it is not working for me. It works if I reset blkio.throttle.write_bps_device and other fields: # echo 0 > /sys/fs/cgroup/blkio/mypath/blkio.throttle.write_bps_device I don't know if it is right. Does anyone know how to do it properly? Thanks! -- Julio Cesar Faracco

1 0

Just joined
by Akash Sarda Nov. 20, 2019

Nov. 20, 2019

Hi, My name is Akash, and I want to start with OS development.. I am interested in memory management, and would like to know if anyone has a newbie project in their mind.. Thanks and Regards Akash

3 3