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 Tue, 29 Apr 2014, Peter Münster wrote:
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
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, 29 Apr 2014, Peter Münster wrote:
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,
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 Sat, 26 Apr 2014, Peter Münster wrote:
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
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 Sun, 20 Apr 2014, Peter Münster wrote:
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
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
On Fri, 18 Apr 2014, Peter Münster wrote:
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.
On Wed, 16 Apr 2014, Peter Münster wrote:
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
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 Thu, 10 Apr 2014, Alan Stern wrote:
On Thu, 10 Apr 2014, Peter Münster wrote:
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
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 Thu, 10 Apr 2014, Peter Münster wrote:
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
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 Mon, 7 Apr 2014, Peter Münster wrote:
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.
This looks a lot like what you got before.
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 Fri, 4 Apr 2014, Peter Münster wrote:
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
On Tue, 1 Apr 2014, Peter Münster wrote:
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
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 Tue, 1 Apr 2014, Peter Münster wrote:
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
On Mon, 31 Mar 2014, Peter Münster wrote:
On Mon, Mar 31 2014, Alan Stern wrote:
That's totally crazy. With wakeup enabled, the commit should have had
no effect at all.
Hi Alan,
With 0aa2832dd0d9d860 kernel, the freeze happens only when something is
connected to the rear port.
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 Mon, 31 Mar 2014, Peter Münster wrote:
One more thing... The bad commit should have no effect on devices
enabled for wakeup -- and keyboards generally _are_ enabled for wakeup.
Can you check this? Under 3.12.x with no patches or reversions,
I've just added your diagnostic patch.
On Thu, 27 Mar 2014, Peter Münster wrote:
Hi Alan,
These are my commands:
echo 8 /proc/sys/kernel/printk
echo on /sys/bus/usb/devices/4-2/power/control
sleep 1
echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue
sleep 1
echo auto /sys/bus/pci/devices/:00:12.1/power/control
sleep
On Wed, 26 Mar 2014, Peter Münster wrote:
On Wed, Mar 26 2014, Alan Stern wrote:
Please try running the test again. When it finishes, go to the
/sys/kernel/debug/usb/ohci/:00:12.1/ directory and post a copy of
the registers file.
Check the contents of that file several times; in
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, 25 Mar 2014, Peter Münster wrote:
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.
Yes.
For this test, plug some
On Tue, 25 Mar 2014, Peter Münster wrote:
On Mon, Mar 24 2014, Alan Stern wrote:
All three files show the system hanging after the resume, even the file
with nothing in the rear ports. Also, the logs are incomplete; it
looks like a bunch of stuff is missing from the start of the
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
On Thu, 20 Mar 2014, Peter Münster wrote:
I'd like to see a comparable log showing what happens when you suspend
with only the mouse plugged in to a rear port, and one with only the
keyboard plugged in to the rear. No serial ports or other stuff.
Please find attached 3 files:
- with
On Wed, 19 Mar 2014, Peter Münster wrote:
On Tue, Mar 18 2014, Alan Stern wrote:
Commit 0aa2832dd0d9d8609fd8f15139bc7572541a1215 introduces a problem for
my system:
You should include the name of the commit along with the hash ID;
otherwise nobody will know what it is unless they
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:
On Tue, 18 Mar 2014, Peter Münster wrote:
Hi,
Commit 0aa2832dd0d9d8609fd8f15139bc7572541a1215 introduces a problem for
my system:
You should include the name of the commit along with the hash ID;
otherwise nobody will know what it is unless they go to the trouble of
looking it up for
40 matches
Mail list logo
