12.1: shutdown problem and acpi?

English Hardware
#1

I’ve seen other threads about shutdown problems, and none of the solutions I’ve seen suggested have worked for me. I’ve tried “/sbin/shutdown -h -P now”. I’ve tried “/sbin/shutdown -H -P now”, which “man shutdown” suggests may be the correct version. I’ve tried switching to systemv. Still, when I shutdown the system, or try to, I end up with computer and monitor still powered, with the last line on the monitor saying “system halted” or “powering down,” depending on which version of the command was used. (“Powering down” may not be the exact quote; it’s from memory.)

I feel like it’s 1995! All I need to make the experience complete is a message stating, “It is now safe to turn off your computer.”

I assume this has to be related to my hardware, since the solutions that appear to have worked for others aren’t working for me. More specifically, I suspect it’s related to the inability to boot OpenSUSE 12.1 32 (either the DVD or the installed configuration) on this machine unless I use the “acpi=off” option. Otherwise, the boot process stalls at the line “:nodes with udev”.

The computer is about six years old, and wasn’t exactly a powerhouse when new. It’s an emachines T5212, with Pentium D 805 processor (2.66 GHz) and ATI Radeo Xpress 200 video, 2 GB RAM installed.

In the past, this machine has run OpenSUSE 10.3, several variants of Ubuntu, several versions of Puppy Linux, and the proprietary OS that came installed on it (which it still dual boots). There have probably been a few other distros running on live CDs as well, but I don’t recall the details. Until now, getting the machine to power off at shutdown has never been a problem.

Obviously, it can be done, and I feel certain that OpenSUSE 12.1 can do, if I can simply determine what I need to reconfigure. But at the moment, I’m at my wit’s end. I’ve tried everything I can think of (not much) and all the suggestions I’ve found with a lot of searching. If anyone can point me in the direction of information I’ve missed or overlooked, I will be very appreciative.

And I’ll be happy to provide more information about my hardware, if anyone wants it. I’m just reluctant to start slinging miscellaneous and probably irrelevant data.

For what it’s worth, my experience is that acpi simply will not start with systemv, neither from the command line nor from Yast. The /proc/acpi directory is missing. Now that I’m back with systemd, acpi does run, but I wonder if it’s doing anything.

As is probably obvious, I have some Linux experience, but what I know is insignificant compared to what I don’t know! I’m not afraid of the command line, but sometimes I’m wary.

Thanks for any genuine suggestions!

#2

So I am pretty sure by using the kernel load option acpi=off, you are disabling the ability to automatically shutdown. There are many acpi settings in the kernel. ACPI or Advanced Configuration and Power Interface, is a specification that defines recognition for hardware, motherboards and other devices. So, I have pulled out the generic ACPI settings that I know of. Imagine that you might find a different setting, that lets your computer boot without turning it all off, but I am not sure just what hardware device is the problem. Here is that listing:

    **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.

Now trying all of this stuff, one at a time, will take a long time and could mean many reboots and lockups. You might look up the exact machine by model and see if anything other than acpi=off has been used with it to get a better direction to go.

Thank You,

#3

Thanks, James! As you say, that’s a long list, but a few have already been eliminated as possibilities. In time, maybe I can find one that works. It’s good to have something to work with.

Question: is it possible that, having installed 12.1 without ACPI turned off, some necessary components were not installed? Package manager doesn’t indicate that I acpi components are missing. And, as I said, it appears to be running when I boot with systemd.

#4

So it modifies how the kernel functions and not sure if it changes any kernel modules. As for YaST, a few thing loaded may not work perhaps. For instance, I wonder how well CPU speed control might work with acpi=off set. You can check your loaded kernel modules with my bash script called skim: S.K.I.M. - SuSE Kernel Installed Modules - A lsmod replacement- Creates Alphabetized Module Listing - Blogs - openSUSE Forums

Thank You,

#5

On 2012-02-02 03:36, robbh wrote:

> For what it’s worth, my experience is that acpi simply will not start
> with systemv, neither from the command line nor from Yast. The
> /proc/acpi directory is missing. Now that I’m back with systemd, acpi
> does run, but I wonder if it’s doing anything.

Do you mean that systemd runs with acpi enabled, but systemv doesn’t?
That’s a bug you should report in Bugzilla.

–
Cheers / Saludos,

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

#6

Unfortunately, I don’t know enough to answer your question!. Yes the daemon appears to be running, after being enabled in Yast. But James’s script shows that no acpi modules have been loaded. Neither acpi nor acpi_cpufreq can be loaded by modprobe.

I can say that I found it impossible to start acpid with Yast or with “/etc/init.d/acpi start” under systemv. But that was because either method tests for the presence of /proc/acpi/. I don’t think I ever tried running /sbin/acpid, but I suspect that would have the same result I see now with systemd: acpid is “running” but not functional.

#7

On 2012-02-02 22:46, robbh wrote:
>
> robin_listas;2436773 Wrote:
>>
>> Do you mean that systemd runs with acpi enabled, but systemv doesn’t?
>> That’s a bug you should report in Bugzilla.
>>
>
> Unfortunately, I don’t know enough to answer your question!. Yes the
> daemon appears to be running, after being enabled in Yast. But James’s
> script shows that no acpi modules have been loaded. Neither acpi nor
> acpi_cpufreq can be loaded by modprobe.

The only test you need to know that acpi is active or not is the presence
or absence of /proc/acpi/

The question I asked is very simple: if you disabled acpi using the kernel
boot parameter, can you boot with systemd or systemv? If one of the two
does not boot, report that as bug.

–
Cheers / Saludos,

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

#8

Again, I apologize for my lack of expertise. Because of my ignorance the question you asked this time (quoted above) sounds to me like a very different question from the one you asked the first time. At least, this time I think (hope) I understand what you’re asking.

Yes, I can boot OpenSUSE 12.1 on this computer, using either systemv or systemd, if and only if I use the acpi=off parameter.

#9

Never mind!

Whatever the problem is, it is NOT limited to OpenSUSE. As I mentioned earlier, other distros have booted successfully, without having to switch acpi off, and have been able to poweroff the computer. But they weren’t current versions; the most recent was Ubuntu 10.4 or a derivative. I’ve just tried live CDs of Fedora 16 and Zubuntu 11.10, both current versions. Neither one will boot with the default acpi settings. So I’m inclined to think my problem may have to do with recent changes in the kernel.

In any case, thanks for the help!

Thanks for

#10

On 2012-02-03 01:16, robbh wrote:

> Yes, I can boot OpenSUSE 12.1 on this computer, using either systemv or
> systemd, if and only if I use the acpi=off parameter.

Ah, then nothing to report. I had hopes.

–
Cheers / Saludos,

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

#11

On 2012-02-03 02:06, robbh wrote:
> So I’m inclined to think my problem may have to do with recent
> changes in the kernel.

Ah. Then you’d have to try older versions of openSUSE, even if no longer
supported. If an old version boots and new don’t, then the issue can also
be reported in Bugzilla and hope they solve it.

–
Cheers / Saludos,

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

#12

Seriously? I neither expect nor intend to ask for support for what’s obviously obsolete hardware. I think it’s time for me to recognize that I need to forget about mainstream distributions for this computer and start looking for a “lightweight distro for older computers.”

I like OpenSUSE and I’ll probably try it again in the future, on more appropriate hardware. And I do appreciate the help that’s been offered. I think I’m done here for now.

#13

On 2012-02-05 17:16, robbh wrote:
> Seriously?

Yes, seriously. A regression is a regression. Working slow is not the same
as not working at all.

–
Cheers / Saludos,

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

#14

robbh, it is OK to ask for help and if the problem is a bug, its OK to suggest you post a bug report and it is really OK to ask for help here for any hardware that is within the minimum recommended hardware for openSUSE. Here are the requirements, from which if you system matches, it is suggested that it will and can work.

The following requirements should be met to ensure smooth operation of openSUSE 11.4 & openSUSE 12.1

  • Pentium* III 500 MHz or higher processor (Pentium 4 2.4 GHz or higher or any AMD64 or Intel* EM64T processor recommended)
  • Main memory: 512 MB physical RAM (1 GB recommended)
  • Hard disk: 3 GB available disk space (more recommended)
  • Sound and graphics cards: supports most modern sound and graphics cards, 800 x 600 display resolution (1024 x 768 or higher recommended)
  • Booting from CD/DVD drive or USB-Stick for installation, or support for booting over network (you need to setup PXE by yourself, look also at Network install) or an existing installation of openSUSE, more information at Installation without CD

The GRUB bootloader co-operates with other operating systems on the same machine. openSUSE can be installed on one free harddisk partition, while preserving existing installations on other partitions.

Further, if it does not, you should always consider posting a bug report.no matter what though, we are to help, at least most of us are. Sometimes we run out of ideas and go silent, leaving others to make noise, but hopefully we are better here than no help on the subject at all.

Thank You,

#15

Hi, I’m having the same issue on SuSe 12.1
I did a fresh install on a DELL Vostro 1700 and all was right (except for wifi and vga drivers, but that was fixed)…
There was a kernell update, and then this issue appeared…
Any help? I’m kinda new on this, but I’m not affraid of some hard work on this, thanks to all!

#16

For what its worth, I have the similar issues.

I boot with acpi enabled, and have entries in “/proc/acpi”

Logging into KDE, then logging out using Restart will reboot the machine. However, Shutdown will not turn off the machine.

At the command line, using “shutdown”, “shutdown -p”, or “halt”, none turns off the machine. Always, I must hold down the power button 5 seconds to force the machine off, manually. I’ve tried the same command line commands from runlevel 3, same results.

This is a machine well above the minimum specs previously posted. Oh, and I should also post that this has worked fine (In openSuses 10.1, 10.3, 11.2, and 11.4) before upgrading to 12.1.

Machine: HP Pavilion dv8000
CPU: Intel T2400 (duel-core 1.8ghz)
Memory: 1.5 GB

Using KDEs “sysinfo:/” URL, it reports the CPUs currently running speed at 1ghz and occasionally hitting 1.8ghz and going back, so ACPI is at least partly working. (It is what controls CPU throttling, right?)

But if this is indeed a kernel bug, I don’t expect much that Suse can do about it.

#17

On 2012-05-06 20:56, gre gyu wrote:

> But if this is indeed a kernel bug, I don’t expect much that Suse can
> do about it.

On the contrary - but you have to report in Bugzilla.

–
Cheers / Saludos,

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