← Back to team overview

kernel-packages team mailing list archive

[Bug 1556471] Re: Connecting an Osprey 2 Mini (USB cellular wireless router) sometimes causes an endless reset loop or a kernel panic


Thanks. I found the update in question. (It seems that some HP BIOS
updates install on Linux, and others require Windows; luckily I had a
dual-boot setup available to install it.)

$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

I can confirm that the issue still occurs. I also determined some
further information:

- The hangs are definitely triggered upon disconnecting the device (or
turning it off) during a reset loop. This has a 100% correlation so far;
if it's not in a reset loop when I disconnect it (even if there was a
loop earlier), the kernel is fine, and if it's in a reset loop but I
don't disconnect it, the kernel is also fine.

- The kernel/device have, on occasion, recovered from a reset loop
"spontaneously" after several seconds. (This has happened twice now.) My
current boot is one such occasion; I attached the device while the
system was booting (reasonably late in the boot sequence), and the reset
loop stopped after a while. I've attached the syslog from this boot
session, in case it helps.

- I managed to catch one of the non-panic hangs (i.e. computer responds
to no input, not even Alt-SysRq combinations, but the Caps Lock light
does not flash) while on the Ctrl-Alt-F1 text terminal. It happened when
I disconnected the Osprey Mini 2 during a reset loop, and started (as
happens in other cases) with text scrolling far too fast to read. Then
it stabilized into displaying messages about CPUs being stuck every 20s
or so. One of them was along the lines of "CPU #2 HARD lockup" (I forget
the exact phrasing, and didn't have time to write it down or take a
photograph); all the others mentioned other CPUs (mostly CPU #3). The
error message for CPU #3 was always almost the same:

NMI watchdog: BUG: CPU #3 stuck for 22s! [apache2:4544]

(the time shown changed on occasion, sometimes it was 21s)

The information only stayed onscreen for a limited time, so I couldn't
write much down; I decided that the top of the stack trace would
probably be the most helpful piece of information for debugging:

no_wait [I didn't write down the offsets from here on so that I could get more of the stack]
? _task_stopped_code

Additionally, after a while of this, the CPU fan settled on a speed that
it normally reaches if 1 of my 4 cores is running at 100% and the others
are all idle. It thus seems most likely that CPU #2 was in a tight loop,
and the other CPUs were blocking on locks that CPU #1 held, thus
preventing the system making any progress.

- The error message in the panic case is not always the same. I've seen
a few different stacktraces, and although I can't remember the details,
they were definitely different each time.

** Attachment added: "system spontaneously recovering from a reset loop"

** Changed in: linux (Ubuntu)
       Status: Incomplete => Confirmed

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  Connecting an Osprey 2 Mini (USB cellular wireless router) sometimes
  causes an endless reset loop or a kernel panic

Status in linux package in Ubuntu:

Bug description:
  Steps to reproduce (happens > 50% of the time, but not every time):

  Turn on an Osprey 2 Mini, and connect it to a USB port via a USB cable
  while both the device and computer are on (i.e. hotplug).

  Observed symptoms:
  - sometimes the Osprey 2 Mini goes into an endless reset loop (visible as the LEDs on the front of the device flashing rapidly), being reset approximately every 200ms; on such occasions, the Ubuntu user interface often reacts as though I'd inserted an audio CD containing corrupted data (e.g. via repeatedly adding an "Audio CD" icon to the launcher and then removing it, and putting up dialog boxes complaining about failure to read the data).
  - sometimes the kernel panics (often some time after the reset loop starts, perhaps up to 10 seconds); when this happens there was always or nearly always a reset loop occurring beforehand.
  - sometimes the device resets once or not at all, then works as expected (showing up as a network interface, and allowing me to communicate to the Internet with a wired connection); I'm currently using an Osprey 2 Mini for this purpose right now.

  The kernel panics lock up the entire system (forcing a hard power
  off). lt-Sysrq commands don't work in this state (even though I have
  them enabled), and sometimes the Caps Lock light flashes repeatedly.
  The logs end some time before the panic occurs.


  The reset loops also occurred when I was using Ubuntu vivid. The
  kernel panics only happened after an upgrade to wily. Output of lsusb
  -v is attached.

  ApportVersion: 2.19.1-0ubuntu5
  Architecture: amd64
   /dev/snd/controlC0:  ais523     6233 F.... pulseaudio
  CurrentDesktop: Unity
  DistroRelease: Ubuntu 15.10
  HibernationDevice: RESUME=UUID=bfbc4bf8-2e40-4799-bbef-9c5044c87007
  InstallationDate: Installed on 2014-06-03 (648 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  MachineType: Hewlett-Packard HP Pavilion 15 Notebook PC
  Package: linux (not installed)
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-32-generic.efi.signed root=UUID=e92d655d-cf36-4d45-90e7-30a0f9d0949e ro quiet splash
  ProcVersionSignature: Ubuntu 4.2.0-32.37-generic 4.2.8-ckt4
   linux-restricted-modules-4.2.0-32-generic N/A
   linux-backports-modules-4.2.0-32-generic  N/A
   linux-firmware                            1.149.3
   0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
  Tags:  wily
  Uname: Linux 4.2.0-32-generic x86_64
  UpgradeStatus: Upgraded to wily on 2016-02-18 (22 days ago)
  UserGroups: adm audio cdrom dip lpadmin plugdev sambashare sudo wireshark
  _MarkForUpload: True
  dmi.bios.date: 12/04/2013
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.42
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 2186
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: 35.12
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.chassis.version: Chassis Version
  dmi.modalias: dmi:bvnInsyde:bvrF.42:bd12/04/2013:svnHewlett-Packard:pnHPPavilion15NotebookPC:pvr098B110000404100000620180:rvnHewlett-Packard:rn2186:rvr35.12:cvnHewlett-Packard:ct10:cvrChassisVersion:
  dmi.product.name: HP Pavilion 15 Notebook PC
  dmi.product.version: 098B110000404100000620180
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to: