[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <F169D4F5E1F1974DBFAFABF47F60C10A069DFFA0@orsmsx507.amr.corp.intel.com>
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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists