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

[niesommer]

Hallo,
Ich hoffe mit meinen Fragen hier richtig zu sein. vielleicht hat auch jemand einen Vorschlag wie ich den Titel aussagekräftiger hinbekomme.
Nun zu meinen fragen:
1.) Seit einiger Zeit habe ich ein Problem mit meiner Netzwerkkarte, heute war es so schlimm das ich mich auf die suche machte und bin eigentlich auch fündig geworden. : http://wiki.hetzner.de/index.php/Instal ... 8-Treibers Die beschreibung passt perfekt zu meinem Problem. Meine Frage dazu: gibt es eine andere Möglichkeit als sich das Kernelmodul selbst zu bauen, also zum beispiel auf jessie zu wechseln oder hätte ich dann wieder das selbe problem? hier meine NIC:

Code: Alles auswählen

02:00.2 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 0a)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: r8169

2.) Nebenbei habe ich dann noch folgendes festgestellt: ausgabe von lspci -nnk

Code: Alles auswählen

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]

Wie man sieht ist hier kein treiber geladen, hatte mich bisher auch nicht gestört, ich weiß nicht mal was das ist. Bei meiner Internetsuche habe ich dann verschiedene Beiträge gesehen bei denen entweder das Modul mei oder mei_me geladen war. Die frage dazu ist was muss ich installieren damit das was auch immer das ist richtig funktioniert?
Das selbe habe ich dann noch hier:

Code: Alles auswählen

00:1f.0 ISA bridge [0601]: Intel Corporation HM76 Express Chipset LPC Controller [8086:1e59] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device [10ec:5289] (rev 01)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]

Würde es sinn machen auf jessie zu wechseln, bzw. was müsste ich installieren damit das unter Wheezy funktioniert?
Würde mich freuen wenn mir jemand sagen könnte was das überhaupt alles ist.
Achja ich verwende der zeit Debian wheezy. Falls ihr noch andere Infos braucht, versuche ich die zu liefern.
Mal abgesehen von Problem 1 kann ich mit meinem Rechner normal arbeiten

[mragucci]

Du könntest ja zunächst versuchen einen aktuell(eren) Kernel aus den Backports zu installieren.

[niesommer]

Du könntest ja zunächst versuchen einen aktuell(eren) Kernel aus den Backports zu installieren.

Ja darüber habe ich auch schon nachgedacht, aber wenn ich den 3.12er Kernel installieren will dann will er den 3.2er Kernel löschen und das finde ich nicht so gut weil ich nicht weiß ob der Rechner mit dem 3.12 ordentlich arbeitet und dann wäre es gut einen Ersatz Kernel zu haben.
Seltsam finde ich auch das bei einem Upgrade auf Jessie (auf meinem Test Rechner) der 3.2er Kernel erhalten bleibt und ich somit unter jessie beide Kernel nutzen kann. Oder gibt es da einen Trick um das zu verhindern.

[smutbert]

Wieso will er denn 3.2 löschen - vielleicht wegen zu alter initramfs-tools?
In den Backports ist übrigens bereits 3.13. Wenn du explizit

initramfs-tools
linux-image-3.13-0.bpo.1-amd64
firmware-linux-nonfree

(letzteres nur falls du es bereits installiert hast oder brauchst) aus den Backports installierst, sollte er Kernel 3.2 mMn nicht deinstallieren wollen.


zum eigentlichen Problem: Das von Hetzner beschriebene ist glaube ich das hier
http://adam.rosi-kessel.org/weblog/2008 ... wn-problem
(laut link hilft es vor dem Aktivieren der Verbindung autonegotiation abzuschalten, allerdings sollte dieses Problem wohl bereits in Wheezy längst gelöst sein)

[rendegast]

Code: Alles auswählen

# modinfo r8169
filename:       /lib/modules/3.13-custom/kernel/drivers/net/ethernet/realtek/r8169.ko
firmware:       rtl_nic/rtl8168g-3.fw
firmware:       rtl_nic/rtl8168g-2.fw
firmware:       rtl_nic/rtl8106e-2.fw
firmware:       rtl_nic/rtl8106e-1.fw
firmware:       rtl_nic/rtl8411-2.fw
firmware:       rtl_nic/rtl8411-1.fw
firmware:       rtl_nic/rtl8402-1.fw
firmware:       rtl_nic/rtl8168f-2.fw
firmware:       rtl_nic/rtl8168f-1.fw
firmware:       rtl_nic/rtl8105e-1.fw
firmware:       rtl_nic/rtl8168e-3.fw
firmware:       rtl_nic/rtl8168e-2.fw
firmware:       rtl_nic/rtl8168e-1.fw
firmware:       rtl_nic/rtl8168d-2.fw
firmware:       rtl_nic/rtl8168d-1.fw
...

