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

Re: Bug#440720: [SPARC]: non-SMP kernel fail on SunFIres with >= 2 CPUs



Bernd Zeimetz <bernd@bzed.de> writes:

> 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.

Have you tested it witn a non-smp kernel?

> 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.

Right. It makes difficult to us to know if has or not been fixed since
your last try.

> 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.

Right :(

> 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

If that's true then we might have two options:

 - add a subarch for sparc with the needed kernel changes for it;
 - change default kernel on installer to be smp;

What other think about that? (added debian-boot on cc due this)

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."



Reply to: