Fix for HyperSPARC DMA errors

Fix for HyperSPARC DMA errors

[Bob Breuer]

I found a solution for the HyperSPARC DMA problems in 2.6.  This allows
my SS20 with HyperSPARCs to boot to single user.  It's not efficient,
but I hope it points out whats needed for a proper fix.  Seems that the
iotlb entries need to flushed to ram or uncached since the iommu changes
between 2.5.60 and 2.5.70.

The second part seems to be needed to allow consistent sbus dma mappings
to be cached on HyperSPARC.  I have also tested this change on 2.4.27
with no noticeable difference.  Can anyone prove if it helps or hurts?

Bob


--- linux-2.6.9/arch/sparc/mm/iommu.c.orig	2004-10-18 16:55:29.000000000 -0500
+++ linux-2.6.9/arch/sparc/mm/iommu.c	2004-11-07 17:25:24.000000000 -0600
@@ -173,6 +173,7 @@ static u32 iommu_get_one(struct page *pa
  	}

  	iommu_viking_flush_iotlb(iopte0, npages);
+	flush_cache_all(); // hack to fix dma errors with hypersparc

  	return busa0;
  }
--- linux-2.6.9/arch/sparc/mm/srmmu.c.orig	2004-10-18 16:54:32.000000000 -0500
+++ linux-2.6.9/arch/sparc/mm/srmmu.c	2004-11-07 13:15:57.000000000 -0600
@@ -1463,6 +1463,7 @@ static void __init poke_hypersparc(void)
  static void __init init_hypersparc(void)
  {
  	srmmu_name = "ROSS HyperSparc";
+	srmmu_modtype = HyperSparc;

  	init_vac_layout();

Re: Fix for HyperSPARC DMA errors

[William Lee Irwin III]

On Tue, Nov 09, 2004 at 09:18:56PM -0600, Bob Breuer wrote:
> I found a solution for the HyperSPARC DMA problems in 2.6.  This allows
> my SS20 with HyperSPARCs to boot to single user.  It's not efficient,
> but I hope it points out whats needed for a proper fix.  Seems that the
> iotlb entries need to flushed to ram or uncached since the iommu changes
> between 2.5.60 and 2.5.70.
> The second part seems to be needed to allow consistent sbus dma mappings
> to be cached on HyperSPARC.  I have also tested this change on 2.4.27
> with no noticeable difference.  Can anyone prove if it helps or hurts?

I'll take this for a spin on one of my SS20's. I've had no success
debugging this myself, and am astounded at how small your solution is.


-- wli

Re: Fix for HyperSPARC DMA errors

[David S. Miller]

On Tue, 9 Nov 2004 19:30:10 -0800
William Lee Irwin III <wli@holomorphy.com> wrote:

> I'll take this for a spin on one of my SS20's. I've had no success
> debugging this myself, and am astounded at how small your solution is.

In particular, not setting srmmu_modtype is a pretty clear
error :-)

Re: Fix for HyperSPARC DMA errors

[William Lee Irwin III]

On Tue, 9 Nov 2004 19:30:10 -0800 William Lee Irwin III wrote:
>> I'll take this for a spin on one of my SS20's. I've had no success
>> debugging this myself, and am astounded at how small your solution is.

On Tue, Nov 09, 2004 at 08:55:32PM -0800, David S. Miller wrote:
> In particular, not setting srmmu_modtype is a pretty clear
> error :-)

You're right, this wants to be merged soon.

Bob, how do you feel about your arch/sparc/mm/iommu.c flush_cache_all()
hack? Would you prefer to have that in mainline for the time being, or
would you rather wait until you devise a better solution?


-- wli

Re: Fix for HyperSPARC DMA errors

[David S. Miller]

On Tue, 9 Nov 2004 21:23:29 -0800
William Lee Irwin III <wli@holomorphy.com> wrote:

> Bob, how do you feel about your arch/sparc/mm/iommu.c flush_cache_all()
> hack? Would you prefer to have that in mainline for the time being, or
> would you rather wait until you devise a better solution?

I think even this part of Bob's patch should just go in.
At worst it will slow things down for people, and it will
fix real bugs for people.

Re: Fix for HyperSPARC DMA errors

[Bob Breuer]

Should probably test for hypersparc so it doesn't slow down the non-hypersparcs.

BTW, I had tried __flush_page_to_ram as used in iommu_map_dma_area, but that
didn't work.  Might flush_cache_range or something similar work?

David S. Miller wrote:
> On Tue, 9 Nov 2004 21:23:29 -0800
> William Lee Irwin III <wli@holomorphy.com> wrote:
> 
> 
>>Bob, how do you feel about your arch/sparc/mm/iommu.c flush_cache_all()
>>hack? Would you prefer to have that in mainline for the time being, or
>>would you rather wait until you devise a better solution?
> 
> 
> I think even this part of Bob's patch should just go in.
> At worst it will slow things down for people, and it will
> fix real bugs for people.
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>