when fix this bug!?

Can you please provide more information according to this howto:
http://fedoraproject.org/wiki/How_to_debug_Systemd_problems#Diagnosing_shutdown_problems

Does the machine poweroff using "sync && poweroff -f" ?

sync && poweroff -f , my system with this command , turned off .

I try systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0

#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro / 
on  /lib/systemd/system-shutdown/debugshutdown.sh
but not found log file!!!

Created attachment 592074 [details]
Shutdown log

Shutdown.sh , create log , i Attached.

(In reply to comment #5)
> Created attachment 592074 [details]
> Shutdown log

This log was obtained without the debug parameters on the kernel command line
 systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0


You say "fedora crashed" - does it mean you can see a stack trace or other error messages? What do you see on the screen when it crashes? Can you take a picture of it and attach it?

hi , i just see fedora logo boot splash .

So to get rid of the splash screens, you can boot without "rhgb quiet" and with "plymouth.enable=0" on the command line. That could make the screen contents more useful.

By the way, I replaced the Fedora wiki page with a link to the upstream wiki, which is more up-to-date:
http://freedesktop.org/wiki/Software/systemd/Debugging
Check it out. There are more tips for debugging shutdown problems.

I changed grub config to text mode .last 10 Messege before hang :
Disabling swaps
detaching loop devices
detaching DM devices
Synchronizing SCSI cache
Stopping disk
pceiport : Wake-up capability enabled by ACPI
ACPI: preparing to enter system sleep state S5
[Firmware Bug]: ACPI : BOIS_OSI(linux) query ignored
Disabling non-boot CPUs
Broke Affinity for irq 16
Broke Affinity for irq 19

Then system hanged

Those are messages from the kernel shutting down. [Reassigning to kernel.]
Does rebooting work normally?

yes , reboot worked !

I installed kernel 3.4.2 from update-testing , but no solved

it seems to be kernel related. i could reproduce it if i first suspended the notebook. (on x86_64). the last message is "Power down". this is a dell latitude e6400 series.

!!! 
do you have solution ?

Same problem with Toshiba Satellite C660D-19X.
Fresh install F17 with update, kernel 3.4.4-3.fc17.
When shuting down last messages are :
pceiport : Wake-up capability enabled by ACPI
ACPI: preparing to enter system sleep state S5
Disabling non-boot CPUs
but no power off, need to use power button to power off laptop.

Hi,

Same result on Dell Optiplex 780. Both for shutdown and restart from GUI, and command line reboot. Blocker for remote restarts.

Was a fresh install, and fully updated.

Is this still happening with 3.8.2 in updates-testing?

I'm still seeing this with F18. This was with a 3.8.1 kernel I think, that system is remote to me. I can test again with latest F18 kernel 3.8.2-206.fc18, 

I assume all you need from this is booting without rhgb, quiet and no GUI. Then initiate a remote reboot and let you know if it hangs and tell you the last lines of output if it does?

Okay I have now tried this on a Dell OptiPlex 790 with  3.8.3-203.fc18.x86_64. The behaviour I get is it always performs a shutdown for me it just won't do a reboot, it just hangs.

I have attached a picture of the last few lines.

Created attachment 714741 [details]
Hung reboot on F18 3.8.3-203.fc18.x86_64 Dell Optiplex 790

Can you try passing the various reboot= options and see if one of them work?
They are:

warm, cold, bios, smp, acpi, efi, pci, force, kbd, triple

I would start with acpi, efi, and pci as those are the most common working options.

I have tried all these options and the only one that works is reboot=pci . Great. 

So is this considered a fix or should the kernel be detecting this somehow and invoking the correct method for this hardware. Or should other options work on this new(ish) hardware and somehow these are being properly invoked by the kernel for this hardware.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Still an issue in F18 see my testing above, should be reassigned to F18. I'll try F19 when I get it installed.

Bumped to 18

I repeated my test on F19 on this Dell Optiplex 790 kernel 3.9.9-301.fc19.x86_64. Identical to before. 

Hangs on reboot unless I put reboot=pci on the kernel line. 

So is this considered a fix or should the kernel be detecting this somehow and invoking the correct method for this hardware. Or should other options work on this new(ish) hardware and somehow these are being properly invoked by the kernel for this hardware.

Please bump to F19

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs.

Fedora 18 has now been rebased to 3.11.4-101.fc18.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19.

If you experience different issues, please open a new bug report for those.

This version needs changed to F19. See my Comment#28. I don't think I can change the version. Can someone else or allow me?

Colin,

could you attach the output of dmidecode of the troublesome box to this BZ please?

thanks,
Michele

Created attachment 824892 [details]
dmidecode from Optiplex 790

Attached the dmidecode from a box that shows the hang on reboot. This machine is a Dell Optiplex 790. Someone else reported that an Optiplex 780 had the same issue, I tried one of these too and it worked fine for me (an update somewhere could have resolved this I guess). My kernel is 3.11.7-200.fc19.x86_64 if that helps, so fully up-to-date.

Thanks Colin

I'll see to submit something like the following:
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index da3c599..97e293b 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -293,6 +293,15 @@ static struct dmi_system_id __initdata reboot_dmi_table[] = {
                        DMI_MATCH(DMI_BOARD_NAME, "0G919G"),
                },
        },
