problem mit onboard realtek-nic

Seite 1 von 1 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/problem-mit-onboard-realtek-nic_236826/page_1 - zur Vollversion wechseln!

davebastard schrieb am 20.11.2013 um 21:08

genauer gesagt um eine Realtek 8111D onboard NIC

hab mit dem chip schon öfter probleme gehabt => immer nach einem kernelupdate ging die NIC nicht weil scheinbar irgendwas an der notwendigen software nicht frei ist => mit dem Realtek treiber von deren website gings aber dann immer.

Seit dem letzten Kernelupdate hab ich aber das Problem dass ich direkt nach dem hochfahren des Systems immer ein

Code:

rmmod r8168 && modprobe r8168

ausführen muss weil sonst die NIC nicht geht OBWOHL das kernelmodul direkt nach dem booten geladen ist. Anscheinend hilft aber ein neu laden des moduls.

wie könnt ich das beheben ?

was ich schon probiert hab:
neben den Realtek treibern von der hp (ein skript erzeugt die notwendigen kernelmodule) hab ich dann auch noch das paket "firmware-realtek" aus non-free versucht (stand irgendwo im netz) => selbes ergebnis

jemand ideen ? kanns sein dass noch immer die "falschen" kernelmodule von realtek direkt geladen werden und nicht die richtigen von debian selbst ?

infos:

debian jessie
kernel 3.10-3-amd64
gnome3

Code:

modinfo r8168
filename:       /lib/modules/3.10-3-amd64/kernel/drivers/net/ethernet/realtek/r8168.ko
version:        8.037.00-NAPI
license:        GPL
description:    RealTek RTL-8168 Gigabit Ethernet driver
author:         Realtek and the Linux r8168 crew <netdev@vger.kernel.org>
srcversion:     4B9CB513BB22516F2449F45
alias:          pci:v00001186d00004300sv00001186sd00004B10bc*sc*i*
alias:          pci:v000010ECd00008168sv*sd*bc*sc*i*
depends:        
vermagic:       3.10-3-amd64 SMP mod_unload modversions 
parm:           eee_enable:int
parm:           speed:force phy operation. Deprecated by ethtool (8). (ushort)
parm:           duplex:force phy operation. Deprecated by ethtool (8). (int)
parm:           autoneg:force phy operation. Deprecated by ethtool (8). (int)
parm:           aspm:Enable ASPM. (int)
parm:           s5wol:Enable Shutdown Wake On Lan. (int)
parm:           rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm:           use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm:           debug:Debug verbosity level (0=none, ..., 16=all) (int)

http://www.realtek.com.tw/Downloads...p;GetDown=false

davebastard schrieb am 21.11.2013 um 17:29

niemand ?

edit: workaround wär eine intel NIC dazukaufen, welche wär den sinnvoll ?

http://geizhals.at/intel-gigabit-ct...ct-a351749.html
die ?

t3mp schrieb am 21.11.2013 um 18:44

Ich glaub meine radeontestbox hat denselben NIC, da macht's eigentlich keine Probleme. Hatte aber noch keine Zeit, mir das anzuschauen.

davebastard schrieb am 21.11.2013 um 20:21

ist es nach dem kernelupdate so dass es ohne dein zutun funzt ?

du hast aber afaik gentoo oder ?

edit: aber auf jedenfall schonmal danke fürs nachschauen

edit2:
ok geht wieder alles
scheinbar sind seit dem letzten mal wo ich mich mit dem problem beschäftigt hab (2-3 wochen) ein haufen updates gekommen, darunter auch ein kernelupdate, jetzt funzts ohne irgendwelche downloads von realtek

t3mp schrieb am 21.11.2013 um 23:48

Zitat von davebastard
ist es nach dem kernelupdate so dass es ohne dein zutun funzt ?

du hast aber afaik gentoo oder ?

Ja/ja, hab dafür noch nie irgendetwas out-of-kernel gebraucht. Die Module werden bei einem Kernelupdate in ein entsprechend versioniertes /lib/modules/<kernelversion> directory installiert, da kann also eigentlich kein Überbleibsel dreinpfuschen. Außer, Debian führt dabei gleichzeitig auch eine Art module-rebuild für externe Packages durch. Aber so wie's aussieht war es eh nur ein temporary lapse.

Das Erste, was ich bei derlei Probleme machen würde, wäre den letzten funktionierenden Fallback-Kernel wieder booten.

davebastard schrieb am 22.11.2013 um 08:41

Zitat
Das Erste, was ich bei derlei Probleme machen würde, wäre den letzten funktionierenden Fallback-Kernel wieder booten.

und den verwenden bis ein update kommt meinst ?

t3mp schrieb am 22.11.2013 um 11:48

Genau. Nachdem Regressions bei meiner alten Intel-GPU eher die Regel denn die Ausnahme geworden sind, bin ich bei Kernel-Updates defensiver geworden. Ich probier jedes neue Major Release aus um zu sehen ob es Fixes gibt, und bin dann aber bisher immer noch gezwungen gewesen wieder auf 3.4 zurück zu gehen. Nachdem das ein LTS Kernel ist, gibt es davon ebenso immer aktuelle Security- und Bugfix-Releases.