Description of Problem: kernel vfree() messages anytime card is removed (2.4.18-3 and -4) Machine remains responsive. Network performance problems with 2.4.18-4: Network transfer rates are either very slow all the time (50k/sec on a 100 MB switched LAN) or will work reasonably well for a short period of time then network becomes unresponsive until machine is rebooted. This behavior is not seen on 2.4.18-3. I have recieved approx. 1.5MB/sec over NFS using 2.4.18-3 on the same network. Version-Release number of selected component (if applicable): 7.3 w/ all errata installed, using both 2.4.18-3 and 2.4.18-4. How Reproducible: always Steps to Reproduce: 1. remove NIC at any time to get vfree() 2. slow or stalled network performance under 2.4.18-4 observable under all network protocols/apps I have tried (FTP, Samba, NFS, pings, DNS queries) 3. Actual Results: 2.4.18-3 - can always reproduce oops seen when removing card, network performance acceptable. 2.4.18-4 - oops always reproduceable, network performance as described above. Expected Results: no oopses when removing cards, decent network performance :) Additional Information: Please see attached files.
Created attachment 61024 [details] lsmod output, should be about the same for -4
Created attachment 61025 [details] lspci output
Created attachment 61026 [details] relevant bits of /var/log/messages with several vfree() messages from both kernels
I also reported a similar oops under bug #74735 for the same NIC/modem card. Additionally, on my laptop I also experience problems when I insert the card. The network is totally unreliable with many transmission errors. If I put the interface down and up again (ip link eth0 down; ip link eth0 up) then it works OK. In the kernel logs one can see that the first time the interface is put up the kernel reports "silicon revision 0", while the second one reports "silicon revision 5". This problem can also be seen in the logs in the previous attachement of this bug report. Something is probably going wrong when the interface is brought up the first time. This never occured back when I was running under kernel 2.2.x (long time ago), but has always happened when running under 2.4.x. The workaround I use is to issue an "ip link eth0 up; ip link eth0 down" in /sbin/ifup-pre-local before the interface is brought up by the network initialization scripts.
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/