ubuntuusers.de

praseodym schrieb:

Ok,

der 35er und der 36er sind runter, 32-28 inkl. Header und prop. NVIDIA-Treiber aus dem PPA inkl. VDPAU reinstalliert (um Dependency Hell auszuschliessen, da die Pakete für Lucid sind von den Versionen her).

Sorry, Bahnhof. 😉 Aus Interesse, damit ich auch lerne, was du meinst:

• Du hast doch Lucid?

• Wieso PPA?

• welche Dependencies bei was genau?

Einige Zeit gedaddelt ▶ Absturz.

acpi=off?

Dann kam ich drauf, dass ich die Prozessortaktung genauer regeln wollte und hab mir die /etc/cpufreqd.conf genauer angesehen. Dort stand massig Zeug drin, was ich auf

eingedampft habe (Rest auskommentiert) nach Lektüre von Forenartikeln, da der Rechner immer sehr warm oben war (wo die CPUs sitzen weiss ich nicht, da der Rechner noch 1,5 Jahre Garantie hat 😉 und ich nicht rumschrauben wollte)

Danach google ich gerade, aber die Tabs lasse ich wieder mal rumliegen, keine Zeit. Bin gerade sogar noch in den ACPI-Ordnern wühlen, auf die ich durch dieses Thema kam. So zeigt es alles auf einmal an:

find /proc/acpi/ -type f -exec ls {} ';' -exec cat {} ';' 2>/dev/null | less

find /proc/acpi/ -type f -exec ls {} ';' -exec cat {} ';' 2>/dev/null

/proc/acpi/thermal_zone/THRM/polling_frequency
<polling disabled>
/proc/acpi/thermal_zone/THRM/cooling_mode
0 - Active; 1 - Passive
/proc/acpi/thermal_zone/THRM/trip_points
critical (S5):           90 C
active[0]:               88 C: devices= FAN 
/proc/acpi/thermal_zone/THRM/temperature
temperature:             32 C
/proc/acpi/thermal_zone/THRM/state
state:                   ok
/proc/acpi/processor/CPU1/power
active state:            C0
max_cstate:              C8
maximum allowed latency: 2000000000 usec
states:
/proc/acpi/processor/CPU1/limit
<not supported>
/proc/acpi/processor/CPU1/throttling
<not supported>
/proc/acpi/processor/CPU1/info
processor id:            1
acpi id:                 1
bus mastering control:   no
power management:        no
throttling control:      no
limit interface:         no
/proc/acpi/processor/CPU0/power
active state:            C0
max_cstate:              C8
maximum allowed latency: 2000000000 usec
states:
/proc/acpi/processor/CPU0/limit
<not supported>
/proc/acpi/processor/CPU0/throttling
<not supported>
/proc/acpi/processor/CPU0/info
processor id:            0
acpi id:                 0
bus mastering control:   no
power management:        no
throttling control:      no
limit interface:         no
/proc/acpi/fan/FAN/state
status:                  on
/proc/acpi/button/power/PWRF/info
type:                    Power Button
/proc/acpi/button/power/PWRB/info
type:                    Power Button
/proc/acpi/event
/proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
HUB0	  S5	 disabled  pci:0000:00:08.0
XVR0	  S5	 disabled  pci:0000:00:10.0
XVR1	  S5	 disabled  
XVR2	  S5	 disabled  pci:0000:00:12.0
XVR3	  S5	 disabled  pci:0000:00:13.0
XVR4	  S5	 disabled  
XVR5	  S5	 disabled  
XVR6	  S5	 disabled  
XVR7	  S5	 disabled  
PS2M	  S4	 disabled  pnp:00:08
PS2K	  S4	 disabled  pnp:00:09
USB0	  S3	 disabled  pci:0000:00:02.0
USB1	  S3	 disabled  pci:0000:00:04.0
USBB	  S3	 disabled  pci:0000:00:04.1
USB2	  S3	 disabled  pci:0000:00:02.1
AZAD	  S5	 disabled  pci:0000:00:07.0
MMAC	  S5	 disabled  pci:0000:00:0a.0
/proc/acpi/sleep
S0 S3 S4 S5 
/proc/acpi/fadt
/proc/acpi/dsdt
/proc/acpi/info
version:                 20090903

PPA ist das aus dem Nvidia-Wiki für den neuesten Treiber (GeForce 315) und dasjenige für VDPAU.

lsb_release -a

No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 10.04.2 LTS
Release:	10.04
Codename:	lucid

Bei den Dependencies bin ich mir nicht sicher gewesen, da ich einen Natty-Mainlinekernel verwendet habe, der zurückportierte sollte aber eigentlich kein Problem gewesen sein. Ich hatte den Nvidia-Treiber für den Natty-Kernel neu installiert, da Gehakel auftrat, das führte dazu, dass die regulären Lucid-Kernel (32-28) das Modul nicht mehr nutzen konnten, also Low-Graphic-Mode.

Ja, der Absturz war mit "acpi=off" (Edit: ) in der /boot/grub/grub.cfg.

Der GraKa-Treiber aus dem PPA sorgt wohl dafür, dass die Performance zu hoch geht, was die Temperatur hochtreibt laut nvidia-settings (gelber Bereich über 50°C, hatte ich vorher nie). Ich downgrade jetzt mal den Treiber auf den regulären Lucid-Treiber. Die Anzeige steht auf "Adaptive", zeigt aber "Performance Mode: Maximum", siehe Anhang.

Scheint wohl am Treiber zu liegen, mit dem 270er war die reguläre Temperatur um die 50°C gelegen, jetzt liegt sie mit dem 195er aus den Quellen bei 40-41°C. Muss das mal mit Gedaddel und den neueren Kerneln testen. "acpi=off" wird nicht verwendet

Ok:

Die Treiber aus dem PPA bringen die Kiste ins Schwitzen.

Offenbar läuft die Karte GeForce 315 mit den Kerneln 2.6.32-28, 2.6.35-23 und 2.6.36-rc8 mit den Treibern 260 und 270 permanent auf "Volllast", was zu erhöhter Hitzeentwicklung und zum Sicherheitsabschalten führt.

Edit: Die Einstellungen aus dem NVIDIA-Wiki in der /etc/X11/xorg.conf halfen nicht; ausserdem war eine Datei ~/.config/monitors.html vorhanden, die ich gelöscht habe. Deren Einstellungen waren aber in Ordnung, sie überschreiben aber natürlich die xorg.conf-Konfiguration, da diese Datei danach ausgelesen wird.

Ich habe das NVIDIA-PPA mit ppa-purge entfernt und den regulären 195er-Lucid-Treiber reinstalliert. Damit treten keinerlei Probleme mit den Kerneln 2.6.32-28 und 2.6.35-23 auf. Den 36er hab ich runtergeworfen, da dieser eine eigene Reinstallation des 195er NVIDIA-Treibers benötigte und dann die anderen nur noch im Low-Graphic-Mode liefen (Fehlermeldung "nvidia-current" und auch nebenbei "virtualbox-4.0" können nicht installiert werden, deshalb war eine eigene Installation für Kernel 2.6.36 nötig).

"acpi=off" ist nun sowohl im BIOS als auch in der /boot/grub/grub.cfg entfernt, die /etc/cpufreqd.conf bleibt wie beschrieben.

Danke an alle Helfer und besonders Benno-007, hier die Angaben:

oliver@slayer:~$ cat /boot/grub/grub.cfg | grep acpi
oliver@slayer:~$

modinfo nvidia-current | egrep 'filen|195'

filename:       /lib/modules/2.6.35-23-generic/updates/dkms/nvidia-current.ko
alias:          char-major-195-*

lspci -nnk | grep -iA2 VGA

02:00.0 VGA compatible controller [0300]: nVidia Corporation Device [10de:0a22] (rev a2)
	Kernel driver in use: nvidia
	Kernel modules: nvidia-current, nouveau, nvidiafb

egrep -v "^$|^#" /etc/cpufreqd.conf

[General]
pidfile=/var/run/cpufreqd.pid
poll_interval=2
verbosity=4
[/General]
[Profile]
name=On Demand High
minfreq=40%
maxfreq=100%
policy=ondemand
[/Profile]
[Profile]
name=On Demand Low
minfreq=20%
maxfreq=80%
policy=ondemand
[/Profile]

Danke für die Anmerkungen, hat auch mir was gebracht.

Randbemerkungen:

apt-cache ist aber immer geleert, deshalb keine Ausgabe für jeden Kernel.

Schau dir vielleicht mal die Manpage dazu an - damit kann man Synaptic im Terminal anwenden, also z.B. alle Infos zu einem Paket anzeigen (und grepen). 😉 Das erspart das Geklicke und Gescrolle durch die Eigenschaften eines Paketes in Synaptic.

Ich weiß nicht, ob mein find-Befehl wirklich für dieses Thema hier hilfreich war, auf jeden Fall hatte mich das Thema dazu angeregt, mich da mal näher umzusehen. 😉

Das gibt einen guten Überblick, ohne jede Datei (bzw. in /proc ja nur im RAM liegend) einzeln öffnen zu müssen.

Die Anzeige steht auf "Adaptive", zeigt aber "Performance Mode: Maximum", siehe Anhang.

Aber auch nur auf Performance Level 0 mit wenig MHz. Die auch ganz oben tatsächlich so angezeigt werden.

Nochmal zur Garantie: Die sollte eigentlich weiterlaufen, wenn man selber RAM erweitert usw.! Aber dazu habe ich noch Tabs offen, da es ja auch Gewährleistung und Sonderfälle gibt. Man darf halt nix kaputtmachen. 😉 Bei Notebooks so eine Sache. Den Rechner habe ich sowieso selber zusammengebaut. Dann hätte ich rein rechtlich wohl nur die defekte Komponente zurückschicken können - und die natürlich möglichst selber rausfinden müssen, es sei denn, die lassen sich drauf ein, dass man alles zurückschickt, aber das kostet bestimmt nicht nur unnötig Versand...

Aber man lernt was dabei und macht es in Ruhe statt schnell zusammengepferscht (Kabel knicken, lockere Verbindungen, Festplatten locker...) und muss im Garantiefall nur die defekte Komponente und nicht gleich den ganzen Rechner einsenden. Und hat mindestens 20 EUR für den Zusammenbau gespart. 😉

Wie kamst du nun auf die Temperaturen als Ursache? Durch den find-Befehl? Da stand ja auch eine Temperatur - bei mir übrigens war dieses Temperaturverzeichnis leer, auch grep am find-Befehl liefert nix. Geforce 8600 GTS. Es zeigt aber Temperaturen im Programm an. Auch ist das Einstellungs-Programm anders aufgebaut und hat andere Schriften.

Grüße, Benno

Ich hab mir in NVIDIA-Settings öfters mal die Anzeige angesehen und dann das Forum durchstöbert und bin auf diesen Post von agaida gestossen. Allerdings hats mir grade wieder die Kiste abgeschaltet. Ich hab mir jetzt das GNOME-Sensors-Applet installiert und beobachte weiter. Kernel ist der 2.6.35.

Feb 19 00:55:41 localhost kernel: [ 1104.389737] ACPI: resource it87 [io  0x0295-0x0296] conflicts with ACPI region IP__ [irq 661-662 pref disabled]
Feb 19 00:55:41 localhost kernel: [ 1104.389745] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Feb 19 01:01:48 localhost kernel: [ 1471.556589] i2c /dev entries driver

Kannst du damit was anfangen? Das ist um den Absturz herum.

Nö, könnte ein IRQ Konflikt sein. Aber wie man den unter Linux auflöst, wenn im BIOS alles auf Auto ist? Musst wohl doch jede Meldung ergoogeln. 😉

Ich hab über Google und das Debianforum diesen Thread gefunden und acpi_enforce_resources=lax in die grub-Zeile eingefügt. Vor dem Einfügen:

sensors

acpitz-virtual-0
Adapter: Virtual device
temp1:       +45.0°C  (crit = +90.0°C)                  

k10temp-pci-00c3
Adapter: PCI adapter
temp1:       +32.0°C  (high = +70.0°C)   

Nachher:

sensors

acpitz-virtual-0
Adapter: Virtual device
temp1:       +36.0°C  (crit = +90.0°C)                  

k10temp-pci-00c3
Adapter: PCI adapter
temp1:       +26.0°C  (high = +70.0°C)                  

