Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261356AbVAaUmF (ORCPT ); Mon, 31 Jan 2005 15:42:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261357AbVAaUmF (ORCPT ); Mon, 31 Jan 2005 15:42:05 -0500 Received: from out007pub.verizon.net ([206.46.170.107]:22954 "EHLO out007.verizon.net") by vger.kernel.org with ESMTP id S261356AbVAaUmC (ORCPT ); Mon, 31 Jan 2005 15:42:02 -0500 Message-ID: <41FE9BA3.BE2896C3@gte.net> Date: Mon, 31 Jan 2005 12:57:07 -0800 From: Bukie Mabayoje X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Brandeburg, Jesse" CC: sfeldma@pobox.com, ncunningham@linuxmail.org, "David =?iso-8859-1?Q?H=E4rdeman?=" , Michael Gernoth , Linux Kernel Mailing List , netdev@oss.sgi.com Subject: Re: 2.4.29, e100 and a WOL packet causes keventd going mad References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out007.verizon.net from [66.199.68.159] at Mon, 31 Jan 2005 14:41:58 -0600 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1601 Lines: 29 The issue is not the PME interrupt, the issue is that the device is going into a state that is not valid. A live system should never ASSERT PME# line. As long as this functionality is enable on the chip the PME will be asserted. To avoid this unwanted condition the driver should disable PME on the chip on a live system. And enable it back when it is going to any of the PWR STATE that require a wake up by the LAN. "Brandeburg, Jesse" wrote: > >+static void e100_shutdown(struct device *dev) > >+{ > >+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev); > >+ struct net_device *netdev = pci_get_drvdata(pdev); > >+ struct nic *nic = netdev_priv(netdev); > >+ > >+ pci_enable_wake(pdev, PCI_D0, nic->flags & (wol_magic | > >e100_asf(nic))); > >+} > >+ > > Separately, does anyone think that the OS should be handling the PME event on the bus (as it comes from the PIC as an interrupt, and can be masked at the PIC) with a default handler? The machines having the problem seem to be killed by an interrupt storm generated by the PME interrupt, just a guess. > > Jesse > - > 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/ - 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/