Bug 97058
| Summary: | (tulip) memory leak on overnight test of network driver | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <sam.overdorf> |
| Component: | kernel | Assignee: | Jeff Garzik <jgarzik> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | peterm |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-30 15:41:05 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Which network card Also please provide more details about what the test is doing I have used the SMC 9332BDT (10/100Mbs) with the tulip 0.9.15-pre12 driver in the RH9 distribution. The Intel "A19845" copper gigabit (Pba # A19845) and the e1000 5.1.11 driver. I am using this driver on both RH8 and RH9 for consistency. My network test is a bash script (it loops forever) that sends and receives a file using (ftp, rcp, nfs), executes an rsh command (ls), does ping and ping- flood. I stick to these utilities so I don't have to deal with any third party programming problems. I monitor free memory with the free, and vmstat command. I just finished a run using the 2.4.21-rc7-ac1 kernel. There was about 80Megs less memory listed in free after the test but this is not the same behaviour as seen with the other kernels. total memory shown in free: 516412 before test: 495688 after test: 415096 Hope this is helpful. Thanks, Sam I have tried the same test with the following kernel and it has the leak. It did take two days to consume memory and not one this time. Red Hat Linux release 9.0.92 (Cambridge) Kernel 2.4.20-20.1.2013.nptl Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/ |
Description of problem: I test network drivers. My computer has 256Megs of memory. For this test it should never swap. I leave an overnight test running and the next morning free memory is down to 8Megs and the system is swapping it's brains out. This does not happen with the following: RedHat 8.0 www.linux.org 2.4.20 www.linux.org 2.4.20 with rc4-ac1 patches applied I does happen with the following: RedHat 9 distribution errata kernel 2.4.20-13.9 errata kernle 2.4.20-18.9 glibc 2.3.2-27.9 xinetd-2.3.11-1.9.0 vsftpd-1.1.3-8 Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. Install RedHat 9 2. Run my network test overnight 3. The next morning memory in down to 8Megs and swaping (vmstat) Actual results: total used free shared buffers cached Mem: 255328 251876 3452 0 704 4420 -/+ buffers/cache: 246752 8576 Swap: 104412 15896 88516 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 1 15892 3552 752 4196 98 138 172 0 139 113 6 12 82 0 0 1 15828 3448 752 4168 60 61 60 61 146 198 1 0 99 0 0 1 15780 3544 788 3992 13 5 48 7 141 201 1 0 99 0 0 1 15784 3552 792 3956 7 145 16 149 160 198 1 1 99 1 0 1 15804 3552 776 3976 0 8 0 8 109 167 0 0 100 0 0 1 15928 3448 820 4004 12 73 49 77 130 188 1 0 99 1 0 1 15928 3448 952 3752 24 15 82 15 172 222 2 1 96 2 0 1 16060 3616 1612 2236 68 313 648 328 351 355 10 9 81 0 1 1 17000 3348 1048 2380 157 428 339 439 1114 530 66 8 25 0 0 1 15992 3936 1044 3216 19 205 296 208 172 191 0 1 99 Expected results: No memory leak and returned to the free list. Additional info: