Archiv verlassen und diese Seite im Standarddesign anzeigen : Via Bug bei A7V 133 ?!
Ich hab gehört das es einen Bug im VIA KT133A Chip gibt, mein PC stürzt immer regelmäßig ab. Hab schon alles mögliche ausprobiert aber es hat sich nichts geändert.
Gibt es diesen Bug wirklich und was kann ich dagegen machen ?!
Mit dem neusten bios und den neustem via 4in1 treibern sollte er eigentlich aus der welt geschaffen sein.
Das hab ich ja alles schon gemacht :(
kauf dir einfach ein neues Board ;D ;) 8)
Hi,
also wenn Dein System instabil läuft, muß das nicht heißen, daß Du Dich gerade mit dem VIA 686B Southbridge-Bug herumschlägst. Ich würde sogar eher sagen NEIN. Der 686B Southbridge-Bug hat vielleicht Connection-Losses zu USB-Geräten oder korrupte Dateien beim Kopieren von einem IDE-Kanal auf den anderen zur Folge, aber Abstürze?! Das kann so viele Ursachen haben!
Als erstes wäre es mal interessant zu wissen, wie Dein PC abstützt? Freeze? Bluescreen? Reboot? Erzähl doch mal! Erst dann kann man in etwa abschätzen, in welcher Ecke Deiner Hardware der Auslöser zu suchen ist... :)
Er hängt sich eigentlich nur beim spieln auf (z.B. QIII und CS).
Als erstes freezt das Bild und der Sound wiederholt sich immer.
Hi,
also das hat 100%ig nichts mit dem VIA 686B Southbridge-Bug zu tun ;)
- Zuerst vergewissere Dich mal, daß keine PCI-Karte im Slot 1 steckt, da dieser auf der gleichen INT-Leitung liegt, wie der AGP-Slot.
- Deaktiviere im BIOS Fast Writes. Bringt nichts auf AMD-Systemen und ist nur ein unnötiger Quell von Problemen :(
- Wenn Du Windows XP verwendest, dann nimm als Grafiktreiber den Detonator 22.80 oder den neuen 27.20. Die 23er solltest Du ebenso meiden (Infinite Loop), wie den 21.83 (Freezes auf dem Desktop), wenn Du ein Board mit VIA Chipsatz hast.
- Stell die AGP Rate mal probeweise auf 2x, wenn das nichts hilft, dann auf 1x. Keine Angst, die Performance leidet dadurch nicht oder nur kaum, wie Du hier (http://www.planet3dnow.de/artikel/diverses/agp_rates/index.shtml) nachlesen kannst.
Probier das der Reihe nach mal durch. Wenn's nichts geholfen hat, dann meld Dich einfach nochmal ;)
netbuster
04.02.2002, 21:45
und hats geholfen? nur thx sagt nicht viel aus...
So wie es aussieht geht es
sniper.de
06.02.2002, 14:41
und was von den Sachen haste gemacht?
Bei mir war es auch so, da habe ich gemerkt, das FASTWRITES aktiviert war und habe es deaktiviert.......Voilà.....
Ich hatt ne Netzwerkkarte im ersten PCI Slot ich glaub die war dran schuld :-[ Wo stellt man das mit den "FASTWRITES" ein ?
HipHopJunkie
06.02.2002, 21:25
Das mit den Fastwrites stellst du im Advanced-Bereich im Bios ein, gleich unter AGP-4x Mode.
Gruß HipHopJunkie
ich frag mich ja manchmal wie die leute in den ersten PCI-Slot überhaupt noch was reinkriegen, also bei mir passt da nix rein........Grafikkarte sei Dank!!
Der geht bei einem Titan-Kühler sowie so verloren
> Hiho Nero,
>
> nachdem ich nun schon seit längerem nicht mehr hier auf dem Forum war und erst die Tage wieder das uralt Problem der via bug mit der southbridge auftauchte (KT 133 a). Wollte ich nun doch ein paar Fragen an Dich stellen.
>
> Du schreibst dass fast write bei AMD Systemen nichts bringt und man es daher disablen solle?
> Kannst du mir kurz sagen bei oder für was es dann Fastpath gibt. Bin mit dieser Einstellung leider immer noch nicht ganz dahinter gestiegen. Denn wenn es rein gar nichts bringt dann werde ich die Funktion auch mal disablen. Hab nämlich auch noch ein A7V133 der ersten Gattung und 2 Platten (ata100 nicht im raid verbund) + primary ide DVD Laufwerk, der rest ist SCSI aber das reicht schon, wie seinerzeits geleen für den bug). Ich kann zwar bis heute über fast keine crc Fehler klagen, aber beim Kopieren von einer auf die andere Platte bleibt der Vorgang einfach stehen. Bzw. ich brauche für 1 GB ca. 3 min zum kopieren. das kann doch auch nicht normal sein oder??? Ferner würde mich noch interessieren was es mit PCI Master Read Caching genau nochmal auf sich hat. Diese Einstellung hab ich auch auf enabled.
> Delayed Transaction -> Disabled ´hab ich da ich die Funktionsweise verstanden habe und damals schon Deinen Rat befolgte :-)
> Aber warum PCI Latency Timer -> 0 ?? Ich dachte immer je niedriger die Latenz, desto mehr wird der Bus (PCI) beansprucht. Wenn der Wert auf 0 steht, dann geht dies doch noch mehr zu Lasten des Busses oder Täusche ich mich da?? Hab den Standartwert 32. Auch mit ner sb live (in slot 4 da scsi adapter in Slot 3) noch nie Probleme gehabt, denk ich zumindest :-))
> Zu guter Letzt noch PCI to DRAM Prefetch -> ENABLED zu dieser Einstellung habe ich bisher immer noch keine genaue Definition gefunden und warum man sie wieder enabelen (hab ich zwar) ???
>
> Du würdest mir ungemein helfen wenn du mir zu meinen Fragen ne Hilfestellung geben könntest.
>
> Ich bedanke mich schon mal ganz herzlich im Voraus...
>
> In diesem Sinne...
>
> Mfg
> Gery aka P.s.y.c.Hi,
also die Option Fast Writes ist ein Teil der AGP 2.0 Spezifikation, aber auch wieder nicht so richtig *buck* Aus diesem Grund streiten Intel und VIA seit zwei Jahren vor Gericht. Intel sieht Fast Writes als eine eigene Entwicklung, VIA als Teil der Spezifikation.
In der Tat war es es so, daß Intel diese Option als erstes eingeführt hat, während VIA die Option nachträglich in ihre Chipsätze/BIOSe hineingeflickt hat. Das ist auch der Grund, warum die Option auf AMD-Systemen nichts bringt, weil die Option ursprünglich gar nicht vorgesehen war. Mit Fast Writes könnte der Chipsatz Geometrie-Daten direkt von der CPU zur Grafikkarte schicken ohne Umweg über das RAM, was natürlich theoretisch einen kleinen Performance-Vorteil bringen sollte. In der Praxis jedoch hat diese Option auf AMD-Systemen 0.0% gebracht, war im Gegenteil bei einige OpenGL-Games sogar kontraproduktiv und die System-Stabilität hat ebenfalls gelitten. Daher deaktivieren :)
Mit der Option PCI Master Read Caching kann der Chipsatz Zugriffe der PCI-Master Karten im L2-Cache des Athlon cachen. Aber in den letzten Monaten und Jahren hat die Performance der PCI-Karten derart zugelegt, daß die Verwaltung der PCI-Master Geräte des VIA-Chipsatzes unter gewissen Umständen Schwächen gezeigt hat. Hier berufe mich hier mal auf Mr. Chang (CEO von VIA):
http://www.planet3dnow.de/cgi-bin/newspub/comments.cgi?view=4317 (http://www.planet3dnow.de/cgi-bin/newspub/comments.cgi?view=4317)
Speziell beim 686B-Bug helfe das Verändern der Priorisierung auf dem PCI: Bei viel Verkehr muss der Prozessor normalerweise drei Busmaster-Anforderungen lang warten, bis er selbst wieder zugreifen darf. Falls Busmaster den PCI-Bus zu lange in Beschlag nehmen, scheint das jedoch zu einem Pufferüberlauf und schließlich zu dem Datenverlust in der Southbridge zu führen. Abhilfe lässt sich nach Changs Angaben dadurch schaffen, dass nur zwei statt drei Busmaster-Anforderungen zugelassen werden. Diese Einstellung tauge jedoch nicht als generelle Lösung, weil sie den isochronen Datentransfer auf dem PCI-Bus behindern könne. Isochrone Transfers benötigen eine garantierte Mindestbandbreite, etwa für Audio- oder Video-Streams. Eine Unterschreitung macht sich bei Audiodaten besonders deutlich durch Knackser bemerkbar.
Delayed Transaction dagegen ist eine Option, die immer wieder mal zu Problemen führt, die laut Heise auch auf Intel-Chipsätze bereits aufgetreten sind. Auch mit dem AMD 760MPX Chipsatz hatten wir Ärger mit Delayed Transaction. Daher am besten auch deaktivieren!
Mit der Option PCI to DRAM Prefetch hat es etwas Spezielles auf sich. Auf dem A7V133 mit Onboard-Sound hat diese Option zu Fehlern bei der Datenübertragung von Low-Bandwidth Geräten geführt, wenn sie deaktiviert war. Vergleiche dazu auch folgenden Thread:
http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=14342&highlight=a7v133 (http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=14342&highlight=a7v133)
Das Aktivieren von PCI to DRAM Prefetch hat das Problem behoben, weshalb es bei den neueren BIOS-Version des A7V133 auch wieder by Default aktiviert sein sollte :)
P.s.y.c.
13.02.2002, 23:49
Re,
vielen Dank! Dies hat meine noch offenen Fragen nun alle beantwortet :-))))
Mfg
P.s.y.c.
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.