@Elias: I don't mean to sound rude, but it feels for me that you have no
problem complaining about what others should and should not do, but then you
are yourself not ready to do much about it. Well, you might say that Ubuntu
is a proprietary project, because there is a corporation behind it, but all
code it produces are completely free and open-source. Many developers work
totatally for free on Ubuntu.

I suggest that instead of telling others what to do, you just go ahead and
do it yourself. I understand that you may not have the time for that, but
maybe you would then understand that other people (the paid developers) also
has a lot of other work to do, and maybe does not have time for your
favorite issue?

And regarding bug 3382: Yes, I agree with you, it sounds like a good idea,
great thinking from you Elias. But, please, I ask you, could you stop
posting about it here in this bug? I at least would be happy if you
wouldn't. You have already posted about it many times here,  you don't need
to post it again. I think the message has gone through clear to everyone
here.

Also, if you would to like to support the developers in some way to do a
better job, you would be much better of giving words of encouragement,
instead of words of complain. I am totally sure that you criticising them
won't give them any more energy (and definitely not any more time) to work
on development.

This is meant as a friendly advice, I hope you don't feel dismayed or
something.

I also want take the opportunity to thank the developers for all the hard
work they are doing, from which I can benefit completely for free.


2008/2/9, Elias Humbolt <email address hidden>:
>
> @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.
> >
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.
>