Was bedeutet "Daten verifizieren"?

[Sven Wehking]

Hallo!

Man kann bei Nero 6 eine Option auswählen "Daten verifizieren"? Was bedeutet
das?

CiaoI
sVENi

[Jan-Christoph Langner]

Post by Sven Wehking
Man kann bei Nero 6 eine Option auswählen "Daten verifizieren"? Was bedeutet
das?

Dann werden die gebrannten Daten nochmal mit den Originaldaten auf der
Festplatte vergleichen ob sie identisch sind.

[Sven Wehking]

Post by Sven Wehking

Post by Sven Wehking
Man kann bei Nero 6 eine Option auswählen "Daten verifizieren"? Was

bedeutet

Post by Sven Wehking
das?

Dann werden die gebrannten Daten nochmal mit den Originaldaten auf der
Festplatte vergleichen ob sie identisch sind.

Wie lange dauert das bei einer gebrannten DVD mit 4,7 GB ungefähr? Und wie
lange bei einer vollen CD? Was ist wenn man eine Audio-CD gebrannt hat und
nur MP3s in das Projekt eingefügt hat? Kann man auch dann eine Verifizierung
durchführen? Ist solch ein Vorgang bei wichtigen CDs/DVDs ratsam?

CiaoI
sVENi

[Jan-Christoph Langner]

Post by Sven Wehking
Wie lange dauert das bei einer gebrannten DVD mit 4,7 GB ungefähr? Und wie
lange bei einer vollen CD? Was ist wenn man eine Audio-CD gebrannt hat und

Bei DVD: 1 Stunde durch Lesegeschwindigkeit
Bei CD: 80 Minuten durch Lesegeschwindigkeit

Post by Sven Wehking
nur MP3s in das Projekt eingefügt hat? Kann man auch dann eine Verifizierung
durchführen?

mal davon abgesehen das es keinen Sinn gibt (Kleine Störungen machen
Audio-CDs nicht so viel) wahrscheinlich nein. Das heisst wenn dus machst:
Das Brennprogramm wandelt die MP3s ja auch entsprechend um, dann werden
wahrscheinlich die umgewandelten Daten mit den geschriebenen verglichen.

Post by Sven Wehking
Ist solch ein Vorgang bei wichtigen CDs/DVDs ratsam?

naja bei ordentlichen Rohlingen eigentlich nicht. Schaden kanns allerdings
auch nicht. Ich hab bisher aber noch keinen Fall gehabt wo ich solche
Lesefehler hatte.

[Axel Berger]

Ich hab bisher aber noch keinen Fall gehabt wo ich solche Lesefehler
hatte.

Ich schon. und freundlicherweise sind hiesige Rohlinge - auch no-name
Billigmüll - weitgehend binär, also entweder o C2 oder Totalausfall, so
daß der Test auch etwas wert ist (trotzdem scanne ich meist).

[Matthias Schulze]

Post by Sven Wehking
Man kann bei Nero 6 eine Option auswählen "Daten verifizieren"? Was bedeutet
das?

1. Was sind Daten?
2. Was bedeutet "verifizieren"?

Und nun kombinieren wir die beiden Antworten und stellen fest: mit
dieser Funktion werden die auf das Medium geschriebenen Daten nach dem
Brennvorgang auf ihre Korrektheit geprüft. :-)

MfG,
Matthias

[Cedric Marais]

Post by Matthias Schulze
1. Was sind Daten?
2. Was bedeutet "verifizieren"?
Und nun kombinieren wir die beiden Antworten und stellen fest: mit
dieser Funktion werden die auf das Medium geschriebenen Daten nach dem
Brennvorgang auf ihre Korrektheit geprüft. :-)

Und wie werden die Daten "verifiziert"? Du willst doch nicht etwa behaupten,
dass eine Bug-verseuchte Software in der Lage ist "zu verifizieren"?

Wenn dir was an deinen Daten liegt, lässt du besser nicht eine ß-Software
'ran, sondern tust es selbst mittels md5Summen oder sha1.

[Alan Tiedemann]

Post by Cedric Marais
Und wie werden die Daten "verifiziert"? Du willst doch nicht etwa behaupten,
dass eine Bug-verseuchte Software in der Lage ist "zu verifizieren"?

Also ein einfaches fc sollte inzwischen sogar Nero hinkriegen.

Post by Cedric Marais
Wenn dir was an deinen Daten liegt, lässt du besser nicht eine ß-Software
'ran, sondern tust es selbst mittels md5Summen oder sha1.

Was aber theoretisch Fehler erlaubt.

Wenn, dann bitte mit fc vergleichen. Alles andere ist elitäres Gehampel.

Alan

[Jens Fangmeier]

On Tue, 23 Dec 2003 10:14:43 +0100, Cedric Marais

Post by Cedric Marais

Post by Matthias Schulze
1. Was sind Daten?
2. Was bedeutet "verifizieren"?
Und nun kombinieren wir die beiden Antworten und stellen fest: mit
dieser Funktion werden die auf das Medium geschriebenen Daten nach dem
Brennvorgang auf ihre Korrektheit geprüft. :-)

Und wie werden die Daten "verifiziert"? Du willst doch nicht etwa behaupten,

Ganz einfach: In dem man die gelesen Daten mit auf der Platte
vergleicht.

Also: if (a == b) then OK else FALSE.

Und das halt für jedes Byte!

Post by Cedric Marais
dass eine Bug-verseuchte Software in der Lage ist "zu verifizieren"?

Das ist nun so ziemlich die Grundoperation jedes Prozzessors: Daten
vergleichen.

Das sollte auch der dümmste Programm-Autor hinbekommen.

Zumal memcmp (verlgleichen von zwei Speicherblöcken) seit urzeiten zu
den C-Bibleothken gehört..

Tschau, Jens

[Matthias Schulze]

Post by Cedric Marais
Wenn dir was an deinen Daten liegt, lässt du besser nicht eine ß-Software
'ran, sondern tust es selbst mittels md5Summen oder sha1.

Naja, dann kann ich auch gleich mit Spatzen auf Kanonen schiessen. Oder
andersrum. ;-)
Was Nero macht, ist halt nur ein einfacher Vergleich der Daten. Bisher
hatte ich damit keine Probleme, die Daten waren auch nach Monaten noch
einwandfrei. Egal, ob Nero sie "verifiziert" hat oder nicht.

MfG,
Matthias

[Alan Tiedemann]

Post by Matthias Schulze

Post by Cedric Marais
Wenn dir was an deinen Daten liegt, lässt du besser nicht eine ß-Software
'ran, sondern tust es selbst mittels md5Summen oder sha1.

Naja, dann kann ich auch gleich mit Spatzen auf Kanonen schiessen. Oder
andersrum. ;-)

So ist es.

Post by Matthias Schulze
Was Nero macht, ist halt nur ein einfacher Vergleich der Daten.

Was im Endergebnis auf genau dasselbe rausläuft wie md5 oder sha1. Nur
daß Nero sich die Rechnerei spart und einfach so die Inhalte der Dateien
vergleicht.

md5, sha1 etc. sind eigentlich nur dann sinnvoll, wenn man *entfernt*
liegende Dateien vergleichen möchte. Rechner 1 in Timbuktu bildet eine
Prüfsumme ("Hash"), Rechner 2 in Hintertupfingen auch. Dann braucht man
nur die Prüfsummen quer um die Erdkugel zu blasen und kann bei
Gleichheit davon ausgehen, daß auch die Dateien gleich sind.

Aber es gibt halt Leute, die müssen alles so kompliziert wie möglich
machen, weil sie dann wichtig erscheinen *SCNR*

Alan

[Jens Fangmeier]

On Tue, 23 Dec 2003 21:30:00 +0100, Alan Tiedemann

Post by Alan Tiedemann

Post by Matthias Schulze

Post by Cedric Marais
Wenn dir was an deinen Daten liegt, lässt du besser nicht eine ß-Software
'ran, sondern tust es selbst mittels md5Summen oder sha1.

Naja, dann kann ich auch gleich mit Spatzen auf Kanonen schiessen. Oder
andersrum. ;-)

So ist es.

Post by Matthias Schulze
Was Nero macht, ist halt nur ein einfacher Vergleich der Daten.

Was im Endergebnis auf genau dasselbe rausläuft wie md5 oder sha1. Nur
daß Nero sich die Rechnerei spart und einfach so die Inhalte der Dateien
vergleicht.

Nein, da hast Du eine Sache bei vergessen:
Das Lesen von der Platte.

Bei md5 oder sha1 wird ja nur einmal von der Platte gelesen und dann
md5 berechnet und vergleichen.

Beim "richtigen" Veriy wird nochmal von der Platte gelesen.

Hierdurch werden also auch Lesefehler von der Platte (OK, nicht so
wahrscheinlich) aber - und das ist viel wichtiger: Auch verfälschte
Daten bei der Übertragung auf dem IDE-Bus erkannt (gerade bei zu
langen IDE-Kabeln oder unsauber verarbeiteten Gehäusen) ist das eine
durchaus nicht zu vernachlässigende ehlerquelle.


Tschau, Jens

[Alan Tiedemann]

Post by Jens Fangmeier
On Tue, 23 Dec 2003 21:30:00 +0100, Alan Tiedemann

[Auch Du darfst den Roman mal bitte kürzen ;-)]

Post by Jens Fangmeier

Post by Alan Tiedemann

Post by Matthias Schulze
Was Nero macht, ist halt nur ein einfacher Vergleich der Daten.

Was im Endergebnis auf genau dasselbe rausläuft wie md5 oder sha1. Nur
daß Nero sich die Rechnerei spart und einfach so die Inhalte der Dateien
vergleicht.

Das Lesen von der Platte.

Naja, ob das nun unbedingt so kritisch ist...

Post by Jens Fangmeier
Bei md5 oder sha1 wird ja nur einmal von der Platte gelesen und dann
md5 berechnet und vergleichen.
Beim "richtigen" Veriy wird nochmal von der Platte gelesen.

Ja. Und? Die meisten Platten sind schneller als die meisten
CD/DVD-Laufwerke.

Post by Jens Fangmeier
Hierdurch werden also auch Lesefehler von der Platte (OK, nicht so
wahrscheinlich) aber - und das ist viel wichtiger: Auch verfälschte
Daten bei der Übertragung auf dem IDE-Bus erkannt (gerade bei zu
langen IDE-Kabeln oder unsauber verarbeiteten Gehäusen) ist das eine
durchaus nicht zu vernachlässigende ehlerquelle.

Also wenn *dabei* schon Fehler auftreten, dann sind die ja beim Brennen
auch (an anderer Stelle) gewesen. Und dann ist *zweimal* von Platte
lesen *wesentlich* besser.

In Deinem Szenario würde das "Bilden eines Hashes beim Brennen" nämlich
genau diese Art von Fehlern *nicht* aufdecken - es wird nämlich
fehlerhaft gelesen, diese fehlerhaften Daten wandern auf die CD/DVD und
*danach* wird der *fehlerhafte* Hash-Wert mit den *fehlerhaften* Daten
verglichen - und der Test liefert das Ergebnis "fehlerfrei".

Wenn man *zweimal* von der Platte liest (einmal beim Brennen, einmal
beim Verifizieren) wird genau diese Situation vermieden. Da sporadische
Lesefehler ja zu unterschiedlichen Zeitpunkten auftreten, tritt nämlich
dann ein Unterschied beim Vergleichen auf - und es wird vollkommen
korrekt eine "fehlerhaft" gebrannte CD gemeldet.

Man sieht also: ein "echtes" Verify hat eigentlich nur Vorteile, weil
man auch unregelmäßig auftretende Lesefehler entlarven kann.

Alan

[Jens Fangmeier]

On Tue, 23 Dec 2003 22:20:28 +0100, Alan Tiedemann

Post by Alan Tiedemann

Post by Jens Fangmeier
On Tue, 23 Dec 2003 21:30:00 +0100, Alan Tiedemann

[Auch Du darfst den Roman mal bitte kürzen ;-)]

Post by Jens Fangmeier

Post by Alan Tiedemann

Post by Matthias Schulze
Was Nero macht, ist halt nur ein einfacher Vergleich der Daten.

Was im Endergebnis auf genau dasselbe rausläuft wie md5 oder sha1. Nur
daß Nero sich die Rechnerei spart und einfach so die Inhalte der Dateien
vergleicht.

Das Lesen von der Platte.

Naja, ob das nun unbedingt so kritisch ist...

Post by Jens Fangmeier
Bei md5 oder sha1 wird ja nur einmal von der Platte gelesen und dann
md5 berechnet und vergleichen.
Beim "richtigen" Veriy wird nochmal von der Platte gelesen.

Ja. Und? Die meisten Platten sind schneller als die meisten
CD/DVD-Laufwerke.

Post by Jens Fangmeier
Hierdurch werden also auch Lesefehler von der Platte (OK, nicht so
wahrscheinlich) aber - und das ist viel wichtiger: Auch verfälschte
Daten bei der Übertragung auf dem IDE-Bus erkannt (gerade bei zu
langen IDE-Kabeln oder unsauber verarbeiteten Gehäusen) ist das eine
durchaus nicht zu vernachlässigende ehlerquelle.

