|Summary:||Reboot instead of powerdown with 2.6.20-rc4 or 2.6.20-rc5|
|Product:||Drivers||Reporter:||François Valenduc (francoisvalenduc)|
|Component:||USB||Assignee:||Alan Stern (stern)|
|Severity:||normal||CC:||acpi-bugzilla, bunk, stern|
dmesg - kernel 184.108.40.206
dmesg, kernel 220.127.116.11
dmesg - kernel 2.6.20-rc5
Dmesg of kernel 2.6.20-rc6 with usb suspend enabled
Disable remote wakeup at EHCI shutdown
patch vs 2.6.20 to fix poweroff
Disable remote wakeup at EHCI shutdown
Disable remote wakeup at EHCI shutdown (v. 3)
Description François Valenduc 2007-01-15 10:11:34 UTC
Comment 1 Andrew Morton 2007-01-15 13:43:36 UTC
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: firstname.lastname@example.org To: email@example.com 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: firstname.lastname@example.org Submitter: email@example.com Most recent kernel where this bug did *NOT* occur: 18.104.22.168 (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.
Comment 2 François Valenduc 2007-01-16 12:57:43 UTC
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".
Comment 3 Adrian Bunk 2007-01-18 03:27:43 UTC
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.
Comment 4 François Valenduc 2007-01-18 04:19:09 UTC
Created attachment 10118 [details] dmesg - kernel 22.214.171.124
Comment 5 François Valenduc 2007-01-18 04:20:31 UTC
Created attachment 10119 [details] dmesg, kernel 126.96.36.199
Comment 6 François Valenduc 2007-01-18 04:21:34 UTC
Created attachment 10120 [details] dmesg - kernel 2.6.20-rc5
Comment 7 François Valenduc 2007-01-18 04:27:51 UTC
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.
Comment 8 Alan Stern 2007-01-24 08:58:26 UTC
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.
Comment 9 François Valenduc 2007-01-28 05:50:03 UTC
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.
Comment 10 Alan Stern 2007-01-28 12:37:34 UTC
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.
Comment 11 François Valenduc 2007-01-29 09:42:04 UTC
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.
Comment 12 Alan Stern 2007-01-29 13:18:36 UTC
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.
Comment 13 Alan Stern 2007-01-30 07:01:21 UTC
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.
Comment 14 François Valenduc 2007-01-30 10:48:33 UTC
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.
Comment 15 François Valenduc 2007-01-30 10:49:33 UTC
Created attachment 10230 [details] Dmesg of kernel 2.6.20-rc6 with usb suspend enabled
Comment 16 Alan Stern 2007-01-31 09:07:52 UTC
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.
Comment 17 François Valenduc 2007-01-31 13:51:35 UTC
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 !
Comment 18 Alan Stern 2007-02-01 07:04:27 UTC
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.
Comment 19 François Valenduc 2007-02-01 10:13:08 UTC
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.
Comment 20 Alan Stern 2007-02-01 10:53:04 UTC
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?
Comment 21 François Valenduc 2007-02-01 11:39:39 UTC
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.
Comment 22 François Valenduc 2007-02-01 11:49:02 UTC
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.
Comment 23 Alan Stern 2007-02-01 12:27:15 UTC
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.
Comment 24 François Valenduc 2007-02-02 10:13:05 UTC
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 ?
Comment 25 Alan Stern 2007-02-02 11:02:17 UTC
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?
Comment 26 François Valenduc 2007-02-02 11:33:37 UTC
So, I just tested what happens with kernel 188.8.131.52. 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 184.108.40.206.
Comment 27 Alan Stern 2007-02-02 12:12:10 UTC
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.
Comment 28 Adrian Bunk 2007-02-05 19:37:37 UTC
*** Bug 7945 has been marked as a duplicate of this bug. ***
Comment 29 Alan Stern 2007-02-06 07:18:16 UTC
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?
Comment 30 François Valenduc 2007-02-07 12:49:45 UTC
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
Comment 31 Alan Stern 2007-02-07 13:16:29 UTC
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 220.127.116.11. You can go ahead and close this bug report.
Comment 32 François Valenduc 2007-02-07 13:20:03 UTC
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 !
Comment 33 Alan Stern 2007-02-08 09:33:22 UTC
Len and Fran
Comment 34 Len Brown 2007-02-09 09:51:09 UTC
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.
Comment 35 Alan Stern 2007-02-09 11:09:33 UTC
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.
Comment 36 François Valenduc 2007-02-09 12:21:48 UTC
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.
Comment 37 Len Brown 2007-02-09 13:06:54 UTC
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.
Comment 38 Len Brown 2007-02-09 13:26:03 UTC
Yes, the patch in comment #29 allows the SE7525GP2 to power off.
Comment 39 Len Brown 2007-02-09 14:22:28 UTC
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.
Comment 40 Alan Stern 2007-02-09 19:35:10 UTC
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?
Comment 41 Alan Stern 2007-02-11 14:03:30 UTC
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.
Comment 42 Len Brown 2007-02-13 00:53:30 UTC
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.
Comment 43 Alan Stern 2007-02-13 11:38:28 UTC
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.
Comment 44 Len Brown 2007-02-13 15:19:15 UTC
The patch in comment #43 fixes poweroff on an Intel SE7505VB2 (32-bit dual Xeon).
Comment 45 Len Brown 2007-02-13 15:32:43 UTC
Observed this failure also on a Supermicro X7DB8+ Dual Xeon server (x86_64). Verified that the patch in comment #43 fixes it.
Comment 46 Len Brown 2007-02-13 15:45:10 UTC
The patch in comment #43 fixes poweroff on an Intel SE7525GP2 (64-bit dual Xeon).
Comment 47 François Valenduc 2007-02-13 23:58:52 UTC
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.
Comment 48 Alan Stern 2007-02-14 07:26:21 UTC
Len, thanks for testing. The patch has been submitted. Fran
Comment 49 Jonathan Woithe 2007-02-19 20:14:17 UTC
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).
Comment 50 Jonathan Woithe 2007-02-20 16:30:08 UTC
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.
Comment 51 Alan Stern 2007-03-07 07:00:58 UTC
The final patch has been queued for 2.6.20-stable.
Comment 52 ChenYongqiang 2007-05-09 19:19:32 UTC
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!
Comment 53 Alan Stern 2007-05-10 08:34:18 UTC
On Wed, 9 May 2007 firstname.lastname@example.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=7828 > > email@example.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|CLOSED |NEW > Resolution|CODE_FIX | > > > > ------- Additional Comments From firstname.lastname@example.org 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