All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Dibowitz <phil@ipom.com>
To: Greg KH <gregkh@suse.de>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Jiri Slaby <jslaby@suse.cz>,
	stable@kernel.org, USB list <linux-usb@vger.kernel.org>,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [34-stable regression] USB delay init quirk causes device events loss
Date: Mon, 13 Sep 2010 18:02:28 +0200	[thread overview]
Message-ID: <4C8E4B14.7090904@ipom.com> (raw)
In-Reply-To: <20100913155608.GA27853@suse.de>

[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]

On 09/13/2010 05:56 PM, Greg KH wrote:
> On Mon, Sep 13, 2010 at 11:37:49AM -0400, Alan Stern wrote:
>> On Mon, 13 Sep 2010, Jiri Slaby wrote:
>>
>>> On 09/13/2010 04:48 PM, Alan Stern wrote:
>>>> On Mon, 13 Sep 2010, Jiri Slaby wrote:
>>>>> In other words, what I could do is to add some printks into
>>>>> hub_port_connect_change if that's called at all. If you need some
>>>>> thorough debugging printks, please send me a patch to test instead.
>>>>
>>>> Hmm.  I'd prefer to explain how it's all supposed to work and let you
>>>> figure out where best to look.  Or try to debug it myself.  Does this
>>>> happen with other sorts of USB devices as well, or just wacom?
>>>
>>> With some sort of devices (I cannot reproduce myself). It's unrelated to
>>> wacom -- people with wacom were unable to even start X with this kernel.
>>> If you look at the bugreport, there are several examples:
>>> ID 046d:c517 Logitech, Inc. LX710 Cordless Desktop Laser defunct
>>> Microsoft USB keyboard defunct x Logitech mice OK
>>> 046a:0021 Cherry GmbH keyboard defunct
>>> logitech wireless laptop mouse defunct
>>> A$Tech wireless laptop mouse defunct
>>> TypeMatrix USB 2030 (ID : 1e54:2030) defunct
>>
>> Okay, I see the problem.  By moving usb_detect_quirks earlier, we end 
>> up calling usb_disable_autosuspend too soon -- before the 
>> pm_runtime_enable call in usb_new_device.  In 2.6.35 this doesn't 
>> matter because the implementation of usb_autosuspend_device has 
>> changed.
>>
>> So yes, in the end it looks like the best course is to revert this
>> patch from 2.6.34.stable.  This is unfortunate but I don't see any way
>> around it without making changes that aren't present in the current
>> kernel. For example, the pm_runtime_set_active and pm_runtime_enable
>> calls could also be moved from usb_new_device into
>> hub_port_connect_change.
> 
> Ok, I'll go revert that from the .34-stable tree and do a new release,
> as it's not nice to have a broken tree out there.

Sorry to chime in late on the conversation on my patch.

Thanks for figuring this out Alan. I think this is reasonable. However, I
think this also went into .32-stable and should probably be reverted there
as well.

I'll advise my users to make sure they have at least .35.

-- 
Phil Dibowitz                             phil@ipom.com
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
 and those who matter don't mind."
 - Dr. Seuss



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2010-09-13 16:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-13 11:18 [34-stable regression] USB delay init quirk causes device events loss Jiri Slaby
2010-09-13 14:16 ` Alan Stern
2010-09-13 14:23   ` Jiri Slaby
2010-09-13 14:48     ` Alan Stern
2010-09-13 14:59       ` Jiri Slaby
2010-09-13 15:37         ` Alan Stern
2010-09-13 15:56           ` Greg KH
2010-09-13 16:02             ` Phil Dibowitz [this message]
2010-09-13 16:24               ` Alan Stern
2010-09-13 17:03                 ` Jiri Slaby
2010-09-13 17:06                   ` Greg KH
2010-09-14 12:03           ` Oliver Neukum
2010-09-14 14:03             ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C8E4B14.7090904@ipom.com \
    --to=phil@ipom.com \
    --cc=gregkh@suse.de \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.