kernel
kernel copied to clipboard
Glitch in interrupt handling? Missed interrupt?
Test program Cargo.toml:
[package]
name = "testtcp"
version = "0.1.0"
edition = "2021"
[dependencies]
[target.'cfg(target_os = "hermit")'.dependencies.hermit]
path = "../rusty-hermit/hermit"
Test program src/main.rs:
#[cfg(target_os = "hermit")]
use hermit as _;
use std::net::TcpListener;
fn main() {
let listener = TcpListener::bind("127.0.0.1:8080").unwrap();
loop {
listener.accept().unwrap();
}
}
rusty-hermit is at f7b3c51cbb3cc4d2cd4c199370e53cb714c5e951 rusty-hermit/kernel is at 5dd731029f1d23c50dbd80c3c04dc7a95ed5bffc
Build and run with Hermit on Intel:
cargo build --target x86_64-unknown-hermit --release \
-Z build-std=std,core,alloc,panic_abort \
-Z build-std-features=compiler-builtins-mem
qemu-system-x86_64 \
-cpu qemu64,apic,fsgsbase,fxsr,rdrand,rdtscp,xsave,xsaveopt \
-smp 1 -m 512M \
-device isa-debug-exit,iobase=0xf4,iosize=0x04 \
-display none -serial stdio \
-kernel ../rusty-loader/target/x86_64/release/hermit-loader \
-initrd target/x86_64-unknown-hermit/release/testtcp \
-netdev user,id=u1,hostfwd=tcp::8080-:8080 \
-device virtio-net-pci,netdev=u1,disable-legacy=on
Test from another terminal:
while socat -u TCP:localhost:8080 CREATE:out ; do date ; done | uniq -c
What I see is initially about 120 connections accepted every second, but soon it drops to about 60, and every now and then something goes wrong, for example:
72 Mon Sep 11 12:18:25 UTC 2023
139 Mon Sep 11 12:18:26 UTC 2023
131 Mon Sep 11 12:18:27 UTC 2023
116 Mon Sep 11 12:18:28 UTC 2023
102 Mon Sep 11 12:18:29 UTC 2023
93 Mon Sep 11 12:18:30 UTC 2023
86 Mon Sep 11 12:18:31 UTC 2023
80 Mon Sep 11 12:18:32 UTC 2023
76 Mon Sep 11 12:18:33 UTC 2023
69 Mon Sep 11 12:18:34 UTC 2023
41 Mon Sep 11 12:18:35 UTC 2023
69 Mon Sep 11 12:18:53 UTC 2023 <-- 17 seconds with no connection here
130 Mon Sep 11 12:18:54 UTC 2023
67 Mon Sep 11 12:18:55 UTC 2023
Perhaps an interrupt is dropped and the program gets rescued by a timer?
I get very similar behaviour on Arm if I avoid #898 by moving the initialisation of cursor
as described at 2023-09-11 11:38 +0100 in that issue.
Hm, you are right. I will investigate the reasons for this behavior