-> firmware-realtek am besten gleich aus den backports.

Code: Alles auswählen

# modprobe -c | egrep -i "1e3a"
alias pci:v00008086d00001E3Asv*sd*bc*sc*i* mei_me
(description:    Intel(R) Management Engine Interface)

# modprobe -c | egrep -i "1e59"
alias pci:v00008086d00001E59sv*sd*bc*sc*i* lpc_ich
(description:    LPC interface for Intel ICH) (? -> wikipedia)
..

# modprobe -c | egrep -i "1e22"
alias pci:v00008086d00001E22sv*sd*bc*sc*i* i2c_i801
(Sensor-Kram)

# modprobe -c | egrep -i "5289"
..
alias pci:v000010ECd00005289sv*sd*bcFFsc*i* rtsx_pci
(description:    Realtek PCI-E Card Reader Driver)

[niesommer]

@smutbert
Das werde ich nachher gleich einmal ausprobieren, mal sehen ob das was bringt.
@rendegast
vielen dank für die Infos, die Firmware werde ich auch gleich mit installieren, derzeit ist die Version aus wheezy installiert.

Ich melde mich nochmal nach dem ich eure Vorschläge umgesetzt habe.

[niesommer]

So habe eure Vorschläge umgesetzt und jetzt habe ich

Code: Alles auswählen

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

am laufen und mein 3.2er kernel wurde nicht gelöscht.
lspci -nnk zeigt jetzt folgendes an:

Code: Alles auswählen

00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: i915
00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: xhci_hcd
00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: mei_me
00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: ehci-pci
00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4)
        Kernel driver in use: pcieport
00:1c.3 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 [8086:1e16] (rev c4)
        Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: ehci-pci
00:1f.0 ISA bridge [0601]: Intel Corporation HM76 Express Chipset LPC Controller [8086:1e59] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: lpc_ich
00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device [10ec:5289] (rev 01)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: rtsx_pci
02:00.2 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 0a)
        Subsystem: CLEVO/KAPOK Computer Device [1558:0240]
        Kernel driver in use: r8169

Es hat sich einiges getan. Das Verhalten meiner Netzwerkkarte werde ich jetzt erst einmal beobachten, mit etwas glück war es das ja schon.
Dank eurer Hilfe
Eine Frage hätte ich da allerdings noch, da ich nicht viel Erfahrung mit den Backports habe, wie läuft das mit den updates?
Werden die Pakete bei apt-get upgrade bzw. dist-upgrade mit gemacht, oder muss ich dann was spezielles angeben?

[smutbert]

Grundsätzlich werden die Pakete aus den Backports ganz normal upgedatet, beim Kernel ist es allerdings soweit ich gelesen habe so:

Sobald eine neue Version in den Backports auftaucht (jetzt also zB 3.14) kann man sich nicht mehr darauf verlassen, dass die vorige auch noch Aktualisierungen erhält und von 3.13 auf 3.14 würde nur automatisch aktualisiert, wenn auch das Metapaket aus den Backports installiert ist. (Also eigentlich das gleiche wie in testing - daher kommen die Pakete in den Backports ja auch üblicherweise)

Ich würde also sicherheitshalber auch noch das Metapaket linux-image-amd64 auf die Version aus den Backports aktualisieren.

[niesommer]

Grundsätzlich werden die Pakete aus den Backports ganz normal upgedatet, beim Kernel ist es allerdings soweit ich gelesen habe so:

Sobald eine neue Version in den Backports auftaucht (jetzt also zB 3.14) kann man sich nicht mehr darauf verlassen, dass die vorige auch noch Aktualisierungen erhält und von 3.13 auf 3.14 würde nur automatisch aktualisiert, wenn auch das Metapaket aus den Backports installiert ist. (Also eigentlich das gleiche wie in testing - daher kommen die Pakete in den Backports ja auch üblicherweise)

Ich würde also sicherheitshalber auch noch das Metapaket linux-image-amd64 auf die Version aus den Backports aktualisieren.

OK, vielen dank Ich werde mal schauen.

[dirk11]

