Messages in this thread | | | From | David Mosberger <> | Date | Sat, 6 Mar 2004 00:39:26 -0800 | Subject | Re: [linux-usb-devel] Re: serious 2.6 bug in USB subsystem? |
| |
>>>>> On Fri, 5 Mar 2004 23:21:32 -0800, David Mosberger <davidm@linux.hpl.hp.com> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |