Most recent kernel where this bug did not occur:2.6.17
I observed at my Thinkpad t41 that after a wakeup from a suspend to mem/disk
pppoe-start failed and I got in my log filegot that message. Restarting the
network (at least: "ifconfig eth0 down; ifconfig eth0 up") solved the problem
but that behaviour is annoying.
The last good commit is acfbc9fde2ec7f304398f6ad7644002e07bf84bc.
The first bad commit is 2db10a081c5c1082d58809a1bcf1a6073f4db160.
The initial bug report can be found here
https://bugs.gentoo.org/show_bug.cgi?id=146005 the problem was discussed at the
mailing-list email@example.com with Auke Kok
<firstname.lastname@example.org> in mid of september of this year.
With kernel git sources 2.6.18-g95f3eff6 at least the output of "$> ethtool -S
eth0" after the resume seems to be more reasonable, before the values were
crappy after suspend/resume. The commit was
Can you please test the 2.6.19-rc2-mm2 kernel?
Tested 2.6.19-rc3-mm1 without success :-(
Author: Auke Kok <email@example.com>
Date: Mon Nov 6 08:57:12 2006 -0800
[PATCH] e1000: Fix regression: garbled stats and irq allocation during swsusp
e1000: Fix suspend/resume powerup and irq allocation
From: Auke Kok <firstname.lastname@example.org>
After 7.0.33/2.6.16, e1000 suspend/resume left the user with an enabled
device showing garbled statistics and undetermined irq allocation state,
where `ifconfig eth0 down` would display `trying to free already freed irq`.
Explicitly free and allocate irq as well as powerup the PHY during resume
fixes when needed.
Signed-off-by: Auke Kok <email@example.com>
Signed-off-by: Jeff Garzik <firstname.lastname@example.org>