Bug 7082

Summary:	suspend with ne2k-pci hangs
Product:	Drivers	Reporter:	Laurent Riffard (laurent.riffard)
Component:	Network	Assignee:	Andrew Morton (akpm)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	akpm, greg, p_gortmaker, rajesh.shah
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.18-rc5	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	config file used for git bisection

Description Laurent Riffard 2006-08-30 10:20:32 UTC

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

Comment 1 Laurent Riffard 2006-08-30 10:22:24 UTC

Created attachment 8905 [details]
config file used for git bisection

Comment 2 Andrew Morton 2006-08-30 10:45:54 UTC

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?

Comment 3 Greg Kroah-Hartman 2006-08-30 11:34:09 UTC

The driver should re-enable the device on resume.  If it doesn't do that, it
is a bug in the driver, right?

Comment 4 Andrew Morton 2006-08-30 11:44:16 UTC

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.

Comment 5 Rajesh Shah 2006-08-30 11:49:47 UTC

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.

Comment 6 Pavel Machek 2006-10-08 13:20:42 UTC

Andrew, can you drop that patch?

Comment 7 Rafael J. Wysocki 2006-10-30 10:12:15 UTC

Could anyone please tell me what the current status of this bug is?

Comment 8 Laurent Riffard 2006-10-31 14:39:31 UTC

The problem stil happens with 2.6.19-rc4: I can reliably hang my computer by
suspending while downloading some big file from Internet.

Comment 9 Rafael J. Wysocki 2006-11-15 10:22:29 UTC

I think the problem has been fixed recently.  Am I right?

Comment 10 Laurent Riffard 2006-11-15 13:23:03 UTC

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>