sparc32 SMP debugging advice needed

sparc32 SMP debugging advice needed

[Robert Reif]

I'm trying to get a git rc4 SMP kernel working on an ss20 and am running
into a few problems.

An SMP kernel boots and runs fine using debian etch and a single
CPU.  However I do get this in kern.log:

Mar 23 10:59:53 ss20 kernel: Kernel command line: root=/dev/sda2 ro
Mar 23 10:59:53 ss20 kernel: PID hash table entries: 1024 (order: 10, 
4096 bytes)
Mar 23 10:59:53 ss20 kernel: start_kernel(): bug: interrupts were 
enabled early
Mar 23 10:59:53 ss20 kernel: Console: colour dummy device 80x25

It looks like something similar was fixed a while back on sparc64 but
I don't know if this is related.  I'm recompiling a kernel with more
debugging turned on to see what happens.

I get a hang when booting the same kernel with 2 CPUs at:

Begin: Loading essential drivers... ...

Nothing interesting before that.

Any advice on how to approach fixing these issues?  I can test patches.

Re: sparc32 SMP debugging advice needed

[BERTRAND Joël]

	Hello,

Robert Reif a écrit :
> I'm trying to get a git rc4 SMP kernel working on an ss20 and am running
> into a few problems.

	I have built the same kernel with some debug information about 
deadlocks and spinlocks. This kernel works fine with one SuperSPARC but 
not with one HyperSPARC (cache aliasing management mistake). With dual 
SuperSPARC (SM71), kernel randomly hangs with spinlock bug. Sometimes, 
it can boot, sometimes not, and I don't know how debug this kernel. When 
it completely boots, I can see some deadlocks (for example, run "make 
-j2" to build a kernel randomly stops with cc in D state), some randomly 
oops (syscall_to_hard) when pipe syscall is executed.

> An SMP kernel boots and runs fine using debian etch and a single
> CPU.  However I do get this in kern.log:
> 
> Mar 23 10:59:53 ss20 kernel: Kernel command line: root=/dev/sda2 ro
> Mar 23 10:59:53 ss20 kernel: PID hash table entries: 1024 (order: 10, 
> 4096 bytes)
> Mar 23 10:59:53 ss20 kernel: start_kernel(): bug: interrupts were 
> enabled early
> Mar 23 10:59:53 ss20 kernel: Console: colour dummy device 80x25
> 
> It looks like something similar was fixed a while back on sparc64 but
> I don't know if this is related.  I'm recompiling a kernel with more
> debugging turned on to see what happens.
> 
> I get a hang when booting the same kernel with 2 CPUs at:
> 
> Begin: Loading essential drivers... ...
> 
> Nothing interesting before that.
> 
> Any advice on how to approach fixing these issues?  I can test patches.

	I can test too. If someones has some idea about this trouble or a 
method to debug this kernel, he is welcome ;-)

	Regards,

	JKB

Re: sparc32 SMP debugging advice needed

[Tom "spot" Callaway]

On Fri, 2007-03-23 at 17:42 -0400, Robert Reif wrote:
> Any advice on how to approach fixing these issues?  I can test
> patches.

Sadly, it seems that in the case of sparc32, no one who is willing is
able, and no one who is able is willing.

There is no maintainer, Dave Miller isn't willing to take it on (not
that I blame him), and much of the hardware is starting to fail, making
debugging that much more fun.

Given that UP has so many issues, I don't even fathom how SMP is going
to work right anytime soon.

I'd be happy to be proven wrong here, but the likelyhood of a stable
sparc32 kernel is very very low.

~spot

Re: sparc32 SMP debugging advice needed

[Jiri Gaisler]

I have a feeling that the broken sparc32 SMP is related to
the CPU-specific SMP code, rather than the whole sparc32 port.
We have added SMP support for the leon3 (V8) processor to
linux-2.6.18.1, and are happily running systems with 8 CPUs
in hardware and up to 16 CPUs in simulation. This is done
using cache snooping to synchronize processors, i.e. we do
NOT flush or disable data caches to keep the system running.

I would therefore appreciate if the sparc32 SMP code was left
in the kernel, and not removed because it does not work on
legacy Sun systems. Leon3/SMP will be used in several projects
(and products), including the UC Berkeley RAMP massively parallel
computer system. We will make an effort to sync our leon3
port to the latest kernel version (2.6.21 ?), and try (again)
to submit the patches for review and inclusion in the
mainstream kernel.

Jiri Gaisler.
Gaisler Research.

Tom "spot" Callaway wrote:
> On Fri, 2007-03-23 at 17:42 -0400, Robert Reif wrote:
>> Any advice on how to approach fixing these issues?  I can test
>> patches.
> 
> Sadly, it seems that in the case of sparc32, no one who is willing is
> able, and no one who is able is willing.
> 
> There is no maintainer, Dave Miller isn't willing to take it on (not
> that I blame him), and much of the hardware is starting to fail, making
> debugging that much more fun.
> 
> Given that UP has so many issues, I don't even fathom how SMP is going
> to work right anytime soon.
> 
> I'd be happy to be proven wrong here, but the likelyhood of a stable
> sparc32 kernel is very very low.
> 
> ~spot
> 
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>