[Intel-gfx] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

Fri Apr 28 19:37:45 UTC 2017

On Fri, Apr 28, 2017 at 12:10:31PM -0500, Pierre-Louis Bossart wrote:
> 
> 
> On 04/28/2017 03:41 AM, Takashi Iwai wrote:
> > On Thu, 27 Apr 2017 18:02:19 +0200,
> > ville.syrjala at linux.intel.com wrote:
> >> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >>
> >> Okay, here's the second attempt at getting multiple pipes playing back
> >> audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is
> >> that now the PCM devices are associated with ports instead of pipes,
> >> so the audio from one device always gets output on the same display.
> >>
> >> I've also tacked on the alsa-lib conf update. No clue whether it's
> >> really correct or not (the config language isn't a close friend
> >> of mine).
> >>
> >> BTW I did notice that with LPE audio all the controls say iface=PCM,
> >> whereas on HDA a bunch of them say iface=MIXER. No idea if that's
> >> OK or not, just something I spotted when I was comparing the results
> >> with HDA.
> > We generally accept both iface types for IEC958 stuff, since
> > historically many drivers have already mixed them up.  So it's no
> > problem :)
> >
> >
> >> Entire series available here:
> >> git://github.com/vsyrjala/linux.git lpe_audio_multipipe_2
> >>
> >> Cc: Takashi Iwai <tiwai at suse.de>
> >> Cc: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com>
> > All look good, and feel free to take my reviewed-by tag
> >    Reviewed-by: Takashi Iwai <tiwai at suse.de>
> >
> > As said previously, my only slight concern is the compatibility.
> > But, in the current situation with PulseAudio, only few people would
> > use this driver, so it shouldn't be so big impact, I suppose.
> >
> > BTW, which port is used in general on BYT/CHT?
> >
> > Oh, also, I suppose you want to carry these over i915 tree?
> > I don't mind either way, I can take them through sound tree if
> > preferred, too.
> I see frequent oops on startup with this lpe_audio_multipipe_2 branch 
> with my CHT device not booting or no HDMI audio device created.
> Not sure if these issues are due to the new patches or to the rest of 
> the drm code?
> 
> [    5.529023] BUG: unable to handle kernel NULL pointer dereference 
> at           (null)
> [    5.529143] IP: hdmi_lpe_audio_probe+0x40f/0x650 [snd_hdmi_lpe_audio]
> [    5.529202] PGD 0
> 
> [    5.529242] Oops: 0000 [#1] SMP
> [    5.529274] Modules linked in: snd_soc_sst_atom_hifi2_platform 
> snd_soc_sst_match snd_soc_core snd_compress lpc_ich snd_seq 
> snd_seq_device shpchp snd_hdmi_lpe_audio(+) snd_pcm snd_timer dw_dmac 
> snd soundcore i2c_designware_platform(+) i2c_designware_core 
> spi_pxa2xx_platform acpi_pad mac_hid nfsd auth_rpcgss nfs_acl lockd 
> grace sunrpc ip_tables x_tables hid_generic mmc_block i2c_hid usbhid hid 
> autofs4
> [    5.529605] CPU: 2 PID: 512 Comm: systemd-udevd Not tainted 
> 4.11.0-rc8-test+ #11
> [    5.529671] Hardware name: ZOTAC XXXXXX/Cherry Trail FFD, BIOS 5.11 
> 09/28/2016
> [    5.529736] task: ffff88007485b780 task.stack: ffffc90000bfc000
> [    5.529793] RIP: 0010:hdmi_lpe_audio_probe+0x40f/0x650 
> [snd_hdmi_lpe_audio]
> [    5.529855] RSP: 0018:ffffc90000bffaf0 EFLAGS: 00010246
> [    5.529904] RAX: 0000000000000000 RBX: ffff880079209898 RCX: 
> ffff88007920f078
> [    5.529967] RDX: 0000000000000014 RSI: ffffc90000bffb28 RDI: 
> 0000000000000002
> [    5.530031] RBP: ffffc90000bffb70 R08: 0000000000000001 R09: 
> 0000000000000000
> [    5.530094] R10: ffff88007441bf00 R11: ffffc90000bffb36 R12: 
> ffff88007920ef20
> [    5.530159] R13: ffff88007920ef48 R14: 0000000000005688 R15: 
> 0000000000000047
> [    5.530225] FS:  00007f627c988640(0000) GS:ffff88007b300000(0000) 
> knlGS:0000000000000000
> [    5.530299] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    5.530352] CR2: 0000000000000000 CR3: 0000000078cb8000 CR4: 
> 00000000001006e0
> [    5.530416] Call Trace:
> [    5.530452]  platform_drv_probe+0x3b/0xa0
> [    5.530494]  driver_probe_device+0x2bb/0x460
> [    5.530538]  __driver_attach+0xdf/0xf0
> [    5.530576]  ? driver_probe_device+0x460/0x460
> [    5.530620]  bus_for_each_dev+0x60/0xa0
> [    5.530658]  driver_attach+0x1e/0x20
> [    5.530693]  bus_add_driver+0x170/0x270
> [    5.530731]  driver_register+0x60/0xe0
> [    5.530769]  ? 0xffffffffa01cb000
> [    5.530803]  __platform_driver_register+0x36/0x40
> [    5.530851]  hdmi_lpe_audio_driver_init+0x17/0x1000 [snd_hdmi_lpe_audio]
> [    5.530915]  do_one_initcall+0x43/0x180
> [    5.530956]  ? __vunmap+0x81/0xd0
> [    5.530991]  ? kfree+0x14c/0x160
> [    5.531024]  ? kmem_cache_alloc_trace+0x38/0x150
> [    5.531070]  do_init_module+0x5f/0x1f8
> [    5.531108]  load_module+0x271e/0x2bd0
> [    5.531147]  ? kernel_read_file+0x1a3/0x1c0
> [    5.531188]  SYSC_finit_module+0xbc/0xf0
> [    5.531226]  ? SYSC_finit_module+0xbc/0xf0
> [    5.531267]  SyS_finit_module+0xe/0x10
> [    5.531305]  do_syscall_64+0x6e/0x180
> [    5.531345]  entry_SYSCALL64_slow_path+0x25/0x25
> [    5.531389] RIP: 0033:0x7f627b5fbbf9
> [    5.531424] RSP: 002b:00007ffe053eee68 EFLAGS: 00000246 ORIG_RAX: 
> 0000000000000139
> [    5.531493] RAX: ffffffffffffffda RBX: 000055d6c745b690 RCX: 
> 00007f627b5fbbf9
> [    5.531558] RDX: 0000000000000000 RSI: 00007f627c134995 RDI: 
> 0000000000000007
> [    5.531622] RBP: 00007f627c134995 R08: 0000000000000000 R09: 
> 00007ffe053eef80
> [    5.531687] R10: 0000000000000007 R11: 0000000000000246 R12: 
> 0000000000000000
> [    5.531751] R13: 000055d6c7459ae0 R14: 0000000000020000 R15: 
> 000055d6c745b690
> [    5.531816] Code: 48 8b 45 b0 8b 48 18 e8 e0 cb 22 e1 49 8b 44 24 28 
> 4a 8d 8c 33 58 01 00 00 48 8d 75 b8 45 31 c9 41 b8 01 00 00 00 ba 14 00 
> 00 00 <48> 8b 38 e8 a9 2a ff ff 85 c0 0f 88 09 01 00 00 49 8b 84 24 58

