DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=I4e6JbXxsQs3UbTFZbjKqOYy5/BeThkgPuYiS5+7IJDMc4OI0vE1cbi+J/oLcxbLRiloqVx7EeB7zi9z04YOoBP31YPe24iZMWYksyGah/y9YxqM6PC18sazCUykitiB/AUZvba8LTNjuqwtBYfl/yHZ6BBpLirHCoeIyMjIPI0=
Message-ID: <47673593.6040104@gmail.com>
Date: Tue, 18 Dec 2007 11:50:59 +0900
From: Tejun Heo <htejun@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20070801)
MIME-Version: 1.0
To: shyam_iyer@dell.com
CC: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
References: <12954112.1197908230928.JavaMail.root@wombat.diezmil.com>
In-Reply-To: <12954112.1197908230928.JavaMail.root@wombat.diezmil.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1697
Lines: 52

Hello,

shyam_iyer@dell.com wrote:
> --- sata_nv.c.orig	2007-12-17 21:08:12.000000000 +0530
> +++ sata_nv.c	2007-12-17 21:08:25.000000000 +0530
> @@ -2407,6 +2407,12 @@
>  			type = GENERIC;
>  	}
>  
> +	/* set 64bit dma masks, may fail */
> +	if (type == ADMA) {
> +		if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
> +			pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
> +	}
> +
>  	ppi[0] = &nv_port_info[type];
>  	rc = ata_pci_prepare_sff_host(pdev, ppi, &host);
>  	if (rc)
> @@ -2418,12 +2424,6 @@
>  	hpriv->type = type;
>  	host->private_data = hpriv;
>  
> -	/* set 64bit dma masks, may fail */
> -	if (type == ADMA) {
> -		if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
> -			pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
> -	}
> -

This is weird.  IIRC, the problem is caused by allocating consistent
memory for legacy DMA over 32bit limit.  Your patch moves setting 64bit
DMA mask upward but it doesn't affect anything because
ata_pci_prepare_sff_host() and hpriv allocation are not DMA memory
allocations and thus unaffected by DMA mask.

Robert's last patch seems correct to me.  I have no idea why it doesn't
work for you tho.  Another interesting point is that you are reporting
data corruption instead of time out or HSM violation, which indicates
that the PRD table is accessible but what it contains is incorrect.

I guess it's time to print out some memory addresses.  I'll prep a debug
patch soon.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/