Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753508Ab3IXNxB (ORCPT ); Tue, 24 Sep 2013 09:53:01 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:35528 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750882Ab3IXNw7 (ORCPT ); Tue, 24 Sep 2013 09:52:59 -0400 Message-ID: <5241992E.3090805@canonical.com> Date: Tue, 24 Sep 2013 09:52:46 -0400 From: Joseph Salisbury User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Jiri Kosina CC: Dan Carpenter , thomas@m3y3r.de, list@osuosl.org, Haiyang Zhang , LKML , open@osuosl.org, HID CORE LAYER , devel@linuxdriverproject.org Subject: Re: [v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup References: <5237430B.5040009@canonical.com> <20130916203824.GP25896@mwanda> <52376ED9.5080208@canonical.com> <20130916210503.GQ25896@mwanda> <5237A5D5.8010006@canonical.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2423 Lines: 58 On 09/24/2013 05:29 AM, Jiri Kosina wrote: > On Mon, 16 Sep 2013, Joseph Salisbury wrote: > >>>> 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, > Thanks for following up, Jiri. It's been a little tricky narrowing this one down. We bisected a couple of times, and both bisects indicated the following commits as the first bad: commit b1a1442a23776756b254b69786848a94d92445ba Author: Jiri Kosina Date: Mon Jun 3 11:27:48 2013 +0200 HID: core: fix reporting of raw events However, reverting this commit does not stop the system from locking up, when the wireless trackpad is connected. I was thinking of maybe using a brute force method and pulling out all the HID changes, added in 3.11-rc1 to ensure the bug goes away. Then add a group back in at a time to narrow down the commit that introduced this. The bisect should have done this, but I'm not sure why it didn't. It would be greatly appreciated if you had any other suggestions on tracking down the cause? Thanks, Joe -- 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/