On suspend (hibernate), and as of kernel version >=2.6.29, with /etc/init.d/net.eth0 started, suspend/hibernate hangs and no longer works.
Temporary workaround is to use hibernate scripts to stop the /etc/init.d/net.eth0 service on suspend/hibernate and restart it during resume along with any dependent services.
(Something else to note, when my net.eth0 init script starts, it's also assigned an ipv6 address in addition to ipv4.)
My network device is the following (lspci):
00:14.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 08)
I also have a laptop using the same driver (w/ similar h/w?) and it hibernates without problems using kernel versions >=2.6.29. Odd.
What is the newest kernel you have tested?
Currently using linux-18.104.22.168, and noticed this bug's symptoms during the initial release of 2.6.29.
I finally diagnosed apparently using this latest stable version.
Just comparing e100.c to linux-2.6.28 series, and there seems to be quite a few additions! Which detail firmware stuff in the declarations.
One thing to not include as the possible cause of this bug is the pci save state. This is a wake on lan fix and this related WOL patch worked on the linux-2.6.28 series. (I was applying this patch manually while waiting for it's publishing.)
One thing I could test sometime, copying over an older 2.6.28 e100.c file into the 2.6.29 tree here and seeing if it fixes my hibernate/suspend issue. Which is very likely as I scan the code?
Probably related to bug 13225.
However in my case rmmod'ing e100 module before suspending doesn't help.
Confirming a second box of mine (Intel 440BX with a PCI E100) doesn't hibernate/suspend without first doing "/etc/init.d/net.eth0 stop".
Mine is built statically.
I'm not sure if this is related to bug 13225 until I see similar activity.
Currently, all I'm seeing is a hang at hibernate on this box & a hang on hibernate & resume on the other box (as it inadvertently tries to resume a hibernated session).
Within bug 13225, you state you *can* get the box to resume successfully w/o hanging.
Strike my last sentence w/i Comment #5.
It should read:
"Within bug 13225, you state you *can* get the box to hibernate successfully (w/o
Yep, I can resume my box but I cannot say it's usable ;)
marked as regression since 2.6.28 kernel worked and 2.6.29 does not.
It seems that this is a duplicated bug of bug13371.
So it will be marked as the duplicated of bug 13371.
*** This bug has been marked as a duplicate of bug 13371 ***
_Please_. Bug 13371 was created by me, to track a regression reported by e-mail. The reporter of that bug doesn't have a kernel Bugzilla account. This one, OTOH, has an active reporter, so it would make much more sense to mark bug 13371 as a duplicate of this one.
*** Bug 13371 has been marked as a duplicate of this bug. ***
Roger, is this still an issue with 2.6.31?
I'll check this over the next day or so. (Sorry for being slow.)
... btw, I can't test 2.6.31 due to too many bugs. I will, however, test 2.6.30.
This bug is still persistent on my Dell 8100 laptop (i815) using 2.6.30.
(2.6.30-gentoo-r7Y -- Linux version 22.214.171.124 -- wish uname would provide the Linux version instead of the distro's version! :-/)
I have bumped into very similar issue with e100 driver since 2.6.29 kernel.
Take a look of my report at
The workaround is to embed the e100 firmware into the kernel, as user-land
firmware loader cannot run while userland is frozen.
Re: Comment #18 - Negative. My e100.c is already compiled statically.
Not only this, but what you are seeing, are likely the results of the many e100.c (firmware) changes made just prior to 2.6.29.
Is this still a problem on newer kernels?
Ping, please reopen or shout if this issue is still present in current mainline kernels.
Sorry for not posting in awhile.
I've long since moved away from the hibernate (& tuxonice) sources.
I still may return to those sources sometime though, but until then, I haven't tested suspend or hibernate on any of my boxes since I probably last posted here.
If I venture back into suspend/hibernate and run into further problems with this issue, I'll be sure to follow-up!