Je tente d'installer NetBSD sur une SparcSTATION 20 munie de 448 Mo
de mémoire, d'une VSIMM 4 Mo (CG14), de deux disques SCA 73 Go et de
deux cartes réseau happy meal an plus de ce qui se trouve déjà sur
la carte mère. Les processeurs sont deux dual ROSS à 200 MHz et OPB
est une version 2.25W (d'origine ROSS).
L'installation se passe bien (NetBSD 3.1). Sauf que... dès que j'ai
le malheur d'appuyer sur ctrl+D, je me prends un retour à la console
avec un truc du style NMI trap et un message d'insulte de l'OPB (pas
de panic). Problème : cette machine fonctionnait bien sous Linux
(UP) en 2.6. Je l'ai testée sous Solaris 9 avec SUNvts sans voir de
défaut. Question : est-ce un problème connu ? Cela me semble
d'autant plus bizarre que ce problème n'apparaît qu'avec un
ctrl+D et que l'erreur prétendument mémoire apparaît à n'importe
quelle adresse (avec un sydrome nul et sans la position de la
barrette défectueuse normalement indiquée par l'OPB...).
Une idée ?
Cordialement
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Oui, il n'y a plus de plantage avec un CTRL+D, mais des trucs bizarres du style "async register" mais à ce moment, l'affichage est corrompu. Pour l'instant, je tourne avec un 3.1 UP et je suis en
Bizarre...
train de recompiler un current (je suis au moins sûr que le current MP n'a pas le problème du CTRL+D, mais la console est cassée dans le GENERIC).
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de schadenfreude pour aujourd'hui.
Recompiler un NetBSD sur un SS20 avec un seul RT626 est une gageure :-(
En étant à peine vache, je te ferai remarquer que la compilation de NetBSD est la seule chose qui fonctionne. Faire tourner le résultat, voilà la gageure.
Oui, il n'y a plus de plantage avec un CTRL+D, mais des trucs
bizarres du style "async register" mais à ce moment, l'affichage est
corrompu. Pour l'instant, je tourne avec un 3.1 UP et je suis en
Bizarre...
train de recompiler un current (je suis au moins sûr que le current
MP n'a pas le problème du CTRL+D, mais la console est cassée dans le
GENERIC).
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de
schadenfreude pour aujourd'hui.
Recompiler un NetBSD sur un SS20 avec un seul RT626 est
une gageure :-(
En étant à peine vache, je te ferai remarquer que la compilation de
NetBSD est la seule chose qui fonctionne. Faire tourner le résultat,
voilà la gageure.
Oui, il n'y a plus de plantage avec un CTRL+D, mais des trucs bizarres du style "async register" mais à ce moment, l'affichage est corrompu. Pour l'instant, je tourne avec un 3.1 UP et je suis en
Bizarre...
train de recompiler un current (je suis au moins sûr que le current MP n'a pas le problème du CTRL+D, mais la console est cassée dans le GENERIC).
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de schadenfreude pour aujourd'hui.
Recompiler un NetBSD sur un SS20 avec un seul RT626 est une gageure :-(
En étant à peine vache, je te ferai remarquer que la compilation de NetBSD est la seule chose qui fonctionne. Faire tourner le résultat, voilà la gageure.
JKB
Le 02-03-2007, à propos de Re: NetBSD et SparcSTATION-20 quadriROSS, Miod Vallat écrivait dans fr.comp.os.bsd :
Oui, il n'y a plus de plantage avec un CTRL+D, mais des trucs bizarres du style "async register" mais à ce moment, l'affichage est corrompu. Pour l'instant, je tourne avec un 3.1 UP et je suis en
Bizarre...
train de recompiler un current (je suis au moins sûr que le current MP n'a pas le problème du CTRL+D, mais la console est cassée dans le GENERIC).
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14 n'est pas fonctionnel (s'il est dans le GENERIC). La machine est accessible en telnet, mais ce n'est pas la but. Tout ça pour dire que je ne vois pas bien ce qu'il y a de risible...
Recompiler un NetBSD sur un SS20 avec un seul RT626 est une gageure :-(
En étant à peine vache, je te ferai remarquer que la compilation de NetBSD est la seule chose qui fonctionne. Faire tourner le résultat, voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et des SunOS de toutes moutures et du VMS depuis avant l'appellation Open, un NetBSD est presque limpide.
Je tenterais bien OpenBSD si seulement le support SMP était assuré sur les sun4m ;-)
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 02-03-2007, à propos de
Re: NetBSD et SparcSTATION-20 quadriROSS,
Miod Vallat écrivait dans fr.comp.os.bsd :
Oui, il n'y a plus de plantage avec un CTRL+D, mais des trucs
bizarres du style "async register" mais à ce moment, l'affichage est
corrompu. Pour l'instant, je tourne avec un 3.1 UP et je suis en
Bizarre...
train de recompiler un current (je suis au moins sûr que le current
MP n'a pas le problème du CTRL+D, mais la console est cassée dans le
GENERIC).
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de
schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14
n'est pas fonctionnel (s'il est dans le GENERIC). La machine est
accessible en telnet, mais ce n'est pas la but. Tout ça pour dire
que je ne vois pas bien ce qu'il y a de risible...
Recompiler un NetBSD sur un SS20 avec un seul RT626 est
une gageure :-(
En étant à peine vache, je te ferai remarquer que la compilation de
NetBSD est la seule chose qui fonctionne. Faire tourner le résultat,
voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et
des SunOS de toutes moutures et du VMS depuis avant l'appellation
Open, un NetBSD est presque limpide.
Je tenterais bien OpenBSD si seulement le support SMP était assuré
sur les sun4m ;-)
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 02-03-2007, à propos de Re: NetBSD et SparcSTATION-20 quadriROSS, Miod Vallat écrivait dans fr.comp.os.bsd :
Oui, il n'y a plus de plantage avec un CTRL+D, mais des trucs bizarres du style "async register" mais à ce moment, l'affichage est corrompu. Pour l'instant, je tourne avec un 3.1 UP et je suis en
Bizarre...
train de recompiler un current (je suis au moins sûr que le current MP n'a pas le problème du CTRL+D, mais la console est cassée dans le GENERIC).
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14 n'est pas fonctionnel (s'il est dans le GENERIC). La machine est accessible en telnet, mais ce n'est pas la but. Tout ça pour dire que je ne vois pas bien ce qu'il y a de risible...
Recompiler un NetBSD sur un SS20 avec un seul RT626 est une gageure :-(
En étant à peine vache, je te ferai remarquer que la compilation de NetBSD est la seule chose qui fonctionne. Faire tourner le résultat, voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et des SunOS de toutes moutures et du VMS depuis avant l'appellation Open, un NetBSD est presque limpide.
Je tenterais bien OpenBSD si seulement le support SMP était assuré sur les sun4m ;-)
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Miod Vallat
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14 n'est pas fonctionnel (s'il est dans le GENERIC). La machine est accessible en telnet, mais ce n'est pas la but. Tout ça pour dire que je ne vois pas bien ce qu'il y a de risible...
Le fait que NetBSD devient un système alternatif au sens propre du terme, de nos jours : un jour il marche, un jour il ne marche pas. Par moments, le manque de test est pitoyable. Personne n'est à l'abri d'une grosse bourde de temps à autre, mais il devrait y avoir une population suffisante d'utilisateur de cg14 parmi les utilisateurs ou développeurs de NetBSD, afin d'éviter que sur les release officielles estampillées label rouge^Worange, ce genre de gag ne se produise pas.
Autant je veux bien comprendre qu'il y ait des problèmes sur une configuration 4xRT626 avec un noyau SMP, autant je ne comprends pas qu'il y ait des problèmes sur l'utilisation de cgfourteen(4) + rcons(8) avec le GENERIC de base de release.
Merde quoi, ça fait dix ans qu'il existe, ce driver, et il y a des gens chez NetBSD comme Mike Parker qui programment les registres du SUNW,sx au petit déjeuner... mais bon, si j'ai bien compris sur ses sparc il tourne du 1.4T ou approchant.
En étant à peine vache, je te ferai remarquer que la compilation de NetBSD est la seule chose qui fonctionne. Faire tourner le résultat, voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et des SunOS de toutes moutures et du VMS depuis avant l'appellation Open, un NetBSD est presque limpide.
Je parlais de la stabilité des binaires, pas de la difficulté de mise en oeuvre.
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de
schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14
n'est pas fonctionnel (s'il est dans le GENERIC). La machine est
accessible en telnet, mais ce n'est pas la but. Tout ça pour dire
que je ne vois pas bien ce qu'il y a de risible...
Le fait que NetBSD devient un système alternatif au sens propre du
terme, de nos jours : un jour il marche, un jour il ne marche pas. Par
moments, le manque de test est pitoyable. Personne n'est à l'abri d'une
grosse bourde de temps à autre, mais il devrait y avoir une population
suffisante d'utilisateur de cg14 parmi les utilisateurs ou développeurs
de NetBSD, afin d'éviter que sur les release officielles estampillées
label rouge^Worange, ce genre de gag ne se produise pas.
Autant je veux bien comprendre qu'il y ait des problèmes sur une
configuration 4xRT626 avec un noyau SMP, autant je ne comprends pas
qu'il y ait des problèmes sur l'utilisation de cgfourteen(4) + rcons(8)
avec le GENERIC de base de release.
Merde quoi, ça fait dix ans qu'il existe, ce driver, et il y a des gens
chez NetBSD comme Mike Parker qui programment les registres du SUNW,sx
au petit déjeuner... mais bon, si j'ai bien compris sur ses sparc il
tourne du 1.4T ou approchant.
En étant à peine vache, je te ferai remarquer que la compilation de
NetBSD est la seule chose qui fonctionne. Faire tourner le résultat,
voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et
des SunOS de toutes moutures et du VMS depuis avant l'appellation
Open, un NetBSD est presque limpide.
Je parlais de la stabilité des binaires, pas de la difficulté de mise en
oeuvre.
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14 n'est pas fonctionnel (s'il est dans le GENERIC). La machine est accessible en telnet, mais ce n'est pas la but. Tout ça pour dire que je ne vois pas bien ce qu'il y a de risible...
Le fait que NetBSD devient un système alternatif au sens propre du terme, de nos jours : un jour il marche, un jour il ne marche pas. Par moments, le manque de test est pitoyable. Personne n'est à l'abri d'une grosse bourde de temps à autre, mais il devrait y avoir une population suffisante d'utilisateur de cg14 parmi les utilisateurs ou développeurs de NetBSD, afin d'éviter que sur les release officielles estampillées label rouge^Worange, ce genre de gag ne se produise pas.
Autant je veux bien comprendre qu'il y ait des problèmes sur une configuration 4xRT626 avec un noyau SMP, autant je ne comprends pas qu'il y ait des problèmes sur l'utilisation de cgfourteen(4) + rcons(8) avec le GENERIC de base de release.
Merde quoi, ça fait dix ans qu'il existe, ce driver, et il y a des gens chez NetBSD comme Mike Parker qui programment les registres du SUNW,sx au petit déjeuner... mais bon, si j'ai bien compris sur ses sparc il tourne du 1.4T ou approchant.
En étant à peine vache, je te ferai remarquer que la compilation de NetBSD est la seule chose qui fonctionne. Faire tourner le résultat, voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et des SunOS de toutes moutures et du VMS depuis avant l'appellation Open, un NetBSD est presque limpide.
Je parlais de la stabilité des binaires, pas de la difficulté de mise en oeuvre.
alwe.maindargent
On Mar 2, 9:08 pm, Miod Vallat wrote:
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14 n'est pas fonctionnel (s'il est dans le GENERIC). La machine est accessible en telnet, mais ce n'est pas la but. Tout ça pour dire que je ne vois pas bien ce qu'il y a de risible...
Le fait que NetBSD devient un système alternatif au sens propre du terme, de nos jours : un jour il marche, un jour il ne marche pas. Par moments, le manque de test est pitoyable. Personne n'est à l'abri d'une grosse bourde de temps à autre, mais il devrait y avoir une population suffisante d'utilisateur de cg14 parmi les utilisateurs ou développeurs de NetBSD, afin d'éviter que sur les release officielles estampillées label rouge^Worange, ce genre de gag ne se produise pas.
Autant je veux bien comprendre qu'il y ait des problèmes sur une configuration 4xRT626 avec un noyau SMP, autant je ne comprends pas qu'il y ait des problèmes sur l'utilisation de cgfourteen(4) + rcons(8) avec le GENERIC de base de release.
Merde quoi, ça fait dix ans qu'il existe, ce driver, et il y a des gens chez NetBSD comme Mike Parker qui programment les registres du SUNW,sx au petit déjeuner... mais bon, si j'ai bien compris sur ses sparc il tourne du 1.4T ou approchant.
En étant à peine vache, je te ferai remarquer que la compilation de NetBSD est la seule chose qui fonctionne. Faire tourner le résultat, voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et des SunOS de toutes moutures et du VMS depuis avant l'appellation Open, un NetBSD est presque limpide.
Je parlais de la stabilité des binaires, pas de la difficulté de mise en oeuvre. Le bug survient sur une current, donc pas vraiment une release
officielle.... Si la population de testeur etait assez grande, il devrait y avoir au moins un bug report à ce sujet. On peut donc en supposer que personne n'a de current ou de 4.0 beta_2 tournant sur ce genre de matériel....
Serait il possible que : - tu essaye de booter un kernel 4.0_beta2 disponible ici pour voir si le problème existe aussi en 4.0 ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-daily/netbsd-4/200703040000Z/sparc/b inary/kernel - envoyer un bug report en précisant bien que ca marche en 3.1, le status de la 4.0 et une description du problème en current.
Si le problème existe en 4.0beta2, il devra être régler avant la sortie de la release.
Cordialement.
On Mar 2, 9:08 pm, Miod Vallat <m...@online.fr> wrote:
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de
schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14
n'est pas fonctionnel (s'il est dans le GENERIC). La machine est
accessible en telnet, mais ce n'est pas la but. Tout ça pour dire
que je ne vois pas bien ce qu'il y a de risible...
Le fait que NetBSD devient un système alternatif au sens propre du
terme, de nos jours : un jour il marche, un jour il ne marche pas. Par
moments, le manque de test est pitoyable. Personne n'est à l'abri d'une
grosse bourde de temps à autre, mais il devrait y avoir une population
suffisante d'utilisateur de cg14 parmi les utilisateurs ou développeurs
de NetBSD, afin d'éviter que sur les release officielles estampillées
label rouge^Worange, ce genre de gag ne se produise pas.
Autant je veux bien comprendre qu'il y ait des problèmes sur une
configuration 4xRT626 avec un noyau SMP, autant je ne comprends pas
qu'il y ait des problèmes sur l'utilisation de cgfourteen(4) + rcons(8)
avec le GENERIC de base de release.
Merde quoi, ça fait dix ans qu'il existe, ce driver, et il y a des gens
chez NetBSD comme Mike Parker qui programment les registres du SUNW,sx
au petit déjeuner... mais bon, si j'ai bien compris sur ses sparc il
tourne du 1.4T ou approchant.
En étant à peine vache, je te ferai remarquer que la compilation de
NetBSD est la seule chose qui fonctionne. Faire tourner le résultat,
voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et
des SunOS de toutes moutures et du VMS depuis avant l'appellation
Open, un NetBSD est presque limpide.
Je parlais de la stabilité des binaires, pas de la difficulté de mise en
oeuvre.
Le bug survient sur une current, donc pas vraiment une release
officielle....
Si la population de testeur etait assez grande, il devrait y avoir au
moins un bug
report à ce sujet. On peut donc en supposer que personne n'a de
current ou de
4.0 beta_2 tournant sur ce genre de matériel....
Serait il possible que :
- tu essaye de booter un kernel 4.0_beta2 disponible ici pour voir
si le problème existe
aussi en 4.0
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-daily/netbsd-4/200703040000Z/sparc/b inary/kernel
- envoyer un bug report en précisant bien que ca marche en 3.1, le
status de la 4.0 et une
description du problème en current.
Si le problème existe en 4.0beta2, il devra être régler avant la
sortie de la release.
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14 n'est pas fonctionnel (s'il est dans le GENERIC). La machine est accessible en telnet, mais ce n'est pas la but. Tout ça pour dire que je ne vois pas bien ce qu'il y a de risible...
Le fait que NetBSD devient un système alternatif au sens propre du terme, de nos jours : un jour il marche, un jour il ne marche pas. Par moments, le manque de test est pitoyable. Personne n'est à l'abri d'une grosse bourde de temps à autre, mais il devrait y avoir une population suffisante d'utilisateur de cg14 parmi les utilisateurs ou développeurs de NetBSD, afin d'éviter que sur les release officielles estampillées label rouge^Worange, ce genre de gag ne se produise pas.
Autant je veux bien comprendre qu'il y ait des problèmes sur une configuration 4xRT626 avec un noyau SMP, autant je ne comprends pas qu'il y ait des problèmes sur l'utilisation de cgfourteen(4) + rcons(8) avec le GENERIC de base de release.
Merde quoi, ça fait dix ans qu'il existe, ce driver, et il y a des gens chez NetBSD comme Mike Parker qui programment les registres du SUNW,sx au petit déjeuner... mais bon, si j'ai bien compris sur ses sparc il tourne du 1.4T ou approchant.
En étant à peine vache, je te ferai remarquer que la compilation de NetBSD est la seule chose qui fonctionne. Faire tourner le résultat, voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et des SunOS de toutes moutures et du VMS depuis avant l'appellation Open, un NetBSD est presque limpide.
Je parlais de la stabilité des binaires, pas de la difficulté de mise en oeuvre. Le bug survient sur une current, donc pas vraiment une release
officielle.... Si la population de testeur etait assez grande, il devrait y avoir au moins un bug report à ce sujet. On peut donc en supposer que personne n'a de current ou de 4.0 beta_2 tournant sur ce genre de matériel....
Serait il possible que : - tu essaye de booter un kernel 4.0_beta2 disponible ici pour voir si le problème existe aussi en 4.0 ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-daily/netbsd-4/200703040000Z/sparc/b inary/kernel - envoyer un bug report en précisant bien que ca marche en 3.1, le status de la 4.0 et une description du problème en current.
Si le problème existe en 4.0beta2, il devra être régler avant la sortie de la release.
Cordialement.
JKB
Le 06-03-2007, à propos de Re: NetBSD et SparcSTATION-20 quadriROSS, écrivait dans fr.comp.os.bsd :
On Mar 2, 9:08 pm, Miod Vallat wrote:
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14 n'est pas fonctionnel (s'il est dans le GENERIC). La machine est accessible en telnet, mais ce n'est pas la but. Tout ça pour dire que je ne vois pas bien ce qu'il y a de risible...
Le fait que NetBSD devient un système alternatif au sens propre du terme, de nos jours : un jour il marche, un jour il ne marche pas. Par moments, le manque de test est pitoyable. Personne n'est à l'abri d'une grosse bourde de temps à autre, mais il devrait y avoir une population suffisante d'utilisateur de cg14 parmi les utilisateurs ou développeurs de NetBSD, afin d'éviter que sur les release officielles estampillées label rouge^Worange, ce genre de gag ne se produise pas.
Autant je veux bien comprendre qu'il y ait des problèmes sur une configuration 4xRT626 avec un noyau SMP, autant je ne comprends pas qu'il y ait des problèmes sur l'utilisation de cgfourteen(4) + rcons(8) avec le GENERIC de base de release.
Merde quoi, ça fait dix ans qu'il existe, ce driver, et il y a des gens chez NetBSD comme Mike Parker qui programment les registres du SUNW,sx au petit déjeuner... mais bon, si j'ai bien compris sur ses sparc il tourne du 1.4T ou approchant.
En étant à peine vache, je te ferai remarquer que la compilation de NetBSD est la seule chose qui fonctionne. Faire tourner le résultat, voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et des SunOS de toutes moutures et du VMS depuis avant l'appellation Open, un NetBSD est presque limpide.
Je parlais de la stabilité des binaires, pas de la difficulté de mise en oeuvre. Le bug survient sur une current, donc pas vraiment une release
officielle.... Si la population de testeur etait assez grande, il devrait y avoir au moins un bug report à ce sujet. On peut donc en supposer que personne n'a de current ou de 4.0 beta_2 tournant sur ce genre de matériel....
Serait il possible que : - tu essaye de booter un kernel 4.0_beta2 disponible ici pour voir si le problème existe aussi en 4.0 ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-daily/netbsd-4/200703040000Z/sparc/binary/kernel - envoyer un bug report en précisant bien que ca marche en 3.1, le status de la 4.0 et une description du problème en current.
Si le problème existe en 4.0beta2, il devra être régler avant la sortie de la release.
Disons qu'avec le noyau 3.1, la CG14 émule une CG3 ou 6 (je ne sais plus) et qu'avec une 4.0beta2, c'est une CG8... Le problème vient de là. Par ailleurs, il y a _beaucoup_ plus grave. Aucun des deux noyaux n'est réellement stable sur du ROSS/SMP.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 06-03-2007, à propos de
Re: NetBSD et SparcSTATION-20 quadriROSS,
alwe.maindargent@gmail.com écrivait dans fr.comp.os.bsd :
On Mar 2, 9:08 pm, Miod Vallat <m...@online.fr> wrote:
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de
schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14
n'est pas fonctionnel (s'il est dans le GENERIC). La machine est
accessible en telnet, mais ce n'est pas la but. Tout ça pour dire
que je ne vois pas bien ce qu'il y a de risible...
Le fait que NetBSD devient un système alternatif au sens propre du
terme, de nos jours : un jour il marche, un jour il ne marche pas. Par
moments, le manque de test est pitoyable. Personne n'est à l'abri d'une
grosse bourde de temps à autre, mais il devrait y avoir une population
suffisante d'utilisateur de cg14 parmi les utilisateurs ou développeurs
de NetBSD, afin d'éviter que sur les release officielles estampillées
label rouge^Worange, ce genre de gag ne se produise pas.
Autant je veux bien comprendre qu'il y ait des problèmes sur une
configuration 4xRT626 avec un noyau SMP, autant je ne comprends pas
qu'il y ait des problèmes sur l'utilisation de cgfourteen(4) + rcons(8)
avec le GENERIC de base de release.
Merde quoi, ça fait dix ans qu'il existe, ce driver, et il y a des gens
chez NetBSD comme Mike Parker qui programment les registres du SUNW,sx
au petit déjeuner... mais bon, si j'ai bien compris sur ses sparc il
tourne du 1.4T ou approchant.
En étant à peine vache, je te ferai remarquer que la compilation de
NetBSD est la seule chose qui fonctionne. Faire tourner le résultat,
voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et
des SunOS de toutes moutures et du VMS depuis avant l'appellation
Open, un NetBSD est presque limpide.
Je parlais de la stabilité des binaires, pas de la difficulté de mise en
oeuvre.
Le bug survient sur une current, donc pas vraiment une release
officielle....
Si la population de testeur etait assez grande, il devrait y avoir au
moins un bug
report à ce sujet. On peut donc en supposer que personne n'a de
current ou de
4.0 beta_2 tournant sur ce genre de matériel....
Serait il possible que :
- tu essaye de booter un kernel 4.0_beta2 disponible ici pour voir
si le problème existe
aussi en 4.0
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-daily/netbsd-4/200703040000Z/sparc/binary/kernel
- envoyer un bug report en précisant bien que ca marche en 3.1, le
status de la 4.0 et une
description du problème en current.
Si le problème existe en 4.0beta2, il devra être régler avant la
sortie de la release.
Disons qu'avec le noyau 3.1, la CG14 émule une CG3 ou 6 (je ne sais
plus) et qu'avec une 4.0beta2, c'est une CG8... Le problème vient de
là. Par ailleurs, il y a _beaucoup_ plus grave. Aucun des deux
noyaux n'est réellement stable sur du ROSS/SMP.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 06-03-2007, à propos de Re: NetBSD et SparcSTATION-20 quadriROSS, écrivait dans fr.comp.os.bsd :
On Mar 2, 9:08 pm, Miod Vallat wrote:
Là, je me permettrais bien une franche rigolade, mais j'ai eu assez de schadenfreude pour aujourd'hui.
Là, je ne comprends pas... Le current boote mais le support CG14 n'est pas fonctionnel (s'il est dans le GENERIC). La machine est accessible en telnet, mais ce n'est pas la but. Tout ça pour dire que je ne vois pas bien ce qu'il y a de risible...
Le fait que NetBSD devient un système alternatif au sens propre du terme, de nos jours : un jour il marche, un jour il ne marche pas. Par moments, le manque de test est pitoyable. Personne n'est à l'abri d'une grosse bourde de temps à autre, mais il devrait y avoir une population suffisante d'utilisateur de cg14 parmi les utilisateurs ou développeurs de NetBSD, afin d'éviter que sur les release officielles estampillées label rouge^Worange, ce genre de gag ne se produise pas.
Autant je veux bien comprendre qu'il y ait des problèmes sur une configuration 4xRT626 avec un noyau SMP, autant je ne comprends pas qu'il y ait des problèmes sur l'utilisation de cgfourteen(4) + rcons(8) avec le GENERIC de base de release.
Merde quoi, ça fait dix ans qu'il existe, ce driver, et il y a des gens chez NetBSD comme Mike Parker qui programment les registres du SUNW,sx au petit déjeuner... mais bon, si j'ai bien compris sur ses sparc il tourne du 1.4T ou approchant.
En étant à peine vache, je te ferai remarquer que la compilation de NetBSD est la seule chose qui fonctionne. Faire tourner le résultat, voilà la gageure.
Mais non... Une fois qu'on s'est paluché des Convex, des Tru64 et des SunOS de toutes moutures et du VMS depuis avant l'appellation Open, un NetBSD est presque limpide.
Je parlais de la stabilité des binaires, pas de la difficulté de mise en oeuvre. Le bug survient sur une current, donc pas vraiment une release
officielle.... Si la population de testeur etait assez grande, il devrait y avoir au moins un bug report à ce sujet. On peut donc en supposer que personne n'a de current ou de 4.0 beta_2 tournant sur ce genre de matériel....
Serait il possible que : - tu essaye de booter un kernel 4.0_beta2 disponible ici pour voir si le problème existe aussi en 4.0 ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-daily/netbsd-4/200703040000Z/sparc/binary/kernel - envoyer un bug report en précisant bien que ca marche en 3.1, le status de la 4.0 et une description du problème en current.
Si le problème existe en 4.0beta2, il devra être régler avant la sortie de la release.
Disons qu'avec le noyau 3.1, la CG14 émule une CG3 ou 6 (je ne sais plus) et qu'avec une 4.0beta2, c'est une CG8... Le problème vient de là. Par ailleurs, il y a _beaucoup_ plus grave. Aucun des deux noyaux n'est réellement stable sur du ROSS/SMP.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
