Hardware-Defekt oder Problem mit 6.2?

A

axl

Active Member
Hallo, Kollegen!

Seit Samstag versuche ich nun, FreeBSD auf meine neue (alte) Serverplattform zu bekommen. Bei allen Versuchen wurde offensichtlich das Schreiben des Basissystems auf die frisch formatierte Festplatte abgebrochen, die Fehlermeldungen habe ich wegen des sehr schnellen Reboot nie komplett lesen können. Das Verhalten war mit 5.5, 6.1 und 6.2 gleich.

Jetzt spiele ich mit FreeNAS und bekomme erstmals eine Meldung, die mir sinnvoll erscheint:

"ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=63"

Das kommt 3x bis zum Abbruch.

Die Festplatte hat bei mehrmaligem badblocks-Scan keine Auffälligkeiten gezeigt. Kann der IDE-Controller auf dem Mainboard einen Treffer haben? (Board ist ein Abit KT7A-RAID mit Athlon 900).

Danke im Voraus!

Axel

Edit:
Zur Erkärung der Überschrift: FreenAS basiert auf einem 6.2er-Kernel.
 
Zuletzt bearbeitet:
Danke, Yamagi!

Ich habe die Kanäle getauscht, bleibt gleich.
Vor 'ner Stunde habe ich ein neues Mainboard abholen können (hatten die Nachbarn angenommen), damit geht's. Scheint also tatsächlich das Mainboard zu sein. Spannend, dass Linux nicht gemeckert hat... (Ubuntu 6.06 Server)

Schade um's Board, das ist wohl Elektronikschrott. Wäre mir wichtiger gewesen als die alte Testplatte.

Ich freu' mich auf 6.2 :-)

Grüße,
Axel
 
harrr dann is linux mittlerweile wie windows, das hatte bei meinen kabeln damals auch nie rumgemeckert, nur freebsd.
<ironie>sollte freebsd im sinne der user nicht endlich mal mit windows gleichziehen?</ironie>

schrott ist das board nicht, verkaufe es bei ebay, findet sich sicher jemand.
 
Moin, Möp!

Dummerweise kommt das Board gerade aus der Bucht. Ganz frisch und keinesfalls "defekt"....

BSD punktet immer mehr bei mir. Spätestens nach dieser Erfahrung kehre ich Linux endgültig den Rücken.
(Na ja, auch die sehr schöne Erfahrung mit pfsense vom Wochenende hat mich schon bestärkt. Der Entschluss steht.)

Dann seh'n wir uns ja jetzt öfter...

Grüße,
Axel
 
Das gibt's ja wohl nicht!!

Die gleiche Festplatte (Samsung SV2042H), mein altes workstation-board (MSI K7N2 Delta2) mit Barton 3000. 6.1 in kürzester Zeit instaliert (per boot-ISO).

Reboot -> Fehlermeldung -> reboot -> Fehlermeldung etc.
(boot ohne ACPI macht keinen Unterschied)

---
Fatal trap 18
(...)
integer divide fault while in kernel mode
panic: integer divide fault
cannot dump. no dump device defined
will reboot in 15 seconds - press a key on the console to abort

---
Das geht ohne Pause so durch.
Was ist da los?

Axel

Edit:
Zurück auf ein weiteres altes Board (MSI mit Athlon 900), gleiche hdd dran: Geht einwandfrei....
Ist das board, mit dem ich ca. 1,5 Jahre gearbeitet habe, jetzt auch Schrott???
 
Zuletzt bearbeitet:
reichen ja paar gb muss ja nicht die ganze platte frei werden. aber hast ja recht, wer riskiert schon gerne seine backups :D
 
Dummerweise hängen sie im Linux-RAID-5. Deswegen muss ich erstmal das RAID auflösen (also auf andere Partitionen verschieben), bevor ich die Platten aus dem Verbund lösen kann.

