From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/0 Description of problem: When copying large (>2GB) file via scp everything goes fine until last byte is copied. Then on box where is copying performed kernel slow down immediately to unusable state. Executing ls or who take about minute. Most of time CPUs spend in system mode. Each process in R state add 1 to load (naturally). There are no process in D state. Shutting down this system via reboot takes hours. No messages in syslog. Entire file is copied, but scp doesn't ends. I found, that some kernels have not this problem: 2.2.19-7.0.16enterprise.i686 2.4.18-5.i386 2.4.18-5.i586 2.4.18-5smp.i586 But these have it: 2.4.18-4smp.i686 2.4.18-5.i686 2.4.18-5bigmem.i686 2.4.18-5debug.i686 2.4.18-5smp.i686 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. other box$ dd if=/dev/zero of=2aG count=4000001; scp 2aG unstable: 2. wait on unstable until copying ends 3. Actual Results: scp doesn't end system immediately slow down and become unusable Expected Results: normal scp ending no additional loads and system calls Additional info: Hardware: HP NetServer 6000 U3 - 4 Pentium III (Cascades) 700 MHz 2 MB cache, 4 GB RAM, AMI MegaRAID (typ T7, 32 MB RAM), two RAID5 volumes, HP SureStore Ultrium 230, CD-ROM, Intel Ethernet Pro 100 NIC. I have not second such server for testing and on "normal" PC boxes this problem doesn't appear.
I have this problem on second HP NetServer 6000 U3 too. I have this problem also with 2.4.18-10.i686.
I have the exact same problem on a machine with the 2.4.18-18.7.xsmp kernel.
the current erratum kernel has a new rmap VM patch to fix this
Yes. It works on kernel-smp-2.4.20-20.7.i686. Many thanks.