lkml.org 
[lkml]   [2007]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
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


\
 
 \ /
  Last update: 2007-12-18 03:53    [W:0.073 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site