Bug 712060 - Kernel 2.6.40.6-0 won't poweroff
Summary: Kernel 2.6.40.6-0 won't poweroff
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-09 11:54 UTC by Andre Costa
Modified: 2011-10-26 18:41 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-21 12:57:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Andre Costa 2011-06-09 11:54:07 UTC
Description of problem:
Kernel 2.6.38.7-30 won't power the system off.

Version-Release number of selected component (if applicable):
2.6.38.7-30

How reproducible:
Always.

Steps to Reproduce:
1.power off the machine
2.
3.
  
Actual results:
Machine doesn't power off.

Expected results:
Machine would power off.

Additional info:
I disabled graphical boot and monitored /var/log/messages with tail -F on a console while I ran "poweroff" on another one, and after a couple of messages complaining about being "unable to detach all DM devices" (apparently harmless according to bug #657497), log registers

[<timestamp>] Power Down

but system remains on.

Comment 1 WarnerJan Veldhuis 2011-06-15 09:41:19 UTC
+1 for this bug. I have exactly the same.

uname -a: Linux mypc.localdomain 2.6.38.7-30.fc15.x86_64 #1 SMP Fri May 27 05:15:53 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Comment 2 WarnerJan Veldhuis 2011-06-15 11:07:29 UTC
A quick update on this: I noticed the display of my Logitech G15 keyboard staying on. When the message "[<timestamp>] Power Down" showed, I pulled the USB chord of the G15 from the computer and the system powered down immediately.

So I used another USB socket, in my case I used one in my monitor which functions as an USB hub, and after that power off works every time. 

Very weird, but fixed for me at the moment.

Comment 3 Andre Costa 2011-06-15 14:03:39 UTC
Sorry to hear that, but hopefully it will attract more attention to this problem.

I did a couple of tests with previous stable kernel version and the results were: the system powered off just fine if it didn't go into suspend state; if it went resume did not work. So, considering pros and cons, I am sticking with latest stable version (which at least resumes from suspend just fine), but I either have to hold power button for 5s in order for it to power off or I reboot and power off during the GRUB screen.

(BTW: restart works just fine, only power off is broken)

Just curious: are you using NVIDIA driver as well?

Comment 4 WarnerJan Veldhuis 2011-06-15 18:08:05 UTC
(In reply to comment #3)

> Just curious: are you using NVIDIA driver as well?

Yes, I am, although I doubt it's the cause of the problem. When you get the Power down message, can you try to remove some energy consuming USB devices to see if this works for you as well?

Comment 5 Andre Costa 2011-06-15 20:38:21 UTC
(In reply to comment #4)
> Yes, I am, although I doubt it's the cause of the problem.

Agreed, it was a long shot ;-) (BTW: I am currently using latest stable driver installed directly from NVIDIA's .run installer because it seems to fix a suspend-resume bug that was causing gnome-shell to segfault)

> When you get the
> Power down message, can you try to remove some energy consuming USB devices to
> see if this works for you as well?

Sure, will do, and I will post back here the results.

Comment 6 Andre Costa 2011-06-17 15:20:02 UTC
I just confirmed, unplugging the USB mouse (the only USB device I have) when I get the power down messange doesn't help, system still doesn't power off.

Comment 7 Andre Costa 2011-06-25 14:41:30 UTC
Any news on this front? Should I report this upstream? Any other info we could provide?

Comment 8 Andre Costa 2011-07-13 18:17:13 UTC
Kernel 2.6.38.8-35 still shows the same problem. One thing I noticed (even with the previous version) is that sometimes it does power off, but I can't precise exactly what triggers the problem. Even though it doesn't make much sense to me, IIRC all the times the system powered off properly were times when I hadn't manually suspended it.

Comment 9 Andre Costa 2011-08-05 13:47:13 UTC
Kernel 2.6.40-4 fixed this problem for me AFAICS. Can anyone else confirm this?

Comment 10 Andre Costa 2011-08-13 14:44:42 UTC
Well, I was wrong. 2.6.40-4 apparently improved things (I've been able to power off a couple of times, more than I've ever been with previous F15 kernels), but most of the times it simply stays there showing the Fedora logo instead of powering off. So, once again, I changed this issue's description to keep it up to date.

... I must say this is really frustrating, I've had similar problems in the past with previous Fedora versions, but they did only last one or two kernel versions at most. Ever since F15 came out I've been unable to consistently power off my system, and it seems no one's looking into this. I even thought about reporting it upstream (kernel developers), but I guess it would be pointless since Fedora kernel isn't vanilla. If anyone has any tip on how I could gather more info on what could be the real cause (kernel? systemd? ...), I would be really thankful.

Comment 11 Jurgen Kramer 2011-09-05 17:14:56 UTC
I've also been plagued by this bug for a while now. 3 out of 5 times my system won't shutdown and I have to switch off the power supply.

I am currently still on 2.6.40.3-0.fc15.x86_64. I'll check if .40.4-5 will improve things.

Comment 12 Jurgen Kramer 2011-09-22 18:21:37 UTC
I did not have the failed-to-shutdown problem since 2.6.40.4-5 (or maybe some other updates).

Comment 13 dobs 2011-10-04 13:07:26 UTC
I have this problem on 2.6.40.4-5.fc15.x86_64

Comment 14 Andre Costa 2011-10-05 20:49:34 UTC
Yeah, me too, it still fails more often than it succeeds. I updated the title, but it looks like we should forget about it for F15 and just hope we'll have better luck with F16...

Just to see if there's anything in common among all of us affected by this bug: do you guys also have your / partition on LVM? My partitions are set like this:

/dev/mapper/VolGroup00-Home on /home type ext4 (rw,relatime,seclabel,user_xattr,barrier=1,data=ordered)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/mapper/VolGroup00-System on /tmp type ext4 (rw,relatime,seclabel,user_xattr,barrier=1,data=ordered)
/dev/mapper/VolGroup00-System on /var/tmp type ext4 (rw,relatime,seclabel,user_xattr,barrier=1,data=ordered)
/dev/mapper/VolGroup00-Home on /home type ext4 (rw,relatime,seclabel,user_xattr,barrier=1,data=ordered)

BTW: i just realized /dev/mapper/VolGroup00-Home appears twice, which is weird but at least both instances are mapped to /home, but /dev/mapper/VolGroup00-System appears twice and, according to mount, each instance is mapped to a different dir (?!). Could this be related? Or is this just some 'mount' bug?

Comment 15 WarnerJan Veldhuis 2011-10-06 07:58:08 UTC
No, either it's a bug, or it's a normal situation. See my mount output:

/dev/mapper/vg_pcwj-lv_home on /home type ext4 (rw,relatime,user_xattr,barrier=1,stripe=64,data=ordered)
/dev/mapper/vg_pcwj-lv_root on /tmp type ext4 (rw,relatime,user_xattr,barrier=1,stripe=64,data=ordered)
/dev/mapper/vg_pcwj-lv_root on /var/tmp type ext4 (rw,relatime,user_xattr,barrier=1,stripe=64,data=ordered)
/dev/mapper/vg_pcwj-lv_home on /home type ext4 (rw,relatime,user_xattr,barrier=1,stripe=64,data=ordered)

As you can see, my config has home and root twice too. I am sure I did not do this, since it's the setup suggested by the installer.

Comment 16 Josh Boyer 2011-10-21 01:46:49 UTC
For anyone having the "won't shut off" problem, does it go away if you stop using the NVIDIA module?  It seems the majority of people in this bug report are using that.

Comment 17 Jurgen Kramer 2011-10-21 07:54:35 UTC
Since a couple of weeks (comment #9) I no longer have the problem and I am using the nvidia module.

kernel-2.6.40.6-0.fc15.x86_64

with:
kmod-nvidia-2.6.40.6-0.fc15.x86_64-280.13-2.fc15.3.x86_64
from rpmfusion

Comment 18 Andre Costa 2011-10-21 13:12:46 UTC
(In reply to comment #16)
> For anyone having the "won't shut off" problem, does it go away if you stop
> using the NVIDIA module?  It seems the majority of people in this bug report
> are using that.

I will try using nouveau driver for a while to see if it improves things. However, I tried F16 Beta (which uses nouveau) a couple of days ago and I had the same problem, so it seems to me it is some kernel bug that only affects some specific hardware.

BTW: I forgot to update the summary when the last kernel came out, it still happens. It seems to happen more frequently if I let the computer on for enough time to auto-suspend kick in -- or, in other words, it happens more frequently after the computer has been suspended at least once. But I've already seen it happen right after boot, if I try to power off right from the login screen.

Also, why has this issue been marked as "CLOSED - NOTABUG"?

Comment 19 Andre Costa 2011-10-25 17:04:59 UTC
Ok, I did some additional tests and it looks like this bug is not nvidia-related.

F16 beta (from x86_64 live cd) doesn't power off either, and it uses latest nouveau.

I removed nvidia kernel module and edited xorg.conf to use "nv" driver instead of "nvidia", and commented all configurations specific to nvidia driver. Not sure if this is all I needed, but GNOME wasn't even able to start properly and had to enter fallback mode (my card is a GeForce 9800 GT). Even then, power off didn't work either.

Josh: is there any other test I could do? It seems to me it's premature to mark this as "CLOSED - NOTABUG".

Comment 20 Andre Costa 2011-10-26 18:41:53 UTC
Even more tests: I removed kmod-nvidia and akmod-nvidia, and booted to runlevel 2 (by appending "init 2" to the kernel parameters) so that graphic mode wasn't even initialized. I double-checked and there was no kernel module related to nvidia (lsmod | grep nvidia). Still, I could not power off (using "poweroff" command as root).

Can someone please reopen this issue? ;-)


Note You need to log in before you can comment on or make changes to this bug.