3c59x.c patch to 2.6.18 fixing Wake on Lan (WOL)

3c59x.c patch to 2.6.18 fixing Wake on Lan (WOL)

[Harry Coin]

Hello all.

The 3c59x.c in kernel 2.6.18 (and as I see later ones too) attempts
to enable PME from the already awake D0 state. The PME config space on Dell 
Optiplexs
for this chip has a zero in the capabilities for this bit-- no 'wake from d0'.

The pci_enable_wake in 2.6.18 tests the capabilities before enabling PME,
so the pci_wake call fails, its result is not tested, so no error is reported.

The routine changes the wake request from 0 to D3_hot.  This fix
causes wake on lan (WOL) to work properly on older Dell Optiplex models.

Kindly overlook newbie mistakes.  Thank you.

Harry Coin
Bettendorf, Iowa


--- drivers-orig/3c59x.c        2007-01-15 00:03:52.000000000 -0600
+++ drivers-fixed/3c59x.c       2007-01-15 00:46:37.000000000 -0600
@@ -3090,8 +3090,8 @@
  /* Set Wake-On-LAN mode and put the board into D3 (power-down) state. */
  static void acpi_set_WOL(struct net_device *dev)
  {
-       struct vortex_private *vp = netdev_priv(dev);
-       void __iomem *ioaddr = vp->ioaddr;
+  struct vortex_private *vp = netdev_priv(dev);
+  void __iomem *ioaddr = vp->ioaddr;

         if (vp->enable_wol) {
                 /* Power up on: 1==Downloaded Filter, 2==Magic Packets, 
4==Link Status. */
@@ -3101,7 +3101,7 @@
                 iowrite16(SetRxFilter|RxStation|RxMulticast|RxBroadcast, 
ioaddr + EL3_CMD);
                 iowrite16(RxEnable, ioaddr + EL3_CMD);

-               pci_enable_wake(VORTEX_PCI(vp), 0, 1);
+               pci_enable_wake(VORTEX_PCI(vp),PCI_D3hot,1);

                 /* Change the power state to D3; RxEnable doesn't take 
effect. */
                 pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot);

Re: 3c59x.c patch to 2.6.18 fixing Wake on Lan (WOL)

[Dan Williams]

On Mon, 2007-01-15 at 09:12 -0600, Harry Coin wrote:
> Hello all.
> 
> The 3c59x.c in kernel 2.6.18 (and as I see later ones too) attempts
> to enable PME from the already awake D0 state. The PME config space on Dell 
> Optiplexs
> for this chip has a zero in the capabilities for this bit-- no 'wake from d0'.
> 
> The pci_enable_wake in 2.6.18 tests the capabilities before enabling PME,
> so the pci_wake call fails, its result is not tested, so no error is reported.
> 
> The routine changes the wake request from 0 to D3_hot.  This fix
> causes wake on lan (WOL) to work properly on older Dell Optiplex models.
> 
> Kindly overlook newbie mistakes.  Thank you.

You'll want to include a line like:

Signed-off-by: Harry Coin <your email here>

which signifies that you are legally able to contribute the attached
patch under the GPL license.  Do this right before the start of the
patch (where you put your signature in the previous mail).

Dan

> Harry Coin
> Bettendorf, Iowa
> 
> 
> --- drivers-orig/3c59x.c        2007-01-15 00:03:52.000000000 -0600
> +++ drivers-fixed/3c59x.c       2007-01-15 00:46:37.000000000 -0600
> @@ -3090,8 +3090,8 @@
>   /* Set Wake-On-LAN mode and put the board into D3 (power-down) state. */
>   static void acpi_set_WOL(struct net_device *dev)
>   {
> -       struct vortex_private *vp = netdev_priv(dev);
> -       void __iomem *ioaddr = vp->ioaddr;
> +  struct vortex_private *vp = netdev_priv(dev);
> +  void __iomem *ioaddr = vp->ioaddr;
> 
>          if (vp->enable_wol) {
>                  /* Power up on: 1==Downloaded Filter, 2==Magic Packets, 
> 4==Link Status. */
> @@ -3101,7 +3101,7 @@
>                  iowrite16(SetRxFilter|RxStation|RxMulticast|RxBroadcast, 
> ioaddr + EL3_CMD);
>                  iowrite16(RxEnable, ioaddr + EL3_CMD);
> 
> -               pci_enable_wake(VORTEX_PCI(vp), 0, 1);
> +               pci_enable_wake(VORTEX_PCI(vp),PCI_D3hot,1);
> 
>                  /* Change the power state to D3; RxEnable doesn't take 
> effect. */
>                  pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot);
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 3c59x.c patch to 2.6.18 fixing Wake on Lan (WOL)

[Harry Coin]

At 11:00 AM 1/15/2007 -0500, Dan Williams wrote:
>On Mon, 2007-01-15 at 09:12 -0600, Harry Coin wrote:
> > Hello all.
> >
> > The 3c59x.c in kernel 2.6.18 (and as I see later ones too) attempts
> > to enable PME from the already awake D0 state. The PME config space on 
> Dell
> > Optiplexs
> > for this chip has a zero in the capabilities for this bit-- no 'wake 
> from d0'.
> >
> > The pci_enable_wake in 2.6.18 tests the capabilities before enabling PME,
> > so the pci_wake call fails, its result is not tested, so no error is 
> reported.
> >
> > The routine changes the wake request from 0 to D3_hot.  This fix
> > causes wake on lan (WOL) to work properly on older Dell Optiplex models.
> >
> > Kindly overlook newbie mistakes.  Thank you.
>
>You'll want to include a line like:
>
>Signed-off-by: Harry Coin <your email here>
>
>which signifies that you are legally able to contribute the attached
>patch under the GPL license.  Do this right before the start of the
>patch (where you put your signature in the previous mail).
>
>Dan

  Thank you.  I've added it to a repeat of the original posting copied below.

> >
> >
> > --- drivers-orig/3c59x.c        2007-01-15 00:03:52.000000000 -0600
> > +++ drivers-fixed/3c59x.c       2007-01-15 00:46:37.000000000 -0600
> > @@ -3090,8 +3090,8 @@
> >   /* Set Wake-On-LAN mode and put the board into D3 (power-down) state. */
> >   static void acpi_set_WOL(struct net_device *dev)
> >   {
> > -       struct vortex_private *vp = netdev_priv(dev);
> > -       void __iomem *ioaddr = vp->ioaddr;
> > +  struct vortex_private *vp = netdev_priv(dev);
> > +  void __iomem *ioaddr = vp->ioaddr;
> >
> >          if (vp->enable_wol) {
> >                  /* Power up on: 1==Downloaded Filter, 2==Magic Packets,
> > 4==Link Status. */
> > @@ -3101,7 +3101,7 @@
> >                  iowrite16(SetRxFilter|RxStation|RxMulticast|RxBroadcast,
> > ioaddr + EL3_CMD);
> >                  iowrite16(RxEnable, ioaddr + EL3_CMD);
> >
> > -               pci_enable_wake(VORTEX_PCI(vp), 0, 1);
> > +               pci_enable_wake(VORTEX_PCI(vp),PCI_D3hot,1);
> >
> >                  /* Change the power state to D3; RxEnable doesn't take
> > effect. */
> >                  pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot);
> >
> > Harry Coin
> > Bettendorf, Iowa
Signed-off-by: Harry Coin hcoin@n4comm.com

e100.c patch to 2.6.18 fixing Wake on Lan (WOL)

[Harry Coin]

Hello from Iowa.

Below please find a fix to the Wake On Lan function in the e100.c (intel 
10/100) driver.   With the original driver distributed in kernel 2.6.18 in 
debian etch, wake on lan did not work.   This was tested on 14 dell 
optiplexes with built-in ethernet chips in a totally diskless environment 
(initramfs / pxelinux).  All operations were normal save wake on lan.

When WOL has been enabled with ethtools, the old driver assumes wrongly 
that e100_configure will be called at least once with !netif_running.  Only 
in that instance will it set the chip to notice 'magic' wol packets if the 
ethtools -s wol g has been called prior.

The old e100_down routine never does call e100_configure so that the driver 
never does  turn off the 'disable WOL magic packet' bit.
Neither does the .shutdown routine.   This fix tries to only enable the WOL 
recognition only when e100_down is called for the last time
before module unload or system shutdown, while leaving ifconfig down 
untouched.    (testing for being run in the context of dev->stop).

Notice that the hw_reset routine is called in the old e100_down, and that 
silently causes WOL to be reset.  In some attempt to avoid this debian (and 
I don't know which other sysvinit tools) added a NETDOWN define to the 
/etc/init.d/halt script, which when changed from the default=yes to 'no' 
avoids the -i option to 'halt' leaving the e100 configured.

With the below fix the default in /etc/init.d/halt is required, the define 
change is not necessary, in fact it is important that halt call down for 
wol to work.  (In the case of the old e100 driver it didn't matter either 
way, as e100_configure was never called once the driver was stopped).

Notice that the binary /sbin/halt in debain etch has a bug and in fact 
never does call ifdown, whether -i is or isn't specified.   Compiling from 
the source by hand does work.  I have submitted a bug report for this.

A further e100 fix I didn't add was for .shutdown to check whether the 
driver was down and to call e100_down if it was still up.   That added fix 
would make sure WOL would work no matter if the halt script did or didn't 
down the driver before system shutdown.    I'm not sure what the 
implications of my fix are in the context of sleep /resume.

I have also submitted the above to the e1000 group at intel privately as 
they are the 'maintainers', but this appears to be the only apropos open 
group I thought to note he here as well.

Thanks


Harry Coin
N4 Communications
Bettendorf, Iowa
Signed-off-by: Harry Coin hcoin@n4comm.com



--- drivers-orig/e100.c 2007-01-15 00:01:48.000000000 -0600
+++ drivers-fixed/e100.c        2007-01-14 23:32:08.000000000 -0600
@@ -2088,10 +2088,26 @@
  static void e100_down(struct nic *nic)
  {
-       /* wait here for poll to complete */
-       netif_poll_disable(nic->netdev);
-       netif_stop_queue(nic->netdev);
-       e100_hw_reset(nic);
+    if ((!netif_running(nic->netdev)) && (nic->flags & wol_magic)) {
+      /* if this is a device close, and not an ifdown, and wol is enabled, */
+      /* then turn off the bit disabling wol magic packet recognition on */
+      /* the chip.  Previously, WOL magic packet recognition was never */
+      /* enabled as e100_down never called e100_configure when */
+      /* nif_running was false.   So: */
+      /* This makes the e100 not only work with WOL, but */
+      /* also avoids having to edit the default NETDOWN variable */
+      /* in /etc/init.d/halt from the default 'yes' to 'no'. */
+      e100_exec_cb(nic, NULL, e100_configure);
+         /* wait here for poll to complete */
+         netif_poll_disable(nic->netdev);
+         netif_stop_queue(nic->netdev);
+      e100_disable_irq(nic);
+    } else {
+         /* wait here for poll to complete */
+         netif_poll_disable(nic->netdev);
+         netif_stop_queue(nic->netdev);
+         e100_hw_reset(nic);
+   }
         free_irq(nic->pdev->irq, nic->netdev);
         del_timer_sync(&nic->watchdog);
         netif_carrier_off(nic->netdev);
@@ -2099,6 +2115,7 @@
         e100_rx_clean_list(nic);
  }
+
  static void e100_tx_timeout(struct net_device *netdev)
  {
         struct nic *nic = netdev_priv(netdev);

Re: e100.c patch to 2.6.18 fixing Wake on Lan (WOL)

[Auke Kok]

Harry Coin wrote:
> Hello from Iowa.
> 
> Below please find a fix to the Wake On Lan function in the e100.c (intel 
> 10/100) driver.   With the original driver distributed in kernel 2.6.18 
> in debian etch, wake on lan did not work.   This was tested on 14 dell 
> optiplexes with built-in ethernet chips in a totally diskless 
> environment (initramfs / pxelinux).  All operations were normal save 
> wake on lan.

Oi,

I've done quite a bit of work especially on that since 2.6.18 and as far as I could see 
those changes fixed WoL, suspend/resume and netconsole, as was confirmed by Andrew 
Morton even.

Have you tried the version in 2.6.19?

> When WOL has been enabled with ethtools, the old driver assumes wrongly 
> that e100_configure will be called at least once with !netif_running.  
> Only in that instance will it set the chip to notice 'magic' wol packets 
> if the ethtools -s wol g has been called prior.
> 
> The old e100_down routine never does call e100_configure so that the 
> driver never does  turn off the 'disable WOL magic packet' bit.
> Neither does the .shutdown routine.   This fix tries to only enable the 
> WOL recognition only when e100_down is called for the last time
> before module unload or system shutdown, while leaving ifconfig down 
> untouched.    (testing for being run in the context of dev->stop).

that's exactly what my patches should fix as far as I can remember

> I have also submitted the above to the e1000 group at intel privately as 
> they are the 'maintainers', but this appears to be the only apropos open 
> group I thought to note he here as well.

I have not seen this patch before, care to Cc me to that? We also publically discuss 
e1000/e100 and ixgb issues on e1000-devel@lists.sourceforge.net. Feel free to Cc that list.

Cheers,

Auke

Re: e100.c patch to 2.6.18 fixing Wake on Lan (WOL)

[Harry Coin]

At 10:19 AM 1/15/2007 -0800, Auke Kok wrote:
>Have you tried the version in 2.6.19?

I even tried copying and pasting the e100_down and the latest PM stuff from 
the newest e100.c version on sourceforge.   I admit to being defeated as to 
how to join a sourceforge group.   Too many hours writing Microsoft 
drivers  maybe?

It comes down to this:

1)  The e100_configure command is the only place that turns off the WOL 
disable bit.

2)  That bit is only turned off if e100_configure is called after 
netif_running is false and wol is set.

3)  e100_configure is not called at any point after dev->stop (the first 
moment netif_running is false) through the end of .shutdown.  Therefore WOL 
disable is always turned on, no matter the request by ethtools.

I sense there is a sense that if pci_enable_wake has been called properly, 
then all's well.   But on this board, there is a configuration bit that 
also has to be disabled, a but that is silently reset during a hw_reset, 
and hw_reset   __is__ called in e100_down.

Hence, the fix I submitted.   I know it isn't perfect because I'm not 
intimately familiar with the dynamics of this chip.   But I do know this:

14 Dell Optiplex systems failed to WOL with the stock 2.6.18 distributed 
with debian etch.   After my patch is applied to e100.c, and no other 
changes from anything default in 2.6.18 and debian etch, it works perfectly 
every time.   I should have added that ACPI and lapic are in use, but 
that's the usual case.

Cheers,

Harry Coin
N4 Communications
Bettendorf, Iowa

Re: e100.c patch to 2.6.18 fixing Wake on Lan (WOL)

[Auke Kok]

Harry Coin wrote:
> At 10:19 AM 1/15/2007 -0800, Auke Kok wrote:
>> Have you tried the version in 2.6.19?
> 
> I even tried copying and pasting the e100_down and the latest PM stuff 
> from the newest e100.c version on sourceforge.   I admit to being 
> defeated as to how to join a sourceforge group.   Too many hours writing 
> Microsoft drivers  maybe?

the list is open to posting, so that's fairly easy.

> It comes down to this:
> 
> 1)  The e100_configure command is the only place that turns off the WOL 
> disable bit.
> 
> 2)  That bit is only turned off if e100_configure is called after 
> netif_running is false and wol is set.
> 
> 3)  e100_configure is not called at any point after dev->stop (the first 
> moment netif_running is false) through the end of .shutdown.  Therefore 
> WOL disable is always turned on, no matter the request by ethtools.
> 
> I sense there is a sense that if pci_enable_wake has been called 
> properly, then all's well.   But on this board, there is a configuration 
> bit that also has to be disabled, a but that is silently reset during a 
> hw_reset, and hw_reset   __is__ called in e100_down.
> 
> Hence, the fix I submitted.   I know it isn't perfect because I'm not 
> intimately familiar with the dynamics of this chip.   But I do know this:
> 
> 14 Dell Optiplex systems failed to WOL with the stock 2.6.18 distributed 
> with debian etch.   After my patch is applied to e100.c, and no other 
> changes from anything default in 2.6.18 and debian etch, it works 
> perfectly every time.   I should have added that ACPI and lapic are in 
> use, but that's the usual case.

okay, I don't necesary meant that your patch is incorrect, however we need to make sure 
that your patch doesn't break 2.6.19, because that code is already upstream.

on top of that, both patches might be needed, and I suspect that is the case to keep 
suspend and netconsole to keep working, so I would still like to ask you to test 2.6.19, 
with and without your patch.

I'll do the same here and push your patch to Garzik if (after testing) we're both OK 
with it.

Thanks,

Auke