We recently had a failing NVMe that also just reset the host one night. I put that exact drive (because of ZFS checksum errors and a suspected failure) into another host to collect some data for RMA and directly observed a reset of that host after which the drive was finally completely dead.
A SWAP provider disappearing may also cause a hard crash, especially if SWAP was not mirrored.
Unmirrored swap disappearing result in hard hangs while the kernel waits for the device to reappear. This makes sense. But a crash (kernel panic, without a register dump) is due to a kernel bug where the developer did not anticipate an error condition, like derefrencing freed or non-existent virtual memory.
I've seen on my systems where a disk failure of half a gmirrored pair will hard hang the machine. This is because the disk locked the SATA bus resulting in no access to any SATA disk. I've seen this before with SCSI disks back in the day too, on FreeBSD and Sparc Solaris, where a faulty SCSI CDROM device locked up the SCSI controller of a Sun 2000, that the machine just froze. These are not panics or crashes. They are hard hangs caused by faulty hardware, and they affect any O/S.
BTW, disconnecting the faulty scsi CDROM device from the bus resolved the Sun 2000 problem.
We tend to use the term system crash imprecisely. The term was first used in the mainframe days. There was no such thing as panic() on the mainframe, it simply either re-IPLed (rebooted) or went into a hard spin loop with interrupts disabled (hard hang). Which is a good segue into what a hard hang is.
A hard hang is when the O/S has disabled interrupts while in critical sections of code in the kernel. Then something unexpected (not expected by the developer) happens. The system may go into a hard loop with no ability to recover because it cannot be interrupted by an device (like disk or keyboard keystroke), like happens when drm-51[05]-kmod suffers a buffer overflow. You will notice the fan on the machine speed up, the keyboard is unresponsive, and you're left with one option: to power cycle the laptop. In this case, interrupts are disabled and the machine is in a hard spin loop, probably a deadlock or lock order reversal -- these bugs can happen to any O/S. The only option is to press the reset switch or power button.
The reason these bugs are so difficult to track down is because after the reset switch or power button is pressed, all diagnostic information in memory is lost. (On the mainframe we had a stand alone dump O/S which we would boot using a reserved area of memory not used by the O/S for that purpose. It would dump all memory and swap allowing one to do post-mortem analysis. Not so on any other O/S today.)
Hard hangs and crashes (panics) are different.
BTW, on Intel, only the NMI, non-maskable interrupt, cannot be disabled. NMI is triggered when there is a RAM fault, and some third-party diagnostic cards use it to invoke a debug mode in drivers that support this function. The reset switch briefly cuts power on some MBs or simply resets the keyboard controller on the MB which in turn resets the rest of the MB. This clears RAM as if the machine was power cycled.
Sorry for taking this in a tangential direction. I wanted to differentiate between a crash (panic) and a hard hang.
