Received: by 2002:a05:7412:5112:b0:fa:6e18:a558 with SMTP id fm18csp1219989rdb; Wed, 24 Jan 2024 08:15:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IFNNXxQSCMviexFbxpSblm6DwhvXPvY5BXiM1A/ieG2m3Ml6ZKGcy8qaOiOAR+2DGfbT1oE X-Received: by 2002:a17:90a:8988:b0:28c:9f74:f713 with SMTP id v8-20020a17090a898800b0028c9f74f713mr4940705pjn.58.1706112926542; Wed, 24 Jan 2024 08:15:26 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706112926; cv=pass; d=google.com; s=arc-20160816; b=XKo1aUWsKWXq45GXgzMzRQbpRFPKcW5sJeDALl8S4AO81kcZO4f52ydEi475SuIHIO mIPoFs7NdkCNiGR6vxV1EqjKeurzpghNBmByLmApM1qDpbViTjSmCh01nEp1CFhJ7iYO 6zmdvv+rtYY0o7bdcmOjTKxKPIDRHSWOIFDb81qww+x9Mkqt5xX3tIMkSFgfg64bce1E ytz0xlBgKY0URTRGKJFvtjh2OUAEOalDS39bJ3EWq/k/CoK5cbY6jefCfpdEnR3tiJik Ov7eMj2MW65NfTC4LLgd0ArKkYj8ivLhLrOoKxSDgq67u3y30bv+rpRORxVuC0FuDcg4 6yww== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=QMRD2imd9xgSdnUZOGZDGmqMjpwAbnayjh5egjb5jBs=; fh=Dr70pGEb7mOAT+NPJ3Qf5jfW9FVJR02txKZ51ju5oqI=; b=oY0o3Cjie98sQC0qONO2xkJSbXZIoLXgEoCy61tbx69xDxnipLRo930NO64Z32boQE HzJplH2lFFiVmhKYG6QQi3EbEWjhzMQCSeL3o8G5xFzMZJHHoO2hCsjXuB9ZbLFvd20f bQz5nGZ32P3WmHK8CLyefEc/QZS3Ft/yW37nuRI2X6cUXecbTWtL2Q62AC8xWAlBzs96 YNSmu8RLV+lNsPKB+9xz1/T2yU+xxqengDNYnvQ3+4C9PdY+PiWPgloZ1ztB8DxOnY+A MqSulJTyv91bhfQvQOjMXFQoblDRJ3ebb7PBEYP3rAY+7904VQ2jyVC367hwlTCT+N9X t2nw== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-37314-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-37314-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id jx1-20020a17090b46c100b002900606c264si11829363pjb.27.2024.01.24.08.15.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 08:15:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-37314-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-37314-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-37314-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 352E1289940 for ; Wed, 24 Jan 2024 16:15:26 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 994F77CF1B; Wed, 24 Jan 2024 16:14:49 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 344BF7CF03; Wed, 24 Jan 2024 16:14:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706112889; cv=none; b=D1upao8EZxYybuYv8tuv4fn8b/w6+LTz9+G6MCjulu2P198O0eJOVfEwQOEajafi8PlwbZDa/pCMOXljI+im5vXUdKq7vlf5YUfPBpV2U0brTMU1XGqesIoC/VET5oMD3FJU31scr0pMWG03vJwf5eaUUX0yjoH6XnQ+ImhgXhU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706112889; c=relaxed/simple; bh=q1Hn7Di1un3vGjw/pWuBZtI2ypUfglqG7TORIqEdXJc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=o0MLAzho3nc2mj9tUvhYWFx3mGPPv8JBOKPu2eE/SqV3Trt02/sA/Hmk8r5uifs1kRCRIrx7XOW5pDl5FXhFzc+5ZbADy4r9bd59/LGUXT9WEAZfb3MeipaL+f6TdcxAlV6o6Vo8uLSNOHFANmcuArcfVFHJZT8NCzg1tghu3GU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9D5001FB; Wed, 24 Jan 2024 08:15:31 -0800 (PST) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DB4743F762; Wed, 24 Jan 2024 08:14:45 -0800 (PST) Message-ID: <83a89509-42cb-4915-94dc-a2b9d5a63311@arm.com> Date: Wed, 24 Jan 2024 16:14:37 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ASMedia ASM1062 (AHCI) hang after "ahci 0000:28:00.0: Using 64-bit DMA addresses" Content-Language: en-GB To: Lennert Buytenhek , Niklas Cassel Cc: Niklas Cassel , Damien Le Moal , linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org References: From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 24/01/2024 1:58 pm, Lennert Buytenhek wrote: > On Wed, Jan 24, 2024 at 02:40:51PM +0200, Lennert Buytenhek wrote: > >>>> There are two ways to handle this -- either set the DMA mask for ASM106x >>>> parts to 43 bits, or take the lazy route and just use AHCI_HFLAG_32BIT_ONLY >>>> for these parts. I feel that the former would be more appropriate, as >>>> there seem to be plenty of bits beyond bit 31 that do work, but I will >>>> defer to your judgement on this matter. What do you think the right way >>>> to handle this apparent hardware quirk is? >>> >>> I've seen something similar for NVMe, where some NVMe controllers from >>> Amazon was violating the spec, and only supported 48-bit DMA addresses, >>> even though NVMe spec requires you to support 64-bit DMA addresses, see: >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4bdf260362b3be529d170b04662638fd6dc52241 >>> >>> It is possible that ASMedia ASM1061 has a similar problem (but for AHCI) >>> and only supports 43-bit DMA addresses, even though it sets AHCI CAP.S64A, >>> which says "Indicates whether the HBA can access 64-bit data structures.". >>> >>> I think the best thing is to do a similar quirk, where we set the dma_mask >>> accordingly. >> >> I'll give that a try. > > I've sent out a patch that appears (from printk debugging) to do the > right thing, but I haven't validated that that patch fixes the original > issue, as the original issue is not trivial to trigger, and the hardware > that it triggered on is currently unavailable. The missing piece of the puzzle is that *something* has to use up all the available 32-bit IOVA space to make you spill over into the 64-bit space to begin with. It can happen just from having many large buffers mapped simultaneously (particularly if there are several devices in the same IOMMU group), or it could be that something is leaking DMA mappings over time. An easy way to confirm the device behaviour should be to boot with "iommu.forcedac=1", then all devices will have their full DMA mask exercised straight away. Cheers, Robin. > I've also made the quirk apply to all ASMedia ASM106x parts, because I > expect them to be affected by the same issue, but let's see what the > ASMedia folks have to say about that. > > Thanks for your help! > > > Kind regards, > Lennert >