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
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 screen
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 is
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. It's
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 consistent,
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.
Yes, you're right!
Sorry, I've forgotten the logs
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
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 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 st...@rowland.harvard.edu
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.
If
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 info
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:
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:
[ 4694.420213] PM:
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 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's
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
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:
19 matches
Mail list logo
