hm, this could be anything - a triple-fault on the shutdown path would cause
the machine to reboot.

Perhaps you could try booting with acpi=off?

Begin forwarded message:

Date: Mon, 15 Jan 2007 10:18:53 -0800
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 7828] New: Reboot instead of powerdown with 2.6.20-rc4 or 2.6.20-rc5


http://bugzilla.kernel.org/show_bug.cgi?id=7828

           Summary: Reboot instead of powerdown with 2.6.20-rc4 or 2.6.20-
                    rc5
    Kernel Version: 2.6.20-rc5
            Status: NEW
          Severity: normal
             Owner: power-management_other@kernel-bugs.osdl.org
         Submitter: francois.valenduc@skynet.be


Most recent kernel where this bug did *NOT* occur: 2.6.19.2 (or maybe 2.6.20
until rc3, I haven't tested 2.6.20 before rc4)
Distribution: Debian sid
Hardware Environment: ACER Travelmate 4001 WMli, processor Intel centrino 1,5
GhZ (pentium M family)
Software Environment: I don't think it's relevant
Problem Description: When I wan't to shutdown the computer, the shutdown
sequence occurs as expected, however, when the computer is supposed to power
down, it reboots.

Steps to reproduce: Try to powerdown the computer.

Please don't hesitate to ask more info if needed.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

Thanks for your advice. Unfortunately, that didn't help a lot. Now, when I turn
my computer off, the screen becomes black before the end of the shutdown
process. The computer seems to work a bit afterwards, but it doesn't power down.
It remains powered, without rebooting. Setting acpi=off as kernel parameter also
prevent my wireless card (using the ipw2200 driver) to work. I get an error like
"eth1 radio has been killed".

Do you have CONFIG_USB_SUSPEND enabled?
If yes, does disabling it help?

In any case, please attach the output of "dmesg -s 1000000" for both 2.6.19 and
2.6.20-rc5.

Created attachment 10118 [details]
dmesg - kernel 2.6.19.2

Created attachment 10119 [details]
dmesg, kernel 2.6.19.2

Created attachment 10120 [details]
dmesg - kernel 2.6.20-rc5

Disabling USB SUSPEND solves the problem. But, until now, I never had problem
with this  option and it's easier to use suspend to disk with USB Suspend enabled.

Try rmmod'ing various USB drivers before you shut down the computer.  Maybe you
can find a particular driver or device which causes the reboot to occur.

Thanks for the advice. I think I have found the buggy driver. If I unload the
ehci-hcd driver before trying to shutdown my computer, then it's power down
correctly. 

Don't be so sure that ehci-hcd is buggy.  More like it just triggers a bug
somewhere else in the system.  As evidence for this, consider the fact that the
source code for ehci-hcd mentions CONFIG_USB_SUSPEND in only one place, and all
it does is control whether or not a warning message is sent to the system log.

You can test this.  Build ehci-hcd.ko with CONFIG_USB_SUSPEND turned off and
keep a copy of the file.  Then boot a kernel which has CONFIG_USB_SUSPEND turned
on, rmmod ehci-hcd, and insmod the ehci-hcd.ko file you saved.  If the computer
then reboots instead of powering off, it proves that ehci-hcd wasn't the cause
of the problem.

My guess is that this is more likely to be an ACPI or PCI problem than a USB
problem.  The test will prove it one way or the other.

Indeed, using an ehci-hcd module compiled without USB Suspend with a kernel that
has USB suspend enabled also cause the computer to reboot instead of powering
down. But what remains true is that unloading ehci-hcd prior to power down also
allows the computer to power down correctly.

Is there any way you can capture the kernel log while the system is shutting
down?  Using a serial console would work, together with

    echo 9 >/proc/sys/kernel/printk

Also be sure to turn on CONFIG_USB_DEBUG.  Comparing the shutdown logs both with
and without ehci-hcd loaded might give us a clue.  To help avoid confusion,
unplug all your USB devices before running the tests.

Here are some other things you can try.  This will test whether
CONFIG_USB_SUSPEND really is responsible for your problem.  For both these tests
you will have to turn on CONFIG_PM_SYSFS_DEPRECATED, and it would be good to
turn on CONFIG_USB_DEBUG as well.

First, boot a kernel with CONFIG_USB_SUSPEND turned on.  Then do:

    echo disabled >/sys/bus/usb/devices/usb/usb4/power/wakeup
    echo disabled >/sys/bus/usb/devices/usb/usb5/power/wakeup
    echo -n 0 >/sys/bus/usb/devices/usb4/power/state
    echo -n 0 >/sys/bus/usb/devices/usb5/power/state

(Here usb4 and usb5 are supposed to be the two USB buses attached to EHCI
controllers; use the appropriate numbers for your system.)  This will wake up
the two EHCI root hubs and prevent them from being suspended.  Then try to
shutdown and see what happens.

For the second test, use a kernel with CONFIG_USB_SUSPEND turned off.  Then do:

    echo -n 2 >/sys/bus/usb/devices/usb4/power/state
    echo -n 2 >/sys/bus/usb/devices/usb5/power/state

This should suspend the two EHCI root hubs.  Then try to shutdown and see what
happens.

For both tests, monitor the dmesg log to make sure the commands listed above
work properly.

Thanks for your help.
So, I did the tests you suggested. With a kernel having USB suspend enabled,
issuing the two commands
     echo disabled >>/sys/bus/usb/devices/usb/usb4/power/wakeup
      echo -n 0 >>/sys/bus/usb/devices/usb4/power/state
prior to halting the computer leads to a correct shutdown of the computer. Here
below is the result of dmesg after having issued the commands:
    usb usb4: usb resume
    usb usb4: finish resume
    hub 4-0:1.0: hub_resume
    ehci_hcd 0000:00:1d.7: resume root hub
    hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0000
    usb usb4: remote wakeup needed for autosuspend

Without USB suspend enabled, the command 
echo -n 2 >/sys/bus/usb/devices/usb4/power/state generates this result in dmesg:
output: hub 4-0:1.0: hub_suspend. 
This also leads to a correct shutdown of my computer. But, I had already tested
that disabling USB suspend prevent the computer to reboot instead of shutting down.

So, I don't really understand what we can conclude of these tests.
Unfirtunately, my computer doesn't have a serial port so I can't doing the test
using a serial console as you asked.

Created attachment 10230 [details]
Dmesg of kernel 2.6.20-rc6 with usb suspend enabled

Were your two kernels really the same except for the CONFIG_USB_SUSPEND setting?

I have trouble understanding how that setting could affect what happens when you
shut down.  In itself CONFIG_USB_SUSPEND doesn't do anything to the system; all
it does is cause USB devices to be suspended at various times.  So even when it
isn't enabled, if you suspend the devices by hand then the system should be in
the same state.

Can you try the experiments again?  Be sure to use a 2.6.20-rc6 kernel in each
case.  Also, to avoid extra influences, please unplug all your USB devices and
rmmod both uhci-hcd and ohci-hcd before starting the tests.

I confirm that the only difference between the two kernels is "usb suspend". So,
without usb suspend enabled, the computer is able to shutdown. With usb suspend,
shutting down  reboots the computer instead of powering down. If I unload
ehci-hcd, the computer is also able to shutdown. Unloading ehci-hcd is not
necessary with a kernel without usb suspend. If you really want, I can redo the
tests with ohci-hcd and uhci-hcd unloaded but I don't see why it's necessary.

So, maybe usb suspend is not the direct cause of the problem. It could be that
usb devices are suspended during shutdown, which may trigger a problem
elsewhere. But if I have well understood, suspending usb devices by hand without
USB suspend enabled would also trigger the problem, but then the test prooves
that in that case, my computer is able to power down.

So, for me, the problem remains a big mystery !

It's a mystery to me too.  Let's see if we can solve it.  The best approach is
to take out one-at-a-time the components added by USB_SUSPEND; then we'll see
which one is the main cause.

How are your C programming skills?  I can make up a patch if you need it, but
the first few steps are easy enough to do by yourself.  In the kernel source, go
to the drivers/usb/core directory.  To start with, edit the file usb.c.  Find
the usb_autosuspend_work() routine, and remove the line where it calls
usb_suspend_both().  Then build a kernel with USB_SUSPEND and USB_DEBUG turned
on.  The resulting kernel will include almost all of the autosuspend code but it
won't actually autosuspend anything.

So then you can do two experiments: one where you shut down normally (with
nothing suspended) and one where you suspend usb4 by hand before shutting down.
Again, it would be best to unplug all your USB devices before running the tests.

If this doesn't make any difference, go on to the next step.  Edit the two files
usb.c and driver.c, and remove all the references to ksuspend_usb_wq.  This will
prevent the USB-autosuspend kernel thread from running.  Repeat the two
experiments and see if there's any difference now.

Thanks for all your advices.
I think I made some progress. As you suggested, I commented the line containing
"usb_suspend_both()" in usb.c. Even if my C programming skills are extremely
limited, I was able to do it !

That was enough to shutdown my computer correctly. I didn't had suspend usb4 by
hand to avoid the problem. I even did two tries to shutdown: one with all usb
devices unplugged and only ehci-hcd loaded, another with all usb modules loaded
and all usb devices (mouse, sound card and printer) plugged. In both cases, my
computer shutdown as expected. 

So, if I have well understood what I did,the autosuspend capability might the
cause of the problem.

No, just the reverse -- this proves that the autosuspend capability is not the
cause!  After all, the kernel had all the autosuspend code present but it still
shut down correctly.

The next thing to try is this:  Use the same kernel as before, and this time
suspend usb4 by hand before shutting down, by doing

    echo -n 2 >/sys/bus/usb/devices/usb4/power/state

It's possible that your problems are related to the BIOS.  Have you checked to
see if any BIOS updates are available?

Thanks for the explanations. I think I now better understand the problem. I
suspended the usb4 hub by hand and that causes the computer to reboot instead of
shutting down. So I guess that if I let the autosuspend capability enabled,
during the shutdown, the usb4 hub is suspended and that causes the problem. If I
remove the autosuspend capability (like I did with the previous try), usb4 isn't
suspended during shutdown and the computer power downs as expected. 

Furthermore, it seems that even if USB 1.1 hubs (using ochi and uhci) are
suspended, that doesn't prevent the computer to power down since with ohci-hcd
and uhci-hcd loaded but ehci-hcd unloaded, the computer shuts down correctly.

Did I well understand this time ? What do I need to try next ? 

I don't think any BIOS update would solve the problem. Anyway, there are no BIOS
updates available for my computer (an ACER Travelmate 4001 Lmi). I had USB
suspend enabled in older kernels (at least since 2.6.18, maybe before) and I
never had this problems.

I checked that USB 1.1 hubs really don't cause any problem. So I suspended them
by hand and let only usb4 "unsuspended". That didn't prevent the computer to
shut down. So, the problem seems to be that suspending the ehci-hcd hub leads
the computer to reboot instead of powering down.

I agree that the problem happens when usb4 is suspended during shutdown.  But
what about comment #14?  There you said that if you turned off USB_SUSPEND and
suspended usb4 by hand, then the shutdown worked.  Right?  So the mere fact that
the controller is suspended isn't the whole story.

Let's try the other experiment mentioned in comment #18.  Edit usb.c and
driver.c, and remove all the references to ksuspend_usb_wq.  Also keep the
change you made before, commenting out the call to usb_suspend_both().  Then see
what happens when you suspend usb4 by hand before shutting down.

Thanks again for your help,
First I must have done something wrong when I tested a kernel without
USB_SUSPEND enabled. With such a kernel, suspending USB4 by hand also prevent
the computer for powering down. Of course, if I don't suspend usb4, the computer
shuts down correctly. I hope I don't create too much confusion !

Now, with a kernel with USB suspend but where all references to
usb_suspend_both() and ksuspend_usb_wq are commented, the computer also reboot
instead of powering down correctly having suspended usb4. In all cases,
suspending usb4 by hand really works. I always get such an output in dmesg:
    hub 4-0:1.0: hub_suspend
    usb usb4: usb suspend

So, finally  the autosuspend capability or USB SUSPEND don't seem to be the
cause. It's rather the fact that having usb4 suspend during shutdown trigger a
problem which leads the computer to reboot instead of powering down.

Do you have any idea to solve the problem ? Or do you have any idea of other
tests I should also do ?

Next we should find out if the same thing happens with earlier versions of the
kernel.  With 2.6.19 and CONFIG_PM_SYSFS_DEPRECATED turned on, if you suspend
usb4 by hand does the shutdown work?

So, I just tested what happens with kernel 2.6.19.2. And if I suspend usb4, that
also prevents the computer to power down. I haven't changed anything to usb.c
and drivers.c files. Should I also modify them ? What I don't understand very
well is that halting the computer without doing anything on the usb4 hubs reboot
the computer with 2.6.20-rc6 and power down the computer with 2.6.19.2.

The difference between 2.6.20 and 2.6.19 is that 2.6.20 has USB autosuspend but
the earlier kernel does not.  As a result 2.6.20 automatically suspends usb4,
since you have no devices plugged into it.  And then since usb4 is suspended,
your shutdown fails.  With 2.6.19, usb4 is not automatically suspended and so
the shutdown works.

You can prevent 2.6.20 from autosuspending usb4 by adding this to your startup
scripts (for example, /etc/rc.d/rc.local):

    echo disabled >/sys/bus/usb/devices/usb4/power/wakeup
    echo -n 0 >/sys/bus/usb/devices/usb4/power/state

After running those two commands, usb4 should no longer be suspended.  You can
check by looking in the dmesg log or at the contents of
/sys/bus/usb/devices/usb4/power/state.

*** Bug 7945 has been marked as a duplicate of this bug. ***

Created attachment 10313 [details]
Disable remote wakeup at EHCI shutdown

I have a theory that the problem arises because remote wakeup is enabled on the
USB ports when an EHCI controller is suspended.  This patch for 2.6.20 will
disable remote wakeup at shutdown time.  Does it allow the shutdown to proceed
correctly when your controller is suspended?

The patch you made solved the problem. I don't understand fully what are the
possible disadvantages of disabling remote wakeup of ehci, but it seems a good
solution to prevent the computer to reboot instead of powering down (without
having to disable autosuspend on the ehci-hcd hub) Do you plan to add that patch
to the official kernel tree ?

Thanks for your help,
Fran

There are no disadvantages.  At shutdown time, remote wakeup is supposed to be
turned off.  I guess on most computers it doesn't matter, but on yours it does.

(Len, have you tried the patch?  Does it help your machine too?)

So yes, I will submit this patch for the official kernel tree.  It might appear
as early as 2.6.20.1.  You can go ahead and close this bug report.

I hope this is the correct way to close the bug. I am not used to it since it
was the first bug I send with the kernel bugzilla system !

Len and Fran

I'll check it out.

BTW. I don't know if this dance is universal, but in the ACPI realm
we mark a bug as RESOLVED when a patch is available for testing
and CLOSED only when the patch has shipped upstream.

Yes, I think I jumped the gun.

I'm concerned about the effect the patch will have when people do
Suspend-to-Disk.  In that situation we do _not_ want to disable remote wakeup on
the EHCI ports -- but if it prevents the machine from shutting down there won't
be any choice.  My hope is that everything can be solved by adjusting settings
in the BIOS.

I don't have any BIOS options related to wakeup settings, so I can't solve the
problem in this way. Anyway, I use suspend to disk (with suspend2) and I didn't
had any problem to use it with USB suspend enabled and your patch. 

With older releases of Suspend2, USB suspend could be used to make suspend and
resume easier with USB devices plugged. More precisely, I can use it to avoid
having to disable my external USB sound card and restart it after resume, which
then implies to stop and restart artsd. I also had some problems with an USB mouse
All these problem seem to be solved with newer releases of Suspend2 and USB
suspend is no more needed. 

The SE7505VB2 BIOS does not have any USB wakeup options.
It has a wake-on modem-ring, which is already disabled.

The SE7525GP2 does not have any USB wakeup options,
It has a wake-on-LAN option, which is already disabled.

Both of these systems worked fine with 2.6.19.

Yes, the patch in comment #29 allows the SE7525GP2 to power off.

Created attachment 10370 [details]
patch vs 2.6.20 to fix poweroff

This patch vs. linux-2.6.20 reverts the commit that
broke poweroff between 2.6.19 and 2.6.20.

Revert: "USB: Add autosuspend support to the hub driver"
40f122f343797d02390c5a157372cac0c5b50bb7

and also a  2nd patch to fix the build:

Revert: "usbcore: remove unused argument in autosuspend"
94fcda1f8ab5e0cacc381c5ca1cc9aa6ad523576

Please explain why sending this patch to 2.6.20.stable would
not be a good idea.

One reason is that the two of you are the only people (that I've heard of) to
report a problem.  Another reason is that the patch in comment #29 also fixes
the problem, in a much less invasive manner.  I would prefer to have that patch
merged instead of reverting the earlier work and losing important functionality.

It's not at all clear that we're facing a kernel problem.  It seems much more
likely to be a BIOS or motherboard bug: If the OS tries to shut down with
remote-wakeup enabled on an EHCI port, the firmware thinks a remote-wakeup event
has occurred (even though it really hasn't) and reboots immediately.

My only real concern has to do with suspend-to-disk.  Some systems really do
support keeping EHCI in D3hot while the machine is off, and they really might
want to have Wake-on-USB enabled.  My patch probably would prevent it from
working (I can't tell whether it will or not; I don't have one of those nice
machines).  However I am willing to sacrifice Wake-on-USB to get 2.6.20-stable
working better.

Do you think I should submit the patch for the stable branch despite this concern?

Created attachment 10387 [details]
Disable remote wakeup at EHCI shutdown

Here is a revised version of the patch.  Unlike the original version, it
doesn't disable the ports completely -- it only turns off remote wakeup, which
seems like a safer thing to do.

Please test it to make sure it also fixes the problem.	If it does, I will
submit it for the stable branch.  It still isn't ideal; a few people may find
that after suspend-to-disk the controller won't respond when a new USB device
is plugged in.	But it's the best I can do for now.

patch in comment #41 fixed poweroff on an Intel SE7525GP2
when applied to Linux-2.6.20

Re: 2.6.20.stable
I believe that a properly functioning poweroff is a fundamental feature
that is extremely important to have working, and keep working.
Indeed, I believe it is more important than suspend to disk,
remote wakeup, and USB power savings combined.

Created attachment 10407 [details]
Disable remote wakeup at EHCI shutdown (v. 3)

After checking around, I decided the original patch would be okay.  Here's a
very slightly revised version of it.  I will submit this version for
2.6.20.stable.

The patch in comment #43 fixes poweroff on an Intel SE7505VB2
(32-bit dual Xeon).

Observed this failure also on a Supermicro X7DB8+ Dual Xeon server (x86_64).
Verified that the patch in comment #43 fixes it.

The patch in comment #43 fixes poweroff on an Intel SE7525GP2
(64-bit dual Xeon).

The 2nd version of the patch also fix the problem. I believe the third one will
do it too but I haven't tested it yet. I don't understand why you worry so much
about suspend-to-disk. If we are both speaking about Suspend2 (from
www.suspend2.net), that works without problem. I have tried it with an usb
device using the ehci-hcd controller and it works absolutely fine after resume.

Len, thanks for testing.  The patch has been submitted.

Fran

It's a little late but I too have a laptop which fails to power off after
shutdown.  2.6.19 worked, 2.6.20 does not.  I shall try the final version of the
patch (v3) and report the outcome.

The only difference between the report's symptoms and my own is that in my case
the screen goes blank, the backlight is turned off and the machine then
effectively hangs (it doesn't reboot).

It turns out I did not have CONFIG_USB_SUSPEND active, so the problem described
here is different to mine.  For completeness I applied the v3 patch but it made
no difference - the machine still locked up (ie: capslock becomes
non-functional) instead of powering off.  I also tried powering off with all USB
modules unloaded and with all modules unloaded (except intel_agp which was
"used" for some reason in text mode) but again there was no difference in behaviour.

The final patch has been queued for 2.6.20-stable.

The patch can not solve my computer poweroff problem!

I must turn off the usb4 autosuspending on kernel 2.6.20.x and 2.6.21.x!

On Wed, 9 May 2007 bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=7828
> 
> aishen944@163.com changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|CLOSED                      |NEW
>          Resolution|CODE_FIX                    |
> 
> 
> 
> ------- Additional Comments From aishen944@163.com  2007-05-09 19:19 -------
> The patch can not solve my computer poweroff problem!
> 
> I must turn off the usb4 autosuspending on kernel 2.6.20.x and 2.6.21.x!

Please do not re-use a closed bug report.  If you have a new problem, open 
a new bug report.

Alan Stern