On Thu, 19 Dec 2013, David Herrmann wrote:
> As this thread doesn't really contain any oops message nor the exact
> driver name (except mentioning hyperv and magicmouse),
FWIW I recall the oopses being present somewhere in the ubuntu bug
tracker, referenced in this thread.
Thanks,
--
Jiri Ko
Hi
On Thu, Dec 19, 2013 at 11:08 AM, David Herrmann wrote:
> Hi
>
> On Thu, Dec 19, 2013 at 10:59 AM, Jiri Kosina wrote:
>> On Thu, 19 Dec 2013, David Herrmann wrote:
>>
>>> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>>> > index 253fe23..81eacd3 100644
>>> > --- a/drivers/hid
Hi
On Thu, Dec 19, 2013 at 10:59 AM, Jiri Kosina wrote:
> On Thu, 19 Dec 2013, David Herrmann wrote:
>
>> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> > index 253fe23..81eacd3 100644
>> > --- a/drivers/hid/hid-core.c
>> > +++ b/drivers/hid/hid-core.c
>> > @@ -1334,7 +1334,7 @
On Thu, 19 Dec 2013, David Herrmann wrote:
> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > index 253fe23..81eacd3 100644
> > --- a/drivers/hid/hid-core.c
> > +++ b/drivers/hid/hid-core.c
> > @@ -1334,7 +1334,7 @@ int hid_report_raw_event(struct hid_device *hid, int
> > type,
Hi
On Mon, Dec 16, 2013 at 2:01 PM, Jiri Kosina wrote:
> On Fri, 27 Sep 2013, Joseph Salisbury wrote:
>
>> >> commit b1a1442a23776756b254b69786848a94d92445ba
>> >> Author: Jiri Kosina
>> >> Date: Mon Jun 3 11:27:48 2013 +0200
>> >>
>> >> HID: core: fix reporting of raw events
>> >>
>> >> Rev
On Fri, 27 Sep 2013, Joseph Salisbury wrote:
> >> commit b1a1442a23776756b254b69786848a94d92445ba
> >> Author: Jiri Kosina
> >> 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
On Mon, Sep 30, 2013 at 04:35:47PM +0200, Jiri Kosina wrote:
> On Fri, 27 Sep 2013, Dan Carpenter wrote:
>
> > It looks like magicmouse_raw_event() returns 1 on success and 0 on
> > failure.
>
> Good catch indeed.
>
> I am not completely sure whether we are going to fix an oops or not by
> this
On Fri, 27 Sep 2013, Dan Carpenter wrote:
> It looks like magicmouse_raw_event() returns 1 on success and 0 on
> failure.
Good catch indeed.
I am not completely sure whether we are going to fix an oops or not by
this, as I haven't seen the actual oops anywhere in this thread :) But
definitely
On Fri, Sep 27, 2013 at 06:24:12PM +0300, Dan Carpenter wrote:
>
> It looks like magicmouse_raw_event() returns 1 on success and 0 on
> failure.
Fixing the return codes is a good idea but it won't fix the oops.
What's the point of returning 1 and 0? In the current code no one
cares and both are
On Fri, Sep 27, 2013 at 10:42:10AM -0400, Joseph Salisbury wrote:
> On 09/27/2013 06:50 AM, Jiri Kosina wrote:
> > On Wed, 25 Sep 2013, Joseph Salisbury wrote:
> >
> >> After further testing reverting the following commit does in fact
> >> resolve the bug:
> >>
> >> commit b1a1442a23776756b254b6978
On 09/27/2013 06:50 AM, Jiri Kosina wrote:
> On Wed, 25 Sep 2013, Joseph Salisbury wrote:
>
>> After further testing reverting the following commit does in fact
>> resolve the bug:
>>
>> commit b1a1442a23776756b254b69786848a94d92445ba
>> Author: Jiri Kosina
>> Date: Mon Jun 3 11:27:48 2013 +0200
>
On Wed, 25 Sep 2013, Joseph Salisbury wrote:
> After further testing reverting the following commit does in fact
> resolve the bug:
>
> commit b1a1442a23776756b254b69786848a94d92445ba
> Author: Jiri Kosina
> Date: Mon Jun 3 11:27:48 2013 +0200
>
> HID: core: fix reporting of raw events
>
>
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
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
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
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
On 09/16/2013 05:05 PM, Dan Carpenter wrote:
> On Mon, Sep 16, 2013 at 04:49:29PM -0400, Joseph Salisbury wrote:
>> On 09/16/2013 04:38 PM, Dan Carpenter wrote:
>>> On Mon, Sep 16, 2013 at 01:42:35PM -0400, Joseph Salisbury wrote:
Reverting the patch changes the driver back to useing kzalloc()
On 09/16/2013 04:38 PM, Dan Carpenter wrote:
> On Mon, Sep 16, 2013 at 01:42:35PM -0400, Joseph Salisbury wrote:
>> Reverting the patch changes the driver back to useing kzalloc() and
>> memcpy() instead of kmemdup. Doing so has uncovered another bug, which
>> causes an oops on memcpy()[1]. We a
On Mon, Sep 16, 2013 at 01:42:35PM -0400, Joseph Salisbury wrote:
> Reverting the patch changes the driver back to useing kzalloc() and
> memcpy() instead of kmemdup. Doing so has uncovered another bug, which
> causes an oops on memcpy()[1]. We are in the process of bisecting that
> one now and
On Mon, Sep 16, 2013 at 04:49:29PM -0400, Joseph Salisbury wrote:
> On 09/16/2013 04:38 PM, Dan Carpenter wrote:
> > On Mon, Sep 16, 2013 at 01:42:35PM -0400, Joseph Salisbury wrote:
> >> Reverting the patch changes the driver back to useing kzalloc() and
> >> memcpy() instead of kmemdup. Doing s
20 matches
Mail list logo