Ist ein Vollzeitjob. Und das jetzt, wo mir mit Glück 2x 2 Stunden pro Woche zum Schrauben bleiben. :-(
 
axl schrieb:
Fatal trap 18
(...)
integer divide fault while in kernel mode
panic: integer divide fault
cannot dump. no dump device defined
will reboot in 15 seconds - press a key on the console to abort
Zum Vergrößern anklicken....

Aus der "Fehlermeldung" kann man sich praktisch gar nichts entnehmen. Muss ausserdem auch nicht heissen, das die Hardware defekt ist. Evtl. laeuft sie einfach nur nicht sauber mit BSD. Und 6.2 ist ein RC. Den gibts deshalb, dass man genau solche Fehler melden kann, dass sie vorm Release noch gefixt werden. Warum ihr Euch fuer den Einstieg fast schon generell immer irgendwelche currents und RCs usw. aussucht, versteh ich auch nicht.
 
Stimmt, bin sofort reumütig zu 6.1 zurückgekehrt nach dem ersten Schluckauf mit 6.2. 5.5 wollte ich eigentlich nur noch für mein altes Notebook anfassen, nicht mehr für die etwas aktuelleren server und desktops.

Heute Abend wag ich's vielleicht noch mal. Danke Euch auf jeden Fall!
 
Hallo!

Derartige Phänomene konnte ich mit FreeBSD schon öfter sehen. Andere Betriebssysteme arbeiten auf der gleichen Hardware einwandfrei, aber FreeBSD hat diese DMA_TIMEOUTs. Ich vermute, dass es damit zusammenhängt, dass FreeBSD hier versucht die volle Leistung auszuschöpfen (UDMA100 oder gar UDMA133) aber irgendeine Komponente kann damit eigentlich gar nicht (richtig) umgehen (Controller, Kabel oder Platte).

Dummerweise habe ich immer noch nicht herausgefunden wie man UDMA66 oder 33 erzwingen könnte (ich habe aber ehrlich gesagt auch nicht sonderlich intensiv danach gesucht, alte Hardware ist eben alt Punkt).

Ich kann UDMA nur ganz abschalten: echo "set hw.ata.ata_dma=1" >>/boot/loader.conf.local

Ciao.
Markus Mann
];-)
 
Moin!

Das Board schient hin zu sein. Mit einer aktuellen hdd (Seagate ST3250620A, eine Barracuda 7200.10) gibt's ebenfalls DMA-Fehler am laufenden Band.

Der Hinweis auf die hohen DMA-Modi ist natürlich auch interessant. Das KT7A RAID soll ja einen UltraATA133-Controller haben. (Der RAID-Chip macht "nur" Ultra100).

Ich probier's noch mal über's BIOS, wenn sich nichts ändert, sehe ich zu, dass ich das Board zurückschicken kann...

Danke,
Axel
 
hatte gerade die selben fehler... habe im Bios die einstellungen verändert, funktioniert jetzt alles einwandfrei...
 
sind die BIOS'e alle auf dem neusten Stand?

ansonsten würde ich mal das IDE-Kabel tauschen; evtl. die Platte alleine an einem Kanal laufen lassen (CD-LW am Sek. Kanal)

Memtest x86 mal laufen lassen wäre auch noch eine Idee.


Es ist schon so, läuft auf einem Rechner FreeBSD einwandfrei, ist die Hardware in Ordnung (eigene persönliche Erfahrung)

Edit: achja, um den UDMA33 zu erzwingen, einfach ein "altes" 40-pin IDE Kabel verwenden.
 
das veranlasst mich denn auch zu einem unquallifizierten Beitrag.
Bisher habe ich Free-BSD und Desktop-BSD auf etwa einem halben dutzend PCs aufgespielt (Desktop-BSD auf einem Laptop), Probleme hatte ich immer nur mit mir und BSD, niemals mit der Hardware.
Deshalb kommt mich schon etwas befremdlich vor, wenn hier getan wird, als wäre BSD da so empfindlich und vor allem, deshalb, weil es vermutlich alle Resourcen ausnutzen möchte. Hmm.
Wesentlich mehr Erfahrung (ebenfalls als Low-Level-User) habe ich allerdings mit GNU/Linux und ehrlich: das läuft doch wenigstens genauso performant.
Toleranz gegenüber billiger HW, in dem Treiber entsprechend angepasst werden, ist nicht ein Zeichen eines schwachen Betriebssystems.

Außerdem und davon unbelastet: meine eigenen Arbeitsrechner laufen mit SCSI-Platten :-)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben