Win2k

[red-polo]

Dass mit den IRQ's weiß ich schon länger, sie lassen sich allerdings nicht manuell verändern.... bleibt mir wohl nur der Umbau?

Cat V - überall, was denn sonst?

Alternativ: was gibt es an guten und preiswerten Ethernetkarten?

[red-polo]

oder wie komme ich an die blöden IRQ-Einstellungen ran... ist immer nur Automatisch einstellen angehakt, kann es aber nicht deakivieren, und das bei allen Treibern für genannte Geräte die IRQ9 belegen.

Admin-Rechte hab ich natürlich....

[Lacknase]

Dann läuft ACPI mit IRQ-sharing, wenn die Felder "deaktiviert" sind. Das ist jetzt so eine Sache. Wenn Windows der Meinung ist, daß alles ok ist, dann ist ein "Eingreifen" mit nicht ganz geringen Risiken verbunden. Wenn's ganz doof läuft, darfst Du neu installieren.

Hier mal die wichtigsten Links zum Thema (und ein bischen Kontext):

http://support.microsoft.com/default.aspx?...b;en-us;Q252420

http://support.microsoft.com/default.aspx?...b;en-us;Q269491

http://support.microsoft.com/default.aspx?...b;en-us;Q237556

http://support.microsoft.com/default.aspx?...b;en-us;Q216251

http://support.microsoft.com/default.aspx?...b;en-us;Q244601

Ich würde die Artikel an Deiner Stelle gut durchlesen und nur weitermachen, wenn Du auch verstehst, was Du tust oder keine Angst vor einer Neuinstallation hast. Auf jeden Fall kannst Du die Karte mal ausbauen und auf einen anderen Slot setzen. Das könnte tatsächlich reichen und dauert nur zwei Minuten ...

Zur Karte noch: wie so oft im Leben kriegt man von den Qualitätsmerkmalen "gut", "einfach/schnell erledigt", "billig" selten mehr als zwei aufeinmal bei einem Produkt.

Ich würde Dir eine Intel eepro100 empfehlen, oder eine 3Com oder eine DEC oder ähnliches. Die sind nicht billig und gut in Leistung, Ausstattung und Doku.

Viel Erfolg!

[red-polo]

Was mich aber irgendwie wundert.... in dem ersten Artikel steht, dass IRQ9 für PCI und IRQ-Sharing vorgesehen ist wenn ACPI läuft. Wieso läuft dann aber meine AGP-Grafikkarte auch auf IRQ9?

So als Frage am Rande...

[Lacknase]

Weil der AGP-Slot ebenfalls einen IRQ braucht, den er sich in aller Regel mit dem 1. PCI-Slot teilt. Prinzipiell ist hinsichtlich der "Steuerlogik" der AGP-Slot mit dem PCI-Bus zu vergleichen. Er unterscheidet sich halt hinsichtlich der direkten Speicheranbindung (an der CPU "vorbei") bzw. der höheren Übertragungsbandbreite und -frequenz. Aber DATA_BREAK/WAIT ist DATA_BREAK/WAIT - egal ob PCI oder AGP.

Jedenfalls folgt daraus, daß Du den ersten PCI-Slot (das ist der direkt neben dem AGP-Slot bzw. bei Tower-Gehäuse-Montage des Boards der "oberste") von IRQ-bedürftigen Karten freilassen solltest (auch wenn sie angeblich IRQ-sharing unterstützen). Der zweite teilt sich meist den IRQ mit onboard-USB oder -Sound. Der dritte und vierte sind ideal. Wobei der vierte sich den IRQ meist nochmal mit dem fünften teiilt ... es sei denn Du hast 6 PCI-Slots, dann gilt entsprechendes für den fünften und sechsten *SEUFZ* Ach ja, und Du solltest neben dem AGP_FAST_WRITE noch DELAYED_TRANSACTION und PCI_MASTER-READ_CACHING im Bios ausschalten; es sei denn, Du hast von Asus eine entsprechend neue Bios-Version, die den Via-Southbridge-Bug behebt.

P.S.: Wo man hinschaut: alles "broken by design". Da versteht man vielleicht auch, warum die Intel/x86-Architektur weithin als Schrott gilt ... aber billig halt

[HerrDerKolbenringe]

übrigens ... ich musste heute auch n format C: machen ... weil mir gestern die kiste KOMPLETT ABGEROTZT is ... weil ich im Explorer F5 (refresh) gedrückt hab! :plemplem: :plemplem: :plemplem: :plemplem: komplett bescheuert ... aber ab da hat die kiste 100mal die sekunde refreshed und das in allen offenen fenstern und auch den desktop etc ... *flimmer* ... nach nem reboot wars genauso ... ich dachte ja erst meine tastatur is am arsch ... andere dran ... dasselbe :plemplem: :plemplem: :plemplem: fragt mich bidde nich was da abging! F8 und "letzte bekannte ..." hat auch nich geholfen! überall flimmern und refresh und nur noch ausrufezeichen im gerätemanager! :grr: ... dann gabs eben n format c! arschlecken! da mach ich nich lang rum! Dauert ja auch nich lang (1,5h max.) ... bei mir heute bisschen länger, weil ich ausversehn n englische direktx8.1 version installiert hab ... statt der deutschen (danebengeklickt) und das scheint sich nich zu vertragen! danach is die kiste nichmehr runtergefahren etc ... auch nachm deinstall nich ... also dann nochmal das ganze! :plemplem: ... jetz geht dem!

[Dr.Paulaner]

also zum irq sharing: das tut aber ganz gut unter win2k habe nen kunden dr hat 4 karten aufer 9 und das sys läuft gut und schnell...realtek ist nicht supersuper, aber mittlerweile laufen die triber auch stabil; ich selber nehme liebr lowcostkarten mit dec wenns zu 3 com nicht langt...

aber die karte isses nicht, was er testen kann wenn er nicht basteln mag oder im bios den irq für jeden slot fest vrgeben: abgesicherter modus MIT netzwerk, dann wird der ip stack mitgeladen, wenns dann nicht crasht....dann isses woanders nen problem was da crasht...

[HerrDerKolbenringe]

ich hab ne Netgear FA311 .... läuft problemlos und war günstig!

[Lacknase]

also zum irq sharing: das tut aber ganz gut unter win2k habe nen kunden dr hat 4 karten aufer 9 und das sys läuft gut und schnell...realtek ist nicht supersuper, aber mittlerweile laufen die triber auch stabil; ich selber nehme liebr lowcostkarten mit dec wenns zu 3 com nicht langt...

aber die karte isses nicht, was er testen kann wenn er nicht basteln mag oder im bios den irq für jeden slot fest vrgeben: abgesicherter modus MIT netzwerk, dann wird der ip stack mitgeladen, wenns dann nicht crasht....dann isses woanders nen problem was da crasht...

