On Fri, 18 Mar 2016 12:36:42 -0400 (EDT)
Alan Stern wrote:
> All right, I have taken Oliver's suggestion. The patch below refactors
> the code to consolidate the common activities in a new function,
> hid_restart_io().
>
> Daniel, can you please test this patch?
Alan, this patch work
On Tue, 1 Mar 2016 17:15:56 -0500 (EST)
Alan Stern wrote:
> Don't worry about the Elan driver. Instead, let's see if this patch
> fixes the problem.
Yes, this patch fixed the problem. I can suspend and resume
without those repeated "reset" messages ;)
It appears just 1 time an
On Tue, 1 Mar 2016 15:55:00 -0500 (EST)
Alan Stern wrote:
> No messages about "usbhid_start urb" or "no input endpoint!" or
> "usbhid_start fail urb"? That means usbhid_start() isn't getting
> called. Which means the device in question probably isn't being used
> at all.
> Do you know what t
On Tue, 1 Mar 2016 10:25:30 -0500 (EST)
Alan Stern wrote:
> Now we're making progress! That shows a problem right there; we ought
> to have more stuff about 3-1.6 between those two lines.
>
> The next patch adds some more debugging output. For this test you
> don't even have to suspend the s
On Tue, 1 Mar 2016 10:25:30 -0500 (EST)
Alan Stern wrote:
> Now we're making progress! That shows a problem right there; we ought
> to have more stuff about 3-1.6 between those two lines.
>
> The next patch adds some more debugging output. For this test you
> don't even have to suspend the s
On Mon, 29 Feb 2016 16:28:40 -0500 (EST)
Alan Stern wrote:
> Okay, that's what I had guessed. Somehow usbhid->urbin is getting set
> to NULL. Maybe the patch below will indicate why. When you post the
> log, include everything that mentions the 3-1.6 device -- even if they
> precede the sus
On Wed, 24 Feb 2016 14:24:44 -0500 (EST)
Alan Stern wrote:
> I intended the patch not to cause any call traces, but it did anyway.
> So let's drop the questionable code and try something that will be
> completely safe.
Ok, here's what I got:
Feb 24 19:16:41 tux kernel: [ 717.316048]
On Tue, 23 Feb 2016 11:48:51 -0500 (EST)
Alan Stern wrote:
> I don't see any crash in that photo.
Sorry. By "crash" I mean "unable to use the keyboard". Maybe I
used the wrong term.
> Also, it looks like the log results in this run were different from
> what you posted before. Earlier
On Tue, 23 Feb 2016 10:19:30 -0500 (EST)
Alan Stern wrote:
> All right; let's try a slightly different approach that shouldn't cause
> any crashes at all.
Unfortunately it still crashed with this new patch. I took a
picture:
http://imgur.com/OJCB129
--
Linux 4.4.2-dirty: Blurry Fish
On Mon, 22 Feb 2016 16:22:59 -0500 (EST)
Alan Stern wrote:
> Unfortunately I really need to see the stuff that shows up before the
> first couple of pictures. Is there any way you can use a serial
> console or network console to capture the log data?
Unfortunately no :(
> Failing tha
On Mon, 22 Feb 2016 14:30:32 -0500 (EST)
Alan Stern wrote:
> Well, I'm still puzzled. I tried running that patch on my system
> (under 4.5-rc2) and it worked perfectly.
>
> So let's try for a little more detail. Please apply this patch instead
> of the earlier one. Also, add no_console_suspen
On Fri, 19 Feb 2016 14:13:25 -0500 (EST)
Alan Stern wrote:
> -22 is -EINVAL, so we need to figure out which of the many possible
> EINVAL errors you're getting. Try the patch below.
I applied your patch, but when it wakes up from S3, the system
is stalled: nothing works. No keyboard, no
On Thu, 18 Feb 2016 15:23:00 -0500 (EST)
Alan Stern wrote:
> Something like the patch below (untested).
> + dev_info(&intf->dev, "post reset hid_start_in -> %d\n", status);
Ok, so I got the following:
Feb 18 19:22:26 tux kernel: [ 258.693120] usb 3-1.6: reset full-speed USB
devic
On Thu, 18 Feb 2016 14:30:15 -0500 (EST)
Alan Stern wrote:
> It looks like there's some problem in the usbhid driver. Apparently
> hid_start_in() gets some sort of error when it submits the input URB,
> because that URB doesn't show up in the usbmon output.
>
> Can you add a debugging line nea
14 matches
Mail list logo