* [PATCH AUTOSEL 6.7 15/23] ahci: asm1166: correct count of reported ports [not found] <20240202183926.540467-1-sashal@kernel.org> @ 2024-02-02 18:39 ` Sasha Levin 2024-02-02 18:39 ` [PATCH AUTOSEL 6.7 19/23] ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers Sasha Levin 1 sibling, 0 replies; 3+ messages in thread From: Sasha Levin @ 2024-02-02 18:39 UTC (permalink / raw) To: linux-kernel, stable Cc: Conrad Kostecki, Hans de Goede, Niklas Cassel, Sasha Levin, dlemoal, linux-ide From: Conrad Kostecki <conikost@gentoo.org> [ Upstream commit 0077a504e1a4468669fd2e011108db49133db56e ] The ASM1166 SATA host controller always reports wrongly, that it has 32 ports. But in reality, it only has six ports. This seems to be a hardware issue, as all tested ASM1166 SATA host controllers reports such high count of ports. Example output: ahci 0000:09:00.0: AHCI 0001.0301 32 slots 32 ports 6 Gbps 0xffffff3f impl SATA mode. By adjusting the port_map, the count is limited to six ports. New output: ahci 0000:09:00.0: AHCI 0001.0301 32 slots 32 ports 6 Gbps 0x3f impl SATA mode. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=211873 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218346 Signed-off-by: Conrad Kostecki <conikost@gentoo.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/ata/ahci.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 3a5f3255f51b..762c5d8b7c1a 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -663,6 +663,11 @@ MODULE_PARM_DESC(mobile_lpm_policy, "Default LPM policy for mobile chipsets"); static void ahci_pci_save_initial_config(struct pci_dev *pdev, struct ahci_host_priv *hpriv) { + if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA && pdev->device == 0x1166) { + dev_info(&pdev->dev, "ASM1166 has only six ports\n"); + hpriv->saved_port_map = 0x3f; + } + if (pdev->vendor == PCI_VENDOR_ID_JMICRON && pdev->device == 0x2361) { dev_info(&pdev->dev, "JMB361 has only one port\n"); hpriv->saved_port_map = 1; -- 2.43.0 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* [PATCH AUTOSEL 6.7 19/23] ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers [not found] <20240202183926.540467-1-sashal@kernel.org> 2024-02-02 18:39 ` [PATCH AUTOSEL 6.7 15/23] ahci: asm1166: correct count of reported ports Sasha Levin @ 2024-02-02 18:39 ` Sasha Levin 2024-02-22 14:58 ` Niklas Cassel 1 sibling, 1 reply; 3+ messages in thread From: Sasha Levin @ 2024-02-02 18:39 UTC (permalink / raw) To: linux-kernel, stable Cc: Lennert Buytenhek, Niklas Cassel, Sasha Levin, dlemoal, linux-ide From: Lennert Buytenhek <kernel@wantstofly.org> [ Upstream commit 20730e9b277873deeb6637339edcba64468f3da3 ] With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was observed that was immediately preceded by the following kernel messages: ahci 0000:28:00.0: Using 64-bit DMA addresses ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000] ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000] ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000] ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000] ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000] ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000] The first message is produced by code in drivers/iommu/dma-iommu.c which is accompanied by the following comment that seems to apply: /* * Try to use all the 32-bit PCI addresses first. The original SAC vs. * DAC reasoning loses relevance with PCIe, but enough hardware and * firmware bugs are still lurking out there that it's safest not to * venture into the 64-bit space until necessary. * * If your device goes wrong after seeing the notice then likely either * its driver is not setting DMA masks accurately, the hardware has * some inherent bug in handling >32-bit addresses, or not all the * expected address bits are wired up between the device and the IOMMU. */ Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual address 0xffffffff00000000 produces the following I/O page faults: vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010] vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010] Note that the upper 21 bits of the logged DMA address are zero. (When asking a different PCIe device in the same PCIe slot to DMA to the same I/O virtual address, we do see all the upper 32 bits of the DMA address as 1, so this is not an issue with the chipset or IOMMU configuration on the test system.) Also, hacking libahci to always set the upper 21 bits of all DMA addresses to 1 produces no discernible effect on the behavior of the ASM1061, and mkfs/mount/scrub/etc work as without this hack. This all strongly suggests that the ASM1061 has a 43 bit DMA address limit, and this commit therefore adds a quirk to deal with this limit. This issue probably applies to (some of) the other supported ASMedia parts as well, but we limit it to the PCI IDs known to refer to ASM1061 parts, as that's the only part we know for sure to be affected by this issue at this point. Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/ Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org> [cassel: drop date from error messages in commit log] Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/ata/ahci.c | 29 +++++++++++++++++++++++------ drivers/ata/ahci.h | 1 + 2 files changed, 24 insertions(+), 6 deletions(-) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 762c5d8b7c1a..d2460fa985b7 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -48,6 +48,7 @@ enum { enum board_ids { /* board IDs by feature in alphabetical order */ board_ahci, + board_ahci_43bit_dma, board_ahci_ign_iferr, board_ahci_low_power, board_ahci_no_debounce_delay, @@ -128,6 +129,13 @@ static const struct ata_port_info ahci_port_info[] = { .udma_mask = ATA_UDMA6, .port_ops = &ahci_ops, }, + [board_ahci_43bit_dma] = { + AHCI_HFLAGS (AHCI_HFLAG_43BIT_ONLY), + .flags = AHCI_FLAG_COMMON, + .pio_mask = ATA_PIO4, + .udma_mask = ATA_UDMA6, + .port_ops = &ahci_ops, + }, [board_ahci_ign_iferr] = { AHCI_HFLAGS (AHCI_HFLAG_IGN_IRQ_IF_ERR), .flags = AHCI_FLAG_COMMON, @@ -597,11 +605,11 @@ static const struct pci_device_id ahci_pci_tbl[] = { { PCI_VDEVICE(PROMISE, 0x3f20), board_ahci }, /* PDC42819 */ { PCI_VDEVICE(PROMISE, 0x3781), board_ahci }, /* FastTrak TX8660 ahci-mode */ - /* Asmedia */ + /* ASMedia */ { PCI_VDEVICE(ASMEDIA, 0x0601), board_ahci }, /* ASM1060 */ { PCI_VDEVICE(ASMEDIA, 0x0602), board_ahci }, /* ASM1060 */ - { PCI_VDEVICE(ASMEDIA, 0x0611), board_ahci }, /* ASM1061 */ - { PCI_VDEVICE(ASMEDIA, 0x0612), board_ahci }, /* ASM1062 */ + { PCI_VDEVICE(ASMEDIA, 0x0611), board_ahci_43bit_dma }, /* ASM1061 */ + { PCI_VDEVICE(ASMEDIA, 0x0612), board_ahci_43bit_dma }, /* ASM1061/1062 */ { PCI_VDEVICE(ASMEDIA, 0x0621), board_ahci }, /* ASM1061R */ { PCI_VDEVICE(ASMEDIA, 0x0622), board_ahci }, /* ASM1062R */ { PCI_VDEVICE(ASMEDIA, 0x0624), board_ahci }, /* ASM1062+JMB575 */ @@ -954,11 +962,20 @@ static int ahci_pci_device_resume(struct device *dev) #endif /* CONFIG_PM */ -static int ahci_configure_dma_masks(struct pci_dev *pdev, int using_dac) +static int ahci_configure_dma_masks(struct pci_dev *pdev, + struct ahci_host_priv *hpriv) { - const int dma_bits = using_dac ? 64 : 32; + int dma_bits; int rc; + if (hpriv->cap & HOST_CAP_64) { + dma_bits = 64; + if (hpriv->flags & AHCI_HFLAG_43BIT_ONLY) + dma_bits = 43; + } else { + dma_bits = 32; + } + /* * If the device fixup already set the dma_mask to some non-standard * value, don't extend it here. This happens on STA2X11, for example. @@ -1931,7 +1948,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) ahci_gtf_filter_workaround(host); /* initialize adapter */ - rc = ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64); + rc = ahci_configure_dma_masks(pdev, hpriv); if (rc) return rc; diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h index 4bae95b06ae3..df8f8a1a3a34 100644 --- a/drivers/ata/ahci.h +++ b/drivers/ata/ahci.h @@ -247,6 +247,7 @@ enum { AHCI_HFLAG_SUSPEND_PHYS = BIT(26), /* handle PHYs during suspend/resume */ AHCI_HFLAG_NO_SXS = BIT(28), /* SXS not supported */ + AHCI_HFLAG_43BIT_ONLY = BIT(29), /* 43bit DMA addr limit */ /* ap->flags bits */ -- 2.43.0 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH AUTOSEL 6.7 19/23] ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers 2024-02-02 18:39 ` [PATCH AUTOSEL 6.7 19/23] ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers Sasha Levin @ 2024-02-22 14:58 ` Niklas Cassel 0 siblings, 0 replies; 3+ messages in thread From: Niklas Cassel @ 2024-02-22 14:58 UTC (permalink / raw) To: Sasha Levin; +Cc: linux-kernel, stable, Lennert Buytenhek, dlemoal, linux-ide Hello Sasha, On Fri, Feb 02, 2024 at 01:39:15PM -0500, Sasha Levin wrote: > From: Lennert Buytenhek <kernel@wantstofly.org> > > [ Upstream commit 20730e9b277873deeb6637339edcba64468f3da3 ] > > With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an > ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was > observed that was immediately preceded by the following kernel > messages: > > ahci 0000:28:00.0: Using 64-bit DMA addresses > ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000] > ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000] > ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000] > ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000] > ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000] > ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000] > > The first message is produced by code in drivers/iommu/dma-iommu.c > which is accompanied by the following comment that seems to apply: > > /* > * Try to use all the 32-bit PCI addresses first. The original SAC vs. > * DAC reasoning loses relevance with PCIe, but enough hardware and > * firmware bugs are still lurking out there that it's safest not to > * venture into the 64-bit space until necessary. > * > * If your device goes wrong after seeing the notice then likely either > * its driver is not setting DMA masks accurately, the hardware has > * some inherent bug in handling >32-bit addresses, or not all the > * expected address bits are wired up between the device and the IOMMU. > */ > > Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual > address 0xffffffff00000000 produces the following I/O page faults: > > vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010] > vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010] > > Note that the upper 21 bits of the logged DMA address are zero. (When > asking a different PCIe device in the same PCIe slot to DMA to the > same I/O virtual address, we do see all the upper 32 bits of the DMA > address as 1, so this is not an issue with the chipset or IOMMU > configuration on the test system.) > > Also, hacking libahci to always set the upper 21 bits of all DMA > addresses to 1 produces no discernible effect on the behavior of the > ASM1061, and mkfs/mount/scrub/etc work as without this hack. > > This all strongly suggests that the ASM1061 has a 43 bit DMA address > limit, and this commit therefore adds a quirk to deal with this limit. > > This issue probably applies to (some of) the other supported ASMedia > parts as well, but we limit it to the PCI IDs known to refer to > ASM1061 parts, as that's the only part we know for sure to be affected > by this issue at this point. > > Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/ > Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org> > [cassel: drop date from error messages in commit log] > Signed-off-by: Niklas Cassel <cassel@kernel.org> > Signed-off-by: Sasha Levin <sashal@kernel.org> > --- I still don't see this commit in stable/linux-6.7.y branch? Nor in: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git What am I missing? ($subject had this patch marked as AUTOSEL, so I would have assumed that it should have been merged by now, since this was 20 days ago.) This patch in $subject is needed for another follow up patch which failed to be backported because $subject patch is not in stable/linux-6.7.y: https://lore.kernel.org/stable/2024021945-jockey-spending-9e68@gregkh/ (The follup up patch had CC: stable tag, but the patch in $subject unfortunately forgot to add CC: stable tag.) Could you please help to get both: 20730e9b2778 ("ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers") and 51af8f255bda ("ahci: Extend ASM1061 43-bit DMA address quirk to other ASM106x parts") backported to kernel 6.6 and 6.7. No need to backport to older kernels, as this problem was first exposed by: 791c2b17fb40 ("iommu: Optimise PCI SAC address trick") which started to put devices into >4GB DMA address range. Kind regards, Niklas ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-02-22 14:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20240202183926.540467-1-sashal@kernel.org>
2024-02-02 18:39 ` [PATCH AUTOSEL 6.7 15/23] ahci: asm1166: correct count of reported ports Sasha Levin
2024-02-02 18:39 ` [PATCH AUTOSEL 6.7 19/23] ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers Sasha Levin
2024-02-22 14:58 ` Niklas Cassel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).