Sobald eine neue Version in den Backports auftaucht (jetzt also zB 3.14) kann man sich nicht mehr darauf verlassen, dass die vorige auch noch Aktualisierungen erhält und von 3.13 auf 3.14 würde nur automatisch aktualisiert, wenn auch das Metapaket aus den Backports installiert ist. (Also eigentlich das gleiche wie in testing - daher kommen die Pakete in den Backports ja auch üblicherweise)

Ich würde also sicherheitshalber auch noch das Metapaket linux-image-amd64 auf die Version aus den Backports aktualisieren.

Ja, genau so ist es.

[niesommer]

Also ich habe mal nach einem Meta-Package für meinen Kernel gesucht es scheint aber keines zu geben für den 3.13erkernel
installiert habe ich folgende:

Code: Alles auswählen

 dpkg -l | grep linux-image-
ii  linux-image-3.13-0.bpo.1-686-pae             3.13.5-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.2+46                             i386         Linux for modern PCs (meta-package)

Gesucht habe ich folgender maßen:

Code: Alles auswählen

apt-cache search linux-image-686
linux-image-686 - Linux für moderne PCs (Übergangspaket)
linux-image-686-bigmem - Linux für PCs mit 4 GB RAM oder mehr (Übergangspaket)
linux-image-686-pae - Linux für moderne PCs (Metapaket)
linux-image-686-pae-dbg - Debugging symbols for Linux 686-pae configuration (meta-package)

Wie ihr seht habe ich nur das Meta-package für den 3.2er kernel installiert, und achja ich verwende 32Bit. Und habe keine lust neu zu installieren um auf 64 bit zukommen, zumal ich ein spiel habe was ich sehr mag und das ist nur 32 Bit, das habe ich noch nicht auf einem 64bit rechner zum laufen bekommen, aber das ist eben eine andere sache.
Aber vielleicht mache ich ja noch irgend etwas nicht so richtig, um das Meta-Package zu finden, und ihr habt noch ein paar Tips für mich auf lager?
Also ich habe da nochmal was anderes versucht:

Code: Alles auswählen

apt-cache showpkg linux-image-686-pae
Package: linux-image-686-pae
Versions: 
3.13+56~bpo70+1 (/var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy-backports_main_binary-i386_Packages)
 Description Language: 
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_binary-i386_Packages
                  MD5: 1ec28d21bf21fb48dac680de73344d2d
 Description Language: de
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_i18n_Translation-de
                  MD5: 1ec28d21bf21fb48dac680de73344d2d
 Description Language: en
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_i18n_Translation-en
                  MD5: 1ec28d21bf21fb48dac680de73344d2d

3.2+46 (/var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_binary-i386_Packages) (/var/lib/dpkg/status)
 Description Language: 
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_binary-i386_Packages
                  MD5: 1ec28d21bf21fb48dac680de73344d2d
 Description Language: de
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_i18n_Translation-de
                  MD5: 1ec28d21bf21fb48dac680de73344d2d
 Description Language: en
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_i18n_Translation-en
                  MD5: 1ec28d21bf21fb48dac680de73344d2d


Reverse Depends: 
  linux-image-686-bigmem,linux-image-686-pae
  linux-image-686,linux-image-686-pae
  linux-image-2.6-686-pae,linux-image-686-pae
  linux-image-2.6-686-bigmem,linux-image-686-pae
  linux-image-2.6-686,linux-image-686-pae
Dependencies: 
3.13+56~bpo70+1 - linux-image-3.13-0.bpo.1-686-pae (0 (null)) 
3.2+46 - linux-image-3.2.0-4-686-pae (0 (null)) 
Provides: 
3.13+56~bpo70+1 - linux-latest-modules-3.13-0.bpo.1-686-pae 
3.2+46 - linux-latest-modules-3.2.0-4-686-pae 
Reverse Provides:

Wenn ich das richtig verstehe dann ist das Metapackage linux-image-686-pae auch für den 3.31er Kernel zuständig, damit werden dann also auch die updates entsprechend eingspielt.

[smutbert]

Hehe, du hast die Antwort doch eigentlich schon selbst gepostet:

zwei Versionen von linux-image-686-pae sind über deine Paketquellen verfügbar:
- 3.2+46 aus wheezy
- 3.13+56~bpo70+1 aus wheezy-backports

Du hast ersteres installiert, das dafür sorgt, dass immer der neuste Kernel aus wheezy/stable installiert ist. Installierst du dagegen zweiteres, sorgt das für den neusten Kernel aus den Backports:

