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, 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 glob
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 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 d
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 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 ab
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 Tue, 22 Apr 2014, Peter Münster wrote:
> 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 ve
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 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 mou
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 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
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
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 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 informati
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:
> >
> > e583d9db9960cf40e0bc8afee
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 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 e583d9db9960cf40e
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 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 befor
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 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...
> >
>
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, 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 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
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 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
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 p
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, 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/co
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 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 seve
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
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 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 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:
> -
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
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 t
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
42 matches
Mail list logo
