Re: Immer wieder: kernelpanic von rsh

On Mon, Apr 21, 2003 at 01:39:48PM +0200, Bernd Walter wrote:
! > In letzter Zeit macht eine von meinen 4.7 Maschinen immer oefter
! > eine kernelpanic. Und zwar immer bei derselben Anwendung, naemlich
! > wenn ich mit rsh die filesystem-dumps vom System herunter schiebe,
! > nachdem schon eine gute Weile Daten geflossen sind.
! > Stacktrace sagt jedesmal, der Crash ist in m_copym() via tcp_output,
! > tcp_usr_send, sosend, soo_write, dofilewrite, write, syscall2.
! >
! > Solange kein Backup laeuft, ist das System voellig stabil. Es
! > arbeitet als Gateway fuer die Internet-Anbindung, es ist also
! > kaum denkbar, dass die Probleme aus genuinem Netzwerktraffic
! > herruehren.
!
! Routing ist was anderes als selber Daten zu verschicken.

Ack.

! Außerdem passiert es in dem Fall gleichzeitig mit Plattenzugriffen,
! die beim routen als solche niemals vorkommen.

Moooeeeglich.

! > Die weitere Analyse entpuppt sich leider als Huerdenlauf. Erste
! > boese Ueberraschung: Ein Pagingspace aus 2 mal 80% des RAM ist
! > zwar gem. "best practices" am sinnvollsten, taugt aber nicht zum
! > Dumpen - also erstmal die Filesysteme umgestrickt.
!
! Klau der Kiste zeitweilig einfach etwas RAM.

Jetzt hab ich schon umgebaut.

! Es gibt dafür extra die Loadervariable hw.physmem, wobei ich nicht
! sicher sagen kann, daß die 4.7 das schon hatte.

Aaahh! Ds ist schoene Sache, auch fuer Performance-Tests. Wusste
noch nicht, dass wir das auch haben.

! Es ist natürlich nciht garantiert, daß die RAM Menge nicht auch Einfluß
! auf das auftreten des Fehlers hat.

Wahrscheinlich. Ich meine mich zu entsinnen, was ich geaendert
hab, als es losging:
Mein Backup arbeitet mit chunks: ein chunk wird von der Quelle
gelesen und auf dem Tape-Server in eine temp-Datei geschrieben,
dann wird eine Checksum ermittelt und das chunk als Datei aufs
Band gebracht. Dann wird der naechste Chunk gelesen. Und irgend-
wann hab ich die chunksize von 50 MB auf 5 MB geaendert.
Es scheint so zu sein, dass das System diesen "Ruettelbetrieb"
(voller durchsatz/pause/voller durchsatz) nicht mag, bzw.
dabei eine Schwachstelle offenbar wird.

! > Dann weiter:
! > - INVARIANTS sollte genauere Fehlermeldungen aus m_copym() liefern,
! > tatsaechlich sorgt es aber nur dafuer, dass der Kernel bei jeder
! > Gelegenheit panict, und noch nichteinmal mehr komplett booten
! > mag. (irgendwas mit ng_ether_attach: already present)
!
! INVARIANTS verlangt, daß alle eingesetzten Module ebenfalls damit
! kompiliert sind.

Ja, das erklaert es. Ich hab gleichzeitig auch -g eingeschaltet,
daraufhin waren die Modules so exorbitant gross geworden, dass ich
die alten weiter nehmen musste.

! > - Wenn ich INVARIANTS nur in kern/uipc_mbuf.c einschalte, dann
! > passiert die panic wieder nur beim Backup, davor erscheint eine
! > Meldung "panic: freeing free mbuf", der stacktrace sieht aber
! > jetzt voellig anders aus als zuvor (und viel laenger), und das
! > System kann dann keinen cache mehr synchronisieren und keinen
! > dump schreiben.
!
! Das geht auch nicht.
! Entweder überall INVARIANTS oder nirgendwo.

Da stand in der Kernelconfig was anderes - das sollte man dann
vielleicht mal aendern:
# called. The intent is that you can set 'INVARIANTS' for single
# source files (by changing the source file or specifying it on the
# command line) if you have 'INVARIANT_SUPPORT' enabled.

Hab Dank und Gruss
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 22 Apr 2003 - 00:57:49 CEST