Also wenn *dabei* schon Fehler auftreten, dann sind die ja beim Brennen
auch (an anderer Stelle) gewesen. Und dann ist *zweimal* von Platte
lesen *wesentlich* besser.

Genau das habe ich doch gesagt.

Post by Alan Tiedemann
In Deinem Szenario würde das "Bilden eines Hashes beim Brennen" nämlich
genau diese Art von Fehlern *nicht* aufdecken - es wird nämlich
fehlerhaft gelesen, diese fehlerhaften Daten wandern auf die CD/DVD und
*danach* wird der *fehlerhafte* Hash-Wert mit den *fehlerhaften* Daten
verglichen - und der Test liefert das Ergebnis "fehlerfrei".

Wie gesagt: Genau so habe ich es gesagt.
Du hast gesagt: "Was im Endeffekt auf genau dasseble rausläuft wie md5
oder sha1".

Und genau das habe ich eben - mit dieser begründung - verneint.

Post by Alan Tiedemann
Wenn man *zweimal* von der Platte liest (einmal beim Brennen, einmal
beim Verifizieren) wird genau diese Situation vermieden. Da sporadische
Lesefehler ja zu unterschiedlichen Zeitpunkten auftreten, tritt nämlich
dann ein Unterschied beim Vergleichen auf - und es wird vollkommen
korrekt eine "fehlerhaft" gebrannte CD gemeldet.
Man sieht also: ein "echtes" Verify hat eigentlich nur Vorteile, weil
man auch unregelmäßig auftretende Lesefehler entlarven kann.

Nichts anderes habe ich doch gesagt!

Tschau, Jens

[Alan Tiedemann]

Post by Jens Fangmeier
On Tue, 23 Dec 2003 22:20:28 +0100, Alan Tiedemann

[Bitte kürz das mal :-(]

Post by Jens Fangmeier

Post by Alan Tiedemann

Post by Jens Fangmeier
Hierdurch werden also auch Lesefehler von der Platte (OK, nicht so
wahrscheinlich) aber - und das ist viel wichtiger: Auch verfälschte
Daten bei der Übertragung auf dem IDE-Bus erkannt (gerade bei zu
langen IDE-Kabeln oder unsauber verarbeiteten Gehäusen) ist das eine
durchaus nicht zu vernachlässigende ehlerquelle.

Also wenn *dabei* schon Fehler auftreten, dann sind die ja beim Brennen
auch (an anderer Stelle) gewesen. Und dann ist *zweimal* von Platte
lesen *wesentlich* besser.

Genau das habe ich doch gesagt.

Sorry, ich hatte das "hierdurch" falsch interpretiert.

Alan

[Werner Holtfreter]

Post by Jens Fangmeier
Beim "richtigen" Veriy wird nochmal von der Platte gelesen.
Hierdurch werden also auch Lesefehler von der Platte (OK, nicht so
wahrscheinlich) aber - und das ist viel wichtiger: Auch
verfälschte
Daten bei der Übertragung auf dem IDE-Bus erkannt (gerade bei zu
langen IDE-Kabeln oder unsauber verarbeiteten Gehäusen) ist das
eine durchaus nicht zu vernachlässigende ehlerquelle.

Spätestens seit VIA die Welt mit defekten Chipsätzen überschwemmt
hat, sind sporadische Datenverfälschungen leider nicht
auszuschließen! Ich habe das beim Spiegeln ganzer Festplatten immer
wieder erlebt, bis ich DMA ausgeschaltet habe, dann war Ruhe.

Prüfaktivitäten an den Dateien sind also auch immer ein
praxisgerechter Hardwarecheck.

[Alan Tiedemann]

Post by Werner Holtfreter

Post by Jens Fangmeier
Beim "richtigen" Veriy wird nochmal von der Platte gelesen.
Hierdurch werden also auch Lesefehler von der Platte (OK, nicht so
wahrscheinlich) aber - und das ist viel wichtiger: Auch
verfälschte
Daten bei der Übertragung auf dem IDE-Bus erkannt (gerade bei zu
langen IDE-Kabeln oder unsauber verarbeiteten Gehäusen) ist das
eine durchaus nicht zu vernachlässigende ehlerquelle.

Spätestens seit VIA die Welt mit defekten Chipsätzen überschwemmt
hat, sind sporadische Datenverfälschungen leider nicht
auszuschließen!

Das hat mit VIA überhaupt nichts zu tun.

Post by Werner Holtfreter
Ich habe das beim Spiegeln ganzer Festplatten immer
wieder erlebt, bis ich DMA ausgeschaltet habe, dann war Ruhe.

Komischerweise hatte ich bei den ca. 40-50 VIA-Chipsatz-PCs, die ich in
den letzten Jahren gebaut hatte, nie solche Probleme.

Post by Werner Holtfreter
Prüfaktivitäten an den Dateien sind also auch immer ein
praxisgerechter Hardwarecheck.

Das ist zwar richtig, das pauschale Eindreschen auf VIA ist aber
schlicht falsch.

Alle Lesefehler, die ich bisher "gefunden" habe (auch bei Kunden) ließen
sich auf zwei Fehlerquellen eingrenzen:
- defektes oder falsches Kabel,
- defektes RAM,
- falsche Treiber installiert (beliebtester Fehler: VIA 4-in-1 auf
VIA/AMD-Mischboards installieren!).

Alan

[Alan Tiedemann]

Post by Alan Tiedemann
Alle Lesefehler, die ich bisher "gefunden" habe (auch bei Kunden) ließen

^^^^ drei!

Post by Alan Tiedemann
- defektes oder falsches Kabel,
- defektes RAM,
- falsche Treiber installiert (beliebtester Fehler: VIA 4-in-1 auf
VIA/AMD-Mischboards installieren!).

Zählen lerne ich dann nächstes Jahr ;-)

Alan

[Werner Holtfreter]

Post by Alan Tiedemann
das pauschale Eindreschen auf VIA ist aber
schlicht falsch.

Auf die schnelle mal ergooglt:

VIA's Wenchi Chen im Interview - reported by doelf
Ein Auszug:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tecChannel.de:. Der Fehler in der Southbridge ist ganz einfach
zu reproduzieren, das ist kein esoterisches und rares Problem. Das
kann den Leuten wirklich passieren. Sieht das nicht nach
hausgemachten Problemen beim Testen von neuen Produkten aus?
Chen: Als wir wussten, dass es diesen Bug wirklich gibt, war
es viel leichter, ich glaube, es war eine Creative-Soundkarte...
tecChannel.de: Der Fehler tritt generell auf, wenn die
DMA-Kanäle stark belastet sind. Es kann also auch zum Beispiel mit
einem Video-Digitizer passieren.
Chen: Ja, das war auch für unser Team überraschend. Ich weiß
nicht, wie viele Millionen dieser Southbridges wir schon
^^^^^^^^^^^^^^^
ausgeliefert haben. Wir installieren gerade ein viel größeres Team,
um all das zu testen. Wir müssen einen immer besseren Job machen...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Post by Alan Tiedemann
Alle Lesefehler, die ich bisher "gefunden" habe (auch bei Kunden)
[...]
- falsche Treiber installiert (beliebtester Fehler: VIA 4-in-1 auf
VIA/AMD-Mischboards installieren!).

Die VIA 4-in-1 sind das Eingeständnis des Bugs und der *Versuch*,
durch rumdrehen am Timing den Bug zu umschiffen. Bei mir läuft
Linux und weil ich keine Lust habe, in dieser Richtung große
Experimente zu machen, darf ich mich nun über ein nicht sinnvoll
nutzbares DMA freuen. Gut möglich, dass ich beim nächsten Board zu
Intel wechsele - die haben seinerzeit die Prozessoren getauscht,
wenn sich jemand am Arithmetikfehler gestört hat.

[Joerg Schilling]

Post by Werner Holtfreter

Post by Alan Tiedemann
das pauschale Eindreschen auf VIA ist aber
schlicht falsch.

VIA's Wenchi Chen im Interview - reported by doelf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tecChannel.de:. Der Fehler in der Southbridge ist ganz einfach
zu reproduzieren, das ist kein esoterisches und rares Problem. Das
kann den Leuten wirklich passieren. Sieht das nicht nach
hausgemachten Problemen beim Testen von neuen Produkten aus?
Chen: Als wir wussten, dass es diesen Bug wirklich gibt, war
es viel leichter, ich glaube, es war eine Creative-Soundkarte...

