USB power always on (fix?)

wadsworth · 04-05-2008, 01:05 PM

I have an issue thats been bothering me since I switched from MS Windows
over two years ago. Windows used to completely power down my computer.
Shutting down from Linux leaves the USB ports powered, so a USB mouse/gamepad
just sits there and "glows" all night for no good reason. Very annoying.

I've been poking around google off-and-on for a solution ever since.
It seems that this occurs due to a "buggy" BIOS implementation that mostly
affects nForce chipset motherboards. (Mine is a Gigabyte GA-7N400-L nForce2)

Finally stumbled on a thread that spans almost two years (!!!)
but contains a workaround:
http://bugzilla.kernel.org/show_bug.cgi?id=5410

Applied the patch, recompiled. And IT WORKS!
USB ports power down just like they should. Awesome.

Here is the diff from my 2.6.21.5 tree:

Code:

--- ./drivers/usb/host/ohci-hcd.c.orig	2007-06-11 14:37:06.000000000 -0400
+++ ./drivers/usb/host/ohci-hcd.c	2008-04-03 22:56:53.000000000 -0400
@@ -361,7 +361,8 @@
 static void ohci_usb_reset (struct ohci_hcd *ohci)
 {
 	ohci->hc_control = ohci_readl (ohci, &ohci->regs->control);
-	ohci->hc_control &= OHCI_CTRL_RWC;
+	/* ohci->hc_control &= OHCI_CTRL_RWC; */
+	ohci->hc_control &= (OHCI_CTRL_RWC | OHCI_CTRL_HCFS);
 	ohci_writel (ohci, ohci->hc_control, &ohci->regs->control);
 }

I guess my question is, could you see any problem surfacing from using this patch?
From my limited understanding of what this patch does, it sounds safe.
I've only been running this kernel for a few days, zero problems so far.
Any thoughts/opinions would be appreciated.

I have to mention that Zenwalk 5.0 properly powers off the USB ports at shutdown.
Only distro that ever has. Thought that maybe the kernel version Zenwalk used
(2.6.24.2) had finally fixed this, so I compiled a vanilla 2.6.24.4 kernel
for Slackware. No luck, same issue. Not sure what Zenwalk did to fix the problem,
but they seem to have it solved.

Thanks!

MS3FGX · 04-05-2008, 01:12 PM

Very rarely does Pat include any patched sources in Slackware, one of the main goals with Slackware is having the system built from all vanilla sources rather than relying on distro-specific patches like many of the others do (it can lead to instability and general incompatibility with other systems).

I don't know enough about the kernel to say if this is 100% safe or not, but I do have to wonder why it has never been implemented into the mainline kernel. Until that point we won't see it in Slackware, that much is certain.

wadsworth · 04-05-2008, 01:41 PM

The kernel devs thinking is probably:
"We're doing the right thing, you're closed-source BIOS isn't.
Since its closed-source, we have no way to fix it. Have a nice day."

Its a little much to expect kernel devs to work around bugs they have no knowledge of
or control over.

Still, would be nice to see some kind of fix in the main kernel.

H_TeXMeX_H · 04-05-2008, 02:56 PM

Maybe it's not a 'fix' maybe it's a 'workaround', in which case it may still make it.

gnashley · 04-06-2008, 01:55 AM

This seems to be a pretty harmless workaround which shouldn't cause you any grief unless you are using ACPI's suspend functionality with a USB keyboard or mouse; and/or (maybe) wake-on-lan with some sort of USB connected network device.
The macros mentioned are 'host controller functional state' and 'remote wakeup connected'

There seems to be little chance of the fix affecting other systems and since it's just a one-line patch it should be easy enough for you to patch your own kernel to apply the fix, at least until the code in that area gets re-written to where it can't be recognized -or maybe the USB developers figure out another way to handle things which takes your problem into account.