Comment 237 for bug 88746

@Ben Collins

Ben, I am happy that somebody from Ubuntu is finally reacting to this
Bug report. If not for fixing it than at least with an official
statement what devs are actually thinking about the issue. And why
obvious simple measures are not taken.

Your argumentations surely is not bare any logic. My first reaction
however was, well if suspend/resume is ought to be broken after
removing/disabling the autosuspend feature, why can I still successfully
suspend/resume on my laptop after disabling it. So now I have both, USB
2.0 and suspend/resume. You understand that some doubts did arise in me
about your claim removal of autosuspend might screw up suspend/resume
for many people.

However, these doubts do not have many grounds just yet, except for my
single perception on one type of system. Therefore I presume what you
are claiming are well tested facts.

I am wondering however, if it would not be possible to enable
autosuspend for the one crowd of chipsets while disabling it for the
other. Sure, not an easy task to identify, which systems to enable and
which not.

Extracting all this information from bug reports surly is hell. And yet,
if you have talked everybody into submitting their data "again", you
still will have to ask all of them to test whether or not disabling
autosuspend breaks suspend/resume for them. This is a challenge for
itslef. Undoable if you ask me, at least with the tools available.

I therefore understand, why literally nothing is done about it!

Undoable, well not if Launchpad had the proper toolset for this! I
actually proposed a feature which would enable you to handle a task like
that: The "attach HW profiles to launchpad accounts" I proposed a while
ago. https://bugs.launchpad.net/bugs/3382

I just had a couple of more ideas on how else this feature could be used
with a little more code.

Oh man, somebody needs to implement that! Have a look. I am happy to
share the idea, but I wont code for free on a proprietary project. And
well, the idea was mine, so don't start crying if RedHat or anybody else
is copying it. This idea is a free for all still!

Imagine how much better bug tracking would work if you could start a
simple poll:
Does disabling autosuspend fix your USB2.0 problem ? yes/no
Does disabling autosuspend break your suspend/hibernate/resume? yes/no

If more than one HW profile is registered with your launchpad account
the following question shows up:
Select the systems these answers apply to ? Choose form list.

And at the end you would know not just for how may people disabling
autosuspend works ... but also what chipsets are affected!

Wouldn't that be coding hours wisely spent? Whether you use it for the
ehci_hcd bug or any other HW related bug in the future? I am sure kernel
devs upstream would be happy to whitelist/blacklist autosuspend
accordingly if they were provided a detailed list for whom, wouldn't
they?

I'd be delighted if you would share your thoughts on the feature I
proposed for launchpad as well as on whether or not it could be a viable
solution to whitelist/blacklist autosuspend in kernel if the proper
information would be available for whom.

On Mon, 2008-02-04 at 21:13 +0000, Ben Collins wrote:
> Elias, you are over simplifying this issue. If we disable autosuspend,
> then suspend/resume wont work for a good portion of people. After long
> ago weighing the options, we had to decide on the lesser of two evils:
> suspend/resume working for a large group of users, or usb2.0 working for
> an equally large group of users. Considering that both problems have
> work arounds, the decision was made based on expected behavior. Usually
> a system with usb2.0 ports that were affected by the problem also had
> usb1.0-only ports that did work. So users could continue to use their
> devices without much problem (although at a slower speed).
>
> Also, please don't exaggerate how many people are affected by this. Over
> all, it's a small percentage of people. I have > 15 laptops, covering a
> large range of chipsets, and none of them are affected by either
> problem.
>