Kernel crashes in rt2x00queue_get_entry+0x24

Bug #1419341 reported by dronus
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Low
Unassigned

Bug Description

When using an Logilink USB WiFi stick reported as Ralink Technology, Corp. RT5372 Wireless Adapter, I ancounter frequent disconnects despite good wifi signal, and repeated kernel crashes at rt2x00queue_get_entry+0x24.

The crash may happen from time to time, but can be provoked by heavy wifi traffic.

Maybe it is a problem with the drivers state management, because dmesg shows resets or replugs of the device if temporary disconnect happens. So I think the device may reset due to other problems (eg. flaky usb power), and the driver doesn't handle it well in all states. Maybe the above function is called with the device already disconnecting.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-24-generic 3.13.0-24.46
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: nf 1858 F.... pulseaudio
 /dev/snd/controlC0: nf 1858 F.... pulseaudio
CurrentDesktop: Unity
Date: Sat Feb 7 21:42:32 2015
InstallationDate: Installed on 2014-12-03 (66 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
MachineType: LENOVO 10BE0002MD
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic.efi.signed root=UUID=206fe64f-468c-48d5-913a-d0880e24a53d ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-24-generic N/A
 linux-backports-modules-3.13.0-24-generic N/A
 linux-firmware 1.127
RfKill:
 4: phy4: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/23/2013
dmi.bios.vendor: LENOVO
dmi.bios.version: FBKT54AUS
dmi.board.name: SHARKBAY
dmi.board.vendor: LENOVO
dmi.board.version: 0B98401 PRO
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnLENOVO:bvrFBKT54AUS:bd10/23/2013:svnLENOVO:pn10BE0002MD:pvrThinkCentreM83:rvnLENOVO:rnSHARKBAY:rvr0B98401PRO:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: 10BE0002MD
dmi.product.version: ThinkCentre M83
dmi.sys.vendor: LENOVO

Revision history for this message
dronus (paul-geisler) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
penalvch (penalvch) wrote :

dronus, thank you for reporting this and helping make Ubuntu better. As per http://support.lenovo.com/us/en/products/desktops-and-all-in-ones/thinkcentre-m-series-desktops/thinkcentre-m83 an update to your computer's buggy and outdated BIOS is available (FBKTA6A). If you update to this following https://help.ubuntu.com/community/BIOSUpdate does it change anything? If it doesn't, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

For more on BIOS updates and linux, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Please note your current BIOS is already in the Bug Description, so posting this on the old BIOS would not be helpful. As well, you don't have to create a new bug report.

Once the BIOS is updated, and all of the information above is provided, then please mark this report Status Confirmed.

Thank you for your understanding.

tags: added: bios-outdated-fbkta6a
Changed in linux (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Expired
Revision history for this message
dronus (paul-geisler) wrote :

There is a new twist to this: The effect can be remedied by using a shorter USB extension cable. So it is obvious that the crashes result from bad communication or bad reaction of the device due to insufficent power.

Question is: Is a misbehaveing USB device like something like bad hardware, that may trigger crashes, or do we see USB devices as unreliable devices we need to handle.

The crash happend once while unplugging the WLAN stick while data was transfered. This is a clue that the same state may be provoked by unplugging of the device in an inconvenient moment, which is of course totally legal and should NOT crash the system.

Should we go on here or should I file a new bug with a new description of the crashs's cause?

Changed in linux (Ubuntu):
status: Expired → Incomplete
Revision history for this message
dronus (paul-geisler) wrote :

Also, I don't think it is related to the machines BIOS. If you like, I can try to trigger the bug by using the WLAN device on some completely different machine, would that be feasable for going "confirmed" ?

Revision history for this message
penalvch (penalvch) wrote :

dronus, filing a new report is not necessary at this point. However, the BIOS should be updated.

Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.