Recent content by anaxagoras

I've got a relatively recent issue. If one of my nodes reboots, the other 2 will lock up and reboot within a few seconds. I'm wondering if this is due to pinning the IRQ's to a specific CPU core, as this hasn't happened to me in the past and that's the most recent change i've made outside of...

I've got 3x minisforum ms-01 with a 13900h. Even with the --bidir flag you have no problem with iperf hitting 27?

hmmm, i'm seeing errors in dmesg around the time the system locks up. i'm sure there's a relation. [65039.247828] x86/split lock detection: #AC: CPU 0/KVM/623152 took a split_lock trap at address: 0xfffff8052744bb6d

I made some progress on this. If i do a less aggressive benchmark using the "default" profile don't get a lockup. SEQ1M Q8T1, SEQ1M Q1T1, RND4K 32T1, RND4K Q1T1 it runs fine. The more aggressive "ssd" profile is where it has a problem. SEQ1M Q8TQ, SEQ128K Q32T1, RND4K Q32T16, RND4KQ1T1...

I changed the io scheduler to native and it died again. it seems to keep dying on the random read tests. it seems to be getting through the sequential 1M Q8Tq, and the SEQ128kQ32T1. It keeps dying on either Random 4k Q32T16 or RND4kQ1T1. i'm unsure if that has any bearing. It doesn't make...

So i did do this test under zfs before setting up ceph, i was curious to see the performance difference to a VM. It worked fine.

I have a windows VM and i'm running crystal disk benchmark in it, and during the benchmark the VM does a soft-lockup. This is repeatable in my environment. I'm running the latest version of PVE 8.1.11, kernel 6.5.13-5-pve, and ceph reef version 18.2.2 What i mean by a soft lockup is: If task...

as of today openzfs doesn't support kernels greater than 6.7, so would it be safe to assume if you use ZFS then upgrading to 6.8 is at your own risk?

So cable pulls worked fine. But I'm having the same problem of frr restarting too early as a post-up command and not surviving a reboot, so I tried your if-up script and having the same issue of only 1 interface coming up on boot

putting a post-up script by itself is not working on boot, but does work if i restart networking. Since I'm testing things remote i can't test if it helps with physically plugging cables in. I also tried @dovh 's method with an if-up.d script, this did work on a reboot! Next tonight i will...

Pretty close to what I did, but running this on boot only doesn't work. On my system I've seen that the interrupt addresses have changed when thunderbolt cables were plugged and unplugged. So i'm thinking it might make more sense to make this part of the udev rule that scyto setup to bring up...

ok, i've been messing with this for the better part of 2 hours. i figured it out. I noticed that when i was getting a lot of retries ksoftirqd was eating up nearly 100% of a CPU core, but when i told iperf3 to limit to 19gbps and i got few retries ksoftirqd was using hardly any cpu. I found...

The CPU has its own tb4 controller and dedicated lanes for both ports. Ive also gotten 26gbps at other points of my testing I had to send a unit back due to a bad rj45 port. But that was also with high retries. I did also hit a weird wall where if my mtu size exceeded 35,000 or so, ceph would...

i never solved it, i just recreated the VM's with debian.

I'm running different hardware than you guys, the minisforum ms-01. I'm getting a lot of retransmits with iperf3. I started with some no-name thunderbolt4 cables, "connbull". I ordered and tried a belkin tb4 cable and an owc tb4 cables no apparent change. I've followed @scyto guide over on...