Most recent kernel where this bug did not occur: 2.6.12.6 (I'm not adventurous enough to try any of the "-rc" kernels) Distribution: Gentoo Hardware Environment: CPU P4 with HT, MB Asus P4C800-E Deluxe (Intel 875P chipset) with onboard e1000 (Intel 82547EI) connected to a 10/100 switch Software Environment: latest BIOS SMP kernel, more info: http://columbia.dragon.cz/~volf/wol_problem/ ver_linux says: Gnu C 3.3.6 Gnu make 3.80 binutils 2.15.92.0.2 util-linux 2.12r mount 2.12r module-init-tools 3.0 e2fsprogs 1.38 reiserfsprogs 3.6.19 reiser4progs line nfs-utils 1.0.6 Linux C Library 2.3.5 Dynamic linker (ldd) 2.3.5 Procps 3.2.5 Net-tools 1.60 Kbd 1.12 Sh-utils 5.2.1 udev 070 Modules Loaded radeon intel_agp drm agpgart nfsd exportfs lockd sunrpc microcode w83627hf i2c_sensor i2c_isa i2c_i801 e1000 snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_bt87x snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc usblp sata_promise libata scsi_mod uhci_hcd ehci_hcd usbcore loop tuner tvaudio bttv video_buf firmware_class i2c_algo_bit v4l2_common btcx_risc tveeprom i2c_core videodev ide_cd cdrom Problem Description: With 2.6.13 and 2.6.14, after I shutdown the computer I can't wake it up with then "MagicPacket" over the network. With 2.6.12 and 2.6.12.x it is working. Steps to reproduce: Boot 2.6.14, "ethtool -s eth0 wol g", press the power button, acpid runs "/sbin/init 0", the computer poweroffs, the link on the switch goes off and WOL is not working. With 2.6.12 the link remains on and WOL is working. I've just found out that when I pull out the power cord for a while after the shutdown from 2.6.14, the link on the switch goes on and WOL is working... More info: Contents of some /proc files, output of lspci -vvvx and the .config are here: http://columbia.dragon.cz/~volf/wol_problem/
Is this issue still present in kernel 2.6.16?
I have a similar problem with 2.6.16-rc4. When I put the machine in S3 sleep, the link remains active, but I can't get it to wake with either a magic packet or directed packet. I also note that after I wake the machine manually, an ethtool eth0 indicates that the link is now FIBRE! Seems like some state is not being correctly maintained across the sleep. Regards, David.
re original report: wake on lan should work with the "aftermarket" intel drivers from sf.net. I will attach a patch you can try. re #2, you have an e1000? is your link up when your machine is asleep, does the light flash when you send the magic packet? are you sure eth0 is the same interface after resuming from sleep? what hardware do you have? also, does the driver from e1000.sf.net work?
Created attachment 7933 [details] implement a shutdown method for e1000 try this patch and let me know if it helps.
To Adrian Bunk: yes, it is still present in 2.6.16 To Jesse Brandeburg: yes, the patch (id=7933) helps, thanks.
I tried the sf.net driver with the supplied patch applied. Still no luck. To answer the questions: - The link remains up during sleep (albeit at 10 or 100 Mbit/s rather than 1000) - The link activity light flashes with either a magic packet or a unicast packet - The new driver seems to have resolved the link re-awakening as FIBRE after sleep - My NIC is the Intel Pro 1000MT with 8245EM chip. - Motherboard is Gigabyte GA-8IPE1000-G which claims to support WOL and has BIOS settings to match (I've tried Gigabyte technical support and they said there should be no trouble getting WOL working) - Command to sleep: echo -n mem >/sys/power/state I don't fully understand how WOL is meant to in terms of its interactions with BIOS, ACPI etc. Are there any other links in the chain that I should check ? Regards, David.
d.giddy, seems like there may be something else going on with your system. Do you have the bios set correctly to allow wake on lan from S3? Have you turned on acpi debugging in your kernel?
Jesse, I found that I needed to enable wakeup (/proc/acpi/wakeup) for the PCI0 device to get it to respond. It now does so, but the machine will not wakeup correctly and simply hangs with no response to anything. I've now cross posted this query to the linux-acpi mailing list as I get the same response with the RTL8169 port on the motherboard, but a successful wakeup on the power button. Hence, I suspect it may not be a driver problem. Thanks, David.
is this issue still outstanding?
No, it seems to be working OK now, not quite sure why... -----Original Message----- From: bugme-daemon@bugzilla.kernel.org [mailto:bugme-daemon@bugzilla.kernel.org] Sent: Saturday, 17 June 2006 4:44 AM To: d.giddy@bigpond.com Subject: [Bug 5609] e1000, 2.6.1[34] - WOL not working http://bugzilla.kernel.org/show_bug.cgi?id=5609 ------- Additional Comments From jesse.brandeburg@intel.com 2006-06-16 11:43 ------- is this issue still outstanding? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.