Forcedeth needs some patching to work ok in 2.6.29, else it hangs after a while. (With and without NAPI) Reproducible: Always
Created attachment 186575 [details, diff] Second patch from the thread specefied in the url bug. Tested here, seems to solve the problem (More than 2 hours running with heavy network load without a problem)
I wonder if it's this one that we actually want? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8f1ead2d1a626ed0c85b3d2c2046a49081d5933f We get our patches off of the repositories rather than the mailing lists as they tend to change before they get committed.
first, thanks for your support :). I don't know what patch should work better, I can test the other patch if you want. By the way the included patch is working fine (No hangs since I post this). Anyway the fix should be included in 2.6.29.1 so maybe we can let this bug open, until the next stable version is out, and close then.
If no one is a rush and we think 2.6.29.1 will be out before we do another genpatches (probable), we can wait on the next patchset.
I got bitten by this too. I had to reboot my mail server several times due to this bug. At first I thought it was my router's fault. It's definitely a short-term patch, but I vote for cutting a new release of 2.6.29 with it added. 2.6.29 as it stands is not going to work for people with forcedeth NICs unless they set the experimental NAPI option in their kernel config.
BTW I'm running Herbert Xu's patch from comment #2 and it fixes the problem for me.
Err, never mind, 2.6.29.1 was released on 2 Apr 2009 and it contains Herbert's patch. Can we get an ebuild for this ASAP please?
gentoo-sources-2.6.29-r1 released which contains the 2.6.29.1 patch set.
(In reply to comment #8) > gentoo-sources-2.6.29-r1 released which contains the 2.6.29.1 patch set. Hi, Mike, I'm running an ASUS M2N-SLI Deluxe with nForce 570 SLI, providing dual MCP MAC with Marvell PHY - thus enabled "CONFIG_FORCEDETH" in the kernel. Rebooting *from* 2.6.27, both get recognized fine. Rebooting *from* 2.6.29-r5 as well as 2.6.29-r6, I suffer from having to completely power-off the box. To me this seems to indicate that during shutdown of the network, the interfaces become configured into a mode where the bios dows not re-recognize them again. Thus, I propose to re-open this bug.
(In reply to comment #9) > (In reply to comment #8) Re-thinking, I suspect the PHY part even more than the MAC. And I found http://www.mail-archive.com/kernel-testers@vger.kernel.org/msg05061.html pointing to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5a9a8e32ebe269c71d8d3e78f9435fe7729f38e9 <cite> forcedeth: add phy_power_down parameter, leave phy powered up by default (v2) Add a phy_power_down parameter to forcedeth: set to 1 to power down the phy and disable the link when an interface goes down; set to 0 to always leave the phy powered up. The phy power state persists across reboots; Windows, some BIOSes, and older versions of Linux don't bother to power up the phy again, forcing users to remove all power to get the interface working (see http://bugzilla.kernel.org/show_bug.cgi?id=13072). Leaving the phy powered on is the safest default behavior. Users accustomed to seeing the link state reflect the interface state and/or wanting to minimize power consumption can set phy_power_down=1 if compatibility with other OSes is not an issue. </cite> This issue is being handled in http://bugzilla.kernel.org/show_bug.cgi?id=13072
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) I can confirm that this issue has been solved at least in vmlinuz-2.6.30.4 as well as in vmlinuz-2.6.30-gentoo-r4 , basing upon vanilla sources 2.6.30 patch 4 already.