Petter Reinholdtsen wrote:
[Harry Coin]
Upgrading to lenny from etch has broken wake on lan after 'poweroff'
on our many Dell Optiplex headless /diskless systems. All packages
are latest lenny/testing as of 6 October 2008.
This is sad.
Yes.
Looking at the code I see that the latest network drivers always
disable WOL after ifup and before ifdown. Then, either at driver
unload time or ifdown time they set the WOL bit in hardware
according to option.
It the kernel drivers behavior with respect to wake-on-lan defined
somewhere? As I see this, the kernel drivers have no consistent
interface to userspace, and thus make it impossible to solve this in a
reliably way in userspace.
Because 'halt' has kernel-feeling options to block or do 'ifdown' and
block or do 'disk sync', its authors must be part of the answer. Long
term my suggestion is both those options seem to be things the kernel
filesystem and storage drivers should do on its way to orderly
ending/rebooting and they properly shouldn't be part of userspace halt.
But since they are at present and since halt is the program that hangs
when doing the right thing (asking for ifdown to set WOL) I am asking
halt authors to engage the correct kernel maintainers to decide either
the kernel and network driver authors must take responsibility to down
the interface or call shutdown routines even when NFS root just before
poweroff happens, or userspace drivers must pivot_root off the nfs root
to a tempfs system and down the interface before calling for a system
poweroff. As it is, network drivers engage WOL options when downing
the interface (though I worry some do it in the .shutdown routine).
Anyone can reproduce this problem: set up a NFS root system then try
poweroff using and not using halt's ifdown option. When choosing ifdown
option, you will see halt hang just before poweroff waiting for a
response from the NFS server that will never come because ifdown has
happened. In this case WOL is set in the adapters but because halt
never actually turns the system off and never exits -- having WOL turned
on is of no importance. The system is effectively hung until a physical
reboot. In the other case, leaving halt's ifdown option not chosen
when using NFS root will allow halt to exit normally, but the network
drivers routines that set the WOL bit never get called by the kernel, so
WOL is broken although the system is turned off.
This make it the responsibility of the
kernel drivers and the kernel space to come up with a solution. If
there is a definition on how the kernel drivers should behave, and
user space applications can depend on this definition during shutdown,
we can discuss how to solve this in sysvinit. Until such definition
show up, I have no idea how to solve this issue reliably.
Please let us know how the kernel decided to handle wake-on-lan in
network drivers, if such decision exist.
I am asking the halt authors to forward this bug to the correct people
since your ideas about who they are must be better than mine.
Happy hacking,
Not so much as I hope! Upgrades near release like Lenny are not supposed
to break basic things. The effect of this problem is wasteful usage of
energy keeping systems that have no work to do nevertheless powered up.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
