Description of problem: kernel 2.6.17-1.2187_FC5 freezes on network activity. A hard reboot is necessary after this happens. Version-Release number of selected component (if applicable): 2.6.17-1.2187_FC5 How reproducible: 100% reproducable Steps to Reproduce: 1. make an ethernet connection to another computer and transfer some data ssh or other low-bandwidth protocols normally do not cause the bug to happen - I have to transfer some file data (or even x11 data) - then the computer hard freezes. Actual results: the computer freezes., Expected results: the data is transferred without a lockup. Additional info: The computer has an athlon64 x2 4600+ (windsor) dual-core processor. The motherboard is: MSI K9N pklatinum with dual gigabit ethernet interfaces (forcedeth driver) downgrading to kernel 2.6.17-1.2174_FC5 fixes the problem. Due to this fact I believe it is a software problem in the kernel or the forcedeth driver. I have another machine with the following similar specification that does not exhibit the problem on 2.6.7-1-2187_FC5: althon64 3400+, single gigabit eth i/f (forcedeth driver)
I have been getting core dumps with this kernel as well, some seem to be triggered by iptables commands, last one I got just doing a dmesg. Two totally different mobo, one ibm 330 and one cheapo clone asus. I will open a new bugs per mobo.
w.r.t. forcedeth driver, can you try with a different network driver to help narrow down to either the forcedeth driver issue or network stack issue?
(In reply to comment #2) > w.r.t. forcedeth driver, can you try with a different network driver to > help narrow down to either the forcedeth driver issue or network stack > issue? Is there another driver I can use that's compatible with the nvidia gigabit ethernet cards? I will be glad to try another driver if there is one. Otherwise I can try unloading the drivers and running a bunch of data through the loopback interface to check the stack...
I have had the same problem using 2.6.17-1.2187_FC5 with AMD64 nvidia MB (forcedeth drivers), during an ssh session which caused a kernel panic. Also on a dell poweredge 750 with built in e1000 cards 'MT'. A kernel panic occured during a 'dmesg' and a ssh session. jason
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
The problem seems to be fixed with the new kernel (2.6.18-1.2200) Also it turned out I had a hardware problem - replacing my videocard and upgrading to the new kernel has resulting in a very stable system again. I'm not sure how to update the status of this bug so I'm leaving it alone but from my point of view the issue is closed.