Und interessant ist, daß der Fehler bei Festplatten typischerweise
nicht auftritt. Auch nicht bei vielen CD Brenern, wohl aber bei
allen Plextor CD Brennern die ich getestet habe.

Auch wenn VIA einen Treiber für M$ anbietet der den Fehler vielleicht
in vielen Fällen zu verschwinden bringt...

Wer Standardkonforme Betriebssysteme verwendet, der bekommt von VIA
keine Hilfe.

Ich habe zwar noch nicht probiert was bei Solaris passiert, bei Linux
tritt der Fehler definitiv auf.

Fazit: das pauschale Herunterspielen der Probleme ist schlichtweg falsch.

[Bernd Mayer]

Post by Joerg Schilling
Und interessant ist, daß der Fehler bei Festplatten typischerweise
nicht auftritt. Auch nicht bei vielen CD Brenern, wohl aber bei
allen Plextor CD Brennern die ich getestet habe.
Auch wenn VIA einen Treiber für M$ anbietet der den Fehler vielleicht
in vielen Fällen zu verschwinden bringt...
Wer Standardkonforme Betriebssysteme verwendet, der bekommt von VIA
keine Hilfe.
Ich habe zwar noch nicht probiert was bei Solaris passiert, bei Linux
tritt der Fehler definitiv auf.

Hallo Joerg,

doch - der Fehler trat bei einer Kopieraktion von einer Festplatte auf
die andere auf und endete mit totalem Datenverlust. Das Board hatte ich
mir extra gekauft um von den neuen Fähigkeiten, damals UDMA-66, zu
profitieren. Beim Aufrüsten wird ja immer empfohlen die neue und zumeist
schnellere Festplatte als Laufwerk für das Betriebssystem zu verwenden.
Bei diesem Umkopieren entstand der Datenverlust. Eine
Creative-Soundkarte, wie sie in den Fehlerberichten häufig erwähnt
wurde, war auch eingebaut. Das Umkopieren erfolgte jedoch ohne Musik.
Diese Soundkarten sind ja ansonsten eher als hochkompatibel und
unproblematisch bekannt

Grüsse


Bernd Mayer

[Joerg Schilling]

Post by Bernd Mayer
doch - der Fehler trat bei einer Kopieraktion von einer Festplatte auf
die andere auf und endete mit totalem Datenverlust. Das Board hatte ich

Um was für einen Chipsatz geht es bei Dir?

Ich habe bislang bei einem KT133A keine Probleme mit der Festplatte gehabt.

Sonst hätte ich das Problem sicherlich eher bemerkt (ich wußte nicht
was für Chips drinwaren....). Ich habe es erst bemerkt, als ich einen
Satz SuSE Cds kopieren wollte und das Ergebnis zwar bootet aber sich nicht
installieren lassen wollte. Ich dachte zuerst an einen Kopierschutz, weil
eine Kopie im RAW mode funktionierte. Da ich vorher auf dem PC nur cdrecord
tests gefahren habe wo man selten prüft ob der _inhalt_ OK ist, kam die
Erkenntnis erst nach einem dreiviertel Jahr.

Inzwischen ist eine andere Festplatte drin und auch diese Festplatte macht
immer noch keine Probleme....

[Bernd Mayer]

Post by Joerg Schilling

Post by Bernd Mayer
doch - der Fehler trat bei einer Kopieraktion von einer Festplatte auf
die andere auf und endete mit totalem Datenverlust. Das Board hatte ich

Um was für einen Chipsatz geht es bei Dir?
Ich habe bislang bei einem KT133A keine Probleme mit der Festplatte gehabt.

Hallo Joerg,

VIA 82C598MVP:

Host Bridge VT82C598 (Apollo MVP3)
PCI Bridge VT 82C598/694X (Apollo MVP3/Pro133x AGP)
ISA Bridge Vt82C596 ISA (Mobile South)
IDE interface VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE (rev
16)

Grüsse und frohes Fest


Bernd Mayer

[Joerg Schilling]

Post by Bernd Mayer

Post by Joerg Schilling

Post by Bernd Mayer
doch - der Fehler trat bei einer Kopieraktion von einer Festplatte auf
die andere auf und endete mit totalem Datenverlust. Das Board hatte ich

Um was für einen Chipsatz geht es bei Dir?
Ich habe bislang bei einem KT133A keine Probleme mit der Festplatte gehabt.

Hallo Joerg,
Host Bridge VT82C598 (Apollo MVP3)
PCI Bridge VT 82C598/694X (Apollo MVP3/Pro133x AGP)
ISA Bridge Vt82C596 ISA (Mobile South)
IDE interface VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE (rev
16)

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 20)

