Bug 5410

please try > 2.6.14-rc2.

Hello Alexey, 
 
thanks for your reply! 
 
I tried 2.6.14-rc3 and the mouse light keeps doing its job after shutdown. So 
it's not fixed as of yet. 
 
Cheers 
 
Sebastian 

2.6.14: No proper shutdown 
 
Cheers 
 
Sebastian 

Could you try to unload usb modules before shutdown?

I'm usually not into modules (I compile everything statically when I need it 
everytime). But I changed my kernel config and recompiled. 
 
On startup I loaded these modules: 
 
usblp 
usbcore 
ehci-hcd 
ohci-hcd 
usbhid 
usb-storage 
 
On shutdown I tried to unload the drivers: 
 
rmmod usblp 
rmmod ehci-hcd 
rmmod ohci-hcd 
rmmod usbhid 
rmmod usb-storage 
rmmod usbcore 
 
But usb-core module didn't want to be unloaded. So next time I booted I didn't 
load it. Then, at shutdown: 
 
rmmod usblp 
rmmod ehci-hcd 
rmmod ohci-hcd 
rmmod usbhid 
rmmod usb-storage 
rmmod usbcore 
 
usbcore didn't want to be unloaded. rmmod said it's still used. It didn't tell 
by whom (same situation like the usb-storage module). I filled in an lsmod 
execution and that's what I got: 
 
Module                  Size  Used by 
usbcore               107136  1 
 
Not really helpful. I'm sorry, I just can't get the last one to unload. 
 

So you think this could be related to the kernel's USB system? Not ACPI? 

Maybe it is because I can't unload the drivers properly. Maybe when compiled 
into the kernel statically there's also a way to remove the drivers and it's 
not working either. 

Do you think we should CC some USB people? :) 

At least. Or move it USB subsystem completely. :)

Great idea!! ;-) 

Still no proper shutdown with kernel 2.6.15 :) 
 
Happy New Year 
 
Sebastian 

Hi,

emm.. are you sure about this?

If I shutdown my system, the light of my mouse stays on too, because I set a jumper on my 
board, about the way the usb boards get their power.

It is called PS2_USB_PWR and is needed, if I want to wake up the box with a ps/2 or usb 
keyboard event (IE pressing a key).

If it is closed, the mouse light stays on, if it is open, the mouse wents off.
Maybe you should check your jumpers?

Because - ATX boards are always powered, as long, as you don't pull the plug from the 
outlet.

Hi Volker, 
 
thanks for your input. Never thought about it this way. 
 
I checked the manual of my motherboard and it turns out there's only one 
jumper on this motherboard(!). Unbelievable but true. And the one jumper is 
for clearing CMOS. So I assume PS2_USB_PWR can't be turned off on this board 
and therefore, because you can select USB power-up and PS/2 power-up in the 
BIOS, it's alway on. So I guess I was irritated by the fact that the light was 
off after shutdown with earlier kernels (and I still am a little, but you 
already said that it works for you). 
 
So, being unable to test because of the lack of a jumper, I assume I should 
just close this bug report? 
 
I wouldn't believe that a motherboard has just one jumber, so in case you want 
to check you can have a look at the manual, too ;) 
 
ftp://ftp.shuttle.com/Manuals/en/an35_n/an35en.zip 
 
Sincerely 
 
Sebastian 

Hi,

I don't know, if this bug should be colses - it was just a suggestion, because this is how two 
of my boards work. With the jumper set, one of my usb-mice never really turns off. 
Without the jumper, it is 'off'. But I don't care too much, because I always switch it off at 
the power strip - very usefull with 'on on power loss'.

Do you have a bios setting 'keyboard power on', that is set?

Maybe that is the cause?

Yes, I have USB power-up and PS/2 power-up options in by bios. Both are 
disabled. The USB power-up only works with ACPI S3 afaik which I have not 
enabled (S1 instead). I was hoping to turn of the lights by disabling 
everything in this regard but no dice. 
 
Sebastian 
 
 

It's possible this really is a small USB bug.  Forgetting about 
board jumpers, VBUS power on USB is often controlled by software 
through the root hub ... and right now nothing in the USB code 
will be issuing a "turn off VBUS power" command on shutdown(). 
 
Now, not every USB root hub supports that, since not every board 
can spend the pin(s) involved for that purpose.  (One pin per port 
in the per-port power switching model, and one per controller in 
the ganged model ... the ganged model may not work well with EHCI.) 
 
I know that the USB controllers on my own NF2 board do ** NOT ** 
support software control of VBUS power through the USB port.  In 
fact _none_ of my current systems support that on the root hub; 
though I certainly have add-in PCI cards that work that way.  It's 
theoretically possible that there are some SouthBridge-internal 
hooks to do that, e.g. GPIOs that the BIOS manages, but those would 
be either chipset or board specific. 
 
(How to tell?  Simplest is "lsusb -v" and look at the "Hub Descriptor" 
entry for your root hubs.  "No power switching" under wHubCharacteristic 
means, well, no power switching.) 
 
Best way to fix this would be waiting till the first 2.6.19 prepatches 
appear, with some new usbcore shutdown hooks.  Then use those to issue 
a new "power down those hub ports" request for the root hubs ... it'd 
work for some systems, not all. 
 
 

Hi David,

lsusb tells me "No power switching" for every root hub. Also NF2.

Btw., I now got windows xp home on a seperate partition. When it shuts down 
the mouse light goes off. Maybe someone can decide which OS does it the proper 
way? I'd still like to see that the light goes off. Since I reported this bug 
I load a patched 2.6.9 kernel (some acpi patch that shuts down the computer - 
found the bzImage in the nvram-wakeup source on sf.net) when I shut down. So 
instead of shutting down instantly the computer reboots, loads the 2.6.9 
kernel and shuts down. It's annoying, but at least the light's off.

I don't get a proper shutdown either with kernel 2.6.15 in Ubuntu Dapper. I seem
to remember 2.6.12 in Breezy powering down my USB devices fine. Windows also
seems to power everything down.

Note, my LAN port appears to stay powered too. This is on an Asus A8N-E mobo

Hello all,

today I wanted to try this again. I found commit 
c36f19e02a96488f550fdb678c92500afca3109b . It fixed the
"didn't power off at all" issue I had with 2.6.13-rc{3,4}.

Then I was able to properly check 2.6.13-rc3 regarding the
mouse light situation. It turns out the problem was
introduced somewhere between 2.6.13-rc2-git5 and
2.6.13-rc3.

So I did a git bisection (git was awesome!) and found the
culprit:

commit edfd6aee1f073ae645bd3e60ef96090fc9f0957b
Author: david-b@pacbell.net <david-b@pacbell.net>
Date:   Wed Jun 29 07:03:10 2005 -0700

    [PATCH] USB: fix ohci merge glitch

    A patch re-organizing some parts of root hub initialization deleted the
    code initializing the bus-neutral reboot/shutdown notifier for OHCI.
    This patch just restores that deleted code.

    Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 0375097..68decab 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -673,8 +673,10 @@ retry:

        ohci_dump (ohci, 1);

-       if (ohci_to_hcd(ohci)->self.root_hub == NULL)
+       if (ohci_to_hcd(ohci)->self.root_hub == NULL) {
+               register_reboot_notifier (&ohci->reboot_notifier);
                create_debug_files (ohci);
+       }

        return 0;
 }

I tested kernel 2.6.13-rc3 again. The vanilla version
(vanilla except for the "didn't power off at all" diff)
kept the mouse light on. I reverted the patch above and
finally the mouse light went of like I figure it should
(I like it better this way and Windows does switch off
the light as well).

I looked around my current kernel (2.6.21-rc5, light
stays on of course) but I couldn't find anything similar.
I hope you guys will.

Thank you
Sebastian

I don't know if this is relevant but I'd like to add that although the mouse 
light goes off I can still plug in my mobile audio player and have it recharge 
while the computer is powered down. I think that's the way it should be.

