hibernate event order question
From: Tobias Diedrich
Date: Sat May 17 2008 - 13:51:43 EST
for some time now I had the problem that after a suspend to disk
network connectivitiy was down and also wake-on-lan would not work.
First a bit of information, for the real question please see (*)
Now I just found the ethtool -d (register dump) option
and decided I want to try to debug this long-standing bug:
I already found out why network connectivity is down after resume:
The interfaces eth0 and eth1 are bridged into br0.
The bridging code sets the interfaces into promiscous mode, but this
is not properly restored after resume.
This bug is easily fixable by calling nv_set_multicast(dev) either
from within nv_open() or after nv_open() in nv_resume().
The second problem (does not wol after s2disk) is still unsolved
though. However I have found that wake-on-lan works fine if I
"rmmod forcedeth" before suspending. This is even a usable
workaround for me, since the bridge device stays configured and I
just have to reload forcedeth and readd the interfaces to the bridge
Now for my question:
AFAICS the ordering of events is as follows:
1) User reqests hibernate
2) Tasks are frozen
3) Device suspend callbacks get called
4) Device resume callbacks get called
5) Memory image is written to disk
Now, the problem I see with this is that while step 3) prepares the
device for suspend (and wake-on-lan), step 4) may undo some of this
In my case, I think the fix for the first bug (promiscous mode does
not get restored on resume) breaks wake-on-lan (since the new value
of NvRegPacketFilterFlags may be incompatible with wake-on-lan).
Shouldn't there be a 'prepare for poweroff'-callback, which gets called
before the system is powered off for real?
--- linux-2.6.26-rc2/drivers/net/forcedeth.c 2008-05-17 14:22:06.000000000 +0200
+++ linux-2.6.26-rc2/drivers/net/forcedeth.c 2008-05-17 19:48:56.000000000 +0200
@@ -5823,6 +5823,7 @@
writel(txreg, base + NvRegTransmitPoll);
rc = nv_open(dev);
Tobias PGP: http://9ac7e0bc.uguu.de
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/