Messages in this thread Patch in this message | | | From | David Mosberger <> | Date | Sat, 6 Mar 2004 01:17:53 -0800 | Subject | Re: [linux-usb-devel] Re: serious 2.6 bug in USB subsystem? |
| |
>>>>> On Fri, 05 Mar 2004 20:55:01 -0800, David Brownell <david-b@pacbell.net> said:
>> Does this sound plausible?
David.B> Parts of it. There's definite recent nastiness. Of the David.B> type that other eyes sometimes see better.
Here is patch #3. It also Works For Me. I was wondering whether it it is really safe to mess with the OHCI control registers the way ed_deschedule() does at a time the OHCI is running. To test this theory, I delayed the ed_deschedule() handling to finish_unlinks(), as shown in the patch below. I don't know whether this is really safe as far as the host's lists are concerned, but it does avoid the crashes.
What's the argument as to why it's safe to update the OHCI control registers in ed_deschedule() at the time start_ed_unlink() is running?
--david
===== drivers/usb/host/ohci-q.c 1.48 vs edited ===== --- 1.48/drivers/usb/host/ohci-q.c Tue Mar 2 05:52:46 2004 +++ edited/drivers/usb/host/ohci-q.c Sat Mar 6 01:09:16 2004 @@ -274,7 +274,10 @@ */ static void ed_deschedule (struct ohci_hcd *ohci, struct ed *ed) { +#if 0 ed->hwINFO |= ED_SKIP; + wmb(); +#endif switch (ed->type) { case PIPE_CONTROL: @@ -431,7 +434,12 @@ { ed->hwINFO |= ED_DEQUEUE; ed->state = ED_UNLINK; +#if 0 ed_deschedule (ohci, ed); +#else + ed->hwINFO |= ED_SKIP; + wmb(); +#endif /* SF interrupt might get delayed; record the frame counter value that * indicates when the HC isn't looking at it, so concurrent unlinks @@ -896,6 +904,11 @@ last = &ed->ed_next; continue; } + +#if 0 +#else + ed_deschedule (ohci, ed); +#endif if (!list_empty (&ed->td_list)) { struct td *td; - 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/
| |