It seems that [at least on my notebook], ethtool -s eth0 wol pumbg does not set the PME-Enable bit in the PCI config space, thus preventing WOL from working. lspci -vv after ethtool -s eth0 wol pumbg: 02:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Asustek Computer, Inc.: Unknown device 1045 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 (8000ns min, 16000ns max) Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at a800 [size=256] Region 1: Memory at d6800000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- lspci -vv after suspending, sending a magic packet and resuming manually: [...] Status: D0 PME-Enable- DSel=0 DScale=0 PME+
Any updates on this one? It's been a year now and my 8139 still doesn't wake up...
Created attachment 6924 [details] a hack that fixes the problem Apparently, the attached patch does the trick. It probably badly violates the driver model, but it works.
Created attachment 7487 [details] suspend/resume/wol
Karol, can you give the patch above a try (no warranty) ? It is diffed against 2.6.16-rc5. -- Ueimor
Karol, did you get chance to test the patch from #3? Does the card work with recent kernel? Thanks.
Closing the bug for no recent activity. Please reopen if confirmed with newest kernel.
i've been reading some driver code ... it seems that the WoL hardware setup is intentionally delayed until some power-down state is entered, which kinda makes sense, assuming the hardware would never enter sleep without letting the kernel know about it. though the driver i looked at (b44) seems to "forget" to do it in certain situations ... investigating ...