WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e
Philipp Matthias Hahn
Somewhere between 2.6.26 and 2.6.27 WOL stopped working on my MS-7350
motherboard with an "nVidia Corporation MCP51 Ethernet Controller (rev a3)".
"etherwake 00:19:db:f2:e1:35" did not work
"etherwake 35:e1:f2:db:19:00" did work
Since I did a BIOS update during the same time window I (wrongly) put
the fault on the BIOS. (See /sys/class/dmi/id/modalias for yourself:
dmi:bvnAmericanMegatrendsInc.:bvrV1.7:bd07/29/2008:svnMSI:pnMS-7350:pvr1.0:rvnMSI:rnMS-7350:rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
)
Today I finally found the time to test various old versions of
"drivers/net/forcedeth.c" and also did a "git-bisect v2.6.26 v2.6.27"
which lead to the following culprit:
f55c21fd9a92a444e55ad1ca4e4732d56661bf2e is first bad commit
commit f55c21fd9a92a444e55ad1ca4e4732d56661bf2e
Author: Yinghai Lu <yhlu....@gmail.com>
Date: Sat Sep 13 13:10:31 2008 -0700
forcedeth: call restore mac addr in nv_shutdown path
after
| commit f735a2a1a4f2a0f5cd823ce323e82675990469e2
| Author: Tobias Diedrich <ranma+...@tdiedrich.de>
| Date: Sun May 18 15:02:37 2008 +0200
|
| [netdrvr] forcedeth: setup wake-on-lan before shutting down
|
| When hibernating in 'shutdown' mode, after saving the image the suspend hook
| is not called again.
| However, if the device is in promiscous mode, wake-on-lan will not work.
| This adds a shutdown hook to setup wake-on-lan before the final shutdown.
|
| Signed-off-by: Tobias Diedrich <ranma+...@tdiedrich.de>
| Signed-off-by: Jeff Garzik <jga...@redhat.com>
my servers with nvidia ck804 and mcp55 will reverse mac address with kexec.
it turns out that we need to restore the mac addr in nv_shutdown().
[ak...@linux-foundation.org: fix typo in printk]
Signed-off-by: Yinghai Lu <yhlu....@gmail.com>
Cc: Tobias Diedrich <ranma+...@tdiedrich.de>
Cc: Ayaz Abdulla <aabd...@nvidia.com>
Cc: Jeff Garzik <je...@garzik.org>
Cc: "Rafael J. Wysocki" <r...@sisk.pl>
Signed-off-by: Andrew Morton <ak...@linux-foundation.org>
Signed-off-by: Jeff Garzik <jga...@redhat.com>
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 0b6ecef..eeb55ed 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -5643,6 +5643,7 @@ static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_i
dev->dev_addr[4] = (np->orig_mac[0] >> 8) & 0xff;
dev->dev_addr[5] = (np->orig_mac[0] >> 0) & 0xff;
writel(txreg|NVREG_TRANSMITPOLL_MAC_ADDR_REV, base + NvRegTransmitPoll);
+ printk(KERN_DEBUG "nv_probe: set workaround bit for reversed mac addr\n");
}
memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
@@ -5890,14 +5891,12 @@ static void nv_restore_phy(struct net_device *dev)
}
}
-static void __devexit nv_remove(struct pci_dev *pci_dev)
+static void nv_restore_mac_addr(struct pci_dev *pci_dev)
{
struct net_device *dev = pci_get_drvdata(pci_dev);
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
- unregister_netdev(dev);
-
/* special op: write back the misordered MAC address - otherwise
* the next nv_probe would see a wrong address.
*/
@@ -5905,6 +5904,15 @@ static void __devexit nv_remove(struct pci_dev *pci_dev)
writel(np->orig_mac[1], base + NvRegMacAddrB);
writel(readl(base + NvRegTransmitPoll) & ~NVREG_TRANSMITPOLL_MAC_ADDR_REV,
base + NvRegTransmitPoll);
+}
+
+static void __devexit nv_remove(struct pci_dev *pci_dev)
+{
+ struct net_device *dev = pci_get_drvdata(pci_dev);
+
+ unregister_netdev(dev);
+
+ nv_restore_mac_addr(pci_dev);
/* restore any phy related changes */
nv_restore_phy(dev);
@@ -5975,6 +5983,8 @@ static void nv_shutdown(struct pci_dev *pdev)
if (netif_running(dev))
nv_close(dev);
+ nv_restore_mac_addr(pdev);
+
pci_disable_device(pdev);
if (system_state == SYSTEM_POWER_OFF) {
if (pci_enable_wake(pdev, PCI_D3cold, np->wolenabled))
:040000 040000 8c603aa1f71b79f3f4a94bef066a830a249c8d2a e85d84f3c509421a33fd4b71bacddeb4b9fbe896 M drivers
Reverting that patch on top of drivers/net/forcedeth.c from 2.6.28.2
resolves the problem for me.
I DON'T use kexec, just simple poweroff.
BYtE
Philipp
--
/ / (_)__ __ ____ __ Philipp Hahn
/ /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmh...@titan.lahn.de
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Yinghai Lu
<pmh...@titan.lahn.de> wrote:
> Hello!
>
> Somewhere between 2.6.26 and 2.6.27 WOL stopped working on my MS-7350
> motherboard with an "nVidia Corporation MCP51 Ethernet Controller (rev a3)".
> "etherwake 00:19:db:f2:e1:35" did not work
> "etherwake 35:e1:f2:db:19:00" did work
> Since I did a BIOS update during the same time window I (wrongly) put
> the fault on the BIOS. (See /sys/class/dmi/id/modalias for yourself:
> dmi:bvnAmericanMegatrendsInc.:bvrV1.7:bd07/29/2008:svnMSI:pnMS-7350:pvr1.0:rvnMSI:rnMS-7350:rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
> )
>
> Today I finally found the time to test various old versions of
> "drivers/net/forcedeth.c" and also did a "git-bisect v2.6.26 v2.6.27"
> which lead to the following culprit:
>
can not find the reason why the WOL doesn't work...
please post
1. boot log for just after AC is pluged-in... ===> you should have
"nv_probe: set workaround bit for reversed mac addr"
2. and boot log after boot from WOL...==> you have have "nv_probe: set
workaround bit for reversed mac addr" too.
YH
Yinghai Lu
> On Wed, Jan 28, 2009 at 10:31 PM, Philipp Matthias Hahn
> <pmh...@titan.lahn.de> wrote:
>> Hello!
>>
>> Somewhere between 2.6.26 and 2.6.27 WOL stopped working on my MS-7350
>> motherboard with an "nVidia Corporation MCP51 Ethernet Controller (rev a3)".
>> "etherwake 00:19:db:f2:e1:35" did not work
>> "etherwake 35:e1:f2:db:19:00" did work
looks like your BIOS, already reverse the MAC addr...
please check attached ... Rafael, wonder if will break suspend/resume...
YH
Rafael J. Wysocki
Well, it doesn't look like it's going to, but testing is necessary.
Thanks,
Rafael
Tobias Diedrich
> Somewhere between 2.6.26 and 2.6.27 WOL stopped working on my MS-7350
> motherboard with an "nVidia Corporation MCP51 Ethernet Controller (rev a3)".
> "etherwake 00:19:db:f2:e1:35" did not work
> "etherwake 35:e1:f2:db:19:00" did work
> Since I did a BIOS update during the same time window I (wrongly) put
> the fault on the BIOS. (See /sys/class/dmi/id/modalias for yourself:
> dmi:bvnAmericanMegatrendsInc.:bvrV1.7:bd07/29/2008:svnMSI:pnMS-7350:pvr1.0:rvnMSI:rnMS-7350:rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
> )
Hmm, I had not tried WOL for some time.
With 2.6.29-rc3 is see the following behaviour:
State WOL Behaviour
------------------------------
shutdown reversed MAC
disk/shutdown reversed MAC
disk/platform OK
Apparently nv_restore_mac_addr() restores the MAC in the wrong order
for WOL (at least for my PCI_DEVICE_ID_NVIDIA_NVENET_15). platform
works, because the MAC is not touched in the nv_suspend() path.
A possible fix might be to only call nv_restore_mac_addr() if
system_state != SYSTEM_POWER_OFF.
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
Tobias Diedrich
> Philipp Matthias Hahn wrote:
> > Somewhere between 2.6.26 and 2.6.27 WOL stopped working on my MS-7350
> > motherboard with an "nVidia Corporation MCP51 Ethernet Controller (rev a3)".
> > "etherwake 00:19:db:f2:e1:35" did not work
> > "etherwake 35:e1:f2:db:19:00" did work
> > Since I did a BIOS update during the same time window I (wrongly) put
> > the fault on the BIOS. (See /sys/class/dmi/id/modalias for yourself:
> > dmi:bvnAmericanMegatrendsInc.:bvrV1.7:bd07/29/2008:svnMSI:pnMS-7350:pvr1.0:rvnMSI:rnMS-7350:rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
> > )
>
> Hmm, I had not tried WOL for some time.
> With 2.6.29-rc3 is see the following behaviour:
>
> State WOL Behaviour
> ------------------------------
> shutdown reversed MAC
> disk/shutdown reversed MAC
> disk/platform OK
>
> Apparently nv_restore_mac_addr() restores the MAC in the wrong order
> for WOL (at least for my PCI_DEVICE_ID_NVIDIA_NVENET_15). platform
> works, because the MAC is not touched in the nv_suspend() path.
>
> A possible fix might be to only call nv_restore_mac_addr() if
> system_state != SYSTEM_POWER_OFF.
With the following patch:
shutdown OK
disk/shutdown OK
disk/platform OK
kexec OK
Signed-off-by: Tobias Diedrich <ranma+...@tdiedrich.de>
Index: linux-2.6.29-rc3/drivers/net/forcedeth.c
===================================================================
--- linux-2.6.29-rc3.orig/drivers/net/forcedeth.c 2009-02-08 16:31:29.000000000 +0100
+++ linux-2.6.29-rc3/drivers/net/forcedeth.c 2009-02-08 16:39:58.000000000 +0100
@@ -6011,9 +6011,20 @@
if (netif_running(dev))
nv_close(dev);
- nv_restore_mac_addr(pdev);
+ /*
+ * Restore the MAC so a kernel started by kexec won't get confused.
+ * If we really go for poweroff, we must not restore the MAC,
+ * otherwise the MAC for WOL will be reversed at least on some boards.
+ */
+ if (system_state != SYSTEM_POWER_OFF) {
+ nv_restore_mac_addr(pdev);
+ }
pci_disable_device(pdev);
+ /*
+ * Apparently it is not possible to reinitialise from D3 hot,
+ * only put the device into D3 if we really go for poweroff.
+ */
if (system_state == SYSTEM_POWER_OFF) {
if (pci_enable_wake(pdev, PCI_D3cold, np->wolenabled))
pci_enable_wake(pdev, PCI_D3hot, np->wolenabled);
Philipp Matthias Hahn
On Sun, Feb 08, 2009 at 05:52:17PM +0100, Tobias Diedrich wrote:
> Tobias Diedrich wrote:
> > Philipp Matthias Hahn wrote:
> > > Somewhere between 2.6.26 and 2.6.27 WOL stopped working on my MS-7350
> > > motherboard with an "nVidia Corporation MCP51 Ethernet Controller (rev a3)".
> > > "etherwake 00:19:db:f2:e1:35" did not work
> > > "etherwake 35:e1:f2:db:19:00" did work
...
> With the following patch:
> shutdown OK
> disk/shutdown OK
> disk/platform OK
> kexec OK
Your patch seems to work for my system, too. (Expect for the case where
I do "poweroff" from busybox or do Alt-SysRq-O; Debians version works,
as long as I remove the '-i' option:
-i Shut down all network interfaces just before halt or reboot.
> Signed-off-by: Tobias Diedrich <ranma+...@tdiedrich.de>
Tested-by: Philipp Matthias Hahn <pmh...@titan.lahn.de>
BYtE
Philipp
--
/ / (_)__ __ ____ __ Philipp Hahn
/ /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmh...@titan.lahn.de