All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: A bug about cache inconsistency report
@ 2018-08-02  8:22 Hans Hu(SH-RD)
  2018-08-02  8:50 ` Takashi Iwai
  0 siblings, 1 reply; 15+ messages in thread
From: Hans Hu(SH-RD) @ 2018-08-02  8:22 UTC (permalink / raw)
  To: 'Takashi Iwai'; +Cc: 'alsa-devel@alsa-project.org'

1. noise relate test:
8086:1C20   noise ;
8086:A170   ok;
8086:8D20   ok;
Seems this issue related to the HDA Card version

2. change *_SG relate test:
Both above platform report Oops

Thanks
Hans

-----邮件原件-----
发件人: Takashi Iwai [mailto:tiwai@suse.de]
发送时间: 01 August 2018 12:45
收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
主题: Re: [alsa-devel] A bug about cache inconsistency report

On Wed, 01 Aug 2018 04:05:18 +0200,
Hans Hu(SH-RD) wrote:
>
> I did more test base on different Intel platform, and result is the same.

Which platform did you test exactly?

> Maybe I made some mistake? Can you do the test in yours  platform?

The negative test result implies that the analysis isn't right.
Actually I haven't seen that problem on my test machines.

BTW, please avoid top-posting.


thanks,

Takashi

>
> Thank you!
> Hans
>
> -----邮件原件-----
> 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> 发送时间: 31 July 2018 21:55
> 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> 主题: Re: 答复: [alsa-devel] A bug about cache inconsistency report
>
> On Tue, 31 Jul 2018 15:51:06 +0200,
> Hans Hu(SH-RD) wrote:
> >
> > I did the test and Oops report when install driver( both snoop and
> > non-snoop mode)
>
> I don't understand.  Did my one-liner change the behavior or not?
>
>
> thanks,
>
> Takashi
>
> >
> > -----邮件原件-----
> > 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> > 发送时间: 31 July 2018 19:59
> > 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> > 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> > 主题: Re: [alsa-devel] A bug about cache inconsistency report
> >
> > On Tue, 31 Jul 2018 12:52:04 +0200,
> > Hans Hu(SH-RD) wrote:
> > >
> > > Hi All,
> > >
> > >                Try send an email.
> > >
> > >                Appearance:
> > > when use non-snoop + ioctl path combination, an issue occurs:
> > > usage: aplay -D plughw:0,0 44100_S16_LE_2c.wav Ubuntu, it
> > > performance intermittently noise;
> > >
> > > Root case:
> > >                Function set_pages_array_wc marked the PTE of the original address; Function set_memory_wc marked the PTE both original and after vmaped address.
> > > [cid:image002.png@01D428FF.92621520]
> > > However, cache or not in transmission process is based on the PTE of the later, and the set_pages_array_wc did't mark it, so a cache inconsistency issue occurs.
> > >
> > >                Related bug:
> > >                SHA1 ID: 9ddf1aeb2134e72275c97a2c6ff2e3eb04f2f27a
> >
> > OK, so did you confirm that dropping the SG buffer support "fixes" the noise problem on your system?  The easiest test would be like:
> >
> > --- a/sound/pci/hda/hda_controller.c
> > +++ b/sound/pci/hda/hda_controller.c
> > @@ -770,7 +770,7 @@ int snd_hda_attach_pcm_stream(struct hda_bus
> > *_bus, struct hda_codec *codec,  size = CONFIG_SND_HDA_PREALLOC_SIZE
> > * 1024;  if (size > MAX_PREALLOC_SIZE)  size = MAX_PREALLOC_SIZE;
> > -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
> > +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
> >        chip->card->dev,
> >        size, MAX_PREALLOC_SIZE);
> >  return 0;
> >
> >
> > thanks,
> >
> > Takashi
> >
> >
> > 保密声明:
> > 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> > CONFIDENTIAL NOTE:
> > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
>
>
> 保密声明:
> 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.


保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: A bug about cache inconsistency report
  2018-08-02  8:22 A bug about cache inconsistency report Hans Hu(SH-RD)
@ 2018-08-02  8:50 ` Takashi Iwai
  2018-08-02 10:56   ` 答复: " Hans Hu(SH-RD)
  0 siblings, 1 reply; 15+ messages in thread
From: Takashi Iwai @ 2018-08-02  8:50 UTC (permalink / raw)
  To: Hans Hu(SH-RD); +Cc: 'alsa-devel@alsa-project.org'

On Thu, 02 Aug 2018 10:22:29 +0200,
Hans Hu(SH-RD) wrote:
> 
> 1. noise relate test:
> 8086:1C20   noise ;
> 8086:A170   ok;
> 8086:8D20   ok;
> Seems this issue related to the HDA Card version

If so, it's not about the HD-audio controller.
Rather it may come from the codec or its setup.

> 2. change *_SG relate test:
> Both above platform report Oops

What did you change exactly and what Oops did you get?
Too little information for a proper analysis...


Takashi

> 
> Thanks
> Hans
> 
> -----邮件原件-----
> 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> 发送时间: 01 August 2018 12:45
> 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> 主题: Re: [alsa-devel] A bug about cache inconsistency report
> 
> On Wed, 01 Aug 2018 04:05:18 +0200,
> Hans Hu(SH-RD) wrote:
> >
> > I did more test base on different Intel platform, and result is the same.
> 
> Which platform did you test exactly?
> 
> > Maybe I made some mistake? Can you do the test in yours  platform?
> 
> The negative test result implies that the analysis isn't right.
> Actually I haven't seen that problem on my test machines.
> 
> BTW, please avoid top-posting.
> 
> 
> thanks,
> 
> Takashi
> 
> >
> > Thank you!
> > Hans
> >
> > -----邮件原件-----
> > 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> > 发送时间: 31 July 2018 21:55
> > 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> > 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> > 主题: Re: 答复: [alsa-devel] A bug about cache inconsistency report
> >
> > On Tue, 31 Jul 2018 15:51:06 +0200,
> > Hans Hu(SH-RD) wrote:
> > >
> > > I did the test and Oops report when install driver( both snoop and
> > > non-snoop mode)
> >
> > I don't understand.  Did my one-liner change the behavior or not?
> >
> >
> > thanks,
> >
> > Takashi
> >
> > >
> > > -----邮件原件-----
> > > 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> > > 发送时间: 31 July 2018 19:59
> > > 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> > > 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> > > 主题: Re: [alsa-devel] A bug about cache inconsistency report
> > >
> > > On Tue, 31 Jul 2018 12:52:04 +0200,
> > > Hans Hu(SH-RD) wrote:
> > > >
> > > > Hi All,
> > > >
> > > >                Try send an email.
> > > >
> > > >                Appearance:
> > > > when use non-snoop + ioctl path combination, an issue occurs:
> > > > usage: aplay -D plughw:0,0 44100_S16_LE_2c.wav Ubuntu, it
> > > > performance intermittently noise;
> > > >
> > > > Root case:
> > > >                Function set_pages_array_wc marked the PTE of the original address; Function set_memory_wc marked the PTE both original and after vmaped address.
> > > > [cid:image002.png@01D428FF.92621520]
> > > > However, cache or not in transmission process is based on the PTE of the later, and the set_pages_array_wc did't mark it, so a cache inconsistency issue occurs.
> > > >
> > > >                Related bug:
> > > >                SHA1 ID: 9ddf1aeb2134e72275c97a2c6ff2e3eb04f2f27a
> > >
> > > OK, so did you confirm that dropping the SG buffer support "fixes" the noise problem on your system?  The easiest test would be like:
> > >
> > > --- a/sound/pci/hda/hda_controller.c
> > > +++ b/sound/pci/hda/hda_controller.c
> > > @@ -770,7 +770,7 @@ int snd_hda_attach_pcm_stream(struct hda_bus
> > > *_bus, struct hda_codec *codec,  size = CONFIG_SND_HDA_PREALLOC_SIZE
> > > * 1024;  if (size > MAX_PREALLOC_SIZE)  size = MAX_PREALLOC_SIZE;
> > > -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
> > > +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
> > >        chip->card->dev,
> > >        size, MAX_PREALLOC_SIZE);
> > >  return 0;
> > >
> > >
> > > thanks,
> > >
> > > Takashi
> > >
> > >
> > > 保密声明:
> > > 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> > > CONFIDENTIAL NOTE:
> > > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
> >
> >
> > 保密声明:
> > 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> > CONFIDENTIAL NOTE:
> > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
> 
> 
> 保密声明:
> 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* 答复:  A bug about cache inconsistency report
  2018-08-02  8:50 ` Takashi Iwai
