Re: unerklärliche Abstuerze

On Thu, Jun 02, 2005 at 10:08:33AM +0200, Dura Zell wrote:
> Heiko Grill schrieb:
>
> >Am Donnerstag, 2. Juni 2005 08:13 schrieb Dura Zell:
> >
> >
> >>Guten Morgen
> >>
> >>
> >Moin, moin,
> >
> >
> >
> >>Ich hab hier einen Rechner mit FBSD 5.4 eingerichtet. Dieser haengt sich
> >>in unregelmaessigen Abstaenden einfach auf.
> >>Er laesst sich dann weder ueber SSH ansprechen, noch reagiert er auf
> >>Keyboardeingaben. Das einzige was dann hilft ist der Resetknopf. Leider
> >>ist auch in den Logfiles nichts zu finden. Hat jemand aehnliche
> >>Erfahrungen oder kann mir sagen was ich tun kann um dem Problem auf die
> >>Spur zu kommen?
> >>
> >>Ich vermute einen Defekt bei den schon etwas älteren SCSI Festplatten.
> >>Da bin ich mir allerdings nicht wirklich sicher. Ich kann die auch nicht
> >>austauschen da ich keine Ersatzgeraete habe. Kann man die, aehnlich den
> >>S.M.A.R.T. Werten bei IDE Platten diagnostizieren? Gibt es andere
> >>Diagnosetools die ich laufen lassen sollte? Memtest86 läuft sauber durch.
> >>Werde vermutlich neu installieren muessen, da die diversen Abstuerze das
> >>Dateisystem schon recht gruendlich durcheinander gebracht haben
> >>duerften. Bevor ich das tue wuerde ich aber gern den Fehler beheben.

SCSI Platten kennen ebenfalls S.M.A.R.T, aber ich glaube nicht an einen
einfachen Plattenfehler - so einer swird vom Kernel gelogged.

> >man camcontrol(8) könnte Dir helfen. Man kann SCSI-Platten in einen Modus
> >schalten, in dem Sie Defekte protokollieren und ausblenden können. Habs
> >leider gerade nicht zur Hand, aber Bernd Walter hat mir mal gesagt, daß
> >das nicht unbedingt default ist. Er wird sich sicher melden ;-)

Ja, über modepage Einstellungen, aber das gibt erst mal Fehler vom
CAM System.

> >>Bei meiner Fehlersuche bin ich auf die Meldungen
> >>
> >>"Jun 2 06:58:37 jailhouse kernel: arp_rtrequest: bad gateway
> >>192.168.9.2 (!AF_LINK)"
> >>und
> >>"Jun 2 06:55:00 jailhouse kernel: arp: 192.168.12.2 is on rl2 but got
> >>reply from 00:0d:88:38:d1:71 on rl1"
> >>
> >>
> >Darf ich raten, das Du drei Netzwerkkarten hast und als IP-Adressen
> >192.168.12.1, 192.168.12.2 und 192.168.12.3 benutzt? Das geht nicht.
> >Sollte aber nicht zu solchen Ausetzern führen.
> >
> >
> Nicht ganz. Ich hab 192.168.9.1, 192.168.12.21 und 192.168.11.21 (Und
> jeweils auf den Karten einige aliase fuer meine jails, alle jedoch im
> gleichen Subnetz)
> Das duerfte allerdings tatsaechlich nicht der Grund sein, ich hab
> mittlerweile herausgefunden wo das herkommt. Der Rechner haengt uber
> zwei Switches an einem anderen Rechner der selbst auch mit zwei Karten
> verbunden ist: 192.168.12.1 und 192.168.11.1. Dabei 192.168.0/24 und
> 192.168.11.0/24 jeweils an einem Switch. Ich vermute das er auf der
> 192.168.12.0/24 eine arp Anfrage sendet und unter Umstaenden auf der
> 192.168.11.0/24 eine Antwort bekommt was ihm nicht gefaellt. Was die
> andere Fehlermeldung mir sagen will hab ich allerdings noch nicht
> verstanden...

Das ist keine Fehlermeldung, es ist eine Warnung dafür, dass die Netze
nicht so sauber getrennt sind, wie es bei der Konfiguration hätte sein
sollten.

> >>Folgende Daten hat der Rechner:
> >>
> >>Hardware
> >>--------
> >>
> >>CPU: 2xPentium III (Katmai) @ 500MHz
> >>Board: Asus P2B-DS
> >>RAM: 512MB SD
> >>Controller: Onboard AIC7890*
> >> Onboard IDE
> >>Festplatten: SEAGATE ST318418N (SCSI 19GB) als /, /usr und /jail
> >>gemounted
> >> IBM DCAS-34330 S65A (SCSI 4GB) als /var gemounted
> >> IBM DCAS-32160W S65A (SCSI 2GB) als /tmp und Swap gemounted
> >> IBM-DTTA-351010/T56OA73A (IDE 9GB) als /usr/home gemounted

Alles in allem eigendlich recht genügsamme und stabile Platten.
B
> da0 at ahc0 bus 0 target 0 lun 0
> da0: <SEAGATE ST318418N 0003> Fixed Direct Access SCSI-3 device
> da0: 20.000MB/s transfers (20.000MHz, offset 63), Tagged Queueing Enabled
> da0: 19001MB (38914049 512 byte sectors: 255H 63S/T 2422C)

Mmm - keine Ahnung mit der genauen Platte, aber Firmware Version 0003
stimmt mich nachdenklich, da andere Seagteplatten aus ähnlichen
Familien bis oder unter 0003 Bugs mit dem Schreibcache hatten.
Man sollte den im Zweifelsfall abschalten - dafür gibt ja bei echten
Platten tagged-command-queuing.
camcontrol modepage -n da -u 0 -P 3 -m 8 -e
WCE feld auf 0 setzen, falls das noch nicht der Fall ist.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message