System doesn't shutdown.

Hi,
from the date I had the last kernel update, shutting down system fails.
These are the messages I can read disabling splash screen:


Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Unmounting file systems.
Unmounted /sys/fs/fuse/connections.
Unmounted /dev/mqueue
Unmounted /sys/kernel/debug.
Unmounted /dev/hugepages.
Unmounted /sys/kernel/security.
Disabling swaps.
Detaching loop devices.
Detaching DM devices.
  206.224920] Power down.

… and nothing more happens, I can hear that the pc is still on and the monitor shows the same messages.

I’ve tried with systemV but I got the same problem.
I would be very grateful if you could help me.
Tell me wich log files do you need and I’ll try to do my best.

Thanks in advance.

marasciallo

On 2012-06-17 15:56, marasciallo wrote:
>
> Hi,
> from the date I had the last kernel update, shutting down system fails.
> These are the messages I can read disabling splash screen:
>
> Code:
> --------------------
>
> Sending SIGTERM to remaining processes…
> Sending SIGKILL to remaining processes…
> Unmounting file systems.
> Unmounted /sys/fs/fuse/connections.
> Unmounted /dev/mqueue
> Unmounted /sys/kernel/debug.
> Unmounted /dev/hugepages.
> Unmounted /sys/kernel/security.
> Disabling swaps.
> Detaching loop devices.
> Detaching DM devices.
> 206.224920] Power down.
> --------------------
>
>
> … and nothing more happens, I can hear that the pc is still on and
> the monitor shows the same messages.
>
> I’ve tried with systemV but I got the same problem.
> I would be very grateful if you could help me.
> Tell me wich log files do you need and I’ll try to do my best.

The system is doing what it should, but system is not powered down. One
more test would be to just log out from your graphics session, switch to VT
1, log as root and issue “halt” there. Huh, no, for 12.1 it is another
command, what was it…

release notes

halt -p or shutdown -h now

If that doesn’t work, you need to create a bugzilla.

Also, test if the factory version can power down your machine. If not,
bugzilla.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Hi robin, thank you for your fast reply!

I don’t know what does it means to “switch to VT 1”, can you please explain me what I have to do?

I tried to login has root and issued “halt -p” but I got the same problem.

I also tried to boot from a usb live image of 12.1 downloaded two month ago and shutting down works well.

