[Pkg-sysvinit-devel] Bug#501351: Bug#501351: Bug#501351: sysvinit: halt breaks wake on lan / WOL under NFS root /diskless lenny

[Henrique de Moraes Holschuh]

On Tue, 07 Oct 2008, Harry Coin wrote:
> > 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.

We have been through a similar problem a while ago: disk shutdown and cache
flushing.  It caused A LOT of pain.

The short answer is: the kernel has to do its job right on anything related
to device setup for suspend/hibernation/power off, and trying to fix it from
userspace just causes things to blow up when the kernel finally gets its act
together.

This is true for WoL just like it was true for disk shutdown.  If WoL is
enabled, the kernel driver has to make sure everything that needs to be done
to the hardware to make it active when entering S3/S4/S5 is done.   There is
NO other acceptable solution, because this is the only way to *always* get
it right, without weird border conditions.

Since the state of things right now is so utterly sad, we can't do much more
than provide both possibilities (good and broken drivers), warn the user
that he has to test which one he needs, and keep one eye in the kernel to
react quickly if the network drivers get fixed.

> 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 

I could do that, yes.  Please provide me a list of the drivers you have
verified to have retarded WoL behaviour, along with the kernel version.  I
can at least make sure it is all listed in bugzilla.kernel.org, although I
doubt I can fix it myself.

> poweroff.   As it is, network drivers engage WOL options when downing 
> the interface (though I worry some do it in the .shutdown routine).

They should engage/de-engage WoL in device-model .shutdown and .suspend.
And if that means they have to bring the transceiver up/down or even paint
the moon blue in order to have the hardware do the right thing, they are to
do it.

At that point, userspace (i.e. Debian) is already frozen (for S3/S4) or
destroied (for S5 - shutdown) and doesn't care.

In fact, we should not have to touch the interfaces at all in the userspace
shutdown path, just like we don't have to do it anymore for disks (in fact,
we must NOT, for disks).

> 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.

I fear we are not going to touch this anymore for Lenny, except as
documentation.  If any of the other maintainers want to, I won't stand in
the way, nor complain about it... but I doubt anyone will want to touch the
shutdown path this late in the freeze.

It is not like we can even fix this crap for good unless the kernel gets its
act together, anyway...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh