On Mon, 2016-03-21 at 11:46 -0400, Alan Stern wrote:
> On Mon, 21 Mar 2016, Oliver Neukum wrote:
>
> > On Fri, 2016-03-18 at 12:36 -0400, Alan Stern wrote:
> >
> > Almost. In case of reset_resume() it makes no sense to still
> > clear a halt or execute a reset that had been ordered. The
> >
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Fri, 2016-03-18 at 12:36 -0400, Alan Stern wrote:
>
> > @@ -1584,10 +1581,8 @@ static int hid_resume(struct usb_interfa
> > static int hid_reset_resume(struct usb_interface *intf)
> > {
> > struct hid_device *hid = usb_get_intfdata(intf);
> >
On Fri, 2016-03-18 at 12:36 -0400, Alan Stern wrote:
> @@ -1584,10 +1581,8 @@ static int hid_resume(struct usb_interfa
> static int hid_reset_resume(struct usb_interface *intf)
> {
> struct hid_device *hid = usb_get_intfdata(intf);
> - struct usbhid_device *usbhid = hid->driver_data;
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?
On Mon, 14 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-14 at 11:03 -0400, Alan Stern wrote:
> > On Mon, 14 Mar 2016, Oliver Neukum wrote:
>
> > > It seems to me that hid_resume_common() needs to be split into three
> > > parts
> > >
> > > a) doing the stuff for pending resets
> > > b)
On Mon, 2016-03-14 at 11:03 -0400, Alan Stern wrote:
> On Mon, 14 Mar 2016, Oliver Neukum wrote:
> > It seems to me that hid_resume_common() needs to be split into three
> > parts
> >
> > a) doing the stuff for pending resets
> > b) conditionally restarting IO
> > c) reset the flag
>
>
On Mon, 14 Mar 2016, Oliver Neukum wrote:
> On Fri, 2016-03-11 at 11:54 -0500, Alan Stern wrote:
>
> > Perhaps I didn't do a good job of addressing the real underlying
> > problem. That's why I asked if this was the right approach.
> >
> > In Daniel's case, usbhid_start() never got called.
On Fri, 2016-03-11 at 11:54 -0500, Alan Stern wrote:
> Perhaps I didn't do a good job of addressing the real underlying
> problem. That's why I asked if this was the right approach.
>
> In Daniel's case, usbhid_start() never got called. Perhaps that's the
> real problem? Anyway, this meant
On Fri, 11 Mar 2016, Jiri Kosina wrote:
> On Wed, 2 Mar 2016, Alan Stern wrote:
>
> [ ... snip ... ]
> > The patch that fixed Daniel's problem is repeated below for your
> > convenience. Is this the right approach? If you think it is, I'll
> > submit it officially.
>
> I've been thinking
On Wed, 2 Mar 2016, Alan Stern wrote:
[ ... snip ... ]
> The patch that fixed Daniel's problem is repeated below for your
> convenience. Is this the right approach? If you think it is, I'll
> submit it officially.
I've been thinking about this, and while I don't really like such bandaids
On Tue, 1 Mar 2016, Daniel Fraga wrote:
> 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
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 ;)
On Tue, 1 Mar 2016, Daniel Fraga wrote:
> 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
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
>
On Tue, 1 Mar 2016, Daniel Fraga wrote:
> 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
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
>
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
>
On Mon, 29 Feb 2016, Daniel Fraga wrote:
> 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,
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 --
On Wed, 24 Feb 2016, Daniel Fraga wrote:
> 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
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
On Tue, 23 Feb 2016, Daniel Fraga wrote:
> 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
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
On Tue, 23 Feb 2016, Daniel Fraga wrote:
> 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
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
--
On Mon, 22 Feb 2016, Daniel Fraga wrote:
> 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
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?
On Mon, 22 Feb 2016, Daniel Fraga wrote:
> 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.
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.
On Fri, 19 Feb 2016, Alan Stern wrote:
> On Fri, 19 Feb 2016, Daniel Fraga wrote:
>
> > 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.
On Fri, 19 Feb 2016, Daniel Fraga wrote:
> 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,
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:
On Thu, 18 Feb 2016, Daniel Fraga wrote:
> On Thu, 18 Feb 2016 15:23:00 -0500 (EST)
> Alan Stern wrote:
>
> > Something like the patch below (untested).
>
> > + dev_info(>dev, "post reset hid_start_in -> %d\n", status);
>
> Ok, so I got the following:
>
>
On Thu, 18 Feb 2016 15:23:00 -0500 (EST)
Alan Stern wrote:
> Something like the patch below (untested).
> + dev_info(>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
On Thu, 18 Feb 2016, Daniel Fraga wrote:
> 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
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
On Thu, 18 Feb 2016, Daniel Fraga wrote:
> On Thu, 18 Feb 2016 11:18:37 -0500 (EST)
> Alan Stern wrote:
>
> > No idea. Can you collect a usbmon trace for bus 3, starting before the
> > suspend and showing the problems?
>
> Ok Alan, I attached the requested
On Tue, 9 Feb 2016, Dâniel Fraga wrote:
> I'm using Linux 4.4.1 kernel on a Dell Inspiron 15R 5537 and
> everytime I wake up from S3 sleep, the syslog is full of the following
> message:
>
> Feb 9 17:19:05 tux kernel: [19196.253206] usb 3-1.6: reset full-speed USB
> device number 6 using
I'm using Linux 4.4.1 kernel on a Dell Inspiron 15R 5537 and
everytime I wake up from S3 sleep, the syslog is full of the following
message:
Feb 9 17:19:05 tux kernel: [19196.253206] usb 3-1.6: reset full-speed USB
device number 6 using ehci-pci
Feb 9 17:19:05 tux kernel:
39 matches
Mail list logo