Re: A bug about cache inconsistency report

From: Takashi Iwai <tiwai@suse.de>
To: "Hans Hu(SH-RD)" <HansHu@zhaoxin.com>
Cc: "Tony W. Wang(BJ-RD)" <TonyWWang@zhaoxin.com>,
	"'alsa-devel@alsa-project.org'" <alsa-devel@alsa-project.org>,
	"Tim Guo(BJ-RD)" <TimGuo@zhaoxin.com>,
	"Annie Liu(BJ-RD)" <AnnieLiu@zhaoxin.com>
Subject: Re: A bug about cache inconsistency report
Date: Fri, 10 Aug 2018 17:15:34 +0200	[thread overview]
Message-ID: <s5hy3de1cdl.wl-tiwai@suse.de> (raw)
In-Reply-To: <7724166a600340619f747586b24b1004@zhaoxin.com>

On Wed, 08 Aug 2018 13:07:06 +0200,
Hans Hu(SH-RD) wrote:
> 
> > > > > >Then the next step would be to fake sg-buffer from this
> > > > > >straight buffer.  Revert the above, and modify sgbuf.c to the following:
> > > > > >- Allocate a large continuous buffer
> > > > > >- Assign each page in this large buffer
> > > > >
> > > > > >If this still works, it's not about vmap, but it just means
> > > > > >that the physically ordered pages do matter -- implicitly
> > > > > >showing that the snooping behavior isn't properly turned on / off on the controller.
> > > > >
> > > > > To fake SG-buffer, I did this test: restore all the codes to the original, then added some codes in snd_malloc_sgbuf_pages() like below, the result is badly niose.
> > > >
> > > > >Not really what I meant.  Rather something like below (totally untested).
> > > >
> > > > [Hans :] I know what you mean now and complete code like below, but the result is still noise.
> > >
> > > >OK, so indeed the vmapped address does seem matter.  Interesting.
> > > >What kind of user access does produce the noise?  Does it via aplay mmap mode, too?
> > >
> > > >In anyway, if the vmap is a problem, it might be worked around a patch like below (again totally untested and not sure whether it's correct).
> > >
> > > [Hans :] As I know, In the hardware layer HDAC’s stream have two data transport path : non-snoop & snoop; In the software layer ALSA-Driver have two data transport path : mmap & not mmap(test shows, it is dependent on wav's format or mmap_flag in aplay.c). When hardware at non-snoop mode, without hardware module's help, software must mark the mem to uncacheable type: when mmap used, the mark action happened at pcm_mmap_prepare(), the not-mmap mode's mark action happened at __mark_pages_wc(). And when at not-mmap mode, the vmapped address directly used in snd_pcm_lib_write_transfer() -> copy_from_user().
> >
> >
> > >Well, that's usually no problem regarding that cache coherency.
> > >At least it hasn't been any issue with Intel and AMD CPUs.
> > >Does the problem happen with Intel CPU instead of VIA?
> >
> > [Hans :] I don't have enough Intel/AMD machine here, up to now, only find one Intel's : HW: mother board is Dell 042P49, HDA controller is 8086:1c20, codec is cx20641.
> 
> >And the same issue is seen on that machine?
> 
> [Hans :] Yes

OK, then let's fix it properly.

I managed to add the non-cached type buffer allocations in the
memalloc.c, so that we can reduce lots of codes in each driver side.

The patches are pushed to topic/memalloc-uc branch of my sound git
tree.  Please give it a try and report back whether it works for you.

Since such a change in the core code would affect many drivers, I'll
postpone this for 4.20, in anyway.

thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel