Re: Call for testers: fxp(4) WOL

On Tue, Nov 04, 2008 at 10:42:46AM +0900, Pyun YongHyeon wrote:
> On Mon, Nov 03, 2008 at 07:35:56PM +0100, Alexey Shuvaev wrote:
>  > Here are relevant messages from the verbose boot:
>  > 
>  > fxp0: <Intel 82801CAM (ICH3) Pro/100 VE Ethernet> port 0xdf40-0xdf7f mem 0xfceff000-0xfcefffff irq 11 at device 8.0 on pci2
> 
> If it's based on ICH controller it would be 82559.
> 
>  > fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfceff000
>  > fxp0: using memory space register mapping
>  > fxp0: PCI IDs: 8086 1031 1179 0001 0042
>  > fxp0: Dynamic Standby mode is disabled
>  > miibus0: <MII bus> on fxp0
>  > fxp0: XXX: driver didn't set ifq_maxlen
>  >       ^^^
>  > Is this something to fix?
>  > 
> 
> fxp(4) didn't set ifq_maxlen and if_attach corrected this with
> its default value. Normally network device drivers set this queue
> length to number of Tx descriptors but it's completely up to
> driver writers and I don't see compeling reason to change that.
> 
Ok, I just was attracted by something with 'XXX'.

>  > However the system seems to honors only the BIOS settings, if I enable WOL in
>  > the BIOS the system wakes up from power-down or suspend (to ram) states
>  > regardless of fxp settings and with disabled WOL in BIOS it never 
>  > wakes up.
>  > 
> 
> Yes that's an expected behaviour. BIOS option should be changed to
> enable WOL if you want to wake up your box from power down. If
> you don't want to wake up your box regardless of BIOS configuration
> you have to disable WOL with ifconfig before shutting down your
> box. Likewise even if you enable WOL with ifconfig(8) to wake up
> your system, BIOS WOL option also should be enabled to make it 
> work.
> 
>  > The worse thing I have noticed is if I send WOL packet while the system is
>  > running it reliably hangs. It does not panic and switching virtual
>  > consoles works (and typing/deleting something in the shell prompt too),
>  > but the cooler runs at full power and you can't do anything else.
>  > This is both with patched fxp and that from -CURRENT.
> 
> Hmm, I think that was old bebahviour of stock fxp(4). Previously
> fxp(4) was programmed to accept WOL packets regardless of running
> state of hardware. With my patch the WOL should be disabled for
> normal operation and WOL is enabled again when you shutdown your
> box. If sotck fxp(4) also show the same behaviour it's big security
> hole.
> ATM I have no idea how WOL packets can affect running box. :-(
> 
I have tested more thoroughly and here are the results.

FreeBSD-CURRENT (late oktober) without your patch
(is it what you call 'stock'?):
	interface up or down, WOL disabled or enabled in the BIOS -
	system hangs when receiving WOL packet.
	Breaking to debugger shows kernel running, namely 3 acpi threads,
	acpi_task_[0-2].
FreeBSD-CURRENT from 4 Nov 2008 with your patch:
	again, with WOL enabled in BIOS or not, system hangs with WOL packet,
	but only if interface is down.
	With interface (fxp0) up and running, nothing happens.
	However, I failed to disable WOL with ifconfig, notebook boots
	always when WOL enabled in the BIOS.
Linux-Ubuntu uname: Linux ubuntu 2.6.22-14-generic #1 SMP
Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux (booted live from CD)
	The same results as with FreeBSD-CURRENT with your patch.
	Disabling wol with ethtool does not produce the desired results.
	Receiving WOL packet when interface is down does not hang the system,
	but it (according to top) consumes 70% in system with
	kacpid process consuming 98.5% of cpu.

> Thanks for testing. I'll think again.
> By chance can you try Linux on your system and check whether it
> works?
>
So, it seems your patch is making FreeBSD on par with Linux.
If you need something more, you are welcome!

Alexey.