From: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> To: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> Cc: Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>, Santosh <santosh.shilimkar-l0cyMroinI0@public.gmane.org>, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, USB list <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Subject: Re: [PATCH] usb: ehci: fix update qtd->token in qh_append_tds Date: Mon, 29 Aug 2011 11:03:06 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1108291046540.2525-100000@iolanthe.rowland.org> (raw) In-Reply-To: <CACVXFVOvw6bSfcOYR2RWJO=k1WLgSCUygmSwZmtRDdM_tZNWEA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Mon, 29 Aug 2011, Ming Lei wrote: > IMO, the dummy has been linked into queue pointed by qh->hw->hw_qtd_next, > so EHCI will fetch dummy qtd and execute the transaction and will not have > any delay on the transaction. > > Let me explain the problem again: On ARM, the wmb() before > 'dummy->hw_token = token;' > will flush l2 write buffer into memory and all parts of 'dummy' except > for hw_token field > have reached into memory already, but dummy->hw_token will stay at l2 > write buffer > and not reach into memory at this time, so ehci may fetch a > inconsistent qtd and execute it, > then mistaken IOC or "total bytes to transfer" are read by EHCI and > cause delayed irq > or lost irq. No. Even if the HC reads dummy before dummy->hw_token has been written out to memory from the L2 cache, it will not see any inconsistencies. It will see the old value in hw_token, which has the ACTIVE bit clear. Therefore it will not try to execute the qTD but will move on to the next QH. See what the fourth paragraph in section 4.10.2 of the EHCI spec says about the case where a qTD's ACTIVE bit is set to 0. Some EHCI implementations have a quirk, in which they perform the overlay even when ACTIVE is clear. But even these implementations won't try to execute the qTD, because the old value of dummy->hw_token also has the HALT bit set. > It is not only a reasoning or guess, and I have traced this kind of > fact certainly. If your controller behaves as you suggest then it is buggy. And in that case, adding another memory barrier won't fix it. There is still the possibility that the HC will read dummy during the brief time after the existing wmb() and before the CPU has written dummy->hw_token. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: Mon, 29 Aug 2011 11:03:06 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1108291046540.2525-100000@iolanthe.rowland.org> (raw) In-Reply-To: <CACVXFVOvw6bSfcOYR2RWJO=k1WLgSCUygmSwZmtRDdM_tZNWEA@mail.gmail.com> On Mon, 29 Aug 2011, Ming Lei wrote: > IMO, the dummy has been linked into queue pointed by qh->hw->hw_qtd_next, > so EHCI will fetch dummy qtd and execute the transaction and will not have > any delay on the transaction. > > Let me explain the problem again: On ARM, the wmb() before > 'dummy->hw_token = token;' > will flush l2 write buffer into memory and all parts of 'dummy' except > for hw_token field > have reached into memory already, but dummy->hw_token will stay at l2 > write buffer > and not reach into memory at this time, so ehci may fetch a > inconsistent qtd and execute it, > then mistaken IOC or "total bytes to transfer" are read by EHCI and > cause delayed irq > or lost irq. No. Even if the HC reads dummy before dummy->hw_token has been written out to memory from the L2 cache, it will not see any inconsistencies. It will see the old value in hw_token, which has the ACTIVE bit clear. Therefore it will not try to execute the qTD but will move on to the next QH. See what the fourth paragraph in section 4.10.2 of the EHCI spec says about the case where a qTD's ACTIVE bit is set to 0. Some EHCI implementations have a quirk, in which they perform the overlay even when ACTIVE is clear. But even these implementations won't try to execute the qTD, because the old value of dummy->hw_token also has the HALT bit set. > It is not only a reasoning or guess, and I have traced this kind of > fact certainly. If your controller behaves as you suggest then it is buggy. And in that case, adding another memory barrier won't fix it. There is still the possibility that the HC will read dummy during the brief time after the existing wmb() and before the CPU has written dummy->hw_token. Alan Stern
next prev parent reply other threads:[~2011-08-29 15:03 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 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 [this message] 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.1108291046540.2525-100000@iolanthe.rowland.org \ --to=stern-nwvwt67g6+6dfdvte/nmlpvzexx5g7lz@public.gmane.org \ --cc=greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \ --cc=santosh.shilimkar-l0cyMroinI0@public.gmane.org \ /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.