On Tue, Sep 09, 2025 at 12:24:06AM +0200, Riccardo Mottola wrote: > 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?
Hard to judge, it could be a hardware issue. If all you see is random crashes with little pattern then I would check that the memory is really OK (including the sockets). The netra T1 is a single core USIIi so I doubt this is any of the ghosts we're hunting on fast SMP boxes like the M10-1. -- :wq Claudio