marasciall, why not tell us more about your computer such as brand and model and what openSUSE version and desktop that you use? It sounds like a ACPI problem and there are kernel startup options one could try.

    acpi=        [HW,ACPI,X86]
            Advanced Configuration and Power Interface
            Format: { force | off | strict | noirq | rsdt }
            force -- enable ACPI if default was off
            off -- disable ACPI if default was on
            noirq -- do not use ACPI for IRQ routing
            strict -- Be less tolerant of platforms that are not
                strictly ACPI specification compliant.
            rsdt -- prefer RSDT over (default) XSDT
            copy_dsdt -- copy DSDT to memory

            See also Documentation/power/pm.txt, pci=noacpi

    acpi_apic_instance=    [ACPI, IOAPIC]
            Format: <int>
            2: use 2nd APIC table, if available
            1,0: use 1st APIC table
            default: 0

    acpi_backlight=    [HW,ACPI]
            acpi_backlight=vendor
            acpi_backlight=video
            If set to vendor, prefer vendor specific driver
            (e.g. thinkpad_acpi, sony_acpi, etc.) instead
            of the ACPI video.ko driver.

    acpi.debug_layer=    [HW,ACPI,ACPI_DEBUG]
    acpi.debug_level=    [HW,ACPI,ACPI_DEBUG]
            Format: <int>
            CONFIG_ACPI_DEBUG must be enabled to produce any ACPI
            debug output.  Bits in debug_layer correspond to a
            _COMPONENT in an ACPI source file, e.g.,
                #define _COMPONENT ACPI_PCI_COMPONENT
            Bits in debug_level correspond to a level in
            ACPI_DEBUG_PRINT statements, e.g.,
                ACPI_DEBUG_PRINT((ACPI_DB_INFO, ...
            The debug_level mask defaults to "info".  See
            Documentation/acpi/debug.txt for more information about
            debug layers and levels.

            Enable processor driver info messages:
                acpi.debug_layer=0x20000000
            Enable PCI/PCI interrupt routing info messages:
                acpi.debug_layer=0x400000
            Enable AML "Debug" output, i.e., stores to the Debug
            object while interpreting AML:
                acpi.debug_layer=0xffffffff acpi.debug_level=0x2
            Enable all messages related to ACPI hardware:
                acpi.debug_layer=0x2 acpi.debug_level=0xffffffff

            Some values produce so much output that the system is
            unusable.  The "log_buf_len" parameter may be useful
            if you need to capture more output.

    acpi_display_output=    [HW,ACPI]
            acpi_display_output=vendor
            acpi_display_output=video
            See above.

    acpi_irq_balance [HW,ACPI]
            ACPI will balance active IRQs
            default in APIC mode

    acpi_irq_nobalance [HW,ACPI]
            ACPI will not move active IRQs (default)
            default in PIC mode

    acpi_irq_isa=    [HW,ACPI] If irq_balance, mark listed IRQs used by ISA
            Format: <irq>,<irq>...

    acpi_irq_pci=    [HW,ACPI] If irq_balance, clear listed IRQs for
            use by PCI
            Format: <irq>,<irq>...

    acpi_no_auto_ssdt    [HW,ACPI] Disable automatic loading of SSDT

    acpi_os_name=    [HW,ACPI] Tell ACPI BIOS the name of the OS
            Format: To spoof as Windows 98: ="Microsoft Windows"

    acpi_osi=    [HW,ACPI] Modify list of supported OS interface strings
            acpi_osi="string1"    # add string1 -- only one string
            acpi_osi="!string2"    # remove built-in string2
            acpi_osi=        # disable all strings

    acpi_pm_good    [X86]
            Override the pmtimer bug detection: force the kernel
            to assume that this machine's pmtimer latches its value
            and always returns good values.

    acpi_sci=    [HW,ACPI] ACPI System Control Interrupt trigger mode
            Format: { level | edge | high | low }

    acpi_serialize    [HW,ACPI] force serialization of AML methods

    acpi_skip_timer_override [HW,ACPI]
            Recognize and ignore IRQ0/pin2 Interrupt Override.
            For broken nForce2 BIOS resulting in XT-PIC timer.

    acpi_sleep=    [HW,ACPI] Sleep options
            Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
                  old_ordering, s4_nonvs, sci_force_enable }
            See Documentation/power/video.txt for information on
            s3_bios and s3_mode.
            s3_beep is for debugging; it makes the PC's speaker beep
            as soon as the kernel's real-mode entry point is called.
            s4_nohwsig prevents ACPI hardware signature from being
            used during resume from hibernation.
            old_ordering causes the ACPI 1.0 ordering of the _PTS
            control method, with respect to putting devices into
            low power states, to be enforced (the ACPI 2.0 ordering
            of _PTS is used by default).
            nonvs prevents the kernel from saving/restoring the
            ACPI NVS memory during suspend/hibernation and resume.
            sci_force_enable causes the kernel to set SCI_EN directly
            on resume from S1/S3 (which is against the ACPI spec,
            but some broken systems don't work without it).

    acpi_use_timer_override [HW,ACPI]
            Use timer override. For some broken Nvidia NF5 boards
            that require a timer override, but don't have HPET

    acpi_enforce_resources=    [ACPI]
            { strict | lax | no }
            Check for resource conflicts between native drivers
            and ACPI OperationRegions (SystemIO and SystemMemory
            only). IO ports and memory declared in ACPI might be
            used by the ACPI subsystem in arbitrary AML code and
            can interfere with legacy drivers.
            strict (default): access to resources claimed by ACPI
            is denied; legacy drivers trying to access reserved
            resources will fail to bind to device using them.
            lax: access to resources claimed by ACPI is allowed;
            legacy drivers trying to access reserved resources
            will bind successfully but a warning message is logged.
            no: ACPI OperationRegions are not marked as reserved,
            no further checks are performed.

These can be added to your openSUSE startup line or typed in just before you press enter to startup openSUSE in the Grub menu. I just posted the whole lot until I know more about your setup.

Thank You,

marasciall, why not tell us more about your computer such as brand and model and what openSUSE version and desktop that you use?

Sorry, you’re right:shame:

ASUS P52F , I use 12.1 64bit

On 2012-06-17 16:36, marasciallo wrote:
> I don’t know what does it means to “switch to VT 1”, can you please
> explain me what I have to do?

ctrl-alt-f1


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

ctrl-alt-f1

Ok thanks, but the result is the same.:frowning:

jdmcdaniel3 marasciall, why not tell us more about your computer such as brand and model and what openSUSE version and desktop that you use? It sounds like a ACPI problem and there are kernel startup options one could try.

I don’t know how to use them, if you have any suggestion or I can try something, tell me.

Here are some potential kernel load options you can try. You can try each command, one per openSUSE startup from the Grub OS selection menu where you can type in any kernel load option before you press the enter key.

You cant try the following options, one each time, they are ordered from more aggressive, likely to work to less aggressive but less functions disabled:

  • acpi=off
    , this one should completely disable acpi. It’s the most likely to work, but you will lose all your power management. - **pci=noacpi **
    , this will make the kernel to ignore acpi for pic scanning and irq assignment. - acpi=noirq
    , this will only disable irq assignment through acpi. - irqpoll
    , this will make the kernel poll for all unattended irq interruptions. - noapic
    , this will make the kernel ignore the APIC. - Based on other questions that suggest some ACPI settings, open terminal and try sudo shutdown -h
    to see whether the shutdown in console text display offers any hintsor if sudo shutdown --force works.

You can enter more than one at a t time, but you are trying to find which one that works or helps.

Thank You,

Same problem slightly different reporting:

My install has been stable and shut down worked correctly up until I installed the last SUSE update which included a kernel update . I am using the standard SUSE supplied KDE release (I do not use any special updated OS or Desktop repositories). There have been no system hardware changes since April.

OS: Linux 3.1.10-1.13-desktop x86_64
System: openSUSE 12.1 (x86_64)
KDE: 4.7.2 (4.7.2) “release 5”
i5-2500K Sandy Bridge LGA 1155 3_3 GHz (not overclocked - yet)
MSI Z68MA-ED55 (B3) LGA 1155 Intel Z68 Micro ATX Intel Motherboard
12 Gig (4 sticks total - 2x4 Gig and 2x2 Gig) G_SKILL DDR3 1600 - PC3 12800 XMP


Disabling swaps.
Detaching loop devices.
Detaching DM devices.
  312.336287] Disabling IRQ #16.

Now, after doing the online update the shutdown hangs forever and there is no power off.

I’m posting here to add more information about this problem, that is a brand new one for me. Now I have to wait until I’m sure it hangs, then push and hold the case power button to complete the shutdown power off.

Are you using built-in graphics? Would you consider a much newer kernel to try (leaving your old there so it can still be used)? Have you tried using the kernel load option nomdoeset which is normally used when graphics does not work, but it might be interesting to see if it makes any difference.

Thank You,

This new kernel is the problem.
See bug reports: #768483, #764864, …

regards,
Hendrik

So if you mean latest as in 3.1.10, this kernel has been declared as being end of life (EOL). In such a case, I might suggest going for kernel 3.4.4. You can use my bash script S.A.K.C. to install it if you like: S.A.K.C. - SUSE Automated Kernel Compiler - Version 2.75 - Blogs - openSUSE Forums

Thank You,

… therefore downgrade to kernel 3.1.10-1.9

I apologize for the slow reply (life gets in the way sometimes :slight_smile: ). First without changing anything, yesterday I had a complete shutdown power off, which was not repeatable (it mostly would hang and never power down the hardware). This is a really, really bad sign for testing. I avoided any SUSE updates while testing and exploring the problem, except I looked at them and today found a sysvinit update to cure a shutdown deadlock. I updated it and have not had any power off failures since.

The strange thing is Yast2 Software Management:
Repository, @System, Kernel Desktop 3.1.10-1.13.1 (3.1.10-1.9.1) is now shown as the available update in red as what appears to be a version downgrade to 3.1.10-1.9.1? Since updating to a version downgrade does not appear to be automatic when updates are run, is this some Yast2 version numbering/compare/sorting_error/whatever, or is SUSE really recommending I downgrade the desktop kernel version (now that the original power down problem appears to be fixed or are there other problems lurking in the new desktop kernel)?

Thank you for your help.

On 2012-06-26 17:26, Mike unique wrote:

> The strange thing is Yast2 Software Management:
> Repository, @System, Kernel Desktop 3.1.10-1.13.1 (3.1.10-1.9.1) now is
> now shown as the available update in red as what appears to be a version
> downgrade to 3.1.10-1.9.1? Since updating to a version downgrade does
> not appear to be automatic when updates are run, is this some Yast2
> version numbering/compare/sorting_error/whatever, or is SUSE really
> recommending I downgrade the desktop kernel version (now that the
> original power down problem appears to be fixed)?

I think that the kernel has been removed from the repo, so that you do not
update to it.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On Tue, 26 Jun 2012 19:53:06 +0000, Carlos E. R. wrote:

> I think that the kernel has been removed from the repo, so that you do
> not update to it.

Yep. A new kernel that addresses this issue is supposed to be on its way
“soon”.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Thanks for the explanation about the Yast2 behavior. All my questions have been answered. Thank you.

I forgot to answer one question, yes I’m using the internal Intel HD Graphics 3000 video.

I have the same problem after last update, but I’m using different hardware!

after the last update, the easiest way found to switch this OS system off is :-

kdesu -c ‘shutdown -h +0’ # in the Yast, Login Screen, Shutdown tap, under Halt:

and for reboot

kdesu -c ‘shutdown -r +0’ # in the Yast, Login Screen, Shutdown tap, under Reboot:

with these cmds at least I’m not left at a terminal prompt after putting in the
root password

Phenom II X4 940; ATI Radeon HD 3200 Graphics; fglrx (12.4)
3.4.3-30-desktop x86_64 (64 bit); KDE 4.8.4 Distro
openSUSE 12.1 (x86_64) VERSION = 12.1 + Tumbleweed

sorry, I’ve got my foot it my mouth again, ignore the above