Was hast Du? Ich habe jedenfalls Schwierigkeiten beim Vergleich...

[Bernd Mayer]

Post by Joerg Schilling

Post by Bernd Mayer
doch - der Fehler trat bei einer Kopieraktion von einer Festplatte auf
die andere auf und endete mit totalem Datenverlust. Das Board hatte ich

Um was für einen Chipsatz geht es bei Dir?
Ich habe bislang bei einem KT133A keine Probleme mit der Festplatte gehabt.

Hallo Joerg,

das ist ein a. 3 Jahre altes Motherboard für Super7-Sockel mit KII-500
Prozessor.

Die Fehlersuche war sehr nervig, da mir zum Zeitpunkt des Datenverlustes
die Probleme mit dem VIA-Chipsatz nicht bekannt war. Daher hatte ich
zunächst mehrmals alles sorgfältigst überprüft (Kabel, Festplatten,
BIOS-Einstellungen usw.) und auch schon erwogen das Board zurückzugeben.
Ich konnte allerdings zunächst den Fehler nicht präzise lokalisieren.
Ich habe dann einen Promise-IDE-Kontroller dazugekauft, auch zum Testen
weil ich zu dem Zeitpunkt kein anderes Board mit UDMA-66 hatte, und
statt der AGP-Grafikkarte eine PCI-Karte eingebaut. Der Rechner war mir
lange suspekt nach diesen Erfahrungen (Der Datenverlust war wirklich
krass, auf beiden Festplatten und das System bootete danach auch nicht
mehr - IIRC). Ich hatte zwar Backups von ca. 90 % - 95 % der Daten,
irgendwas verliert man dennoch immer und Spass macht solch eine
Fehlersuche, Neuinstallation und Backupszusammensuchen usw. gewiss
nicht.

Mit meinen Umbauten funktioniert das Board allerdings bis heute in einer
anderen Funktion als ursprünglich geplant.

Grüsse


Bernd Mayer

[Werner Holtfreter]

Post by Bernd Mayer
Ich habe dann
einen Promise-IDE-Kontroller dazugekauft [...]
Mit meinen Umbauten funktioniert das Board allerdings bis heute in
einer anderen Funktion als ursprünglich geplant.

Willst du damit sagen, die DMA-Probleme haben sich durch Verwendung
des Promise-IDE-Kontrollers erledigt? Fände ich seltsam, die Daten
für die Festplatten laufen ja trotzdem über die Südbrücke.

Zu meinen Erfahrungen: Bei Kopieraktionen innerhalb einer Festplatte
oder von FP zu FP ab ca. 1 GB (!) gab es Datenverfälschungen.

Aufgefallen ist mir das auch erst beim Spiegeln ganzer Festplatten,
was Teil meines Backupkonzepts ist.

Mit Ausschalten von DMA ist der Fehler weg, ich habe seither schon
oft erfolgreich gespiegelt - seither aber immer mit Prüfsumme über
beide Festplatten.

Ob es nun an meinem VIA VT82C686A (A, nicht B) liegt, kann ich nur
vermuten, fest steht nur der Zusammenhang mit eingeschaltetem DMA.
(Ja, die Fehlersuche war auch bei mir nicht lustig!)

[Bernd Mayer]

Bernd Mayer wrote:

[Probleme mit VIA-Chipsätzen wie z.B. Datenverlust]

Nachtrag: siehe auch

http://www.heise.de/newsticker/data/jow-12.04.01-001/

"In der VIA-Soutbridge 82C686B steckt ein Fehler, der zu fehlerhaften
Festplatten-Transfers f?hren kann. Der Fehler tritt in Erscheinung, wenn
w?hrend hoher Last auf dem PCI-Bus gro?e Datenmengen vom ersten zum
zweiten IDE-Kanal wandern. Der Chipsatzhersteller VIA best?tigt diesen
Fehler mittlerweile offiziell."

Grüse


Bernd Mayer

[Alan Tiedemann]

Post by Werner Holtfreter

Post by Alan Tiedemann
das pauschale Eindreschen auf VIA ist aber
schlicht falsch.

VIA's Wenchi Chen im Interview - reported by doelf

