Port-sparc archive

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

Re: shutdown -p panics on SS10



> On May 21, 2023, at 4:31 AM, Martin Husemann <martin%duskware.de@localhost> wrote:
> 
> On Sat, May 20, 2023 at 06:21:34PM -0400, vom513 wrote:
>> On the SS10 - it panics and reboots every time.
> 
> Can you show us the panic message? Would be very easy if you have a
> serial console for that machine.

So a few things since I last posted.

I managed to trigger the panic with a “shutdown -h” as well.  So that’s not immune as I had thought.  I’m thinking this might be hardware issues at this point.

I had to enable ttya getty in /etc/ttys.  Even with this - I don’t get the panic message on serial.  Pretty sure it needs to be a “console”.

So I had thought that much like my trusty IPX box - I would disconn. montior + keyboard to get serial console.

On my IPX - this results in seeing all boot messages, OBP, etc.  Just as one would expect.

On this machine, the green LED comes on - but there is no beep.  I don’t hear any HDD activity nor see anything on serial.  Seems like this issue reported here:

https://forum.vcfed.org/index.php?threads/sun-sparcstation-10-serial-console-not-fully-working.1242113/

However, I do have a panic that managed to get captured in syslog.  Pretty sure this was one of the same ones I’ve been getting.

May 19 00:27:50 ss10 upsmon[364]: Signal 15: exiting
May 19 00:27:50 ss10 upsmon[317]: upsmon parent: read
May 19 00:28:04 ss10 syslogd[163]: Exiting on signal 15
May 19 00:30:29 ss10 syslogd[207]: restart
May 19 00:30:29 ss10 /netbsd: [ 2692.9486587] syncing disks... done
May 19 00:30:29 ss10 /netbsd: [ 2693.0107884] unmounting file systems...
May 19 00:30:29 ss10 /netbsd: [ 2693.0287015] unmounted /dev/sd1a on /mnt/sd1a type ffs
May 19 00:30:29 ss10 /netbsd: [ 2693.0386959] unmounted procfs on /proc type procfs
May 19 00:30:29 ss10 /netbsd: [ 2693.0486897] unmounted ptyfs on /dev/pts type ptyfs
May 19 00:30:29 ss10 /netbsd: [ 2693.0586951] unmounted kernfs on /kern type kernfs
May 19 00:30:29 ss10 /netbsd: [ 2693.6187362] Skipping crash dump on recursive panic
May 19 00:30:29 ss10 /netbsd: [ 2693.6379128] panic: pmap_remove_all: empty vreg
May 19 00:30:29 ss10 /netbsd: [ 2693.6586471] cpu0: Begin traceback...
May 19 00:30:29 ss10 /netbsd: [ 2693.6588026] 0x0(0xf03ba350, 0xf7f755f8, 0xf0484800, 0xf0485800, 0xf04856c8, 0x4) at netbsd:panic+0x20
May 19 00:30:29 ss10 /netbsd: [ 2693.7087483] panic(0xf03ba350, 0x0, 0x4, 0xf045f07c, 0xf0fb6700, 0x0) at netbsd:pmap_page_protect4m+0x320
May 19 00:30:29 ss10 /netbsd: [ 2693.7587541] pmap_page_protect4m(0xf057897c, 0x0, 0x2c, 0xf0a78bc0, 0x7fffffff, 0xfffff000) at netbsd:genfs_do_putpages+0x820
May 19 00:30:29 ss10 /netbsd: [ 2693.7987515] genfs_do_putpages(0x201a, 0x0, 0x0, 0x1fffff, 0xf0578940, 0x1) at netbsd:genfs_putpages+0x24
May 19 00:30:29 ss10 /netbsd: [ 2693.8487617] genfs_putpages(0xf7f758e0, 0x0, 0xf0fb6700, 0x0, 0x0, 0x0) at netbsd:VOP_PUTPAGES+0x38
May 19 00:30:29 ss10 /netbsd: [ 2693.8887526] VOP_PUTPAGES(0xf0d1dcb8, 0x0, 0x0, 0x0, 0x0, 0x201b) at netbsd:vinvalbuf+0x34
May 19 00:30:29 ss10 /netbsd: [ 2693.9187557] vinvalbuf(0xf0d1dcb8, 0x1, 0xffffffff, 0xf0fb6700, 0x0, 0x0) at netbsd:vcache_reclaim+0x74
May 19 00:30:29 ss10 /netbsd: [ 2693.9687754] vcache_reclaim(0xf0d1dcb8, 0x1, 0x8, 0xf09ee000, 0xf7f759d8, 0xf0fb6700) at netbsd:vrecycle+0xdc
May 19 00:30:29 ss10 /netbsd: [ 2694.0087733] vrecycle(0xf0d1dcb8, 0x0, 0x0, 0x0, 0x0, 0x3) at netbsd:vflush+0x164
May 19 00:30:29 ss10 /netbsd: [ 2694.0387859] vflush(0xf09ee000, 0x0, 0x2, 0xf0480d80, 0x41b8f, 0xf0d1dcb8) at netbsd:ffs_flushfiles+0x11c
May 19 00:30:29 ss10 /netbsd: [ 2694.0787818] ffs_flushfiles(0xf09ee000, 0x2, 0xf0fb6700, 0xf0468c00, 0xf08ed880, 0x0) at netbsd:ffs_unmount+0x48
May 19 00:30:29 ss10 /netbsd: [ 2694.1187842] ffs_unmount(0xf09ee000, 0x80000, 0xf0fb6700, 0xf09e8800, 0xf08ed880, 0xf09ee000) at netbsd:VFS_UNMOUNT+0x10
May 19 00:30:29 ss10 /netbsd: [ 2694.1587881] VFS_UNMOUNT(0xf09ee000, 0x80000, 0xf0465400, 0x0, 0xf0e2c7a0, 0x0) at netbsd:dounmount+0x8c
May 19 00:30:29 ss10 /netbsd: [ 2694.1987930] dounmount(0xf09ee000, 0x80000, 0xf0fb6700, 0x0, 0x740, 0x5000) at netbsd:vfs_unmountall1+0x58
May 19 00:30:29 ss10 /netbsd: [ 2694.2487947] vfs_unmountall1(0xf0fb6700, 0xf03eda80, 0x1, 0x80000, 0x0, 0xf09ee000) at netbsd:cpu_reboot+0x17c
May 19 00:30:29 ss10 /netbsd: [ 2694.2988000] cpu_reboot(0x808, 0x0, 0x0, 0x0, 0xf0480c00, 0x0) at netbsd:sys_reboot+0x44
May 19 00:30:29 ss10 /netbsd: [ 2694.3388084] sys_reboot(0x0, 0xf7f75f30, 0xf7f75f28, 0x808, 0x0, 0x14752c) at netbsd:syscall+0xe8
May 19 00:30:29 ss10 /netbsd: [ 2694.3888066] syscall(0xcd0, 0xf7f75fb0, 0xedcd4398, 0xd0, 0x4e, 0xf0fb6700) at netbsd:memfault_sun4m+0x3f4
May 19 00:30:29 ss10 /netbsd: [ 2694.4274910] cpu0: End traceback...
May 19 00:30:29 ss10 /netbsd: [ 2694.4375343] rebooting
May 19 00:30:29 ss10 /netbsd: 

I have a faster CPU coming tomorrow from eBay.  I can try that.  The original memory in this box was def. bad.  I replaced it and thought that I was okay on memory, but now I’m not sure.  Might have to get more memory again and try that.  The strange thing is when the box is running - it seems to be just fine.  Running X uses the memory a bit more than a headless/idle box.  I also ran sha512 sums on all files to stress the CPU.  No errors/issues.  It seems to only be on shutdown - and frustratingly - right as it’s trying to sync/unmount everything...

Thanks for looking at this and any insights.




Home | Main Index | Thread Index | Old Index