From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Mosberger Date: Sat, 06 Mar 2004 08:39:26 +0000 Subject: Re: [linux-usb-devel] Re: serious 2.6 bug in USB subsystem? Message-Id: <16457.36414.613402.726173@napali.hpl.hp.com> List-Id: References: <200310272235.h9RMZ9x1000602@napali.hpl.hp.com> <20031028013013.GA3991@kroah.com> <200310280300.h9S30Hkw003073@napali.hpl.hp.com> <3FA12A2E.4090308@pacbell.net> <16289.29015.81760.774530@napali.hpl.hp.com> <16289.55171.278494.17172@napali.hpl.hp.com> <3FA28C9A.5010608@pacbell.net> <16457.12968.365287.561596@napali.hpl.hp.com> <404959A5.6040809@pacbell.net> <16457.26208.980359.82768@napali.hpl.hp.com> <16457.31740.99944.563029@napali.hpl.hp.com> In-Reply-To: <16457.31740.99944.563029@napali.hpl.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: davidm@hpl.hp.com Cc: David Brownell , Greg KH , vojtech@suse.cz, linux-usb-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, pochini@shiny.it >>>>> On Fri, 5 Mar 2004 23:21:32 -0800, David Mosberger said: David> (1) Start of Frame -> (2) update HccaFrameNumber -> (3) David> trigger SF interrupt David> Now, suppose you get a WDH interrupt between (1) and (2). David> You'd read the old frame-number yet by the time the interrupt David> from (3) arrives the HC might already be accessing the ED David> that you're about to remove. Sorry for the monologue---trying to learn how this is all supposed to work... The OHCI spec says that HccaFrameNumber is updated in this fashion: (a) send Start-of-Frame (b) HccaFrameNumber <- HcFmNumber.StartingFrame (c) start processing ED (& post SF intr if requested) Since start_ed_unlink() uses the following sequence: (1) ed->hwINFO |= ED_DEQUEUE (2) ed->tick = OHCI_FRAME_NO(ohci->hcca) + 1 Then as long as (1) is observed by the HC before (2) (which it should be), the race I described isn't possible: if (2) read the "old" frame-number, then the HC wouldn't have started step (c) yet and hence the HC would observe step (1) and notice that the ED is being dequeued. Converseley, if the HC started to process the ED before (1) completed (i.e., it missed the ED_DEQUEUE flag), then step (2) must have been reading the the new frame-number. OK, I see now the conundrum... BTW: does the value 0xf0000000 bear any special meaning in USB? We already considered whether this would be a NULL-pointer after I/O MMU translation but it is not: the I/O MMU window is at 0x40000000-0x80000000 on the machines in question. --david