[alsa-devel] 答复: 答复: 答复: A bug about cache inconsistency report

[Takashi Iwai]

On Wed, 08 Aug 2018 12:44:00 +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?


> > Yes, of course, this path combinations(non-snoop + not-mmap) unlikely be used by most music players.
> >
> > [Hans :] I complete the patch in your last mail like below, not used the vunmap & re-vmap way(it has a little problem). Result is OK now(no noise anymore).
> 
> >What problem did you get with vunmap / vmap?
> 
> [Hans :] if patch like below, even the new vmapped address new_area be assigned to dmab->area, it will not use this time, but next. This time used dmab->area still the last one, but the old one had been vunmap, so Oops reported.

That's bad.  But the problem isn't as you guessed, I guess.
The allocator re-uses the pre-allocated buffer if available, and this
makes things inconsistent.  I'll cook later.


Takashi