On 09/24/2013 05:29 AM, Jiri Kosina wrote:

On Mon, 16 Sep 2013, Joseph Salisbury wrote:

quoted

quoted

quoted

Can you explain a little further?  Mark commit a4a23f6 as bad?  An
initial bisect already reported that was the first bad commit, so it
can't be marked bad.  The oops on memcpy() happens after commit a4a23f6
is reverted.  The oops on memcpy() did not happen before a4a23f6 was
committed, so I assume this new oops was introduced by a change later.

Right now I'm bisecting down the oops on memcpy() by updating the bisect
with good or bad, depending if the test kernel hit the oops.  I then
revert a4a23f6, so that revert is the HEAD of the tree each time before
building the kernel again(As long as the commit spit out by bisect is
after when a4a23f6 was introduced).

Yep.  Please continue bisecting the memcpy() oops.

kmemdup() is just a kzalloc() followed by a memcpy().  When we split it
apart by reverting the patch then we would expect the oops to move to
the memcpy() part.  Somehow "desc" is a bogus pointer, but I don't
immediately see how that is possible.

regards,
dan carpenter

Thanks for the details.  We'll continue the bisect and let you know how
it goes.

Did this please yield any useful result?

Thanks,

After further testing reverting the following commit does in fact
resolve the bug:

commit b1a1442a23776756b254b69786848a94d92445ba
Author: Jiri Kosina [off-list ref]
Date: Mon Jun 3 11:27:48 2013 +0200

    HID: core: fix reporting of raw events

Reverting this commit in v3.12-rc2 prevents the system from locking up, which happens when connecting a bluetooth trackpad.

Jiri,  do you think we should revert this patch, or is there some further debugging/data collecting you would like to do?

Thanks,

Joe