David Brownlee wrote:
On Fri, 29 Dec 2023 at 16:29, BERTRAND Joël <joel.bertrand%systella.fr@localhost> wrote:David Brownlee wrote:On Wed, 27 Dec 2023 at 08:25, BERTRAND Joël <joel.bertrand%systella.fr@localhost> wrote:Hello, Yesterday, I have changed my system disk (raid0). Thus, system has rebuilt a 1 To raid1 volume and system has crashed three or four times. First time : [ 5235.028358] uvm_fault(0xffffffff8190fbc0, 0xfffff6fc5a75b000, 2) -> e [ 5235.028358] fatal page fault in supervisor mode [ 5235.028358] trap type 6 code 0x2 rip 0xffffffff80ea1063 cs 0x8 rflags 0x10246 cr2 0xfffff6fc5a75bb98 ilevel 0 rsp 0xffffac04372f5e98 [ 5235.028358] curlwp 0xfffff8b686f8a180 pid 0.17 lowest kstack 0xffffac04372f12c0 [ 5235.028358] panic: trap [ 5235.028358] cpu2: Begin traceback... [ 5235.028358] vpanic() at netbsd:vpanic+0x183 [ 5235.028358] panic() at netbsd:panic+0x3c [ 5235.028358] trap() at netbsd:trap+0xbaf [ 5235.028358] --- trap (number 6) --- [ 5235.028358] _atomic_swap_64() at netbsd:_atomic_swap_64+0x3 [ 5235.028358] uvm_km_pgremove_intrsafe() at netbsd:uvm_km_pgremove_intrsafe+0x6d [ 5235.028358] uvm_km_kmem_free() at netbsd:uvm_km_kmem_free+0x3b [ 5235.028358] gc_thread() at netbsd:gc_thread+0x7c [ 5235.028358] cpu2: End traceback... [ 5235.038351] dumping to dev 18,1 (offset=251919, size=4162814): [ 5235.038351] dump Of course, no crash dump was written. I have tried to remove swap in a first time, and system randomly enters in a lock and reboots (maybe with help of watchdog). After rebuild was completed, system seems to be stable. Sorry, I'm unable to obtain more information.Could I ask what controller this was using, and what vintage NetBSD-10 (BETA or RC_1)? There was an issue with the mfi controller which showed up on earlier netbsd-10 BETA versionsYou can ;-) It's a RC_1:OK, so pretty damn recent :-plegendre# uname -a NetBSD legendre.systella.fr 10.0_RC1 NetBSD 10.0_RC1 (CUSTOM) #10: Thu Dec 21 09:51:28 CET 2023 root%legendre.systella.fr@localhost:/usr/src/netbsd-10/obj/sys/arch/amd64/compile/CUSTOM amd64 and tree was updated juste before building system. I have to add that after raid is successfully rebuilt, system is stable. I don't remember last time I have rebuilt this volume.So depending on when it was originally installed (netbsd-8?) it could be possible that whatever issue was present in netbsd-9 also?
Possible. Boot block indicates -8_BETA. But if I remember, this server was installed with Toshiba disks and now, it runs with WD Gold disks as root devices. Thus, I suppose I have rebuilt raid without trouble with a -9.x system.
I only use raidframe on regular sata interface. Motherboard is an Asus Z97Q (if I remember): legendre# lspci | grep SATA 00:1f.2 SATA controller: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode] 08:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9120 SATA 6Gb/s Controller (rev 12) Raid0 and raid1 are connected to 00:1f.2 (wd2 to wd6).OK, so definitely not mfi related... I don't have any directly useful suggestions. Depending on hardware availability and risk of downtime tolerance I'd be tempted to try to reproduce on different hardware - cloning data to another box, or temporarily moving disks across and then triggering a raid rebuild to eliminate any overall issues with the base hardware. Could the power supply be marginal - could rebuilding all disks and some other activity be pushing it a little too hard? Running a few copies of sysutils/cpuburn might flush out some issues if that was the case
I don't think as this server is stable even if CPU usage is around 100%. Now, uptime is greater than 5 days and some bacula processes are spawn at 23h00 daily. When bacula is spawn CPU usage is very high during several hours.
Regards, JB