spontane Reboots

Yoda

Yoda

[Linux|FreeBSD] - User
Hi Leute,
seit ich meinen alten Celeron 700MHz, 512MB-RAM samt Board mit Intel-Chip-Set gegen einen Pentium-M 1,73GHz, 2048MB-RAM mit SiS-Board ausgetauscht habe, kann ich keine großen Partitionen mehr benutzen und keine großen Datenmengen mit hoher geschwindigkeit kopieren.

Nicht das es nicht geht, das geht sehr gut aber nur für ein paar Minuten (manchmal auch nur Sekunden) und dann gibt es einen Reboot....

* Mein System ist ein FreeBSD-6.2-RELEASE-p7.
* Mein Platten: 160 GB S-ATA für System; 2x320 GB S-ATA in SoftRAID (atacontrol: ar0)

Ich hatte ursprünglich einen SiL3114-Controller drin, der lief im 700MHz-Celeron prima und im Pentium jetzt überhaupt nicht mehr. Der on-Boar-Controller kann die Platten wenigstens (langsam) ansprechen, aber wehe es sind mal größere Datenmengen, wie zum Beispiel 10GB oder mehr am Stück...

In der "/var/log/messages" stehen dann solche Meldungen drin (DMA aktiv):

Code: 
Oct  2 07:58:29 erde kernel: g_vfs_done():ar0s1a[WRITE(offset=315998748672, length=16384)]error = 1
Oct  2 07:59:00 erde kernel: g_vfs_done():ar0s1a[WRITE(offset=315998748672, length=16384)]error = 1
Code: 
Zum Reboot stand dann immer etwas mit "alloc" oder so ähnlich. Da habe ich aber kein Foto von.

Dann habe ich zwei Nächte gegoogelt, und habe auch haufenweise Leute gefunden die soein Problem hatten. Leider hatte da jeder etwas anderes in Verdacht, keiner wusste was und eine Lösung war auch fern.

Letzte Nacht habe ich dann einen Post gefunden, in dem behauptet wurde, das man das Problem durch deaktivieren von DMA umgehen kann. Nicht schön, aber ich hab daraufhin in meinem System komplett überall DMA abgeschaltet und er hatte schon etwas länger durchgehalten bis zum Reboot....
Meistens wird der Reboot beim kopieren von dem RAID ausgelöst, das liegt aber daran, das ich auf der Systemplatte kaum was mache. Wenn ich etwas mit TAR packe und gleich durch "bzip2 -9" pipe, dann wird er langsammer und es kommt sehr selten zum Reboot. Beim direkten kopieren (auch auf USB-Platte) wird es in kurzer Zeit rebootet.

Und es sah dann so aus wie auf dem angehängten Foto.

All die Lösungen oder Vermutungen, die ich gelesen hatte trafen auf mein System nicht zu.
Da wurden Dinge wie:

- defekte Platte, kann nicht sein, in einem anderen Rechner läuft sie super;
- defekter Controller, kann nicht sein, da der PCI-SATA-Controller ein Jahr ohne Probleme lief und auch der (neue) on-Board die selben Probleme macht;
- SoftRAID, kann auch nicht sein, da es in allen anderen Systemen in identischer Version super lief, ausserdem haben die meisten das Problem auch ohne RAID;

genann.


Ich schätze es ist irgendein Konfigurationsproblem. Möglicherweise muss man im Kernel eine Option so modifizieren, das er die IRQ nicht ganz so schnell hintereinander auslöst oder das er größere Datenmängen in irgendeinen Puffer verwalten kann, oder sowas...

Was meint Ihr?
Ich kann diese Meldungen nicht wirklich interpretieren, weiß einer etwas?
Ich bin für Jeden Tip dankbar.

Gruß
Yoda
 
hier das Foto, so sieht es mit abgeschaltetem DMA aus
 

Anhänge

  • FreeBSD-SiS-Board-Fehler.jpeg
    FreeBSD-SiS-Board-Fehler.jpeg
    116,7 KB · Aufrufe: 502
Hallo Yoda ;-)

wenn du verlaeesliches RAID willst, solltest du entweder auf gmirror oder aber einen RAID Controller setzen, der den Namen auch verdient. Eine weitere aber unwahrscheinliche Schwachstelle waere der Chipset von SiS.
 
j_t schrieb:
Hallo Yoda ;-)

wenn du verlaeesliches RAID willst, solltest du entweder auf gmirror oder aber einen RAID Controller setzen, der den Namen auch verdient. Eine weitere aber unwahrscheinliche Schwachstelle waere der Chipset von SiS.
Zum Vergrößern anklicken....

Hi j_t ;-)
lange nicht gesehen...
Ja, das habe ich die letzten Nächte auch gelesen, aber da waren auch einige bei, die genau dieses Problem mit gmirror hatten...

Ich vermute auch, das es mit dem SiS-Chip-Set zutun hat, aber dafür muss es doch einen Workaround geben......?
Ein anderes Board kann ich nicht nehmen, da ich sonst die Stromspareigenschaften der CPU nicht voll nutzen kann.
 
Kann es vielleicht hiermit zu tun haben?