+       {       /* Handle problems with rebooting on Dell OptiPlex 790 with 0HY9JP */
+               .callback = set_pci_reboot,
+               .ident = "Dell OptiPlex 790",
+               .matches = {
+                       DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+                       DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 790"),
+                       DMI_MATCH(DMI_BOARD_NAME, "0HY9JP"),
+               },
+       },
        {       /* Handle problems with rebooting on the OptiPlex 990. */
                .callback = set_pci_reboot,
                .ident = "Dell OptiPlex 990",

Hohum, on rereading the last threads on LKML regarding failed reboots it seems that adding yet another quirk is becoming frowned upon...

Colin, does the reboot work on this Optiplex 790 (without specifying reboot=pci) 
if you disable VT-d?

Disabling VT-d in the BIOS , does indeed allow this machine to cleanly reboot.

my fedora 19 hangs on shutdown 
attached:

    The exact kernel command-line used if not default. Typically from the bootloader configuration file (e.g. /boot/grub2/grub.cfg) or from /proc/cmdline
    A copy of the file /var/log/messages
    The output of the dmesg command: dmesg > dmesg.txt
        ideally after booting with systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
    The output of a systemd dump: systemctl dump > systemd-dump.txt
    The output of /usr/bin/systemd --test --system --log-level=debug > systemd-test.txt 2>&1

I tried disabling VT-D on my motherboard I think this is XD technology.
Intel DP35DP, Core 2 quad 6600.
I also tried adding /usr/lib/systemd/system-shutdown/kill-e1000e.sh
which executes 
modprobe -r e1000e
since some had reported a problem with the e1000e driver related to this.

I was getting a message about mei (intel management software)
I also tried adding to /etc/modprobe.d/blacklist.conf the lines
blacklist mei
blacklist mei_me
but I did not do dracut --force
This removed the mei message but it still didn't shutdown.

There was previously a message about GPU Lockup switching to software fbcon.
I also tried using the proprietary nvidia driver. This removed the fbcon error
but it still didn't shutdown.

There was also a message "not all DM devices detatched, 1 left".
but I didn't address this yet.

I think that with kernel option nomodeset it shuts down, it just doesn't
allow me to use the full resolution of my video card (which is useless)
and I tried to reset it in the display settings gui.
There may be a way to specify the modeset manually, but if this is done
incorrectly I will have no graphics.  If someone knows how to do this,
please tell me.


note the command "acpi" reports
No support for device type:  power_supply

kernel options 
apic, noapic, apm=allow_ints, apm=off, apm=power_off, apm=realmode_power_off, reboot=b
were suggested, so far all I have tried is
acpi=force apm=power_off reboot=force

Created attachment 837747 [details]
result of running acpitool

Created attachment 837748 [details]
result of running acpi

Created attachment 837749 [details]
dmesg

Created attachment 837750 [details]
/etc/default/grub

Created attachment 837751 [details]
/var/log/messages

Created attachment 837752 [details]
shutdown log

boot options
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0

save the following script as /lib/systemd/system-shutdown/debug.sh and make it executable:

#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro 

/http://freedesktop.org/wiki/Software/systemd/Debugging/#Diagnosing_Shutdown_Problems

Created attachment 837753 [details]
shutdown log




http://freedesktop.org/wiki/Software/systemd/Debugging/#Diagnosing_Shutdown_Problems

kernel options
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0


save the following script as /lib/systemd/system-shutdown/debug.sh and make it executable:

#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /

Created attachment 837754 [details]
systemctl dump

F17 was end of life on 7/30 thus is no longer maintained by the communtiy so you will need to install F20 ( which got released today ) and retest retry to see if you experience that problem.

updating the name of the bug reflecting it affects F19

Likely not relevant but with 3.12.6 shutdown issues with Acer laptops were fixed
due to commit 2ab0ff9b179aadf1f30f2dfa9db2b9404324e135
Date:   Wed Nov 27 15:19:25 2013 -0700

    PCI: Disable Bus Master only on kexec reboot
    
    commit 4fc9bbf98fd66f879e628d8537ba7c240be2b58e upstream.
    
    Add a flag to tell the PCI subsystem that kernel is shutting down in
    preparation to kexec a kernel.  Add code in PCI subsystem to use this flag
    to clear Bus Master bit on PCI devices only in case of kexec reboot.

Probably worth trying as 3.12.6 has hit updates-testing for F19 as well

this also affects fedora 20
note symptoms differ whether you are using nvidia or radeon graphics card.
could it be something to do with plymouth?

could someone please address this issue?  There are so many people having problems with simply shutting down fedora and other newer distros with new kernels, that this is really important.  For heaven's sake, I can't even shut off my computer.  It may have something to do with the e1000e driver.  I have had some success with

rmmod e1000e
poweroff

but this doesn't ALWAYS work.
I also did:

# yum -y install acpid
# service acpid start
# chkconfig acpid on

and added "acpi=force" to kernel boot options.
I am using uname -a
Linux ****** 3.13.4-200.fc20.x86_64 #1 SMP Thu Feb 20 23:00:47 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux


NOTE THIS STILL APPLIES TO FEDORA 20 current kernel.

The two hardware devices that could cause problems are:

product: uPD720201 USB 3.0 Host Controller [1912:14]
vendor: Renesas Technology Corp. [1912]
bus info: pci@0000:04:00.0
version: 03
width: 64 bits
clock: 33MHz
capabilities:
	Power Management,
	Message Signalled Interrupts,
	MSI-X,
	PCI Express,
	xhci,
	bus mastering,
	PCI capabilities listing
configuration:
	driver: xhci_hcd
	latency: 0
resources:
	irq: 18
	memory: e0100000-e0101fff
Ethernet interface
/0/100/19


product: 82566DC-2 Gigabit Network Connection [8086:294C]
vendor: Intel Corporation [8086]
bus info: pci@0000:00:19.0
logical name: em1
version: 02
serial: 00:1c:c0:1d:65:d4
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities:
	Power Management,
	Message Signalled Interrupts,
	bus mastering,
	PCI capabilities listing,
	ethernet,
	Physical interface,
	twisted pair,
	10Mbit/s,
	10Mbit/s (full duplex),
	100Mbit/s,
	100Mbit/s (full duplex),
	1Gbit/s (full duplex),
	Auto-negotiation
configuration:
	autonegotiation: on
	broadcast: yes
	driver: e1000e
	driverversion: 2.3.2-k
	duplex: full
	firmware: 1.3-0
	ip: 192.168.11.4
	latency: 0
	link: yes
	multicast: yes
	port: twisted pair
	speed: 1Gbit/s
resources:
	irq: 53
	memory: e0400000-e041ffff
	memory: e0424000-e0424fff
	ioport: 30e0(size=32)

dmesg reports these errors:

[    0.109774] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.109780] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    0.109785] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[    0.110799] acpi PNP0A03:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-7f] only partiall\
y covers this bridge



