Hallo Zusammen, Ich möchte von Windows auf Linux(debian) umzusteigen und habe ich mir Wheezy 64bit (noch parallel zu Win 7) installiert. Dieses funktioniert hervorragend, aber: Nachdem ich einmal Win 7 gestartet habe und danach wieder debian, bekomme ich keine Netzwerkverbindung mehr. Es handelt sich bei der 'Netzwerkkarte' um einen Intel I217-V - Controller (debian-Treiber: e1000e) auf einem Z87-Board. Wenn ich Linux Mint | ubuntu statt debian nehme, gibt es dieses Problem nicht. [Für die Spassvögel-> "dann nimm doch mint | ubuntu" ist keine Option] Ich bekam den Tipp, nach einer Win-Sitzung den PC runterfahren und kurz vom Stromnetz zu trennen. Danach Debian starten... Was soll ich sagen: das klappt, aber es ist für mich keine Endlösung, da ich immer unter den Tisch krabbeln muss, bevor ich mit Debian arbeiten kann. ^^ Somit ist für mich eine schaltbare Steckerleiste auch keine Lösung, sondern nur eine Linderung! Wenn jemand da eine (echte) Lösung hat, freue ich mich riesig... MfG KlausX
Schau mal nach welchen Treiber ubuntu nimmt und installier den
Jetzt auch nicht das was du wolltest, aber wie wär es wenn du win in qemu oder ähnlichem laufen lässt ?
Du könntest auch eine 2. Netzwerkkarte kaufen und diese für Windows sperren. Ich habe den umstieg auch vor etwar 4 monaten gewagt. Die erste zeit mit Neustarten zu windows dann nurnoch über Vmware. Und jetzt habe ich noch genau ein Programm für das ich windows in der vmware verwende. Endlich Frei
@Test: ja, ok. Das mach ich... aber was ist, wenn es auch der e1000e ist? @Herr Ast: An sich nicht schlecht, aber ich habe scheinbar nicht alle wichtigen Detils erwähnt... unter Win7 mache ich unter anderem Videoschnitt/Videobearbeitung. Da ist meine Kiste (hier ist der PC gemeint ; -) so manches mal am 'schwitzen'. Das dann auch noch in einer VM auslagern... besser nicht @Kuba Kriese: Super, da will ich auch hin (Umstieg geschafft). Aber: was soll ich von einem Betriebssystem halten, das nicht mal eine recht gängige Hardware sauber einbinden kann und gleich aus dem Takt kommt, wenn WinDoofs diese vorher 'benutzt' hat ; -) Ne, Spass bei Seite... darauf wird es wohl hinauslaufen (wenn ich keine bessere Lösung finde). Da die Schnittsoftware (Win) sehr teuer war und ich mich da richtig reingefuchst habe, werde ich diese auch noch weiter nutzen wollen. OK Jungs... erst mal vielen Dank für eure Hilfe... So ganz ist das aber noch nicht das, was ich gerne hätte... best regards KlausX
Hallo KlausX, KlausX schrieb: > An sich nicht schlecht, aber ich habe scheinbar nicht alle wichtigen > Detils erwähnt... unter Win7 mache ich unter anderem > Videoschnitt/Videobearbeitung. > Da ist meine Kiste (hier ist der PC gemeint ; -) so manches mal am > 'schwitzen'. > Das dann auch noch in einer VM auslagern... besser nicht Wenn die CPU der Maschine die VT-Erweiterungen hat, dürften die Leistungseeinbußen bei der Virtualisierung beispielsweise mit KVM relativ überschaubar sein. Muß man aber für die jeweilige Anwendung ausprobieren. > Aber: was soll ich von einem Betriebssystem halten, das nicht mal eine > recht gängige Hardware sauber einbinden kann und gleich aus dem Takt > kommt, wenn WinDoofs diese vorher 'benutzt' hat ; -) Wenn der Windows-Treiber die Netzwerkkarte beim Herunterfahren nicht korrekt zurücksetzt und sie in einem undefinierten Zustand beläßt, wird sie nach einem Warmstart vom Linux-Kernelmodul, das einen definierten Zustand erwartet, eben nicht eingebunden. Das Linux-Kernelmodul erwartet offenbar einen definierten Zustand, welcher aber in Deinem Fall bisher nur durch einen Kaltstart herbeigeführt werden kann. Im Kernel-Ringpuffer (man dmesg) sollten nach einem fehlerhaften Start entsprechende Fehlermeldungen zu finden sein. Dem Kernelmodul e1000e kann beim Laden zudem der Parameter "debug=16" (man modules, man modprobe.d) mitgegeben werden, was für mehr Debugmeldungen im Ringpuffer sorgt. Möglicherweise kann es auch helfen, das Kernelmodul e1000e nach einem fehlerhaften Start noch einmal zu entladen und dann wieder zu laden. HTH, Karl
Servus Klaus, Schau mal bitte unter der Windows Hardware Einstellung ob bei der Netzwerkkarte sowas wie "abschalten zum Strom sparen" angehakelt ist bzw. obs da Stromspar Optionen gibt. Diese mal ausschalten. Was mich aber momentan eher wundert ist, dass du sagst unter Ubuntu funktioniert es... Ubuntu ist ein Debian Derivat, optimiert auf Home Rechner, die Basis ist jedoch der Debian Kernel. Das heißt die Kernel Treiber sind gleich. Kann es sein das dein debian Setup Mist gebaut hat (Hardewareunterstützung !!)? Benutzt du UEFI? ist AHCI / ACPI angeschaltet? Gabs ne Fehlermeldung bei der Installation von debian? Gruß René
Karl Käfer schrieb: > Wenn der Windows-Treiber die Netzwerkkarte beim Herunterfahren nicht > korrekt zurücksetzt und sie in einem undefinierten Zustand beläßt, wird > sie nach einem Warmstart vom Linux-Kernelmodul, das einen definierten > Zustand erwartet, eben nicht eingebunden. klar wieder du schuld auf Windows schieben. Eine Hardware muss bei booten immer ordentlich eingebunden werden egal in welchen Zustand sie ist. Sonst könnte das Problem auch ohne Windows auftreten, wenn man einfach den "Reset" drückt. Da ist der Zustand auch nicht definiert.
René S. schrieb: > Das heißt die Kernel Treiber sind gleich. Das heißt aber nicht, dass die Einstellungen auch gleich sind.
:
Bearbeitet durch User
Uhu Uhuhu schrieb: > Das heißt aber nicht, dass die Einstellungen auch gleich sind Nuja die Einstellungen sind eine andere Sache... was momentan unbekannt ist sind folgende Dinge... baut die Karte nur keine Verbindung auf oder erkennt das System die Karte überhaupt nicht ... lspci dürfte darüber Aufschluss geben. passiert ersteres wirds ne Einstellung sein, bei zweitem wird die Karte von Win in einen undefinierten Zustand gebracht. Gruß René
Es könnte ein Problem mit der Firmware sein, bei den Intel karten wird oft eine Firmware von Treiber in die Karte geladen, eventuell denkt ja Debian das schon die Firmware vorhanden ist, aber sie dann scheinbar nicht mit dem Treiber zusammenarbeitet. Eventuell kann man irgendwo ein "force" zum laden der Firmware von Debian eintragen.
So ein ähnliches Problem hatte ich auch mal. Da waren die Beteiligten ein Debian Linux (Etch) und Ubuntu. Immer wenn ich das Ubuntu mal gestartet hatte, ging das Ethernet unter Debian nicht mehr, es sei denn man schaltete den PC hart aus. Das Netzwerkinterface war ein RTL61-irgendwas onboard. Anscheinend hat der Ubuntu-Treiber die Hardware beim Runterfahren in einen Zustand gebracht, aus dem man sie erst wieder explizit aufwecken mußte. Was zwar der Treiber in Ubuntu konnte, aber nicht der in dem alten Debian Linux. Ich habe das nie zu Ende debugt. Der PC ist vor einem dreiviertel Jahr zum Schrottplatz gewandert (Mainboard tot). Und mit dem neuen PC und einem aktuellen Debian tritt das Problem nicht auf. Im Zweifelsfall würde ich eher in Linux-Foren/Mailinglisten nach Hilfe suchen als ausgerechnet hier.
KlausX schrieb: > Aber: was soll ich von einem Betriebssystem halten, das nicht mal eine > recht gängige Hardware sauber einbinden kann und gleich aus dem Takt > kommt, wenn WinDoofs diese vorher 'benutzt' hat ; -) Dazu beitragen das das Problem gefixt wird, also ein Ticket im Debian Bug-Tacker aufmachen.
Hast du nachgeschaut, ob es bereits ein Kernel-Update fuer deine Debian-Installation gibt ? Falls ja, auf alle Faelle installieren und neuen Kernel booten. Ausserdem, was macht lspci und ethtool <NETWORK_INTERFACE_NAME> wenn die Probleme auftreten ?
Axel Schwenke schrieb: > Im Zweifelsfall > würde ich eher in Linux-Foren/Mailinglisten nach Hilfe suchen als > ausgerechnet hier. Aber zuerst doch wohl in den Logfiles. wendelsberg
Vermutlich wird die karte einfach deaktiviert/ausgeschaltet. Sie muss wieder eingeschaltet werden. Was wird angezeigt bei:
1 | rfkill list |
http://wiki.ubuntuusers.de/rfkill
:
Bearbeitet durch User
Hallo an Alle, ich versuch mal, so kurz wie möglich auf alles zu antworten, was an mich gerichtet war/ist: @René S.: die die Einstellungen waren gesetzt, eine Änderung brachte nichts Es ist ein UEFI-Board, UEFI ist aber deaktiviert, ACPI-ja @Peter II: ich habe den aktuellen Inteltreiber eingespielt, keine Besserung @Axel Schwenke: dieses Forum ist nicht das einzige, in dem ich um Hilfe bitte. Aber ich bin anscheinend der einzige mit genau diesem Prblem. Es gab nirgens bis jetzt eine Lösung. @dudu: ich bin bis jetzt echt beschäftigt mit ausprobieren und Antworten schreiben... ; -) Neeee, Spass beiseite, wenn ich Zeit hab, mach ich das @olibert: ich bin blutiger Liunx-Anfänger. Auf der Konsole mache ich so gut wie nix (ausser mal ein schüchternes LS oder CD ; -) Ich werde natürlich alles ausprobieren... @wendelsberg: ohje(siehe @olibert), und dann kommst du mir mit Logfiles @Daniel A. siehe @olibert. Ich probieres jetzt alles aus und melde mich dann noch mal Vielen Dank Jungs/Mädels für Eure Hilfe/Vorschläge. best regrads KlausX
KlausX schrieb: > @Peter II: > ich habe den aktuellen Inteltreiber eingespielt, keine Besserung nicht Treiber, Firmware! Bei Debian muss man teilweise ein Firmware packet installieren. Da kommt so ein Hinweis beim landen vom Treiber, das keine Firmware gefunden wurde.
Ich hatte auch mal so etwas bei Debian/Windows-PS. Die Lösung war aber relative simple und nach schnellen Googeln zu finden. Ich kann mich aber nicht mehr daran erinnern. Entweder war das etwas mit den Stromsparoptionen unter Windows, wie hier schon erwähnt wurde. Aber ganz dunkle entsinne ich mich, dass ich im BIOS das "Wake-on-LAN" deaktiviert habe.
Hallo Peter, Peter II schrieb: > klar wieder du schuld auf Windows schieben. Ist das nicht ein bisschen paranoid -- und, verzeih', kindisch? Nicht jede Aussage über Windows ist gleich eine Schuldzuweisung. Es ist sicherlich so, daß durchaus genügend Angriffsfläche vorhanden ist, aber in diesem Falle ginge jede Schuldzuweisung an Windows vorbei an den Hersteller der Netzwerkkarte und der Treiber... Der Netzwerkkartentreiber für Windows ist von Intel, das Linux-Kernelmodul ebenfalls. Ich habe also keine "Schuld" zugewiesen sondern versucht, das Problem zu lösen. Und das stellt sich mir nun einmal so dar, wie ich es beschrieben habe. Meiner ganz persönlichen Auffassung zufolge müßten im Übrigen beide Treiber, sowohl der Windows-Treiber als auch das Linux-Kernelmodul, bei jedem Laden und Entladen einen Reset auslösen, und die NIC so in einen definierten Zustand versetzen. > Eine Hardware muss bei booten immer ordentlich eingebunden werden > egal in welchen Zustand sie ist. Das ist zwar grundsätzlich richtig, funktioniert in diesem Fall aber offensichtlich nicht. Da kann man jetzt lamentieren, sich krampfhaft an irgendwelchen Schuldzuweisungen festbeißen, oder versuchen, das Problem einfach zu lösen. > Sonst könnte das Problem auch ohne Windows auftreten, wenn man > einfach den "Reset" drückt. Da ist der Zustand auch nicht definiert. Nein, dann wird die Karte ja zurückgesetzt (also ein Reset ausgeführt) und damit in einen definierten Zustand versetzt. Liebe Grüße, Karl
Frueher™ trat das Problem reproduzierbar mit 3Com905-Karten auf. Ein Warmstart reichte denen nicht fuer eine vollstaendigen Reset. Selbst ein Linuxwarmstart konnte das zu "Haengern" fuehren. Abhilfe damals™: 3Com raus und Intel rein. Schade des jetzt auch Intel betroffen scheint. Wenn man so die (Linux-)Quelltexte verschiedener Netzwerkhardware anschaut, wundern tut es einen nicht.
Karl Käfer schrieb: >> Sonst könnte das Problem auch ohne Windows auftreten, wenn man >> einfach den "Reset" drückt. Da ist der Zustand auch nicht definiert. > > Nein, dann wird die Karte ja zurückgesetzt (also ein Reset ausgeführt) > und damit in einen definierten Zustand versetzt. warum sollte das so sein? Die karte bekommt zwar ein Reset über den Bus mitgeteilt aber was sie damit macht ist ihre Sache. Scheinbar wird sie nicht resetet, weil sie es sonst bei einen Reboot auch machen würde. Karl Käfer schrieb: > Der Netzwerkkartentreiber für Windows ist von Intel, das > Linux-Kernelmodul ebenfalls. bei Linux bin ich mir nicht so sicher, eventuell steuert Intel ein paar Infos zu, die eigentliche Entwicklung kommt meines Wissens nicht von Intel.
Peter II schrieb: > Karl Käfer schrieb: >> Der Netzwerkkartentreiber für Windows ist von Intel, das >> Linux-Kernelmodul ebenfalls. > > bei Linux bin ich mir nicht so sicher, eventuell steuert Intel ein paar > Infos zu, die eigentliche Entwicklung kommt meines Wissens nicht von > Intel. Doch, kommt sie. Siehe auch Copyright-Vermerke in den Quellen. Das war übrigens schon damals (1996 :-) bei den 100MBit-Karten so. Da hat ein Angestellter Intels die quasi im Alleingang geschrieben. Der Mann war auf jeden Fall kompetent und hat auch geantwortet. Ich hatte ihm mal einen Bug gemeldet, der innerhalb von einer Stunde gefixt war :-) Aber auf jeden Fall: den Bug melden und auf zügige Erledigung hoffen (oder selbst fixen oder jemanden bitten, der sich damit auskennt).
Meine Fresse, ich hätte nicht gedacht, das ich mit so einem
Problem(chen) so eine Welle mache...
Ich habe noch ein paar Antworten und eine Lösung:
@olibert:
ethtool:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 2
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
lspci:
00:00.0 Host bridge: Intel Corporation Haswell DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Haswell PCI Express x16 Controller
(rev 06)
00:14.0 USB controller: Intel Corporation Lynx Point USB xHCI Host
Controller (rev 05)
00:16.0 Communication controller: Intel Corporation Lynx Point MEI
Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection
I217-V (rev 05)
00:1a.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host
Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation Lynx Point High Definition Audio
Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port
#1 (rev d5)
00:1c.5 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port
#6 (rev d5)
00:1d.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host
Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation Lynx Point LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation Lynx Point 6-port SATA
Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation Lynx Point SMBus Controller (rev 05)
01:00.0 VGA compatible controller: NVIDIA Corporation Device 11c0 (rev
a1)
01:00.1 Audio device: NVIDIA Corporation Device 0e0b (rev a1)
03:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA
Controller (rev 01)
@Daniel A.:
rfkill list:
root@klausneumannpc:/home/klaus# rfkill list
root@klausneumannpc:/home/klaus# [blinkender Cursor]
Also im Klartext: nichts
Was aber auch zu erwarten war, denn der Befehl zeigt doch
Funk-Controller an (wenn ich das richtig verstanden habe)
@Klaus I.:
"Wake-on-LAN" ist für den Intel-Controller im BIOS deaktiviert
@Chris D.:
wem soll ich denn den 'Bug'. melden (doch wohl nicht Intel) ?
Und so wie ich die Sache sehe ist auch noch nicht ganz geklärt, ob ich
das nicht irgendwie selber verbockt habe.
Sei es, wie es wolle, nun zu meiner Lösung:
(eines vorweg, einige von Euch werden jetzt gleich denken: was für ein
Honk!)
Aber: die Sache funzt (ich muss nicht mehr unter den Tisch krabbeln)...
1. Netzwerkverbindung im Menü deaktivieren
2. rmmod e1000e [als ROOT im Terminal]
3. Neustart
4. vor Freude fast nass machen, denn oh Wunder: nach dem
Neustart ist alles Suppi und ich habe eine funktionierende
Netzwerkverbindung
[hier wäre evtl. ein kleines Lob für den Newbie fällig]
Ok Jungs. Eigentlich ist damit der Fall für mich abgeschossen, bist ich
mich etwas besser auskenne. Ich weiss, das ist weit weg von einer
sauberen Lösung, aber das ganze schreiben, ausprobieren,... frisst echt
viel Zeit, die ich im Moment einfach nicht habe.
An alle noch mal: Vielen Dank für eure Hilfe...
best regards
KlausX
wendelsberg schrieb: > Axel Schwenke schrieb: >> Im Zweifelsfall >> würde ich eher in Linux-Foren/Mailinglisten nach Hilfe suchen als >> ausgerechnet hier. > > Aber zuerst doch wohl in den Logfiles. Da steht nix. Was soll da auch stehen? Aktuelle Linuxe verwenden udev und den plugdev Mechanismus auch für Geräte, die nicht im laufenden Betrieb aktiviert und deaktiviert werden. Die Netzwerkkarte taucht dann einfach nicht als Gerät auf. Dafür gibts aber keinen Logeintrag. Daniel A. schrieb: > http://wiki.ubuntuusers.de/rfkill Soweit ich sehen kann, ist das für drahtloses Netzwerk. Eine E1000 ist das genausowenig wie meine RTL61xx Peter II schrieb: > nicht Treiber, Firmware! Bei Debian muss man teilweise ein Firmware > packet installieren. Da kommt so ein Hinweis beim landen vom Treiber, > das keine Firmware gefunden wurde. Unwahrscheinlich. Schließlich funktioniert die Karte nach einem Kaltstart, nicht aber nach einem Warmstart nachdem ein "falsches" OS gelaufen ist. Wenn Firmware fehlt, würde es einfach niemals funktionieren. XL
Axel Schwenke schrieb: > Wenn Firmware fehlt, würde es einfach niemals > funktionieren. eventuell gibt es ja eine "Default" Firmware die im vorhanden ist. Sonst würde ja auch booten von Netzwerk nicht funktionieren.
Hallo Peter, Peter II schrieb: > Karl Käfer schrieb: >> Nein, dann wird die Karte ja zurückgesetzt (also ein Reset ausgeführt) >> und damit in einen definierten Zustand versetzt. > > warum sollte das so sein? Weil der Rechner nach einem Druck auf den "Reset"-Button keinen Warmstart durchführt, sondern einen Hardware-Reset -- dazu ist so ein Reset-Knopf ja schließlich da -- und dann sollte die Karte genauso sauber hochkommen wie bei einem Kaltstart. > Karl Käfer schrieb: >> Der Netzwerkkartentreiber für Windows ist von Intel, das >> Linux-Kernelmodul ebenfalls. > > bei Linux bin ich mir nicht so sicher, eventuell steuert Intel ein paar > Infos zu, die eigentliche Entwicklung kommt meines Wissens nicht von > Intel. Use the source, Luke.
1 | $ head -25 /usr/src/linux-headers-3.13.0-36/drivers/net/ethernet/intel/e1000e/Makefile | tail -4 |
2 | # Contact Information: |
3 | # Linux NICS <linux.nics@intel.com> |
4 | # e1000-devel Mailing List <e1000-devel@lists.sourceforge.net> |
5 | # Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 |
Liebe Grüße, Karl
Karl Käfer schrieb: > Peter II schrieb: >> Karl Käfer schrieb: >>> Nein, dann wird die Karte ja zurückgesetzt (also ein Reset ausgeführt) >>> und damit in einen definierten Zustand versetzt. >> >> warum sollte das so sein? > > Weil der Rechner nach einem Druck auf den "Reset"-Button keinen > Warmstart durchführt, sondern einen Hardware-Reset -- dazu ist so ein > Reset-Knopf ja schließlich da -- und dann sollte die Karte genauso > sauber hochkommen wie bei einem Kaltstart. nein, ein µC löscht seinen Ram nicht bei einem Reset. Nicht initialisierte Variable haben also nach einen Reset einen den alten wert. Wenn der Strom komplett abgeschaltet wird, dann sind sie (oft) 0.
hi Klaus, KlausX schrieb: > Sei es, wie es wolle, nun zu meiner Lösung: > (eines vorweg, einige von Euch werden jetzt gleich denken: was für ein > Honk!) > Aber: die Sache funzt (ich muss nicht mehr unter den Tisch krabbeln)... > 1. Netzwerkverbindung im Menü deaktivieren > 2. rmmod e1000e [als ROOT im Terminal] > 3. Neustart > 4. vor Freude fast nass machen, denn oh Wunder: nach dem > Neustart ist alles Suppi und ich habe eine funktionierende > Netzwerkverbindung > [hier wäre evtl. ein kleines Lob für den Newbie fällig] Jut jemacht, Junge! Was passiert wenn Du meinen Tipp oben (Kernelmodul entladen und wieder laden mit "modprobe -r e1000e && modprobe e1000e" -- nimm lieber "modprobe", das ist intelligenter als "rmmod" und "insmod") ausprobiert statt des Neustarts nach dem "rmmod"? HTH, Karl
Hallo Peter, Peter II schrieb: > nein, ein µC löscht seinen Ram nicht bei einem Reset Hier gehts aber nicht um Mikrocontroller, sondern um PC-Hardware. Da hat so ein Reset-Button eine definierte Funktion, nämlich, oh Wunder, die Hardware zurückzusetzen. Ob die dabei ihre Speicher löscht oder nur mit neuen Daten überschreibt, ist allerdings ziemlich wumpe, solange am Ende die korrekten Daten in ihren Speichern stehen. :-) Liebe Grüße, Karl
Karl Käfer schrieb: > Hier gehts aber nicht um Mikrocontroller, sondern um PC-Hardware. Da hat > so ein Reset-Button eine definierte Funktion, nämlich, oh Wunder, die > Hardware zurückzusetzen. Ob die dabei ihre Speicher löscht oder nur mit > neuen Daten überschreibt, ist allerdings ziemlich wumpe, solange am Ende > die korrekten Daten in ihren Speichern stehen. :-) eine Netzwerkkarte hat aber ein Mikrocontroller. Man kann sogar Trojaner drauf laden.
Karl Käfer schrieb: > Jut jemacht, Junge! > > Was passiert wenn Du meinen Tipp oben (Kernelmodul entladen und wieder > laden mit "modprobe -r e1000e && modprobe e1000e" -- nimm lieber > "modprobe", das ist intelligenter als "rmmod" und "insmod") ausprobiert > statt des Neustarts nach dem "rmmod"? Hallo Karl Käfer, danke fürs Lob ; -) ich habe modprobe -r -v e1000e [mit dem Zusatz -v] in der Konsole eingegeben, um zu sehen, was des genau macht. Und siehe da: rmmod e1000e, was doch das selbe ist, wie ich gemacht habe. Sei es wie es wolle... danach gleich wieder das Modul laden brachte nichts. modprobe -r e1000e und dann der neustart funzt allerdings (was, wie eingangs erwähnt, ja auch genau das ist, was ich gemacht habe) Also ohne Neustart habe ich nichts gewonnen... Trotz alle dem... Thx best regards KlausX
>> Sonst könnte das Problem auch ohne Windows auftreten, wenn man >> einfach den "Reset" drückt. Da ist der Zustand auch nicht definiert. Ein Reset ist kein stromlos. Bei "stromlos" sollte ein Prozessor bei Adresse NULL anfangen. Dein PC wird aber wegen WOL noch etwas Strom an Deine Karte liefern? Sonst könnte er nie aufgeweckt werden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.