vfs.hifreebuffers: 812
vfs.lofreebuffers: 406
vfs.numfreebuffers: 7196

eigentlich sind die "num..."-Werte doch die aktuellen
und die anderen beiden sind jeweils die Ober- und Untergrenze.

Nur wie kann der aktuelle Wert größer als der Höchstwert sein?

Oder bin ich hier auf dem Holzweg?
 
g_vfs_done

vielleicht hilft es ja, hier noch die "sysctrl vfs"-Angaben:
Code: 
vfs.devfs.rule_depth: 1
vfs.devfs.generation: 163
vfs.ufs.dirhash_docheck: 0
vfs.ufs.dirhash_mem: 96855
vfs.ufs.dirhash_maxmem: 2097152
vfs.ufs.dirhash_minsize: 2560
vfs.pfs.vncache.misses: 6
vfs.pfs.vncache.hits: 4
vfs.pfs.vncache.maxentries: 6
vfs.pfs.vncache.entries: 4
vfs.pfs.trace: 0
vfs.e2fs.dircheck: 0
vfs.flushwithdeps: 0
vfs.getnewbufrestarts: 0
vfs.getnewbufcalls: 1712306
vfs.hifreebuffers: 812
vfs.lofreebuffers: 406
vfs.numfreebuffers: 7201
vfs.dirtybufthresh: 1643
vfs.hidirtybuffers: 1826
vfs.lodirtybuffers: 913
vfs.numdirtybuffers: 8
vfs.recursiveflushes: 0
vfs.altbufferflushes: 0
vfs.dirtybufferflushes: 0
vfs.hirunningspace: 1048576
vfs.lorunningspace: 524288
vfs.bufdefragcnt: 0
vfs.buffreekvacnt: 0
vfs.bufreusecnt: 7180
vfs.hibufspace: 117702656
vfs.lobufspace: 117637120
vfs.maxmallocbufspace: 5885132
vfs.bufmallocspace: 2048
vfs.maxbufspace: 118358016
vfs.bufspace: 117637120
vfs.runningbufspace: 0
vfs.vmiodirenable: 1
vfs.cache.numfullpathfound: 127
vfs.cache.numfullpathfail4: 0
vfs.cache.numfullpathfail2: 0
vfs.cache.numfullpathfail1: 0
vfs.cache.numfullpathcalls: 127
vfs.cache.nchstats: 76967 5464 639 0 7814 0 78 580
vfs.cache.numneghits: 5464
vfs.cache.numnegzaps: 22
vfs.cache.numposhits: 76967
vfs.cache.numposzaps: 617
vfs.cache.nummisszap: 1161
vfs.cache.nummiss: 6653
vfs.cache.numchecks: 83193
vfs.cache.dotdothits: 297
vfs.cache.dothits: 406
vfs.cache.numcalls: 92484
vfs.cache.numcache: 2055
vfs.cache.numneg: 127
vfs.read_max: 8
vfs.write_behind: 1
vfs.lookup_shared: 0
vfs.usermount: 0
vfs.worklist_len: 2
vfs.timestamp_precision: 0
vfs.reassignbufcalls: 8379
vfs.freevnodes: 1271
vfs.wantfreevnodes: 25000
vfs.numvnodes: 2016
vfs.ffs.doreallocblks: 1
vfs.ffs.doasyncfree: 1
vfs.ffs.compute_summary_at_mount: 0
 
Hi Leute,
ich habe auch die Theorie gelesen, das möglicherweise das Filesystem ausserhalb der Plattengeometrie endet.
Das kann nicht sein, da in soeinem Fall nur Fehler beim schreiben auftreten würden und ich die Platten im Moment aber read-only gemountet habe... und der Reboot tritt trotdem auf.

Allerdings produzieren Schreibzugriffe fast nur Datenmüll. Leider konnte ich bis jetzt noch nicht einkreisen, in welcher Schicht das Problem liegt.
 
Hast du zufaellig /tmp als mfs gemountet?
In dieser Beziehung hatte ich bisher schon oefter Probleme, allerdings im Zusammenhang mit reichlichen Schreibzugriffen.
 
j_t schrieb:
Hast du zufaellig /tmp als mfs gemountet?
In dieser Beziehung hatte ich bisher schon oefter Probleme, allerdings im Zusammenhang mit reichlichen Schreibzugriffen.
Zum Vergrößern anklicken....

Nein, hab ich nicht:

Code: 
# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    140G     60G     69G    46%    /
devfs          1.0K    1.0K      0B   100%    /dev
procfs         4.0K    4.0K      0B   100%    /proc
linprocfs      4.0K    4.0K      0B   100%    /usr/compat/linux/proc
linsysfs       4.0K    4.0K      0B   100%    /usr/compat/linux/sys
devfs          1.0K    1.0K      0B   100%    /var/named/dev
devfs          1.0K    1.0K      0B   100%    /var/db/dhcpd/dev
/dev/ar0s1a    289G    255G     11G    96%    /home
 
Hier noch ein paar Infos zum forschen.
 

