From: Alan Stern <stern@rowland.harvard.edu> To: Ming Lei <ming.lei@canonical.com> Cc: Greg KH <greg@kroah.com>, Santosh <santosh.shilimkar@ti.com>, linux-omap@vger.kernel.org, USB list <linux-usb@vger.kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] usb: ehci: fix update qtd->token in qh_append_tds Date: Sat, 27 Aug 2011 16:06:30 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1108271548110.21403-100000@netrider.rowland.org> (raw) In-Reply-To: <CACVXFVNz_ic_PPM_vNn1Dz85A2z94kRFso4rcqrvJfuLSqRSCg@mail.gmail.com> On Sun, 28 Aug 2011, Ming Lei wrote: > I read the doc again, :-), and it mentions few about mb/wmb/rmb, I think > my above description is still not correct. Generally speaking, mb only > means there is a order between two accesses. > > Now I think only one mb() after 'dummy->hw_token = token;' is enough: > HC will read the up-to-date value of qtd->hw_token after mb() is executed > because of the effect of the mb(), which should be guaranteed by mb. I've been following this whole discussion. I didn't understand the idea behind the original patch, and I don't understand this. What reason is there for adding a memory barrier after the "dummy->hw_token = token" line? Such a barrier would not accomplish anything useful, because there are no later memory accesses which need to be ordered with respect to that line. (By the way, Santosh appears to be right about the earlier wmb() in this routine. As far as I can see, it isn't needed. David Brownell probably wrote it just as a precaution.) > > I mean others, please read the the last 3 lines of the comment and > > compare that to the code lines you added. > > I see now, the comment of the last 3 lines is wrong, should be > > * inside L2 cache. 'token = dummy->hw_token' > * after mb() is added for obeying correct mb() > * usage. > > But the 'token = dummy->hw_token' after mb() isn't needed any > more as described above, is it? I don't see why it was ever needed at all. The compiler will realize that token is a dead variable at that point in the routine and will optimize the new line away. > The patch can make ehci HC see the up-to-date qtd, so make usb transaction > executed correctly. If a qtd->token is not updated, maybe IOC is not set or set very > late, so interrupt can't be triggered in time, also mistaken 'total bytes to transfer' > can make HC work badly. This doesn't make any sense. qtd becomes the new dummy; by the time the HC sees qtd the only important bit set in qtd->hw_token is the HALT bit. > In fact, I have traced the problem and found ehci irq is often delayed by ehci HC. > also sometimes ehci irq is lost, so I start to trace ehci driver and find the problem here. I don't think you have identified the underlying cause correctly. Something else must be responsible. Alan Stern
WARNING: multiple messages have this Message-ID (diff)
From: stern@rowland.harvard.edu (Alan Stern) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] usb: ehci: fix update qtd->token in qh_append_tds Date: Sat, 27 Aug 2011 16:06:30 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1108271548110.21403-100000@netrider.rowland.org> (raw) In-Reply-To: <CACVXFVNz_ic_PPM_vNn1Dz85A2z94kRFso4rcqrvJfuLSqRSCg@mail.gmail.com> On Sun, 28 Aug 2011, Ming Lei wrote: > I read the doc again, :-), and it mentions few about mb/wmb/rmb, I think > my above description is still not correct. Generally speaking, mb only > means there is a order between two accesses. > > Now I think only one mb() after 'dummy->hw_token = token;' is enough: > HC will read the up-to-date value of qtd->hw_token after mb() is executed > because of the effect of the mb(), which should be guaranteed by mb. I've been following this whole discussion. I didn't understand the idea behind the original patch, and I don't understand this. What reason is there for adding a memory barrier after the "dummy->hw_token = token" line? Such a barrier would not accomplish anything useful, because there are no later memory accesses which need to be ordered with respect to that line. (By the way, Santosh appears to be right about the earlier wmb() in this routine. As far as I can see, it isn't needed. David Brownell probably wrote it just as a precaution.) > > I mean others, please read the the last 3 lines of the comment and > > compare that to the code lines you added. > > I see now, the comment of the last 3 lines is wrong, should be > > * inside L2 cache. 'token = dummy->hw_token' > * after mb() is added for obeying correct mb() > * usage. > > But the 'token = dummy->hw_token' after mb() isn't needed any > more as described above, is it? I don't see why it was ever needed at all. The compiler will realize that token is a dead variable at that point in the routine and will optimize the new line away. > The patch can make ehci HC see the up-to-date qtd, so make usb transaction > executed correctly. If a qtd->token is not updated, maybe IOC is not set or set very > late, so interrupt can't be triggered in time, also mistaken 'total bytes to transfer' > can make HC work badly. This doesn't make any sense. qtd becomes the new dummy; by the time the HC sees qtd the only important bit set in qtd->hw_token is the HALT bit. > In fact, I have traced the problem and found ehci irq is often delayed by ehci HC. > also sometimes ehci irq is lost, so I start to trace ehci driver and find the problem here. I don't think you have identified the underlying cause correctly. Something else must be responsible. Alan Stern
next prev parent reply other threads:[~2011-08-27 20:06 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-08-27 14:48 [PATCH] usb: ehci: fix update qtd->token in qh_append_tds ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw 2011-08-27 14:48 ` ming.lei at canonical.com 2011-08-27 15:03 ` Santosh 2011-08-27 15:03 ` Santosh [not found] ` <4E590756.9030307-l0cyMroinI0@public.gmane.org> 2011-08-27 15:18 ` Ming Lei 2011-08-27 15:18 ` Ming Lei [not found] ` <CACVXFVPPPUsntdCT=m=vRJ9XVksn6rGMzqJVvdD+sj=eOcTadg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-08-27 15:46 ` Santosh 2011-08-27 15:46 ` Santosh [not found] ` <1314456515-16419-1-git-send-email-ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> 2011-08-27 15:13 ` Greg KH 2011-08-27 15:13 ` Greg KH 2011-08-27 15:33 ` Ming Lei 2011-08-27 15:33 ` Ming Lei 2011-08-27 16:07 ` Greg KH 2011-08-27 16:07 ` Greg KH 2011-08-27 16:57 ` Ming Lei 2011-08-27 16:57 ` Ming Lei [not found] ` <CACVXFVNz_ic_PPM_vNn1Dz85A2z94kRFso4rcqrvJfuLSqRSCg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-08-27 17:20 ` Ming Lei 2011-08-27 17:20 ` Ming Lei 2011-08-27 20:11 ` Alan Stern 2011-08-27 20:11 ` Alan Stern 2011-08-28 3:35 ` Ming Lei 2011-08-28 3:35 ` Ming Lei 2011-08-27 20:06 ` Alan Stern [this message] 2011-08-27 20:06 ` Alan Stern 2011-08-28 3:13 ` Ming Lei 2011-08-28 3:13 ` Ming Lei [not found] ` <CACVXFVP8Lr=ggH4FjvMQd6r9poLAT1r+_S3Z-NimP0i08DsQ8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-08-28 17:00 ` Alan Stern 2011-08-28 17:00 ` Alan Stern 2011-08-28 23:36 ` Russell King - ARM Linux 2011-08-28 23:36 ` Russell King - ARM Linux 2011-08-29 1:51 ` Alan Stern 2011-08-29 1:51 ` Alan Stern 2011-08-29 8:52 ` Russell King - ARM Linux 2011-08-29 8:52 ` Russell King - ARM Linux 2011-08-29 13:57 ` Alan Stern 2011-08-29 13:57 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1108290951250.2525-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2011-08-29 15:55 ` Ming Lei 2011-08-29 15:55 ` Ming Lei 2011-08-29 16:24 ` Mark Salter 2011-08-29 16:24 ` Mark Salter [not found] ` <Pine.LNX.4.44L0.1108281233270.3742-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org> 2011-08-29 14:25 ` Ming Lei 2011-08-29 14:25 ` Ming Lei [not found] ` <CACVXFVOvw6bSfcOYR2RWJO=k1WLgSCUygmSwZmtRDdM_tZNWEA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-08-29 15:03 ` Alan Stern 2011-08-29 15:03 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1108291046540.2525-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2011-08-29 15:21 ` Ming Lei 2011-08-29 15:21 ` Ming Lei 2011-08-29 16:33 ` Alan Stern 2011-08-29 16:33 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1108291218040.2525-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2011-08-30 14:02 ` Ming Lei 2011-08-30 14:02 ` Ming Lei 2011-08-27 16:31 ` Sergei Shtylyov 2011-08-27 16:31 ` Sergei Shtylyov -- strict thread matches above, loose matches on Subject: below -- 2011-08-27 14:46 ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.4.44L0.1108271548110.21403-100000@netrider.rowland.org \ --to=stern@rowland.harvard.edu \ --cc=greg@kroah.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=ming.lei@canonical.com \ --cc=santosh.shilimkar@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.