Marcelo Tosatti wrote:
> On Sun, Jan 30, 2005 at 08:23:47PM -0800, Bukie Mabayoje wrote:
> >
> > Scott Feldman wrote:
> >
> > > On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
> > > > I experience the same problems as reported by Michael Gernoth when
> > > > sending a WOL-packet to computer
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
On Mon, Jan 31, 2005 at 01:24:31PM -0200, Marcelo Tosatti wrote:
On Sun, Jan 30, 2005 at 08:23:47PM -0800, Bukie Mabayoje wrote:
Scott Feldman wrote:
David, would you give this patch a try? Make sure the system still
wakes from a magic packet if suspended or shut down, and doesn't cause
kacpid to
>+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 |
On Sun, Jan 30, 2005 at 08:23:47PM -0800, Bukie Mabayoje wrote:
>
> Scott Feldman wrote:
>
> > On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
> > > I experience the same problems as reported by Michael Gernoth when
> > > sending a WOL-packet to computer with a e100 NIC which is already
> > >
Hi again.
Ignore that :> I realised later that there's only one badly named
routine and my assumption that there was another called disable_.. was
wrong :>
Nigel
On Mon, 2005-01-31 at 17:14, Nigel Cunningham wrote:
> Hi.
>
> On Mon, 2005-01-31 at 16:00, Scott Feldman wrote:
> > On Sun,
On Mon, Jan 31, 2005 at 01:24:31PM -0200, Marcelo Tosatti wrote:
On Sun, Jan 30, 2005 at 08:23:47PM -0800, Bukie Mabayoje wrote:
Scott Feldman wrote:
David, would you give this patch a try? Make sure the system still
wakes from a magic packet if suspended or shut down, and doesn't cause
kacpid to
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
Marcelo Tosatti wrote:
On Sun, Jan 30, 2005 at 08:23:47PM -0800, Bukie Mabayoje wrote:
Scott Feldman wrote:
On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
I experience the same problems as reported by Michael Gernoth when
sending a WOL-packet to computer with a e100 NIC
On Sun, Jan 30, 2005 at 08:23:47PM -0800, Bukie Mabayoje wrote:
Scott Feldman wrote:
On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
I experience the same problems as reported by Michael Gernoth when
sending a WOL-packet to computer with a e100 NIC which is already
powered on.
+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 |
Hi again.
Ignore that : I realised later that there's only one badly named
routine and my assumption that there was another called disable_.. was
wrong :
Nigel
On Mon, 2005-01-31 at 17:14, Nigel Cunningham wrote:
Hi.
On Mon, 2005-01-31 at 16:00, Scott Feldman wrote:
On Sun, 2005-01-30 at
Hi.
On Mon, 2005-01-31 at 16:00, Scott Feldman wrote:
> On Sun, 2005-01-30 at 19:58, Nigel Cunningham wrote:
> > Do you also disable the WOL event when resuming?
>
> Good catch. How's this look?
I looked at it last week because I used it for an example of device
model drivers at the CELF
On Sun, 2005-01-30 at 19:58, Nigel Cunningham wrote:
> Do you also disable the WOL event when resuming?
Good catch. How's this look?
--- linux-2.6.11-rc2/drivers/net/e100.c.orig2005-01-30 19:13:56.850497376
-0800
+++ linux-2.6.11-rc2/drivers/net/e100.c 2005-01-30 20:53:22.630560952 -0800
Scott Feldman wrote:
> On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
> > I experience the same problems as reported by Michael Gernoth when
> > sending a WOL-packet to computer with a e100 NIC which is already
> > powered on.
>
> I didn't look at the 2.4 case, but for 2.6, it seems e100 was
Hi.
Do you also disable the WOL event when resuming?
Regards,
Nigel
On Mon, 2005-01-31 at 14:47, Scott Feldman wrote:
> On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
> > I experience the same problems as reported by Michael Gernoth when
> > sending a WOL-packet to computer with a e100
On Sun, 2005-01-30 at 09:18, David HÃrdeman wrote:
> I experience the same problems as reported by Michael Gernoth when
> sending a WOL-packet to computer with a e100 NIC which is already
> powered on.
I didn't look at the 2.4 case, but for 2.6, it seems e100 was enabling
PME wakeup during
Hi,
I experience the same problems as reported by Michael Gernoth when
sending a WOL-packet to computer with a e100 NIC which is already
powered on.
In my case, it's running kernel 2.6.8.1 and the NIC is identified by
lspci as:
:02:08.0 Ethernet controller: Intel Corp. 82562EZ 10/100
On Sat, Jan 29, 2005 at 04:18:21PM -0200, Marcelo Tosatti wrote:
> Probably a task event is rescheduling itself repeatedly? e100 does not seem
> to schedule_task() events directly, so I wonder what is going on.
>
> Can you boot a machine with profile=2, then send the WOL packet causing
> keventd
Hi.
On Mon, 2005-01-31 at 16:00, Scott Feldman wrote:
On Sun, 2005-01-30 at 19:58, Nigel Cunningham wrote:
Do you also disable the WOL event when resuming?
Good catch. How's this look?
I looked at it last week because I used it for an example of device
model drivers at the CELF
On Sun, 2005-01-30 at 19:58, Nigel Cunningham wrote:
Do you also disable the WOL event when resuming?
Good catch. How's this look?
--- linux-2.6.11-rc2/drivers/net/e100.c.orig2005-01-30 19:13:56.850497376
-0800
+++ linux-2.6.11-rc2/drivers/net/e100.c 2005-01-30 20:53:22.630560952 -0800
@@
Scott Feldman wrote:
On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
I experience the same problems as reported by Michael Gernoth when
sending a WOL-packet to computer with a e100 NIC which is already
powered on.
I didn't look at the 2.4 case, but for 2.6, it seems e100 was enabling
On Fri, Jan 28, 2005 at 05:48:11PM +0100, Michael Gernoth wrote:
> Hi,
>
> we have about 70 P4 uniprocessor machines (some with Hyperthreading
> capable CPUs) running linux 2.4.29, which are woken up on the weekdays
> by sending a WOL packet to them. The machines all have a E100 nic with
> WOL
Michael Gernoth wrote:
> On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
> > Do you know the official NIC product name e.g Pro/100B. I need to identify
> > the LAN Controller. There are differences between 557 (not sure if 557 can
> > do WOL), 558 and 559 how they ASSERT the
Michael Gernoth wrote:
On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
Do you know the official NIC product name e.g Pro/100B. I need to identify
the LAN Controller. There are differences between 557 (not sure if 557 can
do WOL), 558 and 559 how they ASSERT the PME#
On Fri, Jan 28, 2005 at 05:48:11PM +0100, Michael Gernoth wrote:
Hi,
we have about 70 P4 uniprocessor machines (some with Hyperthreading
capable CPUs) running linux 2.4.29, which are woken up on the weekdays
by sending a WOL packet to them. The machines all have a E100 nic with
WOL enabled
Michael Gernoth wrote:
> On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
> > Do you know the official NIC product name e.g Pro/100B. I need to identify
> > the LAN Controller. There are differences between 557 (not sure if 557 can
> > do WOL), 558 and 559 how they ASSERT the
On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
> Do you know the official NIC product name e.g Pro/100B. I need to identify
> the LAN Controller. There are differences between 557 (not sure if 557 can
> do WOL), 558 and 559 how they ASSERT the PME# signal. Even the same chip have
Michael Gernoth wrote:
> Hi,
>
> we have about 70 P4 uniprocessor machines (some with Hyperthreading
> capable CPUs) running linux 2.4.29, which are woken up on the weekdays
> by sending a WOL packet to them. The machines all have a E100 nic with
> WOL enabled in the bios. The E100 driver is
Michael Gernoth wrote:
Hi,
we have about 70 P4 uniprocessor machines (some with Hyperthreading
capable CPUs) running linux 2.4.29, which are woken up on the weekdays
by sending a WOL packet to them. The machines all have a E100 nic with
WOL enabled in the bios. The E100 driver is compiled
On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
Do you know the official NIC product name e.g Pro/100B. I need to identify
the LAN Controller. There are differences between 557 (not sure if 557 can
do WOL), 558 and 559 how they ASSERT the PME# signal. Even the same chip have
Michael Gernoth wrote:
On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
Do you know the official NIC product name e.g Pro/100B. I need to identify
the LAN Controller. There are differences between 557 (not sure if 557 can
do WOL), 558 and 559 how they ASSERT the PME#
32 matches
Mail list logo