Your last comment doesn't seem to make much sense.  If the mouse light is off, it indicates that the port isn't supplying any power.  So how can the audio player recharge?

Anyway, in more recent kernels the equivalent code is now in a subroutine named ohci_shutdown.  You can't remove the routine itself, but you can try removing the line where it calls ohci_usb_reset.

There's no question that what the Linux driver does at shutdown time is correct.  No doubt what Windows does is correct also.  The difference in behavior must be caused by some strange feature in your BIOS or your motherboard.

Marc Nijdam wrote to say that his computer also leaves the mouse's LED light on after shutdown.  But if he unplugs the mouse's USB cable and then plugs it back in, the light stays off.  So maybe I was wrong about the mouse light indicating whether or not power is present.

What happens if you try it?  This may indicate that the mouse wants something special to happen before it will turn off the light.

My guess is that the mouse light stays on because Linux resets the USB controller, which in turn sends a reset signal to the mouse.  Probably the same amount of power is supplied to the USB bus in any case -- it's just a matter of whether the mouse decides to turn on its LED.

Hello Alan,

sorry I failed to reply earlier.

You're right, when I unplug the mouse after shutdown its light stays off when I plug it back in.

I'm going to try to find the shutdown hook and remove the reset command - let's see what happens.

Regards
Sebastian

It's easy enough to find.  The routine is ohci_shutdown() in drivers/usb/host/ohci-hcd.c.  It first disables interrupt requests from the controller and then calls ohci_usb_reset(), which does the actual reset.

Hello Alan,

thanks so much!

I changed drivers/usb/host/ohci-hcd.c like you suggested (I hope). This is what ohci_shutdown now looks like:

ohci_shutdown (struct usb_hcd *hcd)
{
        struct ohci_hcd *ohci;

        ohci = hcd_to_ohci (hcd);
        ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
        /* ohci_usb_reset (ohci); */
        /* flush the writes */
        (void) ohci_readl (ohci, &ohci->regs->control);
}

With this change Linux now behaves like my Windows XP on shutdown regarding mouse and mp3 player (I'm mentioning my mp3 player not knowing if it's relevant - you decide).

Now after Linux shuts down my mouse light as well as the display of my mp3 player are off. Same happens when Windows XP shuts down. When I replug the player the display goes on again, which means that it's charging. Replugging the mouse has no effect - it's light stays dark.

Before the change both the mouse light and the mp3 player display stayed lit.

Regards
Sebastian

I meant to write "stood lit" (I hope this is correct grammar) ;-)

Actually "stayed" is correct.  "Stayed" is the past tense of "stay", and "stood" is the past tense of "stand".  Isn't English weird?

It's hard to know exactly what's going on here.  I don't see how resetting the controller could affect the signals seen by the mouse or the mp3 player after the computer has been turned off.  Maybe the difference has to do with the signals just before the system turns off.

Another test you could try is to put ohci_shutdown() back the way it was, and change the second line of ohci_usb_reset().  Change it to:

	ohci->hc_control &= (OHCI_CTRL_RWC | OHCI_CTRL_HCFS);

That will leave the controller running but doing nothing, instead of not running.  Perhaps that will affect the mouse's behavior.

Now I got:

static int ohci_get_frame (struct usb_hcd *hcd)
{
        struct ohci_hcd         *ohci = hcd_to_ohci (hcd);

        return ohci_frame_no(ohci);
}

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_CTRL_HCFS);
        ohci_writel (ohci, ohci->hc_control, &ohci->regs->control);
}

/* ohci_shutdown forcibly disables IRQs and DMA, helping kexec and
 * other cases where the next software may expect clean state from the
 * "firmware".  this is bus-neutral, unlike shutdown() methods.
 */
static void
ohci_shutdown (struct usb_hcd *hcd)
{
        struct ohci_hcd *ohci;

        ohci = hcd_to_ohci (hcd);
        ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
        ohci_usb_reset (ohci);
        /* flush the writes */
        (void) ohci_readl (ohci, &ohci->regs->control);
}

