Most recent kernel where this bug did not occur: 2.6.17.11 Distribution: mandriva 2007.0 beta 2 Hardware Environment: Desktop box based on ASUS A7V133-C motherboard (VIA chipset), Athlon XP 1600+, Realtek RTL-8029(AS) PCI Ethernet controller. Software Environment: Problem Description: 2.6.17.11 suspends and resumes successfully even with high network activity. 2.6.18-rc1 and later kernels hang when suspending during network activity. They're stuck just after "swsusp: Critical section: done". When I wait a few minutes, a "Soft lockup" exception occurs. I must shut down network and unload ne2k-pci and 8390 modules in order to suspend/resume reliably. This regression is due to git commit 53e4d30dd666d7f83598957ee4a415eefb47c9a6. (see http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=53e4d30dd666d7f83598957ee4a415eefb47c9a6). Reverting this patch on 2.6.18-rc4-mm3 made me able to suspend/resume during network activity without shutting down network. Steps to reproduce: - boot to runlevel 1 - set up network (service network start). ifconfig looks like this: # ifconfig eth0 Link encap:Ethernet HWaddr 00:40:95:46:6E:2D inet adr:192.168.0.3 Bcast:192.168.0.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ... lo Link encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 ... - echo 5 > /proc/sys/kernel/printk - echo reboot > /sys/power/disk - echo disk > /sys/power/start
Created attachment 8905 [details] config file used for git bisection
hm. I guess it's a driver bug. I'm looking for the place where a net driver suspend method drains its queue and waits for IRQ/DMA activity to terminate, but am not having much luck. Maybe we should revert Rajesh's patch for now?
The driver should re-enable the device on resume. If it doesn't do that, it is a bug in the driver, right?
drivers/net/ne2k-pci.c:ne2k_pci_resume() ;) Yes, the driver does all that. But this failure happens during suspend, when there's net activity. I don't see what's preventing ongoing tx/rx activity when the device is being suspended. Confused.
Yes, this seems to be a driver bug (driver maintainer added to CC). I see other drivers talking to their hardware to silence it in the suspend callback, but not this driver. Dropping my patch for the time being should be ok (though I seem to remember someone else posting a patch to do the same thing - I don't remember why). Decoding resources while disabled is a potential problem, but I haven't seen a problem report where this caused failures.
Andrew, can you drop that patch?
Could anyone please tell me what the current status of this bug is?
The problem stil happens with 2.6.19-rc4: I can reliably hang my computer by suspending while downloading some big file from Internet.
I think the problem has been fixed recently. Am I right?
Yes, this bug has been fixed in 2.6.19-rc5. commit 6851ecc6e2fa4a01449a0fec9f4abd9aec43afde Author: Greg Kroah-Hartman <gregkh@suse.de> Date: Thu Nov 2 23:02:24 2006 -0800 PCI: Revert "PCI: i386/x86_84: disable PCI resource decode on device disable " This reverts commit 53e4d30dd666d7f83598957ee4a415eefb47c9a6. It was found that it caused unneeded problems (see http://bugzilla.kernel.org/show_bug.cgi?id=7082 for details of one such issue. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>