Anhänge

  • df.txt
    582 Bytes · Aufrufe: 276
  • dmesg.txt
    7,3 KB · Aufrufe: 393
  • pkg_info.txt
    10,8 KB · Aufrufe: 325
  • sysctl.txt
    45,7 KB · Aufrufe: 392
Dieser Fehler ist immer aufgetreten, wenn ich auf die Platte geschrieben habe.
 

Anhänge

  • pentium-m-raidfehler.jpg
    pentium-m-raidfehler.jpg
    798,9 KB · Aufrufe: 346
zur Info

Also, hier habe ich die Beschreibung einiger Fehler gefunden:

http://www.gsp.com/cgi-bin/man.cgi?section=8&topic=crash

Da steht, das man meinen ersten Fehler "panic: ffs_valloc: dup alloc" durch einen fsck meistens bereinigen kann.
Nur der tritt ja nicht mehr auf....

Und der aktuelle Fehler "panic: page fault", der bis jetzt durch 'cp', 'mv' und 'bzip2' zuverlässig reproduzierbar ist, steht da leider nicht drin. :grumble:

;'(
 
Hast du mal ACPI abgeschaltet?

Wie ist die genau Bezeichnung deines Onboard-Controllers bzw. des Mainboards?

Steckt der SiL3114 noch im Board oder ist er komplett entfernt?

mousaka
 
mousaka schrieb:
Hast du mal ACPI abgeschaltet?

Wie ist die genau Bezeichnung deines Onboard-Controllers bzw. des Mainboards?

Steckt der SiL3114 noch im Board oder ist er komplett entfernt?

mousaka
Zum Vergrößern anklicken....
ACPI hab ich an.
Die Controler heißen (glaube ich) SiS-180 und SiS-964

es ist dieses Board:
http://www.alternate.de/html/product/details.html?articleId=148209&showTechData=true

Den SiL3114 habe ich komplett entfernt.

Die Systemplatte stekt jetzt mit einem Adapter am 1. ATA
und die beiden Platten für das RAID (ar0) steken an den beiden SATA-Steckplätzen.
 
j_t schrieb:
kannst du testweise auf das tolle ar0 verzichten und eine der HDs direkt nutzen?
Zum Vergrößern anklicken....

Das habe ich so noch nicht ausprobiert, bin noch dabei den Rest meiner Daten zu sichern.

Fest steht nur, das die Maschine auch einen Reboot macht wenn ich auf das ar0-Device nicht zugreife, sondern nur eine 50GB-Datei von der Systemplatte auf eine USB-Platte schieben will.
 
mousaka schrieb:
Machs doch mal ab, ist glaube ich Option 2 im Boot-Menu.

Zum Sichern der Daten kannst du evtl. mittels atacontrol in einen langsameren Modus wechseln.

mousaka
Zum Vergrößern anklicken....

ACPI hab ich wegen der Stromsparfunktionen an, aber ich probiere es mal ohne.

Ich hab schon versucht, ihn runter zu schalten. Leider gibt es aber für SATA keinen langsameren Mode als SATA150 und das ist in diesem Fall auch der schnellste... :-(
 
So, ich habe den Server gerade ohne ACPI hochgefahren und das RAM-Timing runter gedreht:
DDR400 -> DDR333
T2.5 -> T3
T6 -> T9
T3 -> T4
T3 -> T4

Mal sehen ob er morgen wieder einen Reboot hingelegt hat.
 
Yoda schrieb:
So, ich habe den Server gerade ohne ACPI hochgefahren und das RAM-Timing runter gedreht:
DDR400 -> DDR333
T2.5 -> T3
T6 -> T9
T3 -> T4
T3 -> T4

Mal sehen ob er morgen wieder einen Reboot hingelegt hat.
Zum Vergrößern anklicken....

...noch läuft er (aber er hatte schon vorher mal 2,5 Tage durchgehalten), warten wir es ab.

Wenn es jetzt hin haut, dann denke ich war es der RAM, denn mit ACPI hatte ich noch nie Probleme.
In zwei Tagen melde ich mich wieder.
 
Info

Hi Leute,
das sieht tatsächlich so aus, als wenn der Speicher alleine Schuld hat.

Ich habe jetzt die ganzen 260 GB mit tar gezogen, ohne ein Problem. Da waren ACPI abgeschaltet und der RAM runtergetacktet.

Jetzt hab ich die Maschine mit runtergetacktetem RAM aber mit eingeschaltetem ACPI hochgefahren und einen "Streßtest" gestartet, mit dem ich vorher IMMER einen Absturz provozieren konnte. Die ersten 5 Minuten konnte ich heute Morgen noch kein Problem beobachten... ob er tatsächlich durchgehalten hat kann ich erst heute Abend sagen.

Danke und bis denne!
 
Finale

Hi Leute,
jetzt scheint alles wieder zu gehen.
Leider gab es immerwieder Fehler die fsck nicht wirklich reparieren konnte, also hab ich alles gesichert und das ganze RAID neu angelegt und formatiert....

Jetzt scheint alles wieder im Lot, fsck findet keine Fehler mehr.

...und alles nur wegen dem Billigspeicher...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben