thinkpad x201 82577LM e1000e and wireless connections drop out, show high packet loss

Bug #833479 reported by Martin Pool on 2011-08-25
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
High
Unassigned

Bug Description

I have a Thinkpad x201 connected to wired ethernet through the docking station, running oneiric. It has previously been very reliable. For the last week or so the wired connection has been dropping out and then reconnecting after a few seconds. Obviously it's possible this is a hardware problem but nothing seems to have changed there. I might try booting from a natty usb stick and see if I can reproduce it.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: linux-image (not installed)
ProcVersionSignature: Ubuntu 3.0.0-9.14-generic 3.0.3
Uname: Linux 3.0.0-9-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 0/1
   Subdevice #0: subdevice #0
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf2520000 irq 44'
   Mixer name : 'Intel IbexPeak HDMI'
   Components : 'HDA:14f15069,17aa2155,00100302 HDA:80862804,17aa21b5,00100000'
   Controls : 12
   Simple ctrls : 6
Card29.Amixer.info:
 Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw 6QHT33WW-1.14'
   Mixer name : 'ThinkPad EC 6QHT33WW-1.14'
   Components : ''
   Controls : 1
   Simple ctrls : 1
Card29.Amixer.values:
 Simple mixer control 'Console',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
Date: Thu Aug 25 11:50:42 2011
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=a37b4b37-bf4a-4554-bce8-23f96cd1cc72
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
MachineType: LENOVO 3249CTO
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-9-generic root=UUID=8aff985d-377a-420d-a38e-62ce8bd54504 ro crashkernel=384M-2G:64M,2G-:128M quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.0.0-9-generic N/A
 linux-backports-modules-3.0.0-9-generic N/A
 linux-firmware 1.60
SourcePackage: linux
StagingDrivers: mei
UpgradeStatus: Upgraded to oneiric on 2011-08-18 (6 days ago)
dmi.bios.date: 05/31/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 6QET66WW (1.36 )
dmi.board.name: 3249CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6QET66WW(1.36):bd05/31/2011:svnLENOVO:pn3249CTO:pvrThinkPadX201:rvnLENOVO:rn3249CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 3249CTO
dmi.product.version: ThinkPad X201
dmi.sys.vendor: LENOVO

Martin Pool (mbp) wrote :
Brad Figg (brad-figg) on 2011-08-25
Changed in linux (Ubuntu):
status: New → Confirmed

Hi Martin,

We've only applied one patch recently to the e1000e driver and that came through upstream stable ("e1000e: alternate MAC address does not work on device id 0x1060"). Given it was device specific, it would not affect you. Any changes to the e1000e driver prior to that were done in the first upstream v3.0-rc1 release candidate which our Ubuntu 3.0.0-x.y kernels have been based upon since we began uploading 3.0 Ubuntu kernels. That being said, the issue you are seeing isn't likely due to any changes to the e1000e driver. It may very well be a hardware issue. It would be good to know if you are able to reproduce with an earlier kernel. Please let us know your results. Thanks.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete

I think this was something about my router; with ipv6 turned off there
it seems more stable. Because it's intermittent I'm going to leave
this incomplete for now.

I just booted 2.6.38-11.47 and (although the problem is intermittent so it's hard to be sure) I see zero loss in a traceroute immediately after booting, compared to ~75% loss on 3.0.0-10, and general irc and web usage is blessedly stable. So it looks pretty conclusively like a software problem, specifically a kernel rather than userspace, and a recent regression.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
importance: Undecided → High
tags: added: regression-proposed

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel currently in the release pocket than the one you tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.0.0-11.18

I could reproduce this yesterday in 3.0.0-11.17 so I think it's highly likely it is still open. I will try to narrow it down.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Martin Pool (mbp) on 2011-09-14
summary: - e1000e connection drops out
+ thinkpad x201 82577LM e1000e and wireless connections drop out, show
+ high packet loss
Martin Pool (mbp) wrote :

This seems to be ok in 3.0.0-11.18

Changed in linux (Ubuntu):
status: Confirmed → Fix Released
Martin Pool (mbp) wrote :

no, not actually fixed in -11.18, just intermittent. Some days it's totally fine, but when I reboot it suffers very badly. The correlation with rebooting makes me think it is either a laptop hardware problem or an oneiric software problem.

Changed in linux (Ubuntu):
status: Fix Released → Confirmed

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.0.0-12.19
Martin Pool (mbp) wrote :

I'm sorry to say yes this does still happen in 3.0.0-12.19

I was fixing a similar bug in NetworkManager (specific to having both wired and wifi connected at the same time to the same underlying network)... that's bug 856333. The upload of network-manager 0.9.1.90-0ubuntu2 fixes that issue.

Terry Burton (terryburton) wrote :

Long shot... Can you use another device with ping and tcpdump to determine whether the packet loss is during reception or transmission?

If it is only at reception then it might be that the 82577LM chipset is affected by the same issue as the 82579LM chipset reported in bug 870127. (Intel may be able to offer an answer here?)

Affected 82579LM users could use the following as a basis to workaround the issue:

Download the 1.5.1 e1000e drivers from http://sourceforge.net/projects/e1000/files/e1000e%20stable/1.5.1/
tar xvzf e1000e-1.5.1.tgz
cd e1000e-1.5.1/src
make # You will need to ensure that you have the kernel header files installed
rmmod e1000e # Remove current driver
insmod e1000e.ko
/etc/init.d/networking restart

A knowledgeable 82577LM user might determine this by modifying the patch at [1] (which is applied in 1.5.1 and later) to try the same technique with their chipset, presumably by replacing instances of I82579_LPI_CTRL_FORCE_PLL_LOCK_COUNT with I82577_LPI_CTRL_FORCE_PLL_LOCK_COUNT and I82579_LPI_CTRL with I82577_LPI_CTRL.

[1] http://patchwork.ozlabs.org/patch/109926/

Just a thought...

Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers