Or i hardware bug :)

So we can rule out sharing of same channels.

I was looking on your ranger'screenshots and remarked that we've got the same hardware MAC address!
Should not it be different?
It also differs from the Firmware value of ETH0_HWADDR Env var.

But i wrote ...

I created a 'fake' SM502 driver based on linux code (not released as it was proof-of-concept) so you could do that, however the route I was looking at for a VirtioGPU driver was to have it loaded by PCIGraphics.card via SetMethod hooks to give Workbench full RTG support on the VirtIO GPU. It uses a VirtIOGPUBoard NT_RESOURCE resident that runs before graphics.library to hook PCIGraphics.card's FindCard/InitBoard methods. I may pick it up again in the future.

The priority of your interrupt handler is just for multiple handlers among same hw irq. Hw pri is still the same whatever it is. You can set it to max. possible values, but interrupts which have higher hardware priority are not affected.

So even with the test results it's probably still not 100% sure, that it isn't "simply" some (high pri) interrupt handler being stuck in a loop or that's there endless interrupt flood.

Soft-int with maximum priority died.

Interrupts with maximum priority died.

I only know DMA on Sam460EX and A1222 that I had experience emulating but X1000 probably works the same. AmigaOS uses the DMA engine for blitter ops or memory moves and this seems to be coordinated by dma.resource. The Sam460ex is simple as it has only one DMA channel but on A1222 I noticed not all channels are used. Then I was told some channels may be reserved for audio or network that's why not all channels are claimed by dma.resource. If the driver goes through dma.resource to alloc a channel then you could make sure nothing else will use that. Otherwise you may need to use the channel reserved for it but I don't know which is that or is there any. The author of the dma.resource for the X1000 should be able to tell. If you pick a channel that dma.resource can also use then it could be the kernel would also try to use that and break your settings.

Replacing it with a custom one is possible, but can't help.

4) Using the unused X1000/X5000 co-processor "Xena" could help.
Even if the main CPU is stuck this chip could still do something.
I don't know anything at all about it, but I read something on this forum about someone using it for debugging.

5) PerformanceMonitor.resource, if implemented in the X1000 kernel.

Not all kernels support it. Very low level and high priority, may still work even if interrupt handlers don't work anymore or are stuck in an endless loop, or if the OS is killed by something like IExec->Disable(); while(1);

Next things about which i may think for now:

[...]
3). Buy JTAG, and check the state when CPU died..

Make sure you check the right bit for MSR[ME] as PPC docs count bits from the other end than everybody else normally does.

Dump of context at 0x12345678
Trap type: Machine check exception
...

If I understand correctly, the main difference between AOS4 and ASO4FE (PPC) is the new graphics.library API.

The old P96 drivers are unable to load during system boot.

It uses a VirtIOGPUBoard NT_RESOURCE resident that runs before graphics.library to hook PCIGraphics.card's FindCard/InitBoard methods.

It is not helped by that the graphics driver API of AmigaOS 4 is not public but maybe it's similar to the P96 API so you could start from there but there could be differences.

If you ask me I'd trash most of this code and start by patching PCIGraphics.card to load a virtio-vga.chip driver for the PCI IDs of the virtio card

The code as generated by AI does not seem to do any of that