Re: Call for testers: fxp(4) WOL

On Mon, Nov 03, 2008 at 07:35:56PM +0100, Alexey Shuvaev wrote:
 > On Wed, Oct 15, 2008 at 09:37:45AM +0900, Pyun YongHyeon wrote:
 > > I've implemented WOL for fxp(4) and it works ok to me. Because
 > > there too many variants of fxp(4) hardwares I'd like to hear
 > > success/failure report before committing attached patch to tree.
 > > It seems that the following Intel 8255x supports WOL. Apparently
 > > 82557 lacks WOL capabillity.
 > > 
 > > 82558
 > > 82559
 > > 82550
 > > 82551
 > > 
 > How can one figure out which chip he has?
 > I have relative old Toshiba notebook with integrated intel network card.
 > The system is:
 > 
 > FreeBSD localhost.my.domain 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Oct 27 01:25:54 CET 2008     root_at_localhost.my.domain:/usr/obj/usr/src/sys/GENERIC  i386
 > 
 > 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.

 > fxp0: bpf attached
 > fxp0: Ethernet address: xx:xx:xx:xx:xx:xx
 > fxp0: [MPSAFE]
 > fxp0: [ITHREAD]
 > 
 > and this is the output from pciconv -lvc:
 > 
 > fxp0_at_pci0:2:8:0:	class=0x020000 card=0x00011179 chip=0x10318086 rev=0x42 hdr=0x00
 >     vendor     = 'Intel Corporation'
 >     device     = '82801CAM (ICH3) PRO/100 VE (LOM) Network Connection'
 >     class      = network
 >     subclass   = ethernet
 >     cap 01[dc] = powerspec 2  supports D0 D1 D2 D3  current D0
 > 
 > It seems that driver changes something, after boot or 'ifconfig fxp0 wol':
 > 
 > fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
 >         options=2008<VLAN_MTU,WOL_MAGIC>
 > 

It indicates your controller supports WOL with magic packet.

 > and after 'ifconfig fxp0 -wol':
 > 
 > fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
 >         options=8<VLAN_MTU>
 > 
 > 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. :-(

 > 
 > > If your suspend/resume works on your system you can also wake up
 > > your system in suspend by WOL.
 > > 
 > Actually, the system does not wake up from suspended mode properly, either
 > by power button or by WOL packet, but it tries.
 > 

The system I tried didn't resume properly (blank screen) but I
could login via network after sending WOL magic packets so I
thought resume also works.

 > > Thanks.
 > Thank you, if you need something more (debugging output,
 > testing new patches, digging deeper...) just let me know.

Thanks for testing. I'll think again.
By chance can you try Linux on your system and check whether it
works?
-- 
Regards,
Pyun YongHyeon