Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

[Tejun Heo <htejun@gmail.com>]

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