Possible OHCI driver bug ?

["Anantha Subramanyam" <ananth@xxxxxxxxxxxx>]

We think we may have hit a very corner case bug in the ohci_hcd driver
that results in a USB request timing out. This shows up when :
1. 'tick' counter value in an endpoint descriptor is 0x7FFF
and
2. This is the only endpoint descriptor that is being operated upon by
the OHCI controller.

========================================================================
========== 
Relevant code sections :
ohci-q.c
/* there are some urbs/eds to unlink; called in_irq(), with HCD locked
*/
static void
finish_unlinks (struct ohci_hcd *ohci, u16 tick, struct pt_regs *regs)
{
    struct ed   *ed, **last;
 
rescan_all:
    for (last = &ohci->ed_rm_list, ed = *last; ed != NULL; ed = *last) {
        struct list_head    *entry, *tmp;
        int         completed, modified;
        __le32          *prev;
 
        /* only take off EDs that the HC isn't using, accounting for
         * frame counter wraps and EDs with partially retired TDs
         */
        if (likely (regs && HCD_IS_RUNNING(ohci->hcd.state))) {
            if (tick_before (tick, ed->tick)) {   <------ this check
always true if ed->tick is 0x7FFF
skip_ed:
                last = &ed->ed_next;
                continue;
            }
 

ohci-hub.c:
#define tick_before(t1,t2) ((((s16)(t1))-((s16)(t2))) < 0)

========================================================================
==========
 
Since the tick_before condition always returns true, this 'ed' is never
removed for processing and hence the timeout. For trying out the above
condition was changed to :
            if (tick == ed->tick)) {    
skip_ed:
                last = &ed->ed_next;
                continue;
            }

Ofcourse my read of the whole thing might be totally off, but where
earlier we used to see a failure maybe in about 24 hours, driver with
above correction ran for a week. 

Note that it is very unlikely that this bug will be encountered in a
normal OHCI usage scenario. We encountered it only when we were running
extensive USB traffic alongwith a bunch of other system tests. 

Feedback appreciated.

Ananth


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel