On Fri, Jan 13, 2012 at 10:45:24AM -0500, Alan Stern wrote: > [CC: list trimmed a little; I hope nobody objects] > > On Thu, 12 Jan 2012, Sarah Sharp wrote: > > > It would be a big help if it was added. It matters to Linux server > > distributions in particular because several server vendors have started > > to integrate emulated USB devices onto the server. A "BMC" device from > > an outside vendor attaches to a USB host port, and emulates a hub with a > > USB mouse, keyboard, and maybe a USB CD drive attached. Then a sys > > admin can remotely share a .iso file, and on the server side the CD just > > appears in the emulated USB CD drive. > > The impact will be minimal, because of drive polling. Yes, I know. I had hoped that if the auto-suspend timeout was set to zero, the mass storage driver would suspend the device immediately after any SCSI command, but you've said that's not true. > And won't the > emulated mouse and keyboard prevent the hub and controller from > suspending? They can enable auto-suspend for the HIDs, which should give them good power management if remote wakeup actually works. I would hope that these BMC devices don't lose keystrokes like cheap physical mice/keyboards, but I don't know if they do. I did give them a whitepaper showing how to test USB autosuspend with the new powertop, so we'll see if that pushes the server vendors to lean on their BMC device manufacturers. > > The problem is that since the BMC actually attaches to the host > > controller, it can impact system power management if all the emulated > > devices aren't suspended. A couple of Intel server vendors have gotten > > really cranky about the power management on systems with the EHCI rate > > matching hub and a BMC. Apparently power management is much worse for > > unsuspended HIDs under EHCI than under UHCI, since the EHCI periodic > > frame list keeps getting polled by the EHCI hardware, making the CPU > > come out of C states, etc. > > The same is true for UHCI, although perhaps the impact is less severe > because the polling is less frequent (once per frame instead of once > per uframe). Yes, exactly. > > Async endpoints don't cause as big a power > > draw, but it would benefit system power management overall if they were > > able to be suspended. > > Well, one thing they could do right away is unbind the hub driver from > the BMC's emulated hub. Then the emulated hub would be suspended and > wouldn't affect the EHCI controller. > > Of course, it would then be necessary to rebind the hub driver before > using the BMC's integrated components, which might be an issue. Yes, I suppose that could work, assuming they're actually installing any software on the server side for their BMC. With the set up they have now, the server only has to understand about USB devices in order to have the admin control the system via mouse, keyboard, and mass storage device. Only the admin's box needs to have special software to start the session. (I'm just guessing how this all works, of course, so I may be wrong.) Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