it8718-isa-0290
Adapter: ISA adapter
in0:         +1.65 V  (min =  +0.00 V, max =  +4.08 V)   
in1:         +2.45 V  (min =  +0.00 V, max =  +4.08 V)   
in2:         +1.98 V  (min =  +0.00 V, max =  +4.08 V)   
in3:         +2.91 V  (min =  +0.00 V, max =  +4.08 V)   
in4:         +2.50 V  (min =  +0.00 V, max =  +4.08 V)   
in5:         +1.10 V  (min =  +0.00 V, max =  +4.08 V)   
in6:         +0.99 V  (min =  +0.00 V, max =  +4.08 V)   
in7:         +2.94 V  (min =  +0.00 V, max =  +4.08 V)   
Vbat:        +3.02 V
fan1:       1268 RPM  (min =    0 RPM)
temp1:       +36.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = thermal diode
temp2:       -78.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = disabled
temp3:       -78.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = disabled

und dmesg

[   12.890847] it87: Found IT8718F chip at 0x290, revision 5
[   12.890857] it87: VID is disabled (pins used for GPIO)
[   12.890867] it87: in3 is VCC (+5V)
[   12.890868] it87: in7 is VCCH (+5V Stand-By)
[   12.890913] ACPI: resource it87 [io  0x0295-0x0296] conflicts with ACPI region IP__ [irq 661-662 pref disabled]

Was mich stutzig macht, ist immer noch die amd64-Fehlermeldung:

[   12.826244] EDAC amd64_edac:  Ver: 3.3.0 Dec  2 2010
[   12.852123] EDAC amd64: This node reports that Memory ECC is currently disabled, set F3x44[22] (0000:00:18.3).
[   12.852130] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load.
[   12.852144] amd64_edac: probe of 0000:00:18.2 failed with error -22

modinfo amd64_edac_mod

filename:       /lib/modules/2.6.35-23-generic/kernel/drivers/edac/amd64_edac_mod.ko
description:    MC support for AMD64 memory controllers -  Ver: 3.3.0 Dec  2 2010
author:         SoftwareBitMaker: Doug Thompson, Dave Peterson, Thayne Harbaugh
license:        GPL
srcversion:     1C98E21544553C4B26A35F8
alias:          pci:v00001022d00001302sv*sd*bc*sc*i*
alias:          pci:v00001022d00001202sv*sd*bc*sc*i*
alias:          pci:v00001022d00001102sv*sd*bc*sc*i*
depends:        edac_core,edac_mce_amd
vermagic:       2.6.35-23-generic SMP mod_unload modversions 
parm:           report_gart_errors:int
parm:           ecc_enable_override:int
parm:           edac_op_state:EDAC Error Reporting state: 0=Poll,1=NMI (int)

Auszug aus "lspci -nnk | grep -iA2 1022":

00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202]
	Kernel modules: amd64_edac_mod

Dieses Modul wird nicht geladen ("Kernel Driver in use") und lässt sich auch nicht laden, weder direkt noch über die /etc/modules:

FATAL: Error inserting amd64_edac_mod (/lib/modules/2.6.35-23-generic/kernel/drivers/edac/amd64_edac_mod.ko): No such device

😲

Im BIOS gibt es keine Möglichkeit für ECC-Einstellungen.

Sprich: Keine Möglichkeit ECC einzustellen, Device mit richtiger ID ist vorhanden, Treiber dazu auch, wird aber nicht geladen, weil kein Device vorhanden.

Noch was anderes: In nvidia-settings unter "Thermal settings" ist Slowdown Threshold ausgegraut auf 255°C gestellt. Wo/wie kann man das einsehen oder gar ändern?

Ach ja: Die ACPI-Meldung kann wohl laut diversen Treffern zufolge ignoriert werden, da ein eigener selbst installierter Treiber helfen könnte, aber wohl kein Support dafür vorhanden wäre, eigenes Risiko sozusagen...

Interessante Methode. Wegen Nvidia, schau mal in die ~/.nvidia-settings-rc.

Die Bootoption nocrs könnte laut diesem Post im durch mich hierher verlinktenden Thema Erfolg versprechen - tauchte bei dir ja auch auf.

Übrigens fand ich gestern wegen der Garantiesache eine sehr gute Zusammenfassung: http://extreme.pcgameshardware.de/blogs/pokerclock/42-jura-ad-acta-gehaeuse-oeffnen-garantieverlust.html

Die Kommentare sind auch gut. Den Anfang las ich schon anderswo und übersprang ich.

dmesg | grep bug

[    0.342931] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug

Wenn ich das in die Grubzeile eingebe und neu starte kommt:

PCI: Using host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug

Also ein Bug 🙄

Auf jeden Fall läuft das System jetzt stabil.

