On Tuesday 27 February 2007 12:28 pm, Andrea Arcangeli wrote:
> This 90% number may very well be an heuristic that was written in the
> specs (in such case an heuristic not created by linux folks, but still
> an heuristic).
Or 80% for high speed. But it's still not a heuristic. It's
part of the specification, an interoperability rule.
> > Sounds then like the open() is being weird. Nothing issued a read
> > yet; nothing yet said how much bandwidth a read should consume. So
> > it has no business submitting an URB (and thus causing ENOSPC).
>
> Ok, so at least this can be improved.
Very much so...
> > It may be that a case could be made that the error is in the relevant
> > video driver...
>
> It's drivers/media/video/ov511.c if you want to have a look.
ISTR hearing there are various webcam driver updates that have not yet
made it back into the kernel. Maybe some relate to ov511 ...
At any rate, that driver open() is obviously doing bad stuff; it sets
up initial ISO transfer sizes based on the number of cameras it expects
to find on a **dedicated USB bus** ... and then acts really stupid
when that guesswork was wrong (as in your case).
You could try updating /etc/modprobe.conf with "options ov511 cams=2"
(or 3, or 5) to make its default guess be less unfriendly. Or maybe
stick that device on a high speed hub ... the transaction translator
support is pretty messy, but I'd expect there's some way to wire things
up to make it behave. (Getting lowspeed devices off the device you
share with that camera would probably help a lot.)
> Yes, everything is fine if I don't open too many devices at the same time.
... as expected. For various reasons, most folk haven't run into
the bandwidth limitations with pure USB 1.1 systems. In your case,
the issue is that recent NVidia chipsets have shaved costs somewhat
(including power usage) by moving from two OHCI controllers (with
just a few ports each) to one (with eight or more ports).
That doesn't really affect anyone except folk using webcams, since
nobody else ever gets anywhere near the bandwidth limits. You, for
example, can't hook up two full speed webcams to that system, and still
get full size images, without using a high speed hub ... something that
earlier NVidia chipsets handled just fine. And you're forcing the same
sort of error by hooking all those other devices onto that same bus.
> > > And would you then please explain why the bug goes away with my patch? ;)
> >
> > You're replacing one bug ("operator error") by adding a kernel bug
> > (overcommit of periodic bandwidth). I'm quite certain you've seen
> > cases where one bug papers over another. This would be a case of
> > wanting to introduce a bug to achieve that papering-over...
>
> Sure I understand. However I perhaps wrongly assumed that the worst
> side effect of overcommit of periodic bandwidth would be graceful usb
> errors at runtime.
The error is graceful. But the behavior of the ov511 driver -- rather
clearly -- is not. It doesn't even bother to prettyprint its diagnostic
at device open() urb_submit time, much less clean up properly after that
error ...
> For an end user, having eciadsl-start sort of
> hanging because of that code, or because the usb chokes at runtime
> isn't very different I assure. A warning in the logs saying
> "bandiwidth exceeded" at runtime and disconnecting the relevant device
> at runtime, would be my preferred approach.
Again, that's the job of ov511. It requested the bandwidth, it didn't
get it, then it behaved rather poorly.
> I think this is what the
> old USB_BANDWIDTH=n did, but I may be mistaken since I don't know much
> about usb.
Right, but it's been ages since OHCI supported that option. The
only reason to have it optional was because the initial version
bandwidth limitation logic didn't work correctly. (Though OHCI
wasn't very broken, if at all.)
> This approach better assure that we can use the hardware to
> the maximum of its capabilities. Now if you tell me that what I'm
> doing is plain overclocking
That's one way to look at it. How would you describe overcommitting
swapspace? :)
- Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
