netdev - RE: e1000e fails after several S3 resumes (2.6.26 Debian, TP T60)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Oct 2008 09:22:58 -0700
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	Sanjoy Mahajan <sanjoy@....EDU>
CC:	Jesse Brandeburg <jesse.brandeburg@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	NetDEV list <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
Subject: RE: e1000e fails after several S3 resumes (2.6.26 Debian, TP T60) 

Sanjoy Mahajan wrote:
>> hm, does your kernel have CONFIG_PM defined?
> 
> It does have that defined:

ok
 
>> if it happens again please include lspci -vvv before and after
>> ethtool -r (see below)
> 
> I will.  Now I'm running BIOS 2.23, so I'm curious whether that
> 'upgrade' fixes the problem.
> 
> I say 'upgrade' because now S3 sleep and wakeup often take 60 seconds.
> I've also noticed ACPI errors in the 'dmesg'.  Once I have something
> reproducible I'll file a bugzilla report.

ick, it would be nice if the system vendors actually tested their acpi implementations on multiple OSes.
 
>> device was also claiming successfully transmitting, so I don't know
>> why the DHCP packets don't work, can you tcpdump on the network or
>> the dhcp server by chance?
> 
> I'll do that too on the next failure.  Is 'tcpdump host 18.38.0.1'
> sufficient or do I need a few -v switches?

I'm mostly looking for the conversation back and forth, so that should be fine.
Keep in mind that the first dhcp packet is usually a broadcast (not to a 
particular IP)
 
>> can you ifconfig eth0 promisc before doing suspend?  I'd be curious
>> if that fixed it.
> 
> If/when it reproduces, I'll add that line to the pre-suspend code.  (I
> use 's2ram', which I think sleeps with 'echo mem > /sys/power/state'
> and does a vt switch on wakeup).

okay, thanks
 
> Generally: For making debugging go smoothly, is it worth running a
> vanilla kernel rather than the Debian one?  I could try 2.6.26.7 or
> 2.6.27.3.  Is running 2.6.27.y not as useful as running 2.6.26.y, in
> case the bug is merely hidden but not solved in the new kernel?  On
> the other hand, I'm tempted to try 2.6.27.y in case it fixes the slow
> suspend/resume.

I think you should definitely try 2.6.27.y, the e1000e versions in the kernel 
are different than what is in ubuntu at least, so not sure if that applies to 
debian.--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html