On Tuesday 27 February 2007 3:16 pm, Andrea Arcangeli wrote: > On Tue, Feb 27, 2007 at 01:56:59PM -0800, David Brownell wrote: > > You could try updating /etc/modprobe.conf with "options ov511 cams=2" > > cams=2 fixed it! So I've a real clean workaround now. > > And before doing any work on ov511 at this point we'd need to know > what's the status of the driver... (i.e. most uptodate version)
Good that cams=2 worked, and agreed on current version. ISTR there's a website to look at. > > (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.) > > There are 4 ports in the back and 2 in the front. It was in one on the > back, now it's on the front, it doesn't seem to make difference > because internally they seem all connected to the same chip. Right, the alternate wiring would involve an external high speed hub. > Power usage is quite good, with a 65W EE X2 4600 I get 136W total with > average load. Hey, most of the systems I work with lately need _much_ less than 1W. ;) Not x86 of course! For x86, those numbers seem nice. > > That's one way to look at it. How would you describe overcommitting > > swapspace? :) > > But we exactly allow overcommitting swapspace for similar reasons: not > all apps behave sanely. They often allocate ram they never map and so > effectively the reserved ram is just "virtual" and zerocost, just like > the bandwidth reserved by ov511. Actually, ov511 is performing I/O every frame ... that bandwidth is hardly virtual. What's more virtual is the cost for the various "interrupt" transfers. That's done by the host polling the peripheral. Usually when it polls something like a USB keyboard or mouse (or UPS), there's no data; but the bandwidth allocation assumes that every poll will return data. If the device is a low speed mouse sending 8 bytes of data, that wastes a LOT of bandwidth. (Which is why I suggested putting your lowspeed devices on a high speed hub, where they'll waste less bandwidth.) I mentioned swapspace overcommit because there's a good analogy lurking there. Thing is, ISO devices (like webcams) actually *do* use all that bandwidth they're requesting, so ENOSPC there reflects the analogue of a true/hard OOM error. But all those interrupt transfers ... that's where one *might* want to allow overcommit, since most of that bandwidth isn't really used. - 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
