On Wed, Apr 30 2014, Alan Stern wrote:
> Okay, good. Below is a patch which I hope will fix your problem. You
> can leave diag1 in place if you want, but remove all the other patches.
Hi Alan,
Yes, it works very well with latest git-kernel (3.15-rc3).
Thanks,
--
Peter
--
To unsub
On Tue, Apr 29 2014, Alan Stern wrote:
> It's noticeable that your logs include resets of the affected devices,
> whereas the older kernels did not need any resets. This suggests that
> these OHCI controllers will always have problems with global suspend,
> and therefore a controller-specific fix
On Mon, Apr 28 2014, Alan Stern wrote:
> That's interesting. Here's another test you should try with that same
> kernel. Start moving the mouse before you wake up the system, and keep
> moving it until the system has fully resumed. When you do this, does
> it work right? That is, when the scre
On Tue, Apr 22 2014, Alan Stern wrote:
> Here's diag5; it's essentially a subset of diag4. Test it in the same
> way.
>
> (Not being able to wake up the system from the keyboard is expected
> for diag4. With diag5, you may or may not be able to use the keyboard
> for wakeup -- try it and see. I
On Mon, Apr 21 2014, Alan Stern wrote:
> Here's a new diagnostic patch (diag4) to try, on the same kernel, along
> with diag1 and nothing else. This patch does almost the same thing as
> turning off CONFIG_USB_SUSPEND used to do in earlier versions of the
> kernel. If the behavior is consiste
On Fri, Apr 18 2014, Alan Stern wrote:
> Below is a first simple attempt, let's call it fix1. This should be
> applied to the kernel you have been using, with diag1 but without any
> of the diag3* patches. What happens with fix1 and with the mouse
> plugged into the rear?
Hi Alan,
It does not wo
On Thu, Apr 17 2014, Peter Münster wrote:
> On Thu, Apr 17 2014, Alan Stern wrote:
>
>> Just to verify, please try replacing diag3 with each of the two patches
>> below (one at a time). If my guess is right, diag3a will work and
>> diag3b will fail.
>
> Y
On Thu, Apr 17 2014, Alan Stern wrote:
> Just to verify, please try replacing diag3 with each of the two patches
> below (one at a time). If my guess is right, diag3a will work and
> diag3b will fail.
Yes, you're right!
--
Peter
--
To unsubscribe from this list: send the line "uns
On Mon, Apr 14 2014, Alan Stern wrote:
> How many diagnostic patches have you tried so far? I've lost track.
Hi Alan,
diag1: the one with the alan-timer
diag2: reverts commit 0aa2832dd0d9d860 and instead, prints
out information showing what the commit would do
diag3: partially reverts
On Thu, Apr 10 2014, Alan Stern wrote:
> I should have guessed... :-(
Next time, we can try some guesses before bisecting, right?
--
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
On Wed, Apr 02 2014, Alan Stern wrote:
> Below is 0aa2832dd0d9d860 back-ported to 3.9. Please try testing a 3.9
> kernel with this patch installed (and also the first diagnostic patch,
> if it applies with no errors), with CONFIG_USB_SUSPEND _enabled_ and
> the mouse plugged into the rear port.
>
On Tue, Apr 01 2014, Alan Stern wrote:
>> Should I do another git-bisect?
>
> Yes, that would be a good idea.
Hi Alan,
Here is the result:
e583d9db9960cf40e0bc8afee4946baa9d71596e is the first bad commit
commit e583d9db9960cf40e0bc8afee4946baa9d71596e
Author: Alan Stern
Date: Thu Jul 11 14:5
On Fri, Apr 04 2014, Alan Stern wrote:
> No error messages about hung-up tasks 120 seconds later?
Sorry. I had forgotten to wait 2 minutes...
Here again the log with information about hung-up tasks.
--
Peter
[ 97.307415] PM: Syncing filesystems ... done.
[ 97.412888] PM: Prepari
On Tue, Apr 01 2014, Alan Stern wrote:
>> > Also, I'd like to track down the problem when both devices are plugged
>> > into front ports. Can you try that as well, again without the new
>> > diagnostic patch?
>>
>> The system hangs...
>
> Do you have a netconsole log?
Hi Alan,
Yes, here:
[ 46
On Tue, Apr 01 2014, Alan Stern wrote:
> Also, I'd like to track down the problem when both devices are plugged
> into front ports. Can you try that as well, again without the new
> diagnostic patch? If the problem in this case is caused by a separate
> bug then we may not learn anything, but it
On Tue, Apr 01 2014, Alan Stern wrote:
> These all seem to be basically the same, apart from the Nouveau issue.
> This suggests that the previous test (i.e., without the new diagnostic
> patch) would have worked if _nothing_ was plugged into a front port and
> the keyboard was plugged into the
On Fri, Mar 28 2014, Alan Stern wrote:
> This just raises more questions. It looks like it worked almost okay,
> but not quite. Certainly it didn't hang, so it isn't an exact
> reproduction of the problem. Can you run the same test again, and then
> at the end, do:
>
> echo 1 >/sys/bus/us
On Thu, Mar 27 2014, Alan Stern wrote:
> Oops -- I just realized that the instructions I sent you before were
> incomplete. Please try running the same test again, but this time
> issue the following commands to suspend the device:
>
> echo on >/sys/bus/usb/devices/4-2/power/control
>
On Tue, Mar 25 2014, Alan Stern wrote:
> Below is a patch you should apply to normal 3.14 (nothing reverted).
Hi Alan,
I've used 3.12.14, because the source-tree is already set up. I hope
that this is ok.
> For this test, plug some device you aren't going to use (the mouse, for
> example, if
Hi,
Commit 0aa2832dd0d9d8609fd8f15139bc7572541a1215 introduces a problem for
my system:
When it wakes up after s2ram, it freezes. Screen is black, keyboard
does not work, no ssh-connection. Just the network-ping works.
Please see here for more details, especially information about the
hardware: h
20 matches
Mail list logo
