Description of problem: In kernel sourcecode file drivers/net/tg3.c: 11072 /* By default, disable wake-on-lan. User can change this 11073 * using ETHTOOL_SWOL. 11074 */ 11075 tp->tg3_flags &= ~TG3_FLAG_WOL_ENABLE; This line reset Wake On LAN settings for tg3 network cards during every boot process. For example, you enable Wake On LAN on a machine using ethtool then shutdown the system and start it again using Wake On LAN. But now, the linux driver disables Wake On LAN. Effectively you have to enable WOL again after each boot (in an initscript or cronjob) to make sure that it stays enabled. Fedora/RHEL should remove this "feature"/bug from their kernels to allow reasonable use of Wake On LAN with tg3 network adapters. Version-Release number of selected component (if applicable): Every upstream kernel up to latest git version. Steps to Reproduce: 1. On a computer with tg3 network adapter, set WOL active with ethtool eth0 wol. 2. Shutdown. 3. Send Magic Packet. Machine boots up. 4. Shutdown. 5. Send Magic Packet. Actual results: Machine stays down. Expected results: Machine should boot up again.
ETHTOOL_OPTS="wol g" Why is adding this to /etc/sysconfig/network-scripts/ifcfg-eth0 insufficient?
Yes, that would work but it seems- like the solution with the initscript or a cronjob- more like a hack to me to compensate for the fact that the tg3 drivers tampers with settings that it should not touch (without user request). In fact it will not work when the system does not boot up completely or the network-script is not run due to some problem. It will also not work if you are running a Fedora/RHEL installation or using a Fedora-based system as a rescue system (which is critical if you boot the rescue image using PXE/WOL like I do and expect the system to be still WOL-enabled after you shutdown the rescue system). Shouldn't it be the default of the Linux kernel to change as few things as possible permanently on a system so that the system has the same settings after shutdown that is has before Linux booted?
It would be great if we could simply read hardware parameters and set the driver WOL state based on whether or not WOL is enabled in the hardware, but right now it doesn't appear the driver works that way.
"works that way" should really be "works that way right now" :-)
Created attachment 169192 [details] tg3-wol.patch This is completely untested, but it might resolve your issue (the idea is at least correct).
I just tested this patch and it doesn't seem to work on my 5755 card. Reading the MAC_MODE register when coming out of reboot doesn't show the bit 'magic packet' bit set, so this might be a register that isn't persistent across reboots.
Not all of the tg3 hardware may save WoL state when powered-up -- it may only be a setting that can be written while the device is powered. Adding Michael to the CC list to see if he's got anything more to add.
We have a patch that will set WoL according to the NVRAM's setting by default. The user can still override it but the initial setting will match NVRAM's setting. We should be pushing that upstream soon.
Thanks, Michael! I figured if anyone would know, you'd be the one!
The following patch posted today should fix this problem: http://marc.info/?l=linux-netdev&m=119206359520255&w=2
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage Please could those experiencing the issue confirm or deny whether the issue has been resolved for them with the above patch. If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged.
The patch posted in comment #10 seems to have been accepted upstream (it's in 2.6.24-rc7). Will Red Hat include it in FC7 (and above) kernels as well? PS: I didn't tested the patch myself.
Helge, I have done a scratch build with the patch included in koji for you to test if you wish: http://koji.fedoraproject.org/koji/taskinfo?taskID=347248 Cheers Chris
Chris, I just tested the kernel you kindly provided, it works great! Thanks a ton!
Thanks for testing and good to know Uwe :) I don't think the kernel team are anticipating carrying this as 2.6.24 (which includes the patch) is just about to be released so I will close as NEXTRELEASE and Helge can re-open should he feel the need.
That's fine with me. Thanks all.