Re: V240 Status?
"J. Hannken-Illjes" <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.sparc64 |
|---|---|
| Message-ID | <[email protected]> |
On Jan 20, 2013, at 12:41 PM, matthew green <[email protected]> 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 - [email protected] - TU Braunschweig (Germany)