@ 2018-08-02 10:56   ` Hans Hu(SH-RD)
  2018-08-02 11:52     ` Takashi Iwai
  0 siblings, 1 reply; 15+ messages in thread
From: Hans Hu(SH-RD) @ 2018-08-02 10:56 UTC (permalink / raw)
  To: 'Takashi Iwai'; +Cc: 'alsa-devel@alsa-project.org'

1. noise relate test:
When I annotate the return after set_pages_array_wc, then set_memory_wc works, noise disappear
static void __mark_pages_wc(struct azx *chip, struct snd_dma_buffer *dmab, bool on)
{
...
set_pages_array_wb(sgbuf->page_table, sgbuf->pages);
//return;
}
#endif
...
}

2. change *_SG relate test:
Just followed your proposal
-snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
+snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,

Oops details:  ubuntu16.04, kernel = 4.8.1, 8086:8D20
[  239.287557] snd_hda_codec_realtek hdaudioC0D0: ALC1150: SKU not ready 0x00000000
[  239.288057] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC1150: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line
[  239.288058] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[  239.288058] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
[  239.288059] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[  239.288060] snd_hda_codec_realtek hdaudioC0D0:    dig-out=0x11/0x1e
[  239.288060] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[  239.288062] snd_hda_codec_realtek hdaudioC0D0:      Front Mic=0x19
[  239.288062] snd_hda_codec_realtek hdaudioC0D0:      Rear Mic=0x18
[  239.288063] snd_hda_codec_realtek hdaudioC0D0:      Line=0x1a
[  239.299500] input: HDA Intel PCH Front Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input19
[  239.299542] input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input20
[  239.299618] input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1b.0/sound/card0/input21
[  239.299675] input: HDA Intel PCH Line Out Front as /devices/pci0000:00/0000:00:1b.0/sound/card0/input22
[  239.299729] input: HDA Intel PCH Line Out Surround as /devices/pci0000:00/0000:00:1b.0/sound/card0/input23
[  239.299798] input: HDA Intel PCH Line Out CLFE as /devices/pci0000:00/0000:00:1b.0/sound/card0/input24
[  239.300010] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input25
[  239.485322] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[  239.485326] IP: [<ffffffffc0496629>] setup_bdle.isra.4+0x79/0x120 [snd_hda_core]
[  239.485334] PGD fd7a92067 PUD fbb54a067 PMD 0
[  239.485336] Oops: 0000 [#1] SMP
[  239.485339] Modules linked in: snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel(E) snd_hda_codec(E) snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore ccm arc4 mt7601u mac80211 cfg80211 joydev input_leds hid_generic uas usbhid usb_storage hid nls_iso8859_1 eeepc_wmi intel_rapl asus_wmi sparse_keymap video edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw glue_helper mei_me ablk_helper cryptd mei intel_cstate intel_rapl_perf shpchp serio_raw lpc_ich mac_hid parport_pc ppdev lp parport autofs4 psmouse e1000e mxm_wmi r8169 ahci ptp libahci pps_core mii fjes wmi [last unloaded: soundcore]
[  239.485365] CPU: 3 PID: 13872 Comm: pulseaudio Tainted: G            E   4.8.1 #2
[  239.485366] Hardware name: ASUS All Series/SABERTOOTH X99, BIOS 3402 08/18/2016
[  239.485367] task: ffff8f9db7bbd700 task.stack: ffff8f9dc7e7c000
[  239.485368] RIP: 0010:[<ffffffffc0496629>]  [<ffffffffc0496629>] setup_bdle.isra.4+0x79/0x120 [snd_hda_core]
[  239.485371] RSP: 0018:ffff8f9dc7e7fc00  EFLAGS: 00010246
[  239.485372] RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000000
[  239.485373] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8f9dc09c44f0
[  239.485374] RBP: ffff8f9dc7e7fc50 R08: 0000000000000000 R09: 0000000000000004
[  239.485375] R10: 0000000000000005 R11: ffff8f9db6c19b80 R12: ffff8f9dcd25004c
[  239.485375] R13: ffff8f9dc09c44f0 R14: ffff8f9dd7acc000 R15: 0000000000000000
[  239.485377] FS:  00007fa88e446880(0000) GS:ffff8f9e3fcc0000(0000) knlGS:0000000000000000
[  239.485378] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  239.485378] CR2: 0000000000000010 CR3: 0000000fb6d00000 CR4: 00000000003406e0
[  239.485379] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  239.485380] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  239.485381] Stack:
[  239.485382]  ffff8f9dc7e7fc88 0000ac44c7e7fc01 fffffff00000ac44 ffff8f9df7303000
[  239.485383]  00000000baaaef4e ffff8f9dc09c3000 0000000000001138 ffff8f9df7303000
[  239.485385]  ffff8f9dcd250000 ffff8f9dc09c4400 ffff8f9dc7e7fcc0 ffffffffc04968f0
[  239.485387] Call Trace:
[  239.485390]  [<ffffffffc04968f0>] snd_hdac_stream_setup_periods+0x220/0x240 [snd_hda_core]
[  239.485395]  [<ffffffffbaaa485a>] ? notifier_call_chain+0x4a/0x70
[  239.485398]  [<ffffffffc049698f>] snd_hdac_stream_set_params+0x7f/0xc0 [snd_hda_core]
[  239.485405]  [<ffffffffc04b27cc>] azx_pcm_prepare+0xcc/0x1d0 [snd_hda_codec]
[  239.485412]  [<ffffffffc0280817>] snd_pcm_do_prepare+0x17/0x30 [snd_pcm]
[  239.485415]  [<ffffffffc028047f>] snd_pcm_action_single+0x2f/0x70 [snd_pcm]
[  239.485417]  [<ffffffffc0280528>] snd_pcm_action_nonatomic+0x68/0x70 [snd_pcm]
[  239.485420]  [<ffffffffc0283694>] snd_pcm_common_ioctl1+0x784/0xc20 [snd_pcm]
[  239.485423]  [<ffffffffbac54136>] ? __mnt_want_write+0x56/0x60
[  239.485426]  [<ffffffffbac4e2b9>] ? file_update_time+0xc9/0x110
[  239.485428]  [<ffffffffc0283f06>] snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
[  239.485431]  [<ffffffffc02840c8>] snd_pcm_capture_ioctl+0x28/0x40 [snd_pcm]
[  239.485433]  [<ffffffffbac45cb1>] do_vfs_ioctl+0xa1/0x5e0
[  239.485436]  [<ffffffffbaa6b2b2>] ? __do_page_fault+0x202/0x4d0
[  239.485438]  [<ffffffffbac46269>] SyS_ioctl+0x79/0x90
[  239.485441]  [<ffffffffbb279176>] entry_SYSCALL_64_fastpath+0x1e/0xa8
[  239.485442] Code: ff 00 00 00 0f 87 ab 00 00 00 49 8b 55 28 49 63 c7 44 89 f9 48 c1 e8 0c 81 e1 ff 0f 00 00 4c 89 ef 48 c1 e0 04 44 89 fe 89 4d d4 <48> 03 42 10 48 63 d1 48 8b 40 08 48 25 00 f0 ff ff 48 01 d0 89
[  239.485459] RIP  [<ffffffffc0496629>] setup_bdle.isra.4+0x79/0x120 [snd_hda_core]
[  239.485462]  RSP <ffff8f9dc7e7fc00>
[  239.485463] CR2: 0000000000000010
[  239.485464] ---[ end trace 1fc145537f028cee ]---

