10ec:8172 r8192se_pci: rtl8191SEVA2 fails to transmit certain mumble packets

[Steve Langasek]

Trying to use a new laptop with the Canonical mumble server, I have found that the rtl8191SEVA2 wireless card fails to send certain packets out. This is shown in the packet captures I'll be attaching shortly: packet 23 in 'mumble-local.pcap', as well as all subsequent retransmission attempts, never make it to the gateway (mumble-inside.pcap).

This is reproducible with both a lucid and a maverick kernel, and has been tested on multiple different wireless networks (with different routers). If I connect the laptop over ethernet instead, it has no difficulty connecting to mumble.

A cursory examination of the troublesome packet doesn't tell me what makes it different from other packets. I have not noticed any other connection problems or slow connections that would suggest there are other retransmission problems, only when connecting to mumble; and the problem is 100% reproducible when connecting to the mumble server.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: linux-image-2.6.35-22-generic 2.6.35-22.33
Regression: No
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: vorlon 2518 F.... pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf2520000 irq 46'
   Mixer name : 'Intel IbexPeak HDMI'
   Components : 'HDA:14f15069,17aa2155,00100302 HDA:80862804,17aa21b5,00100000'
   Controls : 14
   Simple ctrls : 6
Card29.Amixer.info:
 Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw 6QHT30WW-1.11'
   Mixer name : 'ThinkPad EC 6QHT30WW-1.11'
   Components : ''
   Controls : 1
   Simple ctrls : 1
Card29.Amixer.values:
 Simple mixer control 'Console',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [off]
Date: Mon Oct 4 17:51:47 2010
HibernationDevice: RESUME=UUID=f6ab3c43-61b4-4af7-bf03-fa3b147a1de0
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
Lsusb:
 Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 004: ID 0a5c:217f Broadcom Corp. Bluetooth Controller
 Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: LENOVO 3249CTO
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-22-generic root=/dev/mapper/hostname-root ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
RelatedPackageVersions: linux-firmware 1.38
SourcePackage: linux
dmi.bios.date: 08/23/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6QET52WW (1.22 )
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:bvr6QET52WW(1.22):bd08/23/2010:svnLENOVO:pn3249CTO:pvrThinkPadX201:rvnLENOVO:rn3249CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 3249CTO
dmi.product.version: ThinkPad X201
dmi.sys.vendor: LENOVO

[Jeremy Foshee (jeremyfoshee)]

Hi Steve,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Steve Langasek (vorlon)]

The latest mainline upstream kernel package available, 2.6.36-999.201010151118, provides no driver for this module.

[Jane Silber (silbs)]

I also have a new Thinkpad x201s with Thinkpad wireless and Steve asked me to try to replicate this. I have Mumble issues, but am not sure if it's the same issue as Steve or not (i.e., I'm not sure what the symptoms of Steve's bug are).

On a wired connection, Mumble seems to work but I do get a channel message of "UDP packets cannot be sent to or received from the server, switching to TCP mode", followed by a message of "UDP packets can be sent to and received from the server. Switching back to UDP mode."

On a wireless connection, I get repeated (i.e,. once a minute) messages of
- Connected
- Server connection failed. The remote host closed the connection.
- Reconnecting

Network manager looks like it is still connected throughout that series of messages, but Steve did mention to me that these machines require regular module loads/unloads to stay connected, so that could be the root cause of the Mumble behavior I see on wireless.

[Steve Langasek (vorlon)]

On Thu, Oct 21, 2010 at 03:22:28PM -0000, Jane Silber wrote:
> On a wireless connection, I get repeated (i.e,. once a minute) messages of
> - Connected
> - Server connection failed. The remote host closed the connection.
> - Reconnecting

Yep, that's the symptom of this bug.

I've replaced the realtek in my laptop with a Centrino Ultimate-N card and
plan to arrange to pass the realtek card off to someone on the kernel team
at UDS to hammer on.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Steve Langasek (vorlon)]

A hallway conversation here at UDS with one of the kernel guys brought up the suggestion that maybe this was related to QoS. A look at the trace shows that, indeed, the packet that fails to be sent is the first one that uses DSCP class selector 5 instead of 1 or 0. Since no other traffic that runs on my laptop uses DSCP hints that I know if, this is likely to be the culprit.

[penalvch (penalvch)]

Steve Langasek, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Steve Langasek (vorlon)]

Christopher,

On Wed, Aug 14, 2013 at 10:49:20AM -0000, Christopher M. Penalver wrote:
> Steve Langasek, this bug was reported a while ago and there hasn't been
> any activity in it recently. We were wondering if this is still an
> issue? If so, could you please test for this with the latest development
> release of Ubuntu? ISO images are available from
> http://cdimage.ubuntu.com/daily-live/current/ .

The wifi card in question was useless to me as a result of this bug and
other driver bugginess, so as a result I yanked it from the laptop, replaced
it with an intel centrino wifi, and delivered the realtek card to Tim
Gardner on the kernel team. Perhaps he can tell you whether it works any
better now. :)

[penalvch (penalvch)]

Tim Gardner, any news on the card Steve Langasek gave you working in Saucy?

[Tim Gardner (timg-tpi)]

That was nearly 3 years ago. I can hardly remember what I had for breakfast.

[penalvch (penalvch)]

Tim Gardner, thanks for the quick response.

Steve Langasek, given this, let us close this report, and we could always reopen if the card rises back from the grave.