Hi all!
not new to OpenBSD, not new to sparc, but new to it on sparc64.
My Netra T1 was running Solaris 8, was used less and less until it
stopped booting due to a faulty RAM module. Found out which one, bought
one used... and it runs again, but with no more real use: time to put
OpenBSD on it! I already have NetBSD/sparc64 (and also sparc32, but
OpenBSD/sparc32 is sadly no more...) so a good BigEndian testing system
comes, much more capable than the 32bit ones!
essentially before Holidays the system booted, worked, I installed
packages, did some first compilation attempts, no big issues, run for a
couple of hours a couple of days before "summer pause".
Today I needed to test some updated code... boot, git update && make and
after a while it locks.
Out of chance, I still had the serial console attached with minicom on
my workstation running.
Here the output:
login: splassert: assertwaitok: want 0 have 1
panic: mtx 0x1c1e6d0: locking against myself
Stopped at db_enter+0x8: nop
TID PID UID PRFLAGS PFLAGS CPU COMMAND
panic: kernel diagnostic assertion "p->p_wchan == NULL" failed: file
"/usr/src/
sys/kern/kern_sched.c", line 370
Stopped at db_enter+0x8: nop
TID PID UID PRFLAGS PFLAGS CPU COMMAND
panic: sleep: not SONPROC but 2
Stopped at db_enter+0x8: nop
TID PID UID PRFLAGS PFLAGS CPU COMMAND
panic: sleep: not SONPROC but 2
Stopped at db_enter+0x8: nop
TID PID UID PRFLAGS PFLAGS CPU COMMAND
panic: sleep: not SONPROC but 2
Stopped at db_enter+0x8: nop
TID PID UID PRFLAGS PFLAGS CPU COMMAND
panic: sleep: not SONPROC but 2
Stopped at db_enter+0x8: nop
TID PID UID PRFLAGS PFLAGS CPU COMMAND
panic: sleep: not SONPROC but 2
Stopped at db_enter+0x8: nop
TID PID UID PRFLAGS PFLAGS CPU COMMAND
--db_more--
LOM event: +12h26m58s host FAULT: watchdog triggered
LOM event: +12h26m58s Fault LED ON
Apart that the orange led was really on...
I try to reboot it and:
WARNING: CHECK AND RESET THE DATE!
panic: kernel data fault: pc=1585a24 addr=c6c000
Stopped at db_enter+0x8: nop
TID PID UID PRFLAGS PFLAGS CPU COMMAND
*247958 1 0 0x2 0 0 init
data_access_fault(4002efbf690, 30, 1585a24, c6c000, c6cfa0, 80080f) at
data_acc
ess_fault+0x2f0
Ldatafault_internal(1c7cf50, 0, 19663b8, 400042f1a44, 400042f1a44,
3b9ac800) at
Ldatafault_internal+0xcc
pool_do_put(1c7cf50, 400042b9b90, 1, 1c84ed0, 192850c, 400042f1a40) at
pool_do_
put+0x1fc
pool_put(1c7cf50, 400042b9b90, 0, 0, 0, 0) at pool_put+0x3c
process_zap(400042e7270, 4002effc8d0, 198b8e8, 0, 0, 0) at process_zap+0xac
dowait6(4000000000000000, 0, 0, 4000040000000000, 2, 40000) at dowait6+0x588
sys_wait4(16, 4002efbff40, 4002efbfe00, 1887710, 124dc60, 1) at
sys_wait4+0xa4
syscall(4002efbfee0, 19bdf40, 4002efbff40, 1794008, 1c00, 4002efc3858)
at sysca
ll+0x3ac
syscall_setup(ffffffffffffffff, ffffffcafdafaa74, 2, 0, 0, 1ffd9b8c0f8)
at sysc
all_setup+0x124
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb>
I wonder if the new memory module is faulty again in a more subtle way?
or perhaps another one is failing in a way that startup is not rejecting
the DIMM immediatly?
Thank you,
Riccardo
