Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1210010 > unrolled thread

Bluetooth related possible system hard lockups

Back to article view | Back to linux.kernel

Contents

  Bluetooth related possible system hard lockups Jamin Collins <jamin.collins@gmail.com> - 2015-08-19 22:10 +0200
    Re: Bluetooth related possible system hard lockups Jamin Collins <jamin.collins@gmail.com> - 2015-08-19 23:10 +0200
    Re: Bluetooth related possible system hard lockups Vinicius Costa Gomes <vinicius.gomes@intel.com> - 2015-08-20 01:00 +0200

#1210010 — Bluetooth related possible system hard lockups

I've recently started experiencing what appear to be hard lockups on
what has otherwise been a very solid system (Lenovo W530 Thinkpad).
I'm running a fully updated Arch Linux install on it, and have been
for a few months (since roughly April of this year).  Just before
experiencing these lockups I started using a bluetooth mouse.

When the apparent lockup occurs:
- the laptop screen seems to be off (no display)
- the CPU fan is running at a moderate speed (not the slowest, and not
the fastest)
- no apparent disk activity
- nothing in journalctl (when I hard reset I find only a gap, last
entry hours before)
- unresponsive to network requests (ping, etc)

The only way I've found to recover the system thus far is a hard reset
(hold power for 4+ seconds).

I know it involves bluetooth being on, possibly requires having
connected a device, and then some indeterminate amount of time away
from the system (lack of user interaction).  I'm currently testing
with bluetooth on, but no device connected to see if the issue occurs.

The kernel in question:
Linux version 4.1.5-1-ARCH (builduser@tobias) (gcc version 5.2.0 (GCC)
) #1 SMP PREEMPT Tue Aug 11 15:41:14 CEST 2015

Bluetooth:
Bluetooth daemon 5.33

The bluetooth device I've been using is a Thinkpad Bluetooth Laser Mouse:
ThinkPad Bluetooth Laser Mouse as
/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:11/0005:17EF:6002.0001/input/input19

I'm not subscribed to this list, so please CC me on replies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1210024

Issue Update

I have not been successful in reproducing the issue *without*
connecting a bluetooth device at least once.

I have however actually witnessed the lockup now:
- the screen does *not* turn off as part of the lockup
- initially the keyboard was non-responsive
- after a few seconds of use the jmouse stopped responding
- was able to momentarily reconnect the bluetooth mouse and then it
too stopped responding

On Wed, Aug 19, 2015 at 1:04 PM, Jamin Collins <jamin.collins@gmail.com> wrote:
> I've recently started experiencing what appear to be hard lockups on
> what has otherwise been a very solid system (Lenovo W530 Thinkpad).
> I'm running a fully updated Arch Linux install on it, and have been
> for a few months (since roughly April of this year).  Just before
> experiencing these lockups I started using a bluetooth mouse.
>
> When the apparent lockup occurs:
> - the laptop screen seems to be off (no display)
> - the CPU fan is running at a moderate speed (not the slowest, and not
> the fastest)
> - no apparent disk activity
> - nothing in journalctl (when I hard reset I find only a gap, last
> entry hours before)
> - unresponsive to network requests (ping, etc)
>
> The only way I've found to recover the system thus far is a hard reset
> (hold power for 4+ seconds).
>
> I know it involves bluetooth being on, possibly requires having
> connected a device, and then some indeterminate amount of time away
> from the system (lack of user interaction).  I'm currently testing
> with bluetooth on, but no device connected to see if the issue occurs.
>
> The kernel in question:
> Linux version 4.1.5-1-ARCH (builduser@tobias) (gcc version 5.2.0 (GCC)
> ) #1 SMP PREEMPT Tue Aug 11 15:41:14 CEST 2015
>
> Bluetooth:
> Bluetooth daemon 5.33
>
> The bluetooth device I've been using is a Thinkpad Bluetooth Laser Mouse:
> ThinkPad Bluetooth Laser Mouse as
> /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:11/0005:17EF:6002.0001/input/input19
>
> I'm not subscribed to this list, so please CC me on replies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210065

Hi Jamin,

Jamin Collins <jamin.collins@gmail.com> writes:

> I've recently started experiencing what appear to be hard lockups on
> what has otherwise been a very solid system (Lenovo W530 Thinkpad).
> I'm running a fully updated Arch Linux install on it, and have been
> for a few months (since roughly April of this year).  Just before
> experiencing these lockups I started using a bluetooth mouse.
>
> When the apparent lockup occurs:
> - the laptop screen seems to be off (no display)
> - the CPU fan is running at a moderate speed (not the slowest, and not
> the fastest)
> - no apparent disk activity
> - nothing in journalctl (when I hard reset I find only a gap, last
> entry hours before)
> - unresponsive to network requests (ping, etc)
>
> The only way I've found to recover the system thus far is a hard reset
> (hold power for 4+ seconds).
>

Without more information (the backtrace of the crash, from the kernel
logs or even a picture of the screen showing the crash dump), it is hard
to be sure. I can only guess.

This looks like this issue (for one colleague on a very similar setup as
yours, it was the case):

http://thread.gmane.org/gmane.linux.kernel.input/45023

I just checked, that patch is in the stable queue, and for little it
missed the 4.1.6 deadline, but it should appear on 4.1.7 (if it is
released) or 4.2 (for sure).

You can also apply that patch locally and see if solves your problem,
or you can give the input subsystem kernel tree a try:

https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git


Cheers,
--
Vinicius
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web