On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 8:42 am, Christopher Montgomery wrote:
>
> > The hub is plugged in doing nothing.
>
> Except being regularly polled "did anything happen" about 4x/second.
> It's certainly active. (Though there's some new autosuspend stuff
> in the works that could de-activate it and use remote wakeup to
> learn about all interesting happenings.)
Uh.. yes. I said that. You were the one repeating that there were no
active URBs so it was impossible I was seeing what I was seeing. I am
seeing it, there are active URBs. I've gone through the scenario a
few times now. Plug in hub. Unplug hub. buckets of EPROTO. lots of
unschedule reschedule that I'd like to prevent.
> You appear to have changed something, and thereby prevented khubd
> from marking the device gone. Otherwise faults like EPROTO would
> normally appear at most once.
The code in ehci-hub.c immediately resubmits that URB on -EPROTO. it
will retry ten times. Regardless what it causing it, in the possible
[probable] event I'm confused as to *why*,at least *what* is certain.
it is happening. It is in my logs, I am not imagining it.
But to be damned certain, I will go build a 100% generic kernel and
log it again, just to be really really really sure.
>
>
> > > That's why the URB submitter should throttle its activity. ehci-hcd can't
> > > do much about it.
> >
> > ...except that ehci-hcd is what is resubmitting the URB.
>
> Nope ... no 2.6 HCD resubmits URBs; they're not allowed to.
> Automagic resubmission has been gone for several years now.
2.6.17-rc3: core/hub.c:hub_irq():
switch (urb->status) {
case -ENOENT: /* synchronous unlink */
case -ECONNRESET: /* async unlink */
case -ESHUTDOWN: /* hardware going away */
return;
default: /* presumably an error */
/* Cause a hub reset after 10 consecutive errors */
dev_dbg (hub->intfdev, "transfer --> %d\n", urb->status);
if ((++hub->nerrors < 10) || hub->error)
goto resubmit;
hub->error = urb->status;
/* FALL THROUGH */
/* let khubd handle things */
case 0: /* we got data: port status changed */
bits = 0;
for (i = 0; i < urb->actual_length; ++i)
bits |= ((unsigned long) ((*hub->buffer)[i]))
<< (i*8);
hub->event_bits[0] = bits;
break;
}
hub->nerrors = 0;
/* Something happened, let khubd figure it out */
kick_khubd(hub);
resubmit:
if (hub->quiescing)
return;
if ((status = usb_submit_urb (hub->urb, GFP_ATOMIC)) != 0
&& status != -ENODEV && status != -EPERM)
dev_err (hub->intfdev, "resubmit --> %d\n", status);
Am I misinterpreting the meaning of 'resubmit'? This is the block of
code being executed on -EPROTO. The urb is being resubmitted.
> The URBs you're talking about have already been submitted,
> and the HCD is still working on them. Drivers are free to
> unlink them, and usbcore will abort them sometime after it
> notices a disconnect. But until one of those things happens,
> or the URB gets a hardware fault, the HCD is not allowed to
> do anything except work on completing the URBs.
I'm not arguing with this. I'm looking for a way to avoid wasted
computation that *is* occurring. I'm not even claiming it's a huge
problem, just one I'd like to avoid if it's at all easy to do so.
Monty
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
