Absender: Jens Friedrich
Datum: Fr, 02.12.2005 20:53:07
In-reply-to:
<216B9311-95E9-4E51-B882-7D139C0A9D95@xxxxxxxxxxx>
Hi Peter, Hast Du noch nicht einfach mal unsere Kernel ausprobiert? Das würde uns natürlich auch brennend interessieren, ob die bei Euch instabil sind, uns (mir) kam noch keine einzige Info diesbzgl. rein... Ich hab auf dem normalen, aber mit upgrade aktualisierten ctsrv kompiliert. Compiler war Standard - denke das war schon gcc 3.3.5 wie aktuell auch. Ich lasse aktuell mal den ipcop-1.4.9 in einer sarge-chroot (debootstrap sarge...) kompilieren, um dann mal ein bischen mit Deinen Hinweisen zu testen/patchen. 700MHz PIII mit 384MB ;-) auf meinem produktiven Server. IPCop lief bei mir bis jetzt stabil - reboot war nicht nötig (Hab aber nur 384kbit DSL :-(((, da ist wohl nix mit Stress-Download... Aber grosse files gehen...halt nur stabil mit 48kB... Wir haben also immer noch Unterschiede in allen Bereichen: - gcc ist unterschiedlich - ipcop version ist unterschiedlich - kompilier-umgebung ist unterschiedlich (zum. bei mir) Bitte teste doch mal unsere kernels...das Ergebnis ist schon interessant! Viele Grüsse Jens > -----Ursprüngliche Nachricht----- > Von: ctsrvdev-bounces@xxxxxxxxxxxxxxxxx > [mailto:ctsrvdev-bounces@xxxxxxxxxxxxxxxxx] Im Auftrag von > Peter Siering > Gesendet: Freitag, 2. Dezember 2005 19:36 > An: Entwicklung rund um den c't Server > Betreff: [ctsrvdev] ipcop uml und 2.6 host > > Hallo allerseits, > > ich komme leider nur kleckerweise vorwärts. Ich habe jetzt > mit den HInweisen aus http://www.ctserver.org/ftopic507.html > eine neuere Version unserers Build-Ansatzes für den Kernel > des IPCop zusammengebaut. Inbesondere auf den aktuelleren > UML-Patch umgestellt und den erwähnten Fix eingebaut. > > Zum Testen, ob das dafür sorgt, dass die IPCop-UML dann > stabil unter einem 2.6.12-ct-1-Kernel läuft, bin ich vorerst > bei der letzten IPCop- Fassung (1.4.6) geblieben. Die > IPCop-"Abstürze" unter Last, die mich zu der erneuten Warnung > vor 2.6 als Host veranlasst haben, waren damit perfekt zu > reproduzieren. > > Leider kann ich nach wie vor durch längere Downloads Aussetzer > provozieren: Zum bekannten Fehlerbild (IPCop-Instanz beendet > sich) gesellt sich als neue Form ein Stehenbleiben des > Downloads (der IPCop lebt weiter). > > Ich will noch einige Dinge ausprobieren, möchte aber auch auf > diesem Weg eine Suche nach möglichen Ursachen anstoßen - dazu > eine genauere Beschreibung des Testszenarios und der > beteiligten Systeme: > > - Server ist ein C3 mit 533 MHz, Kernel 2.6.12-ct-1 > > - IPCop 1.4.6 mit Kernel 2.4.29 > > - als Testclient dient Mac OS X 10.3, Download eines ISOs mit curl > > Der IPCop wird über das mit der Version 1.4.6 gelieferte > init-Skript gestartet, das heißt, er läuft in einer > chroot-Umgebung. Das Kernel- Binary ist dazu statisch gelinkt > (CONFIG_SKAS und CONFIG-TT gesetzt; nicht aber > CONFIG_STATIC_LINK - das ist kaputt, CONFIG_TT hat den > gleichen Effekt). Hier die vollständigen Optionen aus dem > .config, das in Build-Umgebung eingebaut ist: > > CONFIG_USERMODE=y > CONFIG_MODE_SKAS=y > CONFIG_MODE_TT=y > # CONFIG_UML_SMP is not set > # CONFIG_UML_WATCHDOG is not set > CONFIG_UML_SOUND=n > CONFIG_UML_NET=y > CONFIG_UML_NET_ETHERTAP=y > CONFIG_UML_NET_TUNTAP=y > CONFIG_UML_NET_SLIP=y > CONFIG_UML_NET_SLIRP=y > CONFIG_UML_NET_DAEMON=y > CONFIG_UML_NET_MCAST=y > # CONFIG_UML_NET_PCAP is not set > CONFIG_STATIC_LINK=n > CONFIG_HOSTFS=n > CONFIG_HUMFS=n > CONFIG_HPPFS=n > CONFIG_MCONSOLE=y > CONFIG_MAGIC_SYSRQ=n > CONFIG_HOST_2G_2G=n > CONFIG_UML_SMP=n > CONFIG_NEST_LEVEL=0 > CONFIG_KERNEL_HALF_GIGS=1 > CONFIG_PROC_MM=n > CONFIG_KERNEL_STACK_ORDER=2 > CONFIG_UML_REAL_TIME_CLOCK=y > CONFIG_SSL=y > CONFIG_FD_CHAN=y > CONFIG_NULL_CHAN=y > CONFIG_PORT_CHAN=y > CONFIG_PTY_CHAN=y > CONFIG_TTY_CHAN=y > CONFIG_XTERM_CHAN=y > CONFIG_SSL_CHAN="pty" > CONFIG_CON_CHAN=xterm > CONFIG_CON_ZERO_CHAN=fd:0,fd:1 > CONFIG_TTY_LOG=n > CONFIG_BLK_DEV_UBD=y > # CONFIG_BLK_DEV_UBD_SYNC is not set > CONFIG_COW=y > CONFIG_MMAPPER=n > CONFIG_PPP_MPPE=m > CONFIG_DEBUG_SLAB=n > CONFIG_DEBUGSYM=n > CONFIG_O1_OPTIM=n > > Mich würde interessieren: > > - ob ich der einzige bin, der einen so lahmen Server > einsetzt ;-) (Der Fehler ließ sich auch mit schnelleren > Systemen reproduzieren; ich habe vorerst nur das o.g. > Test-Set gequält) > > - ob/wie die für die funktionierenden UML-IPCops gesetzten > Kernel- Optionen (.config) abweichen > > - welche Compiler beim Übersetzen des Kernels zum Einsatz > kommen (bei mir ist es der für den IPCop selbst verwendete > 3.3.3 in der chroot- Umgebung des IPCop) > > - was für maximale uptimes mit der Kombination 2.6.12-ct-1 > und UML- IPCop erreicht worden sind? > > Danke+Gruß, > Peter > > > > _______________________________________________ > ctsrvdev Mailingliste > ctsrvdev@xxxxxxxxxxxxxxxxx > http://www.heise.de/bin/newsletter/listinfo/ctsrvdev >