[    5.922225] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:1c:c0:1d:65:d4
[    5.922230] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    5.923724] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 6, PBA No: FFFFFF-0FF
[    5.923804] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \\
IGPO 1 (20131115/utaddress-251)
[    5.923812] ACPI: If an ACPI driver is available for this device, you should use it instead of t\
he native driver

[    5.853373] SELinux: initialized (dev sdb1, type ext4), uses xattr
[    5.868493] EXT4-fs (sdc1): warning: maximal mount count reached, running e2fsck is recommended
[    5.869330] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)
[    5.869340] SELinux: initialized (dev sdc1, type ext3), uses xattr
[ 




when it shuts down it reports
dracut Warning:  Killing all remaining processes
Cannot finalize remaining filesystems and devices, giving up

and then it hangs without shutting power off.
Could it have anything to do with the power supply which is compatible with haswell cpus?  the cpu is intel core 2 quad 6600.  the motherboard is intel dp35dp.

I originally suspected the video card as well.
VGA compatible controller
/0/100/1/0


product: Cape Verde XT [Radeon HD 7770 GHz Edition] [1002:683D]
vendor: Advanced Micro Devices, Inc. [AMD/ATI] [1002]
bus info: pci@0000:01:00.0
version: 00
width: 64 bits
clock: 33MHz
capabilities:
	Power Management,
	PCI Express,
	Message Signalled Interrupts,
	vga_controller,
	bus mastering,
	PCI capabilities listing,
	extension ROM
configuration:
	driver: radeon
	latency: 0
resources:
	irq: 51
	memory: d0000000-dfffffff
	memory: e0300000-e033ffff
	ioport: 2000(size=256)
	memory: e0360000-e037ffff

sync  && shutdown -f

hangs implying it is a kernel problem not systemd.

Partial solution:

shutdown -h -P now
does NOT work, but I think 
halt -p
always works.
So I can still not shut down the xfce window manager by the standard
shutdown menu, but I can shut down from the console.

I also made the modification:

added /etc/default/halt
garberw@electron> cat /etc/default/halt
# Default behaviour of shutdown -h / halt. Set to "halt" or "poweroff".
HALT=poweroff
INIT_HALT=POWEROFF
NETDOWN=yes
garberw@electron> 

and manpage downloaded from web:
attached

Created attachment 868007 [details]
/etc/default/halt    manpage

With the /etc/default/halt file as attached, console command "halt -p" solves this problem.
At least I tested it 5 times and it did.

Created attachment 868008 [details]
/etc/default/halt

/etc/default/halt
should be included as in debian/ubuntu installation.

Not a solution to the problem, but note that in Fedora /usr/sbin/halt is a symlink to /usr/bin/systemctl. IINM calling 'halt' is equivalent to 'systemctl halt'.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.13.5-100.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Solved problem with fedora 20 crashing on shutdown, at least in my case.
Solution was to add kernel option pci=nocrs

My best guess as to why this helps was that it has something to do with 
the e1000e driver in fedora, based on the logs / dmesg.

attached:
bug-report.txt (journalctl output)
acpidump
dmesg
dmidecode
etc_default_halt (added the contents of this file as /etc/default/halt; may help)
lspci

Created attachment 884247 [details]
result of running command acpidump

Created attachment 884248 [details]
result of running journalctl -k -b -l; excerpts of errors and solution to problem

Created attachment 884249 [details]
result of running dmesg

Created attachment 884250 [details]
result of running dmidecode

Created attachment 884251 [details]
result of running lspci

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.14.4-100.fc19.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20.

If you experience different issues, please open a new bug report for those.

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.