Ja, den Bericht kenne ich. Das Problem trat halt im Zusammenhang mit
stark DMA-lastigen PCI-Karten auf - das hat man wohl leider übersehen.
Seit etwa drei Jahren sollte das Problem aber wirklich behoben sein -
wenn auch "nur" im Treiber, und bei sehr vielen Boards sogar im BIOS.

Post by Werner Holtfreter
Die VIA 4-in-1 sind das Eingeständnis des Bugs und der *Versuch*,
durch rumdrehen am Timing den Bug zu umschiffen. Bei mir läuft
Linux und weil ich keine Lust habe, in dieser Richtung große
Experimente zu machen, darf ich mich nun über ein nicht sinnvoll
nutzbares DMA freuen.

Das liegt aber, wenn man Jörg Schilling mal liest, nicht unbedingt am
Board, sondern an der dillettantischen Unterstützung von DMA in Linux.

Post by Werner Holtfreter
Gut möglich, dass ich beim nächsten Board zu
Intel wechsele - die haben seinerzeit die Prozessoren getauscht,
wenn sich jemand am Arithmetikfehler gestört hat.

Auch der Bug ist inzwischen längst behoben (meinst Du den FDIV-Bug?).

Alan

[Bernd Mayer]

Post by Alan Tiedemann
Komischerweise hatte ich bei den ca. 40-50 VIA-Chipsatz-PCs, die ich in
den letzten Jahren gebaut hatte, nie solche Probleme.
Alle Lesefehler, die ich bisher "gefunden" habe (auch bei Kunden) ließen
- defektes oder falsches Kabel,
- defektes RAM,
- falsche Treiber installiert (beliebtester Fehler: VIA 4-in-1 auf
VIA/AMD-Mischboards installieren!).

Hallo Alan,

ich hatte mit einem VIA-Chipsatz (schon eine Weile her) schon krasse
Datenverluste erlebt. Am VIA 4-in-1 lag es nicht, da als Betriebssystem
Linux verwendet wurde. Das mit dem 4-in-1 Treibern ist eh ein Käse, weil
da empfohlen wurde bei der Installation dieses Treibers zunächst nur die
Grafikkarte einzubauen - IIRC. In der Praxis bedeutet das ja, dass man
nach einem Absturz und der folgenden Neuinstallation von Windows und den
Treibern den Rechner öffnen muss und alle übrigen Karten ausbauen muss,
dann den 4-in-1 installieren und danach die restlichen Karten wieder
einbauen kann - das ist wirklich ein unverhältnismässiger Aufwand. Der
Aufwand für die Ursachenforschung des Datenverlustes war auch nicht
unerheblich!

Ausserdem, was nützt dieser Treiber den Anwendern andererer
Betriebssysteme - irgendwas ist daran wirklich ungewöhnlich oder gar
verdächtigt (das wurde ja später nach und nach veröffentlicht und
bestätigt), da ich eine solche Vorgehensweise (Installation nur mit
minimalem Kartenausbau) sonst noch bei keinem andern Motherboard/Chisatz
gesehen habe.

Grüsse


Bernd Mayer

[Cedric Marais]

Post by Alan Tiedemann
Aber es gibt halt Leute, die müssen alles so kompliziert wie möglich
machen, weil sie dann wichtig erscheinen *SCNR*

Erste und zweite Aussage in deinem Satz stehen in keinem logischen
Zusammenhang, sondern verbinden sich erst in deinem Kopf zu einem scheinbar
solchen. Naja, was soll's.

[Alan Tiedemann]

Post by Cedric Marais

Post by Alan Tiedemann
Aber es gibt halt Leute, die müssen alles so kompliziert wie möglich
machen, weil sie dann wichtig erscheinen *SCNR*

Erste und zweite Aussage in deinem Satz stehen in keinem logischen
Zusammenhang, sondern verbinden sich erst in deinem Kopf zu einem scheinbar
solchen. Naja, was soll's.

Es ist nicht mein Problem, wenn Du einfache logische Schlußfolgerungen
nicht nachvollziehen kannst ;-)

Vielleicht ist es für Dich auch schlicht zu einfach *SCNR*

Alan

[Cedric Marais]

Post by Alan Tiedemann
Es ist nicht mein Problem, wenn Du einfache logische Schlußfolgerungen
nicht nachvollziehen kannst ;-)
Vielleicht ist es für Dich auch schlicht zu einfach *SCNR*

Es ist Weihnachten, Alan. Ich wär' ein Narr, wenn ich dir zu dieser Zeit
nur meine linke Wange anbieten würde. ;-)