Hello,
[email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
