Oliver Fromme schrieb:
>Dura Zell <dura-zell(at)freenet.de> wrote:
> > Ich hatte gelesen das der ULE Scheduler fuer SMP Maschinen besser
> > geeignet sei.
>
>Ja, das ist zumindest das Design-Ziel. In der Praxis muß
>man aber dem BSD-Scheduler zugute halten, daß er zehnmal
>älter ist, von hundertmal mehr Programmierern unter die
>Lupe genommen wurde und tausendfach mehr in der Praxis ge-
>testet wurde.
>
>ULE steckt halt -- vergleichsweise -- noch in den Kinder-
>schuhen, und da sind gewisse Kinderkrankheiten nicht un-
>gewöhnlich. Das war bei anderen substantiellen Neuerungen
>(z.B. Soft-updates) nicht anders.
>
>
Meinte ich auch nicht böse oder abwertend. Ich wusst nur nicht das er so
experimentell ist. Ich bin sowohl was BSD angeht als auch was SMP
betrifft ein Neuling.
> > Ich baue gerade einen Kernel mit dem BSD Scheduler
> > und werde das dann testen und ggf. berichten. Da die Abstuerze eher
> > sporadisch auftreten kann das aber unter Umstaenden etwas dauern.
>
>Wenn es tatsächlich der Scheduler war, dann läßt sich das
>Problem vielleicht schneller provozieren, wenn man ihn et-
>was mehr fordert. Bei einem »make -j10 buildworld« dürfte
>der Scheduler beispielsweise gut zu tun bekommen.
>
>
Werde ich testen wenn ich wieder zurueck bin. Muss gleich zu einem
Termin und moechte das nicht machen lassen wahrend ich nicht da bin.
> > Das Netzteil wuerde ich gerne ausschliessen. Es ist das
> > einzige an dem Rechner was neu ist und sollte mit 350
> > Watt auch ausreichen.
>
>Das denke ich eigentlich auch. Allerdings ist nicht allein
>die nackte Wattzahl entscheidend -- ich hatte schon Netz-
>teile, die durchaus »viel Watte« drin hatten, aber bei
>kurzfristigen Leistungsspitzen (z.B. wenn ein Laufwerk an-
>lief oder der Prozessor aus dem Idle-mode plötzlich auf
>Vollast gebracht wurde) brach dann eine der Spannungsver-
>sorgungen geringfügig ein. Für heutige empfindliche Hard-
>ware ist schon ein geringer Spannungsabfall ausreichend,
>um alle möglichen Fehlersymptome zu erzeugen, von gekippten
>Bits (was bestenfalls zu Coredumps führt und schlimmsten-
>falls unbemerkt bleibt) bis hin zum kompletten Absturz oder
>Einfrieren der Kiste, oder spontanem Reboot.
>
>
Mag sein, ich werde hier im Ansatz versuchen ein Monitoringtool laufen
zu lassen. Ist fuer später wenn er dauerhaft laufen soll ohnehin sinnvoll.
> > Den Speicher kann ich leider nicht tauschen da ich keinen Ersatz hier
> > herumliegen habe. Es sind zwei 256er Riegel verbaut. Das Board kann aber
> > laut Asus Manual auch mit dem normalen Speicher umgehen, eventuell werde
> > ich das testen sofern ich diesen auftreiben kann. Vielleicht hilft da
> > auch einfach mal das Ausbauen und wieder Einbauen des Speichers falls
> > sich ein Staubkorn oder sowas auf den Kontaktleisten festgesetzt hat.
>
>Ja, das hat schon in anderen Fällen geholfen. Manchmal
>bilden sich auch durch thermische Spannungen Kontaktpro-
>bleme. Du kannst den Riegel auch mal testweise in einen
>anderen Slot stecken; manchmal unterscheiden sich die
>Timings der Slots minimal (durch Laufzeitunterschiede der
>verschieden langen Leiterbahnen sowie damit einhergehender
>kapazitiver Wirkungen), was bei winzigen Schwächen des
>RAMs schon den entscheidenden Unterschied machen kann.
>
>
Werde ich tun wenn der Fehler mit dem 4BSD Scheduler weiter besteht.
> > Ein Satz noch zum Schluss bezueglich der Fehlermeldung
> > "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":
> > Der Rechner ist uber Switches mit zwei Karten an einen anderen Rechner
> > angeschlossen der ebenfalls mit zwei Karten an den Siwtches haengt.
>
>Die Fehlermeldung deutet auf einen Fehler im Routing oder
>in der Verkabelung hin (bzw. generell im Netzdesign).
>
>Kannst Du bitte mal die IP-Adresse inkl. Netzmasken(!)
>aller beteiligten Interfaces nennen? Und die hängen alle
>am selben Switch, ja? Denke daran, daß die Routing-Table
>immer eindeutig sein sollte, d.h. keine Überlappungen (es
>sei denn, man weiß, was man tut).
>
>
Listing kommt unten. Ich hab für jedes Subnetz ein eigenes Switch. Nicht
erschrecken wegen der vielen IP Adressen, ich experimentiere gerade mit
dem jailsystem und hab mehrere Aliase fuer die jails mit denen ich
"herumbastele".
> > BSD Rechner soll spaeter den anderen Rechner ersetzen. Eine arp
> > Anfrage/Antwort kann also von zwei Karten kommen was zu der Meldung
> > fuehrt.
>
>Wenn alles korrekt konfiguriert ist, kann eine ARP-Antwort
>eigentlich nur von einem eindeutig bestimmten Interface
>kommen.
>
>
Ist es afaik auch, aber wie gesagt, zwei Rechner koennen sich mit je
zwei Netzkarten ueber verschiedene Subnetze erreichen:
|----- -Switch---|
Rechner1| |Rechner2
|------Switch---|
(man verzeihe mir meine schelchte ASCII Art ;)
Ich vermute das es sowas ist und verschwindet sobald der alte Rechner
(Rechne1) vom Netz ist.
>Gruß
> Olli
>
>
>
Mit freundlichen Gruessen,
Sven Mertens
IP Adressen, Ausgabe nach ifconfig des BSD Rechners:
root(at)jailhouse# ifconfig
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=8<VLAN_MTU>
inet 192.168.9.220 netmask 0xffffff00 broadcast 192.168.9.255
inet 192.168.9.200 netmask 0xffffffff broadcast 192.168.9.200
inet 192.168.9.1 netmask 0xffffffff broadcast 192.168.9.1
inet 192.168.9.2 netmask 0xffffffff broadcast 192.168.9.2
inet 192.168.9.3 netmask 0xffffffff broadcast 192.168.9.3
inet 192.168.9.4 netmask 0xffffffff broadcast 192.168.9.4
inet 192.168.9.5 netmask 0xffffffff broadcast 192.168.9.5
inet 192.168.9.6 netmask 0xffffffff broadcast 192.168.9.6
inet 192.168.9.7 netmask 0xffffffff broadcast 192.168.9.7
inet 192.168.9.8 netmask 0xffffffff broadcast 192.168.9.8
inet 192.168.9.9 netmask 0xffffffff broadcast 192.168.9.9
inet 192.168.9.10 netmask 0xffffffff broadcast 192.168.9.10
inet 192.168.9.12 netmask 0xffffffff broadcast 192.168.9.12
inet 192.168.9.201 netmask 0xffffffff broadcast 192.168.9.201
inet 192.168.9.202 netmask 0xffffffff broadcast 192.168.9.202
ether 00:08:a1:67:93:34
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=8<VLAN_MTU>
inet 192.168.11.21 netmask 0xffffff00 broadcast 192.168.11.255
inet 192.168.11.22 netmask 0xffffffff broadcast 192.168.11.22
inet 192.168.11.23 netmask 0xffffffff broadcast 192.168.11.23
ether 00:08:a1:66:28:26
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
rl2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=8<VLAN_MTU>
inet 192.168.12.21 netmask 0xffffff00 broadcast 192.168.12.255
inet 192.168.12.22 netmask 0xffffffff broadcast 192.168.12.22
inet 192.168.12.23 netmask 0xffffffff broadcast 192.168.12.23
ether 00:08:a1:66:28:05
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
--------
ifconfig des anderen Rechners (z.Zt Gateway ins Internet, oeffentliche
IP entfernt)
eth0 Link encap:Ethernet HWaddr 00:0D:88:38:D1:71
inet addr:192.168.11.1 Bcast:192.168.11.255 Mask:255.255.255.0
inet6 addr: fe80::20d:88ff:fe38:d171/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2762308 errors:0 dropped:0 overruns:0 frame:0
TX packets:5055070 errors:0 dropped:0 overruns:3 carrier:0
collisions:0 txqueuelen:100
RX bytes:208202348 (198.5 Mb) TX bytes:3081003037 (2938.2 Mb)
Interrupt:11 Base address:0xa000
eth1 Link encap:Ethernet HWaddr 00:0D:88:38:FE:3E
inet addr:192.168.178.221 Bcast:192.168.178.255
Mask:255.255.255.0
inet6 addr: fe80::20d:88ff:fe38:fe3e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1901266 errors:0 dropped:0 overruns:0 frame:0
TX packets:1719667 errors:0 dropped:0 overruns:2 carrier:0
collisions:0 txqueuelen:100
RX bytes:1520655090 (1450.2 Mb) TX bytes:833471253 (794.8 Mb)
Interrupt:5 Base address:0xc000
eth2 Link encap:Ethernet HWaddr 00:50:BF:49:E3:D2
inet addr:192.168.12.1 Bcast:192.168.12.255 Mask:255.255.255.0
inet6 addr: fe80::250:bfff:fe49:e3d2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6698423 errors:0 dropped:0 overruns:0 frame:0
TX packets:4622308 errors:0 dropped:0 overruns:3 carrier:0
collisions:0 txqueuelen:100
RX bytes:3883751475 (3703.8 Mb) TX bytes:1687632421 (1609.4 Mb)
Interrupt:9 Base address:0xe000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:72482 errors:0 dropped:0 overruns:0 frame:0
TX packets:72482 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11272531 (10.7 Mb) TX bytes:11272531 (10.7 Mb)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 02 Jun 2005 - 11:30:35 CEST