Zur Realtek (FreeBSD-CVS//sys/pci/if_rl.c):

/*

* The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is

* probably the worst PCI ethernet controller ever made, with the possible

* exception of the FEAST chip made by SMC. The 8139 supports bus-master

* DMA, but it has a terrible interface that nullifies any performance

* gains that bus-master DMA usually offers.

*

* For transmission, the chip offers a series of four TX descriptor

* registers. Each transmit frame must be in a contiguous buffer, aligned

* on a longword (32-bit) boundary. This means we almost always have to

* do mbuf copies in order to transmit a frame, except in the unlikely

* case where a) the packet fits into a single mbuf, and b) the packet

* is 32-bit aligned within the mbuf's data area. The presence of only

* four descriptor registers means that we can never have more than four

* packets queued for transmission at any one time.

*

* Reception is not much better. The driver has to allocate a single large

* buffer area (up to 64K in size) into which the chip will DMA received

* frames. Because we don't know where within this region received packets

* will begin or end, we have no choice but to copy data from the buffer

* area into mbufs in order to pass the packets up to the higher protocol

* levels.

*

* It's impossible given this rotten design to really achieve decent

* performance at 100Mbps [...]

*/

Die Jungs von *BSD haben die ganzen DMA-Features "umgangen", während die Programmierer der letzten Windows-Treiber das nicht taten. Ergebnis: Das Ding "liest" quasi spekulativ. Wenn die Jungs von REALTEK das also nicht dokumentieren, dann mag es doch denkbar sein, daß auch andere Hersteller von Hardware/Treibern davon nix wissen.

Hinzukommt nu das K7M und die NVidia-Karte. Die AGP-Bridges auf alten Athlon Boards haben eine andere Vorstellung von DMA-Adressierung als Geforce-Karten. (Da schreibt einer dem anderen in den Puffer bzw. liest aus fremden Puffern.) Besonders übel war das mit der Kombination aus Via-Northbridge und Geforce-Karten. Daneben besteht das Problem, daß Busmaster-Karten mit kaputtem IRQ-sharing (darunter fällt auch die Realtek bzw. OEMs derselben, die keine ordentliche PCI-ID vergeben) sich mit Geforce-Karten ebenfalls schlecht vertrugen, wenn erstere hohe Transferraten zu verarbeiten hatten. Nachdem die Karre jedesmal mit einem Kernel-Halt und einem ominösen Hinweis auf tcpip.sys abranzt (den ich bei der detaillierten Fehlermeldung, die red postete, nicht mehr sah), liegt die Vermutung nahe, daß Hardware versagt - und zwar wahrscheinlich _während_ der Netzübertragung. Wenn es "bloß" das Netzwerk selber wäre, würde doch nur der Stack versagen, oder? Die Kiste dürfte doch nicht komplett stehen bleiben.

[red-polo]

aber die karte isses nicht, was er testen kann wenn er nicht basteln mag oder im bios den irq für jeden slot fest vrgeben: abgesicherter modus MIT netzwerk, dann wird der ip stack mitgeladen, wenns dann nicht crasht....dann isses woanders nen problem was da crasht...

crasht auch im abgesicherten Modus mit Netzwerk wenn ich den den verifier auf die tcpip.sys loslasse...

werd dann vielleicht doch mal eine andere Ethernetkarte probieren... mal schauen ob damit vielleicht besser wird...

[Lacknase]

aber die karte isses nicht, was er testen kann wenn er nicht basteln mag oder im bios den irq für jeden slot fest vrgeben: abgesicherter modus MIT netzwerk, dann wird der ip stack mitgeladen, wenns dann nicht crasht....dann isses woanders nen problem was da crasht...

crasht auch im abgesicherten Modus mit Netzwerk wenn ich den den verifier auf die tcpip.sys loslasse...

werd dann vielleicht doch mal eine andere Ethernetkarte probieren... mal schauen ob damit vielleicht besser wird...

Äh - was heißt "verifier"?

[red-polo]

verifier.exe in \system32

[Lacknase]

Hm. Und - vom Namen ausgehend - nehme ich mal an, daß die die Signatur der Treiberdatei checkt, ja? Dann wäre es noch interessant zu wissen, welche Version, Hersteller, Blabla die "böse" tcpip.sys hat ...

[red-polo]

genau!

Version 5.00.2195.5267

Hersteller Microsoft

[Lacknase]

genau!

Version 5.00.2195.5267

Hersteller Microsoft

OK. Die is orichinool[TM]. Also folgendes Procedere:

[1] Netzwerkkarte umstecken. (s.o.)

[2] BIOS-Update auf K7M AMI ACPI BIOS 1009 final (= KM131 Beta / 12.04.2000), sofern nicht schon eingespielt. Dabei brav nach Herstelleranleitung vorgehen: bei ASUS-Boards VOR und NACH dem flash LOAD_SETUP_DEFAULTS=YES nicht vergessen, da sonst das NV-RAM hin ist!

Biosfile:

ftp://ftp.asuscom.de/pub/ASUSCOM/BIOS/Slo.../K7M/Km1009.zip

Flashtool (für DOS, also mit DOS/Win98-Diskette hochfahren):

ftp://ftp.asuscom.de/pub/ASUSCOM/BIOS/Slo...51/amifl827.zip

[3] Mainboard/Chipsatz-Treiber-Update.

Northbridge-Treiber:

ftp://ftp.asuscom.de/pub/ASUSCOM/TREIBER/...MDdrvpk_130.exe

(Die anderen Dateien im verzeichnis sind nur für das A7M266!)

Southbridge-Treiber:

ftp://ftp.asuscom.de/pub/ASUSCOM/TREIBER/...IA/4in1445v.exe

[4] Aktuelle NVidia-Treiber aufspielen.

http://download.nvidia.com/Windows/41.09/4....09_win2kxp.exe

[5] Kabelverbindungen/Lüfter checken.

Wenn das nix hilft, Betriebssystem neu aufspielen oder wechseln

[red-polo]

Danke noch mal für die vielen Ratschläge.... habe zunächst angefangen mal bei den ganzen installierten Progs auszumisten... unter anderem die ganze Teletot-Kacke komplett runtergeschmissen die ich ja dank LAN nicht mehr brauche...

... und siehe da seither toi toi toi, kein Absturz mehr.

[Lacknase]

Hi Red!

Erstmal Gratulation (*TOITOITOI*). Eins hätte ich aber doch gerne gewußt: Kannst Du mir bitte erklären, was Du mit "Teletot-Kacke" meintest? Ein Programm/Hersteller dieses Namens ist mir nämlich gänzlich unbekannt.

[red-polo]

Telekom-SW

[red-polo]

jetzt hab ich nur noch hin und wieder ein klitzekleines Problem...

... und zwar verlier ich hin und wieder mal wieder meine Funkmaus, sprich sie reagiert plötzlich einfach nicht mehr. Da hilft dann auch nur noch komplett ausschalten und wieder einschalten des Rechners, normaler Neustart bringt nichts. Dieser "Fehler" tritt aber nach längerer Mausbenutzung auf.

Im Gerätemanager zeigt es mir auch zweimal "HID-compliant Cordless Mouse" an. Es bringt aber auch nichts eine zu entfernen, beim nächsten Neustart ist sie wieder da.

Maus ist über USB angeschlossen, da PS2 Anschluss am Board defekt.

Kann es u.U. an den Batterien der Maus liegen, oder am doppelten Eintrag, oder gar am defekten PS2?

[Lacknase]

Danke auch für die Info. Die "Software" kenne ich

Zur Maus:

Das kann tatsächlich an den Batterien liegen. Du solltest aber zusätzlich (wie oben schonmal beschrieben) im BIOS USB_LEGACY_DEVICE deaktivieren, MOUSE_TYPE auf Auto.

[red-polo]

USB_LEGACY DEVICE war schon seit eher "disabled", sowas wie Mouse_Type gibts bei mir nicht.

Hab jetzt noch den PS/2 Mouse Support auf disabled gestellt. Mal schauen, werden aber wohl doch die Batterien sein.

[red-polo]

Die Freude währte nicht besonders lange...

Rechner stürzt schon wieder ständig ab :veryangry: bestimmt 15 Abstürze seit Spätnachmittag... da ist arbeiten mit fast überhaupt nicht möglich :grr:

Hier das Bild aus der Ereignisanzeige:

hab schon 3 verschiedene SCSI-Treiber versucht, hat sich aber nichts geändert...

[Lacknase]

Hi Red,

das ist aber auch ein Dauerärger Und Controllerfehler kann viel heißen. Laut groups.google.de taucht der Fehler manchmal auf, wenn das Board kein UDMA66/100er Modus unterstützt, aber die Platte es kann, wenn keine 80-adrigen-UDMA-IDE-Kabel verwendet werden, wenn kein SPXY installiert ist, wenn bestimmte Plattenkombinationen nicht miteinander wollen/können, bei bestimmten Controllertreibern etc. etc. Immerhin: IDE-(Platten)-Fehler können wir wohl ausschließen.

Ich habe keinen großen Plan von der Treiber-Namensgebung unter Windows, aber interessant scheint mir, daß der Fehlermanager da jetzt links einen aic78xx_1_ meldet, während rechts aic78xx aufgeführt wird. Das kann nun z.B. bedeuten, daß entweder da mehrere Treiberversionen "konkurrierend" laufen (aic78xx0/aic78xx1/aic78xx2), oder daß der Bus1 auf aic78xx nicht fit ist.

Ich würde mit der Diagnose für Fall zwei anfangen:

[1] korrekten Sitz aller Kabel sowie die Kabellängen checken (letztes Gerät an das Ende des SCSI-Kabels stecken, wenn da kein aktiver Terminator hängt).

[2] korrekten Sitz der SCSI-Karte (wenn nicht eh onboard) checken.

[3] Terminierung der Geräte auf der SCSI-Kette kontrollieren.

[4] Passen die SCSI-Bios-Einstellungen?

[4] die Endgeräte an Bus1 auf ihre Funktion hin prüfen. (Ist der Fehler durch Zugriff auf Gerät XY reproduzierbar?)

Sollte da alles in Ordnung sein, würde ich sämtliche SCSI-Treiber von Hand (also über die Hardware-Routine mit Anzeige der inaktiven Treiber) DEinstallieren und nach Reboot den aktuellsten neu aufspielen.

Sollte das nicht fruchten, wäre es hypsch, wenn Du das exakte SCSI-Setup posten würdest. Ich habe Dir mal ein Muster beigefügt:

;------ ID 4, no Term. (CDROM) -- ID 5, no Term. (Brenner) -- ID 4, Term. int. (DVD)

|

|

[bus1: UltraSCSI (SCSI 2), 20 MHz, 80cm Kabel -> Flachband]

|

Symbios Controller (ID7, autoterm.)

|

[bus0: Ultra2SCSI (UW2/LVD), 80MHz, 60cm Kabel -> gedrillt/abgeschirmt]

|

|

;------ ID 0, no Term. (HD1, boot) -- ID 1, no Term (HD2) -- ID 0, no Term. (HD3) --- Aktiver LVD-Terminator

[red-polo]

(1) SCSI-Kabel, 50polig, ca. 1,50m, 7 Abgriffe, Abgriffe 7, 6 und 5 belegt, letztes Laufwerk auch als solches definiert.

(2) Karte sitzt

(3) SCSI-ID's zum Controller hin absteigend (4,3,2)

(4) Karte ohne eigenes BIOS (Adaptec 2904CD)

[Lacknase]

Maximale Kabellänge ist bei dem Controller-Typ (SCSI2 - 10MB/s) zwar 3m, aber ich würde die Geräte trotzdem auf die ersten Abgriffe setzen. Da spielt die Kabelqualität und -abschirmung schon eine große Rolle. Überdies würde ich im Gerätemanager - sofern einstellbar - beim Controller und den Endgeräten "Parity_Enabled" einstellen. Dazu muß Parity auf den Geräten selber auch gejumpert sein. Zusätzlich letztes Gerät der Kette auf Term(iniert) jumpern (Gerät mit ID4).

Viel Glück!

[red-polo]

hat leider alles nichts gebracht... heute schon wieder 5 Abstürze.

Früher konnte man doch direkt in die *.ini Dateien des Systems schauen bzw. editieren, geht das immer noch? Wollte mich nun mal auf die Suche nach evtl doppelkten Treibern machen... aber wo anfangen?

[Lacknase]

Evtl. mal ein neues Kabel nehmen. Was sagt denn die Temperaturanzeige im Bios? Immernoch die alte Fehlermeldung?

Zu den Treibern: Wenn man den Gerätemanager auf die Ansichtsoption "ausgeblendete Objekte anzeigen" klickt, sieht man wirklich alles. Da würde ich den/die Treiber deinstallieren.

Danach den neuesten ASPI-Treiber von Adaptec installieren

http://www.adaptec.com/worldwide/support/d...=aspi_471a2.exe

Reboot und dann aktuellen Treiber nachschieben

http://www.adaptec.com/worldwide/support/d...=aspi_471a2.exe

Teste das mal ...

[red-polo]

irgendwie bekomm ich hier einfach nicht Ruhe in den Karton... :grr:

immer noch das selbe leidige Problem! Nachdem das Problem anscheinend vom SCSI herrührte (nach Ereignisanzeige) habe ich mittlerweile zunächst den SCSI deinstalliert und wieder installiert -keine Verbesserung. Also wieder raus damit.

Als nächstes habe ich einen gänzlich anderen SCSI-Adapter installiert (2940UW) - wieder keine Verbesserung.

Das lustige an der Sache ist nur, jetzt zeigt das Ereignisprotokoll keinerlei Fehler mehr an, Absturzursache wieder unbekannt! :grr:

letzter Bluescreen sah folgendermaßen aus:

***STOP: 0x0000000A (0x001C8A88, 0x00000002, 0x00000000, 0x804326F9)

IRGL_NOT_LESS_OR_EQUAL

***Adress 804326F9 base at 80400000, Date Stamp 3d366b8b - ntoskrnl.exe

Bearbeitet 4. März 2003 von red-polo

[Lacknase]

Hi Red!

Erstmal Kompliment an den Geduldsfaden. Ich hätte die Kiste schon lange aus dem Fenster geworfen

Zum Problem: Die Fehlermeldung bedeutet, daß ein Kernelprozess oder ein Treiber versucht hat, ohne die erforderliche Berechtigung auf einen "geschützten" Speicherbereich zuzugreifen. Im aktuellen Fall ist es der Kernelprozess "ntoskrnl.exe". Sowas passiert, wenn sich Komponenten Resourcen teilen oder sie verwalten, obwohl sie das eigentlich nicht ordentlich können. Häufig sind da sog. "BusMaster"-fähige Karten im Spiel, z.B. Netzwerkkarten oder Graphikkarten oder eben SCSI-Controller. Ich bin darum nahezu 100% sicher, daß es ein IRQ- oder Eingabe/Ausgabe-Adressen-Problem ist, auch wenn wir das schonmal durchgegangen sind - zumindest soweit ich mich jetzt erinnern kann.

Bitte kontrolliere darum (noch)mal beim Hochfahren die kurz nach dem Bios-POST angezeigten IRQs (einfach die "Pause"-Taste drücken, danach zum Weitermachen ESC oder RETURN). Win2k zeigt das ja leider im APM/ACPI-Modus nicht ordentlich an bzw. nur die Windows "verwalteten" Einstellungen.

Ich würde zur weiteren Fehlersuche unbedingt auch folgendes machen:

[1] Solltest Du an T-DSL hängen: den T-Online-PPPoE-Treiber deinstallieren (sog. Engel-Treiber ...). Nimm die internen von Microsoft oder den von: http://www.raspppoe.com/

[2] Den Rechner mit so wenig Komponenten wie möglich starten und testen (also echt nur Prozessor, Speicher, Systemplatte, Graphikkarte und Netzwerkkarte).

[3] Sämtliche PCI-IRQs im Bios von Hand zuweisen oder auf dem Board jumpern.

Wenn Du so - HOFFENTLICH! - einen "stabilen Zustand" gefunden hast, sortierst Du einfach durch stückweises Zustecken die "böse Komponente" bzw. deren Einstellungen aus. Melde Dich dann nochmal.

Viel Glück!

[red-polo]

su, gut erst mal hab ich jetzt damit angefangen ein Bios-Update der karte zu machen und danach wieder die aktuellsten Treiber installiert.

Und schau an, es hat soweit zwar alles gut geklappt, nur hab ich jetzt ununterbrochen Laufwerksanfragen... sprich die Laufwerke versuchen die ganze Zeit ihren Inhalt zu lesen egal ob einer drin ist oder nicht und das kostet Ressourcen und nervt! Einzig Schublade auf, bringt Abhilfe!

Was hab ich denn nu wieder verbrochen, bzw. wie korrigier ich das?