In der .nvidia-settings.rc steht nichts bezüglich der Temperatur ausser

Timer = Thermal_Monitor_(GPU_0),Yes,1000
Timer = PowerMizer_Monitor_(GPU_0),Yes,1000

In wieweit das damit zu tun hat/haben soll, erschliesst sich mir nicht...

praseodym schrieb:

dmesg | grep bug

[    0.342931] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug

Wenn ich das in die Grubzeile eingebe und neu starte kommt:

PCI: Using host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug

Entschuldige, aber: 🤣 Dein Board ist launisch wie manche Frau. 😉

Also ein Bug 🙄

Auf jeden Fall läuft das System jetzt stabil.

Einfach so?

In der .nvidia-settings.rc steht nichts bezüglich der Temperatur ausser

Timer = Thermal_Monitor_(GPU_0),Yes,1000
Timer = PowerMizer_Monitor_(GPU_0),Yes,1000

In wieweit das damit zu tun hat/haben soll, erschliesst sich mir nicht...

Vielleicht ist 1000 der Höchstwert (100 Grad?)? Bzw. 255?

Weil:

Noch was anderes: In nvidia-settings unter "Thermal settings" ist Slowdown Threshold ausgegraut auf 255°C gestellt. Wo/wie kann man das einsehen oder gar ändern?

War aber auch nur ein Gedanke.

Vielleicht wird die Funktion von deiner Karte nicht unterstützt. Ansonsten könnte man vielleicht einen Eintrag machen, wenn man die Syntax und Bezeichnung wüsste. Aber da es ausgegraut ist, wird das sicherlich scheitern.

Das Problem besteht weiterhin bei dauerhaftem Spielen intensiver Games, wie Freespace2, The Babylon Project und TORCS. Ich habe jetzt den 2.6.38-rc7 installiert:

uname -r

2.6.38-020638rc7-generic

dmesg | grep error

[    1.632085] generic-usb: probe of 0003:058F:6363.0001 failed with error -22
[    2.838876] uvesafb: probe of uvesafb.0 failed with error -5
[   12.343365] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro

dmesg | grep fail

[    1.632085] generic-usb: probe of 0003:058F:6363.0001 failed with error -22
[    2.838876] uvesafb: probe of uvesafb.0 failed with error -5

dmesg | grep amd64

[   12.129904] EDAC amd64_edac: v3.3.0
[   12.132335] EDAC amd64: DRAM ECC disabled.
[   12.132344] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load.

dmesg | grep bug

[    0.321897] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    1.100090] ehci_hcd 0000:00:02.1: debug port 1
[    1.120441] ACPI: PCI Interrupt Link [AU2B] disabled and referenced, BIOS bug
[    1.120605] ehci_hcd 0000:00:04.1: debug port 1
[   12.560234] Disabling lock debugging due to kernel taint

Memtest und vollständiger Plattenscan brachten keine Fehler zum Vorschein. Ich beobachte weiter.

Also:

Das Problem liegt offenbar an einer zu stark steigenden Plattentemperatur. Meist liegt die Plattentemperatur bei lm-sensors um die 40 Grad, was als orangener Balken angezeigt wird. Abstürze treten ab etwa 45 Grad oder höher (roter Balken) auf. Die Platte soll laut Hersteller max. 60 Grad aushalten, allerdings sind die Einstellungen in lm-sensors dahingehend zwar änderbar (60°C ist als Maximum eingestellt), aber man will es ja nicht mit Gewalt herausfordern.

Ist bekannt, ob die roten Ausgaben von

sudo lshw -html > ~/System.html 

irgendeine "Alarm"-Farbe darstellen soll? Es könnte ja am 64bit System liegen, da diese Angaben 32bit enthalten. Allerdings sind exakt dieselben Angaben unter der 32bit-Live-CD (gerade damit drin) identisch und auch rot, siehe Anhang.

Der Rechner ist ein kleiner, schmaler Tower, der nur auf der fensterabgewandten Seite Lüftungsschlitze hat. Evtl. bringt es was, wenn man weitere Löcher reinmacht 🙄 . Offen stehen lassen bzw. um 180° drehen geht nicht wegen dem Hund und damit auch wegen der Kabel. ☹ Einfach den Rechner woanders hin auch nicht.

Falls noch jemand Ideen hat, nur her damit.