Re: WOL question

On 4/10/07, David Christensen <davidch_at_broadcom.com> wrote:
> > > > I think I heard once that some BIOSes turn it off during
> > the boot cycle
> > > > somewhere and it is up to the OS to turn it back on. I do
> > know that some
> > > > BIOSes
> > > > phuck with the NIC enough to stop IPMI from working
> > during the boot.
> > > >
> > >
> > > That would make sense; you don't want the card to generate
> > an NMI during
> > > boot from a spurius WOL package before the system is ready
> > to handle it.
> >
> > Hmm, so I have two competing views about things, one is that
> > the kernel
> > is actively doing something to disable WOL on shutdown, and now the
> > theory that its just not rearming the system.
> >
> > I really need to know which it is, because I'm putting code
> > in the driver that
> > I think should rearm it, and it doesnt work, and I've been
> > left wondering if
> > my code is wrong, or if something deeper in the kernel is
> > clobbering the
> > things I am trying to set up :)
>
> Is this a NIC or a LOM?  For Broadcom NICs there is a procedure
> implemented
> in firmware for toggling power to the chip from MAIN to VAUX prior to
> entering D3cold so that the controller still has power and can recognize
>
> the magic packet.  For LOM designs that's not required because the VAUX
> rail is always powered by the motherboard.  The easy way to check is to
> see if you still have a link LED lit on the back of the controller when
> you expect to be in WoL mode.  No LED, no power.  Are you resetting the
> link speed to 100Mbps or less?  Running at 1000Mbps generally draws more
> than 375mA and I've seen some systems that shutdown power to a slot when
> it draws too much power in VAUX.

Its a LOM. I think I have come up with a test that settles things.
I boot Knoppix and init 0, I know that in this state a magic packet
will wake the box up. Next I just boot thru the BIOS to the Knoppix
boot prompt, then power the system off. When I do this etherwake
will no longer wake it up.

I believe this proves Julian's claim is correct.

Next, I would just like to be confident that the ACPI layer is not going
to clobber something my driver does, but at least I need to take another
look at my code, maybe I got it wrong...

Thanks for the inputs everyone,

Jack