Port-sparc archive

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

Re: MP kernel doesn't boot



Hello,

On Nov 14, 2008, at 12:18 PM, BERTRAND Joel wrote:

Manuel Bouyer a écrit :
Hi,

        Hello,

An up-to-date current fails to boot on a dual-CPU ss10
(SPARCstation 10 MP (2 X 390Z55), No Keyboard):
Rebooting with command: Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0 File and args:
NetBSD/sparc Secondary Boot, Revision 1.15
(builds%b0.netbsd.org@localhost, Mon Apr 28 21:05:09 UTC 2008)
Booting netbsd
3444696+99664+327156 [228144+216910]=0x42e170
OBP version 3, revision 2.25 (plugin rev 2)
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
   2006, 2007, 2008
   The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
   The Regents of the University of California.  All rights reserved.
NetBSD 4.99.62 (GENERIC.MP) #1: Thu May  1 15:09:15 CEST 2008
bouyer@rock:/dsk/l1/misc/bouyer/tmp/sparc/obj/dsk/l1/misc/ bouyer/current/src/sys/arch/sparc/compile/GENERIC.MP
total memory = 111 MB
avail memory = 104 MB
data fault: pc=0xf01de5c0 addr=0x0 sfsr=126<PERR=0,LVL=1,AT=1,FT=1,FAV,OW> data fault: pc=0xf01e3c00 addr=0x0 sfsr=126<PERR=0,LVL=1,AT=1,FT=1,FAV,OW> data fault: pc=0xf01e3c00 addr=0x0 sfsr=126<PERR=0,LVL=1,AT=1,FT=1,FAV,OW>
[...]
data fault: pc=0xf01e3c00 addr=0x0 sfsr=126<PERR=0,LVL=1,AT=1,FT=1,FAV,OW>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc4<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc1<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc6<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc3<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc0<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc5<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc2<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc7<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc4<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc1<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc6<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc3<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc0<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc5<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc2<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc7<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc4<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc1<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc6<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc3<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc0<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc5<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc2<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc7<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc4<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc1<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc6<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc3<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc0<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc5<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc2<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc7<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc4<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc1<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc6<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc3<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc0<S,PS>
trap type 0x2: pc=0xf0002000 npc=0xf0002004 psr=40000fc5<S,PS>
Watchdog Reset
Any idea ?
A UP kernel boots fine on this system.

        Same constatation with a dual RT626 SS20 (512 MB) and last kernel
(NetBSD-5.0 beta 20081113). Any news ?

Yes, sparc MP support is horribly broken right now. Known problem with a known solution but nobody with the right combination of time, skill and hardware. The problem is, that the new MP code wants to play with all struct cpuinfo befire cpus attach which results in the crash above because on sparc struct cpuinfo for any secondary CPUs is allocated when they attach. The short term solution is to have - for now - all SMP kernels statically allocate four struct cpuinfo ( not just one for the boot CPU ) since we don't really support hw with more than 4 CPUs anyway. In the worst case that wastes two pages which seems acceptable.

have fun
Michael



Home | Main Index | Thread Index | Old Index