Xiwai M-Key PCIe SATA JMB585 -> kernel panic

[ilg-ul]

Hi Jeff,

I recently tested in my CM4IO (RPi OS 64-bit) the following SATA board:

• Xiwai NGFF NVME M-Key PCI Express to SATA 3.0 6Gbps 5 Ports Adapter Converter Hard Drive Expansion Card JMB585 2280

The result was a kernel panic :-(

The board is fine, it was recognised by the Debian kernel in another SBC (a ROCK Pi 4a, details below); the PCIe to NVME adapter is also fine, since I used it with a Samsung M.2 SSD for many months without problems.

There are many similar boards with the same JMB585 chip which look more or less identical. I don't know if the problem is caused by the chip itself, or it is specific to this Xiwai board.

Anyway, perhaps it would be useful for your nice site to also list the boards that are known to not work with the CM4IO.

[6by9]

Provide some information about the kernel panic if you want anyone to look into it. Ideally a dump of the panic.
Is it when the card probes, a drive detects, or a drive is accessed?

[6by9]

dmesg for the kernel logs.

[ilg-ul]

AFAIK dmesg shows the messages related to the current boot. Do you know of any command line options to display the messages related to the previous (failed) boot attempt?

[6by9]

There are different levels of panic, so some take the kernel out, whilst others leave the system working.

Best bet is to blacklist the module via /etc/modprobe.d. At a guess it'll be ahci, so a new file with extension .conf in that directory with the content blacklist ahci should do it for you. The system should then boot, and you can load the module manually with sudo modprobe ahci. Run dmesg -w in a different terminal when you do the modprobe, and if you're lucky it'll keep spitting out the logs.

[ilg-ul]

The panic completely hanged the kernel, the system was not usable.

Probably a better way to get the panic log would be with a serial console, but I don't have a free board now for these tests, the CM4IO board is now installed as an openmediavault NAS.

[6by9]

You can try adding dtoverlay=pcie-32bit-dma in /boot/config.txt to force the kernel to use 32bit addresses for all PCIe DMA.
Otherwise I may see if I can pick up one of these boards.

[ilg-ul]

For completeness, in the ROCK Pi 4a, the board was identified as:

01:00.0 SATA controller: JMicron Technology Corp. Device 0585 (prog-if 01 [AHCI 1.0])
	Subsystem: JMicron Technology Corp. Device 0000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 230
	Region 0: I/O ports at 0000
	Region 1: I/O ports at 0000
	Region 2: I/O ports at 0000
	Region 3: I/O ports at 0000
	Region 4: I/O ports at 0000
	Region 5: Memory at fa010000 (32-bit, non-prefetchable) [size=8K]
	Expansion ROM at fa000000 [disabled] [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: ahci

and the Debian kernel reported:

[ 2.140731] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 2.141190] pci 0000:00:00.0: bridge window [mem 0xfa000000-0xfa0fffff]
[ 2.141835] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[ 2.142606] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
[ 2.143225] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[ 2.143801] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded
[ 2.143909] aer 0000:00:00.0:pcie02: service driver aer loaded

[6by9]

It looks like it may be that card rather than chipset as Jeff does have https://pipci.jeffgeerling.com/cards_storage/iocrest-jmb585-m2-sata.html and https://pipci.jeffgeerling.com/cards_storage/iocrest-sata-5-port-jmb585.html listed on the site. That sort of makes it less relevant for me to pick up a random version of that chipset.

[ilg-ul]

It may be the card, I chose it because it has the heatsink and was readily available, but otherwise I have no experience with the manufacturer.