Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753181AbZAaXkI (ORCPT ); Sat, 31 Jan 2009 18:40:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751720AbZAaXjx (ORCPT ); Sat, 31 Jan 2009 18:39:53 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:51128 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751380AbZAaXjw (ORCPT ); Sat, 31 Jan 2009 18:39:52 -0500 Date: Sat, 31 Jan 2009 15:39:18 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: "Rafael J. Wysocki" cc: Parag Warudkar , Matt Carlson , "netdev@vger.kernel.org" , Linux Kernel Mailing List , "David S. Miller" , Andrew Morton Subject: Re: What should PCI core do during suspend-resume? (was: Re: 2.6.29-rc3: tg3 dead after resume) In-Reply-To: Message-ID: References: <200901312242.17273.rjw@sisk.pl> <200902010008.32126.rjw@sisk.pl> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1433 Lines: 32 On Sat, 31 Jan 2009, Linus Torvalds wrote: > > But how many people test STR while doing a "ping -f" from another machine? > > It _should_ work. Do you guarantee that it does? Btw, this really only is interesting if there's a shared interrupt. I'm sure that there are network drivers that will crash even on their own with _just_ the right timing (imagine having a delayed interrupt pending, then doing the "pci_set_power_state(PCI_D3hot)" thing, and then get the interrupt handler invoked on another CPU _just_ afterwards), but it's probably really hard to trigger, and a bug in that specific driver anyway. But what's much more interesting (and not necessarily a driver bug, but a general PM infrastructure problem) is if we have that shared interrupt case, and the network driver gets lots of interrupts just as "driver X" is shutting down with that interrupt shared. Then, "driver X" will get interrupts after the PM layer has put its device to sleep, and now "driver X" is quite understandably confused - it didn't even do the "put to sleep" itself, but now its device is no longer responding. And now it's not a really unlikely race condition any more. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/