Code: Alles auswählen

apt-get install linux-image-686-pae/wheezy-backports

[niesommer]

Hehe, du hast die Antwort doch eigentlich schon selbst gepostet:

zwei Versionen von linux-image-686-pae sind über deine Paketquellen verfügbar:
- 3.2+46 aus wheezy
- 3.13+56~bpo70+1 aus wheezy-backports

Du hast ersteres installiert, das dafür sorgt, dass immer der neuste Kernel aus wheezy/stable installiert ist. Installierst du dagegen zweiteres, sorgt das für den neusten Kernel aus den Backports:

Code: Alles auswählen

apt-get install linux-image-686-pae/wheezy-backports

vielen dank für Deine Erklärung, aber ich bin mir oft sehr unsicher bei der Interpretation solcher ausgaben zumal ich mit Backports keine Erfahrung habe, da ich sie bisher immer vermieden habe und dann lieber gleich testing benutzt habe. Aber so wie es jetzt ist scheint alles gut zu sein, ich hatte bis jetzt noch keine aussetzer im Netz und irgendwie habe ich das gefühl das der Rechner jetzt sogar Performanter ist und der Lüfter dreht auch nicht mehr so stark.
Noch einmal ein großes Dankeschön an alle die Geholfen haben.

[rendegast]

Noch einen aus der Trick-Kiste

Code: Alles auswählen

# dpkg -l | grep linux-ima
...
ii  linux-headers-3.2.0-5-amd64             1.0-dummy                          amd64        dummy linux-headers-3.2.0-5-amd64
ii  linux-headers-3.2.0-6-amd64             1.0-dummy                          amd64        dummy linux-headers-3.2.0-6-amd64
ii  linux-headers-amd64                     3.13+56~bpo70+1                    amd64        Header files for Linux amd64 configuration (meta-package)
...
ii  linux-image-3.2.0-5-amd64               1.0-dummy                          amd64        dummy linux-image-3.2.0-5-amd64
ii  linux-image-3.2.0-6-amd64               1.0-dummy                          amd64        dummy linux-image-3.2.0-6-amd64
ii  linux-image-amd64                       3.13+56~bpo70+1                    amd64        Linux for 64-bit PCs (meta-package)
...

Die Meta-Pakete aus backports, da sich da mehr neue kernel tummeln.
Die equivs-dummys als Platzhalter für einen eventuell neuen Standardkernel,
dessen Entwicklung doch um einiges langsamer verläuft.


Eigentlich sollen kernel nicht automatisch gelöscht werden,
aber ich habe schon einen Patch (unter ubuntu?, jessie?, postinst des kernel-Pakets? ) gesehen,
der die Anzahl der kernel auf 2(3) beschränkt.

[niesommer]

Noch einen aus der Trick-Kiste

Code: Alles auswählen

# dpkg -l | grep linux-ima

Ja aber damit siehst du ja nur was du schon installiert hast und nicht was noch zur Installation zur Verfügung steht. Dafür muss man dann doch den apt-cache befragen oder nicht?

Eigentlich sollen kernel nicht automatisch gelöscht werden,
aber ich habe schon einen Patch (unter ubuntu?, jessie?, postinst des kernel-Pakets? ) gesehen,
der die Anzahl der kernel auf 2(3) beschränkt.

Also mir ist es immer ganz recht wenn keine Kernel gelöscht werden, in der Regel funktionieren die ja auch, und wenn ich dann der Meinung bin das ich alte Kernel nicht mehr brauche dann kann ich sie selbst von Hand löschen. Was eigentlich das verhalten ist was ich von Debian kenne, mit der einen Ausnahme wie ich oben beschrieben habe. Aber das könnte ja auch mit den Backports zu tun haben.

[rendegast]

@niesommer,
Du hast leider zweimal falsch verstanden.

Die Platzhalter sorgen dafür, daß falls von debian ein solcher Kernel zur Verfügung steht,
dieser automatisch installiert wird (Version!).
Wegen - in wheezy ist Vorhersehbarkeit des Namens des eventuellen Folgekernels gegeben und für längere Zeit gültig
(diese beiden dummys dürften bis zum Ende von wheezy ausreichen),
in wheezy-backports weniger, daher dort das Metapaket.

Zum anderen, das war eher in Richtung Warnung gemeint, daß dort was im Busch ist,
nicht in Richtung "fantastische neue Möglichkeit".

[niesommer]

@niesommer,
Du hast leider zweimal falsch verstanden.

Die Platzhalter sorgen dafür, daß falls von debian ein solcher Kernel zur Verfügung steht,
dieser automatisch installiert wird (Version!).
Wegen - in wheezy ist Vorhersehbarkeit des Namens des eventuellen Folgekernels gegeben und für längere Zeit gültig
(diese beiden dummys dürften bis zum Ende von wheezy ausreichen),
in wheezy-backports weniger, daher dort das Metapaket.

Ok, dann danke ich dir für die Erklärung

Zum anderen, das war eher in Richtung Warnung gemeint, daß dort was im Busch ist,
nicht in Richtung "fantastische neue Möglichkeit".

Du meinst also das auch Debian die Anzahl der Kernel beschränken will, die man gleichzeitig installiert hat?
Aber welcher sinn oder Zweck steckt dahinter bzw. warum soll man so etwas wollen?

[rendegast]

das auch Debian die Anzahl der Kernel beschränken will, die man gleichzeitig installiert hat?

Schon passiert, apt jessie/sid
/apt_0.9.16.1_amd64/etc/apt/apt.conf.d/01autoremove
/apt_0.9.16.1_amd64/etc/kernel/postinst.d/apt-auto-removal

warum soll man so etwas wollen?

Bugreport, wishlist, das kommt von sowas.

apt (0.9.9.1) unstable; urgency=low

...
* cherry pick debian/apt.auto-removal.sh feature from the
ubuntu/master branch

[ Steve Langasek ]
* debian/apt.conf.autoremove: don't include linux-image*,
linux-restricted-modules*, and linux-ubuntu-modules* packages in the
list to never be autoremoved.
* debian/apt.auto-removal.sh, debian/rules, debian/apt.dirs: install new
script to /etc/kernel/postinst.d/ which ensures we only automatically
keep the currently-running kernel, the being-installed kernel, and the
newest kernel, so we don't fill /boot up with an unlimited number of
kernels. LP: #923876.

[niesommer]

Hallo,
@rendegast
für die Hinweise

Habe heute ca 30 min gebraucht bis ich wieder ins Netz konnte, im Moment scheint es zu gehen.
ifconfig+ping ausgabe Wie ihr seht habe ich zuerst keine IP bekommen dann als ich sie hatte ein haufen verluste. Hat noch jemand eine Idee?
PS: ausgabe von ethtool:

Code: Alles auswählen

#ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 10Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

Speed auf 10MB/s ist mir auch etwas schleierhaft. Aber ich denke ich weiß warum pre-up /usr/sbin/ethtool -s eth1 autoneg off habe ich ausprobiert, wie ihr seht anschalten bringt dann auch wieder volle leistung. Achja das Abschalten bringt keine besserung.

Code: Alles auswählen

#ethtool -S eth0 
NIC statistics:
     tx_packets: 3430
     rx_packets: 3653
     tx_errors: 0
     rx_errors: 858
     rx_missed: 0
     align_errors: 129
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 3476
     broadcast: 83
     multicast: 94
     tx_aborted: 0
     tx_underrun: 0

Code: Alles auswählen

root@tbbt:/home/shelly#ethtool -s eth0 speed 1000 duplex full
Cannot set new settings: Invalid argument
  not setting speed
  not setting duplex

Code: Alles auswählen

root@tbbt:/home/shelly#ethtool -s eth0 autoneg on
root@tbbt:/home/shelly#ethtool -s eth0 speed 1000 duplex full

Code: Alles auswählen

root@tbbt:/home/shelly#ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  1000baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
                                             1000baseT/Half 1000baseT/Full 
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

Code: Alles auswählen

root@tbbt:/home/shelly#ping www.debian.org
PING www.debian.org (130.89.148.14) 56(84) bytes of data.
64 bytes from klecker4.snt.utwente.nl (130.89.148.14): icmp_req=1 ttl=55 time=35.8 ms
64 bytes from klecker4.snt.utwente.nl (130.89.148.14): icmp_req=2 ttl=54 time=40.4 ms
64 bytes from klecker4.snt.utwente.nl (130.89.148.14): icmp_req=3 ttl=55 time=39.8 ms
^C
--- www.debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 35.872/38.726/40.455/2.046 ms

[rendegast]

1.) Seit einiger Zeit habe ich ein Problem mit meiner Netzwerkkarte,
...
Supports auto-negotiation: Yes
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Speed: 10Mb/s
Duplex: Full

(<-> eine "normale" Ausgabe

Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full

)
Haben vielleicht Hund/Katze/Maus am Kabel geknabbert?
Gegenstelle ( Router/Switch? ) defekt?

[niesommer]

Also defekte HW habe ich eigentlich schon ausgeschlossen, Netzwerkkabel habe ich gleich als erstes getauscht, und sonst hängen da noch andere Rechner dran wie netbook meiner frau winxp Laptop meiner Tochter MAC Book PRO und mein Test PC mit Debian Jessie alle laufen über meinen Router und Funktionieren 1a. Ich habe aber noch einen anderen Verdacht um den ich mich gerade gekümmert habe, seit dem 3.13er Kernel bekam ich eine Meldung von cpufreq-utils das der govenor nicht korrekt ist. also habe ich ein:

Code: Alles auswählen

cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Bitte melden Sie Fehler an cpufreq@vger.kernel.org.
analysiere CPU 0:
  Treiber: intel_pstate
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0
  Maximale Dauer eines Taktfrequenzwechsels: 0.00 ms.
  Hardwarebedingte Grenzen der Taktfrequenz: 800 MHz - 2.40 GHz
  mögliche Regler: performance, powersave
  momentane Taktik: die Frequenz soll innerhalb 2.40 GHz und 2.40 GHz.
                    liegen. Der Regler "performance" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
analysiere CPU 1:
  Treiber: intel_pstate
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 1
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 1
  Maximale Dauer eines Taktfrequenzwechsels: 0.00 ms.
  Hardwarebedingte Grenzen der Taktfrequenz: 800 MHz - 2.40 GHz
  mögliche Regler: performance, powersave
  momentane Taktik: die Frequenz soll innerhalb 2.40 GHz und 2.40 GHz.
                    liegen. Der Regler "performance" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.

gemacht und siehe da er kann jetzt kein ondemand mehr also habe ich das entsprechend angepasst Batterie auf Powersave und Netz auf Performance gesetzt. Rechner neugestartet. Die Ausgabe von ethtool eth0 sieht jetzt so aus:

Code: Alles auswählen

root@tbbt:/home/shelly#ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
                                             1000baseT/Half 1000baseT/Full 
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

Vielleicht kommt die Karte ja irgendwie nicht mit den Energiespareinstellungen nicht zurecht. Das ist mir alles etwas schleierhaft, zumal ich jetzt ja fast ein Jahr mit dem Rechner arbeite und eigentlich alles funktionierte. wie gesagt mein ausgangsproblem habe ich noch nicht lange, aber genau kann ich das leider nicht sagen da es mich zu anfang nicht störte weil es zu selten vorkam.

[rendegast]

das der govenor nicht korrekt ist. also habe ich ein:

Treiber: intel_pstate

Gab hier vor kurzem einen Thread,
neue Technik, wohl noch nicht richtig implementiert / "wackelig".

Aber daß das was mit der Netzwerkkarte zu tun haben soll / hat? Wer weiß? Beobachten.

[niesommer]

das der govenor nicht korrekt ist. also habe ich ein:

Treiber: intel_pstate

Gab hier vor kurzem einen Thread,
neue Technik, wohl noch nicht richtig implementiert / "wackelig".

Aber daß das was mit der Netzwerkkarte zu tun haben soll / hat? Wer weiß? Beobachten.

Ich danke dir für deine Bemühungen , und beobachte es weiterhin.
Ich noch einen Beitrag eröffnet "ACPI Warnungen" hast du bestimmt schon gesehen, nicht das das damit irgendwie zusammenhängt, bin wegen diesen Beitrag hier darauf aufmerksam geworden. Ich kann nicht sagen ob es diese Warnung schon vorher gab.

[niesommer]

Hallo ,
Also ich habe folgendes beobachtet, die NIC geht scheinbar nur noch down im Batteriebetrieb, nach meinen Beobachtungen fängt das ungefähr bei ca 50% ladestand des Akku an. Daraus schließe ich das die NIC probleme mit dem energiesparen hat, und fühle meine sicht durch diese Meldung aus der /var/log/messages bestätigt.

Code: Alles auswählen

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

Die frage ist nun wie kann ich dafür sorgen, das die NIC vom energiespar-managetment ausgeschlossen wird, dann verbraucht die zwar mehr strom aber ich vermute das die NIC dann nicht mehr down geht und ich keine aussetzer mit dem Netz habe.

[smutbert]

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
pcie_aspm=force

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

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.