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 F.68 09/21/2015 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: queue_read_lock_slowpath+0x92/0xa0 _raw_read_lock+0x1c/0x20 no_wait [I didn't write down the offsets from here on so that I could get more of the stack] SyS_wait4 ? _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" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1556471/+attachment/4599246/+files/syslog ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1556471 Title: Connecting an Osprey 2 Mini (USB cellular wireless router) sometimes causes an endless reset loop or a kernel panic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1556471/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
