Loading pata_marvell module will crash the kernel when there is an error reading an attached SATA drive

Loading pata_marvell module will crash the kernel when there is an error reading an attached SATA drive

[James Feeney]

Arch Linux
linux 6.0.7.arch1-1
ASUSTeK P6T DELUXE V2

00:1c.4 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express
Root Port 5
        Subsystem: ASUSTeK Computer Inc. P6T Deluxe Motherboard
        Kernel driver in use: pcieport

05:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6111/6121 SATA
II / PATA Controller (rev b2)
        Subsystem: ASUSTeK Computer Inc. Device 8212
        Kernel modules: pata_marvell, pata_acpi, ata_generic

ahci driver built into kernel, but with *no* kernel command line "ahci.marvell_enable=1"


Attaching an external SATA drive, manually loading the pata_marvell module, and then failing to read the drive, the kernel will lock-up, requiring a system reboot.  The read error appears to be triggered by a too long eSATA cable, since a shorter eSATA cable resolves the problem.

Alternatively, using the ahci driver instead, under the same error condition, the ahci driver simply gives-up and does not crash the kernel.

This is an obscure condition in very old hardware, but maybe somebody could take a look at pata_marvell.c.  The pata_marvell driver and the ahci driver respond to the error very differently - crashing the kernel or not crashing the kernel.

Loading pata_marvell, ending with a kernel lock-up, the log has:

 scsi host6: pata_marvell
 scsi host7: pata_marvell
 ata7: PATA max UDMA/100 cmd 0xcc00 ctl 0xc880 bmdma 0xc400 irq 16
 ata8: PATA max UDMA/133 cmd 0xc800 ctl 0xc480 bmdma 0xc408 irq 16
 ata8.00: qc timeout (cmd 0xec)
 ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4)
 ata8: link is slow to respond, please be patient (ready=0)
 ata8: device not ready (errno=-16), forcing hardreset
 ata8.00: ATA-9: WDC WD10JUCT-63CYNY0, 01.01A01, max UDMA/133
 ata8.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 0/32)
 ata8.00: qc timeout (cmd 0xec)
 ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4)
 ata8.00: revalidation failed (errno=-5)
 ata8.00: limiting speed to UDMA/133:PIO3
 ata8: link is slow to respond, please be patient (ready=0)
 ata8: device not ready (errno=-16), forcing hardreset
 scsi 7:0:0:0: Direct-Access     ATA      WDC WD10JUCT-63C 1A01 PQ: 0 ANSI: 5
 sd 7:0:0:0: Attached scsi generic sg4 type 0
 sd 7:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
 [kernel lock-up here]


Instead, manually loading pata_marvell, with the shorter eSATA cable, and *no* kernel lock-up, the log has:

 scsi host6: pata_marvell
 scsi host7: pata_marvell
 ata7: PATA max UDMA/100 cmd 0xcc00 ctl 0xc880 bmdma 0xc400 irq 16
 ata8: PATA max UDMA/133 cmd 0xc800 ctl 0xc480 bmdma 0xc408 irq 16
 ata8.00: ATA-9: WDC WD10JUCT-63CYNY0, 01.01A01, max UDMA/133
 ata8.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 0/32)
 scsi 7:0:0:0: Direct-Access     ATA      WDC WD10JUCT-63C 1A01 PQ: 0 ANSI: 5
 sd 7:0:0:0: Attached scsi generic sg4 type 0
 sd 7:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
 sd 7:0:0:0: [sdd] 4096-byte physical blocks
 sd 7:0:0:0: [sdd] Write Protect is off
 sd 7:0:0:0: [sdd] Mode Sense: 00 3a 00 00
 sd 7:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sd 7:0:0:0: [sdd] Preferred minimum I/O size 4096 bytes


In comparison, using the ahci driver with "ahci.marvell_enable=1", and with the same drive read error, the log has:

 ahci 0000:05:00.0: Disabling your PATA port. Use the boot option 'ahci.marvell_enable=0' to avoid this.
 ahci 0000:05:00.0: controller can't do NCQ, turning off CAP_NCQ
 ahci 0000:05:00.0: controller can't do PMP, turning off CAP_PMP
 ahci 0000:05:00.0: masking port_map 0x7 -> 0x3
 ahci 0000:05:00.0: SSS flag set, parallel bus scan disabled
 ahci 0000:05:00.0: AHCI 0001.0000 32 slots 3 ports 3 Gbps 0x3 impl IDE mode
 ahci 0000:05:00.0: flags: 64bit stag led slum part
 scsi host6: ahci
 scsi host7: ahci
 scsi host8: ahci
 ata7: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffd00 irq 16
 ata8: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffd80 irq 16
 ata9: DUMMY
 ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
 ata7.00: qc timeout (cmd 0xec)
 ata7.00: failed to IDENTIFY (I/O error, err_mask=0x4)
 ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
 ata7.00: qc timeout (cmd 0xec)
 ata7.00: failed to IDENTIFY (I/O error, err_mask=0x4)
 ata7: limiting SATA link speed to 1.5 Gbps
 ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata7.00: qc timeout (cmd 0xec)
 ata7.00: failed to IDENTIFY (I/O error, err_mask=0x4)
 ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata8: SATA link down (SStatus 0 SControl 300)
 ata7: SATA link down (SStatus 0 SControl 300)


The ahci driver simply gives-up, and there is no kernel lock-up.  But also, here, the ahci driver never actually is able to identify the hard drive, and so, never has to subsequently interact with the drive using a bad connection.

Does the pata_marvell module simply "block" forever, after partly identifying the hard drive, and lock-up the kernel in the process?

James