Bug#440720: [SPARC]: non-SMP kernel fail on SunFIres with >= 2 CPUs
Hi,
> Looks like we need to discuss the available options for this
> problem. Other issue is to know if current snapshots of 2.6.23 does
> work or not on this hardware.
>
> Bernd, can you test lastest 2.6.23 snapshot and see if it works? Check
> at http://wiki.debian.org/DebianKernel for more information where to
> find them.
I've installed the machine using a 2.6.23-rc5 _smp_ kernel, all older
non-smp kernels failed to boot, and as Ihad to build my own installer
and kernel anyway I've decided to use an smp version.
As it takes a _long_ time to reboot a machine with a "crashed" CPU
(which was the result of all non-SMP kernel tests so far), and the
machine should be in production yet, I would like to avoid to try a
non-smp kernel on this machine.
I've looked trough the sparc64 commits (about 80) between 2.6.22 and
2.6.23-rc6 and there was non which looked like it would address such an
issue. If you can point me to such a change I'll give a non-smp kernel a
try.
Also I'm pretty sure that non-smp kernels just don't work on the
machine. As far as I understand the way those machines work is that at
least two CPUs have to be in an operating state as they share one CPU
Data switch (if you have a look into such a machine you see that always
2 CPUs + their memory are sitting in a CPU bay, and as far as I know you
can't run the system with an odd number of CPUs.
All processors share the same pysical memory address space and use -
depending on the number of CPUs - different cache coherence protocols,
so as far as I understand it such a system can't work at all without
having all CPUs properly initialized. But probably somebody with a
better knowledge about this architecture can give us some insight on
that, therefore I'm forwarding the message to debian-sparc, too.
Probably interesting to read for you:
http://www.sun.com/processors/manuals/USIIIv2.pdf
http://docs-pdf.sun.com/806-6592-11/806-6592-11.pdf
Cheers,
Bernd
--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>
Reply to: