[Pkg-sysvinit-devel] Bug#405870: sysvinit: halt binary missing ifdown, breaks wake on lan, src...

[HarryCoin at aol.com]

In a message dated 1/13/2007 11:53:00 A.M. Central Standard Time,  
pere at hungry.com writes:

[Harry  Coin]
> With the etch version of 'halt', the interface will not be  brought
> down, both ifconfigs will report the interface works  normally.

According to the report in bug #388244, wake-on-lan need  the
interfaces to be up when the machine is taken down, 
I can provide some help on this question.  I am sorry about the  length but 
without the background it will make no sense.  The  short answer is this 
depends on whether the machine is has an NFS root at  poweroff time or a local root, 
and whether the driver implements WOL in the  ifdown routine, or the 
.shutdown routine, and whether the driver requires ifdown  to be called and then 
.shutdown to be called for WOL to work as there are at  least two requirements for 
WOL to work:   Setting the PME flag in the  ethernet chip's PCI config space 
and setting the chip specific flag that looks  for WOL magic packets (which is 
not set until after the interface is  deconfigured).
 
1)  There are two communities that use the wake on lan (WOL)  function:  
Those that boot the OS from local media (disk, CDROM, flash,  etc.) and those that 
rely on the network entirely (diskless, whether nfs boot or  the initrd 
initramfs method (which is the one etch uses)).   The  importance is that for those 
that have a local root file system only,  ifdown is called when the network 
is deconfigured earlier in the  poweroff/halt/shutdown scriptl  For the network 
root group it is not, these  rely on halt to do it.  So the broken 'halt' 
does not affect the first  group as ifdown has already been called.
 
2)  Some LAN drivers enable the wol in ifdown only (3c59x) , while  others do 
it in .shutdown (e100).  Some drivers require the interface to  NOT be 
deconfigured for WOL to work  (See the origin of the NETDOWN define  in the 
/etc/init.d/halt script-- some drivers need that to be 'NO' for WOL,  others need it 
to be the default, YES.)
 
3)  Some LAN drivers, before enabling and recognizing WOL magic  packets 
(this is an additional step to setting the PME flag in the PCI config  space) , 
require the interface to be 'down' as well as having the WOL flag  active 
(e100). This is fine for systems with local root, as .shutdown is called  after the 
lan is deconfigured, but WOL is not activated if the system is  diskless as 
the interface is up when .shutdown is called.
 
4)  I have learned that some ethernet drivers implement .shutdown,  while 
others do not.   On these non .shutdown drivers, if ifdown is  not called, the 
the functions to set the PME bit are not called.  This is  how I discovered the 
problem with halt  problem.   ( I  also wonder whether the sync option is not 
called, perhaps why some folk  are having mysterious file system corruption 
across reboots?!?) 
 
5) I have learned that some drivers rely upon the 'ethertools  -g wol'  
option to enable wake on lan, while others do not implement it, in favor of a  
module loadtime option (3c59x, which also has a wol bug I fixed).  In the  2.6.18 
version distributed with etch, in the acpi_set_WOL routine, this change  
allowed wol to work on Dell optiplex machines : change
-- pci_enable_wake(VORTEX_PCI(vp), 0, 1)
++     pci_enable_wake(VORTEX_PCI(vp),PCI_D3hot,1);
 
6) for what it is worth, I report also that on diskless Dell Optiplex  
machiones with a built in e100 driver, if I force the system off with the power  
switch at the 'grub' os selection time, WOL on that system works normally.   But 
if I set ethtool -s wol g in the init.d/halt script just before  halt -f -d 
.... then poweroff, the system will not WOL.   It  matters not whether using 
ACPI or APM, lapic or not, 2.6.18 kernel, debian etch,  no patches).
 
Pere continues<
while your report
the opposite.  Is this different from driver to  driver?  I implemented
the NETDOWN boot option to make ifdown optional,  but the default is
still to take down the interfaces.

I've tried to  rebuild the package, and it did not change anything.
I'm testing this now,  and see that the interfaces are still up after
halt -i is executed.  No  idea why yet.>



I am very pleased you have found a way to duplicate at least part of the  
problem.   If ifdown isn't being called, I wonder if also sync is not  called?  
It would explain file system corruption bugs etch / debian folk  have written 
of across reboots.  
 
 
Thank you for your attention to this problem!
 
Harry Coin
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20070114/e2b4b24e/attachment.html