Description of problem: After powering off the PC with "poweroff", it is not possible to restart it using "ether-wake" (from an other PC). This was working before (see "Additional info" below). Version-Release number of selected component (if applicable): 2.6.14-1.1656_FC4 How reproducible: Always. Steps to Reproduce: 1. Poweroff from command line, gnome, or gdm. 2. Try ether-wake from an other PC (of course everything is configured OK in the BIOS of the first PC). 3. Actual results: The PC stays happily off. Expected results: The PC should switch on, start POST and booting sequence. Additional info: First of all, the PC is an intel based one, P-4 3GHz, I guess Prescott, with intel chipset. Not sure, I think it should be some 945G chipset with gigabit ethernet (e1000 driver). The interesting thing is that with RH9 and kernel 2.4.20-30.9, everything worked fine. After shutdown it was possible to wake on lan the machine. Just after the upgrade to FC4, kernel 2.6.14-1.1656_FC4(smp) the wake up on lan was not working anymore (smp or not smp kernel) after software poweroff. Interesting to say that a physical poweroff (ATX switch off or button off just after POST) makes the machine wake on lan-able. Googling around returned some interesting info about the fact that this seems to be 1) an old linux problem and 2) some people are blaming the motherboard for it. But here, again, the software upgrade is the only difference (on 3 identical PCs) between WOL working or not after shutdown. Somewhere else was mentioned that soft poweroff should set the ethernet to ACPI state D3, while D4 is full off, this might be some intentional behaviour... There are scripts that, on shutdown using pci-config, set the ethernet power state D3 (not tried on the PCs). Last info, on the ethernet side, "ethtool eth0" returns ... Supports Wake-on: g Wake-on: g ... which should indicate that the card supports the Magic Packet and it is also enabled. As mentioned above, it could be that intentional all the peripherals are set to D4 on poweroff, or that the shutting down procedure is not fully correct. Very last info, same results with BIOS WOL enabled or, alternatively, with PCI PME enable.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
OK, here we go. I upgraded the machine to 2.6.15-1.1830_FC4 smp and not smp. The BIOS provides two possible WOL, one is "WOL on ACPI S5" and the other is "Wake on PCI PME" (claimed to be ACPI independent). This two options are in alternative, i.e. either one or the other can be enabled at a given time. I tried both smp and not smp (new) kernel with both the options, in all cases the PC did not WOL. In all cases, switching the ATX PSU off, waiting for the capacitors discharge, switching it on again, caused the WOL to work. I tested an other BIOS option, the "Action after power failure", this could be "PC off", "PC on" or "Previous state". I tested only "PC off" and "Previous state" and the behaviour was always the same as above. This could be strange, since "Previous state" could have been "un-WOL-able", but it was not. It seems the power on of the ATX PSU was always "resetting" the WOL functionality. I have an other PC, an old one based on a P2B-S MB. This one is blacklisted by the kernel ACPI subsystem, i.e. ACPI does not work. Power off is, I assume, APM based. In this case WOL works just fine, without any issue. It would be interesting (for me) to know a not-so-complex way to verify what's going on. BTW I tested the ACPI S3 capabilities of the new kernel. The smp one starts something but it does not go to S3, it simply goes back to normal state. The non smp one goes into S3, but it does not wake up anymore. I mean, the ATX PSU restart, but nothing is working, no screen, no keyboard, no _reset_. Only a power off was possible. Hope this helps.
Please attach the output of running sysreport. Thanks! Also, have you tried using the Fedora-netdev kernels? http://people.redhat.com/linville/kernels/fedora-netdev/ Please give them a try and post the results here...thanks!
(In reply to comment #3) > Please attach the output of running sysreport. Thanks! Uhm, usually I try to be supportive, but... See below... I tried sysreport, which, by the way, was not working without "-norpms", the last part (the data collating) failed. So I used it with "-norpms". I checked the info it collects and, unfortunately, I think I cannot attach the full report here, due to confidentiality reasons. If there is anything I can look by myself into the report, please let me know, I'll be probably able to check and come back to you. Again, kernel 2.4.20-30.9 from RH9 was OK (I know I repeat myself, but I found this of critical importance). > Also, have you tried using the Fedora-netdev kernels? > > http://people.redhat.com/linville/kernels/fedora-netdev/ > > Please give them a try and post the results here...thanks! At the moment I had no time, I'll check ASAP, even if I do not see any patch that could solve the issue. Thanks again.
There is a privacy checkbox you can set when attaching a file to the bug. Please use it if you feel the need to do so. Also, please do try the fedora-netdev kernels and let me know if they work any better for you...thanks!
(In reply to comment #5) > There is a privacy checkbox you can set when attaching a file to the bug. > Please use it if you feel the need to do so. Uhm, sorry, I really cannot. What I can do is to look into the report for you, if you give me some indications on what to search. > Also, please do try the fedora-netdev kernels and let me know if they work any > better for you...thanks! I tried these kernels, the 1831 version patched. Both smp and non-smp and I got the same results as before, with the 1830 "standard", i.e. no WOL. Is there any way to check (source code somewhere?) what exactly is happening on power off and what _was_ happening with the 2.4.x kernel? I'm thinking to try a vanilla kernel, to see if anything changes. I'll let you know. Thanks, bye
OK, some news after a while. I checked (quickly) with the latest kernel 2.6.16-1.2069_FC4smp and the result is always the same: not WOL after shutdown. And, again, after switching off/on the PSU (with waiting) the WOL works. Pretty annoying... :-) I could not try a vanilla kernel, no time, sorry, but there is still hope!
Good news or bad news, depending on the point of view... I check the vanilla kernel 2.6.16.1, and the result is exactly the same, no WOL except when PSU is off/on etc. etc. So I guess something changed in the mainline, problem is to find what.
Are you still on FC4? Or have you moved to FC5? I'm planning on doing an FC5 test kernel w/ some recent upstream patches that appear to address this problem. I'm not planning to do any for FC4, but I can post the patch separately...
Created attachment 130053 [details] jwltest-e1000-wol-shutdown.patch
Test kernels w/ the above patch are available here: http://people.redhat.com/linville/kernels/fc5/ Please give them a try and post the results here...thanks!
(In reply to comment #9) > Are you still on FC4? Or have you moved to FC5? > > I'm planning on doing an FC5 test kernel w/ some recent upstream patches that > appear to address this problem. I'm not planning to do any for FC4, but I can > post the patch separately... First of all thanks for the patch. I'm in the process of migrating to FC5, two PCs are already there. I'll give it a try to the new kernel on Monday and I'll see if it works. About FC4, I'm not sure all the PCs will go to FC5 at all, since we are not fully convinced by FC5, so a new FC4 kernel with the patch will be really appreciated (maybe also someone else needs it on FC4). Do you know what's the situation of mainstream vanilla kernel? Thanks.
I have been having the same problem, also with an e1000. The patched kernel solved my problem; WoL now works after a clean shutdown.
(In reply to comment #11) > Test kernels w/ the above patch are available here: > > http://people.redhat.com/linville/kernels/fc5/ > > Please give them a try and post the results here...thanks! Yep! I tried it today, it made the trick! Now WOL work fine with e1000 hardware. I also noticed that mainstream kernel 2.6.17-rc5-git5 has the patch. There is only one issue left. This bug is open for FC4 so I will not close it :-) Is it possible to forward the patch to the FC4 kernels? Maybe having it in the next (scheduled) update? Thanks again.
I just noticed that the kernel 2.6.17-1.2139 is available in updates of both FC4 and FC5. This should contain the patch posted in comment #10. I tested the FC5 version and it works fine, shutdown and wol are no problem. I guess also the FC4 works, so I'll close the bug.
I have got a 2.6.18-1.2239.fc5 kernel and It is still problem for me, I can not upgrade to kernel kernel-2.6.18-1.2210.2.2.fc5.jwltest.18.i686.rpm, because: "package kernel-2.6.18-1.2239.fc5 (which is newer than kernel-2.6.18-1.2210.2.2.fc5.jwltest.18) is already installed" Can anyone help me ?
rpm -ihv --force kernel-2.6.18-1.2210.2.2.fc5.jwltest.18.i686.rpm But FWIW, the patch should already be in the vanilla FC5 code. If you are seeing a similar problem, please open a new bug.