<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=US-ASCII">
<META content="MSHTML 6.00.2800.1586" name=GENERATOR></HEAD>
<BODY id=role_body style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial"
bottomMargin=7 leftMargin=7 topMargin=7 rightMargin=7><FONT id=role_document
face=Arial color=#000000 size=2>
<DIV>In a message dated 1/13/2007 11:53:00 A.M. Central Standard Time,
pere@hungry.com writes:</DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT
style="BACKGROUND-COLOR: transparent" face=Arial color=#000000 size=2>[Harry
Coin]<BR>> With the etch version of 'halt', the interface will not be
brought<BR>> down, both ifconfigs will report the interface works
normally.<BR><BR>According to the report in bug #388244, wake-on-lan need
the<BR>interfaces to be up when the machine is taken down, </FONT></BLOCKQUOTE>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.)</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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?!?) </DIV>
<DIV> </DIV>
<DIV>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</DIV>
<DIV>-- pci_enable_wake(VORTEX_PCI(vp), 0, 1)<BR>++
pci_enable_wake(VORTEX_PCI(vp),PCI_D3hot,1);</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>Pere continues<</DIV>
<DIV><FONT style="BACKGROUND-COLOR: transparent" face=Arial color=#000000
size=2>while your report<BR>the opposite. Is this different from driver to
driver? I implemented<BR>the NETDOWN boot option to make ifdown optional,
but the default is<BR>still to take down the interfaces.<BR><BR>I've tried to
rebuild the package, and it did not change anything.<BR>I'm testing this now,
and see that the interfaces are still up after<BR>halt -i is executed. No
idea why yet.></FONT></DIV>
<DIV><FONT style="BACKGROUND-COLOR: transparent" face=Arial color=#000000
size=2><BR> </DIV></FONT>
<DIV></DIV>
<DIV>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. </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Thank you for your attention to this problem!</DIV>
<DIV> </DIV>
<DIV>Harry Coin</DIV>
<DIV> </DIV></FONT></BODY></HTML>