-----邮件原件-----
发件人: Takashi Iwai [mailto:tiwai@suse.de]
发送时间: 02 August 2018 16:50
收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
主题: Re: [alsa-devel] A bug about cache inconsistency report

On Thu, 02 Aug 2018 10:22:29 +0200,
Hans Hu(SH-RD) wrote:
>
> 1. noise relate test:
> 8086:1C20   noise ;
> 8086:A170   ok;
> 8086:8D20   ok;
> Seems this issue related to the HDA Card version

If so, it's not about the HD-audio controller.
Rather it may come from the codec or its setup.

> 2. change *_SG relate test:
> Both above platform report Oops

What did you change exactly and what Oops did you get?
Too little information for a proper analysis...


Takashi

>
> Thanks
> Hans
>
> -----邮件原件-----
> 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> 发送时间: 01 August 2018 12:45
> 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> 主题: Re: [alsa-devel] A bug about cache inconsistency report
>
> On Wed, 01 Aug 2018 04:05:18 +0200,
> Hans Hu(SH-RD) wrote:
> >
> > I did more test base on different Intel platform, and result is the same.
>
> Which platform did you test exactly?
>
> > Maybe I made some mistake? Can you do the test in yours  platform?
>
> The negative test result implies that the analysis isn't right.
> Actually I haven't seen that problem on my test machines.
>
> BTW, please avoid top-posting.
>
>
> thanks,
>
> Takashi
>
> >
> > Thank you!
> > Hans
> >
> > -----邮件原件-----
> > 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> > 发送时间: 31 July 2018 21:55
> > 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> > 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> > 主题: Re: 答复: [alsa-devel] A bug about cache inconsistency report
> >
> > On Tue, 31 Jul 2018 15:51:06 +0200,
> > Hans Hu(SH-RD) wrote:
> > >
> > > I did the test and Oops report when install driver( both snoop and
> > > non-snoop mode)
> >
> > I don't understand.  Did my one-liner change the behavior or not?
> >
> >
> > thanks,
> >
> > Takashi
> >
> > >
> > > -----邮件原件-----
> > > 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> > > 发送时间: 31 July 2018 19:59
> > > 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> > > 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> > > 主题: Re: [alsa-devel] A bug about cache inconsistency report
> > >
> > > On Tue, 31 Jul 2018 12:52:04 +0200, Hans Hu(SH-RD) wrote:
> > > >
> > > > Hi All,
> > > >
> > > >                Try send an email.
> > > >
> > > >                Appearance:
> > > > when use non-snoop + ioctl path combination, an issue occurs:
> > > > usage: aplay -D plughw:0,0 44100_S16_LE_2c.wav Ubuntu, it
> > > > performance intermittently noise;
> > > >
> > > > Root case:
> > > >                Function set_pages_array_wc marked the PTE of the original address; Function set_memory_wc marked the PTE both original and after vmaped address.
> > > > [cid:image002.png@01D428FF.92621520]
> > > > However, cache or not in transmission process is based on the PTE of the later, and the set_pages_array_wc did't mark it, so a cache inconsistency issue occurs.
> > > >
> > > >                Related bug:
> > > >                SHA1 ID: 9ddf1aeb2134e72275c97a2c6ff2e3eb04f2f27a
> > >
> > > OK, so did you confirm that dropping the SG buffer support "fixes" the noise problem on your system?  The easiest test would be like:
> > >
> > > --- a/sound/pci/hda/hda_controller.c
> > > +++ b/sound/pci/hda/hda_controller.c
> > > @@ -770,7 +770,7 @@ int snd_hda_attach_pcm_stream(struct hda_bus
> > > *_bus, struct hda_codec *codec,  size =
> > > CONFIG_SND_HDA_PREALLOC_SIZE
> > > * 1024;  if (size > MAX_PREALLOC_SIZE)  size = MAX_PREALLOC_SIZE;
> > > -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
> > > +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
> > >        chip->card->dev,
> > >        size, MAX_PREALLOC_SIZE);
> > >  return 0;
> > >
> > >
> > > thanks,
> > >
> > > Takashi
> > >
> > >
> > > 保密声明:
> > > 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> > > CONFIDENTIAL NOTE:
> > > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
> >
> >
> > 保密声明:
> > 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> > CONFIDENTIAL NOTE:
> > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
>
>
> 保密声明:
> 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.


保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 答复:  A bug about cache inconsistency report
  2018-08-02 10:56   ` 答复: " Hans Hu(SH-RD)
@ 2018-08-02 11:52     ` Takashi Iwai
       [not found]       ` <fd1d78d3a46845f2867fbc79deabe066@zhaoxin.com>
  0 siblings, 1 reply; 15+ messages in thread
From: Takashi Iwai @ 2018-08-02 11:52 UTC (permalink / raw)
  To: Hans Hu(SH-RD); +Cc: 'alsa-devel@alsa-project.org'

On Thu, 02 Aug 2018 12:56:30 +0200,
Hans Hu(SH-RD) wrote:
> 
> 1. noise relate test:
> When I annotate the return after set_pages_array_wc, then set_memory_wc works, noise disappear
> static void __mark_pages_wc(struct azx *chip, struct snd_dma_buffer *dmab, bool on)
> {
> ...
> set_pages_array_wb(sgbuf->page_table, sgbuf->pages);
> //return;
> }
> #endif

set_memory_uc() performs __pa() for the given address, and in this
case, it's vmapped address.  Something bogus in your test, I'm
afraid.

And moreover, all Intel chipsets do work with snooping well, AFAIK.


> }
> 
> 2. change *_SG relate test:
> Just followed your proposal
> -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
> +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,

OK, you need one more oneliner:

diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
index a12e594d4e3b..2eaed4956e7f 100644
--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -707,7 +707,7 @@ static const struct snd_pcm_ops azx_pcm_ops = {
 	.pointer = azx_pcm_pointer,
 	.get_time_info =  azx_get_time_info,
 	.mmap = azx_pcm_mmap,
-	.page = snd_pcm_sgbuf_ops_page,
+	// .page = snd_pcm_sgbuf_ops_page,
 };
 
 static void azx_pcm_free(struct snd_pcm *pcm)


And, again, please avoid top-posting.


Takashi

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: 答复: 答复:  A bug about cache inconsistency report
       [not found]       ` <fd1d78d3a46845f2867fbc79deabe066@zhaoxin.com>