This setup works as well. Mouse and player aren't lit, replugging both has no effect on the mouse and the player starts recharging.

The thing is, making that change to the driver wouldn't be a good idea.  The controller really should be stopped.

Does your BIOS setup include an entry for USB Legacy support?  Does changing the setting help?

Can you try installing a vanilla 2.6.22 kernel?  Make sure that CONFIG_USB_SUSPEND is enabled when you build it.  Then try doing this experiment while the system is running and the mouse is plugged in:

   cd /sys/bus/usb/devices/.../power
   echo disabled >wakeup
   echo suspend  >level

where you must fill in the ... part with the ID of the mouse device.  That will suspend the mouse, which ought to cause the LED to turn off.  Assuming it does, does the LED then turn on again if you shut down the computer?

> Does your BIOS setup include an entry for USB Legacy support?  Does changing
> the setting help?

Yes and I toggled it before - didn't help. Anyway, I need the Legacy mode or I wouldn't be able to operate the lilo boot menu.

I am running a vanilla 2.6.22.9 anyway, so I reversed the changes we made, rebooted and tried what you suggested. I was able to suspend the mouse all right, the light went off - but it immediately turned back on after shutdown.

Hello Alan,

> The thing is, making that change to the driver wouldn't be a good idea. The
> controller really should be stopped.

Could you please explain what the downside would be? And in case some of us want to patch the kernel anyway - what would be the least intrusive/objectionable patch?

Btw looking at this report a reader could come under the impression that only two people have this problem (namely Chris from comment #18) and me. The truth is there are more people out there with the same issue.

For instance: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/48773

I for one would really appreciate a fix, even if it is a fix that doesn't end up in a vanilla kernel.

Regards
Sebastian

Allthough an in-kernel fix would be nicer of course :-)

Without knowing exactly where the problem lies, it's difficult to be specific.  For example, once the mouse's LED is off (because the mouse is suspended), what could cause it to turn back on?  The only thing I can think of is that it doesn't remain suspended -- but nothing the kernel does would reactivate it.  The only possibility is that somehow the BIOS reactivates the mouse at shutdown time.

Except if the controller is left running; then the BIOS (or whoever) leaves the mouse alone.  To me this sounds like a bug in the BIOS.  Now, obviously nothing the kernel does can fix the BIOS.

But these is a workaround; you can always use the code in comment #28.  I'm not sure it will work if you suspend the mouse before shutting down, however you probably don't do that very often.

By the way, in your original bug description you said that the kernel doesn't shut the computer down completely.  Now we know in fact that it's exactly the other way around:  The kernel _does_ shut things down completely, but then the BIOS reactivates the mouse!  The only way to keep the mouse's LED from turning back on is for the kernel to leave the controller running!

So the problem isn't that the kernel fails to shut the computer down completely; the problem is that the kernel _does_ shut the computer down completely and then the BIOS goes crazy.

  The idea of suspending my _mouse_ never entered my mind :) So the workaround in comment #28 it is. Thank you!

  The funny thing is this. I've got another computer at home, and I'm pretty sure it's also using OHCI (it's an Asus M2A-VM mainboard). It has jumpers for USB (which this board right here lacks). So for jumper setting 0-1 electricity is on and for 1-2 it's off (after shutdown). I set 0-1 for the front panel USB connectors as I want to hook up my mp3 player from time to time.
  Now when I power off the computer the display of the player is turned off (without your workaround) :) So there has to be a difference between this board and the M2A-VM regarding the USB issue (assuming this board lacking USB jumpers means it's set to 0-1 all the time).

  Ah, freaky hardware :-)

  P.S.: How about finally closing this bug?

Sure there has to be a difference, but it doesn't have to be a hardware difference.  It could be a difference in the BIOSes.

If you're ready to close the bug report, go right ahead.

Thanks to everyone involved! Chris, I hope the workaround works for you as well.