• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[[wieder un]gelöst] PC schaltet nach Herunterfahren nicht ab

Fritzmartin

Fritzmartin

Hallo,

ich habe auf meinem Rechner (Athlon XP 2200, Gigabyte GA-7ZMMH mit BIOS Rev. 11b) Windows XP Home SP2 in der primären Partition und Suse Linux 10.3 mit Gnome Desktop in der erweiterten Partition installiert. Von Windows aus kann ich den Rechner normal herunterfahren. Wenn ich aber bei Linux auf den Button "Herunterfahren" klicke, startet das BIOS den Rechner erneut. Ich muss dann warten, bis der Auswahlschirm von GRUB erscheint, und dann den Ausschalttaster am Rechner betätigen. Vermutlich schreibt Suse einen falschen Wert in das entsprechende Register der RTC. Wie läßt sich das Problem beheben?
 
longman

longman

Schaltet er ab, wenn Du in einer su-Konsole halt eingibst ?

Ich meine hier war vor einigen Wochen mal ein Thread, der genau das Thema hatte, doch
leider kann ich mich nicht mehr genau erinnern. Ich meine fast, das war mit einem Patch zu
lösen, aber wie bei den Lottozahlen.. ohne Gewähr.
 
OP
Fritzmartin

Fritzmartin

Sowohl nach "halt" als auch nach "shutdown -h now" fährt der Rechner wieder hoch.
Ich habe noch eine aktuelle Live-DVD von Fedora eingelegt: Nach starten der Distribution und anschließendem anklicken des Shutdown-Buttons fährt der Rechner auch wieder hoch; da es sich dabei jedoch um kein Betriebssystem auf der Festplatte handelt, hat das nicht unbedingt etwas zu bedeuten.
 
OP
Fritzmartin

Fritzmartin

Hallo,

danke für den ACPI-Tipp. Leider macht der Rechner nach "Herunterfahren" bei voran gegangener Bootoption "noacpi" einen Reboot, bei voran gegangenem "acpi=off" bleibt der Rechner mit dem Boot-/Abmeldeschirm stehen. Erst ein Druck auf den Taster am Rechnergehäuse bewirkt etwas - nämlich auch einen Reboot.

Ich habe daraufhin unter dem Stichwort "ACPI" bei Wikipedia nachgeschaut: Dort wird erwähnt, dass die Motherboards Tabellen und Routinen für das Betriebssystem bereitstellen, vorzugsweise für Windows. Da Windows sich aber offenbar nicht immer an die fest gelegten Regeln hält, und manche Boardhersteller ACPI nicht für andere Betriebssysteme wie Linux testen, kommt es - wie in meinem Fall - zu Problemen.

Die Lösung dieses Problems wäre dann [ nur (?) ] Programmierung in der ACPI Source Language...

Fazit: Es handelt sich offenbar um keinen Linux-Bug. Auch tröstlich.
 
OP
Fritzmartin

Fritzmartin

Nein, auch acpi=force führt nach dem herunterfahren zu einem Reboot. Die unterschiedlichen Erfahrungen von Euch mit den einzelnen Bootoptionen hängen wohl mit den jeweiligen Motherboards - genauer: BIOS und Chipsatz - zusammen.
Dennoch danke für die Tipps.
 
OP
Fritzmartin

Fritzmartin

Mittlerweile habe ich den Hinweis bekommen, dass ich doch mal den Kernel ohne die Option APM ( den Vorgänger von ACPI ) neu kompilieren sollte, da sich möglicherweise APM und ACPI im Kernel ins Gehege kommen würden; booten des jetzigen Kernels mit Bootoption "noapm" bzw. "apm=off" brachte jedenfalls keinen Erfolg.
Es bleibt spannend...
 
OP
Fritzmartin

Fritzmartin

Hallo,

an diesem Wochenende habe ich mich ans kompilieren gewagt: Ich denke, ich habe alle sinnvollen Möglichkeiten ausprobiert, aber es hat nichts geholfen. Der entsprechende (letzte) Auszug aus der .config sieht so aus:

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""
CONFIG_SUSPEND_SMP=y

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_SLEEP is not set
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_DOCK=m
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
# CONFIG_ACPI_CUSTOM_DSDT_INITRD is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=m
CONFIG_ACPI_SBS=m
# CONFIG_APM is not set

Der längste Durchlauf mit make dauerte ca. 2 1/2 Stunden ( Athlon XP 2200+ / 1 GiB RAM ), der kürzeste wenige Minuten.
 
OP
Fritzmartin

Fritzmartin

Mittlerweile habe ich mich an die DSDT gewagt. Erstellen der dazu notwendigen DSDT.aml wie folgt (zu der Zeit hatte ich noch Ubuntu 8.04; jetzt bin ich bei SuSE 11):

Code: 
sudo acpidump -t DSDT -o dsdt.dat -b
iasl -d dsdt.dat

ergab folgende Meldungen:
Intel ACPI Component Architecture
AML Disassembler version 20061109 [May 16 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

Loading Acpi table from file dsdt.dat
Acpi table [DSDT] successfully installed and loaded
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
.........................................................................................................................................................................................
Parsing completed
Disassembly completed, written to "dsdt.dsl"

Code: 
iasl -sa dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20061109 [May 16 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

dsdt.dsl 2346: Method (STM, 0, Serialized)
Warning 1086 - ^ Not all control paths return a value (STM_)

dsdt.dsl 2919: Method (_WAK, 1, NotSerialized)
Warning 1079 - ^ Reserved method must return a value (_WAK)

ASL Input: dsdt.dsl - 3004 lines, 104022 bytes, 1234 keywords
AML Output: dsdt.aml - 10315 bytes 414 named objects 820 executable opcodes

Compilation complete. 0 Errors, 2 Warnings, 0 Remarks, 344 Optimizations

Für die zweite Warnung gab es im Internet diesen Vorschlag:

Return(Package(0x02){0x00, 0x00})

Aus Plausibilitätsgründen habe ich ihn auch für die erste Warnung verwendet. Die Anweisung wurde jeweils unmittelbar vor der letzten schließenden Klammer der betreffenden Methode eingefügt. Ein erneuter Compilerdurchlauf war dann einwandfrei:

Code: 
iasl -sa dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20061109 [May 16 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

ASL Input: dsdt.dsl - 3007 lines, 104127 bytes, 1236 keywords
AML Output: dsdt.aml - 10327 bytes 414 named objects 822 executable opcodes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 348 Optimizations

Ich habe mutigerweise für

Code: 
mkinitrd ... -a DSDT.aml

die bestehende initrd verändert.

Beim Booten ergab ein Auszug aus dmesg für den vorherigen Zustand:

ACPI: Checking initramfs for custom DSDT
Parsing all Control Methods:
Table [DSDT](id 0001) - 419 Objects with 36 Devices 106 Methods 26 Regions
tbxface-0598 [00] tb_load_namespace : ACPI Tables successfully acquired

Mit der veränderten DSDT ergab sich:

ACPI: Checking initramfs for custom DSDT
ACPI: Found DSDT in DSDT.aml.
ACPI: Override [DSDT- VIA_K7], this is unsafe: tainting kernel
ACPI: Table DSDT replaced by host OS
ACPI: DSDT 00000000, 2857 (r1 VIA VIA_K7 1000 INTL 20061109)
ACPI: DSDT override uses original SSDTs unless "acpi_no_auto_ssdt"Parsing all Control Methods:
Table [DSDT](id 0001) - 419 Objects with 36 Devices 106 Methods 26 Regions
tbxface-0598 [00] tb_load_namespace : ACPI Tables successfully acquired

Leider schaltete sich Susie auch nach dieser Modifikation beim herunterfahren nicht ab.
Wie angedeutet hatte ich schon unter Ubuntu 8.04 diese DSDT für die initrd verwendet. Dabei tauchte beim selben Bootvorgang dreimal die Meldung "Checking Batterie-Status" oder so auf. Außerdem startete die grafische Oberfläche mit reduzierter Auflösung; deshalb hatte ich erst heute unter Susie den Test gewagt, der erfreulicherweise ohne solch seltsamen Effekte ablief.

Es bleibt herauszufinden, ob die Modifikation der DSDT in beiden Fällen durch den richtigen Eintrag erfolgte, oder was ich sonst noch unternehmen könnte - abgesehen vom Kauf eines anderen Motherboards...
 
OP
Fritzmartin

Fritzmartin

Heute habe ich zufällig den "Abschalten"-Button von (mittlerweile) SuSE 11.0 gedrückt. Überraschenderweise blieb der PC ausgeschaltet. Ich habe das noch viermal wiederholt - es blieb dabei.
Offenbar war bei den vorgenommenen Updates auch eines dabei, das sich auf ACPI ausgewirkt hat. Da ich keinen Hinweis darauf bei den Aktualisierungen gefunden hatte, kann ich leider keine Tipps geben, wie sich das Problem bei anderen Leidensgenossen beheben lässt.
 
OP
Fritzmartin

Fritzmartin

SuSE hat es gegeben, SuSE hat es genommen...

Am 19.09. gab es ein neues Update für SuSE 11.0: uvcvideo-kmp-pae. Seitdem schaltet der Rechner trotz anklicken des Buttons "Ausschalten" nicht mehr ab, sondern bootet erneut.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben