On 2023-04-25 05:17, Jason Adriaanse wrote:
Ok great,
I take it a change needs to be made in
drivers/pci/quirks.c
?
I do not mind making the change locally here and letting you know if it
works or not.
Indeed, something like this (make sure the IDs actually match what your
device reports, I'm just guessing):
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 44cab813bf95..a9166e886b75 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4161,6 +4161,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9220,
/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c49 */
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9230,
quirk_dma_func1_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9235,
+ quirk_dma_func1_alias);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TTI, 0x0642,
quirk_dma_func1_alias);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TTI, 0x0645,
Marvell themselves seem to lump the 88SE92xx products together as a
closely-related family, so given that we do have quirks for 3 of the 4
already, this one does rather seem conspicuous by its absence...
Thanks,
Robin.
On 24/04/2023 22:07, Robin Murphy wrote:
On 2023-04-24 14:44, Jason Adriaanse wrote:
I took out "iommu=soft" and the server failed to boot, so yes it does
break.
The first error was
ata7.00: Failed to IDENTIFY (INIT_DEV_PARAMS failed , err_mask=0x80)
OK, great, that confirms the underlying issue existed all along, so
the regression is only a change in who wins a fight between certain
conflicting command-line arguments, which is arguably not so critical.
The rest of the evidence points to 88SE9235 wanting the same phantom
function quirk as most other Marvell controllers, since although it's
apparently been half-fixed such that DMA for two of the ports is being
correctly emitted from function 0 - given that you say two of the
disks *are* detected OK - the other two are still claiming to be
function 1 after all.
Thanks,
Robin.
On 24/04/2023 21:20, Robin Murphy wrote:
On 2023-04-22 07:25, Jason Adriaanse wrote:
Hi Christoph,
Sorry for my late reply, I have been on the road.
So, if I boot with
intel_iommu=off
Then the server boots fine..although that is not a solution because
I need Intel iommu for virtualisation.
Also, I build all my kernels with CONFIG_INTEL_IOMMU=y
If you boot 5.15 *without* the "iommu=soft" argument, just
"intel_iommu=on", does that also break?
Robin.
