Messages in this thread | | | From | "Brandeburg, Jesse" <> | Date | Fri, 24 Oct 2008 09:22:58 -0700 | 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.
| |