diff options
author | Tobias Diedrich <ranma+kernel@tdiedrich.de> | 2009-02-16 03:13:20 -0500 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2009-02-16 03:13:20 -0500 |
commit | 34edaa88324004baf4884fb0388f86059d9c4878 (patch) | |
tree | 9e042713b2084cdf7d307668aae8bfcab6f51867 /drivers | |
parent | 1d7b33f77b2d8b0b1ee767e6f8f05cbd9d72cb7c (diff) |
net: forcedeth: Fix wake-on-lan regression
Commit f55c21fd9a92a444e55ad1ca4e4732d56661bf2e ("forcedeth: call
restore mac addr in nv_shutdown path"), which was introduced to fix
the regression tracked at
http://bugzilla.kernel.org/show_bug.cgi?id=11358 causes the
wake-on-lan mac to be reversed in the shutdown path. Apparently the
forcedeth situation is rather messy in that the mac we need to
writeback for a subsequent modprobe to work is exactly the reverse of
what is needed for proper wake-on-lan.
The following patch explains the situation in the comments and
makes the call to nv_restore_mac_addr() conditional (only called if
we are not really going for poweroff).
Tobias Diedrich wrote:
> 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+kernel@tdiedrich.de>
Tested-by: Philipp Matthias Hahn <pmhahn@titan.lahn.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers')
-rw-r--r-- | drivers/net/forcedeth.c | 13 |
1 files changed, 12 insertions, 1 deletions
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c index 5b910cf63740..b8251e827059 100644 --- a/drivers/net/forcedeth.c +++ b/drivers/net/forcedeth.c | |||
@@ -6011,9 +6011,20 @@ static void nv_shutdown(struct pci_dev *pdev) | |||
6011 | if (netif_running(dev)) | 6011 | if (netif_running(dev)) |
6012 | nv_close(dev); | 6012 | nv_close(dev); |
6013 | 6013 | ||
6014 | nv_restore_mac_addr(pdev); | 6014 | /* |
6015 | * Restore the MAC so a kernel started by kexec won't get confused. | ||
6016 | * If we really go for poweroff, we must not restore the MAC, | ||
6017 | * otherwise the MAC for WOL will be reversed at least on some boards. | ||
6018 | */ | ||
6019 | if (system_state != SYSTEM_POWER_OFF) { | ||
6020 | nv_restore_mac_addr(pdev); | ||
6021 | } | ||
6015 | 6022 | ||
6016 | pci_disable_device(pdev); | 6023 | pci_disable_device(pdev); |
6024 | /* | ||
6025 | * Apparently it is not possible to reinitialise from D3 hot, | ||
6026 | * only put the device into D3 if we really go for poweroff. | ||
6027 | */ | ||
6017 | if (system_state == SYSTEM_POWER_OFF) { | 6028 | if (system_state == SYSTEM_POWER_OFF) { |
6018 | if (pci_enable_wake(pdev, PCI_D3cold, np->wolenabled)) | 6029 | if (pci_enable_wake(pdev, PCI_D3cold, np->wolenabled)) |
6019 | pci_enable_wake(pdev, PCI_D3hot, np->wolenabled); | 6030 | pci_enable_wake(pdev, PCI_D3hot, np->wolenabled); |