From: Bukie Mabayoje <bukiemab@gte.net>
To: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
Cc: sfeldma@pobox.com, ncunningham@linuxmail.org,
"David Härdeman" <david@2gen.com>,
"Michael Gernoth" <simigern@stud.uni-erlangen.de>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
netdev@oss.sgi.com
Subject: Re: 2.4.29, e100 and a WOL packet causes keventd going mad
Date: Mon, 31 Jan 2005 12:57:07 -0800 [thread overview]
Message-ID: <41FE9BA3.BE2896C3@gte.net> (raw)
In-Reply-To: C925F8B43D79CC49ACD0601FB68FF50C0301425C@orsmsx408
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/
next prev parent reply other threads:[~2005-01-31 20:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-31 19:26 2.4.29, e100 and a WOL packet causes keventd going mad Brandeburg, Jesse
2005-01-31 20:57 ` Bukie Mabayoje [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-01-30 17:18 David Härdeman
2005-01-31 3:47 ` Scott Feldman
2005-01-31 3:58 ` Nigel Cunningham
2005-01-31 5:00 ` Scott Feldman
2005-01-31 6:14 ` Nigel Cunningham
2005-01-31 9:08 ` Nigel Cunningham
2005-01-31 4:23 ` Bukie Mabayoje
2005-01-31 15:24 ` Marcelo Tosatti
2005-01-31 20:29 ` David Härdeman
2005-01-31 21:13 ` Bukie Mabayoje
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41FE9BA3.BE2896C3@gte.net \
--to=bukiemab@gte.net \
--cc=david@2gen.com \
--cc=jesse.brandeburg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ncunningham@linuxmail.org \
--cc=netdev@oss.sgi.com \
--cc=sfeldma@pobox.com \
--cc=simigern@stud.uni-erlangen.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).