Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: I am seeing a large memory spike (19-21gb) when trying to scp a small file 10mb. 2. What is the Version-Release number of the kernel: 6.19.12-300.fc44.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : I have not been able to test since when this problem is present. I know it's present in the newer linux kernel being used by ubuntu 26.04 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Yes, consistently. Create a file: dd if=/dev/urandom of=/tmp/test10m bs=1M count=10 Transfer it: scp /tmp/test10m any_host:/tmp/test10m it might take 2-3 transfers for it to trigger. rsync shows the same behaviour, nc doesn't show it. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: I did not try it. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No, but I am force probing xe driver instead of i915 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. mem log captured using: ``` while true; do echo "=== $(date +%T) ===" >> /tmp/memwatch.txt grep -E 'MemTotal|MemFree|SwapFree|Slab|SReclaimable|SUnreclaim' /proc/meminfo >> /tmp/memwatch.txt sleep 1 done ``` 07:55:23 MemFree: 14.8GB SUnreclaim: 356MB ← normal 07:55:24 MemFree: 10.7GB SUnreclaim: 4.4GB ← spike starts 07:55:25 MemFree: 5.5GB SUnreclaim: 9.6GB 07:55:26 MemFree: 0.4GB SUnreclaim: 14.7GB ← nearly OOM! 07:55:27 MemFree: 0.5GB SUnreclaim: 19.2GB ← swap kicks in 07:55:28 MemFree: 1.7GB SUnreclaim: 21.2GB ← peak 07:55:29 MemFree: 10.5GB SUnreclaim: 12GB ← collapsing 07:55:30 MemFree: 19.2GB SUnreclaim: 3.3GB 07:55:31 MemFree: 22GB SUnreclaim: 343MB ← back to normal Reproducible: Always
Created attachment 2137422 [details] dmesg log
Created attachment 2137423 [details] memory watch log
Reported here https://bugzilla.kernel.org/show_bug.cgi?id=221092 as an intel be201 issue.
Hey Saurabh, Thanks for reporting this. It looks like the upstream bug has progressed to being resolved with a current upstream kernel release based on the 7.0.14 kernel and above. Fedora 44 has access to the 7.1.5 kernel via 7.1.5-201 kernel packages. Are you able to update the kernel and see if the issue is reproduced? Likewise, disabling TSO seemed to workaround the issue in the upstream report (https://bugzilla.kernel.org/show_bug.cgi?id=221092#c14) are you able to test with that as well? The reason I ask for the additional testing with TSO disabled is because the memory consumption reported here is not brought up in the upstream report. I am not exactly convinced the upstream bug is a match for the reported bug here (though it is entirely possible the issue is the same but has different symptoms under different circumstances). So the request to test with TSO disabled is to help support the idea the two reports are for the same issue. Thank you!
Hi Charles, Thanks for taking a look. Unfortunately I am on alma 10 and back to using this system as my primary device, so not possible for me to test Fedora now. Sorry about that. I believe it was the same issue though: https://github.com/basecamp/omarchy/issues/5827#issuecomment-4714931911 John has reported it to be fixed. Thanks