@ 2018-08-02 14:35         ` Takashi Iwai
  2018-08-06  4:01           ` 答复: " Hans Hu(SH-RD)
  0 siblings, 1 reply; 15+ messages in thread
From: Takashi Iwai @ 2018-08-02 14:35 UTC (permalink / raw)
  To: Hans Hu(SH-RD); +Cc: 'alsa-devel@alsa-project.org'

On Thu, 02 Aug 2018 15:59:31 +0200,
Hans Hu(SH-RD) wrote:
> 
> > 1. noise relate test:
> > When I annotate the return after set_pages_array_wc, then
> > set_memory_wc works, noise disappear static void
> > __mark_pages_wc(struct azx *chip, struct snd_dma_buffer *dmab, bool
> > on) { ...
> > set_pages_array_wb(sgbuf->page_table, sgbuf->pages); //return; }
> > #endif
> 
> > set_memory_uc() performs __pa() for the given address, and in this case, it's vmapped address.  Something bogus in your test, I'm afraid.
> 
> [Hans:] I know __pa() handle the vmapped address is wrong, that why I don't know how to fix the problem, I try this because I see kernel older than 3.7.6. [bogus? pretending to be real or genuine?] no no no, but the noise problem machine(8086:1c20) in another city, I will make sure it again.
 
I meant about the reliability of the test result.  Or whether we're
heading to a wrong fish.

In anyway, which kernel version are you testing?  And exactly what is
your problem?  Which machine, which hardware setup (codec, etc) and
which output, and how is the sound backend (PulseAudio or direct ALSA
write)?

> > And moreover, all Intel chipsets do work with snooping well, AFAIK.
> [Hans:] yes, all Intel chipsets do work with snooping well here too. And the problem case here is "non-snoop"+"aplay -D plughw:*.*"+"44.1k 16bit"+"8086:1c20", I will see if I can find more machine do the test.

Ah, so you explicitly test with non-snoop mode for this chipset?
For what purpose...?

> > 2. change *_SG relate test:
> > Just followed your proposal
> > -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
> > +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
> 
> >OK, you need one more oneliner:
> 
> >diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c index a12e594d4e3b..2eaed4956e7f 100644
> >--- a/sound/pci/hda/hda_controller.c
> >+++ b/sound/pci/hda/hda_controller.c
> >@@ -707,7 +707,7 @@ static const struct snd_pcm_ops azx_pcm_ops = {
>  >.pointer = azx_pcm_pointer,
>  >.get_time_info =  azx_get_time_info,
>  >.mmap = azx_pcm_mmap,
> >-.page = snd_pcm_sgbuf_ops_page,
> >+// .page = snd_pcm_sgbuf_ops_page,
> > };
> 
> > static void azx_pcm_free(struct snd_pcm *pcm)
> [Hans :] I did this, and the Oops report as the same.

My bad, there are other SG-buffer codes in sound/hda/*, too.

So scratch these two oneliners.  The only thing you'd need is the
big-hammer change (again oneliner :)

--- a/sound/core/Kconfig
+++ b/sound/core/Kconfig
@@ -181,7 +181,7 @@ config SND_VMASTER
 	bool
 
 config SND_DMA_SGBUF
-	def_bool y
+	def_bool n
 	depends on X86
 
 source "sound/core/seq/Kconfig"

> >And, again, please avoid top-posting.
> [Hans :] sorry, I didn't understand at first. My mailbox is Outlook, am I right now?

Yes, looks better now.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 15+ messages in thread

* 答复: 答复: 答复:  A bug about cache inconsistency report
  2018-08-02 14:35         ` 答复: " Takashi Iwai
@ 2018-08-06  4:01           ` Hans Hu(SH-RD)
  2018-08-06  5:36             ` Takashi Iwai
  0 siblings, 1 reply; 15+ messages in thread
From: Hans Hu(SH-RD) @ 2018-08-06  4:01 UTC (permalink / raw)
  To: 'Takashi Iwai'
  Cc: Tony W. Wang(BJ-RD), 'alsa-devel@alsa-project.org',
	Tim Guo(BJ-RD), Annie Liu(BJ-RD)



-----邮件原件-----
发件人: Takashi Iwai [mailto:tiwai@suse.de]
发送时间: 02 August 2018 22:36
收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
主题: Re: 答复: 答复: [alsa-devel] A bug about cache inconsistency report

On Thu, 02 Aug 2018 15:59:31 +0200,
Hans Hu(SH-RD) wrote:
>
> > 1. noise relate test:
> > When I annotate the return after set_pages_array_wc, then
> > set_memory_wc works, noise disappear static void
> > __mark_pages_wc(struct azx *chip, struct snd_dma_buffer *dmab, bool
> > on) { ...
> > set_pages_array_wb(sgbuf->page_table, sgbuf->pages); //return; }
> > #endif
>
> > set_memory_uc() performs __pa() for the given address, and in this case, it's vmapped address.  Something bogus in your test, I'm afraid.
>
> [Hans:] I know __pa() handle the vmapped address is wrong, that why I don't know how to fix the problem, I try this because I see kernel older than 3.7.6. [bogus? pretending to be real or genuine?] no no no, but the noise problem machine(8086:1c20) in another city, I will make sure it again.

>I meant about the reliability of the test result.  Or whether we're heading to a wrong fish.
>In anyway, which kernel version are you testing?  And exactly what is your problem?  Which machine, which hardware setup (codec, etc) and which output, and how is the sound backend (PulseAudio or direct ALSA write)?

[Hans:] OS: Ubuntu 17.10 + 4.13.0-21-generic (or any one after 3.7.6).
HW: mother board is Dell 042P49, HDA controller is 8086:1c20, codec is cx20641.
Output and sound backend: Except the command below, anything other is default setting.

Problem(what I have done and found): When system setup, I add "modprobe snd-had-intel.snoop=0" in grub, after setup, execute command "aplay -D plughw:0,0 44.1k_16b_2c.wav", then I hear music with noise. The reason cause this is the buffer address should been mark as WC type and the __mark_pages_wc was patched for this, but if define CONFIG_SND_DMA_SGBUF, the actual marked address is the address before vmapped(0xffff88*...*), however the address used in snd_pcm_lib_write_transfer() is the address after vmapped(0xffffc9*...*), so the mark didn't work and cache inconsistency occur(noise).

> > And moreover, all Intel chipsets do work with snooping well, AFAIK.
> [Hans:] yes, all Intel chipsets do work with snooping well here too. And the problem case here is "non-snoop"+"aplay -D plughw:*.*"+"44.1k 16bit"+"8086:1c20", I will see if I can find more machine do the test.
>Ah, so you explicitly test with non-snoop mode for this chipset?
>For what purpose...?

[Hans:] Yes, I've been testing a HDA controller recently(predecessor is VIA), it has the same problem. I want to figure out if it is hardware's problem or not.

[Hans:] I did the same test on another platform(8086:A170), it do work with non-snoop well.  In addition, I did such a change, oneliner, the purpose is to mark nothing, and it still do work with non-snoop well, this  supposed to be right?

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
#ifdef CONFIG_X86
static void __mark_pages_wc(struct azx *chip, struct snd_dma_buffer *dmab, bool on)
{
int pages;
+return;



> > 2. change *_SG relate test:
> > Just followed your proposal
> > -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
> > +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
>
> >OK, you need one more oneliner:
>
> >diff --git a/sound/pci/hda/hda_controller.c
> >b/sound/pci/hda/hda_controller.c index a12e594d4e3b..2eaed4956e7f
> >100644
> >--- a/sound/pci/hda/hda_controller.c
> >+++ b/sound/pci/hda/hda_controller.c
> >@@ -707,7 +707,7 @@ static const struct snd_pcm_ops azx_pcm_ops = {
>  >.pointer = azx_pcm_pointer,
>  >.get_time_info =  azx_get_time_info,  >.mmap = azx_pcm_mmap,
> >-.page = snd_pcm_sgbuf_ops_page,
> >+// .page = snd_pcm_sgbuf_ops_page,
> > };
>
> > static void azx_pcm_free(struct snd_pcm *pcm)
> [Hans :] I did this, and the Oops report as the same.

>My bad, there are other SG-buffer codes in sound/hda/*, too.

>So scratch these two oneliners.  The only thing you'd need is the big-hammer change (again oneliner :)

>--- a/sound/core/Kconfig
>+++ b/sound/core/Kconfig
>@@ -181,7 +181,7 @@ config SND_VMASTER
 >bool
>
> config SND_DMA_SGBUF
>-def_bool y
>+def_bool n
> depends on X86

> source "sound/core/seq/Kconfig"

[Hans :] If this, All the platform are all right.


Thank you,

Hans


保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 答复: 答复: 答复:  A bug about cache inconsistency report
  2018-08-06  4:01           ` 答复: " Hans Hu(SH-RD)
@ 2018-08-06  5:36             ` Takashi Iwai
  0 siblings, 0 replies; 15+ messages in thread
From: Takashi Iwai @ 2018-08-06  5:36 UTC (permalink / raw)
  To: Hans Hu(SH-RD)
  Cc: Tony W. Wang(BJ-RD), 'alsa-devel@alsa-project.org',
	Tim Guo(BJ-RD), Annie Liu(BJ-RD)

On Mon, 06 Aug 2018 06:01:34 +0200,
Hans Hu(SH-RD) wrote:
> 
> 
> 
> -----邮件原件-----
> 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> 发送时间: 02 August 2018 22:36
> 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> 主题: Re: 答复: 答复: [alsa-devel] A bug about cache inconsistency report
> 
> On Thu, 02 Aug 2018 15:59:31 +0200,
> Hans Hu(SH-RD) wrote:
> >
> > > 1. noise relate test:
> > > When I annotate the return after set_pages_array_wc, then
> > > set_memory_wc works, noise disappear static void
> > > __mark_pages_wc(struct azx *chip, struct snd_dma_buffer *dmab, bool
> > > on) { ...
> > > set_pages_array_wb(sgbuf->page_table, sgbuf->pages); //return; }
> > > #endif
> >
> > > set_memory_uc() performs __pa() for the given address, and in this case, it's vmapped address.  Something bogus in your test, I'm afraid.
> >
> > [Hans:] I know __pa() handle the vmapped address is wrong, that why I don't know how to fix the problem, I try this because I see kernel older than 3.7.6. [bogus? pretending to be real or genuine?] no no no, but the noise problem machine(8086:1c20) in another city, I will make sure it again.
> 
> >I meant about the reliability of the test result.  Or whether we're heading to a wrong fish.
> >In anyway, which kernel version are you testing?  And exactly what is your problem?  Which machine, which hardware setup (codec, etc) and which output, and how is the sound backend (PulseAudio or direct ALSA write)?
> 
> [Hans:] OS: Ubuntu 17.10 + 4.13.0-21-generic (or any one after 3.7.6).
> HW: mother board is Dell 042P49, HDA controller is 8086:1c20, codec is cx20641.
> Output and sound backend: Except the command below, anything other is default setting.
> 
> Problem(what I have done and found): When system setup, I add "modprobe snd-had-intel.snoop=0" in grub, after setup, execute command "aplay -D plughw:0,0 44.1k_16b_2c.wav", then I hear music with noise. The reason cause this is the buffer address should been mark as WC type and the __mark_pages_wc was patched for this, but if define CONFIG_SND_DMA_SGBUF, the actual marked address is the address before vmapped(0xffff88*...*), however the address used in snd_pcm_lib_write_transfer() is the address after vmapped(0xffffc9*...*), so the mark didn't work and cache inconsistency occur(noise).

Well, basically the vmapped address isn't used *at all* on the
HD-audio controller hardware.  The SG buffer addresses are passed on
BDL of the chip, but the vmapped address is used only in PCM core for
some data manipulation.  And this is purely software stuff, hence it
shouldn't matter there whether it's in snoop mode or not.  The snoop
mode difference appears mainly when accessed via mmap from user-space
directly to kernel-space.

That said, I guess your suspect heading to a wrong direction.

> > > And moreover, all Intel chipsets do work with snooping well, AFAIK.
> > [Hans:] yes, all Intel chipsets do work with snooping well here too. And the problem case here is "non-snoop"+"aplay -D plughw:*.*"+"44.1k 16bit"+"8086:1c20", I will see if I can find more machine do the test.
> >Ah, so you explicitly test with non-snoop mode for this chipset?
> >For what purpose...?
> 
> [Hans:] Yes, I've been testing a HDA controller recently(predecessor is VIA), it has the same problem. I want to figure out if it is hardware's problem or not.
> 
> [Hans:] I did the same test on another platform(8086:A170), it do work with non-snoop well.  In addition, I did such a change, oneliner, the purpose is to mark nothing, and it still do work with non-snoop well, this  supposed to be right?
> 
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> #ifdef CONFIG_X86
> static void __mark_pages_wc(struct azx *chip, struct snd_dma_buffer *dmab, bool on)
> {
> int pages;
> +return;

This is essentially other way round; it skips the non-cache setup.


> > > 2. change *_SG relate test:
> > > Just followed your proposal
> > > -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
> > > +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
> >
> > >OK, you need one more oneliner:
> >
> > >diff --git a/sound/pci/hda/hda_controller.c
> > >b/sound/pci/hda/hda_controller.c index a12e594d4e3b..2eaed4956e7f
> > >100644
> > >--- a/sound/pci/hda/hda_controller.c
> > >+++ b/sound/pci/hda/hda_controller.c
> > >@@ -707,7 +707,7 @@ static const struct snd_pcm_ops azx_pcm_ops = {
> >  >.pointer = azx_pcm_pointer,
> >  >.get_time_info =  azx_get_time_info,  >.mmap = azx_pcm_mmap,
> > >-.page = snd_pcm_sgbuf_ops_page,
> > >+// .page = snd_pcm_sgbuf_ops_page,
> > > };
> >
> > > static void azx_pcm_free(struct snd_pcm *pcm)
> > [Hans :] I did this, and the Oops report as the same.
> 
> >My bad, there are other SG-buffer codes in sound/hda/*, too.
> 
> >So scratch these two oneliners.  The only thing you'd need is the big-hammer change (again oneliner :)
> 
> >--- a/sound/core/Kconfig
> >+++ b/sound/core/Kconfig
> >@@ -181,7 +181,7 @@ config SND_VMASTER
>  >bool
> >
> > config SND_DMA_SGBUF
> >-def_bool y
> >+def_bool n
> > depends on X86
> 
> > source "sound/core/seq/Kconfig"
> 
> [Hans :] If this, All the platform are all right.

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.


Takashi

> Thank you,
> 
> Hans
> 
> 
> 保密声明:
> 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: A bug about cache inconsistency report
  2018-08-08 11:07 Hans Hu(SH-RD)
@ 2018-08-10 15:15 ` Takashi Iwai
  0 siblings, 0 replies; 15+ messages in thread
From: Takashi Iwai @ 2018-08-10 15:15 UTC (permalink / raw)
  To: Hans Hu(SH-RD)
  Cc: Tony W. Wang(BJ-RD), 'alsa-devel@alsa-project.org',
	Tim Guo(BJ-RD), Annie Liu(BJ-RD)

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: A bug about cache inconsistency report
@ 2018-08-08 11:07 Hans Hu(SH-RD)
  2018-08-10 15:15 ` Takashi Iwai
  0 siblings, 1 reply; 15+ messages in thread
From: Hans Hu(SH-RD) @ 2018-08-08 11:07 UTC (permalink / raw)
  To: 'Takashi Iwai'
  Cc: Tony W. Wang(BJ-RD), 'alsa-devel@alsa-project.org',
	Tim Guo(BJ-RD), Annie Liu(BJ-RD)

> > > > >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

Thanks,

Hans

> > 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.


保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: A bug about cache inconsistency report
  2018-08-07  9:00 Hans Hu(SH-RD)
@ 2018-08-07  9:25 ` Takashi Iwai
  0 siblings, 0 replies; 15+ messages in thread
From: Takashi Iwai @ 2018-08-07  9:25 UTC (permalink / raw)
  To: Hans Hu(SH-RD)
  Cc: Tony W. Wang(BJ-RD), 'alsa-devel@alsa-project.org',
	Tim Guo(BJ-RD), Annie Liu(BJ-RD)

On Tue, 07 Aug 2018 11:00:39 +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).


Takashi

---

diff --git a/sound/core/sgbuf.c b/sound/core/sgbuf.c
index 84fffabdd129..643f6cb2048c 100644
--- a/sound/core/sgbuf.c
+++ b/sound/core/sgbuf.c
@@ -68,7 +68,7 @@ void *snd_malloc_sgbuf_pages(struct device *device,
 			     size_t *res_size)
 {
 	struct snd_sg_buf *sgbuf;
-	unsigned int i, pages, chunk, maxpages;
+	unsigned int i, pages;
 	struct snd_dma_buffer tmpb;
 	struct snd_sg_page *table;
 	struct page **pgtable;
@@ -90,38 +90,18 @@ void *snd_malloc_sgbuf_pages(struct device *device,
 		goto _failed;
 	sgbuf->page_table = pgtable;
 
-	/* allocate pages */
-	maxpages = MAX_ALLOC_PAGES;
-	while (pages > 0) {
-		chunk = pages;
-		/* don't be too eager to take a huge chunk */
-		if (chunk > maxpages)
-			chunk = maxpages;
-		chunk <<= PAGE_SHIFT;
-		if (snd_dma_alloc_pages_fallback(SNDRV_DMA_TYPE_DEV, device,
-						 chunk, &tmpb) < 0) {
-			if (!sgbuf->pages)
-				goto _failed;
-			if (!res_size)
-				goto _failed;
-			size = sgbuf->pages * PAGE_SIZE;
-			break;
-		}
-		chunk = tmpb.bytes >> PAGE_SHIFT;
-		for (i = 0; i < chunk; i++) {
-			table->buf = tmpb.area;
-			table->addr = tmpb.addr;
-			if (!i)
-				table->addr |= chunk; /* mark head */
-			table++;
-			*pgtable++ = virt_to_page(tmpb.area);
-			tmpb.area += PAGE_SIZE;
-			tmpb.addr += PAGE_SIZE;
-		}
-		sgbuf->pages += chunk;
-		pages -= chunk;
-		if (chunk < maxpages)
-			maxpages = chunk;
+	if (snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, device, size, &tmpb) < 0)
+		goto _failed;
+
+	for (i = 0; i < pages; i++) {
+		table->buf = tmpb.area;
+		table->addr = tmpb.addr;
+		if (!i)
+			table->addr |= pages; /* mark head */
+		table++;
+		*pgtable++ = virt_to_page(tmpb.area);
+		tmpb.area += PAGE_SIZE;
+		tmpb.addr += PAGE_SIZE;
 	}
 
 	sgbuf->size = size;

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: A bug about cache inconsistency report
@ 2018-08-07  9:00 Hans Hu(SH-RD)
  2018-08-07  9:25 ` Takashi Iwai
  0 siblings, 1 reply; 15+ messages in thread
From: Hans Hu(SH-RD) @ 2018-08-07  9:00 UTC (permalink / raw)
  To: 'Takashi Iwai'
  Cc: Tony W. Wang(BJ-RD), 'alsa-devel@alsa-project.org',
	Tim Guo(BJ-RD), Annie Liu(BJ-RD)

> > > 1. noise relate test:
> > > When I annotate the return after set_pages_array_wc, then
> > > set_memory_wc works, noise disappear static void
> > > __mark_pages_wc(struct azx *chip, struct snd_dma_buffer *dmab,
> > > bool
> > > on) { ...
> > > set_pages_array_wb(sgbuf->page_table, sgbuf->pages); //return; }
> > > #endif
> >
> > > set_memory_uc() performs __pa() for the given address, and in this case, it's vmapped address.  Something bogus in your test, I'm afraid.
> >
> > [Hans:] I know __pa() handle the vmapped address is wrong, that why I don't know how to fix the problem, I try this because I see kernel older than 3.7.6. [bogus? pretending to be real or genuine?] no no no, but the noise problem machine(8086:1c20) in another city, I will make sure it again.
>
> >I meant about the reliability of the test result.  Or whether we're heading to a wrong fish.
> >In anyway, which kernel version are you testing?  And exactly what is your problem?  Which machine, which hardware setup (codec, etc) and which output, and how is the sound backend (PulseAudio or direct ALSA write)?
>
> [Hans:] OS: Ubuntu 17.10 + 4.13.0-21-generic (or any one after 3.7.6).
> HW: mother board is Dell 042P49, HDA controller is 8086:1c20, codec is cx20641.
> Output and sound backend: Except the command below, anything other is default setting.
>
> Problem(what I have done and found): When system setup, I add "modprobe snd-had-intel.snoop=0" in grub, after setup, execute command "aplay -D plughw:0,0 44.1k_16b_2c.wav", then I hear music with noise. The reason cause this is the buffer address should been mark as WC type and the __mark_pages_wc was patched for this, but if define CONFIG_SND_DMA_SGBUF, the actual marked address is the address before vmapped(0xffff88*...*), however the address used in snd_pcm_lib_write_transfer() is the address after vmapped(0xffffc9*...*), so the mark didn't work and cache inconsistency occur(noise).

>Well, basically the vmapped address isn't used *at all* on the HD-audio controller hardware.  The SG buffer addresses are passed on BDL of the chip, but the vmapped address is used only in PCM core for some data manipulation.  And this is purely software stuff, hence it shouldn't matter there whether it's in snoop mode or not.  The snoop mode difference appears mainly when accessed via mmap from user-space directly to kernel-space.
>That said, I guess your suspect heading to a wrong direction.

[Hans:] So, am I misunderstand? Or snoop has two different meanings? 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 WC 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().
Yes, of course, this path combinations(non-snoop + not-mmap) unlikely be used in most music players.


> > > And moreover, all Intel chipsets do work with snooping well, AFAIK.
> > [Hans:] yes, all Intel chipsets do work with snooping well here too. And the problem case here is "non-snoop"+"aplay -D plughw:*.*"+"44.1k 16bit"+"8086:1c20", I will see if I can find more machine do the test.
> >Ah, so you explicitly test with non-snoop mode for this chipset?
> >For what purpose...?
>
> [Hans:] Yes, I've been testing a HDA controller recently(predecessor is VIA), it has the same problem. I want to figure out if it is hardware's problem or not.
>
> [Hans:] I did the same test on another platform(8086:A170), it do work with non-snoop well.  In addition, I did such a change, oneliner, the purpose is to mark nothing, and it still do work with non-snoop well, this  supposed to be right?
>
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> #ifdef CONFIG_X86
> static void __mark_pages_wc(struct azx *chip, struct snd_dma_buffer
> *dmab, bool on) { int pages;
> +return;

>This is essentially other way round; it skips the non-cache setup.


> > > 2. change *_SG relate test:
> > > Just followed your proposal
> > > -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
> > > +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
> >
> > >OK, you need one more oneliner:
> >
> > >diff --git a/sound/pci/hda/hda_controller.c
> > >b/sound/pci/hda/hda_controller.c index a12e594d4e3b..2eaed4956e7f
> > >100644
> > >--- a/sound/pci/hda/hda_controller.c
> > >+++ b/sound/pci/hda/hda_controller.c
> > >@@ -707,7 +707,7 @@ static const struct snd_pcm_ops azx_pcm_ops = {
> >  >.pointer = azx_pcm_pointer,
> >  >.get_time_info =  azx_get_time_info,  >.mmap = azx_pcm_mmap,
> > >-.page = snd_pcm_sgbuf_ops_page,
> > >+// .page = snd_pcm_sgbuf_ops_page,
> > > };
> >
> > > static void azx_pcm_free(struct snd_pcm *pcm)
> > [Hans :] I did this, and the Oops report as the same.
>
> >My bad, there are other SG-buffer codes in sound/hda/*, too.
>
> >So scratch these two oneliners.  The only thing you'd need is the big-hammer change (again oneliner :)
>
> >--- a/sound/core/Kconfig
> >+++ b/sound/core/Kconfig
> >@@ -181,7 +181,7 @@ config SND_VMASTER
>  >bool
> >
> > config SND_DMA_SGBUF
> >-def_bool y
> >+def_bool n
> > depends on X86
>
> > source "sound/core/seq/Kconfig"
>
> [Hans :] If this, All the platform are all right.

>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.

---a/sound/core/sgbuf.c
+++b/sound/core/sgbuf.c
void *snd_malloc_sgbuf_pages(struct device *device,
     size_t size, struct snd_dma_buffer *dmab,
     size_t *res_size)
{
struct snd_sg_buf *sgbuf;
unsigned int i, pages, chunk, maxpages;
struct snd_dma_buffer tmpb;
struct snd_sg_page *table;
struct page **pgtable;

+size *= 2;  /* expand the buffer two times */

dmab->area = NULL;
dmab->addr = 0;

... ...

if (chunk < maxpages)
maxpages = chunk;
}

+for(i = 0; i < sgbuf->pages / 2; i ++)        /* restore size to the original it wanted */
+sgbuf->page_table[i] = sgbuf->page_table[i  * 2]; /* take a page every other page, just for test, ignore page release */
+size /= 2;
+sgbuf->pages /= 2;

sgbuf->size = size;
dmab->area = vmap(sgbuf->page_table, sgbuf->pages, VM_MAP, PAGE_KERNEL);


Thanks,

Hans



保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: A bug about cache inconsistency report
  2018-08-01  2:05 Hans Hu(SH-RD)
@ 2018-08-01  4:45 ` Takashi Iwai
  0 siblings, 0 replies; 15+ messages in thread
From: Takashi Iwai @ 2018-08-01  4:45 UTC (permalink / raw)
  To: Hans Hu(SH-RD); +Cc: 'alsa-devel@alsa-project.org'

On Wed, 01 Aug 2018 04:05:18 +0200,
Hans Hu(SH-RD) wrote:
> 
> I did more test base on different Intel platform, and result is the same.

Which platform did you test exactly?

> Maybe I made some mistake? Can you do the test in yours  platform?

The negative test result implies that the analysis isn't right.
Actually I haven't seen that problem on my test machines.

BTW, please avoid top-posting.


thanks,

Takashi

> 
> Thank you!
> Hans
> 
> -----邮件原件-----
> 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> 发送时间: 31 July 2018 21:55
> 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> 主题: Re: 答复: [alsa-devel] A bug about cache inconsistency report
> 
> On Tue, 31 Jul 2018 15:51:06 +0200,
> Hans Hu(SH-RD) wrote:
> >
> > I did the test and Oops report when install driver( both snoop and
> > non-snoop mode)
> 
> I don't understand.  Did my one-liner change the behavior or not?
> 
> 
> thanks,
> 
> Takashi
> 
> >
> > -----邮件原件-----
> > 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> > 发送时间: 31 July 2018 19:59
> > 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> > 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> > 主题: Re: [alsa-devel] A bug about cache inconsistency report
> >
> > On Tue, 31 Jul 2018 12:52:04 +0200,
> > Hans Hu(SH-RD) wrote:
> > >
> > > Hi All,
> > >
> > >                Try send an email.
> > >
> > >                Appearance:
> > > when use non-snoop + ioctl path combination, an issue occurs:
> > > usage: aplay -D plughw:0,0 44100_S16_LE_2c.wav Ubuntu, it
> > > performance intermittently noise;
> > >
> > > Root case:
> > >                Function set_pages_array_wc marked the PTE of the original address; Function set_memory_wc marked the PTE both original and after vmaped address.
> > > [cid:image002.png@01D428FF.92621520]
> > > However, cache or not in transmission process is based on the PTE of the later, and the set_pages_array_wc did't mark it, so a cache inconsistency issue occurs.
> > >
> > >                Related bug:
> > >                SHA1 ID: 9ddf1aeb2134e72275c97a2c6ff2e3eb04f2f27a
> >
> > OK, so did you confirm that dropping the SG buffer support "fixes" the noise problem on your system?  The easiest test would be like:
> >
> > --- a/sound/pci/hda/hda_controller.c
> > +++ b/sound/pci/hda/hda_controller.c
> > @@ -770,7 +770,7 @@ int snd_hda_attach_pcm_stream(struct hda_bus
> > *_bus, struct hda_codec *codec,  size = CONFIG_SND_HDA_PREALLOC_SIZE *
> > 1024;  if (size > MAX_PREALLOC_SIZE)  size = MAX_PREALLOC_SIZE;
> > -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
> > +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
> >        chip->card->dev,
> >        size, MAX_PREALLOC_SIZE);
> >  return 0;
> >
> >
> > thanks,
> >
> > Takashi
> >
> >
> > 保密声明:
> > 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> > CONFIDENTIAL NOTE:
> > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
> 
> 
> 保密声明:
> 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: A bug about cache inconsistency report
@ 2018-08-01  2:05 Hans Hu(SH-RD)
  2018-08-01  4:45 ` Takashi Iwai
  0 siblings, 1 reply; 15+ messages in thread
From: Hans Hu(SH-RD) @ 2018-08-01  2:05 UTC (permalink / raw)
  To: 'Takashi Iwai'; +Cc: 'alsa-devel@alsa-project.org'

I did more test base on different Intel platform, and result is the same.
Maybe I made some mistake? Can you do the test in yours  platform?


Thank you!
Hans

-----邮件原件-----
发件人: Takashi Iwai [mailto:tiwai@suse.de]
发送时间: 31 July 2018 21:55
收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
主题: Re: 答复: [alsa-devel] A bug about cache inconsistency report

On Tue, 31 Jul 2018 15:51:06 +0200,
Hans Hu(SH-RD) wrote:
>
> I did the test and Oops report when install driver( both snoop and
> non-snoop mode)

I don't understand.  Did my one-liner change the behavior or not?


thanks,

Takashi

>
> -----邮件原件-----
> 发件人: Takashi Iwai [mailto:tiwai@suse.de]
> 发送时间: 31 July 2018 19:59
> 收件人: Hans Hu(SH-RD) <HansHu@zhaoxin.com>
> 抄送: 'alsa-devel@alsa-project.org' <alsa-devel@alsa-project.org>
> 主题: Re: [alsa-devel] A bug about cache inconsistency report
>
> On Tue, 31 Jul 2018 12:52:04 +0200,
> Hans Hu(SH-RD) wrote:
> >
> > Hi All,
> >
> >                Try send an email.
> >
> >                Appearance:
> > when use non-snoop + ioctl path combination, an issue occurs:
> > usage: aplay -D plughw:0,0 44100_S16_LE_2c.wav Ubuntu, it
> > performance intermittently noise;
> >
> > Root case:
> >                Function set_pages_array_wc marked the PTE of the original address; Function set_memory_wc marked the PTE both original and after vmaped address.
> > [cid:image002.png@01D428FF.92621520]
> > However, cache or not in transmission process is based on the PTE of the later, and the set_pages_array_wc did't mark it, so a cache inconsistency issue occurs.
> >
> >                Related bug:
> >                SHA1 ID: 9ddf1aeb2134e72275c97a2c6ff2e3eb04f2f27a
>
> OK, so did you confirm that dropping the SG buffer support "fixes" the noise problem on your system?  The easiest test would be like:
>
> --- a/sound/pci/hda/hda_controller.c
> +++ b/sound/pci/hda/hda_controller.c
> @@ -770,7 +770,7 @@ int snd_hda_attach_pcm_stream(struct hda_bus
> *_bus, struct hda_codec *codec,  size = CONFIG_SND_HDA_PREALLOC_SIZE *
> 1024;  if (size > MAX_PREALLOC_SIZE)  size = MAX_PREALLOC_SIZE;
> -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
> +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
>        chip->card->dev,
>        size, MAX_PREALLOC_SIZE);
>  return 0;
>
>
> thanks,
>
> Takashi
>
>
> 保密声明:
> 本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.


保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: A bug about cache inconsistency report
  2018-07-31 10:52 Hans Hu(SH-RD)
@ 2018-07-31 11:59 ` Takashi Iwai
  0 siblings, 0 replies; 15+ messages in thread
From: Takashi Iwai @ 2018-07-31 11:59 UTC (permalink / raw)
  To: Hans Hu(SH-RD); +Cc: 'alsa-devel@alsa-project.org'

On Tue, 31 Jul 2018 12:52:04 +0200,
Hans Hu(SH-RD) wrote:
> 
> Hi All,
> 
>                Try send an email.
> 
>                Appearance:
> when use non-snoop + ioctl path combination, an issue occurs:
> usage: aplay -D plughw:0,0 44100_S16_LE_2c.wav
> Ubuntu, it performance intermittently noise;
> 
> Root case:
>                Function set_pages_array_wc marked the PTE of the original address; Function set_memory_wc marked the PTE both original and after vmaped address.
> [cid:image002.png@01D428FF.92621520]
> However, cache or not in transmission process is based on the PTE of the later, and the set_pages_array_wc did't mark it, so a cache inconsistency issue occurs.
> 
>                Related bug:
>                SHA1 ID: 9ddf1aeb2134e72275c97a2c6ff2e3eb04f2f27a

OK, so did you confirm that dropping the SG buffer support "fixes" the
noise problem on your system?  The easiest test would be like:

--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -770,7 +770,7 @@ int snd_hda_attach_pcm_stream(struct hda_bus *_bus, struct hda_codec *codec,
 	size = CONFIG_SND_HDA_PREALLOC_SIZE * 1024;
 	if (size > MAX_PREALLOC_SIZE)
 		size = MAX_PREALLOC_SIZE;
-	snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG,
+	snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
 					      chip->card->dev,
 					      size, MAX_PREALLOC_SIZE);
 	return 0;


thanks,

Takashi

^ permalink raw reply	[flat|nested] 15+ messages in thread

* A bug about cache inconsistency report
@ 2018-07-31 10:52 Hans Hu(SH-RD)
  2018-07-31 11:59 ` Takashi Iwai
  0 siblings, 1 reply; 15+ messages in thread
From: Hans Hu(SH-RD) @ 2018-07-31 10:52 UTC (permalink / raw)
  To: 'alsa-devel@alsa-project.org'


[-- Attachment #1.1: Type: text/plain, Size: 1058 bytes --]

Hi All,

               Try send an email.

               Appearance:
when use non-snoop + ioctl path combination, an issue occurs:
usage: aplay -D plughw:0,0 44100_S16_LE_2c.wav
Ubuntu, it performance intermittently noise;

Root case:
               Function set_pages_array_wc marked the PTE of the original address; Function set_memory_wc marked the PTE both original and after vmaped address.
[cid:image002.png@01D428FF.92621520]
However, cache or not in transmission process is based on the PTE of the later, and the set_pages_array_wc did't mark it, so a cache inconsistency issue occurs.

               Related bug:
               SHA1 ID: 9ddf1aeb2134e72275c97a2c6ff2e3eb04f2f27a

Best Regards!
Hans Hu



?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

[-- Attachment #1.2: image002.png --]
[-- Type: image/png, Size: 11070 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2018-08-10 15:15 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-02  8:22 A bug about cache inconsistency report Hans Hu(SH-RD)
2018-08-02  8:50 ` Takashi Iwai
2018-08-02 10:56   ` 答复: " Hans Hu(SH-RD)
2018-08-02 11:52     ` Takashi Iwai
     [not found]       ` <fd1d78d3a46845f2867fbc79deabe066@zhaoxin.com>
2018-08-02 14:35         ` 答复: " Takashi Iwai
2018-08-06  4:01           ` 答复: " Hans Hu(SH-RD)
2018-08-06  5:36             ` Takashi Iwai
  -- strict thread matches above, loose matches on Subject: below --
2018-08-08 11:07 Hans Hu(SH-RD)
2018-08-10 15:15 ` Takashi Iwai
2018-08-07  9:00 Hans Hu(SH-RD)
2018-08-07  9:25 ` Takashi Iwai
2018-08-01  2:05 Hans Hu(SH-RD)
2018-08-01  4:45 ` Takashi Iwai
2018-07-31 10:52 Hans Hu(SH-RD)
2018-07-31 11:59 ` Takashi Iwai

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.