list_add the same timer
corrupted the list.
We can avoid this problem when resuming from hibernate by first deleting
the timer and then initializing it and adding it to the timer list.
Signed-off-by: Tony Camuso
Acked-by: Don Zickus
---
drivers/usb/host/xhci.c |9 -
1 files changed, 8
returning from hibernate,
the timer was still active, and the attempt to list_add the same timer
corrupted the list.
We can avoid this problem when resuming from hibernate by first deleting
the timer and then initializing it and adding it to the timer list.
Signed-off-by: Tony Camuso
Acked-by: Don
Sergei,
Thank you for your response.
On 02/16/2013 11:32 AM, Sergei Shtylyov wrote:
Commit 71c731a
Please also specify that commit's summary in parens (or however you like).
Yes, I will re-submit with an excerpt of the summary. It's rather long, so I
will just take the first paragraph,
statements of the
original commit.
Signed-off-by: Tony Camuso
Acked-by: Don Zickus
---
drivers/usb/host/xhci.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index f1f01a8..267a7b1 100644
--- a/drivers/usb/host
uot;
On 02/18/2013 12:52 PM, Tony Camuso wrote:
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP controller,
but it introduced a bug where resume from hibernate would add the
comp_mode_recovery_timer to the time
, except after a function name where all words
start with lower case, in keeping with the style prevalent elsewhere
in xhci.c.
Signed-off-by: Tony Camuso
---
drivers/usb/host/xhci.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb
Sarah,
This patch is pursuant to the patch at ...
http://www.mail-archive.com/linux-usb@vger.kernel.org/msg14965.html,
Message ID <1361209953-5195-1-git-send-email-tcam...@redhat.com>
... and must be applied after that patch is applied.
Can these patches be included in the next merge?
Thanks,
T
On 02/19/2013 04:48 PM, Sarah Sharp wrote:
Hi Tony,
Greg closed the usb-next tree for 3.9 two weeks ago. The bug fix
patches will have to go in after the 3.9 merge window closes
(approximately two weeks from now).
Understood.
Sorry for the lack of response, I was on vacation. I'll review y
On 02/20/2013 10:15 AM, Alan Stern wrote:
On Tue, 19 Feb 2013, Sarah Sharp wrote:
The one thing I wanted to check was my understanding of the hibernate
flow path. As you mentioned, I thought that xhci_suspend would be
called in the hibernate path, but it's not.
Are you sure about that? AFAI
On 02/20/2013 12:35 PM, Alan Stern wrote:
I bet it really was called, but you didn't realize it because of the
way you monitored the output from the printks. You looked at the
log buffer or the kernel log file after resuming, right? You didn't
have a serial console attached to another machine,
On 02/21/2013 10:46 AM, Alan Stern wrote:
On Wed, 20 Feb 2013, Sarah Sharp wrote:
Of course, in your case this doesn't matter. In the memory image, the
timer is active. Hence it is still active when the system resumes,
even though xhci_suspend _was_ called.
Ah, I see now. So basically any
the
call to create a new instance of this timer, whether returning from
suspend or hibernate.
Thanks to Alan Stern for his help with understanding the problem.
Signed-off-by: Tony Camuso
Acked-by: Don Zickus
---
drivers/usb/host/xhci.c |9 -
1 files changed, 8 insertions(+), 1
change I may want to make to clarify where the timer is
being deleted, suspend or resume, but I will submit that patch in the
thread I started for that purpose.
Regards,
Tony
On 02/21/2013 04:11 PM, Tony Camuso wrote:
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware
On 02/21/2013 05:04 PM, Alan Stern wrote:
Would it be simpler to delete the timer in xhci_bus_suspend() and
restart it in xhci_bus_resume()? Then you wouldn't need to care
about the difference between suspend and hibernation.
Alan,
I tried implementing this. There were some static functions
ended.
Then should I continue to pursue relocating calls to init and delete
the compliance mode recovery timer to xhci_bus_suspend/resume?
On Mon, 25 Feb 2013, Tony Camuso wrote:
Furthermore, xhci_bus_suspend is called before xhci_bus_resume, so
an attempt is made to delete the compliance
On 02/26/2013 11:11 AM, Alan Stern wrote:
On Tue, 26 Feb 2013, Tony Camuso wrote:
Then should I continue to pursue relocating calls to init and delete
the compliance mode recovery timer to xhci_bus_suspend/resume?
I don't know. If you think the scheme will work then pursue it,
othe
On 02/27/2013 07:20 PM, Sarah Sharp wrote:
I would like be conservative here, and keep as much of the current code
we have (with the compliance timer being manipulated in xhci_suspend and
xhci_resume). That was the code that was submitted by TI, and we should
stick as close to it as possible, wi
On 02/27/2013 07:20 PM, Sarah Sharp wrote:
Basically, I'd like Tony to make his first patch work, rather than
pursuing moving the timer manipulation to xhci_bus_suspend/resume.
Not to add confusion, but here is a less intrusive patch that simply
checks to see if the Compliance Mode Recovery T
On 03/14/2013 05:42 PM, Alexis R. Cortes wrote:
Hi Sarah,
On 3/11/2013 5:20 PM, Sarah Sharp wrote:
On Mon, Mar 11, 2013 at 05:33:26PM +, Cortes, Alexis wrote:
Hi Sarah,
Sorry for my delayed response, I was investigating this. By 'Inactive' state
you mean the Compliance mode? since SS.Ina
On 03/22/2013 02:33 PM, Cortes, Alexis wrote:
Hi Tony,
Well, considering the circumstances, the only issue I see here is that the
system won't be able to wake on a device connect if the port to which the
device was connected enters in compliance mode (I might add that compliance
mode is not a
:
Hi Tony,
Just a note that I'm queuing this patch to Greg for 3.10. I'm working
on a bug fix patch for 3.9 that includes turning off runtime PM, and
should fix the issue with the compliance timer causing list corruption
on resume.
Sarah Sharp
On Tue, Feb 19, 2013 at 08:59:35AM -050
, except after a function name where all words
start with lower case, in keeping with the style prevalent elsewhere
in xhci.c.
Signed-off-by: Tony Camuso
---
drivers/usb/host/xhci.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers
On 04/17/2013 08:27 PM, Sarah Sharp wrote:
[Sarah reworked this patch to cover the case where the xHCI restore
register operation fails, and (temp & STS_SRE) is true (and we re-init
the host, including re-init for the compliance mode), but hibernate is
false. The original patch would have cause
On 04/18/2013 05:12 PM, Sarah Sharp wrote:
On Thu, Apr 18, 2013 at 02:45:40PM -0400, Tony Camuso wrote:
Sarah,
This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7.
I can attach the S3_Suspend_message.log, if you like, but here are the
last few lines.
Is it hanging on suspend or on
On 04/18/2013 05:12 PM, Sarah Sharp wrote:
On Thu, Apr 18, 2013 at 02:45:40PM -0400, Tony Camuso wrote:
Sarah,
This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7.
= snip =
Is it hanging on suspend or on resume?
3.9.0-rc8 hangs in both suspend and resume on a hp z620 running
On 04/23/2013 05:14 PM, Sarah Sharp wrote:
On Tue, Apr 23, 2013 at 04:18:00PM -0400, Tony Camuso wrote:
It hangs in both suspend and resume with vanilla 3.9-rc7 and rc8.
Neither the new patch nor the old patch helps.
It might be unrelated to USB then. Let's see what the bisect shows.
On Tue, Apr 23, 2013 at 04:18:00PM -0400, Tony Camuso wrote:
It hangs in both suspend and resume with vanilla 3.9-rc7 and rc8.
That should say, "It hangs in resume-from-suspend...".
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of
On 04/26/2013 12:47 PM, Dave Jiang wrote:
I have a feeling it's something else and the patch maybe have exposed
it. A channel error occured and bit 12 is Completion Address Error.
IOATDMA driver has no suspend/resume support. So what happens to the
driver when a suspend and then resume happens? I
On 04/26/2013 01:46 PM, Dave Jiang wrote:
On 04/26/2013 10:39 AM, Tony Camuso wrote:
Platform is HP Z820 with Two 8-core Intel(R) Xeon(R) CPU E5-2660 0
@ 2.20GHz and HT enabled.
Output of lspci and lsmod available at these links.
http://people.redhat.com/tcamuso/xhci-logs/lspci.txt
http
On 04/26/2013 01:53 PM, Dave Jiang wrote:
No I mean are you transitioning to S3 (standby, sleep, or suspend to
RAM) state via suspend and then resumed?
Sorry, I misunderstood the question.
The Call Trace occurs near the end of resuming from S3 after executing
the following command.
On 04/26/2013 02:12 PM, Dave Jiang wrote:
On 04/26/2013 11:09 AM, Dave Jiang wrote:
A different question. Is the system utilizing IOATDMA at all at the
point of suspend/resume? Any RAID5/6 volumes? Or NET_DMA is on?
Dave,
I just booted with ioatdma blacklisted in /etc/modprobe.d/blacklis
atch would have caused list corruption in this
case.]
Signed-off-by: Tony Camuso
Acked-by: Don Zickus
Signed-off-by: Sarah Sharp
---
Tony, will you test this version? Thanks!
Sarah,
With ioatdma blacklisted, I was able to test this patch on an hp z820,
which is the system family on which
On 05/09/2013 07:31 PM, Sarah Sharp wrote:
> Hi Tony, Don, and Oliver,
>
> Can one of you double check these two patches resolve the resume from S3
> issue on effected HP systems with the TI compliance mode quirk?
>
> Oliver has confirmed that the first patch works, but no one has tested
> the pa
On 05/09/2013 07:31 PM, Sarah Sharp wrote:
> Hi Tony, Don, and Oliver,
>
> Can one of you double check these two patches resolve the resume from S3
> issue on effected HP systems with the TI compliance mode quirk?
>
> Oliver has confirmed that the first patch works, but no one has tested
> the p
Sarah,
These patches allow return-from-hibernate to work with the
latest upstream tree at
commit 8f710dd34a46500e135203816c71c3ec567c46fd
However, while the restore from hibernate worked, patch 2/2
introduced the following call trace. With just 1/2 applied,
the trace does not appear.
firewir
>
--- snip ---
>
> Sarah Sharp (1):
> xhci: Disable D3cold for buggy TI redrivers.
>
> Tony Camuso (1):
> xhci - correct comp_mode_recovery_timer on return from hibernate
>
> drivers/usb/host/xhci-pci.c |8
> drivers/usb/host/xhci.c | 16 +
36 matches
Mail list logo
