lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 31 Dec 2013 20:13:04 +0100
From:	Vi0L0 <vi0l093@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Thomas Gleixner <tglx@...utronix.de>
Subject: 3.13 <= rc6. Using USB 2.0 devices is braking the system when using "threadirqs" kernel option

Hi,

as said the problem does not occur when not using "threadirqs" kernel option.


Problem:
Connecting most of the devices to USB 2.0 port is causing instability (or 
breakage) of the whole system.


Tested on My PC:
GNU/Linux: Arch Linux x86_64 with linux 3.13 <= rc6
Motherboard: MSI Z77A-GD65   BIOS: 10.11 (newest)

Partialy tested on a laptop:
GNU/Linux: Ubuntu 13.10 x86_64 with linux 3.13 rc3
MODEL: TOSHIBA SATELLITE PRO R950


My PC:
------
It's easiest to notice when connecting USB mouse and starting DM/X.
USB keyborad works fine so I'm able to login to tty and do anything there, but 
whenever I start DM/X and trying to move mouse' cursour the X freeze in less 
than 1 second. Establishing the new ssh connection then is impossible. 
Fortunatelly sometimes (but only sometimes) ssh session established before 
DM/X start is alive so I can trace whatever you need, still it's impossible to 
kill X process and perform system' reboot.
I've tested 2 mouses with same results: A4tech X750 and Razor DeathAdder
Also checked out 2 different DMs: KDM and GDM.

Connecting mouse to USB 3.0 port is solving the mouse' problem, but then other 
devices connected to USB 2.0 ports are causing problems - ie. using Logitech 
webcam for some short time is making KDE 4.12.0 freeze.


In the attachements I'm sending my system' logs catched on 3.13 rc6 kernel.
First log - rc6-journalctl-less-debug.log - was catched on a kernel build with 
some basic debugging enabled, while second log - rc6-journalctl-more-
debug.tar.gz - was catched on a kernel build with much more debugging.
I'm not sure if it will be helpfull enought. I would be happy to help more, 
just let me know what can I do since I'm no expert in such debugging...

What I believe is most relevant in the logs are those lines (taken from rc6-
journalctl-less-debug.log, line numbers on the left):

2105 gru 31 14:40:31 xaos systemd[1]: Started K Display Manager.
2106 gru 31 14:40:32 xaos kernel: usb 3-1.2: ep 82: reserve intr @ 0+8 (0.0+1) 
[1/3 us] mask 1c01
2107 gru 31 14:40:32 xaos kernel: usb 3-1.2: link qh1-1c01/ffff8800d7cbcf00 
start 0 [1/3 us]
2108 gru 31 14:41:40 xaos kernel: ------------[ cut here ]------------
2109 gru 31 14:41:40 xaos kernel: WARNING: CPU: 7 PID: 198 at 
kernel/watchdog.c:245 watchdog_overflow_callback+0x9b/0xc0()
2110 gru 31 14:41:40 xaos kernel: Watchdog detected hard LOCKUP on cpu 7
2114 gru 31 14:41:40 xaos kernel: CPU: 7 PID: 198 Comm: irq/16-ehci_hcd Not 
tainted 3.13.0-2-mainline #1
2162 gru 31 14:41:40 xaos kernel: INFO: rcu_preempt detected stalls on 
CPUs/tasks: { 7} (detected by 0, t=60002 jiffies, g=592, c=591, q=0)
2165 gru 31 14:41:40 xaos kernel: CPU: 7 PID: 198 Comm: irq/16-ehci_hcd 
Tainted: G        W    3.13.0-2-mainline #1

I'm also sending my kernel config (rc6-config.x86_64) used to catch rc6-
journalctl-less-debug.log


Laptop:
------
Today I had quick access to TOSHIBA SATELLITE PRO R950 laptop, i tested how 
it's working with "threadirqs" option. 
It wasn't able to even start a DM, it was stuck before, throwing these lines 
on a tty:
BUG: soft lockup - CPU#1 stuck for 23s! [fsck:264]
BUG: soft lockup - CPU#3 stuck for 22s! [fsck:254]
INFO: rcu_sched detected stalls on CPU/tasks: { 2}
But after the reboot (without "threadirqs" it was working perfectly fine) there 
was nothing interesting in the syslog, not even one info about the stalls. As 
said I had a quick access and no time for further investigatiuon. In the 
attachement I'm sending its lsusb and lspci (toshiba-lspci_lsusb.txt).
ATM I don't have access to this laptop.



I believe that this problem is much more general and touching many PCs with 
intel (and maybe also non-intel) chipsets inside.
I wrote about this problem on linux-usb@...r.kernel.org, but I was told to get 
back here because the problem is affecting also other subsystems (that's why i 
put Mr Thomas Gleixner on the CC).


BTW: Happy New Year! :-)

Regards
Vi0L0

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)

View attachment "rc6-config.x86_64" of type "text/x-mpsub" (111442 bytes)

View attachment "rc6-journalctl-less-debug.log" of type "text/x-log" (210888 bytes)

Download attachment "rc6-journalctl-more-debug.tar.gz" of type "application/x-compressed-tar" (74371 bytes)

View attachment "my_pc-lspci_lsusb" of type "text/plain" (2591 bytes)

View attachment "toshiba-lspci_lsusb" of type "text/plain" (2493 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