sonnenblen.de - Das unabhängige Sun User Forum
Betriebssysteme => NetBSD => Thema gestartet von: Lordy am 26. September 2002, 00:13:46
-
Hey,
hier mal ein neuer Thread fuer das Thema NetBSD MP.
Also ich hab ein paar infos zum Thema zusammen getragen, die ich hier mal niederschreiben :) .
1.) Bei NetBSD 1.6 ist MP noch kein Fixxer bestandteil, und es muss deswegen der Kernel gepatched werden.
2.) Auf x86 Systemen laeuft MP schon zimlich stabil und ohne groessere Probleme. Wenn es wem interessiert wie man unter einen x86 System MP zum laufen bringt sollte er sich hier melden, da sollte ich eigendlich helfen koennen 8)
3,1.) Arch SPARC SuperSparc: Bei Systemen mit einen SuperSparc sollte es auch laufen, leider kann ich das nicht testen da ich kein sollchen System habe, und weiter helfen dabei kann ich auch nicht, weil ich wirklich nichts dazu gefunden hab ausser "it run!!" ... ::)
3,2.) Arch SPARC HyperSparc: Bei Systemen mit HyperSparc CPU's ist die Sache schon etwas heickler, da diese cpu's anscheinent eine andere Cache-Controll haben und diese noch nicht richtig laeuft. Es wurde zwar mal einige Monate lang darueber gesprochen, und etwas rum gehackt, aber ich habe keine Informationen zu einen endgueltigen Erbnis finden koennen.
4.) Arch. SPARC64: Hier ist die Sache recht einfach: Es laeuft nocht nicht :'(
Gruss,
chris
-
Hey,
heute wurde die Patch fuer x86 MP in NetBSD-current aufgenommen, also faeld in zukunft schon mal die Patch arbeit weg.
MP ist bei NetBSD auch auf den Alpha und VAX Port lauffaehig. Ach ja, der Mac Port ist nich zu vergessen, da ist MP aber noch sehr jung.
Gruss,
chris
-
ich wollte noch mal genauer auf die sparcys eingehen:
options MULTIPROCESSOR # include multiprocessor support
mainbus0 at root
cpu0 at mainbus0
cpu* at mainbus0 # declare additional CPUs
ist schon genug um mp betrieb aufzunehmen, ich habe das von
der GENERIC.MP in meine file übernommen...
mfg, stefan
-
@stefan: nicht mehr nötig? kein patchen?
Was ich mich noch frage, braucht man -current oder hast du das relase-1.6?
chris
-
Man merkt ich werde alt - und das schon in so jungen Jahren ;)
Ein blick nach /usr/src/sys/arch/sparc/conf beantwortet meine Fragen schon ..
Kein Patchen ist mehr nötig, und ja, es ist schon in relase-1.6 drinnen.
chris
-
sorry, konnte nich früher antworten :)
wie gesagt, ich hab mir die 2 zeilen einfach aus GENERIC.MP
geholt, dann compilierst das einfach rein und fertig (1.6 stable)
.. aber hast ja eh schon bemerkt :)
mfg,stefan
-
klingt fuer mich als ob sich meine ss20 bald von solaris trennen muesste. ;)
ich lasse mich ueberraschen und werden mal berichten wie meine ss20 verhaelt.
friday
-
moin,
1.6 aus dem netz gezogen, auf cd gebannt, installiert, konfiguriert, kernel kompiliert und gebootet. alles kein problem ...
aber wie sag ich netbsd, das ein proggi auf der 2. cpu laufen soll?
friday
-
Hey,
du sagst das NetBSD gar nicht. NetBSD ist selbst dafür zuständig die Prozesse auf die zur Verfühgung stehenden CPU's aufzuteilen (das macht der Scheduler).
Wenn du mehr Prozesse startest und dir dann die Sache mit 'top' anguckst solltest du eigendlich auch sehen auf welchen CPU's welcher Prozess läuft.
Gruss,
chris
-
genau da liegt mein problem,
es laufen alle auf der ersten, bisher sagt mir top immer auf CPU/0.
sind sie bei sun4m noch nicht soweit oder habe ich was vergessen?
friday
-
hast du einen kernel mit den von mir oben geposteten
options ?
mfg, stefan
-
Bei Linus-Distris ist immer ein SMP-Kernel fällig.
NetBSD habe ich noch nicht ausprobiert.
Aber ich denke, daß SMP im Kernel ausgewählt/enabled werden muß.
-
gut doch bei antwort #2 - das sind die optionen, die mit
in kernel reincompiliert werden müssen...
mfg, stefan
-
Hey,
also wie gesagt, wenn du die Sachen die Stefan gepostet hat in deinen kernel drin hast, sollte es funktionieren.
mach mal "dmesg | grep 'cpu'", das sollte dir anzeigen welche CPU's das System gefunden hat beim booten. Wenn nur eine, dann hast du nenn fehler gemacht beim Kernel bauen, wenn zwei, dann hast du dich vielleicht bei top verguckt - sonst feld mir jetzt kein fehler mehr ein.
chris
-
hab mich eigentlich nicht verguckt:
dmesg:
.
.
.
cpu0 at mainbus0: mid 8: TMS390Z50 v0 or TMS390Z55 @ 75 MHz, on-chip FPU
cpu0: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled
cpu1 at mainbus0: mid 10: TMS390Z50 v0 or TMS390Z55 @ 75 MHz, on-chip FPU
cpu1: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled
.
.
.
cpu0: booting secondary processors: cpu1
soweit so gut ... alle prozesse die ich anstarte laufen dann in top mit xxx/0 und die min. cpu idle betraegt 50%.
??? ??? ???
ok, hab mir gerade den aktuellen syssrc per cvs gezogen, mal sehen was passiert wenn er fertig compiliert ist...
friday
-
noe, mit current das selbe spiel ....
friday
-
Hey,
kannst mir vielleicht man nenn account auf den rechner geben, weil so ne ferndiagnose ist schwer und mir fehlt jetzt eigendlich nichts mehr ein.
Wenn du wegen den Accout zustimmst schick mir die Daten an: "atlan at utanet dot at"
chris
-
Hey,
d.h. fehlt ==> nicht feld.
Auf dem feld wachsen Rüben.
-
hai hai, der kernel hat sich richtig schön compiliert, dann meinte
er beim booten 'can't ping cpu1' - ideen ? als ich einen fürn
freund gebaut hab ging das super
mfg, stefan
-
Was sagt denn ein module-info im OK-Prompt ?
Mir scheint es , als würde die zweite CPU nicht erkannt werden.
-
MBus: 40mhz
Sbus: 20mhz
CPU#0: 40 mhz Supersparc
CPU#2: 40 mhz Supersparc
das 2te ist auf #2 weil in ersten steckplatz ja auch dual
module rein können die #0 und #1 beanspruchen denke ich.
der kernel erkennt die soweit auch
cpu0 at mainbus0: TMS390Z50 v1 @ 40 MHz, on-chip FPU
cpu0: physical 20K instruction (64 b/l), 16K data (32 b/l): cache enabled
cpu at mainbus0 not configured
mfg, stefan
p.s.: ich versuche mal die 2te cpu impliziet anzugeben:
options MULTIPROCESSOR
mainbus0 at root
cpu0 at mainbus0
cpu2 at mainbus0 # da
-
gemacht:
cpu2: did not spin up
...
raise_ipi_wait_and_unloc(cpu0): could'nt ping cpu1
<- endlosschleife mit der meldung von oben ->
mfg, stefan
-
Tausch die CPU´s mal gegeneinander aus.
Dann weist du wenigstens ob # 2 lebt.
-
#2 lebt definitiv, habs getestet, sieht so aus als sind
die sm40 nicht dual fähig :-/
wären da nur 2x sm71 drin ;)
mfg, stefan
-
Welche OBP -Version hast du denn ?
Du benötigst dazu mindestens 2.22, besser 2.25.
-
ja die ich dir abgekauft hab, 2.25R :) nur sind diese module
immer verdammt teuer, genau wie hypersparcs :(
aber im prinzip sollte es ja egal sein ob die in ner ss10 oder
ss20 sitzen ?
mfg, stefan
-
hab folgendes gefunden (openbsd mailing list)
Sun shipped 7 different SM4x Mbus modules. Breakdown as follows:
501-2219 - SM40, SuperSPARC 2.x, does not support MP.
501-2358 - SM40, SuperSPARC 3.x, MP with OBP 2.12 but not recommended.
501-2570 - SM40, SuperSPARC 3.x, MP with OBP 2.12.
...
so, die ersten drei sind interessant - jetzt muss ich nur wissen welche
versionsnummern ich hab, kann man das per software auslesen ?
mfg, stefan
edit: ok sorry für den spam :)
cpu0 at mainbus0: TMS390Z50 v1 @ 40 MHz, on-chip FPU
-
... mit etwas Glück gibt dir ein "module-info" im OBP wenigstens die Cache Version aus ... das sollte dir ja dann schonmal weiterhelfen.
Gruß
Walt
-
.. gebe nacheinander im OK Prompt folgendes ein :
.psr
.mcr
2 switch-cpu
.psr
.mcr
...und gebe hier bitte die Ausgabe wieder.
Die sieht ungefähr so aus:
(http://www.hyperstation.de/mcrpsr.jpg)
-
ok .psr
CWP: 6 ET: 1 PS: 1 S: 1 PIL: d EF: 1 EC: 0 ICC: nzvc VER: 1 IMPL: 4
ok .mcr
ME:1 NF:0 PSO:0 DE:1 IE:1 SB:1 MB:1 PE:0 BM:0 SE:1 AC:0 TC:0 PF:0 VER:0 IMPL:0
ok 2 switch-cpu
< hier raucht er ab,weder stop+a noch strg+off geht net, muss man gewaltsam abschalten >
hab dann die 2te cpu einzeln eingebaut und der output ist folgender:
ok .psr
< alle argumente auf 0 >
ok .mcr
ME:1 NF:0 PSO:0 DE:1 IE:1 SB:1 MB:1 PE:0 BM:0 SE:1 AC:0 TC:0 PF:0 VER:0 IMPL:0
mir ist auch noch aufgefallen, das der beim memory init nur 16mb checkt,
obwohl 32mb drin sind und im OBP wie von netbsd erkannt werden....
ich bin ja sowas von überfordert ;D
@sunroot#: der sagt mir da lieder nix , nur sowas wie
cpu0: 40mhz SuperSparc
cpu2: <- dito ->
-
Sodele deine erste CPU ist eine der ersten, da sie die Revision 2..x hat.
Für deine zweite CPU gilt das gleiche, mit dem Zusatz, daß diese
CPU warscheinlich defekt ist.
Wenn diese schon beim Versuch der Register auszulesen abstürzt.
Nachvollziehen, kannst du das hier:
http://sunsolve.sun.com/handbook_pub/Devices/CPU_Module/SuperSPARC_SPARC_Proc_Rev.html
-
ich glaube net , dass die kaputt ist. mein router läuft gerade mit
dem modul, da gibt es kein problem beim booten ...
abrauchen tut der nur, wenn ich das switch auf die cpu2 ausführen
will.
-
Wenn er dann allein in der Maschine sitzt auch nicht ?
-
er sitzt im moment allein drin, kein problem, wenn er mit dem anderen
drin sitzt gibts auch keins, außer beide sind im kernel aktiviert, dann
kommt der ping error wieder...
mfg, stefan
-
Dann wollen die zusammen eben nicht ! ;D
-
genau das ist meine befürchtung :-/ , vertickst du zufällig sm71 oder
sm81 module ?
-
Nur ab und zu mal ROSS HyperSPARC CPU`s....
-
das ist das problem, ich glaube die dinger laufen dual nicht
einwandfrei mit netbsd, sonst hätte ich die eine von dir genommen
mfg, stefan
-
Was spricht man denn in einschlägigen Foren dazu ?
-
ich dachte ich bin hier in einem ;D
-
In diesen fall ist es wohl das beste wenn man 1.) die Mailliste durchsucht und wenn man da dann darüber nichts findet 2.) Eine E-Mail mit der genauen fehler beschreiben schick.
> ich dachte ich bin hier in einem
Wir sind auch nur Menschen ;)
chris
-
Crosspost wegen http://sonnenblen.de/cgi-bin/YaBB/YaBB.cgi?board=Neuvorstellungen&action=display&num=1039792470
--- snip ---
SMP support for NetBSD/sparc is virtually nonexistent. it spins up
other cpus (or at least the second one for me) but that's all. there is
some #if 0-ed code which i was said is far from complete (or even
working) anyway.
--- snip ---
Siehe auch: http://mail-index.netbsd.org/port-sparc/2002/12/10/0000.html
d.h. NetBSD erkennt zwar die zweite CPU, kann aber effektiv absolut garnichts mit ihr anfangen ...
Ich hab leider auch nciht die Zeit, mich mit besagtem #if 0-ed code zu beschäftigen :(
-
Mal ein aktueller Stand:
hi folks.
due largely to the efforts of paul kranenburg, SMP support on sparc has
finally arrived. this has only been tested successfully so far on an
ss20/712, an sun4/690 and an ss10/712 (i think), with a failure on a
4/670. hypersparc support is almost certainly busted...
there are still some bugs and there are lots of implementation details
that could be reworked, but it seems pretty stable and performant so far.
see my boot log below.
.mrg.
...
SPARCstation 20 MP (2 X SuperSPARC-II), No Keyboard
ROM Rev. 2.25, 160 MB memory installed, Serial #3445063.
Ethernet address 8:0:20:20:23:48, Host ID: 72349147.
...
NetBSD 1.6K (_russian_) #234: Sun Jan 5 04:46:55 EST 2003
...
cpu0 at mainbus0: mid 8: TMS390Z50 v0 or TMS390Z55 @ 75 MHz, on-chip FPU
cpu0: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled
cpu1 at mainbus0: mid 10: TMS390Z50 v0 or TMS390Z55 @ 75 MHz, on-chip FPU
cpu1: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled
...
NetBSD 1.6K (_russian_) #234: Sun Jan 5 04:46:55 EST 2003
# top -b
load averages: 1.06, 0.28, 0.10 22:43:37
20 processes: 19 sleeping, 1 on processor
Memory: 15M Act, 164K Wired, 2880K Exec, 3576K File, 123M Free
Swap: 202M Total, 202M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
192 root 2 0 396K 1412K select/1 0:06 57.40% 22.61% sshd
4 root -18 0 0K 25M reaper/1 0:01 1.85% 1.61% [reaper]
213 root 10 0 308K 920K wait/0 0:00 3.26% 1.07% sh
5 root 18 0 0K 25M syncer/1 ??? 0.00% 0.00% [ioflush]
3 root -18 0 0K 25M pgdaem/1 ??? 0.00% 0.00% [pagedaemon]
215 root 38 0 148K 716K CPU/1 0:01 0.00% 0.00% top
120 root 10 0 0K 25M nfsidl/1 0:00 0.00% 0.00% [nfsio]
119 root 10 0 0K 25M nfsidl/0 0:00 0.00% 0.00% [nfsio]
118 root 10 0 0K 25M nfsidl/1 0:00 0.00% 0.00% [nfsio]
117 root 10 0 0K 25M nfsidl/0 0:00 0.00% 0.00% [nfsio]
211 root 10 0 248K 656K nanosl/0 0:00 0.00% 0.00% cron
1 root 10 0 76K 656K wait/0 0:00 0.00% 0.00% init
115 root 10 0 488K 520K mfsidl/0 0:00 0.00% 0.00% mount_mfs
105 root 2 0 216K 824K select/1 0:00 0.00% 0.00% rpcbind
206 root 2 0 128K 800K select/0 0:00 0.00% 0.00% inetd
90 root 2 0 216K 724K select/0 0:00 0.00% 0.00% syslogd
166 root 2 0 184K 624K select/1 0:00 0.00% 0.00% lpd
2 root -6 0 0K 25M sccomp/0 0:00 0.00% 0.00% [scsibus0]
-
.....hypersparc support is almost certainly busted......
-
Nachdem ich die Mail von Matthew Green gerade gelesen habe, musste ich erstmal einen Freudenschrei in die Welt bruellen ...
rm -fr /home/exports/gaia/solaris
mkdir /home/exports/gaia/netbsd-current
:)
-
.....hypersparc support is almost certainly busted......
Hier ein Ausschnitt aus einer mail die letzte Nacht über die NetBSD Liste ging:
PARCstation 20 MP (2 X RT625), No Keyboard
ROM Rev. 2.25R hyperSPARC, 160 MB memory installed, Serial #7493664.
Ethernet address 8:0:20:72:58:20, Host ID: 72725820.
Initializing Memory [BREAK]
Type help for more information
<#0> ok boot netbsd.mp
Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0 File and args: netbsd.mp
>> NetBSD/sparc Secondary Boot, Revision 1.12
>> (autobuild@tgm.daemon.org, Mon Sep 9 08:12:32 UTC 2002)
Booting netbsd.mp
2086740+87300+189956 [131920+100148]=0x289ed0
OBP version 3, revision 2.25 (plugin rev 2)
[ using 232560 bytes of netbsd ELF symbol table ]
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 1.6L (SHADOWFAX.MP) #94: Wed Jan 15 14:12:40 MET 2003
pk@mang:/usr/src/sys/arch/sparc/compile/SHADOWFAX.MP
total memory = 159 MB
avail memory = 144 MB
using 896 buffers containing 8264 KB of memory
bootpath: /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@3,0
mainbus0 (root): SUNW,SPARCstation-20
cpu0 at mainbus0: mid 8: RT620/625 @ 100 MHz, on-chip FPU
cpu0: 256K byte write-back, 64 bytes/line, sw flush: cache enabled
cpu1 at mainbus0: mid 9: RT620/625 @ 100 MHz, on-chip FPU
cpu1: 256K byte write-back, 64 bytes/line, sw flush: cache enabled
obio0 at mainbus0
:) :) :)
-
Dies ist ja dann offensichtlich der Beweis,
das die Hypersparc-Unterstützung doch funktioniert.