[gelöst]Kernel module fehlen [defekte netzwerkkabel]

[niesommer]

wenn Du Lust hast ein bißchen im Dunkeln zu stochern: ASPM (PCIe Active State Power Management) läßt sich mit einer Kerneloption (de)aktivieren (der Meldung kann ich nicht entnehmen, welche der beiden Optionen aussichtsreicher ist):

Code: Alles auswählen

pcie_aspm=off

Damit würde ich doch das Power Management komplett ausschalten oder?

Code: Alles auswählen

pcie_aspm=force

Und damit erzwingen?

Wenn du es aktiviert läßt, kannst du das Verhalten von ASPM beeinflussen mit /sys/module/pcie_aspm/parameters/policy (dort etwa performance hineinschreiben, zB mit den sysfsutils) oder wieder über eine Kerneloption

Code: Alles auswählen

pcie_aspm.policy=performance

Also ich habe mal ein

Code: Alles auswählen

cat /sys/module/pcie_aspm/parameters/policy
[default] performance powersave

gemacht. eingetragen sind dort die beiden zustände die meine CPU derzeit kann. Folgendes habe ich eingetragen in der /etc/laptop-mode/laptop-mode.conf

Code: Alles auswählen

#meine Anpassungen für cpu und batterie kontrolle:
BATT_CPU_GOVERNOR=powersave
LM_AC_CPU_GOVERNOR=performance
NOLM_AC_CPU_GOVERNOR=performance

hier meine volständige laptop-mode.conf

Code: Alles auswählen

 cat /etc/default/cpufrequtils 
# Which governor to use. Must be one of the governors listed in:
#   cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
#
# and which limits to set. Both MIN_SPEED and MAX_SPEED must be values
# listed in:
#   cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
# a value of 0 for any of the two variables will disabling the use of 
# that limit variable.
#
# WARNING: the correct kernel module must already be loaded or compiled in.
# 
# Set ENABLE to "true" to let the script run at boot time.
# 
# eg:   ENABLE="true"
#       GOVERNOR="ondemand"
#       MAX_SPEED=1000000
#       MIN_SPEED=500000

ENABLE="true"
GOVERNOR="performance"
#MAX_SPEED=0
#MIN_SPEED=0

So das waren die Anpassungen die ich entsprechend nachträglich noch vorgenommen habe, und damit ja auch entsprechende verbesserungen erreicht. In der /etc/sysfs.conf ist alles auskommentiert da ich dort noch keine änderung vorgenommen habe, weil ich gelesen habe das die sysfs-sachen veraltet sind und man sie nicht verwenden sollte.

ASPM (ich denke Link State Power Management ist im wesentlichen das gleiche) läßt sich auch meist im BIOS (de)aktivieren - das Ändern dieser Einstellung wäre vielleicht auch einen Versuch Wert.

Hmm, das muss ich mal nach sehen ob da im BIOS irgendwas zu steht, soweit ich mich erinnere ist da nicht viel drin gewesen.

[smutbert]

ASPM/Link State Power Management hat imho nichts mit der CPU zu tun. Da geht es nur um das Stromsparen von Geräten die am PCIe hängen und dieses Stromsparen läßt sich meines Wissens eben nur für den gesamten PCIe konfigurieren/abschalten/erzwingen und nicht für einzelne Geräte.

Diese Meldung

Code: Alles auswählen

r8169 0000:02:00.2: can't disable ASPM; OS doesn't have ASPM control

suggeriert, dass ASPM zwar aktiv ist, aber Linux nicht die Kontrolle darüber hat (sondern das BIOS?), deshalb hätte ich vielleicht als erstes das pcie_aspm=off versucht, wobei es ja vielleicht sein könnte, dass es vom BIOS aus trotzdem aktiviert ist und genau das der Grund dafür ist, dass Linux es nicht kontrolliert. Dann wäre vielleicht pcie_aspm=force oder das Abschalten im BIOS die Lösung - so ungefähr ist zumindest mein wirrer Gedankengang.
(und deshbla habe ich im dunkeln stochern geschrieben )

[niesommer]

Achso, ja dann werde ich das mal ausprobieren und bei der gelegenheit gleich mal im BIOS nachsehen.
Danke für deine Erklärung

[niesommer]

So ich habe mal im BIOS nach gesehen und dort gibt es keine möglichkeiten etwas mit ernergiesparen ein zustellen bzw. zu deaktivieren, das einzige was ich dort aktivieren könnte wäre Intel smart connection Technologie und nach dem ich im Netz geschaut habe was das ist, will ich das nicht wirklich haben das entsprciht ganz und garnicht meinen vorstellungen.
So im Moment läuft der rechner mit der option

Code: Alles auswählen

pcie_aspm=force

die Meldung ist nicht mehr dafür habe ich eine andere Meldung:

Code: Alles auswählen

ACPI : EC: GPE storm detected(9 GPEs), transactions will use polling mode

Das ist gleich geblieben.

Code: Alles auswählen

cat /sys/module/pcie_aspm/parameters/policy
[default] performance powersave 

Also werde ich das jetzt in die grub konfiguration schreiben, grub-update machen und das ganze beobachten, mal sehen was so passiert.
Nachtrag:

Code: Alles auswählen

cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-3.13-0.bpo.1-686-pae root=/dev/mapper/tbbt-root ro quiet pcie_aspm=force

[smutbert]

zur Erklärung des GPE Storms, siehe hier die Antwort:
http://askubuntu.com/questions/148726/w ... -gpe-storm
klingt also eigentlich nicht so wahnsinnig toll, bin gespannt ob es dafür dein Netzwerkproblem löst.

In dem Zusammenhang fällt mir ein, dass es vielleicht noch eine Kerneloption gibt, die den Umgang des Kernels mit deiner Hardware vereinfachen kann (und vielleicht pcie_aspm=… und andere Tricksereien überflüssig macht):

Code: Alles auswählen

acpi_osi=Linux

(aber da darfst du keine Erklärungen mehr von mir erwarten - ich gleube nur zu wissen, dass diese Option Linux glauben läßt, es würde vom BIOS als Betriebssystem unterstützt und so dafür sorgen kann, dass die Hardware erwartungsgemäß funktioniert und nicht viele Funktionen einfach deaktiviert werden…)

[niesommer]

So habe deinen neuen Vorschlag getestet und er scheint keine Wirkung zu haben da sich nichts ändert. Habe es wieder um gestellt auf pcie_aspm=force siehr auch:

Code: Alles auswählen

 cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-3.13-0.bpo.1-686-pae root=/dev/mapper/tbbt-root ro quiet pcie_aspm=force

Ich werde das jetzt einfach wieder beobachten, im moment läuft es, mal sehen wie lange oder was noch so kommt.
Vielen dank für deine Hilfe

[niesommer]

Hui mein kernel redet mit mir, das problem das sagt mir jetzt leider nix.

Code: Alles auswählen

Message from syslogd@localhost at Apr  1 15:19:01 ...
 kernel:[ 2660.956660] Uhhuh. NMI received for unknown reason 30 on CPU 0.

Message from syslogd@localhost at Apr  1 15:19:01 ...
 kernel:[ 2660.956664] Do you have a strange power saving mode enabled?

Message from syslogd@localhost at Apr  1 15:19:01 ...
 kernel:[ 2660.956665] Dazed and confused, but trying to continue

Das hat bestimmt was mit pcie_aspm=force zu tun. Weiß wer einen rat?

[smutbert]

habe ich nur ergoogelt, dass du die Meldungen wahrscheinlich mit

Code: Alles auswählen

echo 0 > /proc/sys/kernel/nmi_watchdog

oder als Kerneloption

Code: Alles auswählen

nmi_watchdog=0

los wirst. Habe aber auch gelesen, dass letzteres mit systemd nicht unbedingt hilft, weil das den watchdog wieder einschaltet.

Gelegentich soll es auch eine BIOS Option geben (sync flood oä aktivieren) die die Meldungen beseitigt, was aber meinem Eindruck widerspricht, dass sich diese nmi-Watchdogs eher nach einer reinen Softwaregeschichte anhören


Zu diesem Thema solltest du von mir echt keine konstruktiven Beiträge mehr erwarten… ich steh' sowas von daneben, dass ich höchstens noch Dinge schreibe, die ich finde, wenn ich nach deinen Kernelmeldungen suche und darüber hinaus nur noch die Dinge, die ich finde, wenn ich nach der Bedeutung von dem Suche, was ich bei der ersten Suche gefunden habe.

Am besten bitte ich einen Moderator, dass er mich von diesem Thread ausschließt, damit ich nicht noch mehr Blödsinn schreiben kann.

viel Glück

[niesommer]

habe ich nur ergoogelt, dass du die Meldungen wahrscheinlich mit

Code: Alles auswählen

echo 0 > /proc/sys/kernel/nmi_watchdog

oder als Kerneloption

Code: Alles auswählen

nmi_watchdog=0

Ja, das habe ich auch rausgefunden, nur leider nix darüber was das ist. Nur ne Meldung weg zudrücken finde ich immer etwas mekrwürdig, da das problem (falls es eins ist) ja dann immer noch weiter besteht, ich sehe es halt nur nicht mehr.

los wirst. Habe aber auch gelesen, dass letzteres mit systemd nicht unbedingt hilft, weil das den watchdog wieder einschaltet.

Das ist noch nicht weiter problematisch da ich ja noch wheezy habe und mir systemd nicht eingerichtet habe, was sich aber bei jessie dann wohl ändern wird.

Gelegentich soll es auch eine BIOS Option geben (sync flood oä aktivieren) die die Meldungen beseitigt, was aber meinem Eindruck widerspricht, dass sich diese nmi-Watchdogs eher nach einer reinen Softwaregeschichte anhören


Zu diesem Thema solltest du von mir echt keine konstruktiven Beiträge mehr erwarten… ich steh' sowas von daneben, dass ich höchstens noch Dinge schreibe, die ich finde, wenn ich nach deinen Kernelmeldungen suche und darüber hinaus nur noch die Dinge, die ich finde, wenn ich nach der Bedeutung von dem Suche, was ich bei der ersten Suche gefunden habe.

Am besten bitte ich einen Moderator, dass er mich von diesem Thread ausschließt, damit ich nicht noch mehr Blödsinn schreiben kann.

viel Glück

Wie ich schon geschrieben habe mein BIOS gibt nicht viel her, auch sowas nicht.
Ich bedanke mich bei Dir für deine in meinen Augen sehr konstruktiven und hilfreichen Antworten.

[niesommer]

So heute gabs wieder eine neue Meldung:

Code: Alles auswählen

mce: [Hardware Error]: Machine check events logged

Gestern hatte ich wieder 3x eth0 down, lies sich aber leicht beheben durch erneuern der ip, dafür passierte es aber im Netzbetrieb also nicht im Akku-betrieb. Sonst kann ich problemlos arbeiten.

[smutbert]

Was ist denn das für ein (merkwürdiger ) Computer?

Diese Machine Check Event können alles mögliche sein, zB Speicherfehler, die dank ECC erkannt (und behoben oder auch nicht) wurden oder Überhitzung oder eine nicht ausreichende Stromversorgung oder… Du könntest versuchen den Meldungen mit mcelog auf den Grund zu gehen: http://www.mcelog.org/faq.html

[niesommer]

Was ist denn das für ein (merkwürdiger ) Computer?

Diese Machine Check Event können alles mögliche sein, zB Speicherfehler, die dank ECC erkannt (und behoben oder auch nicht) wurden oder Überhitzung oder eine nicht ausreichende Stromversorgung oder… Du könntest versuchen den Meldungen mit mcelog auf den Grund zu gehen: http://www.mcelog.org/faq.html

Habe dazu gerade diese Seite gefunden: https://www.robhost.de/adminblog/archiv ... eiten.html Also habe ich mir gleichmal mcelog installiert, ein aufruf von mcelog selbst gibt gar keine Fehlermeldung aus, dafür habe ich aber folgendes in der messages drin stehen:

Code: Alles auswählen

Apr  3 08:58:04 localhost kernel: [ 1918.917653] r8169 0000:02:00.2 eth0: link up
Apr  3 09:15:59 localhost kernel: [ 2995.558989] CPU0: Core temperature/speed normal
Apr  3 09:15:59 localhost kernel: [ 2995.558990] CPU1: Package temperature/speed normal
Apr  3 09:15:59 localhost kernel: [ 2995.558994] CPU0: Package temperature/speed normal
Apr  3 09:16:06 localhost kernel: [ 3002.429652] mce: [Hardware Error]: Machine check events logged
Apr  3 10:27:45 localhost mcelog: Processor 0 heated above trip temperature. Throttling enabled.
Apr  3 10:27:45 localhost mcelog: Please check your system cooling. Performance will be impacted
Apr  3 10:27:45 localhost mcelog: Processor 0 below trip temperature. Throttling disabled

Naja, so richtig schlau werde ich aus meinem Rechner auch nicht, aber ich werde es mal im auge behalten, so wie das im Blog steht, zumal die Meldung bis jetzt ja einmalig ist. Solangsam bin ich echt gespannt was noch so alles auftaucht. Danke für den Link auf die FAQ, werde die mal durch nen übersetzter jagen, oder kennst du dafür vielleicht noch eine deutsche Übersetzung?

[smutbert]

Nein, kenne keine Übersetzung, aber so wahnsinnig hilfreich sind die FAQ auch wieder nicht. Ich habe sie verlinkt, weil drinsteht, dass es sich bei MCEs um Hard- und nicht um Softwareprobleme handelt und man sich deshalb auch an der Hardwarehersteller wenden muss, wenn man wissen will was die Ursache ist. Stimmt nur wieder nicht so ganz, denn selbst auf dem MacPro, bei dem es naturgemäß gar keine wie auch immer geartete Unterstützung für Linux und für dieses Modell nicht einmal mehr für MacOS X gibt, habe ich dank mcelog herausgefunden, dass es sich um Speicherfehler handelt.

Bei dir würde ich dagegen davon ausgehen, dass entweder die CPU-Temperatur tatsächlich zu hoch ist oder dass das System sie für zu hoch hält und deswegen die CPU gebremst wird. Das Problem, dass MCEs auftauchten und die CPU angeblich zu heißt war und deswegen gebremst wurde hatte ich mit einigen Kernelversionen auf einem Asus-Netbook auch. Mit der älteren Version hat dafür die Netzwerschnittstelle nur sporadisch funktioniert - erst seit 3.13 läuft auf dem Gerät alles problemlos, also nur nicht aufgeben

[niesommer]

Nein, kenne keine Übersetzung, aber so wahnsinnig hilfreich sind die FAQ auch wieder nicht. Ich habe sie verlinkt, weil drinsteht, dass es sich bei MCEs um Hard- und nicht um Softwareprobleme handelt und man sich deshalb auch an der Hardwarehersteller wenden muss, wenn man wissen will was die Ursache ist. Stimmt nur wieder nicht so ganz, denn selbst auf dem MacPro, bei dem es naturgemäß gar keine wie auch immer geartete Unterstützung für Linux und für dieses Modell nicht einmal mehr für MacOS X gibt, habe ich dank mcelog herausgefunden, dass es sich um Speicherfehler handelt.

Aha, das ist sehr interessant.

Bei dir würde ich dagegen davon ausgehen, dass entweder die CPU-Temperatur tatsächlich zu hoch ist oder dass das System sie für zu hoch hält und deswegen die CPU gebremst wird. Das Problem, dass MCEs auftauchten und die CPU angeblich zu heißt war und deswegen gebremst wurde hatte ich mit einigen Kernelversionen auf einem Asus-Netbook auch. Mit der älteren Version hat dafür die Netzwerschnittstelle nur sporadisch funktioniert - erst seit 3.13 läuft auf dem Gerät alles problemlos, also nur nicht aufgeben

Ja, so etwas habe ich mir auch schon zusammengereimt, schön das Bestätigt zubekommen.
Och nein, aufgeben kommt nicht in frage. Denn wie ich ja schon schrieb kann ich ja bis jetzt eigentlich ganz normal arbeiten.
Und nach allem was ich bis jetzt über den 3.14er Kernel gelesen habe, könnte der ja auch verbesserungen bringen, allerdings werde ich wohl auf den noch eine weile warten müssen, aber das ist nicht so schlimm. Ich habe ja Geduld.

[niesommer]

Das heutige Kernel-Update scheint auch schon mal Verbesserungen zu bringen, weniger Meldungen und bei den Sensoren habe ich festgestellt das die CPU schneller wieder an Temperatur verliert.

Code: Alles auswählen

 uname -a
Linux tbbt 3.13-0.bpo.1-686-pae #1 SMP Debian 3.13.7-1~bpo70+1 (2014-03-29) i686 GNU/Linux

Tja, da war ich wohl mal wieder zu Voreilig, das Problem mit der NIC ist jetzt noch schlimmer geworden.
mal ein kleiner auszug:

Code: Alles auswählen

Apr  5 14:00:14 localhost kernel: [18447.021185] r8169 0000:02:00.2 eth0: link up
Apr  5 14:00:17 localhost kernel: [18449.137409] r8169 0000:02:00.2 eth0: link down
Apr  5 14:00:25 localhost kernel: [18457.913429] r8169 0000:02:00.2 eth0: link up
Apr  5 14:00:26 localhost kernel: [18458.781950] r8169 0000:02:00.2 eth0: link down
Apr  5 14:00:30 localhost kernel: [18462.655932] r8169 0000:02:00.2 eth0: link up
Apr  5 14:00:50 localhost kernel: [18482.722600] r8169 0000:02:00.2 eth0: link down
Apr  5 14:01:16 localhost kernel: [18503.902621] r8169 0000:02:00.2 eth0: link down
Apr  5 14:01:16 localhost kernel: [18503.902654] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Apr  5 14:01:46 localhost kernel: [18534.440623] r8169 0000:02:00.2 eth0: link down
Apr  5 14:01:46 localhost kernel: [18534.440665] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Apr  5 14:01:48 localhost kernel: [18535.801794] r8169 0000:02:00.2 eth0: link down
Apr  5 14:01:48 localhost kernel: [18535.801831] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Apr  5 14:02:42 localhost kernel: [18590.134998] r8169 0000:02:00.2 eth0: link up
Apr  5 14:02:42 localhost kernel: [18590.135007] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Code: Alles auswählen

Apr  5 17:18:23 localhost kernel: [ 8192.508677] r8169 0000:02:00.2 eth0: link down
Apr  5 17:18:26 localhost kernel: [ 8195.178855] r8169 0000:02:00.2 eth0: link up
Apr  5 17:18:48 localhost kernel: [ 8217.453961] r8169 0000:02:00.2 eth0: link down
Apr  5 17:21:43 localhost kernel: [ 8392.393118] r8169 0000:02:00.2 eth0: link up
Apr  5 17:21:44 localhost kernel: [ 8393.490911] r8169 0000:02:00.2 eth0: link down
Apr  5 17:21:47 localhost kernel: [ 8395.835290] r8169 0000:02:00.2 eth0: link up
Apr  5 17:26:04 localhost kernel: [ 8653.512270] r8169 0000:02:00.2 eth0: link down
Apr  5 17:26:07 localhost kernel: [ 8656.261848] r8169 0000:02:00.2 eth0: link up
Apr  5 17:28:20 localhost kernel: [ 8789.402623] r8169 0000:02:00.2 eth0: link down
Apr  5 17:30:13 localhost kernel: [ 8902.798897] r8169 0000:02:00.2 eth0: link up

Ich werde das mal rausnehmen

Code: Alles auswählen

pcie_aspm=force

und mal schauen.

[niesommer]

So habe eine neue seltsamkeit herrausgefunden. Zuerstmal habe ich jetzt kernel boot optionen geändert.

Code: Alles auswählen

cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-3.13-0.bpo.1-686-pae root=/dev/mapper/tbbt-root ro quiet pcie_aspm=off acpi_osi=linux

Weiter habe ich festgestellt sobald ich den laptop im Batteriebetrieb habe geht die Nic down und dann habe ich jetzt diesen neue Meldung:

Code: Alles auswählen

NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.

Es scheint immer verrückter zu werden.
Ich werde den Rechner jetzt mit folgenden Optionen fahre und sehen was passiert:

Code: Alles auswählen

pcie_aspm=force acpi_osi=linux nmi_watchdog=0

So nachdem ich jetzt den Rechner neugestartet habe:

Code: Alles auswählen

/proc/cmdline 
BOOT_IMAGE=/vmlinuz-3.13-0.bpo.1-686-pae root=/dev/mapper/tbbt-root ro quiet acpi_osi=linux nmi_watchdog=0 pcie_aspm=force

sehe ich immer noch diese sachen.

Code: Alles auswählen

Apr  7 09:56:20 localhost kernel: [   88.653559] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
Apr  7 09:56:54 localhost kernel: [  122.860785] ACPI : EC: GPE storm detected(9 GPEs), transactions will use polling mode

subjektiv wahrnehmbar geändert hat sich die lüfter steuerung der dreht wieder sehr stark. scheint also auch nix zu bringen. So werde jetzt mal wieder in den Batteriebetrieb wechseln, wenn sich etwas positiv ändert schreib ich das sonst ist alles beim alten und ich muss erst wieder schauen wie ich die Nic online bekomme.

[rendegast]

Der 3.13 wheezy-backports scheint mir mittlerweile etwas vermurkst.
Gestern kam 3.13.7-1~bpo70+1

Code: Alles auswählen

$ dpkg -l | grep linux-ima
ii  linux-image-3.12-0.bpo.1-68 3.12.9-1~bpo70+1   i386               Linux 3.12 for modern PCs
ii  linux-image-3.13-0.bpo.1-68 3.13.7-1~bpo70+1   i386               Linux 3.13 for modern PCs
ii  linux-image-3.2.0-4-686-pae 3.2.54-2           i386               Linux 3.2 for modern PCs

und diesen auch mal gebootet (linux-image-3.13-0.bpo.1 war bis dahin nur zusätzlich installiert).
1. Beobachtung das Ding reagiert hakelig, ein htop-Prozeß bleibt dauerhaft auf 17-18% CPU.
Umgebootet auf den linux-image-3.12-0.bpo.1, Rechner reagiert wieder agil, htop 1% CPU.
(auf dem 64bitter aber keine solche Beobachtung)

Vielleicht sollte wie bei amerikanischen Hochhäusern auf die "13" verzichtet werden.

[niesommer]

Hallo rendegast,
Habe das ganze jetzt auch mit dem 3.12 getestet und ja ich habe auch neugebootet und bei den upadtes bin ich auf dem neuesten stand.

Code: Alles auswählen

dpkg -l | grep linux-ima
ii  linux-image-3.12-0.bpo.1-686-pae  3.12.9-1~bpo70+1                  i386         Linux 3.12 for modern PCs
ii  linux-image-3.13-0.bpo.1-686-pae  3.13.7-1~bpo70+1                  i386         Linux 3.13 for modern PCs
ii  linux-image-3.2.0-4-686-pae         3.2.54-2                    i386         Linux 3.2 for modern PCs
ii  linux-image-686-pae         3.13+56~bpo70+1           i386         Linux for modern PCs (meta-package)

Leider keine Änderung, ich werde wohl in der nächsten zeit den Laptop mit Netzstrom versorgen, denn dann funktioniert das mit der Nic, problematisch ist dann nur das zuklappen und wieder aufklappen denn dort verschwindet die NIC dann auch manchmal, bekomme die aber immer wieder on.
Ich frage mich was sich geändert hat im Februar, denn ungefähr seit dem haben die Probleme mit der NIC ja angefangen und da hatte ich noch den 3.2er Kernel und deswegen mitlerweile die Backportskernel, verstehen tue ich das nicht.

[smutbert]

Aber sag noch einmal:

Im Ursprungszustand hat alles funktioniert, bis auf dass im Akkubetrieb die Netzwerkverbindung nur sporadisch funktioniert hat?

[niesommer]

Aber sag noch einmal:

Im Ursprungszustand hat alles funktioniert, bis auf dass im Akkubetrieb die Netzwerkverbindung nur sporadisch funktioniert hat?

Nein, das war etwa ein Jahr lang alles i.o. im Februar hatte ich dann sporadisch netzwerk abbrüche und auch mal Komplett abstürze (der Laptop ging teilweise einfach aus) bis ende März steigerte sich das dann so das ich entsprechend nachforschungen betrieb. Alles andere steht hier in dem Beitrag.
Was hier nicht drin steht, weil ich denke das das nicht relevant ist, ist das ich zuerst den network-manager als Fehlerquelle vermutete aber mit oder ohne den NM blieb alles gleich.
Das mit dem Akkubetrieb habe ich erst heute so richtig feststellen können, denn sobald ich den Netzstecker ziehe geht die NIC down und kommt nicht mehr hoch auch dann nicht wenn ich den Stromstecker wieder reinstecke, da hilft nur ein neustart.
in den logs steht dann folgendes drin:

Code: Alles auswählen

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

Das hat jetzt etwas länger gedauert, weil jetzt der Laptop gerade ausging ohne Vorwarnung und ohne irgendetwas in den Logs zu hinterlassen, zumindest habe ich nichts gefunden und mcelog gibt auch nichts aus.

[smutbert]

Ach so.

Naja, jedenfalls, hat mich dirk11s xfce-powermanager-Thread auf die pm-utils gebracht. Die enthalten auch ein Stromsparskript für PCI-Geräte: /usr/lib/pm-utils/power.d/pci_devices
Wenn es das ist, das jetzt die Probleme bei dir verursacht, könntest du es mit

Code: Alles auswählen

touch /etc/pm/power.d/pci_devices

lahmlegen.

[niesommer]

Ach so.

Naja, jedenfalls, hat mich dirk11s xfce-powermanager-Thread auf die pm-utils gebracht. Die enthalten auch ein Stromsparskript für PCI-Geräte: /usr/lib/pm-utils/power.d/pci_devices
Wenn es das ist, das jetzt die Probleme bei dir verursacht, könntest du es mit

Code: Alles auswählen

touch /etc/pm/power.d/pci_devices

lahmlegen.

So das habe ich jetzt erstmal gemacht, im moment kann ich nicht sagen ob es was gebracht hat oder nicht. Ich werde das beobachten und auch nochmal in den Batteriebetrieb gehen mal sehen was passiert.

So Batteriebetrieb getestet, NIC geht down und bleibt down, stromkabel wieder reingesteckt und karte kommt nach ca. einer Minute wieder ON

Code: Alles auswählen

Apr  7 12:45:25 localhost kernel: [ 2623.514626] r8169 0000:02:00.2 eth0: link down
Apr  7 12:45:25 localhost kernel: [ 2623.514673] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Apr  7 12:47:09 localhost kernel: [ 2727.967273] r8169 0000:02:00.2 eth0: link up
Apr  7 12:47:09 localhost kernel: [ 2727.967283] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Und diese Meldung ist geblieben

Code: Alles auswählen

NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.

werde weiter beobachten.

[niesommer]

So war jetzt mal eine weile unterwegs und der Laptop zugeklappt und am Stromnetz angeschlossen, wiedergekommen aufgeklappt NIC war down und blieb es auch weder ein:
ifconfig eth0 up /down noch /etc/init.d/network-manager start/stop/restart und sogar das entladen und laden der module mit rmmod und modprobe r8169 brachten die Nic wieder also neustarten, aber die nic blieb down wieder ausgeschalten ca. 3 min gewartet und wieder angeschaltet nic geht jetzt wieder. neue log infos gibts keine. Moment ich wollte gerade den Beitrag abschicken und noch mal ein blick in die /var/log/messages gemacht und siehe da hier steht jetzt ganz viel neues:
pastebin.php?mode=view&s=37768

könntes das damit was tun haben?

Code: Alles auswählen

touch /etc/pm/power.d/pci_devices

Ich glaube so langsam das mein laptop mich veralbern will.

[smutbert]

Ich kann mir beim besten Willen nicht vorstellen, dass das etwas miteinander zu tun hat. Das Skript ist Teil des Pakets pm-utils und Debian sollte ja auch ohne pm-utils laufen, zumindest tut es das auf allen Computern, die ich kenne.

[niesommer]

Ich kann mir beim besten Willen nicht vorstellen, dass das etwas miteinander zu tun hat. Das Skript ist Teil des Pakets pm-utils und Debian sollte ja auch ohne pm-utils laufen, zumindest tut es das auf allen Computern, die ich kenne.

Das habe ich mir auch schon gedacht. Ich werde jetzt mal zu diesem mittel greifen und hoffen das meine kiste nicht kaputt geht:

Code: Alles auswählen

acpi_enforce_resources=lax

also wenn ihr länger nichts von mir hört ist die kiste kaput.