[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Systems which can run on a SS2.



Martin wrote:
On Sun, 2009-07-26 at 14:38 -0700, Peter Crawford wrote:
Mon, 25 May 2009 11:29:27 +0200 Joël BERTRAND wrote,
"Etch worked fine."

Whereas http://www.debian.org/releases/stable/sparc/ch02s01.html.en#sparc-cpus states "sun4, sun4c, sun4d, sun4m
   ...
The last Debian release to support sparc32 was Etch, but even then only for sun4m systems. Support for the other 32-bits subarchitectures had already been discontinued after earlier releases."

The Web page is wrong?
I believe the web page is the official position.  The differences
between 32 bit SPARC based machines are not that great (multiply and
divide added in V8 / sun4m, plus (IIRC) one or two of the
synchronisation operations).  Thus it is possible that older machines
could be run using etch or mostly etch.  Plus, without more context I
couldn't be entirely sure which machines Joel is refering to.

Only sun4m (SS5 in of course UniProcessor configuration [MicroSparc-II/85, not TurboSparc] and SS20 [SuperSparc II/75]). I have some trouble with SS20 in SMP configuration (dual SM71 or quad ROSS). Last kernel that works fine on HyperSparc's was 2.2.19. My SS2 runs with etch (sparcv7 processor at 40 MHz).

Mon, 25 May 2009 11:29:27 +0200 Joël BERTRAND wrote,
" ... good results with lenny and 2.6 kernel (only UP and sparcv8 [SS20] ..."

Would UP be Ultra Panther or Ultra Plus? Not that I have either; just for interest.
I suspect it is uni-processor

	Yes, of course.

as SS20's could be fitted with 2 (or with
later modules, 4) processors, althought support for this has been iffy
for some time.

" ... sun4[cdm] stations, you have to use NetBSD 4.0.1 (or 5.0 in UP)."

NetBSD 4.0.x runs fine on SuperSparc, but I suspect a bug in HyperSparc support (my quad ROSS SS20 can enter in a deadlock). NetBSD 5.0 perfectly run on a UP sun4m. There are some bugs in SMP support (kernel tries to use struct_cpu before allocation... This bug is well known but not easy to fix...).

In http://www.netbsd.org/ports/sparc/
sun4c is listed as supported. Absence of reference to a release should mean that 5.0 works.
I am under the impression that sun4d and sun4m are effectively supersets
of sun4c, thus 4c support should be sufficient.

I'm not sure. sun4, sun4c, sun4d and sun4m are _different_ (and I have found a doc from Sun with a sun4e arch, but I have never seen any sun4e sparcstation.). On sun4d, you have to add Xbus support. On sun4m, you have to add SMP support (and mbus support), but sun4m doen't mean sparcv8 because you can find SS20 with dual sparcv7 processors... In sun4m, you can install Sparc/SuperSparc processors with wired cache, but you can install too HyperSparc processors with cache aliasing... If you have sun4c support, you only have sun4c support, not sun4m (you can try to boot a SS20/HyperSparc UP with a strict sun4c kernel.). If you have a sparcstation that boots with linux, you can see that its kernel is patched on the fly to support all sparc subarchitectures (MMU).

Mon, 25 May 2009 16:31:12 +0100 Martin wrote,
" ... and remember having an insecure box on the net doesn't just affect
you; it potentially affects everyone."

You've convinced me.  I'll learn to install NetBSD.

Good choice. Even Solaris is not stable on SS20. The last one I that is stable (in SMP) is 2.6. After 2.7, I suppose that sparc32 support was deprecated and Solaris often crashes with 'NMI watchdog error' or deadlocks.

Again, without context, I'm not sure if you're quoting me or what I was
talking about but I guess it's a question of what you want to do with
the machines, an older version of Debian may be sufficient, or maybe
NetBSD.

I don't agree. In text mode only, etch is usable. With X, I can see some 'NMI watchdog reset' (CG6, CG14 or ZX framebuffer).

	Regards,

	JKB


Reply to: