NetBSD Problem Report #18566

Received: (qmail 28802 invoked by uid 605); 7 Oct 2002 03:07:13 -0000
Message-Id: <200210070303.g9733Fx00674@enterprise.home.river-styx.org>
Date: Mon, 7 Oct 2002 13:03:15 +1000 (EST)
From: murray@river-styx.org
Sender: gnats-bugs-owner@netbsd.org
Reply-To: murray@river-styx.org
To: gnats-bugs@gnats.netbsd.org
Subject: multi processor issues with sable
X-Send-Pr-Version: 3.95

>Number:         18566
>Category:       port-alpha
>Synopsis:       MP kernel panic on alpha sable
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    port-alpha-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 07 03:08:00 +0000 2002
>Closed-Date:    
>Last-Modified:  Sat Nov 12 16:47:45 +0000 2005
>Originator:     Murray Armfield
>Release:        NetBSD 1.6
>Organization:

>Environment:
System: NetBSD 1.6 (GENERIC.MP)
Architecture: alpha
Machine: alpha
>Description:
	I have a digital alphaserver 2100 4/275 kicking around. It has NetBSD 1.6 on it
	but works with only one cpu at any time. Having more than one cpu panics system.

	dmesg:

	sd6 at scsibus1 target 2 lun 0: <DEC, RZ29B    (C) DEC, 0014> SCSI2 0/direct fixed
	sd6: 4091 MB, 3708 cyl, 20 head, 113 sec, 512 bytes/sect x 8380080 sectors
	sd6: sync (100.0ns offset 8), 8-bit (10.000MB/s) transfers, tagged queueing
	IPsec: Initialized Security Association Processing.
	root on sd0a dumps on sd0b
	root file system type: ffs

	unexpected machine check:

	mces    = 0x1
	vector  = 0x660
	param   = 0xfffffc0000006400
	pc      = 0xfffffc000030073c
	ra      = 0xfffffc000030072c
	code    = 0x10000008a
	curproc = 0x0

    panic: machine check
    Stopped at      cpu_Debugger+0x4:       ret     zero,(ra)
    db{1}> t
    cpu_Debugger() at cpu_Debugger+0x4
    panic() at panic+0x168
    machine_check() at machine_check+0x25c
    dec_2100_a500_machine_check() at dec_2100_a500_machine_check+0x40
    interrupt() at interrupt+0x228
    XentInt() at XentInt+0x1c
    --- interrupt (from ipl 0) ---
    idle() at idle+0x64
    idle() at idle+0x54
    --- root of call graph ---
    db{1}> sync
    syncing disks... done

    dumping to dev 8,1 offset 524351
    dump 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 2
    33 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209
    208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 1
    84 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160
    159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 1
    35 134 133 132 131 130 129 128 127 

    unexpected machine check:
    unexpected machine check:


	  mces    = 0x1
   	  mces    = 0x1
	  vector  = 0x660
	  vector  = 0x670
	  param   = 0xfffffc0000006000
	  param   = 0xfffffc0000006400
	  pc      = 0xfffffc00005e44d4
	  pc      = 0xfffffc0000346d4c
	  ra      = 0xfffffc00005e4044
	  ra      = 0xfffffc0000346d4c
	  code    = 0x10000008a
	  code    = 0x10000008a
	  curproc = 0x0
	  curproc = 0x0


     panic: panic: machine checkmachine check

      tSotpoppepde d   a t              captu_cDpeub_uDgegbeurg+g0exr4+:0 x 4 :         r e t           
      z 
       e rroe,t( r a ) 
       zdebr{o0,}(>r a )
  db{1}>

  As you can see it also fails to dump to disk. I had a look at the freebsd code and it seems that freebsd
  has rewritten the T2 chipset support based on Tru64 support from Compaq which was open sourced with a bsd
  license.

  If someone would like to work on this I can supply access to the hardware. Please feel free to contact me.

>How-To-Repeat:
	Try turning on more than one cpu on a sable.
>Fix:
  no idea off hand.
>Release-Note:
>Audit-Trail:
>Unformatted:

Home	PR Database Search