Lüftersteuerung nach Ruhezustand

frankqn · 11 Juli 2013

Hallo,

erwacht mein System aus dem Ruhezustand, drehen alle Lüfter mit voller Geschwindigkeit, werden also nicht mehr geregelt. Meine Recherche ergab die fehlende Datei /usr/lib/pm-utils/sleep.d/80acpi-fan. Das kann aber nicht die einzige Ursache sein, denn das Erstellen dieser Datei (aus älterem pm-utils) bewirkt keine Änderung. Was kann man noch tun?

openSUSE 12.3 > Tumbleweed

Jägerschlürfer · 11 Juli 2013

könnte ähnliches wie hier sein,...
http://www.linux-club.de/viewtopic.php?f=29&t=118012

frankqn · 11 Juli 2013

Die Temperatur wird bei mir eher niedriger, da ja alle Propeller voll aufdrehen.

Was ich nicht verstehe: was hat das OS überhaupt an den Lüftern zu schaffen, wenn das doch über PWM im BIOS geregelt wird, zumindest der CPU-Lüfter? Manchmal, nach einem Reboot muss ich sogar den Rechner erst komplett ausschalten, damit mein Board wieder die Kontrolle über die Lüfter bekommt. Das heisst manchmal wollen die Lüfter sogar nach einem Reboot weiter voll laufen.

josef-wien · 12 Juli 2013

Prinzipiell kannst Du die Lüftersteuerung entweder vom BIOS oder von fancontrol (aus dem Paket sensors) vornehmen lassen (beides gemeinsam würde ich nicht tun, letzteres ist nicht bei jedem mainboard möglich). Je nach den BIOS-Fähigkeiten ist eine der beiden Möglichkeiten die bessere Wahl. Wenn das BIOS die Arbeit machen soll, darf die Datei /etc/fancontrol nicht vorhanden sein (bzw. der Dienst fancontrol.service nicht aktiv sein).

RME · 12 Juli 2013

Hallo,

Teste folgendes:

(als root)

Code:

touch /usr/lib/systemd/system-sleep/99fancontrol
chmod 755 /usr/lib/systemd/system-sleep/99fancontrol

Die Datei "99fancontrol" mit einem Editor (als user mit root Rechten) öffnen

Code:

kdesu kwrite /usr/lib/systemd/system-sleep/99fancontrol

und folgenden Code einfügen:

Code:

#!/bin/sh

case "$1" in
 hibernate|suspend)
  # Stopping is not required.
  ;;
 thaw|resume)
   for k in /sys/class/thermal/cooling_device*/cur_state
     echo -n 0 > $k
     sleep 2
   done
  ;;
 *) exit $NA
  ;;
esac

exit 0

und abspeichern.

Edit: (Dank an josef-wien)

Code:

   for k in /sys/class/thermal/cooling_device*/cur_state; do

Die Idee (Code von mir etwas abgeändert) >>> https://bugzilla.redhat.com/show_bug.cgi?id=895276 (Comment 11)

----------

Variante:

http://askubuntu.com/questions/2872...se-after-system-wakeup-in-newly-install-13-04

Code:

touch /etc/pm/sleep.d/99fancontrol
chmod 755 /etc/pm/sleep.d/99fancontrol

Code:

#!/bin/sh

case "$1" in
 hibernate|suspend)
  # Stopping is not required.
  ;;
 thaw|resume)
 for k in /sys/devices/virtual/thermal/cooling_device*/cur_state; do
   echo -n 0 > $k
   sleep 2
 done
  ;;
 *) exit $NA
  ;;
esac

exit 0

(Unterschied: der Ort von "99fancontrol" und "cur_state")

Ich vermute dass das eigentliche Problem auf dem Motherboard zu finden wäre (gibts ein BIOS Update?).

Gruss,
Roland

frankqn · 12 Juli 2013

Roland,
Das Skript bewirkt an beiden Speicherorten nichts. Mein BIOS ist aktuell, aber daran liegt es wohl auch nicht, wenn es mit anderen OS wie z. B. openSUSE 12.2 reibungslos funktioniert.
edit: mit dem Originalskript aus dieser Anleitung klappt es nun: http://askubuntu.com/questions/287257/high-fan-speed-and-noise-after-system-wakeup-in-newly-install-13-04

Josef,
bei mir ist keine Lüftersteuerung im OS konfiguriert, deshalb gibts auch keine Konfigurationsdatei in /etc.

Danke für die Hilfe

RME · 12 Juli 2013

Das Skript bewirkt an beiden Speicherorten nichts.

edit: mit dem Originalskript aus dieser Anleitung klappt es...

Das "Originalskript" entspricht in seiner Funktion genau dem zweiten von mir geposteten :???:

...aber Hauptsache das Problem ist "gelöst"

-/-

spoensche · 12 Juli 2013

Poste mal die Ausgabe von

Code:

dmesg | egrep -i "acpi|err|fail|fault"

frankqn · 12 Juli 2013

RME schrieb:
...aber Hauptsache das Problem ist "gelöst"

Es funktioniert nur manchmal. Wenn ich den PC per Tastendruck in den Ruhezustand schicke, klappt es beim Wecken, geht er per Timer, ist beim Wecken wieder alles laut. Vielleicht ist das aber auch nur Zufall und es funktioniert mal oder eben mal nicht.

Code:

dmesg | egrep -i "acpi|err|fail|fault"
[    0.000000] BIOS-e820: [mem 0x00000000cff90000-0x00000000cff9dfff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000cff9e000-0x00000000cffdffff] ACPI NVS
[    0.000000] MTRR default type: uncachable
[    0.000000] ACPI: RSDP 00000000000fab70 00014 (v00 ACPIAM)
[    0.000000] ACPI: RSDT 00000000cff90000 00040 (v01 7599MS A7599100 20110304 MSFT 00000097)
[    0.000000] ACPI: FACP 00000000cff90200 00084 (v01 7599MS A7599100 20110304 MSFT 00000097)
[    0.000000] ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130328/tbfadt-603)
[    0.000000] ACPI: DSDT 00000000cff905d0 098F4 (v01  A7599 A7599100 00000100 INTL 20051117)
[    0.000000] ACPI: FACS 00000000cff9e000 00040
[    0.000000] ACPI: APIC 00000000cff90390 0007C (v01 7599MS A7599100 20110304 MSFT 00000097)
[    0.000000] ACPI: MCFG 00000000cff90410 0003C (v01 7599MS OEMMCFG  20110304 MSFT 00000097)
[    0.000000] ACPI: OEMB 00000000cff9e040 00072 (v01 7599MS A7599100 20110304 MSFT 00000097)
[    0.000000] ACPI: SRAT 00000000cff99ed0 000E8 (v03 AMD    FAM_F_10 00000002 AMD  00000001)
[    0.000000] ACPI: HPET 00000000cff99fc0 00038 (v01 7599MS OEMHPET  20110304 MSFT 00000097)
[    0.000000] ACPI: SSDT 00000000cff9a000 0088C (v01 A M I  POWERNOW 00000001 AMD  00000001)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled)
[    0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000
[    0.000000] spurious 8259A interrupt: IRQ7.
[    0.000006] pid_max: default: 32768 minimum: 301
[    0.004450] ACPI: Core revision 20130328
[    0.007404] ACPI: All ACPI Tables successfully acquired
[    0.185864] PM: Registering ACPI NVS region [mem 0xcff9e000-0xcffdffff] (270336 bytes)
[    0.186213] ACPI: bus type PCI registered
[    0.187239] ACPI: Added _OSI(Module Device)
[    0.187240] ACPI: Added _OSI(Processor Device)
[    0.187241] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.187243] ACPI: Added _OSI(Processor Aggregator Device)
[    0.187799] ACPI: EC: Detected MSI hardware, enabling workarounds.
[    0.187801] ACPI: EC: Look up EC in DSDT
[    0.188733] ACPI: Executed 4 blocks of module-level executable AML code
[    0.194677] ACPI: Interpreter enabled
[    0.194684] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20130328/hwxface-568)
[    0.194688] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130328/hwxface-568)
[    0.194700] ACPI: (supports S0 S3 S4 S5)
[    0.194701] ACPI: Using IOAPIC for interrupt routing
[    0.195491] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
[    0.202923] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.202995] ACPI: No dock devices found.
[    0.227810] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.228198] pci 0000:00:02.0: System wakeup disabled by ACPI
[    0.228284] pci 0000:00:06.0: System wakeup disabled by ACPI
[    0.228631] pci 0000:00:12.0: System wakeup disabled by ACPI
[    0.228759] pci 0000:00:12.1: System wakeup disabled by ACPI
[    0.228938] pci 0000:00:12.2: System wakeup disabled by ACPI
[    0.229076] pci 0000:00:13.0: System wakeup disabled by ACPI
[    0.229212] pci 0000:00:13.1: System wakeup disabled by ACPI
[    0.229398] pci 0000:00:13.2: System wakeup disabled by ACPI
[    0.229843] pci 0000:00:14.2: System wakeup disabled by ACPI
[    0.230049] pci 0000:00:14.4: System wakeup disabled by ACPI
[    0.230190] pci 0000:00:14.5: System wakeup disabled by ACPI
[    0.235029] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM
[    0.235030] acpi PNP0A03:00: Unable to request _OSC control (_OSC support mask: 0x08)
[    0.243723] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)
[    0.243776] ACPI: PCI Interrupt Link [LNKB] (IRQs *4 7 10 11 12 14 15)
[    0.243826] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)
[    0.243876] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 12 14 15)
[    0.243926] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[    0.243976] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 12 14 15)
[    0.244025] ACPI: PCI Interrupt Link [LNKG] (IRQs 10 *11 12 14 15)
[    0.244075] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[    0.244198] acpi root: \_SB_.PCI0 notify handler is installed
[    0.244224] Found 1 acpi root devices
[    0.244400] ACPI: bus type ATA registered
[    0.244469] ACPI: bus type USB registered
[    0.244596] PCI: Using ACPI for IRQ routing
[    0.253784] NetLabel:  unlabeled traffic allowed by default
[    0.257527] pnp: PnP ACPI init
[    0.257536] ACPI: bus type PNP registered
[    0.257598] pnp 00:00: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.257627] pnp 00:01: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.257646] pnp 00:02: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.257669] pnp 00:03: Plug and Play ACPI device, IDs PNP0c04 (active)
[    0.257924] pnp 00:04: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.258048] system 00:05: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.258298] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.258346] pnp 00:07: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
[    0.258408] pnp 00:08: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 (active)
[    0.258532] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.258602] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.270080] system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active)
[    0.270192] pnp: PnP ACPI: found 12 devices
[    0.270193] ACPI: bus type PNP unregistered
[    0.279389] PCI: CLS 64 bytes, default 64
[    0.592014] io scheduler cfq registered (default)
[    1.929461] ACPI: Power Button [PWRB]
[    1.950034] ACPI: Power Button [PWRF]
[    2.092410] nouveau W[     DRM] failed to create encoder 0/1/0: -19
[    5.558314] systemd[1]: Starting LSB: Set default boot entry if called...
[    7.555745] ACPI Warning: 0x0000000000000b00-0x0000000000000b07 SystemIO conflicts with Region \SOR1 1 (20130328/utaddress-251)
[    7.555750] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    7.556198] sp5100_tco: failed to find MMIO address, giving up.
[    7.562966]  Either enable ECC checking or force module loading by setting 'ecc_enable_override'.
[    7.562966]  (Note that use of the override may cause unknown side effects.)
[    7.622703] ALSA patch_realtek.c:423 SKU: override=0x1
[    7.776591] acpi-cpufreq: overriding BIOS provided _PSD data

edit: kann das vielleich vom nouveau-Treiber kommen? Das ist nämlich der einzige Unterschied zu vorher, als noch alles ok war. Ich benutze momentan den nouveau, weil sich nvidia nicht mit dem 3.10 Kernel installieren lässt.

josef-wien · 12 Juli 2013

RME schrieb:
:???:

Im ersten Skript fehlt ein "do", daher kommt es zu einem syntax error. Das erste Skript verwendet Verknüpfungen, das zweite Skript die "echten" Namen.

frankqn schrieb:
Vielleicht ist das aber auch nur Zufall

Entferne das Skript wieder, und sieh Dir mit

Code:

cat /sys/devices/virtual/thermal/cooling_device*/cur_state

die Inhalte an. Wenn auch beim "lauten" Aufwachen jeweils "Null" enthalten ist, ist Dein Problem ein anderes.

Zu sp5100_tco (watchdog timer), zu nouveau und zum Kernel 3.10 kann ich nichts sagen.

Nachtrag: Findet sich in pm-*.log etwas?

RME · 12 Juli 2013

@josef-wien:

josef-wien schrieb:
Im ersten Skript fehlt ein "do", daher kommt es zu einem syntax error. Das erste Skript verwendet Verknüpfungen, das zweite Skript die "echten" Namen.

...ahh ja, vielen Dank! Ich werde es noch korrigieren.

Gruss,
Roland

frankqn · 13 Juli 2013

Stimmt, Josef, wenn die Nullen einmal drin sind, müssen sie nicht immer wieder neu reingeschrieben werden.

In pm-suspend.log kann ich nichts Auffälliges finden, allerdings sieht pm-powersave.log m. E. merkwürdig aus:

Code:

Running hook /usr/lib/pm-utils/power.d/disable_wol false:
Setting Wake On Lan for eth0 to enable...Done.

/usr/lib/pm-utils/power.d/disable_wol false: success.
Running hook /usr/lib/pm-utils/power.d/hal-cd-polling false:

/usr/lib/pm-utils/power.d/hal-cd-polling false: success.
Running hook /usr/lib/pm-utils/power.d/intel-audio-powersave false:
/usr/lib/pm-utils/power.d/intel-audio-powersave: Zeile 25: printf: snd_ac97_codec: Ungültige Zahl.
Setting power savings for  to 0...Setting power savings for  to 0...Done.
/usr/lib/pm-utils/power.d/intel-audio-powersave: Zeile 25: printf: snd_hda_intel: Ungültige Zahl.
Setting power savings for  to 0...Setting power savings for  to 0...Done.

/usr/lib/pm-utils/power.d/intel-audio-powersave false: success.
Running hook /usr/lib/pm-utils/power.d/journal-commit false:
Setting journal commit time for / to 0...Done.
Setting journal commit time for /home to 0...Done.

/usr/lib/pm-utils/power.d/journal-commit false: success.
Running hook /usr/lib/pm-utils/power.d/laptop-mode false:
Laptop mode disabled.

/usr/lib/pm-utils/power.d/laptop-mode false: success.
Running hook /usr/lib/pm-utils/power.d/pcie_aspm false:
/usr/lib/pm-utils/power.d/pcie_aspm: Zeile 9: echo: Schreibfehler: Die Operation ist nicht erlaubt.

/usr/lib/pm-utils/power.d/pcie_aspm false: success.
Running hook /usr/lib/pm-utils/power.d/readahead false:
Setting readahead for /dev/sda3 to 256...Done.
Setting readahead for /dev/sda7 to 256...Done.
Setting readahead for /dev/sda1 to 256...Done.
Setting readahead for /dev/sda2 to 256...Done.
Setting readahead for /dev/sda5 to 256...Done.
Setting readahead for /dev/sda8 to 256...Done.
Setting readahead for /dev/sda8 to 256...Done.

/usr/lib/pm-utils/power.d/readahead false: success.
Running hook /usr/lib/pm-utils/power.d/sata_alpm false:
Setting SATA APLM on host0 to max_performance...Done.
Setting SATA APLM on host1 to max_performance...Done.
Setting SATA APLM on host2 to max_performance...Done.
Setting SATA APLM on host3 to max_performance...Done.

/usr/lib/pm-utils/power.d/sata_alpm false: success.
Running hook /usr/lib/pm-utils/power.d/sched-powersave false:
**sched policy powersave OFF

/usr/lib/pm-utils/power.d/sched-powersave false: success.
Running hook /usr/lib/pm-utils/power.d/wireless false:

/usr/lib/pm-utils/power.d/wireless false: success.
Running hook /usr/lib/pm-utils/power.d/xfs_buffer false:

/usr/lib/pm-utils/power.d/xfs_buffer false: success.

/usr/lib/pm-utils/power.d/intel-audio-powersave:

Code:

#!/bin/sh

# Allow the driver to put the audio hardware to sleep
# once the driver has been inactive for a second.
# This hook should work with at least the ac97 and hda codecs.

INTEL_AUDIO_POWERSAVE=${INTEL_AUDIO_POWERSAVE:-true}

help() {
cat <<EOF
--------
$0: Intel Audio powersave parameters.

This hook has 1 tuneable parameter. 
INTEL_AUDIO_POWERSAVE = controls whether we will try to save power on battery.
Defaults to true.

EOF
}

audio_powersave() {
    [ "$INTEL_AUDIO_POWERSAVE" = "true" ] || exit $NA
    for dev in /sys/module/snd_*; do
	[ -w "$dev/parameters/power_save" ] || continue
	printf "Setting power savings for $s to %d..." "${dev##*/}" "$1"
	echo $1 > "$dev/parameters/power_save" && echo Done. || echo Failed.
    done
}

case $1 in
    true) audio_powersave 1 ;;
    false) audio_powersave 0 ;;
    help) help;;
    *) exit $NA
esac

exit 0

/usr/lib/pm-utils/power.d/pcie_aspm:

Code:

#!/bin/sh

aspm="/sys/module/pcie_aspm/parameters/policy"

[ -w "$aspm" ] || exit $NA

case $1 in
    true) echo powersave > "$aspm";;
    false) echo default > "$aspm";;
    *) exit $NA;;
esac

exit 0

josef-wien · 13 Juli 2013

Die genannten Dateien stammen aus dem Paket pm-utils. Beide Fehlermeldungen habe ich auch, und zwar ohne Auswirkungen (was auch logisch ist). Eine Aktion betrifft eine Text-Ausgabe, bei der anderen blockiert der Kernel eine Änderung dieses Parameters im laufenden Betrieb (mit "false" soll "default" aktiviert werden, was bei mir ohnehin aktiv ist).

frankqn schrieb:
wenn die Nullen einmal drin sind, müssen sie nicht immer wieder neu reingeschrieben werden.

Die von RME gefundenen Lösungen erklären sich für mich nur dadurch, daß beim "Aufwachen" die ursprünglichen Werte "verlorengehen" und wiederhergestellt werden müssen. Ob das bei Dir (manchmal) auch so ist, mußt Du herausfinden. Und um keine an den Haaren herbeigezogene Möglichkeit auszulassen, kannst Du ja nach dem nächsten "Lärmstart" das Skript manuell ausführen.

frankqn · 13 Juli 2013

Nein, die Nullen stehen immer drin. Deshalb bringt es nichts, sie neu reinzuschreiben. Die cur_state sehen nach dem Skript genau so aus wie vorher, es steht immer eine 0 drin. Es ist demzufolge auch völlig gleich, wann oder wie man das Skript ausführt, es ändert nichts am Inhalt der cur_state.

Was ist denn mit der fehlenden /usr/lib/pm-utils/sleep.d/80acpi-fan? Das deutet doch darauf hin, dass man irgendwas geändert hat seit openSUSE 12.2. Wie schon beschrieben ändert auch das manuelle einsetzen der Datei nichts. Aktuell ist pm-utils-1.4.1-26.13.1

80acpi-fan aus pm-utils-1.4.1-18.3.2

Code:

#!/bin/bash
#
# Stefan Seyfried, SUSE Linux Products GmbH, 2006
# mostly taken from the powersave project

. "${PM_FUNCTIONS}"

#############################################################
# triggers the ACPI fan(s) after resume. Since ACPI drivers
# have no suspend support, this is sometimes necessary.
# see http://article.gmane.org/gmane.linux.acpi.devel/16643
kick-fan()
{
	local FAN DUMMY STATE 
	for FAN in /proc/acpi/fan/*/state; do
		[ ! -e $FAN ] && continue
		read DUMMY STATE < $FAN
		if [ "$STATE" = "on" ]; then
			echo "kicking $FAN on"
			echo -n 3 > $FAN
			echo -n 0 > $FAN
		else
			echo "kicking $FAN off"
			echo -n 0 > $FAN
			echo -n 3 > $FAN
		fi
	done
}

case $1 in
	thaw|resume)
		kick-fan
		;;
        *) exit $NA
           ;;
esac

exit 0

josef-wien · 13 Juli 2013

Änderungsprotokoll von pm-utils-1.4.1-26.13.1.x86_64.rpm schrieb:
- Deleted 80acpi-fan, since it used /proc/acpi/fan/ and it was removed from kernel long ago. bnc#806635

Da wurde also nur eine Leiche entsorgt.

Ich denke, daß Dein Problem mit

frankqn schrieb:
3.10 Kernel

zusammenhängt, und dabei kann ich Dir nicht weiterhelfen.

spoensche · 14 Juli 2013

Der Fehler mit der Luftersteuerung hängt zu 99% mit den ACPI Fehlern zusammen. Hast du mal ein BIOS Update gemacht?

frankqn · 15 Juli 2013

Es gibt kein BIOS-Update, es ist aktuell. Ich habe immer sofort nach Erscheinen eines Updates das BIOS aktualisiert. Davon kommt es auch nicht, sonst hätten andere OS auch Probleme. Ich tippe auf Kernel oder nouveau. Mit dem nouveau möchte ich lieber nicht rumexperimentieren, man kriegt ihn so schlecht deaktiviert bzw. danach wieder aktiviert.

Phenom II 955 auf MSI 770C45, 8GB 1333 RAM, NVIDIA GTX 260, Neu installiertes openSUSE 12.3 mit sofortiger Umwandlung zu Tumbleweed.

Update: auch mit dem 3.7er Kernel tritt das Problem auf.

spoensche · 15 Juli 2013

frankqn schrieb:
Es gibt kein BIOS-Update, es ist aktuell. Ich habe immer sofort nach Erscheinen eines Updates das BIOS aktualisiert. Davon kommt es auch nicht, sonst hätten andere OS auch Probleme. Ich tippe auf Kernel oder nouveau. Mit dem nouveau möchte ich lieber nicht rumexperimentieren, man kriegt ihn so schlecht deaktiviert bzw. danach wieder aktiviert.

Das Problem ist, dass BIOS Hersteller das BIOS so stark auf Windows anpassen und das BIOS dadurch Buggy wird. Was meinst du wo die ganzen ACPI Fehler herkommen?

Was hat der Grafiktreiber mit der CPU Lüftersteuerung zu tun? Nichts.

Wenn du unter /etc/modprobe.d eine Datei.conf mit dem Eintrag

Code:

blacklist modulname

verhinderst du das dass Modul geladen wird.

frankqn · 16 Juli 2013

spoensche schrieb:
Was hat der Grafiktreiber mit der CPU Lüftersteuerung zu tun? Nichts.

So einfach ist das nicht, glaube ich. Ich weiß nicht in welcher Reihehnfolge welche Sachen beim Aufwecken aktiviert werden. Die grafische Oberfläche gehört aber auf jeden Fall auch dazu. Vielleicht ist es ja ein Timing-Problem und irgendwas braucht vielleicht einfach nur zu lange. Dafür spricht, dass es manchmal funktioniert.

Am BIOS liegt es nicht, es funktioniert auch mit anderen Linux-OS, unter Anderem auch mit openSUSE 12.2.

nouveau kann man blacklisten, wie man will, es wird trotzdem geladen, jedenfalls sagt das NVIDIA und bricht die Installation ab. Bei mir half immer nur eine Deinstallation und mkinitrd. Und nach einer NVIDIA-Deinstallation habe ich es bis jetzt auch noch nie geschafft, zurück zu nouveau zu switchen.

---

Update: ich habe es geschafft, den NVIDIA-Treiber für den 3.10er Kernel zu patchen und zu installieren. Mein Rechner wacht nun wierder leise und fehlerfrei auf.

Es stellt sich die Frage, was durch nouveau durcheinander gebracht wird. Ich glaube, es wird zu schnell die Grafik geladen und dadurch vielleicht andere Skripte unterbrochen, beendet oder nicht gestartet.

Lüftersteuerung nach Ruhezustand

frankqn

Member

Jägerschlürfer

Moderator

frankqn

Member

josef-wien

Ultimate Guru

RME

Advanced Hacker

frankqn

Member

RME

Advanced Hacker

spoensche

Moderator

frankqn

Member

josef-wien

Ultimate Guru

RME

Advanced Hacker

frankqn

Member

josef-wien

Ultimate Guru

frankqn

Member

josef-wien

Ultimate Guru

spoensche

Moderator

frankqn

Member

spoensche

Moderator

frankqn

Member