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

[Harry Coin]

Henrique de Moraes Holschuh wrote:
> 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.
>
>   
Thank you.

The drivers that don't enable WOL / wake-on-lan in the context of NFS 
root after poweroff include e100.c  and 3c59x.c as shipped in Debian 
/Lenny-Testing.    Modified versions of these drivers did function 
properly in Debian etch (kernel .18).  But so many changes happened to 
them that my changes don't apply any longer.   I think the problem is 
they expect ifdown to happen and enable WOL there, they don't check for 
it at .shutdown.    I think I remember someone hacking a version of the 
e100.c to WOL on suspend, but as for poweroff:   Etch / 2..18 yes, Lenny 
2..26 no.



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