Disassembling that I get:

  4005a0:       48 8b 45 b0             mov    -0x50(%rbp),%rax
  4005a4:       8b 48 18                mov    0x18(%rax),%ecx
  4005a7:       e8 e0 cb 22 e1          callq  ffffffffe162d18c <_end+0xffffffffe102c14c>
  4005ac:       49 8b 44 24 28          mov    0x28(%r12),%rax
  4005b1:       4a 8d 8c 33 58 01 00    lea    0x158(%rbx,%r14,1),%rcx
  4005b8:       00 
  4005b9:       48 8d 75 b8             lea    -0x48(%rbp),%rsi
  4005bd:       45 31 c9                xor    %r9d,%r9d
  4005c0:       41 b8 01 00 00 00       mov    $0x1,%r8d
  4005c6:       ba 14 00 00 00          mov    $0x14,%edx
  4005cb:       48 8b 38                mov    (%rax),%rdi
  4005ce:       e8 a9 2a ff ff          callq  3f307c <_init-0xd32c>
  4005d3:       85 c0                   test   %eax,%eax
  4005d5:       0f 88 09 01 00 00       js     4006e4 <__GNU_EH_FRAME_HDR+0x100>
  4005db:       49                      rex.WB
  4005dc:       8b                      .byte 0x8b
  4005dd:       84 24 58                test   %ah,(%rax,%rbx,2)

Comparing that with the disassembly from my build, that
first call looks like the snprintf() and the second one would
then be snd_jack_new(). So it seems to blow in the
ctx->card_ctx->card dereference. But I don't really see how
a NULL pointer could sneak in there.

-- 
Ville Syrjälä
Intel OTC