On Wed, 20 Jan 2016, Jason Gerecke wrote:
> I've been prompted to resurrect this question after fielding yet another
> question from a user encountering a locked-up system. We received a
> surprising number of reports of people encountering this issue in the
> past several weeks and that's only
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
On Sun, Nov 29, 2015 at 2:29 AM, Ioan-Adrian Ratiu wrote:
> On Fri, 20 Nov 2015 22
Hi Jiri,
On Tue, Dec 1, 2015 at 8:36 AM, Jiri Kosina wrote:
> On Fri, 20 Nov 2015, Ioan-Adrian Ratiu wrote:
>
>> The critical section protected by usbhid->lock in hid_ctrl() is too
>> big and because of this it causes a recursive deadlock. "Too big" means
>> the case statement and the call to hid
On Fri, 20 Nov 2015, Ioan-Adrian Ratiu wrote:
> The critical section protected by usbhid->lock in hid_ctrl() is too
> big and because of this it causes a recursive deadlock. "Too big" means
> the case statement and the call to hid_input_report() do not need to be
> protected by the spinlock (no UR
On Fri, 20 Nov 2015 22:19:02 +0200
Ioan-Adrian Ratiu wrote:
> The critical section protected by usbhid->lock in hid_ctrl() is too
> big and because of this it causes a recursive deadlock. "Too big" means
> the case statement and the call to hid_input_report() do not need to be
> protected by the
The critical section protected by usbhid->lock in hid_ctrl() is too
big and because of this it causes a recursive deadlock. "Too big" means
the case statement and the call to hid_input_report() do not need to be
protected by the spinlock (no URB operations are done inside them).
The deadlock happe