Port-sparc64 archive

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

Re: V240 Status?



On Jan 20, 2013, at 12:41 PM, matthew green <mrg%eterna.com.au@localhost> wrote:

> 
>>      cpu0 at mainbus0: SUNW,UltraSPARC-IIIi @ 1503 MHz, UPA id 0
> 
> can you try cpuctl offline 1 and see if that helps?
> 
> it needs a SMP kernel to probe/access all memory ranges,
> but we have issues with usIIIi under load.  i am not
> familiar with hangs, but h/w generated resets that appear
> to be timeouts in the jbus interface that normally indicate
> a h/w problem.

Tracked it down a bit ... I was using a kernel with the new vfs_fstrans
using subr_pserialize using high priority cpu crosscalls.

Changing pserialize_perform to use low priority calls makes the machine work.


With a DEBUG+LOCKDEBUG kernel and both cpus running I get panics around
the thread "0.2 == idle/0" like:

  cpu0: data fault: pc=14ab540 rpc=12c503c addr=0
  kernel trap 30: data access exception
  Stopped in pid 0.2 (system) at  netbsd:lockdebug_barrier+0x140: lduh          
  [%g4 + 0x314], %o1

  with 14ab540 == subr_lockdebug.c:666 and 12c503c == kern_idle.c:74

or

  panic: kernel diagnostic assertion "l == curlwp" failed: file 
"src/sys/sys/lwp.h", line 496 
  Stopped in pid 0.2 (system) at  netbsd:cpu_Debugger+0x4:        nop


Are high priority cpu crosscalls working on other Sparc64 SMP systems?

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)



Home | Main Index | Thread Index | Old Index