Re: WOL question

Jack Vogel wrote:
> On 4/10/07, Scott Long <scottl_at_samsco.org> wrote:
>> Julian Elischer wrote:
>> > Jack Vogel wrote:
>> >> I am hoping someone here who has more familiarity with the ACPI
>> >> code can enlighten me....
>> >>
>> >> I have an internal bug filed complaining that FreeBSD disables
>> >> wake-on-lan on the hardware. This means that if you boot, say,
>> >> Linux, even Knoppix as a quickie, and then shutdown, if the
>> >> hardware supports it, it will be left in a state where a magic-packet
>> >> wakeup will work. However, even if I boot up a FreeBSD kernel
>> >> with NO em driver, and then shutdown, it undoes the WOL setup.
>> >>
>> >> Now, I would like to have explicit WOL support added into the
>> >> em driver, but before I even worry about that I need to understand
>> >> where the kernel turns this off without the driver even needed.
>> >>
>> >> I've looked around at the dev/acpi and arch/acpi code and at
>> >> least so far I'm having a hard time getting an adequate picture
>> >> to know how it happens.
>> >>
>> >> Jack
>> >> _______________________________________________
>> >> freebsd-current_at_freebsd.org mailing list
>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> >> To unsubscribe, send any mail to
>> >> "freebsd-current-unsubscribe_at_freebsd.org"
>> >
>> > 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 :)
> 
> Jack


set up the kernel debugger to stop the boot at the first possible instance 
(boot -d from the loader) 
and see what state it is then.. at that point it has only touched a very few things..
mostly just RAM and the console device.