← 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


OK, after discussion on the upstream mailing lists, we've concluded that
the bug causing the reset loop is in the device itself (that it is
failing to respect the USB protocols), but that the buggy part of the
Osprey 2 Mini is related to installing the Windows and Mac OS X drivers,
which aren't needed by Linux. It's possible to blacklist the buggy part
(which does not work under Linux even when the reset loops don't happen)
via changing a module parameter; this causes the buggy part (the driver
installation) to fail, thus allowing the part that most users are using
the device for (the Internet connection) to work.

While the system is running, this can be achieved via the following

$ echo 1bbb:f000:i | sudo tee /sys/module/usb_storage/parameters/quirks

(The 1bbb:f000 is specific to the device in question, so it shouldn't
have effects on other devices.)

I've tested this on the mainline kernel, and it seems to prevent the bug
from occurring. I suspect that the same would occur on Ubuntu kernels,
but have not tested this yet (I can test it if you think that would be

It might also be possible to set the parameter in question
(usb_storage.quirks=1bbb:f000:i) via the kernel command line or
configuration; I don't know of a method other than telling the
bootloader to set it, which would be far too intrusive a solution for a
problem that won't affect most users, but there might be a less
intrusive one. This would have the advantage of preventing a crash (on
an Ubuntu kernel) if the device were attached during boot. Eventually
the Ubuntu kernel is likely to catch up to upstream, meaning that the
impact would be much lower and people could just disconnect and
reconnect the device to work around this situation.

I think it might be worthwhile to get Ubuntu to set the parameter in
question automatically in order to fix the bug. However, I'm not sure
where the best place to set it would be. The obvious thing to do is to
use /etc/sysctl.d, but unfortunately it only seems to affect /proc files
rather than /sys files (and the /proc/sys tree and /sys trees are
different). Alternatively, if it's possible to set default module
arguments in the kernel configuration, that would be another good place.

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: